Hi Everyone...
I am Julian, I am a very inactive active CPCer from the start I have much to do...
Anyway, I have previous suggested the following to a couple of people and thought now is time to suggest to this forum and see if there is any interest.
I am wanting someone to partner with to create a hardware expansion for CPC. Mostly it will be funded by me.
HW Requirements:
- as an Mother X4 expansion card - perhaps it can fit in the 5th slot (that is the through connector) so 5 cards can fit...
- lets the CPC user connect a Raspberry Pi directly to the expansion port
- if the cost is marginal to allow two Pi's to connect to the expansion port at the same time, will consider this
current Work In Progress circuit:
https://docs.google.com/spreadsheets/d/1bS1CLDIN0jPP3GI2pCcTU7_VIf2otQ10bVm-NL0F2eQ/edit#gid=0
SW Requirements:
- build a minimal communication method (API or just a pattern) between CPC and Pi C application. From this pattern we can then pass data back and forth and work from there, whether the CPC is a dumb terminal to the Pi, or whether there is a greater integration through RSXs
[Added 20170128...
Ultimate Goal of this board when a Raspberry Pi 3B is attached:
- 16kb Memory Mapped I/O Space
- 512Mb General Use RAM 8192 x 64kb blocks accessed as 32768 x 16kb blocks (available in addition to other CPC RAM expansions) usable for data and turbomode
- ARMv8 Native code libraries callable from CPC covering:
- text, window and 2d graphics primitives
- opengl 3d graphics
- video and mp3 playback
- keyboard, joystick & mouse I/O
- Z80 CPU emulation to run code in turbomode (with fallback to standard CPC if PI board is not present)
- RSXs to make use of the above from BASIC
- a CPC ROM to make the above facilities more easily available without taking up too much of the CPC's RAM
...]
Possible Uses:
- run Z80 emulators on the Pi in parallel to CPC and offload Z80 code
- play NES and other games on your Amstrad CPC (ok, on the Pi... but do we only support Pi video? CPC video is it possible? or... passthrough the video Genlock style?)
- use the Pi's ethernet from the CPC indirectly thereby gaining internet access
- use the Pi's USB and even HDMI as additional modes on CPC
- use the Pi's audio capabilities from the CPC
- use other PI facilities and RAM (as a RAM drive) from the CPC indirectly
Funding:
- well, I did say 'mostly' funded by me, so this can be done in a few ways. I am not limited to the following suggestions but I am happy to kick off the project...
- i fund it 100% and i retain 100% of profits from sales of it (I don't expect to make money from it, but recoup some of my costs if not all)
- it is funded by myself in conjunction with the partner i can find
Other requirements:
- for me to fund you, you must have proven to have already created a commercial piece of CPC hardware or similar.
I am not a bottomless pit of money but just something fun for me to give to the CPC community (if it cannot even come even with cost)... I am a software guy, not a hardware guy
Now, it is all in fun but if done in a pretty simple way as Pi's get upgraded we can replace them with newer Pis using this same bridge card.
Anyone want to discuss with me?
Julian (From Melbourne, Australia)
This is an interesting proposition. But, I think, before discussing funding etc we need to discuss what is feasible and useful with this setup...
They used to link a CPC to a PC for software development, maybe the Pi could perform the same functions as the development PC?, secondly if we want doom like games on the CPC the Pi could function as a graphics terminal like CP/M required.
Well if the hardware can be interfaced in a fairly efficient way so that the cpc can leverage off the pi hardware and the pi can be easily connected or removed so it is easily upgradable to future pi's then i am happy to fund it... of course to a negotiated amount. I can think of several cheap ways to connect them but lets see what ideas come up that are feasable. If no dma it could still be feasable for fun projects and i also like the idea of a self hosted cross dev system... if it can be done at the right price i will fund it for myself to have 2...
Perhaps if someone wants to opensource the hardware design and work on a budget if it is worth to go ahead then maybe that would be better? I am thinking a 4 figure budget... not including cents. Not quite like a comellion card for c64 but a good way to let lots of software experiments happen... could run a full lamp stack c dev env emulated cpus hardware access etc cheaply from the cpc...
Hi Zhulien,
first off, DMA isn't possible, the CPC has no provision for this. Next I'd suggest you take a look at the 50 pin expansion connector to see how much access this port actually allows. Other than the data bus, address bus and a few control signals it doesn't offer very much else. You could map i/o pins from the RPi to every pin which would then allow you to emulate things like ROM or RAM expansions. You can also pass data between the two devices, however it would always require software to be running on the CPC side to handle this, there is no real way to control the CPC externally. What the Pi then does with the data is up to you.
Bryce.
I have looked at the cpc expansion bus but as said im not a hardware guy. Elementary at best. If we just pligged a few io ports of the pi to the address and databus of the cpc what throughout is likely possible? Yep i am fully expecting to code on the cpc side and the pi for them to communicate. I can code both sides actually pretty well.
I'm a pure hardware guy, not sure what the theoretical max speed is, but I'm sure some of the coders here will be able to tell you. It will of course depend on what the Z80 needs to do between sending bits.
Bryce.
well... let's see if anyone want's to charge out their services to build the card so that everyone who wants one (which is at least me twice) can get one and cheaply (not including cost of dev and production) upgrade their CPC in a unique way...
Just bumping this as there is no job board in the forums... id rather someone with cpc hardware creation experience than someone who has never seen a cpc... the job offer is still opened.
I have found someone locally here who will be quoting me on the project over the next week or two. The project has now been scoped as:
- a card in the Mother X4 form factor that has some form of RAM on it that will be 16kb in size (usable) that can be switched into the CPC at #4000 like a Multiface 2/dkTronics but likely different IO port. It will be directly read/written to by the PI2 or PI3 (both have same pinouts). Pi will see 16kb at this stage we are considering a 2 stage write process vs paging, so that we can get away with 9 GPIO lines for the full 16kb and 8 GPIO lines for the data, 9 left for control.
- prove CPC / PI stability with constant transfers of data both ways.
After that, *if* we get as far as a production run, the card will be offered for sale below AU$100. I won't be expecting to make back my 4 figure investment, but it is all in fun - I want two even if i don't sell any more.
Software goal beyond that: HDMI, Ethernet, RAMDISK, WiFi, Analog IO ports, Audio, Video... whatever other wonderful PI hardware we can create an Amstrad CPC API to access...
Will keep you posted...
Cool 8)
Offtopic: Please check your messages regarding M4 boards....
This sounds so cool. Hopefully it's not set in the realms of dreams...
Amiga 600 has the vampire 2 card and c64 has the chameleon... do you think an fpga on the cpc if it pushes up the price is worth the extra cost vs a pi bridgeboard? For me coding with the pi solution is easier and opens up lots of possibilities that a pure fpga might not... unless the fpga was also the bridge to the pi... best of both worlds but what cost would be acceptable to the cpc community?
For a PI bridgeboard i am hoping to keep the cost below au $100... for use with a Pi 2 or Pi 3...
But if adding an fpga likr a cyclone? In small qty maybe it will almost double that cost...
Gryzor... if someone wants to be paid to build the card then it will go ahead if we can agree on a cost... i have one person in the process of quoting but will also need to manage his time between this project and a double degree at uni...
What exactly could be done with a Rasp-PI connected to the CPC?
I mean, is there already some software on the PI which allows to to some things? What could it be?
I don't have one, so I have to ask. :)
Quote from: zhulien on 20:24, 11 August 16
Amiga 600 has the vampire 2 card and c64 has the chameleon... do you think an fpga on the cpc if it pushes up the price is worth the extra cost vs a pi bridgeboard? For me coding with the pi solution is easier and opens up lots of possibilities that a pure fpga might not... unless the fpga was also the bridge to the pi... best of both worlds but what cost would be acceptable to the cpc community?
For a PI bridgeboard i am hoping to keep the cost below au $100... for use with a Pi 2 or Pi 3...
But if adding an fpga likr a cyclone? In small qty maybe it will almost double that cost...
Gryzor... if someone wants to be paid to build the card then it will go ahead if we can agree on a cost... i have one person in the process of quoting but will also need to manage his time between this project and a double degree at uni...
To interface between a Pi and the CPC requires nothing more than an address decoder and some line buffering. Using an FPGA to do this is cracking a nut with a sledgehammer.
And as TFM just said... But why?
Bryce.
Quote from: zhulien on 14:14, 08 May 16
Hi Everyone...
I am Julian, I am a very inactive active CPCer from the start I have much to do...
Julian (From Melbourne, Australia)
Julian Cassin ?
Quote from: TFM on 21:09, 11 August 16
What exactly could be done with a Rasp-PI connected to the CPC?
I mean, is there already some software on the PI which allows to to some things? What could it be?
I don't have one, so I have to ask. :)
New hdmi screenmodes. Cross development hosted in the cpc to build direct to cpc ram. USB. Ethernet. Wifi. Cpu power. Can use the cpc as a terminal for the pi and vice versa... or complete hybrid software...
Quote from: zhulien on 04:13, 12 August 16
New hdmi screenmodes. Cross development hosted in the cpc to build direct to cpc ram. USB. Ethernet. Wifi. Cpu power. Can use the cpc as a terminal for the pi and vice versa... or complete hybrid software...
The Berry as an terminal? That's an interesting idea for sure. Just thinking if the Pi fits in the case of the CPC... ;)
Maybe there are f.e. some math libraries on the Pi already to allow it to be a math co-processor. Or some kind of intelligent device.
Hi everyone. I got my 6128 plus up and running again after a long vacation (he was asleep in the cupboard for many years). Ive ordered a couple of cpc wifi cards and have a couple of neat projects under way with them... but aside from that. I have decided to look first at the fpga options i have. Currently i have had a terasic trex and used to program my c-one all those years back so have a little experience in fpga programming (but not a lot). Trex is out of production but tersasic DE0 looks like a good replacement candidate... it has lots of IOs... perhaps enough to cover the whole cpc bus and more... and floppy? But it isnt really a cpc hardware. Still if i can get it to communicate with cpc i should also be able to use it as a bridge to the PI. Benefits being that... yes you can create custom cores in the fpga but also in software entirely on the PI side as an option.
Aside from the terasic boards can anyone recommend an alternative for this tentatively called "Schwarzenegger" board that i should investigate first?
Hi there
Any progress on the CPC-RPI bridge card?
This would really come in handy :-)
Regards,
/Ygdrazil
nope... i have a person willing to take on the project who is an honors uni student but have to wait... unless someone else volunteers.
I have been in the mean time looking at 5v tolerant FPGAs - seems there are a few, but not too many - it's a lot of voltage levelers if i was to level 50 pins of the expansion port for a 3.3v FPGA, even if they are 8bit ones, that's like 7....
just a minor update... i have found a possible stopgap solution to interface a PI with the CPC - but am working on getting a quote from the guy who makes those boards to make it less complex and more 'CPC'... to bring the costs down. if he cannot or won't or we cannot agree to make it go forward, it 'could' be the basis of a development board to produce the final solution... or at least as a self-hosted PI->CPC cross compiling solution (I believe the hardware will work out of the box - but isn't the cheapest least complicated solution).
For an FPGA solution... although it doesn't readily have PI connectivity - I am thinking the GODIL40_XC3S500E DIL FPGA module (40 pin DIL) might suit. Almost sounds to good to be true, unless i misread the docs wrong... pop out the Z80, wire in this one with the appropriate core (with some awesome extras) and you have a super fast (for new software) but compatible with old software turbo board for CPC...
Z80 drop-in replacement FPGA board
https://shop.trenz-electronic.de/en/TE0261-00B-GODIL40_XC3S500E-DIL-FPGA-module-40-pin-DIL?c=97 (https://shop.trenz-electronic.de/en/TE0261-00B-GODIL40_XC3S500E-DIL-FPGA-module-40-pin-DIL?c=97)
http://www.oho-elektronik.de/pics/UM_GODIL.pdf (http://www.oho-elektronik.de/pics/UM_GODIL.pdf)
Graphics drawing accelerator cartridge creation - Commodore 64 (C64) Forum (http://www.lemon64.com/forum/viewtopic.php?p=734625&sid=998aa4ad4c43812a0b5e07160edf8ebc)
Ruud's Commodore Site: RB6502 (http://www.baltissen.org/newhtm/rb6502.htm)
The 50 pin version would give 10 additional IO ports for PI integration or other... need to create a socket adapter too for this which would raise the profile of it... i think i like the 40 more because of this...
https://shop.trenz-electronic.de/en/TE0262-00B-GODIL50_XC3S500E-DIL-FPGA-module-2-x-50-pin-IDC (https://shop.trenz-electronic.de/en/TE0262-00B-GODIL50_XC3S500E-DIL-FPGA-module-2-x-50-pin-IDC)
and a suitable core?
Projects :: OpenCores (http://opencores.org/project),a-z80
I'm almost sold on this one...
I have ordered my Xilinx programmer and a couple of GODIL's to see what I can do... will keep you posted
Quote from: zhulien on 06:24, 13 September 16
I have ordered my Xilinx programmer and a couple of GODIL's to see what I can do... will keep you posted
Did you order a real Xilinx programmer or a Chinese knockoff? If it's a Chinese one, be very careful not to click yes if it asks you to update the firmware!
Bryce.
I ordered a real one, sadly they aren't cheap (the USB cable 2) but luckily got a good price on ebay... with luck it should be working fine as advertised.
the plan:
- put a z80 core into the GODIL and see if CPC works as per normal (this is the biggest risk of it not working before enhancing the core)
- enhance the z80 core to have a turbo mode as follows:
- new instructions switch between normal and turbo mode and to copy RAM or perhaps just page the internal FPGA RAM at slow CPC speed for it to do normal speed memory transfers
- normal mode, it executes code from normal CPC RAM at normal CPC speeds with normal Z80 behaviour using the external clock
- turbo mode, it executes code inside the FPGA with RAM also inside the FPGA at fastest possible using an internal clock but pretending to satisfy the rest of the CPC's timings with nop behaviour
- connect the PI to the additional 4 I/O pins
Can anyone see any flaws in this approach?
Quote from: Bryce on 08:20, 13 September 16
Did you order a real Xilinx programmer or a Chinese knockoff? If it's a Chinese one, be very careful not to click yes if it asks you to update the firmware!
Bryce.
Oh, the ones that get bricked?
Quote from: Gryzor on 11:28, 13 September 16
Oh, the ones that get bricked?
Yup, the new Firmware bricks them.
Bryce.
Quote from: Bryce on 08:20, 13 September 16
If it's a Chinese one, be very careful not to click yes if it asks you to update the firmware!
Why?
If I recall correctly from what Bryce had told me many moons ago, the firmware is the original one and it can distinguish between an original device and clones, so it'll brick the clone. Hope I remember this correctly.
My xilinx programmer arrived... now awaiting the 2 GODIL fpgas...
2 GODIL's arrived :D
First to work out which way they go in and ensure they are safe by default in a CPC6128 (I'd rather that die than the Plus)...
will keep you all posted, if an FPGA can truely clone a Z80 I can see no reason it won't work at least if the core is compatible enough.
Here is a good article on ICE on the GODIL Home · hoglet67/AtomBusMon Wiki · GitHub (https://github.com/hoglet67/AtomBusMon/wiki)
I am hoping to give this a try this week if i get the time. It will prove if it can work or not. Interestingly, this page shows that it can work on a Spectrum +2 but not a Spectrum 48K (I don't know much about spectrum board revisions) - so there is still some hope that some CPC can run a GODIL. Now apparently there is about 40kb of RAM in it which could be used as a fastRAM. There are other possible uses for a GODIL if it works too, such as... it could be used to run things like gameboy games on a CPC - since even Minimig can run on the same FPGA core it seems maybe other CPU cores could be in there. Anyway, first see if the things work in some form on a CPC, then we can play with the ideas.
ICE T80 · hoglet67/AtomBusMon Wiki · GitHub (https://github.com/hoglet67/AtomBusMon/wiki/ICE-T80)
things a bit slow here, i ended up ordering 2 ZIF sockets and also a few Z80 sockets because the GODILs are quite expensive and don't want to lose pins in the Z80 socket. The ZIFs have arrived, not yet the Z80 sockets - Seems I need to build a small breadboard circuit to program the GODIL the first time to ensure no wrong voltages get applied to the CPC.
I have put together what i think would be the GPIO mappings from a Pi to CPC. A couple of things I am unsure of on the CPC side. I am hoping one of you with more CPC hardware knowledge than me would be able to give some feedback.
https://docs.google.com/spreadsheets/d/1bS1CLDIN0jPP3GI2pCcTU7_VIf2otQ10bVm-NL0F2eQ/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1bS1CLDIN0jPP3GI2pCcTU7_VIf2otQ10bVm-NL0F2eQ/edit?usp=sharing)
The Pi Zero or Pi B+ has 40 GPIO ports we can use:
- For the Pi to be able to map into the CPC address space, have I missed any CPC bus signals we need?
- I have hijacked 2 address lines (2 lower bits of the upper byte) and set them always high, is that ok?
- Does hardware have to somehow detatch from all bus activity if it isn't the active hardware, I am guessing i have missed something here? Is there like a latch that if this device sees an IO request for it's port, then it switches in or something?
I am hoping the Pi could map into the address space, preferably as a 16kb chunk (8kb if i have to forego another bit, or even 4kb forgoing another 2 bits)... There are 4 Level Converters to allow the Pi GPIOs which are 3.3V to connect to the 5V CPC.
If there is an interest in a Pi Zero or such connected to CPC, then maybe this could be worked as a MX board, but this is early days...
Below is an example PI logic. My only hardware projects have been dumb things in the past with switches light bulbs etc.
As I have never simulated hardware before, I am guessing the behaviour but trying to think in hardware terms. I usually think in software.
Of course, with the lack of GPIOs I can't simulate a DkTronics memory expansion, but some other wonderful things are possible.
I am assuming mapping it always into #8000 - #C000. This allows quick data transfers from normal video memory as well as 16k banked RAM within #4000 - #C000.
In my questions at the bottom, if I need BUSAK, then I will need to sacrifice another GPIO of the address space, unless I am better to replace RAMDIS with BUSAK. Also if the clock has a use, eg: timing PI operations with the CPC?
My thoughts are as follows... Allowing the PI to have mapped I/O as well as memory, I can use the memory for quick transfers in a similar way Duke's Wifi Card does it from using ROM space of the CPC. The I/O will tell the PI what I want to do, then, the memory will let me read and write chunks of data.
Am I on the right track so far?
[logic removed as will change until it is right]
questions: can IORQ and MREQ be high at the same time?
do i even need RAMRD if I don't need to know about ROM state? I can reclaim a bit if I don't need RAMRD...
when the PI sends data to the CPC, how long does it need to keep the databus high? How does it know when the CPC got the data? BUSAK? Maybe BUSAK is more important than RAMRD?
Here are the level converters I am thinking of using. They are not expensive, and needs 4 of them per board. http://www.ebay.com.au/itm/301893252205?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.com.au/itm/301893252205?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT)
Should I have any other hardware to protect the CPC or the PI? Or just 4 of them wired to the buses and nothing else?
There are multiple PI boards with the 40 pin/28 GPIO interface.
PI 2b: https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ (https://www.raspberrypi.org/products/raspberry-pi-2-model-b/)
900Mhz Quad Core CPU, 1GB RAM, 4 USB, Full HDMI, Ethernet, Audio, Micro SD, 3D Graphics
PI 3b: https://www.raspberrypi.org/products/raspberry-pi-3-model-b/ (https://www.raspberrypi.org/products/raspberry-pi-3-model-b/)
1.2Ghz Quad Core CPU, Wifi, Blutooth, 1 GB RAM, 4 USB, Full HDMI, Ethernet, Audio, MicroSD slot, 3D Graphics
Imagine... RSXs for BASIC and Z80 code libraries on CPC which produce awesome 3D graphics in Full HD resolution!!! Then... I will see if Symbos will support this too ;)
Pi-side Logic:
PI_RAMADDR_START = #8000
PI_RAMADDR_END = #BFFF
PI_IOADDR_UNMAPPED = #0001 ; used as both the I/O address and mode status
PI_IOADDR_MEMORY = #0002 ;
PI_IOADDR_MAPPEDIO = #0003 ;
intPIMode = PI_IOADDR_UNMAPPED
blnInRead = false
blnInWrite = false
Set (ALL GPIOs) BCM0 to BCM27, GPIO0, GPIO1, GPIO5, GPIO21 to INPUT
Set GPIO_RAMDIS to OUTPUT
;Set GPIO_RAMDIS to LOW ;NOT REQUIRED?
while (1)
{
Read (iorq) BCM25 into REG_IORQ
Read (mreq) BCM24 into REG_MREQ
Read (address bus) inputs BCM0-BCM15 into REG_ADDR
Read (rd) BCM26 into REG_READ
Read (wr) BCM27 into REG_WRITE
if ((intPIMode == PI_IOADDR_MEMORY) || (intPIMode == PI_IOADDR_MAPPEDIO))
{
if ((REG_ADDR >= PI_RAMADDR_START) && (REG_ADDR <= PI_RAMADDR_END))
{
if (REG_MREQ == 0)
{
// PI is active and we have a memory request
if (REG_READ == 0) // READ REQUEST
{
if (!blnInRead)
{
blnInRead = true // start of read cycle
set GPIO_RAMDIS to HIGH
set (data bus) BCM16-BCM23 to OUTPUT
// memory read requests
if (intPIMode == PI_IOADDR_MEMORY)
{
// read data from somewhere in PI RAMDisc memory
REG_DATA = readMemory(REG_ADDR);
}
else if (intPIMode == PI_IOADDR_MAPPEDIO)
{
// read data from somewhere in PI I/O memory
REG_DATA = readIOMemory(REG_ADDR);
}
put REG_DATA into (data bus) BCM16-BCM23
}
}
else if (REG_WRITE == 0) // WRITE REQUEST
{
if (!blnInWrite)
{
blnInWrite = true // start of write cycle
set GPIO_RAMDIS to HIGH
set (data bus) BCM16-BCM23 to INPUT
Read (data bus) inputs BCM16-BCM23 into REG_DATA
// memory write request
if (intPIMode == PI_IOADDR_MEMORY)
{
// write memory to the PI RAMDisc memory
writeMemory(REG_ADDR, REG_DATA);
}
else if (intPIMode == PI_IOADDR_MAPPEDIO)
{
// write memory to the PI I/O memory
writeIOMemory(REG_ADDR, REG_DATA);
}
}
else
{
blnInWrite = false // end of write cycle, is it even a cycle?
}
}
}
else
{
if (blnInRead)
{
if (REG_MREQ == 1)
{
blnInRead = false // end of read cycle
}
}
}
}
}
else if (REG_IORQ == 0) // I/O REQUESTS
{
if (REG_ADDR == PI_IOADDR_UNMAPPED)
{
// deselect PI from address space
;set GPIO_RAMDIS to LOW ; just in case it was high NOT REQUIRED?
intPIMode = PI_MODE_UNMAPPED
}
else if (REG_ADDR == PI_IOADDR_MEMORY)
{
// select PI into CPC address space in memory mode
intPIMode = PI_IOADDR_MEMORY
}
else if (REG_ADDR == PI_IOADDR_MAPPEDIO)
{
// select PI into CPC address space in mapped I/O mode
intPIMode = PI_IOADDR_MAPPEDIO
}
}
// process I/O requests based on I/O memory
processIOMemory();
}
is your pi device a co-processor/gfx card?
CPC sends commands, and then pi processes the commands?
Pi is 3v for GPIO and CPC is 5v. Are you using a voltage converter?
Quote from: arnoldemu on 19:32, 29 January 17
is your pi device a co-processor/gfx card?
CPC sends commands, and then pi processes the commands?
Pi is 3v for GPIO and CPC is 5v. Are you using a voltage converter?
Yes, 4 of them for 32 GPIOs. The PI has 40 GPIOs on the Model 3 B. I have only a Model 1 which is not enough but am waiting for a 3B to arrive. I am plugging the PI via the Voltage Levelers directly to the CPC bus to emulate memory as well as memory mapped I/O (of the PI's hardware).
Of all the CPC signals I've mapped to, what would be the next most 'useful' one that I haven't? I have one more GPIO...
https://docs.google.com/spreadsheets/d/1bS1CLDIN0jPP3GI2pCcTU7_VIf2otQ10bVm-NL0F2eQ/edit#gid=0
You must drive the datalines from the falling edge of RD or WR to the rising edge ( you can see all these timings in the z80 manual ).
BUSAK is no use without BUSRQ and strictly not needed, because you know by the next cycle it will release the bus, which may turn in handy if you cannot maintain I/O mapping at all times.
The important signals for your purpose is A15-A0, D0-D7, RD, WR, IORQ, MREQ, ROMEN, RAMDIS, ROMDIS, BUSRQ. Of course if you need no rom mapping, you can discard ROMEN and ROMDIS.
BUS_RESET and RESET is nice to have if you need to delay startup time.
RAMDIS or ROMDIS will need to be driven high to not drive data lines on RD and to not write to base memory on WR. There is probably more I forgot right now :)
I've refactored the spreadsheet so it is much more clear. I'm now debating ROMEN and ROMDIS in please of BRST & RESET - as I have exhausted all the GPIO's I reasonably have access to. 32 of them. Thanks for the falling edge tip, I'm sure I will get lots of bugs otherwise. If I don't need the RESETs, then the ROM support could be useful to emulate yet another ROMBoard, but there are really good ROMBoard solutions already :D
To time the rising and falling edges, do I need to monitor the clock? investigating... http://www.piclist.com/techref/mem/dram/slide4.html (http://www.piclist.com/techref/mem/dram/slide4.html)
Actually that explains a lot when I was wondering... how do i know when the CPU finished reading. now I know.
Quote from: zhulien on 21:24, 29 January 17
To time the rising and falling edges, do I need to monitor the clock? investigating... http://www.piclist.com/techref/mem/dram/slide4.html (http://www.piclist.com/techref/mem/dram/slide4.html)
You don't need to monitor the clock, ideally, I don't know if PI has this, what I use on the Cortex series, is edge detectors, meaning you can setup an interrupt or event for a given gpio. I am using the event in a interrupt disabled closed loop in tight assembly, because a few too many instructions will skew the timing.
Then you just issue the instruction WFE (wait for event), do your checkings and drive/read whatever lines, WFE again for the rising edge, loop.
Of course you can also just loop after driving the data lines, while ( gpio(RD/WR/ROMEN/MREQ/ETC)== 0 ) ;
I updated the logic in the previous page to cater for rising and falling clock edges. Currently i only have the original Raspberry Pi which doesn't have enough I/Os, I am waiting for the new one to arrive so can't test much really until then.
In this version, the rising and falling, for a read, I start on the falling, then finish on the rising for which the mreq stops. For a write, since both the start and end of the cycle on on the rising, does it really matter? I am guessing that as soon as the WR operation starts, the data is immediately available and it's up to me to do what i want with it quickly.
With IOREQ, are timings important for that? I would have thought as long as it's the IO port I am decoding, then it's mine.
Actually I don't need the clock, I can detect the edges of the MREQ.
Use the PI as a RTC for the CPC is on your feature list ?
Quote from: genesis8 on 23:20, 29 January 17
Use the PI as a RTC for the CPC is on your feature list ?
It is now :)
Hi Zhulien
Great news! As a big fan of the RPI and CPC, the CPC-RPI bridge is the project. Was thinking of doing something like this for a long time!
How is the bridge mounted? On the expansion bus (with additional pins) or between the CPC motherboard and the Z80?
Keep up the good work :-)
Regards,
/Ygdrazil
Quote from: zhulien on 05:16, 30 January 17
It is now :)
Expansion bus. With 40 gpios mapped for now
My pi 3b arrived so just waiting for the voltage levellers...
In the meantime some ideas I would like to consider...
Pi hardware exposed:
Hdmi FullHD
3d graphics
Audio
Mp3
Wifi
Bluetooth
Ethernet
Rtc
Sdcard
Simulated cpc hardware:
512mb Ram expansion
Memory mapped io to pi for hardware activation and control of other operations.
Can register jumpblocks to pi. Eg register an address with a target of a call that can be synchronous or asynchronous. Sync will basically loop to itself until pi is ready then pi will change the loop to a return. Async will just be a return immediately but it triggers a process. The process can be read later.. or ignored. Both cases registers are passed into the jumpblock.
Transformations. Eg... register a transformation to be triggered based on a call or mapped io. A transformation could be eg... fill memory with a sine wave xor 2 memories multiple can then be triggered by using an ldir. I wonder how much processing can be achieved in a single cpc instruction cycle?
Although i have access to 32 gpio ports 4 are on this ugly flat camera connector plastic ribbon type thing... 3 i can forego but 1 i cannot which is ramdis.
Are there ICs that eg... block a signal in a direction so i can connect ramdis that is output and and the rd signal that is always input to the same gpio? So that when the gpio is in it reads rd... but if it is out it write to ramdis? Ramdis needs to be kept high on out... so is such an ic a latch?
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 ) https://www.facebook.com/100010582416753/videos/285077698521642/ (https://www.facebook.com/whateverjulian/videos/285077698521642/)
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.
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:
https://hackaday.com/2018/05/31/reverse-emulating-nes-nintendception/ (https://hackaday.com/2018/05/31/reverse-emulating-nes-nintendception/)
The trick is explained from 11'40'' on here:
https://www.youtube.com/watch?v=ar9WRwCiSr0&t=640&authuser=1
Quote from: LambdaMikel on 19: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: https://www.youtube.com/watch?v=5YAsx11bgaw
Another similar use of a Pi, but this one uses an FPGA also.
https://hackaday.com/2022/11/13/emulate-any-isa-card-with-a-raspberry-pi-and-an-fpga/
https://www.youtube.com/watch?v=1ej76w8sHxY
Yet another 8bit computer doing much the same
https://github.com/frntc/RAD
Anyone want to put the POC together if I send you the parts I have so far?
Has all development stopped on this now?
I really hope not 😢
An accelerated CPC with a graphics board would be fantastic!
Or am I just the only one?
I wish someone would do a CPC-Next!
Quote from: Iridium+ on 12:42, 20 March 23Has all development stopped on this now?
I really hope not 😢
An accelerated CPC with a graphics board would be fantastic!
Or am I just the only one?
I wish someone would do a CPC-Next!
I hope not too. The issue is I created a basic hardware design with my very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very limited hardware knowledge based on lots of other proven similar projects - ok, there wasn't many proven at the time of conception, but here were a couple - and now there seems dozens - I tried to even hire someone to make a board, there even is a local company microbee (the computer company) that even when I had the money at that time to build a prototype board said they could, but never actually went anywhere - not from my lack of trying. Unfortuantely I'm really only a software person, a bit advanced, but there are always better programmers too. Such is life.
The circuit I designed if anyone wants to help, is online - it shouldn't take much effort, I can even send the bits i have already if you want a start at it. The original article I did find has long gone and that was using a Raspberry Pi to bitbang hardware running an emulated CPU core to pretend to be a CPU. I believe it is possible, but whether ultimately it is limited in some way is unknown on the CPC. A couple of guys mentioned RAM expansions can be fiddley on the CPC in relation to timings.
Just a note, I recommend anyone to buy a CPLink card as it is a currently existing card that allows you to plug a raspberry Pi onto the CPC. It currently works and with some more software could provide a good coprocessor foundation - of course I believe interfacing directly with the CPC could give you a sort of Amiga Vampire-like experience or Amiga PiStorm equivalent.
Hmmm,i have given a thought a lot of times in the past about a CPC accelerator too :)
The main problem is that, it's not enough just to have a faster CPU, you need also to accelerate, at least the RAM too! For example, even if you only have an emulated Z80 running 100X times faster than original, you will not see any overall speed improvement of ~10%-20% because EVERYTHING else on the CPC board, still runs at the mere 1Mhz....
With some computers like an Amiga, it's rather easy to make such an accelerator, because main cpu (MC68000) already supports a special connection with ram (the famous "Fast ram" which only cpu can access, and it's separate from the rest of the system), so having a powerful cpu and a lot of fast ram, can truly speed up things quite a lot! But, even using this kind of accelerators, since the rest of the system (and especially the circuit that controls video) is still running at the "Ancient" speeds of a few MhZ, you will see great improvement, only when executing CPU intensive code. Practically this means very fast decompression of data (which used a lot in amiga games) and great improvement in 3D games, all the rest would be the ~same.
Returning to Amstrad CPC, unfortunately this mode of operation is not available. So, it would not be so easy to create a powerful accelerator with cpu+fast ram and at the same time keep everything else in tact, in order to function properly. You see, as there is no DMA access on Amstrad CPC, and all timings are controlled by the GATE array chip, i'm afraid that you might need to "fast emulate" this chip too. Even if you design a super fast z80 with a lot of fast ram too, i doubt it would make any big difference, if you still have GA chip controlling everything at... 1Mhz ::)
I have a Terasic T-Rex which can run CPC in turbo mode at 28Mhz. If this can do it, I cannot see why another solution cannot - Think of a solution like a Raspberry Pi where the emulator has taken over 99% of the CPC when in turbo mode - but uses the CPC keyboard, perhaps CPC floppy, perhaps some other hardware plugged into the CPC with the helpers of some CPC API that exists - but when in CPC high compatability mode, it goes into use the CPC the majority of time with the real hardware running stuff. Alternatively as this project was primarily, to use the Raspberry Pi to supliment what the CPC has, some hardware created in software.
Emulating the entire system on FPGA or using rasberry pi etc, is of course the best approach to get best performance, but then, what you need the original Amstrad CPC for? You can perfectly plug a keyboard/mouse, video/audio out connectors, and you are ready to go :)
Anyway, i don't want to sound pessimist but the: "...uses the CPC keyboard, perhaps CPC floppy, perhaps some other hardware plugged into the CPC with the helpers of some CPC API that exists " concept, would be much harder to do than said. Moreover, the most critical point in such projects, i believe is the Software development! No matter how amazing a "SUPER Amstrad CPC" would sound, it would be practically useless, if there is no software that uses it.
And in order to "convince" all the people who are still involved in making software for Amstrad cpc to develop software for it, is to have a wide acceptance for the project.
As i am the creator of USIfAC/ULIfAC boards,i would say this would be the most difficult part...
I don't want to use an external keyboard
Quote from: ikonsgr on 12:36, 26 March 23Emulating the entire system on FPGA or using rasberry pi etc, is of course the best approach to get best performance, but then, what you need the original Amstrad CPC for? You can perfectly plug a keyboard/mouse, video/audio out connectors, and you are ready to go :)
Anyway, i don't want to sound pessimist but the: "...uses the CPC keyboard, perhaps CPC floppy, perhaps some other hardware plugged into the CPC with the helpers of some CPC API that exists " concept, would be much harder to do than said. Moreover, the most critical point in such projects, i believe is the Software development! No matter how amazing a "SUPER Amstrad CPC" would sound, it would be practically useless, if there is no software that uses it.
And in order to "convince" all the people who are still involved in making software for Amstrad cpc to develop software for it, is to have a wide acceptance for the project.
As i am the creator of USIfAC/ULIfAC boards,i would say this would be the most difficult part...
111% agreed! :) :) :)
Yet another pi 8-bit hardware emulator doing exactly this but for a slower system
https://youtu.be/ReTXGczq8Vk
I watched that video yesterday and I think we could learn a lot from it thanks to it being an open source project.
Another non-CPC card...
https://github.com/tjboldt/Apple2-IO-RPi
Who wants to finish this hardware for which I believe I have all the components?
More proof that the concept could / should work
https://youtu.be/zAla_RtPECE
Now that i remembered, wasn't Duke developing something like a "SUPER AMSTRAD CPC" board (that would plug onto Z80 socket) codenamed "M7" or something? What happened to this project afterall?
The core that is used in Mister would work I assume:
It is using the T80 core:
https://github.com/MiSTer-devel/Amstrad_MiSTer/tree/master/rtl/T80
From the readme:
--------------------------------------------------------------------------------
-- ****
-- T80(c) core. Attempt to finish all undocumented features and provide
-- accurate timings.
--
-- Version 351.
-- Merged Gameboy fixes from Bruno Duarte Gouveia (brNX)
-- Passes Blargg's test ROMs
--
-- Version 350.
-- Copyright (c) 2018 Sorgelig
-- Test passed: ZEXDOC, ZEXALL, Z80Full(*), Z80memptr
-- (*) Currently only SCF and CCF instructions aren't passed X/Y flags check as
-- correct implementation is still unclear.
--
-- ****
-- T80(b) core. In an effort to merge and maintain bug fixes ....
--
-- Ver 303 add undocumented DDCB and FDCB opcodes by TobiFlex 20.04.2010
-- Ver 301 parity flag is just parity for 8080, also overflow for Z80, by Sean Riddle
-- Ver 300 started tidyup.
--
-- MikeJ March 2005
-- Latest version from www.fpgaarcade.com (original www.opencores.org)
--
-- ****
-- Z80 compatible microprocessor core
--
-- Version : 0250
-- Copyright (c) 2001-2002 Daniel Wallner (jesus@opencores.org)
-- All rights reserved
Quote from: zhulien on 08:32, 04 February 17Although i have access to 32 gpio ports 4 are on this ugly flat camera connector plastic ribbon type thing... 3 i can forego but 1 i cannot which is ramdis.
Are there ICs that eg... block a signal in a direction so i can connect ramdis that is output and and the rd signal that is always input to the same gpio? So that when the gpio is in it reads rd... but if it is out it write to ramdis? Ramdis needs to be kept high on out... so is such an ic a latch?
First of all you need compareable signals. So it needs to be either both control (with same logic) or both data.
So you could potentially pair read and write. This can be done similar what UPDI does.
UPDI is a serial protocol that uses a single line for read and write. It uses a diode and a resistor to separate read from write traffic. However you need to ensure (protocol level) that read and write never can occure concurrently. But that is true for the CPU anyhow.
https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md
Another way would be to use the ~WR line, a tri-state buffer and an OR gate.
Screenshot 2023-10-25 133405.png
If ~WR is high, the tristate will enable the signal from ~RD to get to your GPIO PIN, The signal from ~RAMDIS will never get to the PI. Also if ~WR is high One of the input of the OR gate is high, resulting in ~RAMDIS high, regardless of what happens to the other input (actually the Output from the tristate buffer.
If ~WR is low the tristate is going to high impedance (actually floating) and whatever is on the GPIO PIN is getting to the OR gate. The OR gate however is having one pin tied to low, so the output is just reflecting what the other input is doing.
So ~WR acts like an enablement for whatever the other line is doing.
However, this does not preserve any state. So for instance you cannot set RAMDIS and then try to read anything. Because as soon as you activate the tristate, ~RAMDIS will become high and RAM is enabled again.
I am not sure if that is matching your question, but that is normally how you solve those issues.
If you need state, you need to put a FlipFlop to the position of the OR gate. The flipflop can be activated on low clock (e.g. still the ~WR signal) and then outputs whatever you have written to it until you change it again.
i will have to read that again :) but thanks for the reply. I understand the concurrent nature - so even if i could use it for both input and output, it wouldn't be at the same time exactly - i will need to have a think abou tthat.
I made a mistake in the above diagram.
RAMDIS is actually active high. The reason for that is, that the RAM (as well as ROM) has an ~OE signal that activates the RAM/ROM with active low.
For the ROM ~OE is directly connected to a pulldown resistor (so it is always low if nothing else drives it) and for RAM it is going through an OR gate. One half is coming from the GA and the other part is coming from the RAMDIS signale from the expansion port.
In the schematic below you can see how ROMDIS works with the internal ROM chip. Normally the Output Enable (~OE) it is enabled via the pulldown Resistor R112 as it is an active low signal. Then the GateArray defines if it be active with the chip select (~CS) signal and only if both are low, the ROM actually outputs data to the Bus.
Screenshot 2023-11-02 092007.jpg
If an external ROM is getting selected it actually drives ROMDIS high, which subsequently disables the output of the rom.
It works similar with the internal RAM. However as the RAM does need to be enabled all the time for the video display, here it is separated from the CPU via a latch (IC114). And the output enable (~OE) line is also connected to the Gatearray and the RAMDIS line from the expansion port. That is an OR gate (IC112) that works the same way as in the diagram I posted above.
Screenshot 2023-11-02 092629.png
One input is connected to RAMDIS of the expansion port and is also pulled down via R124 to low. The other signal is coming from the GateArray.
If nothing is connected to the expansion port this OR gate has one line always 0, so the output will represent directly what the GateArray outputs on ~RAMRD signal.
If you have an external RAM card (and do not have any other logic in it), the card can pull up RAMDIS, so the data from the internal RAM will never reach the CPU, instead any read will go to your external RAM card and writes will go to both.