The Ultimate CPC MIDI Sound & Interface Card

Building a state-of-the art CPC MIDI Synthesizer with the Blue Pill, Serdashop's WaveBlaster S2, and Adafruit's MIDI Feather Modules

Similar projects worth following
I am building a MIDI synthesizer / MIDI interface for the Amstrad CPC line of computers. Features:
- Blue Pill-based (72 MHz)
- Send and receive MIDI data from (resp. with) the CPC
- Standalone MIDI Instrument
- MIDI Soft Through
- Flexible MIDI routing
- GM MIDI Sound Card for the CPC
- MIDI Interface for the CPC
- Works with Serdashop's DreamBlaster S2, Dreamblaster X2, E-Wave, McFly, and even the Yucatan FX GM MIDI Modules
- Only one additional chip required for address decoding (GAL22V10), since the Blue Pill does not have enough 5V-compatible GPIOs
- Minimal and versatile IO extension card to the CPC, using only software ISR's for IOREQ READ and WRITE handling (no additional \WAIT circuitry required, 72 MHz Blue Pill is fast enough to do that in software)

Part 9:
The project was well received on my YouTube channel, and I already sold the first batch. I have ordered another batch of PCBs. Thanks for the warm reception, CPC fans!

Part 8:
Thanks to OshPark for the super-swift service upgrade - the PCBs were back in record time, in flawless quality, and what's most important - they worked out of the box!

Part 7:
Prototype PCBs were designed and submitted to OshPark, Fingers crossed!

Part 6:
The breadboard is finished by now. I have added a DIL switch for option settings, i.e. MIDI and audio routing options: 

| Switch | Explanation                       | 
|   1    | Route CPC to S2                   | 
|   2    | Route CPC to MIDI OUT             | 
|   3    | Route MIDI IN to S2               | 
|   4    | Route MIDI IN to MIDI OUT         | 
|   5    | Route S2 L Channel to CPC Speaker | 
|   6    | Route S2 R Channel to CPC Speaker | 
|   7    | 1 = Enable card - make sure 8 = 0 | 
|   8    | 0 = Enable card - make sure 7 = 1 | 

Also, the S2 is now getting a proper reset signal at startup (S2 /RESET has to be pulled low for ~10 ms to ensure proper operation). For the audio outputs I am using decoupling capacitors and some resistors to optionally also route the S2 audio back into the CPC, so that the S2 sound can be heard in the CPC's internal speaker (not really HiFi, but good enough).

The card can also be disabled - simply removing VCC / GND doesn't work, as it is still connected to the bus, so parasitic effects will crash the CPC. Indeed, there are CPC backplanes available that allow you to "power down" the expansion card. This is useless, for that reason, and not a working way of removing a card from the bus. The only way to remove an IO extension device from the CPC expansion port (without uninstalling it pysically from the backplane) is to "cut" the IOREQ line with a switch. However, this leaves the IOREQ input to the address decoder floating now, so that's not a good situation either as it will again result in spurious false positive IOREQuests to the Blue Pill which will mess with the CPC databus then, and hence crash the CPC. So, we need *two* switches to disable the card - one for "cutting" IOREQ, and another one to connect the GAL IOREQ input to VCC (over a resistor) so it wont't hallucinate. I could have done this with one switch and an additional inverter, but hey, the aim of this project is to have no extra glue logic (with the exception of the one GAL22V10). Also, that makes good use of the 8 position DIL switch - I would have had one switch left unassigned otherwise :-) 

Part 5:
MIDI data is received over the MIDI IN DIN socket on the MIDI Feather board by now, put into a receive ring buffer, and relayed / presented to the CPC byte by byte. Two pointers are used to index the buffer: a write pointer (index), and a read pointer (index). The buffer has 256 bytes, and it stalls when

read_cursor == (write_cursor + 1) % BUFFER_SIZE

 until more bytes have been consumed by the CPC to make space again in the buffer. The protocol uses two IO port: address &FBFE for checking if a MIDI byte is availabe (1 or 0), and &FBEE for receiving the next byte from the buffer (it then gets removed from the buffer). Instead of generating MIDI data from a connected MIDI keyboard, I am again using my Roland USB MIDI interface and a MID song played (and turned into MIDI messages) by the PC, hence streaming MIDI data from the PC into the Midi Feather, into the Blue Pill, into the receive buffer, and finally into the CPC. The CPC is then playing the received NOTE ON / NOTE OFF MIDI messages using its internal sound chip (the AY-3-8912) - a maching code program is running on the CPC turning it into a 3-voice polyphonic MIDI synthesizer! This kind of real-time MIDI data processing with the CPC really requires a machine code program; BASIC would be too slow (despite the receive buffer; it would overflow to quickly...

Read more »

  • More MIDI Modules...

    Michael Wessel06/14/2021 at 15:08 0 comments

    I have also ordered a McFly and an E-Wave from Serdashop - these should work as well, same S2 connector! I am also going to order a Yucatan-FX later this year. Great that there is such a plethora of S2-compatible midi modules to choose from!

View project log

Enjoy this project?



adam.klotblixt wrote 05/29/2021 at 16:28 point

Congrats on your fast success! Nice to see/hear it working.

  Are you sure? yes | no

Michael Wessel wrote 05/29/2021 at 17:19 point

Thanks Adam! And when I am done, I am going to make the sources public, as usual. Cheers Michael

  Are you sure? yes | no

adam.klotblixt wrote 05/26/2021 at 14:01 point

I've read that the Z80 refresh is disabled during WAIT, so memory might corrupt if you hold it too long.

  Are you sure? yes | no

Michael Wessel wrote 05/26/2021 at 15:16 point

That might be the case for Z80-based computers that rely on the Z80 for DRAM Refresh. The CPC does not though, so you can hold it as long as you want. The
Z80 is not refreshing the DRAM in the CPC, and there are actually very few Z80-based old computers that use the build-in Z80 hardware DRAM refresh feature. Most of them implement their own refresh logic.

  Are you sure? yes | no

Michael Wessel wrote 05/20/2021 at 19:42 point

Thanks Adam, yes - the Blue Pill has awesome performance for its price tag. Tensy 4.0 might also be tempting... if it only was 5V-compatible! So I rather go with the Blue Pill for now and the extra GAL for address decoding, that's still a cheaper and easier setup than all the additional level shifters I would need for a more powerfull MCU like the Tensy 4.0.

I will post it at some point when it does a little bit more.  At this point, it is nothing more than the GPIO port declarations, and an ISR that handles both IOREAD and IOWRITE requests coming from the GAL. To be sure I am not missing the databus value, I also halt the Z80 CPU long enough for IOWRITE requests to get a stable databus readout, and also while switching the databus GPIO from input to output  while serving the IOREAD request (and while switching it back to input mode again after the IOREAD request was served).

  Are you sure? yes | no

adam.klotblixt wrote 05/20/2021 at 19:06 point

Would love to have a look at the Blue Pill code. This is a great way to build cheap expansions to many retro computer systems.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates