Kevin Vance - Last night, while working on dsmzx, I got the Caverns title screen…

Tags

:

dsmzx, megazeux, nintendo ds

Last night, while working on dsmzx, I got the Caverns title screen to show up by accident. I tweaked the startup code to switch to the config directory at startup to read a configuration file, and since CAVERNS.MZX was in there too, it started!

Yesterday was a tough day for dsmzx hacking. I realized that my copy of mzx2.81g was really old, and it took hours to port my changes to version 2.82... especially changing from one custom make system to another similar BUT DIFFERENT custom make system. I never thought I'd *want* to see autotools so bad. Now I'm up to date, and I'm using git-svn to sync things up. git is a fantastic source code management tool. Being able to merge branches fast and effortlessly... wow. Goodbye SVN for future projects.

The next problem was that MZX would always crash a few seconds into the file selection dialog. Turns out that I only have 16K of stack space to work with, and MZX does a fair amount of stack allocation. Allocating the world structure in main() killed the first 10K of my stack before the program starts! I started using libnds's default exception handler, providing me with a red screen of death when things like this happen in the future.

But hey, I got it running and at that point I had been doing this all day. I tried to continue my BioShock game, but my 7900 was running too hot. ASUS really needs to get back to me about that...

The next day came dsmzx user input. Fortunately, my up-to-date copy of MZX actually has the input code for PSP and GP2X, so it should have been easy. But it turns out that ndsSDL is half-baked. Or it's a quarter baked. I had to remove some extra libnds calls (ndsSDL assumes that it gets to monopolize libnds) and modify the magnitude of the fake "joystick axes" it returns. Until this point, I was not initializing the SDL video subsystem, since I had to roll my own. It turns out that the event subsystem requires the video to be initialized, or the event queue can never accept input. Lame.

But now I can play the first few boards of caverns! It runs at an acceptable speed, with palette changes causing slowness. I think this is MZX doing something inefficient, since running the palette updater on every frame had no effect on my test app. There is also a noticeable amount of tearing. I can't waste my last two 128K banks of VRAM on double buffering, since the only other sprite VRAM bank for the subscreen is only 16K—not enough for a full charset on the subscreen. Maybe it would be acceptable to work on an offscreen buffer and DMA it into VRAM on the vertical blank.

The next game I tried to run (xenogenesis) triggered a stack overflow on the second board. I have more work to do. And using the editor kills a lot of stack. A great way to check for functions that do too much stack allocation is objdump -S and search for sp, #[0-9]\{4\}. It returns lines like:

 2073470:       e24ddc47        sub     sp, sp, #18176  ; 0x4700

That's almost 18K of stack allocation in one function!

I tried getting sound to work tonight, but as you may have guessed, ndsSDL's audio subsystem is a trainwreck. It triggers the hardware exception handler, but prevents it from writing precious debugging information to the screen. SDL is (annoyingly) deeply integrated into MegaZeux, so I'm not sure whether I should try to work around SDL at this point, or try to fix it.