superctr
commented
4 years ago lessons learned from the first Z80 implementation (mdssub.z80)
- polling the FM timers add a lot of overhead. It's more efficient to 'count cycles' and try to even out the different code paths (or even eliminate them)
- Buffers should be as large as possible (128 or 256 bytes per channel) to reduce the overhead from bankswitching. Double buffering could be used some delay is acceptable (if 128 bytes per channel, the delay will be about half a frame for 16khz)
- perhaps there should be multiple "editions" of Z80 code, for systems like MCD and 32X the Z80 can be entirely focused on e.g. frequency calculations and write queues to reduce CPU load.
possible future version:
- keep channel registers in bc', de', hl', mixing/buffer stuff in bc, de, hl
- buffer 2 samples on one channel for each mixed sample that is output
- once a buffer is completely filled, switch to the next channel
It looks like I am writing a Z80 PCM against better advice. The goal of the new Z80 driver is to offload some tasks from the 68k to improve CPU load and smoother PCM playback (=no need to stop Z80 for longer periods of time)
68k sends key on/off commands to Z80Not neededAdvanced features (No need to implement, could be nice to have?)
Z80 could write instrument data, however it would not be very useful unless a full command queue is implemented. The 68k instrument loading routine is already very tight.