CUzeBox - The new official Uzebox emulator

[Artcfox]

I solved the issue for where the cross-compiled OS X version was looking for the libSDL2.dylib in a hardcoded place, and it now looks for it in the same directory as the cuzebox executable. I have updated the attachment in the post above with new i386 and x86_64 OS X builds.

I tested the executable inside the i386 directory on a real Mac and it works, but I don't have an x86_64 Mac to test the other build on, so if someone can test that, it would be greatly appreciated.

[Jubatian]

Cool, I would suggest zipping up the Windows binary, since most Windows users won't be able to do anything with a .tar.bz2 file.

Done, so it will be packed that way then (I dunno what Windows can easily extract).

If you need static linking for OS X, do it that way for that OS, maybe I will add a compile flag later by your description and some research. For Linux distros, I think it is fine as it is (SDL is pretty much a standard component which someone interested in Uzebox has likely installed as it is often required for games and other emulators too).

Edit: I spoke too soon earlier when I thought it was working. I'm having a hard time getting the bootloader to run games now. This is what it shows me: (...) and then when I try to pick a game, it just goes right back to the bootloader menu.

I did notice that if I run cuzebox with the bootloader, pick a .uze file play it, quit and then run cuzebox with a .hex file that's not the bootloader, it starts at the bootloader again instead of prioritizing the hex file. The only way that I can get it to play the new .hex file is if I delete the coderom.bin file. Is that intentional, or should it prioritize whatever is passed on the command line?

The warnings are normal. I tested with the 0.4.5 bootloader, and for me it works just like the real hardware (games start fine either in Game or Menu mode). Do you experience an actual change between CUzeBox versions? Are you sure you don't have anything pressed (or simulating any button being pressed in some manner) when booting?

Uze and Hex files behave a little differently, that's normal. An Uze file is certainly a game, so CUzeBox then prioritizes Game when auto-fusing the AVR (it sets the BOOTRST fuse to boot at 0x0000 thus ignoring any bootloader). When you upload a Hex file, if you have a bootloader in the resulting ROM (that restored from the saved ROM image if any and the added Hex file data), it will start the bootloader (it currently can't determine whether the .hex contains game, bootloader or maybe some mix, to do this, interface changes would be necessary).

[Artcfox]

Cool, I would suggest zipping up the Windows binary, since most Windows users won't be able to do anything with a .tar.bz2 file.

Done, so it will be packed that way then (I dunno what Windows can easily extract).

If you need static linking for OS X, do it that way for that OS, maybe I will add a compile flag later by your description and some research. For Linux distros, I think it is fine as it is (SDL is pretty much a standard component which someone interested in Uzebox has likely installed as it is often required for games and other emulators too).

Edit: I spoke too soon earlier when I thought it was working. I'm having a hard time getting the bootloader to run games now. This is what it shows me: (...) and then when I try to pick a game, it just goes right back to the bootloader menu.

I did notice that if I run cuzebox with the bootloader, pick a .uze file play it, quit and then run cuzebox with a .hex file that's not the bootloader, it starts at the bootloader again instead of prioritizing the hex file. The only way that I can get it to play the new .hex file is if I delete the coderom.bin file. Is that intentional, or should it prioritize whatever is passed on the command line?

The warnings are normal. I tested with the 0.4.5 bootloader, and for me it works just like the real hardware (games start fine either in Game or Menu mode). Do you experience an actual change between CUzeBox versions? Are you sure you don't have anything pressed (or simulating any button being pressed in some manner) when booting?

Uze and Hex files behave a little differently, that's normal. An Uze file is certainly a game, so CUzeBox then prioritizes Game when auto-fusing the AVR (it sets the BOOTRST fuse to boot at 0x0000 thus ignoring any bootloader). When you upload a Hex file, if you have a bootloader in the resulting ROM (that restored from the saved ROM image if any and the added Hex file data), it will start the bootloader (it currently can't determine whether the .hex contains game, bootloader or maybe some mix, to do this, interface changes would be necessary).

I thought I might need static linking for SDL on OSX, but I don't anymore. I figured out how to get it to use rpath to find the .dylib in the same directory. I built production-ready binaries for OS X both i386 and x86_64, and replaced my proof-of-concept binaries in my older post with the production-ready versions.

I do experience an actual change with cuzebox, in that it no longer lets me pick games from the bootloader menu. In order for me to be able to get the bootloader to load and play a game (it doesn't try to flash the game as it thinks it's already there, but when it tries to run it, it goes right back to the bootloader) I needed to do a:

Code: Select all

git checkout 6af8950ad0171d3095d509c06f3d91ea73185af3

It wasn't enought to just revert the latest commit, I had to undo both of them.

[Jubatian]

I do experience an actual change with cuzebox, in that it no longer lets me pick games from the bootloader menu. In order for me to be able to get the bootloader to load and play a game (it doesn't try to flash the game as it thinks it's already there, but when it tries to run it, it goes right back to the bootloader) I needed to do a:

Code: Select all

git checkout 6af8950ad0171d3095d509c06f3d91ea73185af3

It wasn't enought to just revert the latest commit, I had to undo both of them.

I can not reproduce this. I did a fresh compile on latest, and copied the binary, Bootloader_0_4_5.hex, and two uze files in an empty directory. There starting the bootloader works all right, initially in Menu mode. I can program or restart games, works like real hardware. If I switch to Game mode, when starting the bootloader (./cuzebox Bootloader_0_4_5.hex), the last selected game starts, like on the real hardware. You can enter into the bootloader by quickly pressing down something while starting the emulator (same as real hardware, just that on real HW, you can hold down a controller button while plugging the thing in).

Can you send me a setup which produces the behaviour you think incorrect? (Package a CUzeBox binary and a set of game & bootloader files and instructions describing how to produce the behaviour you experience. Also include the description of build options or modifications used to build the CUzeBox binary if there was anything).

[Artcfox]

This is what happens with the latest code:

Code: Select all

user@debian:/tmp$ mkdir test-procedure
user@debian:/tmp$ cd test-procedure
user@debian:/tmp/test-procedure$ git clone https://github.com/jubatian/cuzebox
Cloning into 'cuzebox'...
remote: Counting objects: 594, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 594 (delta 2), reused 4 (delta 2), pack-reused 584
Receiving objects: 100% (594/594), 393.66 KiB | 0 bytes/s, done.
Resolving deltas: 100% (422/422), done.
user@debian:/tmp/test-procedure$ cd cuzebox/
user@debian:/tmp/test-procedure/cuzebox$ make
mkdir _obj_
gcc -c main.c -o _obj_/main.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_ufile.c -o _obj_/cu_ufile.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_hfile.c -o _obj_/cu_hfile.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_avr.c -o _obj_/cu_avr.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_avrc.c -o _obj_/cu_avrc.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_avrfg.c -o _obj_/cu_avrfg.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_ctr.c -o _obj_/cu_ctr.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_spi.c -o _obj_/cu_spi.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_spir.c -o _obj_/cu_spir.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_vfat.c -o _obj_/cu_vfat.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c cu_spisd.c -o _obj_/cu_spisd.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c filesys.c -o _obj_/filesys.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c eepdump.c -o _obj_/eepdump.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c romdump.c -o _obj_/romdump.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c guicore.c -o _obj_/guicore.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c audio.c -o _obj_/audio.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c ginput.c -o _obj_/ginput.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c frame.c -o _obj_/frame.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c chars.c -o _obj_/chars.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c textgui.c -o _obj_/textgui.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -c conout.c -o _obj_/conout.o -Os -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros 
gcc -o cuzebox _obj_/main.o _obj_/cu_ufile.o _obj_/cu_hfile.o _obj_/cu_avr.o _obj_/cu_avrc.o _obj_/cu_avrfg.o _obj_/cu_ctr.o _obj_/cu_spi.o _obj_/cu_spir.o _obj_/cu_vfat.o _obj_/cu_spisd.o _obj_/filesys.o _obj_/eepdump.o _obj_/romdump.o _obj_/guicore.o _obj_/audio.o _obj_/ginput.o _obj_/frame.o _obj_/chars.o _obj_/textgui.o _obj_/conout.o -O3 -s -flto  -DTARGET_LINUX -DVER_DATE=0x20170929 -DFLAG_DISPLAY_FRAMEMERGE=1 -Wall -pipe -pedantic -Wno-variadic-macros  -lSDL2
user@debian:/tmp/test-procedure/cuzebox$ wget http://uzebox.org/forums/download/file.php?id=2044
--2017-10-01 04:11:56--  http://uzebox.org/forums/download/file.php?id=2044
Resolving uzebox.org (uzebox.org)... 160.153.94.73
Connecting to uzebox.org (uzebox.org)|160.153.94.73|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11358 (11K) [application/octet-stream]
Saving to: ‘file.php?id=2044’

file.php?id=2044           100%[=====================================>]  11.09K  --.-KB/s    in 0.002s  

2017-10-01 04:11:56 (5.04 MB/s) - ‘file.php?id=2044’ saved [11358/11358]
user@debian:/tmp/test-procedure/cuzebox$ mv file.php\?id\=2044 Bootloader.hex
user@debian:/tmp/test-procedure/cuzebox$ wget http://uzebox.org/forums/download/file.php?id=2212
user@debian:/tmp/test-procedure/cuzebox$ mv file.php\?id\=2212 bugz.uze
user@debian:/tmp/test-procedure/cuzebox$ ./cuzebox Bootloader.hex
CUzeBox 20170929
UzeRom parser: Error: Bootloader.hex is not a UzeRom file.
Hex parser: Warning: Invalid record type on line 504 in Bootloader.hex.
Hex parser: Succesfully loaded program from Bootloader.hex
Starting emulator
Load game controller mappings:
    /tmp/test-procedure/cuzebox/gamecontrollerdb.txt
    could not open
Found: bugz.uze (58094 bytes)
Found: Bootloader.hex (11358 bytes)
Found: cuzebox (64072 bytes)
Found: types.h (2817 bytes)
Found: textgui.h (2571 bytes)
Found: textgui.c (11861 bytes)
Found: romdump.h (1498 bytes)
Found: romdump.c (2197 bytes)
Found: main.c (11365 bytes)
Found: guicore.h (3538 bytes)
Found: guicore.c (14930 bytes)
Found: ginput.h (1807 bytes)
Found: ginput.c (12575 bytes)
Found: gamefile.h (1295 bytes)
Found: frame.h (1693 bytes)
Found: frame.c (16420 bytes)
Found: filesys.h (4550 bytes)
Found: filesys.c (10475 bytes)
Found: filesmin.c (4972 bytes)
Found: eepdump.h (1439 bytes)
Found: eepdump.c (1927 bytes)
Found: cuzebox_minimal.html (2506 bytes)
Found: cu_vfat.h (3349 bytes)
Found: cu_vfat.c (15142 bytes)
Found: cu_ufile.h (1973 bytes)
Found: cu_ufile.c (3956 bytes)
Found: cu_types.h (7674 bytes)
Found: cu_spisd.h (3310 bytes)
Found: cu_spisd.c (24250 bytes)
Found: cu_spir.h (2530 bytes)
Found: cu_spir.c (5869 bytes)
Found: cu_spi.h (1806 bytes)
Found: cu_spi.c (2214 bytes)
Found: cu_hfile.h (1345 bytes)
Found: cu_hfile.c (5190 bytes)
Found: cu_ctr.h (2857 bytes)
Found: cu_ctr.c (3344 bytes)
Found: cu_avrfg.h (1689 bytes)
Found: cu_avrfg.c (5881 bytes)
Found: cu_avrc.h (5168 bytes)
Found: cu_avrc.c (12627 bytes)
Found: cu_avr_n.h (19755 bytes)
Found: cu_avr_e.h (24549 bytes)
Found: cu_avr.h (4914 bytes)
Found: cu_avr.c (35814 bytes)
Found: conout.h (1413 bytes)
Found: conout.c (2046 bytes)
Found: chars.h (1369 bytes)
Found: chars.c (5616 bytes)
Found: avr_inst_table.txt (3251 bytes)
Found: avconv.h (2624 bytes)
Found: avconv.c (5767 bytes)
Found: audio.h (1780 bytes)
Found: audio.c (7608 bytes)
Found: README.rst (7299 bytes)
Found: Makefile (4526 bytes)
Found: Make_defines.mk (3459 bytes)
Found: Make_config.mk (4906 bytes)
Found: LICENSE (35141 bytes)
Found: .gitignore (589 bytes)
CUzeBox: 100% 28.636MHz; 60Fps; Audio: 15.734KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 98% 28.114MHz; 61Fps; Audio: 15.748KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 61Fps; Audio: 15.781KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 61Fps; Audio: 15.798KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.610MHz; 60Fps; Audio: 15.810KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 97% 27.656MHz; 59Fps; Audio: 15.835KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 99% 28.238MHz; 60Fps; Audio: 15.837KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.610MHz; 60Fps; Audio: 15.838KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.610MHz; 60Fps; Audio: 15.834KHz; Keys: SNES 1P FrameMerge 

Now pick Bugz from the menu, and press START, notice it flashes the ROM, then press ESC to exit cuzebox.

Now do the same thing, and notice it flashes the ROM again (I would think that it wouldn't)

Code: Select all

user@debian:/tmp/test-procedure/cuzebox$ ./cuzebox Bootloader.hex 
CUzeBox 20170929
UzeRom parser: Error: Bootloader.hex is not a UzeRom file.
Hex parser: Warning: Invalid record type on line 504 in Bootloader.hex.
Hex parser: Succesfully loaded program from Bootloader.hex
Starting emulator
Load game controller mappings:
    /tmp/test-procedure/cuzebox/gamecontrollerdb.txt
    could not open
Found: eeprom.bin (2048 bytes)
Found: coderom.bin (65536 bytes)
Found: bugz.uze (58094 bytes)
Found: Bootloader.hex (11358 bytes)
Found: cuzebox (64072 bytes)
Found: types.h (2817 bytes)
Found: textgui.h (2571 bytes)
Found: textgui.c (11861 bytes)
Found: romdump.h (1498 bytes)
Found: romdump.c (2197 bytes)
Found: main.c (11365 bytes)
Found: guicore.h (3538 bytes)
Found: guicore.c (14930 bytes)
Found: ginput.h (1807 bytes)
Found: ginput.c (12575 bytes)
Found: gamefile.h (1295 bytes)
Found: frame.h (1693 bytes)
Found: frame.c (16420 bytes)
Found: filesys.h (4550 bytes)
Found: filesys.c (10475 bytes)
Found: filesmin.c (4972 bytes)
Found: eepdump.h (1439 bytes)
Found: eepdump.c (1927 bytes)
Found: cuzebox_minimal.html (2506 bytes)
Found: cu_vfat.h (3349 bytes)
Found: cu_vfat.c (15142 bytes)
Found: cu_ufile.h (1973 bytes)
Found: cu_ufile.c (3956 bytes)
Found: cu_types.h (7674 bytes)
Found: cu_spisd.h (3310 bytes)
Found: cu_spisd.c (24250 bytes)
Found: cu_spir.h (2530 bytes)
Found: cu_spir.c (5869 bytes)
Found: cu_spi.h (1806 bytes)
Found: cu_spi.c (2214 bytes)
Found: cu_hfile.h (1345 bytes)
Found: cu_hfile.c (5190 bytes)
Found: cu_ctr.h (2857 bytes)
Found: cu_ctr.c (3344 bytes)
Found: cu_avrfg.h (1689 bytes)
Found: cu_avrfg.c (5881 bytes)
Found: cu_avrc.h (5168 bytes)
Found: cu_avrc.c (12627 bytes)
Found: cu_avr_n.h (19755 bytes)
Found: cu_avr_e.h (24549 bytes)
Found: cu_avr.h (4914 bytes)
Found: cu_avr.c (35814 bytes)
Found: conout.h (1413 bytes)
Found: conout.c (2046 bytes)
Found: chars.h (1369 bytes)
Found: chars.c (5616 bytes)
Found: avr_inst_table.txt (3251 bytes)
Found: avconv.h (2624 bytes)
Found: avconv.c (5767 bytes)
Found: audio.h (1780 bytes)
Found: audio.c (7608 bytes)
Found: README.rst (7299 bytes)
Found: Makefile (4526 bytes)
Found: Make_defines.mk (3459 bytes)
Found: Make_config.mk (4906 bytes)
Found: LICENSE (35141 bytes)
Found: .gitignore (589 bytes)
CUzeBox: 100% 28.636MHz; 60Fps; Audio: 15.734KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 98% 28.114MHz; 61Fps; Audio: 15.748KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 61Fps; Audio: 15.782KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.574MHz; 60Fps; Audio: 15.795KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.610MHz; 60Fps; Audio: 15.818KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 99% 28.475MHz; 60Fps; Audio: 15.835KHz; Keys: SNES 1P FrameMerge 

(If you do the same thing again, then it won't re-flash Bugz, it will just launch right into it)

Code: Select all

user@debian:/tmp/test-procedure/cuzebox$ ./cuzebox Bootloader.hex 
CUzeBox 20170929
UzeRom parser: Error: Bootloader.hex is not a UzeRom file.
Hex parser: Warning: Invalid record type on line 504 in Bootloader.hex.
Hex parser: Succesfully loaded program from Bootloader.hex
Starting emulator
Load game controller mappings:
    /tmp/test-procedure/cuzebox/gamecontrollerdb.txt
    could not open
Found: eeprom.bin (2048 bytes)
Found: coderom.bin (65536 bytes)
Found: bugz.uze (58094 bytes)
Found: Bootloader.hex (11358 bytes)
Found: cuzebox (64072 bytes)
Found: types.h (2817 bytes)
Found: textgui.h (2571 bytes)
Found: textgui.c (11861 bytes)
Found: romdump.h (1498 bytes)
Found: romdump.c (2197 bytes)
Found: main.c (11365 bytes)
Found: guicore.h (3538 bytes)
Found: guicore.c (14930 bytes)
Found: ginput.h (1807 bytes)
Found: ginput.c (12575 bytes)
Found: gamefile.h (1295 bytes)
Found: frame.h (1693 bytes)
Found: frame.c (16420 bytes)
Found: filesys.h (4550 bytes)
Found: filesys.c (10475 bytes)
Found: filesmin.c (4972 bytes)
Found: eepdump.h (1439 bytes)
Found: eepdump.c (1927 bytes)
Found: cuzebox_minimal.html (2506 bytes)
Found: cu_vfat.h (3349 bytes)
Found: cu_vfat.c (15142 bytes)
Found: cu_ufile.h (1973 bytes)
Found: cu_ufile.c (3956 bytes)
Found: cu_types.h (7674 bytes)
Found: cu_spisd.h (3310 bytes)
Found: cu_spisd.c (24250 bytes)
Found: cu_spir.h (2530 bytes)
Found: cu_spir.c (5869 bytes)
Found: cu_spi.h (1806 bytes)
Found: cu_spi.c (2214 bytes)
Found: cu_hfile.h (1345 bytes)
Found: cu_hfile.c (5190 bytes)
Found: cu_ctr.h (2857 bytes)
Found: cu_ctr.c (3344 bytes)
Found: cu_avrfg.h (1689 bytes)
Found: cu_avrfg.c (5881 bytes)
Found: cu_avrc.h (5168 bytes)
Found: cu_avrc.c (12627 bytes)
Found: cu_avr_n.h (19755 bytes)
Found: cu_avr_e.h (24549 bytes)
Found: cu_avr.h (4914 bytes)
Found: cu_avr.c (35814 bytes)
Found: conout.h (1413 bytes)
Found: conout.c (2046 bytes)
Found: chars.h (1369 bytes)
Found: chars.c (5616 bytes)
Found: avr_inst_table.txt (3251 bytes)
Found: avconv.h (2624 bytes)
Found: avconv.c (5767 bytes)
Found: audio.h (1780 bytes)
Found: audio.c (7608 bytes)
Found: README.rst (7299 bytes)
Found: Makefile (4526 bytes)
Found: Make_defines.mk (3459 bytes)
Found: Make_config.mk (4906 bytes)
Found: LICENSE (35141 bytes)
Found: .gitignore (589 bytes)
CUzeBox: 100% 28.636MHz; 60Fps; Audio: 15.734KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 98% 28.114MHz; 61Fps; Audio: 15.748KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 61Fps; Audio: 15.782KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 60Fps; Audio: 15.792KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 60Fps; Audio: 15.818KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.610MHz; 60Fps; Audio: 15.819KHz; Keys: SNES 1P FrameMerge 

Now I want to try Lee's SPIRamMusicDemo.hex, which you can download here: download/file.php?id=2840
I already had it in a directory, so I just copied it into the current directory, and tried to run the .hex file:

Code: Select all

user@debian:/tmp/test-procedure/cuzebox$ cp /tmp/cuzebox/SPIRamMusicDemo.hex .
user@debian:/tmp/test-procedure/cuzebox$ cp /tmp/cuzebox/SD_MUSIC.DAT .
user@debian:/tmp/test-procedure/cuzebox$ ./cuzebox SPIRamMusicDemo.hex 
CUzeBox 20170929
UzeRom parser: Error: SPIRamMusicDemo.hex is not a UzeRom file.
Hex parser: Succesfully loaded program from SPIRamMusicDemo.hex
Starting emulator
Load game controller mappings:
    /tmp/test-procedure/cuzebox/gamecontrollerdb.txt
    could not open
Found: SD_MUSIC.DAT (84442 bytes)
Found: SPIRamMusicDemo.hex (48614 bytes)
Found: eeprom.bin (2048 bytes)
Found: coderom.bin (65536 bytes)
Found: bugz.uze (58094 bytes)
Found: Bootloader.hex (11358 bytes)
Found: cuzebox (64072 bytes)
Found: types.h (2817 bytes)
Found: textgui.h (2571 bytes)
Found: textgui.c (11861 bytes)
Found: romdump.h (1498 bytes)
Found: romdump.c (2197 bytes)
Found: main.c (11365 bytes)
Found: guicore.h (3538 bytes)
Found: guicore.c (14930 bytes)
Found: ginput.h (1807 bytes)
Found: ginput.c (12575 bytes)
Found: gamefile.h (1295 bytes)
Found: frame.h (1693 bytes)
Found: frame.c (16420 bytes)
Found: filesys.h (4550 bytes)
Found: filesys.c (10475 bytes)
Found: filesmin.c (4972 bytes)
Found: eepdump.h (1439 bytes)
Found: eepdump.c (1927 bytes)
Found: cuzebox_minimal.html (2506 bytes)
Found: cu_vfat.h (3349 bytes)
Found: cu_vfat.c (15142 bytes)
Found: cu_ufile.h (1973 bytes)
Found: cu_ufile.c (3956 bytes)
Found: cu_types.h (7674 bytes)
Found: cu_spisd.h (3310 bytes)
Found: cu_spisd.c (24250 bytes)
Found: cu_spir.h (2530 bytes)
Found: cu_spir.c (5869 bytes)
Found: cu_spi.h (1806 bytes)
Found: cu_spi.c (2214 bytes)
Found: cu_hfile.h (1345 bytes)
Found: cu_hfile.c (5190 bytes)
Found: cu_ctr.h (2857 bytes)
Found: cu_ctr.c (3344 bytes)
Found: cu_avrfg.h (1689 bytes)
Found: cu_avrfg.c (5881 bytes)
Found: cu_avrc.h (5168 bytes)
Found: cu_avrc.c (12627 bytes)
Found: cu_avr_n.h (19755 bytes)
Found: cu_avr_e.h (24549 bytes)
Found: cu_avr.h (4914 bytes)
Found: cu_avr.c (35814 bytes)
Found: conout.h (1413 bytes)
Found: conout.c (2046 bytes)
Found: chars.h (1369 bytes)
Found: chars.c (5616 bytes)
Found: avr_inst_table.txt (3251 bytes)
Found: avconv.h (2624 bytes)
Found: avconv.c (5767 bytes)
Found: audio.h (1780 bytes)
Found: audio.c (7608 bytes)
Found: README.rst (7299 bytes)
Found: Makefile (4526 bytes)
Found: Make_defines.mk (3459 bytes)
Found: Make_config.mk (4906 bytes)
Found: LICENSE (35141 bytes)
Found: .gitignore (589 bytes)
CUzeBox: 100% 28.636MHz; 60Fps; Audio: 15.734KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 98% 28.114MHz; 62Fps; Audio: 15.750KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 61Fps; Audio: 15.784KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 61Fps; Audio: 15.806KHz; Keys: SNES 1P FrameMerge 
CUzeBox: 100% 28.501MHz; 60Fps; Audio: 15.816KHz; Keys: SNES 1P FrameMerge 

At this point, instead of playing Lee's SPIRamMusicDemo.hex like I would expect because I passed that as a parameter, it boots to the bootloader, but if I select Bugz, it plays his music demo! I can't get it to reproduce what was happening before which was I somehow got it into a state where I couldn't select Bugz from the bootloader menu because it would just immediately go back to the bootloader menu, but you should be able to reproduce what I pasted above.

Interestingly enough (and maybe unrelated) when I pass his SPIRamMusicDemo.hex file as a parameter and the bootloader is set to boot to MENU, select Bugz, and it plays his demo, his demo sounds correct. However if I do the same, passing his demo .hex file as a parameter and the bootloader is set to boot to GAME, it'll boot to his demo, but the sounds are all wrong in his demo. I'm still working with Lee to try to figure out why sometimes his sounds are wrong (it wasn't reproducable before) but now I have a reliable way to make his demo either work or not. (If I delete the coderom.bin file and try to just play his demo from the .hex file, it sounds wrong, but if I do the above and let it go through the bootloader set to boot to GAME, it sounds correct. I'm wondering if there is his demo uses values w/o initializing them?)

Edit: Saw your post, attached stuff.

[Jubatian]

Ugh... Really you want to drive the poor thing totally nuts...

Now pick Bugz from the menu, and press START, notice it flashes the ROM, then press ESC to exit cuzebox.

This is like ripping the power cord out while the real hardware is flashing. Seriously, what would you expect to happen? (It writes the game CRC used for identification after the flashing process, so it will think that still the previous game is flashed, while the flash contents are actually wrecked).

At this point, instead of playing Lee's SPIRamMusicDemo.hex like I would expect because I passed that as a parameter, it boots to the bootloader.

As I described above, CUzeBox is currently not capable to determine whether a hex file is a game, bootloader or both. It will write it over the reloaded ROM contents, and if in the result there is a bootloader, it autofuses like a normal Uzebox, to start with bootloader, so that bootloader will start.

(...) but if I select Bugz, it plays his music demo!

Since the ROM contains it, but the bootloader last programmed Bugz and remembered that game's CRC in the EEPROM, it will still think that it has Bugz. This is a serious flaw of the bootloader, making you pull hair out when your SD card is crappy and you occasionally have an incorrect flashing (you can't just reprogram the game since the bootloader has its CRC stuck in its mind, no matter that the actual flash contents don't match).

(If I delete the coderom.bin file and try to just play his demo from the .hex file, it sounds wrong, but if I do the above and let it go through the bootloader set to boot to GAME, it sounds correct. I'm wondering if there is his demo uses values w/o initializing them?)

Maybe he is playing the bootloader area as a sample?

So far I think these mostly are things which would also happen on real HW, it is just that it is a lot easier to "reflash" CUzeBox than the real HW, so you aren't experiencing it. But if you tried to intentionally do similar things on the real HW, you would see similar results (or smoke ).

[Artcfox]

Ugh... Really you want to drive the poor thing totally nuts...

Now pick Bugz from the menu, and press START, notice it flashes the ROM, then press ESC to exit cuzebox.

This is like ripping the power cord out while the real hardware is flashing. Seriously, what would you expect to happen? (It writes the game CRC used for identification after the flashing process, so it will think that still the previous game is flashed, while the flash contents are actually wrecked).

At this point, instead of playing Lee's SPIRamMusicDemo.hex like I would expect because I passed that as a parameter, it boots to the bootloader.

As I described above, CUzeBox is currently not capable to determine whether a hex file is a game, bootloader or both. It will write it over the reloaded ROM contents, and if in the result there is a bootloader, it autofuses like a normal Uzebox, to start with bootloader, so that bootloader will start.

(...) but if I select Bugz, it plays his music demo!

Since the ROM contains it, but the bootloader last programmed Bugz and remembered that game's CRC in the EEPROM, it will still think that it has Bugz. This is a serious flaw of the bootloader, making you pull hair out when your SD card is crappy and you occasionally have an incorrect flashing (you can't just reprogram the game since the bootloader has its CRC stuck in its mind, no matter that the actual flash contents don't match).

(If I delete the coderom.bin file and try to just play his demo from the .hex file, it sounds wrong, but if I do the above and let it go through the bootloader set to boot to GAME, it sounds correct. I'm wondering if there is his demo uses values w/o initializing them?)

Maybe he is playing the bootloader area as a sample?

So far I think these mostly are things which would also happen on real HW, it is just that it is a lot easier to "reflash" CUzeBox than the real HW, so you aren't experiencing it. But if you tried to intentionally do similar things on the real HW, you would see similar results (or smoke ).

No, I'm not interrupting the flashing process, I was telling you to actually choose 1P from the Bugz menu to start the game, because that will initialize the EEPROM properly.

[Jubatian]

No, I'm not interrupting the flashing process, I was telling you to actually choose 1P from the Bugz menu to start the game, because that will initialize the EEPROM properly.

Uh, where? You did not tell this in the above post, and in the console dump, it can not be observed whether you waited the flashing to complete or actually started the game.

I could reproduce this, but as far as I see, this again is a flaw in the bootloader. It doesn't format the EEPROM (or it seems like so), so when you first start a game with it, once the game starts, the kernel will format the EEPROM. This will destroy the CRC the bootloader wrote into it (without formatting), so next time starting the bootloader it will think there is no game programmed. After that it will work since the EEPROM remains formatted.

[Artcfox]

No, I'm not interrupting the flashing process, I was telling you to actually choose 1P from the Bugz menu to start the game, because that will initialize the EEPROM properly.

Uh, where? You did not tell this in the above post, and in the console dump, it can not be observed whether you waited the flashing to complete or actually started the game.

Sorry I wasn't more clear.

I could reproduce this, but as far as I see, this again is a flaw in the bootloader. It doesn't format the EEPROM (or it seems like so), so when you first start a game with it, once the game starts, the kernel will format the EEPROM. This will destroy the CRC the bootloader wrote into it (without formatting), so next time starting the bootloader it will think there is no game programmed. After that it will work since the EEPROM remains formatted.

I was just thinking that if someone passed a .uze or .hex (that is not a bootloader) as a parameter that it should always override whatever is in the coderom, since that is a unique case only to the emulator (being able to force it to run exactly this thing I pass you on the command line). The real hardware only has what's been flashed to it (the bootloader and/or a .hex file). You can tell right now whether something passed is a bootloader or not correct? (Based on where the code is loaded, IIRC) so I think that might be enough for the intended behavior. If a user wants to test the bootloader, they'll always pass in a bootloader hex file on the command line, otherwise, just force it to load a game directly as if there is no bootloader?

[Jubatian]

I was just thinking that if someone passed a .uze or .hex (that is not a bootloader) as a parameter that it should always override whatever is in the coderom, since that is a unique case only to the emulator (being able to force it to run exactly this thing I pass you on the command line). The real hardware only has what's been flashed to it (the bootloader and/or a .hex file). You can tell right now whether something passed is a bootloader or not correct? (Based on where the code is loaded, IIRC) so I think that might be enough for the intended behavior. If a user wants to test the bootloader, they'll always pass in a bootloader hex file on the command line, otherwise, just force it to load a game directly as if there is no bootloader?

It overrides the area defined in the .hex or .uze file. If it overrode more, then there wouldn't be any point of persisting the ROM at all expect for supporting the current quirky bootloader, while this way it would be capable to support programs which store things in areas of the ROM not covered by the main binary (honestly I would happily ditch persisting ROM altogether, it is a rather useless feature beyond trying to work with the current bootloader).

The emulator is not capable to tell whether a file is a bootloader or not. It can assume that a .uze file is not a bootloader, but it can not make such assumptions on .hex files (the information which regions were written is lost across the interface).

For normal users these all shouldn't be a problem as they wouldn't load the bootloader (or if they have such a package, then would always use the bootloader).

I wouldn't want to put any effort in trying to mess with this any more for now. Better invest that effort in creating a bootloader which works better and forget about these problems.