ive been on the hunt for a while to find a nice solution to interface a RPI (full or Zero W) with a CPC with an easy solution that doesnt involve too many chips, and uses what i have on hand!.. it should be able to emulate most features found on external board and more.. everything from 4MB addressable RAM, ROMs, FDC,serial, wifi, sound emulation/overlay, video emulation (V9990 like) over hdmi.. i want a device that can be programmed in the future to expand to more (emulated) devices and upgrade capabilities.. things like the hdmi and large memory and insane speed can acheive this...
tonight i used Grok 3 beta to help me narrow down what i need... i had to prompt it which ICs to use in some cases, and asked it to find alternatives to GPIO ICs to interface the address bus..
i also went through a few various MCUs instead of the RPI, namely the ESP32, SPI was a speed issue (i can see why now thanks to grok!).. so had to be dropped for another solution.Grok thought that the RPI was the best overall solution along with using a STM32 bluepill to decode the address bus... BUT 10-36Mhz SPI is an issue i hear you say.. well this is where grok plays its part.. it suggested i used a parallel bus to communicate between the STM32 and RPI.. it turns out, we have enough pins left on both stm32 and rpi to do this! and support for decoding of 256 IO ports is available but maybe 128 is plenty?! :P
with this design the RPI connects to the data bus directly, and provides full speed reads and writes without any limitations
There was also the issue of 5v tolerant pins on the MCUs/RPI.. to help there 1k or 2k ohm resistors where suggested to decrease the source/sink currents and help save the STM32 and RPI and z80 from burning up long term...the STM32 to RPI 8bit parallel bus is already at 3.3v.. it could be easy to add bi directional level shifters, but this way is cheaper...
i know its probably not needed 74LS245 buffer on the data bus
sound emulation at this stage is generated on a PWM pin but can be moved to HDMI or i2s quite easily..
what i have at the moment is best summerized by grok!
Components- STM32 Bluepill (STM32F103C8T6): Decodes Z80 address bus (A0-A15) and control lines, outputs 8-bit region codes.
- Raspberry Pi Zero W: Manages Z80 data bus (D0-D7) via a buffer, handles emulation and features.
- T74LS245B1: Buffers D0-D7 between Z80 (5V) and Pi (3.3V).
Pinouts
STM32 Bluepill- A0-A15: PA0-PA15 (16 pins, 5V-tolerant, 2kΩ resistors)
- Control Lines:
- /MREQ → PB0
- /IORQ → PB1
- /RD → PB2
- /WR → PB3
(4 pins, 2kΩ resistors)
- Parallel Out (8-bit): PB8-PB15 → Pi GPIO 5, 6, 12, 13, 2, 3, 4, 15 (8 pins)
Raspberry Pi Zero W- D0-D7: GPIO 16-23 (8 pins, 2kΩ resistors) via T74LS245B1
- Control Lines:
- /RD → GPIO 24 (to LS245 DIR)
- /WR → GPIO 25 (to LS245 /OE)
(2 pins, 2kΩ resistors)
- /WAIT: GPIO 26 (1 pin, 2kΩ resistor, 10kΩ pull-up)
- Parallel In (8-bit): GPIO 5, 6, 12, 13, 2, 3, 4, 15 ← STM32 PB8-PB15 (8 pins)
- Sound: GPIO 7 (1 pin, PWM)
- Video: HDMI (no GPIO used)
T74LS245B1- A0-A7: Z80 D0-D7 (5V side)
- B0-B7: Pi GPIO 16-23 (3.3V side, 2kΩ resistors, VCC = 5V)
- /OE: GPIO 25 (low to enable)
- DIR: GPIO 24 (high = read, low = write)
Key Features- Speed: Runs at 4 MHz with ~135 ns latency (no /WAIT needed, < 250 ns threshold).
- Address Regions: Supports 256 regions via 8-bit codes; 5 used (RAM, ROM, SD, sound, V9990), 251 available.
- Emulations:
- 512 KB RAM
- ROM banks
- SD/FDC
- Sound (PWM)
- V9990 video (HDMI)
- Pin Usage:
- STM32: 28/37 pins
- Pi: 20/26 pins
- Safety: 2kΩ resistors on 5V-to-3.3V lines, LS245 buffers data bus.
- Hardware: Built with STM32 Bluepill, T74LS245B1, and Raspberry Pi Zero W.
Summary
The STM32 Bluepill decodes the Z80's A0-A15 into 256 region codes, sent over an 8-bit parallel bus to the Raspberry Pi Zero W. The Pi handles D0-D7 via the T74LS245B1 buffer, running emulations at 4 MHz with 135 ns latency. The design uses existing parts, ensures voltage safety, and leaves room for future I/O expansion. Next steps: code the STM32 for address mapping and the Pi for emulation, then assemble with a CPC connector.
im after any ideas and suggestions on what could be added and if where im headed looks right....
i dont care if the RPI has enough power to emulate a CPC fully and then some, thats the point! i want it to run all this and an emulator of whatever system, while i run my real CPC! (that comes after all this!) and can emulate a Symbiface card and more
things like video cam to RAM or a math co-processor would be possible...
i know this is a very ambitious task but maybe we could turn it into a community thing, im happy for anyone to be involved, i wanted to opensource it anyways...
thoughts?!.. anything that looks obviously wrong, or that im forgetting?
my first step is to work on wiring up the STM32 on a breadboard to the CPCs address bus to a passthough on an extension expander board, and code and verify the decoding works as expected
Cool, sounds very promising, I like every attempt to recreate a V9990 and even more (Ram, SD card)! Could it use the USB for a mouse (SF2 or Alibreo compatible)?
thanks for the encoragment Prodatron!.. i know v9990 is quite the task, and will probably come last!..and maybe not a full compatable implementation, but i will definatly be looking at some of your routines for accessing its regisiters!.. maybe could even enhance it somewhat to run higher resolutions and colors, more ram etc.. the rpi has the power!
..and yes USB mouse and keyboard possibly.. i was thinking maybe they could even be over Blutooth/BLE
im also thinking things like MP3 player, chiptune player,internet radiio etc controlled from CPC..even if its just to queue up a mp3 file from the RPIs SD and play and stop it...
with a little more thought and input to.from grok, it would be possible to send 2 bytes to the RPI from the stm32 to represent the full 64k memory and io space within the 250ns threshold instead of only 256 regions..
its probably going to take a bit for the RPI OS to boot so will need to reset the CPC once the rpi has booted and its buffers etc are setup.. maybe need to find a way to hold the CPC in reset until its booted...
grok is really bad this solution is doomed to failure rework the subject.
Quote from: Canou1967 on 11:25, 11 April 25grok is really bad this solution is doomed to failure rework the subject.
another fake account for trolling purposes? SMH..pathetic
What is this Grok 3? It can design hardware expansions?
No, it just lacks the vital signals for it to work.
... RAMDIS ROMDIS
Quote from: Canou1967 on 10:11, 12 April 25No, it just lacks the vital signals for it to work.
... RAMDIS ROMDIS
...why didnt you just say that to begin with!?.. it was something id forgotten about... ..thanks for the reminder!..
that is trivial anyways, what i posted was never going to be the final pinout...
..i have the stm32 half built up and need to work on some testing code...need to find the time..
No worries, all my encouragement.
Interesting Projekt.
Can you elaborate a little bit more on which controller (STM32 and RPI) is doing what?
You are talking about address decoding and data bus. That is clear, but who will host the RAM/ROM for instance?
If it is the Raspberry Pi, will the RPI not also need all 15 address lines, or at least (for ROM) 14 of those? ....
What is the actual function of the Regions ? Is it to support all kind of IO requests so that the Raspberry PI can emulate multiple expansion parts at the same time?
Do you already have a block diagram on how things should connect or even better a schematic?
Regarding the T74LS245B1.
I am not sure if that is a good solution. You still would need the resistors, which comes with a lot of other timing relevant constraints. So the signal flanks might not be fast enought any more.
Maybe you want to look at a TXB0108, which has been actually designed for bidirectional datatransfer between two voltages and does not require external resistors.
https://www.ti.com/lit/ds/symlink/txb0108.pdf
It is specified for up to 10Mhz, which should be plenty for the usecase here, that has at maximum 4mhz signals. Typically the signals are up for much longer times (e.g. 1-3 clocks).
The txb0108 is for CMOS push/pull logic - if you have open drain you would need txs0108. Not 100% sure yet what we actually would need here.
Quote from: Prodatron on 16:09, 10 April 25Cool, sounds very promising, I like every attempt to recreate a V9990 and ...
I can second that. The thing I am missing most, is
a graphic card. Because I'm using Symbos quiet often,
I could benefit from a higher resolution and more colours.
Steven
Quote from: SerErris on 17:10, 10 August 25Interesting Projekt.
Can you elaborate a little bit more on which controller (STM32 and RPI) is doing what?
You are talking about address decoding and data bus. That is clear, but who will host the RAM/ROM for instance?
If it is the Raspberry Pi, will the RPI not also need all 15 address lines, or at least (for ROM) 14 of those? ....
What is the actual function of the Regions ? Is it to support all kind of IO requests so that the Raspberry PI can emulate multiple expansion parts at the same time?
Do you already have a block diagram on how things should connect or even better a schematic?
Regarding the T74LS245B1.
I am not sure if that is a good solution. You still would need the resistors, which comes with a lot of other timing relevant constraints. So the signal flanks might not be fast enought any more.
Maybe you want to look at a TXB0108, which has been actually designed for bidirectional datatransfer between two voltages and does not require external resistors.
https://www.ti.com/lit/ds/symlink/txb0108.pdf
It is specified for up to 10Mhz, which should be plenty for the usecase here, that has at maximum 4mhz signals. Typically the signals are up for much longer times (e.g. 1-3 clocks).
The txb0108 is for CMOS push/pull logic - if you have open drain you would need txs0108. Not 100% sure yet what we actually would need here.
thanks for them suggestions SerErris!
yes the STM32 (bluepill/blackpill) decodes the address bus (and some control signals) and sends it off to the RPI over an 8bit parallel connection, (will need 2 writes to get the 16bit across to the rpi, but should still be fast enough)
the regions thing was when from when i was looking at just decoding IO ports, ideally the rpi will act as an all in one addon device, ram, rom, sound (various chips), video (original and v9990), coprocessor etc etc so the rpi will need the complete 16bit address..
having the RAM on the rpi should allow the rpi to "reconstruct" the video from the CPC, so it can use HDMI out and not need a converter... the V9990 emulation im guessing would be on its own IO port with its own emulated video ram
its not possible to totally disable the CPCs onboard ram due to the GA, so the base 64K will have to be shadowed for the rpi to reconstruct it...
it seems the PicoCPC may already have most of these features on the way...so this project has been sorta put on hold till i see what the final version of the picocpc offers...i might be able to drop a bunch of it and focus on the video emulation