CUzeBox - The new official Uzebox emulator

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

If anyone had any difficulty with the SD card, I managed to leave a simple SPI RAM bug in the last commit which prevented using it. This is now fixed so things should work proper.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Artcfox »

Jubatian wrote:If anyone had any difficulty with the SD card, I managed to leave a simple SPI RAM bug in the last commit which prevented using it. This is now fixed so things should work proper.
Even with the latest changes, I can't get T2K to run. I'm getting the "LEVEL FILE NOT FOUND ON SD CARD" error, perhaps the fix hasn't made it up to Github yet?
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

Refresh. I am testing with that game right now, the bug is fixed.

I am doing some quite ridiculous thing to squeeze a few cycles more out of this thing. I implemented an instruction set deflagger, a stage which proves whether certain flags of arithmetic instructions are never used, and if so, replaces them to variants which doesn't calculate those. The results are a bit dubious, but Emscripten seems to receive a very certain speed bump.

By theory this should work since at any given point in the instruction stream you can look forward to see what instructions come ahead (which might be a tree if there are conditional branches) with a very few exceptions (where the program counter is set to an arbitrary value: IJMP, ICALL, RET and RETI). If the pass works correctly (which might or might not be the truth currently depending on how tired I was while hacking that code), the resulting behaviour should be identical to that without this pass with a single exception I could imagine. Interrupts wouldn't necessarily see the same state like with the original code upon their entry. But normally they don't rely on that (except for saving and restoring the SREG, which hides this difference). Assuming the pass being bug-free, you could so still discover the presence of it by a carefully timed interrupt which would examine the SREG.

EDIT: I discovered something being buggy about this, in Castlevania passing the first door this new version jumps into the last room. As I test stuff side by side, in native compiles, the new version for me is substantially slower, while in Emscripten it is substantially faster. It is annoying. My very best guess is that the code inflated with the new instructions just doesn't fit the cache too well, and it might trigger more branch mispredictions by making certain instruction streams less possible to guess by the CPU. In overall unless I get some positive feedback on this, I will likely revert. At least it was interesting to see what this does (I verified that it indeed does the pass by disassembling the video mode codes of a few games I tested with, so despite that it replaces tons of very frequently executed instructions to variants requiring less computation, the native result is slower on my PC).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Artcfox »

The latest commit is: f292e1f9f5179ee78026a30fc9a73d1974c2ba20

Code: Select all

$ ls t2k.uze utempest.lvl 
t2k.uze  utempest.lvl
$ ./cuzebox t2k.uze
UzeRom parser: Succesfully loaded program from t2k.uze:
	Name .......: Tornado2000
	Author .....: CunningFellow
	Year .......: 2015
	Description : 
Starting emulator
Found: cu_ctr.c (3344 bytes)
Found: utempest.lvl (442601472 bytes)
Found: guicore.h (3011 bytes)
Found: README.rst (1795 bytes)
Found: guicore.c (10822 bytes)
Found: cu_avrc.h (6178 bytes)
Found: Makefile (3080 bytes)
Found: frame.h (1576 bytes)
Found: audio.h (1420 bytes)
Found: avr_inst_table.txt (3251 bytes)
Found: cu_spir.h (2530 bytes)
Found: audio.c (6047 bytes)
Found: bugz.uze (58094 bytes)
Found: cu_avrdf.c (17204 bytes)
Found: cu_spi.c (2054 bytes)
Found: filesys.h (4532 bytes)
Found: cuzebox (48600 bytes)
Found: cu_hfile.c (5204 bytes)
Found: cu_vfat.c (14751 bytes)
Found: cu_ufile.h (1944 bytes)
Found: cu_hfile.h (1316 bytes)
Found: eepdump.c (1926 bytes)
Found: t2k.uze (61494 bytes)
Found: cu_ufile.c (3913 bytes)
Found: cu_vfat.h (3013 bytes)
Found: eepdump.h (1439 bytes)
Found: LICENSE (35141 bytes)
Found: Make_defines.mk (2539 bytes)
Found: filesys.c (10072 bytes)
Found: cu_spisd.h (3066 bytes)
Found: cu_types.h (7402 bytes)
Found: cu_avr.h (3529 bytes)
Found: cu_avrdf.h (1384 bytes)
Found: cu_avrc.c (12627 bytes)
Found: Make_config.mk (2029 bytes)
Found: cu_spir.c (5871 bytes)
Found: cu_spi.h (1806 bytes)
Found: avconv.c (4363 bytes)
Found: avconv.h (2624 bytes)
Found: types.h (2139 bytes)
Found: cu_ctr.h (2857 bytes)
Found: .gitignore (378 bytes)
Found: cu_spisd.c (21266 bytes)
Found: main.c (9817 bytes)
Found: eeprom.bin (2048 bytes)
Found: frame.c (10783 bytes)
Found: cu_avr.c (52631 bytes)
CUzeBox CPU: 100% (28.656 MHz); FPS: 61
I'm still getting LEVEL FILE NOT FOUND ON SD CARD
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Artcfox »

For what it's worth, I compiled and tested Tornado 2000 with each and every commit that's in the git log for cuzebox, and got that same error message for every single one of them, even on the one that specifically states that you got it running on Tempest.

Running Uzem from within that same directory on the same t2k.uze and utempest.lvl files works fine.

Edit: Alter Ego runs just fine with the latest commit.
Edit 2: I tried it with just the t2k.uze and utempest.lvl file in the directory, rather than with other files in the same directory, and still no luck.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

I think you have a different version of Tempest then!

You should attach the uze file so I can debug what happens. I guess it won't work at me either with the uze file you have.

The adventure continues. I ditched the deflagger experiment as I figured out something better which actually works. Quite simple: I pre-calculated the flags. The result is a speed bump of 0% - 10% for everything (Tempest experiences no change at all while everything else I tried runs at 5% - 10% faster). This also applies to Emscripten, so you would have even better web performance with this (after a bit of cleanup, the results got even more substantial, including Tempest gaining more than 10% on my PC, while the Emscripten build now can consistently run at full speed in full resolution with debug aids on tested with Castlevania)
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Artcfox »

Jubatian wrote:I think you have a different version of Tempest then!

You should attach the uze file so I can debug what happens. I guess it won't work at me either with the uze file you have.
I'm using the uze file linked on the Tornado 2000 wiki page, confirmed to be the newest version by CunningFellow:

http://uzebox.org/wiki/index.php?title=Tornado_2000
Jubatian wrote:The adventure continues. I ditched the deflagger experiment as I figured out something better which actually works. Quite simple: I pre-calculated the flags. The result is a speed bump of 0% - 10% for everything (Tempest experiences no change at all while everything else I tried runs at 5% - 10% faster). This also applies to Emscripten, so you would have even better web performance with this (after a bit of cleanup, the results got even more substantial, including Tempest gaining more than 10% on my PC, while the Emscripten build now can consistently run at full speed in full resolution with debug aids on tested with Castlevania)
Sweet!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Artcfox »

You had mentioned that Emscripten is very slow to update a frame. Could it be that you're calling LockSurface and LockTexture, which sends every pixel back from the graphics card to the CPU? If you look at the SDL2 calls I made in Uzem, I found it faster to use a static texture, rather than a streaming one, because the texture memory is write only, and I never need to read the pixels back again. Doing it that way, I never had to lock the surface, or the texture.

By the way, does the latest version of T2K that I linked in my previous post work for you?
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

OK, behaviour confirmed: this Tempest is unable to init the SD card on the current CUzeBox. Debugging is on the way...

Yes, I use SDL_LockSurface (SDL1, no textures), which as SDL1 is normally implemented is truly slower than a dead slug. However look at Line 196 of guicore.c, I turn off accurate SDL1 behaviour to fit my needs, eliminating the copies you mentioned. Only the single backbuffer to canvas copy takes place within SDL_UnlockSurface which I traced and verified in Emscripten's code. Nothing else of any significance on the term of consumed CPU resources happen.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: CUzeBox - a new Uzebox emulator in progress

Post by Jubatian »

It was not my bug, but I fixed it anyway. So that version of Tempest should also work now.

The bug is that the SD card protocol permits stuff bytes after commands which my emulator can emulate, and by default was set to provide one stuff byte (which the Tempest version I had worked with). The released Tempest has a bug in its mmc.s file (in the kernel) that it doesn't account for stuff bytes in CMD1, and so can never detect a successful card initialization. So with the stuff bytes set to zero it works.

I discovered another bug in it which might prevent you running it: The start sector is an "int" (16 bits). This means that the level file has to start within the first ~31 megabytes of the card for it to be able to use it. Notably if you leave the zipped up level file alongside it, it might happen that the Virtual FAT picks that up first, so the level file ends up starting on a sector above this barrier making the game fail.

A small note for developers. The cu_spisd.c file of cuzebox has several configuration options on its top, now along with a lot of comments relating to various games which are one or another way problematic. If you are developing SD code, you could tune them to emulate a very strict SD card to test your code with.

By the way any particular notable observation about the audio? (How stable it is?) I got no feedback since the complaints, and then I made some fundamental adjustments in it and the frame rate manager. For Emscripten, you could tweak it (such as reducing buffer size), but test it with something producing music so you can hear whether the audio is continuous. I set the buffer size since I saw that lower sizes cause more frequent buffer underruns due to the various bursts of load (such as the JavaScript garbage collector) taking away time from the emulator, and I considered lag less bad than frequent cracks and skips (and of course there is a point when it becomes irrelevant as the PD controller guessing the necessary playback frequency also screws up).
Post Reply