Review Videos

"MeinElektronikHobby" (in German): 

AmstradNoob: 


Development History:


Part 14: 

By now, the BIN MID file player is also able to use the 512 KB memory expansion (DK'tronics "standard"). The Python-based converter has been improved a bit; timing is much better by now. Here is a line out-recording of the card with he X2GS. Enjoy!

Part 13:

Previously, to generate song files for the card, I had to record the MIDI events generated by playing back a MIDI song in realtime into the CPC. MID playback was done with the PC and MIDIBAR, and the CPC recorded the messages arriving with a USB->MIDI cable in the card's MIDI IN DIN port. Now, depending on the complexity of the MIDI data stream this can be very close to the limit of what the card / CPC can process (some .MID's require CRAZY bandwidth...) Whereas this works mostly fine for MIDI songs of medium complexity (whatever that means - e.g., all the song fragments demonstrated in Part 12 were created in that way), this "realtime MIDI message recording into the CPC"-approach is not feasible for very complex MIDI songs.

Hence, I created a Python-based .MID to .BIN converter which allows me to generate song content for the card much more readily and conveniently by now (with the push of a button). Also, since these BIN song files get very large, we need to use the CPC's extended RAM. The CPC 6128 already offers 128 KBs, and I simply set aside the second 64 KB bank exclusively for MIDI data. Here is a video of the first songs created by the Python-converter, utilizing the extended memory - AxelF and MammaGamma unabridged!


The Python converter still needs a bit of work, but I am going to release it on the Github repo soon.

Next, I am also going to support the standard DK'tronics 512 KB memory extension for the CPC, which is a modern and wel-supported "CPC standard" (e.g., ToTO's XMem and Revaldinho's RAM extensions are all DK'tronics compatible). 

Part 12:
I have a new favorite sound module for the Ultimate MIDI Card - the X2 GS! It really sounds as good as my Roland Sound Canvas. The GS certified Roland MIDI sound bank makes all the difference in terms of sound quality. Whereas I was a bit disappointed by the X2, the X2 GS exceeded my expectations! Really an amazing sound module. Hence, I recommend the S2 for the price sensitive customer, and the X2 GS as the audiophile no-compromise-MIDI solution. Listen to the X2 GS here; this is a line-out recording. Sound starts at 2'10:

Part 11:
Thanks to PCBWay for sponsoring this project by giving me a free batch of PCBs!

They are thick and sturdy and I can recommend them. I am making this endorsement as an individual, and it should not be construed as coming from or being related to my employer in any ways. Interestingly, the PCBWay PCBs appear to be identical to the Seeed Fusion PCBs to me (maybe they are even using the same factory?) This is of course speculation.

Anyhow, I have assembled one with the new PCBWay PCB, and you can see and hear it in the following video, where I am comparing 4 different MIDI options: the Roland Sound Canvas, the S2, the McFly, and the EWave, all but the Sound Canvas are from Serdashop. The S2 is still my favorite. The line out audio of the EWave is at a lower level by default, and the McFly gave up on the MIDI data. It doesn't like the song it seems, there is some MIDI data in the song which makes it give up. Maybe the complexity of the song data is too high. Anyhow, there might be other songs which play fine with the McFly, I have to investigate that a bit further. However, it seem the S2 has highest line out levels and best clarity; the filtering (?) on both of the McFly and the EWave is too strong IMHO, they lack a bit of clarity. I will try another MIDI song on the McFly at some point to get a better understanding of what's going on.

Part 10:
Complex MIDI playback from the CPC, standalone. I took some time to implement the MIDI data stream recorder in Z80. It is basically a CPC MIDI realtime "sequencer" (without quantization) that just records and stores to memory all incoming MIDI messages, clock-indexed. To record data, I can just playback a MID file with the PC and stream the MIDI data into the CPC via a USB MIDI cable. The MIDI data gets recorded into CPC memory, and can then be played back standalone without requiring the USB MIDI cable and PC. I can also save the song data to disk, obviously. So I now have a way of playing back complex MIDI songs from the CPC standalone, without having to "program" them or having to use a tracker / composition program on the CPC. The standalone CPC MIDI song player & recorder is demonstrated in the video below. As usual, the assembler source code, and the 8 GM MID song fragments demonstrated here, can be found in the Github repo:


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 since BASIC could not consume the bytes fast enough from the buffer). Here is a video - the CPC sounds quite good for Baroque music in unison with the S2 module (Bach, Pachelbel):



Part 4:
MIDI IN over the Adafruit MIDI Feather DIN socket is working by now. So I now have MIDI SOFT THRU as well as MIDI IN -> Waveblaster S2 working. I can actually also receive MIDI Data from the CPC in parallel, and I am using this "on the fly mixing" of 2 MIDI data streams to "drum along" (admittedly very poorly) with MID MIDI data being streamed from the PC over a USB -> MIDI DIN cable. So, the CPC MIDI soundcard is playing CANYON.MID and some music from DESCENT2 here.

On a technical note, the Blue Pill is very nice for ISR handling - I now have 2 ISRs, one for serving the CPC IOREAD and IOWRITE requests, and another one, handling the MIDI IN UART RX data (which gets buffered). In principle, both interrupts can happen at the same time, so I gave higher priority to the ISR handling the CPC IOREAD and IOWRITE requests, because it crashes the system if the timing is only slightly off. I am currently also halting the Z80 when the UART MIDI IN ISR becomes active. As shown in the video, this results in stable behavior with no CPC crashes.

The synchronization can still be improved a bit; sometimes, the MIDI UART streams (MIDI IN and CPC MIDI data from "real time drumming") get "shuffled", resulting in bad notes (note that MIDI messages consists of multiple bytes). I expect this to be a corner case anyway - the MIDI IN data is quite complex here. For a MIDI sequencer running on the CPC, we will need to send MIDI data out over the CPC IO port while receiving MIDI IN data at the same time (i.e., while recording a new instrument track), so this is somewhat relevant. However, the received MIDI IN data is much less complex in a typical sequencer application (since the musician plays in the notes of one new instrument / track whilst listening to what was already recorded), and not a whole MID song like here. In contrast, the MIDI data played back from the CPC (in a typical sequencer application) will be more complex than the MIDI "realtime drumming" data that I am producing by hand here.




Part 3:
I now have the Adafruit MIDI Feather module and Serdashop's S2 DreamBlaster modules hooked up! And it works. So the 3V USART2 from the Blue Pill is driving the S2, and the 5V-compatible USART1 is talking to the MIDI Feather. The firmware relays any byte coming from the CPC to both UARTs, so I can demo the S2 and the Roland Sound Canvas in this video:


The next step is to enable the firmware to receive MIDI IN data, and make it available to the CPC via a buffer and IOREAD requests. That will require a receive buffer and a second IOREQ read port for reading the status of the buffer (byte available or not?), in addition to the existing IOREQ read port for reading the received byte. Since timing is already very critical, I want to make the firmware as minimal as possible. I will add another DIL switch for mode selection, rather than doing this in software. With the DIL mode settings, one can determine MIDI THRU and other options (from MIDI IN to MIDI OUT and/or the S2, CPC to S2 and/or MIDI OUT, etc.)

Layz Engineering - my first PCB will hence only have the GAL22V10, and 3 sockets - one for the Blue Pill, one for the S2, and one for the MIDI Feather. Depending on interest, time, and other factors, I will also look into making a custom PCBs with everything on board, but the modules are a great way of getting things started! Some CPC folks also might not need the DIN MIDI IN / OUT sockets from the Adafruit MIDI Feather, so this is optional.

Part 2: 
Current status of the project is - the Blue Pill <-> CPC interface is working reliably, also with other expansion cards connected to the bus, and it has now been stress tested in assembler rather than just BASIC to achieve maximal IO throughput. I made the test somewhat more interesting by also relaying the IO byte received from the CPC to the USART and connected an FTDI USB cable so that the byte shows up in the MINICOM terminal program running on my old trusted Ubuntu Eeepc:


Part 1:
Getting the basics working. This CPC IO interface comprises a GAL22V10 acting as the address decoder reacting to IO RD & WR requests at address &FBEE, and the Blue Pill. Nothing else. Some projects out there are using a capacitor and transistor in order to pull a WAIT state on the Z80 with a MCU for such an expansion interface. This is not required here since the Blue Pill 72 MHz MCU is fast enough, so the \READY signal can be pulled down in software by the ISR (Interupt Service Routine) when IOREQ's are happening.