Uzebox SD Gameloader V0.4.5

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
JRoatch
Posts: 108
Joined: Mon May 11, 2009 11:48 pm
Contact:

Re: Uzebox SD Gameloader Alpha...at last!

Post by JRoatch »

I encountered a strange glitch today and I can't seem to reproduce it.
While I was playing zombienator, I died in a 1 player game then I decided to play a 2 player game, but then the screen went black and started flashing something like "Init Good First read fails" and "Error reading SD image" rapidly. It wouldn't go away even if I pressed the reset button. I had to unplug it and replug it back in to fix it. :?

By the way, For people using avrdude, here's the command I used to set the fuses.

Code: Select all

avrdude -v -p m644 -P usb -c avrispmkII -U hfuse:w:0xD2:m
If other bytes of fuses need to be set(I had the avcore) so as to match the options from the first post use these options:
-U efuse:w:0xFE:m
-U hfuse:w:0xD2:m
-U lfuse:w:0xFF:m
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox SD Gameloader Alpha...at last!

Post by uze6666 »

I encountered a strange glitch today and I can't seem to reproduce it.
While I was playing zombienator, I died in a 1 player game then I decided to play a 2 player game, but then the screen went black and started flashing something like "Init Good First read fails" and "Error reading SD image" rapidly. It wouldn't go away even if I pressed the reset button. I had to unplug it and replug it back in to fix it. :?
Weird! Just like the game resetted or branched into the bootloader. If it happens again try removing then re-inserting the SD, after that the reset usually works again.

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

Re: Uzebox SD Gameloader Alpha...at last!

Post by JRoatch »

If I was to try to work on the bootloader on the weekend which branch and folder should I try to compile and work on?
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox SD Gameloader Alpha...at last!

Post by uze6666 »

It's unfortunate Pragma has kinda disappeared as he was working on SD/MCC and FAT code. I took over and reworked it to be C callable. So I'd use this one (it uses the latest SD/MMC code in assembler, plus starting FAT16): http://code.google.com/p/uzebox/source/ ... Bootloader

I think we should keep in sync and pre-agree on what to work on in order to plan, not duplicate efforts and go in the same direction. So far here's the vision:
  • Gotta fit in 4K (duh :) )
  • Have SD/MMC on FAT16 work first and keeping in mind SDHC and FAT32.
  • The developed code to be part of the kernel, so all exportable function must be C-callable
  • SD/FAT16 read code in assembler (no choice, really). Can be developed in C to test/validate concepts, that's what I'm doing for FAT16 (and there a heck of work left here)
  • GUI in C for ease of use, if it wont fit 4K, we'll port to assembler
  • Have the bootloader boot using a configurable mode as discussed previously
  • Find some way for the currently programmed game to invoke the flashing code to "chain programs together", i.e. flashing the next level
So right now, the chunk left is the FAT16 code. Specially file filtering and cluster chaining. We would need some plan/model if we were to work both at the same time on this. Let me know in what you are interested in.

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

Re: Uzebox SD Gameloader Alpha...at last!

Post by tim1724 »

That looks like an excellent plan.
User avatar
JRoatch
Posts: 108
Joined: Mon May 11, 2009 11:48 pm
Contact:

Re: Uzebox SD Gameloader Alpha...at last!

Post by JRoatch »

I saw what the size of the current bootloader is (4042 bytes). What have I gotten myself into?
I'll take a look at the source later on in the week, I can't exactly say what I'll choose to work on at this moment.

I'm sure you know this already, I'll say what's on my mind anyway.
I think when designing we should let whatever memory the C-callable Routines (and it's subroutines) be relocatable by a pointer that's passed and or put onto the stack. That way when a game calls a bootloader routine (if it can do that) such as "read sector X", the game can tell were that 512 byte block memory will be located.

Other than that, there's a lot of things I'm going to have to learn. Like how SD/MCC works, how FAT is structured, etc.

Also should I use Packrom or rompacker?
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox SD Gameloader Alpha...at last!

Post by uze6666 »

I saw what the size of the current bootloader is (4042 bytes). What have I gotten myself into?
Yep, gotta fit the video kernel, basic sound, a font, MMC/SD card & FAT16 routines and a nice GUI in 4096 bytes! :lol:
I think when designing we should let whatever memory the C-callable Routines (and it's subroutines) be relocatable by a pointer that's passed and or put onto the stack. That way when a game calls a bootloader routine (if it can do that) such as "read sector X", the game can tell were that 512 byte block memory will be located.
Yeah, it already like that. the fat_init and mmc_int takes a single parameter, a pointer to a 512 bytes buffer. But I'm deeply devised on the fact that games should depend on the bootloader to run at all. There was a thread discussing this some time ago (can't find it) and most thought it should be avoided. That said, I'd like to hear what the community has to say and suggest their pro and cons. For one, we can't fit any write routines in there, so the main program must have it. Since the MMC/FAT api uses internal functions & variable, how to share them?? But the Atmega1284 has 128K of flash, meaning the bootloader will be at a higher address making pointer sharing "harder"?

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

Re: Uzebox SD Gameloader Alpha...at last!

Post by JRoatch »

I think that if there's going to be callable boot functions, the internal variables that aren't on a stack should be an offset from a pointer passed to it. As for the difficulty of maintaining addresses between bootloader versions(there's bound to be bugs). In that case, I think that the bootloader functions should be somehow callable by defined byte values (kind of like the GBA BIOS calls). Maybe that's accomplished by a jump table in a single function at a constant address. As for Atmega1284, there will be a flag for the game ROM that says if it is for the Atmega644 or the Atmega1284. So if the game is for the Atmega644 but it's actually on the Atmega1284, then the Atmega1284 bootloader will write a jump instruction (and/or other redirects) at the address were the Atmega644 bootloader calls would of been.

Maybe we won't have a full FAT file system manipulating functions, but at the very least we should have a "write 512 bytes to sector X" function.
User avatar
JRoatch
Posts: 108
Joined: Mon May 11, 2009 11:48 pm
Contact:

Re: Uzebox SD Gameloader Alpha...at last!

Post by JRoatch »

Other things came up so I probably won't be working on the boot-loader this weekend.

What I'll probably be doing is finding and fixing miscellaneous compile errors, and other miscellaneous things.
I might also look into why rompacker segfaults with SpriteDemo.hex (even if compiled from source).
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox SD Gameloader Alpha...at last!

Post by uze6666 »

Seg faults? On which platform, Windoze?

-Uze
Post Reply