SpritesMind.Net

"load ROMs quickly for development and debugging" -> both have an usb connection for that. ARM is just a detail.

And the second UMDK and Mega Everdrive x7.

Well yes, GOAC + output mixer + glue would be cheap to make, however the total market for any expansion is low. Even for official Sega ones.

Are the japanese disc docs in japanese?

http://nesdevcompo.nintendoage.com/contest17/
Inherent Smile was my entry for a NES compo, try it

That happens with XGM if you forget to init that specific sfx. No idea if they use it though.

https://shop.terraonion.com/en/products ... ridge.html

There's now a FPGA version of the sega cd. Bit pricy though.

Plus with zlib, and using gzopen/gzread you get transparent decompression. It works for both uncompressed and gzipped files.

Or maybe even an ODE that replaces the drive with a SD card? Which could also lead to MegaSG implementing it.

SLZ looks very similar to LZ4 and Stef's LZ4W. The zlib code I had posted needed 4kb, but it's possible to go as low as 765 bytes, based on the 6502 asm implementation.

As posted in the thread before I sent zlib code in, aplib does not compress better: http://gendev.spritesmind.net/forum/viewtopic.php?f=19&t=2275 It may decompress faster, but as long as the compressor is closed source, it is unusable. I do have an unreleased project using zlib, but there's no need ...

I disagree with much of the new direction. I will not pollute my computer with Java. Waiting for another frame in case of a slightly delayed frame will cause jitter for little gain. Zlib is an industry standard, and keeping it would cost nothing. Thus I will keep using an older version, and probably...

(just how many emulators do you have under development at once? )
A byuu mcd emu would certainly be welcome, and ease dev for that system.

I think many emulators don't bother implementing any limit (beyond a 8-bit var). IIRC I tested mednafen and/or dgen.

There's little point to the "Tower of power" when a Saturn is better for all practical purposes.