Page 1 of 27

CUzeBox - The new official Uzebox emulator

Posted: Thu Sep 08, 2016 1:44 pm
by Jubatian
So I am making a new Uzebox emulator. As the screenshot demonstrates, it already runs, and you may check it out and compile for yourself from its Git repository, or download the attached binaries (I will try to keep them up to date) at the bottom of the post.
CUzeBox running Toorum's Quest, a game utilizing the SD write feature.
toorums_ingame_2.png (20.03 KiB) Viewed 23543 times
For now it has the following notable features:
  • Visual debugging: on the left and right sides, the entire sync signal shows which it compares to a reference extracted from Megatris. On the bottom IO and RAM read and write accesses are shown, which most strikingly shows the RAM tile budget, but knowing exact locations it could be useful for a variety of experiments.
  • Compiles with Emscripten, and it is faster than Uzem, so it could be more useful for providing browser games.
  • Much better sync management which works correctly even in Emscripten. It syncs to video if it runs between about 58 - 62 Hz, and automatically chooses a suitable audio output rate to follow it. If the video has higher refresh rate, it correctly limits.
  • It doesn't crash on broken games or otherwise failing video signal.
  • Supports SD writes (even creating new files with some limitations).
  • Supports SPI RAM.
  • Supports the SPM instruction and some related features necessary for bootloaders.
SPI RAM demo program running
spiram_demo_2.png (34.9 KiB) Viewed 23544 times
(The SPI RAM demo above can be found in this post)

A bit of explanation on the visual debugging aids.

The left and right blue sidebars are the sync pulse indicators. On the left are the rising edges, on the right are the falling edges. It marks with red indicators if they are off by one or two cycles, to the left if the pulse is too short, to the right if too long, and a yellow indicator if the pulse is off by more than 3 cycles. On the bottom of these bars the VSync is also observable, excepting the pulse timing of the current kernel. The faint separator bar would be alight if the frame's row count isn't 262 (if it is shorter, this bar expands upwards as nonexistent lines are indicated with yellow bars). So this feature is useful for tweaking the kernel itself or working on the inline mixer.

The memory blocks mark reads with green pixels, writes with red pixels, and the two might mix into yellow. Each box represents 256 bytes, the leftmost separated block is the IO range. If a cell is not accessed, the respective marks fade out. Addresses within a block grow from top to bottom, then left to right. Implicit accesses (CPU registers, SREG, the stack pointer, and any hardware activity) are not marked, only explicit accesses made by load, store, stack reads and writes, input and output instructions.

Notably missing elements
  • UART. For now implementing this is unlikely, I have a crappy net, and if Lee's note that he had to split the ESP8266's emulation in a different thread (for his Uzem hack) is really a hard constraint there, I neither think I have the computing power to run anything of it, so there is little motivation.
  • Controllers, particularly mouse or PS/2 keyboard.
  • Various capture and replay features present in Uzem (except video capture which is implemented). I plan to add these later, particularly a capability to save and replay controller input in a deterministic manner, also including emulator state saves and reloads.
  • GDB support. Maybe I will add it, but I never ever used a debugger in my life, and experience told me it doesn't do much good to those who do (There were several occasions when I had to find problems in other people's broken code for them which problems weren't possible to discover with a debugger). So there is no big motivation, but it depends on how complex is the interface and whether there is any actual need for it.
The AVR core

This part incorporates every method invented for the Uzem emulator to boost its performance, and several tweaks beyond. I also wiped out all the ugly kludges still maintaining fully accurate timing (Mode 13 works proper, I also verified a few related things with the real hardware).

The source code

I did it in plain C, trying to maintain a clean code base. I will keep it this way.

What runs

It seems like anything which doesn't require any of the unimplemented features (mouse, keyboard, or the ESP8266). I tested it with a load of games I had here.

Some usage notes

It accepts one parameter: the game file to load. It can be either a UzeROM or a hex file. With no parameters it attempts to start gamefile.uze. The emulator's window is resizable, with F11 you may switch it to full screen. There is a short documentation on the controls and various features on the GitHub page.

For now I prefer to work on this emulator on my own as there are many areas where I have very clean ideas on how things should be implemented, how the architecture should end up looking like. I publish it as I feel it could be useful to some of you. Particularly to those who might be tweaking video modes.

Binaries (Linux 64 bit binary) (Windows 32 bit binary with SDL2.dll)

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Thu Sep 08, 2016 9:03 pm
by CunningFellow
This is awesome.

The video sync line indicators sound just perfect.

Sadly I can't compile it at the moment so I will have to wait to see it.

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Fri Sep 09, 2016 5:23 am
by Jubatian
Do you mean you tried and ran in a problem, or just that you aren't at it yet? (If there's a problem, I would look into fixing it as soon as possible!)

A small side note I omitted. When setting the target in, don't forget to adjust the output's name accordingly, such as to "cuzebox.html" for Emsripten or "cuzebox.exe" for Windows (if you can even get that to work, I didn't test that target yet).

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Fri Sep 09, 2016 5:33 am
by CunningFellow
No bugs/errors or anything - I mean I don't have a computer I can set up an environment to compile at the moment.

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Fri Sep 09, 2016 8:04 pm
by Jubatian
I hammered the thing through a Windows cross compile, so now that target should work (hopefully also in Windows possibly with some tweaks).

I noticed a problem in Uzem's compiler flags which I originally copied assuming they were set up for extensive link time optimizations. The "fwhole-program" flag rather identifies that the compilation unit is the whole program as-is, which is definitely not the case, and on the GNU documentation it is especially not recommended to use it with "flto". In my case it broke the cross-compile as the linking process as a result couldn't find SDL_main (which as I see is a hack, redefining "main" to "SDL_main" during compiling, so then the "fwhole-program" flag essentially disposed it).

Anyway, so it now works at least if you try to cross to Windows from Linux (I have no Windows to try a native compile, but if necessary, I could send a binary to anyone interested).

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Sat Sep 10, 2016 12:54 pm
by Jubatian
I was annoyed by the size of the binary produced by Emscripten, so did a bit of research.

It turns out that it all boils down to this simple experiment:

Code: Select all

#include <SDL2/SDL.h>
int main(int argc, char** argv){
    return 0;
This compiled with all the optimizations hurled at it (along with "-s USE_SDL=2" of course), the resulting Javascript is above 1.3 Megabytes (!), with nothing actually done apart from initializing SDL. Then, a very similar experiment:

Code: Select all

#include <SDL/SDL.h>
int main(int argc, char** argv){
    return 0;
Note the subtle difference (of course along with "-s USE_SDL=1"). The resulting Javascript is slightly less than 120 Kilobytes.

That's the difference, of course growing a lot bigger as the emulator was actually doing things with SDL. The reason is that SDL2 comes in native format, compiled by Emscripten into Javascript, while SDL1 is built-in. So while it works, it produces a big ugly mess for web use (considering that the emulator itself is a magnitude smaller, compiling into an approximately 300K Javascript with all the SDL interfacing removed, so as something only dropping status reports of the thing actually running). For Emscripten I guess I will downgrade to SDL1, which should also help performance (less Javascript to compile by the browser) along with bandwidth.


I am going to cry... I am analysing the performance of the optimized emulator running in Emscripten, and I am getting that only 50% of the CPU is allocated for everything within my code, that is the AVR emulation (everything else takes marginal time, even software-rendering the picture onto a 32 bit buffer). From the rest 15% flies away for a single routine: SDL_UnlockSurface(), and 22% to stuff only labelled as "Graphics".

What the heck are those? The emulator, on my PC unable to reach full speed, drops every second frame, so actually does around 25 per second, calling that SDL_UnlockSurface() so often (while emulating 50 frames of AVR instruction fluctuating around 80% speed). I traced it all the way into Emscripten's source, discovering that it actually simply performs an array to canvas transfer the most efficient manner possible.

I have a kind of deja vu... From more than a decade ago when I was hacking around with MMX on a Pentium 1 (233MHz!), devising graphics effects. It could do some awesome stuff... If only it was possible to actually get them on the screen! But it wasn't. The bandwidth was like if I tried to watch Youtube through a modem, I mean one with those ugly acoustic couplers. It isn't very rewarding to see the CPU burning down shovelling pixels towards the screen in a vain attempt.

Anyway, at least there is one possible solution to get at least some okay display: to render smaller, such as simply going down to about 310 x 224 for the Uzebox's display. It can still be scaled up, won't look that nice, but at least it is something.

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Wed Sep 14, 2016 5:51 am
by D3thAdd3r
Seems reasonable to me. Better it runs fulls peed on more PCs than looking better but being unplayabe.

Aw man, I actually want an acoustic coupler for the collection even :lol:

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Wed Sep 14, 2016 5:18 pm
by Jubatian
SD reading is completed. It can run the SD based games I had laying around, notably Tempest, Toorum's Quest or Alter Ego.

I found Alter Ego quite ignoring all timing recommendations for init, so I had to remove them from my SD emulation code (not actually removed, just turned them off by defines). It also seems to have quite bad video timing which I checked with Uzem as well, it has bad timing there as well. Probably it should receive a few fixes...

And well, Toorum's Quest does (or should be doing) SD writes! I will use that to test the code I build for SD write support then.

EDIT: Is Toorum's Quest write support present? I can't see any write command on my SPI transmission log, neither anything suggesting writes took place on the real hardware either.

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Wed Sep 14, 2016 8:30 pm
by Artcfox
Very nice work!

I tested it out under Linux, and it works great. I did modify the source a bit to add support for the L/R shoulder buttons (since Bugz uses those buttons), and I remapped the inputs to match Uzem (and my muscle memory).

I'm assuming that the process for compiling this with Emscripten is very similar to that for compiling Uzem. A while back I made a wiki page describing how to install and configure Emscripten under Linux, so I'll try following that except with CUzeBox when I get a chance.

Re: CUzeBox - a new Uzebox emulator in progress

Posted: Wed Sep 14, 2016 9:58 pm
by D3thAdd3r
On Alter Ego, what exactly is off on the SD timing, too rapid calls to init? To initialize the cards, I did a little trick that fixed problems some cards were experiencing, basically you had to reset the console a couple times for it to work, take out put back in, or things of that nature. If I recall, if it failed to open the file, it will rapidly remount/init and try again a few times. Without that, some real cards didn't seem to want to work at all(this problem seems inherent to the few SD programs for Uzebox). If there just needs to be a wait or something after program start and before opening the file, I can switch it to that, but the method as far as anyone's card I heard about works 100% on real hardware. BTW, some development versions of AE did have an old or possible hacked kernel that Alec pointed out, I believe I did post that somewhere which is just stock mode 3, I will look and try to remove the bad versions.

Toorum's Quest is the same thing potentially because I am terribly sloppy with spewing out hacked development versions, and also forgetting where I was when I let a project collect dust for a while. I am pretty sure at some point TQ did write to a real SD card, and I just checked now that Uzem gives the "SD writing not implemented" 512 times. I attached the latest version I have, though keep in mind you must get a high score to trigger the 512 byte write. If it will help, I can probably hack that quick to make the game write a sector, WaitVsync(60), write sector, etc for testing.