• Registered: 2022-10-19
  • Posts: 7

Topic: Emulator for Z80 systems

I introduced MicroBeast, my Z80 computer kit a while ago, since it has 1-bit audio which I hope to exploit.

So this new development may be useful for anyone writing Z80 music trackers: I've now built a cycle accurate emulator for the system, which can be run at any desired CPU clock-speed, and supports writing 1 bit audio output to raw PCM files (16 bit, 1 channel, 22050 Hz). That should make it possible to test 1 bit routines for a variety of targets.

The initial release of the emulator is here: https://github.com/atoone/BeastEm - it's very early days, but I'd be glad for any feedback.

  • Shiru
  • 1-bit Wizard
  • Offline
  • From: Russia, Moscow
  • Registered: 2015-07-01
  • Posts: 514

Re: Emulator for Z80 systems

Why the output is 22050 Hz, tho? It will take an extremely good resampler/filter in the emu to make basic engines with channels interleaving (such as Music Box) to sound good at this rate, because the carrier tone will get well into the audible range otherwise.

website - 1bit music - other music - youtube - bandcamp - patreon - twitter (latest news there)

Shiru's Website

  • Registered: 2022-10-19
  • Posts: 7

Re: Emulator for Z80 systems

Good point. It's a question of getting decent performance out of the emulation. I have the clock time in picoseconds, and cycle accurate I/O, but that has to be translated both to the O/S audio layer (so you can hear it) and written to an audio file (so you can examine the waveform).

I can make the sample frequency user selectable (would 44K be enough??), but don't know enough to implement a realistic filter in the emulation itself. If anyone has any good resources or suggestions, I'd be very happy to implement them.

It's worth noting that in the demo firmware, I put in a (broken) version of the qchan music player. It uses 'pin' synthesis which sounds bad in the emulation. The good news is it sounds exactly as bad on my real hardware (which has a cellphone style speaker with a fairly heavy R/C filter) - so clearly that style of sound generation doesn't work well with MicroBeast....

  • Shiru
  • 1-bit Wizard
  • Offline
  • From: Russia, Moscow
  • Registered: 2015-07-01
  • Posts: 514

Re: Emulator for Z80 systems

From your description it kinda sounds like your emulator works in realtime for some reason. Normally an emulator does not run in realtime, it executes a chunk of code worth of a frame clocks, all sound writes just get queued with a timestamp in the emulated system clocks. Then it get synced with the realtime - a frame buffer displayed, the queue rendered and downsampled into a sound frame (~882 samples at 44100 Hz) that can be either streamed to the OS audio or dumped into file.

A filter is not a problem per se, just a low pass filter applied to your sound stream rendered at the system clock (8000000 Hz), so you get rid of the high frequencies before downsampling (this called pre-filtering), then downsample it to 22050/44100/48000 etc, with something better than linear interpolation preferably. The tricky part was usually how to do it efficiently, although I don't think it is a big deal for the modern PCs.

website - 1bit music - other music - youtube - bandcamp - patreon - twitter (latest news there)

Shiru's Website

  • Registered: 2022-10-19
  • Posts: 7

Re: Emulator for Z80 systems

It's not running in realtime, but the synchronisation with the display output and the audio output are separate. The display is updated with relation to the emulated clock time for various reasons (I need to be able to view intermediate display states when the emulator is halted).

I sample the audio at the SDL audio driver's frequency (ie. 22050 etc.) and then write the sound buffer directly (to the audio driver and optionally to file) through a callback. This was the 'obvious' way to do it, but I'm happy to improve it if it helps.

It would be possible to sample the audio at a much higher rate, but I don't have good information on down sampling 1-bit audio to a 'realistic' output. I'm also nervous of killing the overall performance of the emulator, since the cycle-exact emulation of the main components is quite demanding already.

In the short term, I've added a command line option to determine the sample frequency, so you can set it to eg. 48000 and get higher quality output - though it's still going to be unfiltered.