Raspberry Pi on CPC - Free v9990 or Symbiface 2

[zhulien]

Hi,


I am back to my raspberry pi project for CPC after a very long delay.


https://docs.google.com/spreadsheets/d/1bS1CLDIN0jPP3GI2pCcTU7_VIf2otQ10bVm-NL0F2eQ/edit?usp=sharing


To be honest, I am not a hardware guy only due to not having made much hardware beyond switches and buttons and lightbulb experiments, it has never been the 'fun' bit of computing for me.  I much prefer to code.

I'd love someone to make the hardware and let me experiment with it with the ultimate goal of making it a useful hardware + software for CPC users.


The first person to successfully negotiate with me for 2 of these built (without magic smoke), I'll give you your choice of a v9990 (not used) or a Symbiface 2 (very little used).


For the ones to be built first, I don't mind if they are socketed or not.  They should be in mx4 form factor and allow a raspberry pi to be either plugged in (like the CPC-Link card) or via a ribbon to the Pi.  The goal is to make it cheap so everyone will want one, but worthwhile with a bit of profit for whoever wants to make them will make them.

[zhulien]

All the level converters have the following pins: A0 -> A7, B0 -> B7, VCCA, VCCB, GND


The level converters are arranged as a set of 4.


Level Converter 1 maps the CPC Address Bus pins A8 -> A15 to the Pi's BCM0 -> BCM7.  one-way to Pi
Level Converter 2 maps the CPC Address Bus pins A0 -> A7 to the Pi's BCM8 -> BCM15.  one-way to Pi

Level Converter 3 maps the CPC Data Bus pins D0 -> D7 to the Pi's BCM16 -> BCM23.  this is bidirectional


So far so good - I think.

[zhulien]

Level Converter 4 maps the control signals of the CPC bus to the Pi as follows:


MREQ to the Pi's BCM24  one way to Pi
RD to the Pi's BCM25  one way to Pi
WR to the Pi's BCM26  one way to Pi
BRST to the PI's BCM8  one way to CPC
RAMDIS to the PI's BCM27  one way to CPC


Is there any dangers in mapping these right away?

[revaldinho]

@zhulien can you tell us more about what you want to do with this interface ?


CPC-CPLink gives you a simple FIFO message passing interface between CPC and RaspberryPi (or any other MCU) which means that you do not need to do any bare metal programming on the Pi side at all. You can run a full Linux on the Pi and get access to all the high level features on offer while programming in any convenient language.


It looks like you are hooking up as much of the Z80 bus as possible to the Pi-side GPIOs, and will be using the Pi to monitor and drive these in real time. That's definitely a bare metal application, and in that case I wonder if a Pico might be a better co-processor than a standard Pi? The Pico PIOs offload the CPU from pin toggling tasks and the whole Pico environment seems more suitable for this lower level of programming. Even with a Pico, doing a little decoding on the interface board in 74 series ICs might save you a number of GPIOs and simplify the programming.
[size=78%] [/size]

[eto]

if a Pico might be a better co-processor than a standard Pi

The Pico might not be able to handle the same resolutions as a v9990 due to the limited amount of RAM, but 320x240 in 8bit or 640x480 in 4 bit will be possible. Solutions to easily add VGA or DVI already exist (just a bunch of resistors). One core is under heavy load for the video output, but the other one is free and with 250MHz (that it is running for DVI anyway) I guess sprites, scrolling and so on should not be too much of a problem. Hardware cost incl. the Pico would be around 10€ and probably can be built by anyone who knows on which side the iron gets hot.

[zhulien]

@zhulien can you tell us more about what you want to do with this interface ?

Yes, as per another PI project I read a long time ago (sorry I didn't keep the link), the guy used a PI as an in-circuit CPU replacement successfully - I think it was 6502 but really can't remember.  There is also the spectrum HDMI adapter which uses a PI in a very similar way and the PI is fast enough to handle that with realtime HDMI output from spectrum bus monitoring.


In the reference section of the spreadsheet above are a lot of articles on using the PI with very fast GPIO behaviour, even in the Gigahertz for certain applications.


So, as a POC, the hope is that different CPC expansions can be created purely in software with upgradable PIs as better pin-compatible ones come out.


Not only can you code port I/O type hardware, you can code all types of memory manipulation hardware (assuming the POC with the PI proves to be fast enough).


For example...


using PI's own hardware - Memory Expansion, FullHD Video Output, SD Card support, Wifi, Blutooth


then other ideas I have such as...


- automatic PI configuration on multiple platforms
- memory transformations, since the PI is simulating a RAM expansion, it has DMA into that memory and can modify things automatically from the CPCs point of view


original thread here: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/cpc-raspberry-pi-bridge-card/

[pelrun]

Be warned, this is a very difficult thing to do in practise. While the Pi might be very fast compared to the 4MHz bus, the problem is latency, which will be extremely high. Just putting level shifters in between is not really going to be sufficient; if you look at something like the PiStorm it also needs a CPLD to do the hard realtime synchronisation.
You might want to look at the timing diagrams in the z80 datasheets and do some tests to see if you can actually replicate the bus transactions successfully with an externally generated clock before committing time or money to a hardware design (i.e. you'll want to put a logic analyzer on the Pi outputs and capture the actual waveforms.)
An added wrinkle is the CPC also makes heavy use of the /WAIT signal, which complicates things significantly - you can't just bash out a fixed waveform on the bus or you'll stomp over the gate array accessing the video ram.

I already looked at doing this with standard STM32 microcontrollers and it was infeasible - although I have a strict requirement of perfect timing that some other projects haven't bothered with. I figure Duke's Galaxy project probably got tripped up at that hurdle.

As for the Pico, well... I'll have more to say about that very soon.

[zhulien]

Surely someone wants a free v9990 gfx card to do this for me?

[abalore]

Be warned, this is a very difficult thing to do in practise. While the Pi might be very fast compared to the 4MHz bus, the problem is latency, which will be extremely high. Just putting level shifters in between is not really going to be sufficient; if you look at something like the PiStorm it also needs a CPLD to do the hard realtime synchronisation.
You might want to look at the timing diagrams in the z80 datasheets and do some tests to see if you can actually replicate the bus transactions successfully with an externally generated clock before committing time or money to a hardware design (i.e. you'll want to put a logic analyzer on the Pi outputs and capture the actual waveforms.)
An added wrinkle is the CPC also makes heavy use of the /WAIT signal, which complicates things significantly - you can't just bash out a fixed waveform on the bus or you'll stomp over the gate array accessing the video ram.

I already looked at doing this with standard STM32 microcontrollers and it was infeasible - although I have a strict requirement of perfect timing that some other projects haven't bothered with. I figure Duke's Galaxy project probably got tripped up at that hurdle.

As for the Pico, well... I'll have more to say about that very soon.

According to my investigations, you need to program the RPi at low level within a real-time operating system to be able to synchronize with the CPC Z80 using just level shifters. I was able to do it for continuous I/O read and write operations, but I don't consider it a mainstream solution. I'm working in a FIFO based interface that will be ready soon. It won't work for real-time things like RAM expansions, but it will do for things like massive storage, networking, or maybe the V9990 depending on the usage.

[zhulien]

It does it perfectly for hdmi output on zx spectrum by monitoring the bus.

[abalore]

It does it perfectly for hdmi output on zx spectrum by monitoring the bus.

If you are talking about the TK-Pie and ZX-HD, they both use powerful CPLDs between the ZX and the RPi, not just level shifters.