Yet another attempt at a RPI all in one expansion design...

[Brocky]

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?!
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

[Prodatron]

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)?

[Brocky]

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...

[Canou1967]

grok is really bad this solution is doomed to failure rework the subject.

[Brocky]

grok is really bad this solution is doomed to failure rework the subject.

another fake account for trolling purposes? SMH..pathetic

[Skunkfish]

What is this Grok 3? It can design hardware expansions?

[Canou1967]

No, it just lacks the vital signals for it to work.

...  RAMDIS ROMDIS

[Brocky]

No, 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..

[Canou1967]

No worries, all my encouragement.