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.
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.
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
http://files.jubatian.com/cuzebox_linux_amd64.tar.bz2 (Linux 64 bit binary)
http://files.jubatian.com/cuzebox_windows_x86.zip (Windows 32 bit binary with SDL2.dll)