Skip to content

Working on the Firmware

Last updated on 2021-05-31

The last 2 nights i spend some time debugging the firmware of the prototype board. I added CRC checks for the sram areas and each uploaded bank. Hence i can push roms to the sram and verify it at runtime on both sides. So i can see if there are any transfer errors. Iam not using any CRC checks on USB layer, because the VUSB lib only supports this for 18MHz driven mcpus and we use 20MHz. This why i have to do it by ‘hand’ later after a block/bank is upoaded.

Also i switched the SRAM addressing mode to the faster counter based version. This boosted the upload speed by a great magnitude. I guess there is more room for optimization, but right now its quite fast to upload a rom. Like 2 seconds for a 32kb LOROM bank. So just a few seconds for a 4mbit game.

I know that USB could do much faster, but there are limits to the USB lib we are using. The client side allows only transfer up to 254 for each call. Minus the protocol overhead. Also the host side runs in user mode and can’t be compared to a kernel module performance. USB Transfer is realized thru callback in the firmware. Right now an 128 Bytes data transfer is splitted into 16 times 8 bytes payload callbacks. So i got a huge accumulated function overhead with this. Either i have to optimize this callback behavior or do it in ASM to squeeze out some cycles.

There a little downside right now. I can’t get commerical roms working. Iam able to upload and run homebrew stuff, but games doesn’t seem to boot. Sometime i have weird crashes in homebrew stuff.

I can assume that our attached CRC chip is working, because i made it into the start screen of Mr.Do, but Super Mario World doesn’t even show up the Nintendo start logo.
I guess there is something wrong with the our HI/LOROM or WR Enable switching logic. Have to investigate this….

Comments are closed, but trackbacks and pingbacks are open.