Bootloader

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Bootloader

Post by Jhysaun » Fri May 29, 2009 6:10 am

So I've was looking at the Bootloader code in the SVN repository, and I saw that Uze is using a kernel without sound to make the bootloader size smaller. Yet the graphics code and the font probably takes up a decent amount of program space (currently 3.4% of the total space). But why don't we (by we I mean pragma and Uze) just have the bootloader ONLY have code for loading stuff from the SD card (No video/sound). We can store a file manager on the SD card and the bootloader will load the file manager to the 644. After copying the file manager to the program memory from the SD card, it could boot that program. The file manager could take up the full 64K of Program space (meaning fancy graphics plus sound). When you want to run a program, just have the file manager overwrite itself with a program on the SD card. *If* you can't have a program overwrite itself, we could always have the file manager write the file name you want to boot to EEPROM, and restart the system. The bootloader would see that a file name is in the EEPROM, it could copy that file, and it could over right the old file name back to the Filemanager.

>J
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.

User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: Bootloader

Post by Jhysaun » Fri May 29, 2009 6:16 am

For Example:

I have an SD Card with these files:

Filemanager.hex
Megatris.hex
Halloween.hex

When the Uzebox starts, the bootloader reads the EEPROM and sees Filemanager.hex.

The bootloader copies Filemanager.hex to the Program Memory.

In Filemanager.hex it lists all the files on the SD card. I tell it to run Megatris.hex. The file manager writes "Megatris.hex" to EEPROM. The file manager then reboots the uzebox.

When the uzebox reboots, the bootloader reads EEPROM and sees Megatris. It first changes the EEPROM back to Filemanager.hex so next time it boots it runs the filemanager. Then it copies Megatris.hex into the program memory. You then play Megatris.

Next time the uzebox starts up the bootloader sees "Filemanager.hex" in EEPROM and it will boot into the Filemanager again.

If this is possible, it will allow the filemanager to be as large as any other program.

>J
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.

User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Bootloader

Post by pragma » Fri May 29, 2009 3:34 pm

Jhysaun wrote:So I've was looking at the Bootloader code in the SVN repository, and I saw that Uze is using a kernel without sound to make the bootloader size smaller. Yet the graphics code and the font probably takes up a decent amount of program space (currently 3.4% of the total space). But why don't we (by we I mean pragma and Uze) just have the bootloader ONLY have code for loading stuff from the SD card (No video/sound). We can store a file manager on the SD card and the bootloader will load the file manager to the 644. After copying the file manager to the program memory from the SD card, it could boot that program. The file manager could take up the full 64K of Program space (meaning fancy graphics plus sound). When you want to run a program, just have the file manager overwrite itself with a program on the SD card. *If* you can't have a program overwrite itself, we could always have the file manager write the file name you want to boot to EEPROM, and restart the system. The bootloader would see that a file name is in the EEPROM, it could copy that file, and it could over right the old file name back to the Filemanager.

>J
There's just one problem with this. The 644 has built-in protection against overwriting PGM space if the program counter is *outside* the specified bootloader space, however big that is. This partitioning, and the size of the boot area is controlled externally by the fuse bits. So I think that you can't overwrite yourself when in the normal "application" area of the chip.

That said, it might be possible to create a hybrid application of sorts where the minimal FAT read and PGM write routines are kept in boot space, and the deluxe loader application is simply installed for UI purposes. That would work, since the minimal FAT support needs to be there to bootstrap the whole mess anyway. There's also this issue of grooming the EEPROM space (ala Playstation memory cards) that also puts even more demand on the bootloader - this could go a long way to solve that problem.

Also, I cooked up some FAT stuff for Uze and it looks like the bootloader is within 1K or so of the planned 4k target, without any optimization. Uze also suggested that by using a ramtile-based text mode, more space can be freed by loading the font from the SD card. I have a feeling that's the direction this is headed. :)

User avatar
JRoatch
Posts: 108
Joined: Mon May 11, 2009 11:48 pm
Contact:

Re: Bootloader

Post by JRoatch » Fri May 29, 2009 3:48 pm

Here's what I think the bootloader could be, but I probably have no sense of how much ROM space this would take.
The bootloader (which I think would be 4k if i remembered correctly) would first check to see if there is a SD card (while maintaining video signal), and if there isn't it would start the program that is written to the other 60k, but if there is a SD card. It would then attempt to read all the files (from the root of the SD card most likely) that could be installed (something as simple as files ending with .hex), and then display a list of games to choose from along with the game already written.

the screen could look something like this.

Code: Select all

 UZEBOX GAME SELECTOR
----INSTALLED---------------------------
-> Megatris.hex
----SD CARD-----------------------------
  MEGATRIS.HEX
  HALLOWEEN.HEX
  PACMAN.HEX
In replay to pragma. I still hope that a font could be in the bootloader. I'm still theorizing on how the font could be smaller.

User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Bootloader

Post by pragma » Fri May 29, 2009 4:09 pm

JRoatch wrote:Here's what I think the bootloader could be, but I probably have no sense of how much ROM space this would take.
The bootloader (which I think would be 4k if i remembered correctly) would first check to see if there is a SD card (while maintaining video signal), and if there isn't it would start the program that is written to the other 60k, but if there is a SD card. It would then attempt to read all the files (from the root of the SD card most likely) that could be installed (something as simple as files ending with .hex), and then display a list of games to choose from along with the game already written.

the screen could look something like this.

Code: Select all

 UZEBOX GAME SELECTOR
----INSTALLED---------------------------
-> Megatris.hex
----SD CARD-----------------------------
  MEGATRIS.HEX
  HALLOWEEN.HEX
  PACMAN.HEX
In replay to pragma. I still hope that a font could be in the bootloader. I'm still theorizing on how the font could be smaller.
I think we're all on the same page with this, but I can't speak for Uze. Everything I've seen and thought about myself is along these lines.

With respect to the font, it already is bitmapped monocrhome at roughly eight bytes per letter - it doesn't get much smaller than that. I suspect that compression will require as many if not more bytes in program logic to decode as what is saved by compressing the font. I feel like we're already close to the balance point as it is. If push comes to shove, I really think that going the other direction and putting a high-resolution font in RAM (and loading it from the SD card) is the best way to conserve PGM space. But again, Uze gets the final word on that one.

I really think that the bootloader will wind up in 100% ASM, with heavy use of functions and call instructions to minimize the code footprint. Right now, the bulk of things is in unoptimized C and ASM, so there's lots of room to reduce overhead. I think it's doable in 4k.

User avatar
JRoatch
Posts: 108
Joined: Mon May 11, 2009 11:48 pm
Contact:

Re: Bootloader

Post by JRoatch » Fri May 29, 2009 9:46 pm

I'm not sure if this would help anything, but here's another video mode I thought up. I would try to program it myself but I'm still trying to figure out how to compile a program for uzebox on a GNU/linux system.

It's a bit packed mode just like the one currently for the bootloader. Only with a smaller font.
Each character is 6 pixels high and 4 pixels wide. Each pixel is 4 pixels wide(in the emulator) and each scanline is repeated twice. and also there's 2 (emulator) pixels before each character. That would give us 40 by 18 characters on the screen. The first and last 8 scanlines would be black.

This way each character would only take 3 bytes, and I think the raster code would be about the same complexity as it is right now.
The font is very pixelated though.
Attachments
mock_screenshot_halfsize.png
A mock screenshot of a small font video mode, at half the size of the emulator.
mock_screenshot_halfsize.png (1.4 KiB) Viewed 4962 times
4x6_font.png
The small font.
4x6_font.png (343 Bytes) Viewed 4915 times

tim1724
Posts: 30
Joined: Mon Dec 08, 2008 8:38 pm

Re: Bootloader

Post by tim1724 » Fri May 29, 2009 9:52 pm

pragma wrote: There's just one problem with this. The 644 has built-in protection against overwriting PGM space if the program counter is *outside* the specified bootloader space, however big that is. This partitioning, and the size of the boot area is controlled externally by the fuse bits. So I think that you can't overwrite yourself when in the normal "application" area of the chip.
It seems to me that you could have a function in the bootloader section which takes a filename of the file to use and then does the re-flashing.

But I'd rather have the more complicated boot loader anyway. Sure, we'd be giving up some extra storage space, but I think it would be worth it. Also, it would prevent reprogramming the flash as often. (with Jhysaun's proposal, you'd be reprogramming it twice every time you turned the machine on, unless you were very careful to remove the SD card.)

User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Bootloader

Post by pragma » Fri May 29, 2009 9:59 pm

::headdesk:: Don't keep the empty pixels in memory, and use a smaller font. :)

That's a great idea. I agree that would be a big step forward for the memory size. That brings us down from 1KB to 384 bytes!

The only lingering problem is the game names. Right now, I've only gone as far as 8.3 filenames - no long file name (LFN) support. Given that .hex files don't store any kind of metadata, that puts the burden of readable titles back to LFN stuff if we can figure out how to do it given the memory constraints involved.

User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: Bootloader

Post by Jhysaun » Sat May 30, 2009 6:16 am

Given that .hex files don't store any kind of metadata,
So why don't we (again meaning you and Uze) just make a new file type (*.uze files)

It could be something like this

Code: Select all

#Megatris
!Uze6666
*40 KiB
$
(This is where the Hex code starts)
This filetype is simple, the key is the first charicter of ech line

# means name
! means developer
* means size
$ signals the end of Meta data and the start of Hexcode

I can' think of any other info we need

>J
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.

PlayerOne
Posts: 21
Joined: Mon Sep 29, 2008 8:45 pm
Location: UK

Re: Bootloader

Post by PlayerOne » Sat May 30, 2009 8:40 am

It seems to me that a simple, useful bootloader would be:

If you switch on the uzebox with a&b held down (or whatever), then flash BOOT.UZE from the root of the SD card.

No video required, and the FAT handling could probably be simplified. Maybe some audio, just to indicate that it's working.

Yes, it would be nice to have some more flexible and friendly bootloader, but the above would at least mean my uzebox doesn't need to be physically connected to both my laptop and my TV.

Incidentally, would the loader use .hex files, or would it need the "compiled" binary? A hex file is a text representation of binary isn't it?

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests