Uzebox Bootloader V5
Re: New bootloader
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! (You can put away the o-scope )
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! (You can put away the o-scope )
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: New bootloader
Whoo hoo! Hide and Seek master!
Re: New bootloader
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.
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.
Re: New bootloader
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).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.
Re: New bootloader
Gotcha. Maybe if clang/llvm can ever cross-compile AVR code we could use is static analyzer.
Re: New bootloader
Another update: V.5.0.02 Bootloader added (download from top post).
No bugs this time, rather new features.
Of course to get this all in, there were lots of small tweaks in code size to make room
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.
Of course to get this all in, there were lots of small tweaks in code size to make room
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: New bootloader
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).nicksen782 wrote: ↑Tue Oct 10, 2017 8:45 pmDoes 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??
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: New bootloader
... 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?
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?
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: New bootloader
I was discussing this with someone a little while ago.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!
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.