Uzebox Bootloader V5

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

Re: New bootloader

Post by Jubatian »

HOLY-SON-OF-A-COW!

This will seriously compete for the tilte of being the most ridiculous bug I faced ever.

It turned out to be a rather trivial thing once discovering it, but of course with every bug, discovering the cause is what takes long and gets hair pulled out.

The problem was around Line 210 in the kernel. There I initialized for displaying the video mode, but forgot to set up first_render_line and render_lines_count. These work the same way like in the regular kernel, the video frame driver copies the "tmp" variables to the actual variables in VSync. However to do that, first it has to get to VSync. And that may be impossible if the variables it is trying to read while generating the signal are set up in a manner that they can't produce video (worse, in a way that the video frame driver can never reach VSync to set them up correctly).

Apparently that particular broken SD library demo had such values in the RAM positions used for these variables in the bootloader that it couldn't get to VSync.

Updated bootloader (V.5.0.01) is attached to the top post, replacing the previous one. So this should now really work! :D (You can put away the o-scope :lol: )
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: New bootloader

Post by nicksen782 »

Whoo hoo! Hide and Seek master!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New bootloader

Post by Artcfox »

Good catch!

That almost makes me wonder if we couldn't add some sort of "fuzzing" option to cuzebox, that could run a game with the memory that isn't explicitly set to zero by the program, pre-set to something else. Although it seems like a static analyzer might do a much better job of catching those bugs.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

Artcfox wrote: Mon Oct 09, 2017 9:21 pmThat almost makes me wonder if we couldn't add some sort of "fuzzing" option to cuzebox, that could run a game with the memory that isn't explicitly set to zero by the program, pre-set to something else. Although it seems like a static analyzer might do a much better job of catching those bugs.
It would be possible, but that would make starting from a definite state more difficult or needing more things to store (complicating capturing and replaying controller input reliably - if I ever implement that, I don't want to do it by a command-line flag, rather that the emulator would capture into memory which you can decide to save at any point during playing, say, if you run in something interesting).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New bootloader

Post by Artcfox »

Gotcha. Maybe if clang/llvm can ever cross-compile AVR code we could use is static analyzer.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

Another update: V.5.0.02 Bootloader added (download from top post).

No bugs this time, rather new features.
  • Displays the year of the game (as stored in the UZE file), it is capable to display between 2000 and 2099.
  • When loading, uses hollow rectangles to indicate that no actual programming happened on a given sector group.
I also did a minor interface tweak, the "Insert SD Card" screen no longer flickers occasionally (it was due to that it still tried to poll the nonexisting card then occasionally instead of just attempting to init).

Of course to get this all in, there were lots of small tweaks in code size to make room :P
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: New bootloader

Post by nicksen782 »

Jubatian wrote: Sun Oct 08, 2017 11:45 am Exposed SD & FAT API which may later be used by the kernel or games to add SDHC & FAT32 support.
Does this mean that games can access code within the bootloader such as the code it uses for the SD card? Am I reading that correctly? How??
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

nicksen782 wrote: Tue Oct 10, 2017 8:45 pm
Jubatian wrote: Sun Oct 08, 2017 11:45 am Exposed SD & FAT API which may later be used by the kernel or games to add SDHC & FAT32 support.
Does this mean that games can access code within the bootloader such as the code it uses for the SD card? Am I reading that correctly? How??
Yes, it means exactly that. There are API entry points in a pre-defined location (actually substituting the largely unused interrupt vector table) along with a "magic value" to allow for detecting the bootloader, and its version number. I will create a FAT library later which can interface it (having a minimal fallback to FAT16 + no fragmentation SD cards if there is no suitable bootloader present), this I believe will be very useful for a "new wave" of SPI RAM games which don't require full speed SD access anyway (so they can just work since if the bootloader could load them, then they can happily access the card themselves too with the bootloader's code which was proven working by loading the game).
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: New bootloader

Post by nicksen782 »

... that ... sounds ... AWESOME!

Now, figure out a way for people to update their bootloaders without using an ISP and you are golden!

But I have an ISP so I'm already ready!

I wonder... could the old bootloader be used to overwrite itself? Could a bootloader overwrite itself?

EDIT: And one more question, what about SD writing?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: New bootloader

Post by CunningFellow »

nicksen782 wrote: Tue Oct 10, 2017 9:17 pm Now, figure out a way for people to update their bootloaders without using an ISP and you are golden!
I was discussing this with someone a little while ago.

If you know where the bootloaders SPM instruction is you can set up your write from "user land" and hijack the bootloader to do your bidding. Then just have the timer interrupt rescue control back to you again after the write.

We where talking about how you would have to know what version of the bootloader was already in the machine to know where SPM was and all sorts of "what if" things. Then who ever I was chatting to about it found this with his obviously much better google skills than I have.

http://oneweekwonder.blogspot.com.au/20 ... -hack.html

Someone else already had the idea and has written a general purpose version that finds the SPM for you.
Post Reply