Revised port inits, please test!

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
Jubatian
Posts: 1406
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Revised port inits, please test!

Post by Jubatian » Wed Oct 18, 2017 3:35 pm

I opened an issue in the Uzebox repo:

https://github.com/Uzebox/uzebox/issues/82

If you can, please test whether the proposed fix ( https://github.com/Uzebox/uzebox/pull/83 or the new bootloader's 5.0.07 version) works on your hardware.

The problem I found is that by how the original kernel & bootloader initializes I/O ports it sets them up quite dangerously for the SD Card (and the SPI RAM) which might be a cause of the rare occasional fried cards. If the modified version works on your hardware I will merge it in. Also possibly time for merging the new bootloader (I added the fix to the old one, but compiling it so it actually works is another problem...).

I tested on a V.1.3.1 PCB Uzebox with ATMega644 and an E-Uzebox with ATMega644p, the fixed versions (5.0.07 bootloader and some games in the master) work on these.

User avatar
Jubatian
Posts: 1406
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Revised port inits, please test!

Post by Jubatian » Tue Oct 24, 2017 7:30 am

Could anyone report on this one? If there is no problem with it, I will merge it in!

User avatar
nicksen782
Posts: 677
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Revised port inits, please test!

Post by nicksen782 » Wed Oct 25, 2017 3:06 am

I have a V1.2 board here with the SPIRAM/WiFi module installed. I was able to flash the new bootloader. I was also able to flash a game with it. Upon resetting the game (with the reset button) I saw the flashing progress bar moving from the bootloader before my game started. It moved faster this time probably because the game was already flashed.

Code in case anybody was wondering: (Linux)

Code: Select all

sudo avrdude -V -p m644 -P usb -c usbtiny -B 1 -U flash:w:Desktop/bootld.hex 
It works and is fast. If I could report any bug it would be that if the SD card is ejected that the info of the selected game remains at the bottom. That's it.

I have a "factory" Uzebox other than a 3D printed enclosure. I can only confirm that it works on my Uzebox. Hopefully this is helpful.

EDIT: Retraction! I tried to reflash the game but only got the quick progress bar (then the game loaded.) I then put other .uze files on the SD card. They were not seen by the new bootloader. Only the existing game that was on the card. So I deleted the existing game and then recopied over some .uze files. The SD card appears to be detected but the bootloader states that the card is empty.

I need to investigate further. I'll update later.

EDIT: I formatted the card in different ways.

In Linux: sudo mkdosfs -F 16 /dev/mmcblk0p1

In Windows from "My Computer"

With the SD Formatter Tool.

I tried full (not quick) formats with the Windows and SD Formatter Tools.

It only worked with the SD Formatter Tool. Does it use a different allocation unit or cluster size or something? I've not had this problem before.

... Seems I can't write files to it via my Ubuntu Linux system. I can use a Windows machine though. Why? I was on Ubuntu 16 and now I am on 17. Should it really make a difference? When I tested the first time that dev copy of Bubble Bobble had been written by an Ubuntu 16 machine.

Sorry I wasn't much help. I tried to flash back the old boot loader too. Same thing except giberish filenames. I don't think the bootloader is at fault.

EDIT: I was able to write a file from Linux. I'm going to bed. ... I'll test it all again tomorrow.

User avatar
Jubatian
Posts: 1406
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Revised port inits, please test!

Post by Jubatian » Wed Oct 25, 2017 5:33 am

Thanks! At least that Uzebox seem to be happy with the new port inits then! :)
nicksen782 wrote:
Wed Oct 25, 2017 3:06 am
I saw the flashing progress bar moving from the bootloader before my game started. It moved faster this time probably because the game was already flashed.
That's how it is supposed to work: unlike the old bootloader this doesn't attempt to remember which game is loaded, it rather sweeps the game file and compares to the flash contents, flashing every page which has to be flashed. You will see hollow progress bas boxes for 2K blocks which didn't contain any actual flashing (the contents already matched).
nicksen782 wrote:
Wed Oct 25, 2017 3:06 am
If I could report any bug it would be that if the SD card is ejected that the info of the selected game remains at the bottom.
I just don't clear that region, I didn't think it important enough to waste ROM space for the code :)
nicksen782 wrote:
Wed Oct 25, 2017 3:06 am
Retraction! I tried to reflash the game but only got the quick progress bar (then the game loaded.) I then put other .uze files on the SD card. They were not seen by the new bootloader. Only the existing game that was on the card. So I deleted the existing game and then recopied over some .uze files. The SD card appears to be detected but the bootloader states that the card is empty.

(...)
Could you create a dump (with "dd") of the beginning of a card exhibiting the problem? First 16 megabytes, maybe, not of the partition, the entire card (so a device like "/dev/mmcblk0", wherever your card comes up). Most likely the filenames are non-standard in some manner or the MBR could contain something odd. What's the actual size of the card? It seems odd to me that you need to specify FAT16 explicitly. The new bootloader can understand FAT32.

You also say "sudo mkdosfs -F 16 /dev/mmcblk0p1". That's as far as I see is the second partition of the SD card, and that's not seen by the bootloader. The bootloader, if the card is actually partitioned, only uses the first partition (/dev/mmcblk0p0). You might investigate it a bit, if you are somehow missing the first partition, then something might be screwed up with the card's formatting (not the partition, the entire card, maybe using cfdisk is necessary, or you might just format the device itself to FAT losing the partition table).

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Revised port inits, please test!

Post by D3thAdd3r » Wed Oct 25, 2017 6:04 am

Sorry I have been busy lately, but I think this works. I will do some more extensive testing tomorrow and report back.

CunningFellow
Posts: 1192
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Revised port inits, please test!

Post by CunningFellow » Wed Oct 25, 2017 8:13 am

Sorry for not reporting earlier - I had lent someone my AvrOne! so could not flash anything.

I can confirm it works fine on my hardware.

T2K does not load afterwards, but that is probably its fault for not doing init of the SD correctly.

I will have to update T2K to be able to use SDHC cards soon.

User avatar
Jubatian
Posts: 1406
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Revised port inits, please test!

Post by Jubatian » Wed Oct 25, 2017 6:10 pm

CunningFellow wrote:
Wed Oct 25, 2017 8:13 am
T2K does not load afterwards, but that is probably its fault for not doing init of the SD correctly.

I will have to update T2K to be able to use SDHC cards soon.
I wanted to take a look of it, but couldn't find the source right now. For the SDHC adaption, I suggest to look into how the new bootloader API is used in the example library (it is here). So you don't need to implement SDHC and FAT32 on your own, you can request the bootloader to do it for you to arrive to having a start sector of your level file. If you do it like the example library does, you will also retain compatibility with the old bootloader and emulators as there it would use the same MMC init like the old bootloader.

Doing this should make it easier to adapt SDHC and FAT32 (as you don't need to adapt it at all, just use the bootloader if available, other bootloaders don't understand SDHC or FAT32 anyway :) ).

I wished to look in the code though to see why it doesn't work with the new init (I guess you attempted a compile and it failed to work, or do you meand that when using the new bootloader, you can't play Tornado 2000? - even if it is on a card which it can normally use?).

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest