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!
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!
Prototype PCBs were designed and submitted to OshPark, Fingers crossed!
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 :-)
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 »