yamaha_dx97 VS mame

I've been writing a lot of 8-bit assembler for the 6303, which is in the same processor family as the CPU in the TRS-80, which the author is writing code for (for this project in case anyone is wondering: https://github.com/ajxs/yamaha_dx97). I ran into the exact same issue. I wrote a MAME driver for the target platform, so I could test my builds on my development machine. Obviously that sped things up a lot. The MAME debugger isn't really a tool for unit testing, and can't really be easily instrumented, but I was able to write a lot of scripts for the debugger which would set up the breakpoints and system memory for an individual 'test'. Not quite unit testing, but as close as I could get cheaply.

I'm super impressed that someone has emulated the CZ-101's sound generation LSI!

Lots of people use MAME as an emulator to help reverse-engineering vintage synthesisers. I only recently discovered this too. Since most 80s synths were built mostly out of 'off the shelf' components, it's not too difficult to build a MAME driver which is capable of running the synth's firmware. The actual sound generation is another story though.

I wrote a MAME driver for the Yamaha DX9 while working on this project: https://github.com/ajxs/yamaha_dx97

I wrote a little bit about the project here in case anyone is interested: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...

Very cool! I've been doing a lot of work reverse-engineering the firmware from Yamaha's 1980s synthesisers[0], all of which feature Hitachi 6303-series processors. The 6303 is Hitachi's second-source implementation of the Motorola 6803 architecture. I'd love to know how these devices were developed. I'm guessing a development platform like this would have been used by Yamaha. If anyone has any more information regarding development targeting the Hitachi 6300 series chips in the 1970s/1980s, I'd love to know!

[0] In case anyone is curious, my latest successful work is hacking the Yamaha DX9 to have the full DX7 feature set: https://github.com/ajxs/yamaha_dx97

If you don't mind swapping some chips, there's a project to bring out the full potential: https://github.com/ajxs/yamaha_dx97

Yes, there are many challenges in reverse engineering these classic games. This is a good example.

https://www.youtube.com/watch?v=objL2hGAEgU

Living in L.A. in the 90's, I remember Pack Mann in Pasadena had this one.

http://www.arcaderestoration.com/games/3330/Gals+Panic+II.as...

The ROM dump's been done but people seem to be stuck on the RLE encoding. It's hard to say what kind of wizardry is needed in this case.

https://github.com/mamedev/mame/issues/5816

There's a good start at it in the tree ( https://github.com/mamedev/mame/blob/master/src/mame/yamaha/... ) but it's missing the sound generation which is kind of the important part :-)

> As requested by users, you can finally use delta CHD files for clone systems and software items. This allows for major disk space savings in some cases when you have multiple versions of a system or software item.

FWIW, this is commit https://github.com/mamedev/mame/commit/d1172bf710f2a7b1777ed...

The GitHub Actions workflow bgfxshaders.yml will rebuild the shaders and then zip them up as an artefact. If you push your shader changes to GitHub and let the workflow run, you can grab the rebuilt shades from there.

Note that the process of getting the MSYS64/MinGW build environment set up is simple enough that we have automated CI builds for it on GitHub Actions without needing any custom actions of our own.