CPC / Raspberry Pi Bridge Card

Started by zhulien, 16:14, 08 May 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I believe the only part i am waiting for now is the voltage levelers.  Our local electronics stores only sell single line voltage levelers which I would have to use 30+ of if i got them.  That would make a very busy prototype board.

I am now considering the following... what do you think?

16 address lines, all input to PI
8 data lines, I/O to and from PI
RAMDIS (necessary) output from PI
RD, WR to control reading and writing
BRST i am considering attaching to the same GPIO as address line 0, with directions filtered by diodes (can anyone see any issues with this?)
this leaves 1 GPIO left for something else... *and* more importantly I don't need to use the horrible flat cable camera GPIOs of the PI... Just a single 40 pin ribbon cable to connect.

At first I thought I need MREQ and IORQ, but now I don't believe I do, because the PI can monitor everything.  It only matters if i want to know the difference between an I/O request and a memory request and I cannot see why I need to since I won't be sharing address space between the MREQ and IORQ anyway within the PI.

Now here is an interesting thing... If I extend the 40 pins to multiple sockets... I can cater for multiple PIs at once with only the cost of sockets added and board size I believe.  So... why do this?  In theory as follows.

All PIs are monitoring the bus.  Consider if PIs are used for transformations.  Multiple PIs can perform different transformations of the same data at the same time with a simple LDIR.  Consider using a 3d library.  The main PI outputting the 'front' display, subsequent PIs outputting peripheral displays with no additional CPC overheads.  Just like Gran Turismo on the PS3... Maybe we could see a Star Strike 2 one day with peripheral displays... or a Castle Master or similar?

OK, this is really GT5 on PS3 (not the 6128Plus :D


How will I know to enable the PI or disable it and not be conflicted with every other memory read/write occuring on the CPC?  I can make sure a particular 'pattern' is in a part of memory to activate the PI... which from a PI's perspective would be a simple string compare.  ie: if ALLPISAREGO is sent to the bus in sequence (can be an LDIR too)... initialising it backward so it doesn't trigger the PI by default...

I am also investigating Spectrum, Sega, PCW and MSX options for the hardware too.  So far I believe the Spectrum, Sega, PCW will be very trivial to support in the same hardware.  The MSX I am still investigating to do with CS1, CS2 and BUSDIR...



Just an update because someone in the CPC accelerator thread suggested that everyone should make something and not just talk.  Our projects are being researched, funded and developed through my company and will be likely released in time where the research has proven (hoping sometime this year).  We had advertised locally as well as directly to a few community members to have the hardware work contracted to them, but they had turned us down due to other commitments - so we are taking on this ourselves.

We now have now an abundance of 6128 Pluses, CPC 6128s, a 464 and a few 664s for testing. I got my first PI 3B a couple of weeks ago, GODIL FPGAs, and JustCPC 128ks and all especially for such developments as well as a new PCW, PCW16 and MSX2.  Initial development focuses on CPC as that is what we are most familiar with - we are also mainly a software team - much of our code will be portable to the other Z80 systems.

Some products/projects will be fully open, in the public domain with source code provided (as with the 8BML, VB6 Cross Compiler) and some will be sold but as affordable as possible because we want every CPC owner (and more) to have a new Graphics card with parallel processing capabilities, acceleration, and a few other bells and whistles. We have chosen the PI bolted onto the CPC directly as the PI over 3 generations... have remained backward compatible with their PIs - so our hope is that future upgrades will be possible and inexpensive.

I am waiting still for a few more components to arrive that cannot be bought locally in the electronics shops (Jaycar doesn't really sell much electronic components anymore).  We have more plans for the PI than I have stated here but we are excited still and will update as we progress.

Will it be a CPC if it has a graphics card?  Well... is a PC a PC if you use cards instead of all the onboard features? Definitely!!!  In practice, on the CPC... a Graphics Card won't retarget existing software (CP/M and BASIC could be possible to retarget), but that doesn't mean we all can't have fun coding on our CPCs doing new things in Z80 which we all know and love.

As for the VB6 Cross Compiler... that is the only project that is currently inactive, because we could not find someone competent in Z80 code generation willing to finish it off.  We can and in time we might... but it is the lowest priority of all the projects at this time.


This sounds an fascinating and mind boggling project! I can't say I understand much of the technical stuff you've described here, but I certainly wish you luck with it, and will be interested in getting my hands on the final product at what ever time it is ready!

Good luck with such an ambitious project.
Chibi Akumas: Comedy-Horror 8-bit Bullet Hell shooter!
Learn ARM, 8086, Z80, 6502 or 68000 with my tutorials: www.assemblytutorial.com
My Assembly programming book is available now on amazon!


Atari ST community has a similar card : http://joo.kie.sk/?page_id=384

I would love to have an equivalent on my CPC (ROM, RAM, floppy drive emulation, HDD emulation with a specific firmware, internet access, files, images, snapshots transfers, soundplayer, video acquisition... ) to replace all the different cards more or less maintained


I do have the Atari equivalent. It's a beast and can do tremendous stuff, but it's not the easiest add-on to use...

Unfortunately, its developer had to abandon further development and selling because of the crippling taxes he had to endure.


FWIW - here is a great project that gives some insights to some of the engineering challenges one faces in making such a device.

As already suspected, being able to quickly react to an address with the correct byte being put on the databus is extremely challenging with a Raspberry Pi, and only works with a trick here:


The trick is explained from 11'40'' on here:



Quote from: LambdaMikel on 21:56, 01 June 18
The trick is explained from 11'40'' on here

Having said that, this trick (basically, address prediction / guessing) won't work well for the CPC Memory.


But then, he is using a Pi Zero... the most recent Pi 3B+ should be almost 2.5 times as fast as the Pi Zero. So maybe it is within range.

What do hardware experts think here? Is that feasible? My suspicion is still "no", because you actually have to do some computation in order to react to an address in an intelligent way (OK, it could just be a memory lookup, but then it is not that interesting).


I watched that video a couple of days ago, really really nice and interesting. I also liked the philosophical angle he threw in.

That said, although it's extremely interesting and impressive, is it practical?


Interesting Sidekick64 for Commodore 64 does something very similar - another verification that 'in theory' using a Pi directly to the CPC bus could simulate many hardwares.  Skip to about 17 minutes if you don't want to watch the entire video: 

Powered by SMFPacks Menu Editor Mod