#RetroChallenge @RetroChallenge Update 3

A project log for A Retro-Authentic Microtronic Emulator

Compute like its 1981 - hex on a 6digit 7segment LED bubble display! @RetroChallenge 2021/10 MIDI DRUMS Project

Michael WesselMichael Wessel 3 days ago0 Comments

We are ready to drum!

I don't dare to call this a "drum tracker" or "drum sequencer" yet because the input is blocking. Usually, a tracker or sequencer plays back in a loop, and you can change beats / drum on the fly and immediately get an idea how the loop / track is affected. However, as explained in the video, the Microtronic does not support non-blocking keypad input. So currently setting up a drum loop is a two-step process: input the drum pattern first step by step, 8 steps currently, using blocking input. We can at least hear the drum after each input. And then play them back in a loop; the speed can be adjusted using the RUN+<HEX> key function, which sets the speed of the CPU emulation.

Next steps for this project - figure out a way how to edit the drum loop pattern in real time. This will require a new non-blocking keyboard input command. I could, for example, use one of the vacuous op-codes to toggle the existing keyboard input (KIN) op-code behavior between blocking and non-blocking input. But there are other options as well.

And then, there are still some other shortcomings that need to be addressed. For example, there is no polyphony for drums currently - only one drum can be played per beat / step. Not such a big deal for a drum computer (it would be a deal breaker for MIDI tracker of course), but many drum patterns require at least the base drum & hi-hat or cymbal crash being played simultaneously. Moreover, it would be nice to have longer patterns, more than 8 steps - maybe there is even a way to add more registers to the CPU model? Note that we don't have any other writable memory in the Microtronic, and programs also cannot be self-modifying or write into program memory (this is a Harvard architecture). How about 64 or 128 steps... have to think about that. We could use the EEPROM for that... (SRAM is pretty full). I would still have enough vacuous op-codes available to support some RISC-like "load-store architecture".

So, stay tuned - future work!