Uzebox Bootloader V5

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New bootloader

Post by Artcfox »

nicksen782 wrote: Tue Jun 09, 2020 3:38 pm I have not been able to play Tornado on real hardware. I have played it on the emulators though. I would really like to play it on a real tv.

So, there is a new bootloader that will support Tornado and a new update to Tornado too?

Uze (or whomever knows for certain) what should the fuses be set to?
Yes! Using SDHC cards.

The new bootloader (5.0.12) lives in this directory of the official Uzebox repository:

Code: Select all

uzebox/demos/Bootloader5
(Make sure you do a git pull, since there were recent changes.)

The new Tornado 2000 that supports SDHC cards can be found in this post and the data file it needs can be downloaded here.

Once you build the bootloader, you can flash it onto a Uzebox using:

Code: Select all

avrdude -c avrispmkII -P usb -p m644 -U flash:w:Bootloader5.hex
And then flash the fuses with:

Code: Select all

avrdude -c avrispmkII -P usb -p m644 -U hfuse:w:0xd2:m -U lfuse:w:0xf7:m -U efuse:w:0xfc:m
If you aren't using an AVR ISP mkII, then change the:

Code: Select all

avrispmkII
to whatever the avrdude name of your programmer is.

IIRC, changing that extended fuse raises the brownout detection to 4.5V, so the chip doesn't come out of reset until the power is more stable. (It helped my original Uzebox from a kit get a more reliable video signal when powering it on with the new bootloader.) I'm not sure what the impact of having that level of brownout detection on the Uzebox Portable is, but so far mine has been running fine with it. I just hope that it's still below the level where the low battery LED comes on. If you don't want to mess with the brownout detection, then you can leave off the:

Code: Select all

 -U efuse:w:0xfc:m
part of that command.

If you are reflashing this bootloader on a Uzebox DTV, you will have to change the device name in the above commands to:

Code: Select all

m644p
and FYI, the ICSP pinouts for the Uzebox DTV are: GND, VCC, RESET, SCK, MISO, MOSI with GND being the pin closest to the uSD card.
Last edited by Artcfox on Thu Jun 11, 2020 4:35 am, edited 1 time in total.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

Those fuses indeed might need some thought, seems to me you (Artcfox) are leaning towards keeping it safe (selecting longer startup delays and adding the BOD), which in fact is a good idea! Especially due to the thing being overclocked.

On normal Uzeboxes (using the DIP ATmega) either the 644 or the 644p can occur, whichever chip you happen to have (ATmega644 and ATmega644A are 644, while ATmega644P and ATmega644PA are 644p, tried all four at some point, either works).

Setting the BOD might be reasonable not only for the startup, but since it just can not really be expected that the MCU runs okay almost 1.5 times its rated frequency at lower power. The startup delays (for frequency stabilization) might be interesting to tweak as shortening them (BOD only, no extra milliseconds) can allow for smoother transition between bootloader and game (depending on display).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New bootloader

Post by Artcfox »

I was messing around with different themes for the new Bootloader, and I think I finally settled on the one to use for my D3thAdd3r-themed Uzebox, and Uzebox Portable:
Screenshot from 2020-06-12 15-01-37.png
Screenshot from 2020-06-12 15-01-37.png (15.61 KiB) Viewed 22598 times
IMG_20151120_231400.jpg
IMG_20151120_231400.jpg (110.25 KiB) Viewed 22598 times
Here is a diff against the latest Bootloader5 from the main Uzebox repo. (It also corrects the capitalization of "Uzebox" in the bootloader.)

Code: Select all

diff --git a/demos/Bootloader5/graphics.s b/demos/Bootloader5/graphics.s
index 941c764..5352eb1 100644
--- a/demos/Bootloader5/graphics.s
+++ b/demos/Bootloader5/graphics.s
@@ -177,7 +177,7 @@ Graphics_InitPal:
 
 Graphics_paldata:
        .byte 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-       .byte 0xAD, 0xB6, 0xB7, 0xFF, 0xFF, 0xB7, 0xB6, 0xAD
-       .byte 0x00, 0x66, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-       .byte 0x01, 0x0A, 0x0B, 0x13, 0x13, 0x0B, 0x0A, 0x01
+       .byte 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F
+       .byte 0x07, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+       .byte 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
 
diff --git a/demos/Bootloader5/res.s b/demos/Bootloader5/res.s
index 7fa37ab..e56c8b5 100644
--- a/demos/Bootloader5/res.s
+++ b/demos/Bootloader5/res.s
@@ -221,7 +221,7 @@ RGCR_data_empty:
        .byte ' ' - 32, 'C' - 32, 'a' - 32, 'r' - 32, 'd' - 32
 
 RGCR_data_title:
-       .byte 'U' - 32, 'z' - 32, 'e' - 32, 'B' - 32, 'o' - 32, 'x' - 32, ' ' - 32, 'G' - 32
+       .byte 'U' - 32, 'z' - 32, 'e' - 32, 'b' - 32, 'o' - 32, 'x' - 32, ' ' - 32, 'G' - 32
        .byte 'a' - 32, 'm' - 32, 'e' - 32, ' ' - 32, 'L' - 32, 'o' - 32, 'a' - 32, 'd' - 32
        .byte 'e' - 32, 'r' - 32, ' ' - 32, ' ' - 32, ' ' - 32, ' ' - 32, ' ' - 32, ' ' - 32
        .byte 'V' - 32, '.' - 32
And I've also attached a Bootloader5.hex file.
Attachments
Bootloader5.hex
(11.29 KiB) Downloaded 962 times
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

Artcfox wrote: Sat Jun 13, 2020 10:12 pm I was messing around with different themes for the new Bootloader, and I think I finally settled on the one to use for my D3thAdd3r-themed Uzebox, and Uzebox Portable:
Nice! Glad to see it is hackable enough to pull of such tweaks! :)
User avatar
Kilo
Posts: 330
Joined: Wed Dec 19, 2012 3:43 pm
Location: AC, Germany

Re: New bootloader

Post by Kilo »

Hey,

don't know how much free space left for the bootloader but would it be possible to implement some nice features?

What I'm missing is a function to delete .uze files from the SD card directly in the bootloader.
Also a small subfolder function would be cool. Such as: ACTION, PUZZLE, etc.
And in that folders are the .uze files. 🤔
The last digit of Pi is 7! I calculated this, as I counted to infinity yesterday!
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: New bootloader

Post by CunningFellow »

Apparently in its current state there is only a byte or two of FLASH free.

I think an architecture rethink could gain enough space for some new features, but it is a big big job and not one I think anyone has time for.
rv6502
Posts: 80
Joined: Mon Feb 11, 2019 4:27 am

Re: New bootloader

Post by rv6502 »

Yeah, looks like a big job.

( I can't remember if I suggested this already, it's been a while :lol: )
I think the easiest way to add features would be to load another 4K (or however much) just under the bootloader on demand.

Would require an extra file on the SD card to provide the extended part of the bootloader.

I haven't checked the kernel EEPROM blocks but if there's room there could be a flag put in there to mark that the extended section is intact along with a checksum that way the [SD MENU] can be entered without the SD card actually present or without the bootloader extension file present on the SD card.

Since the end part of the flash is the least re-flashed, if a game doesn't go all the way to the top of the flash there's no need to reflash every time.

Keep just the minimum into the base bootloader:

Code: Select all

   [GAME] <-- --> [LOAD SD MENU]
If the bootloader is set to [game], just boot the game (not that menu)
If the bootloader is set to [menu] and the extended part is intact, go right to the menu.
If the bootloader is set to [menu] but the extended part is taken by the game, show this menu to avoid some reflashing when possible.

Sadly I haven't got any time for that fun stuff right now either.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: New bootloader

Post by CunningFellow »

I think from my back of napkin calculations it is possible to have a bootloader that fits in 4K do game icons/animations.

Genre/subfolders would be doable also.
Bluescreen2001
Posts: 78
Joined: Wed Nov 02, 2022 3:57 pm

Re: Uzebox Bootloader V5

Post by Bluescreen2001 »

Is there some flashing via uart implemented in the bootloader? Like the Arduino bootloader.
I am currently programming for the Uzebox and it is very annoying to everytime pull the SD card, copy the new uze file to it, reinsert and running the uze file from the bootloader.

A much faster turnaround time is flashing the new software via ISP and AVRDude. But this destroys the bootloader and I need to open up my nice Uzebox case to get the ISP connector.

I see the bootloader space is nearly full, so I don't think it is possible to add such thing if it is not already there.

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

Re: Uzebox Bootloader V5

Post by D3thAdd3r »

That would be a great feature to aid hardware development, but as far as I know it isn't present. Jubatian has a habit of insane optimization levels, so I would be surprised if there were any real tricks left to make extra space either.
CunningFellow wrote: Fri Aug 05, 2022 7:41 am I think from my back of napkin calculations it is possible to have a bootloader that fits in 4K do game icons/animations.

Genre/subfolders would be doable also.
Well...maybe such things are possible? Eh, out of my realm either way.

I would recommend just ditching the bootloader while you are doing hardware development, and flashing the .hex directly, then putting it back when you are done with hardware stuff. Or have multiple Uzebox for different purposes. Would it be possible for you to make a case mod something like this?
Image
Post Reply