Z80Tube. Running Acorn Co-Processors on the Amstrad CPC

[revaldinho]

Time to announce a new project which has reached the prototype stage: Z80Tube - bringing the Acorn BBC Micro Second Processors to the Amstrad CPC.



As you may know, the Acorn BBC Microcomputer series slightly predates the CPC464 but both the original and updated models were sold in parallel for many years. Unusually,  the BBC micro was originally designed as a front-end terminal (the Proton) servicing a more powerful co-processor rather than as a complete computer in its own right. When the Proton was re-purposed as the BBC Micro it retained the hardware interface - the Tube - to an external co-processor board. The tube interface is basically a subset of the 6502 bus signals with a dedicated connector on the computer coupled with  Acorn's own Tube IC (a Ferranti ULA) sitting on this bus in each of the external coprocessor cards. The Tube IC implements multiple FIFO buffers in both directions for data transfer between host and client (aka parasite) CPUs.


Back in the day many different co-processors were available for the BBC. There were high speed 6502s, a Z80 opening up the world of CP/M, the NS16032 (aka 32016!) for super-computing, the 80186 for running DOS and later even the original ARM processor itself was first implemented as second processor card. These second processor modules are hard to find today and some are still relatively unaffordable, but that doesn't matter because now we have the most excellent PiTubeDirect project instead.


PiTubeDirect is a bare metal code project which provides pretty much all of the original second processors running at much higher speeds than the original for just the cost of a RaspberryPi. The 6502 second processor runs at around 350MHz on an RPI 3A+, but even the humble £5 Pi Zero can run rings around any of the original processors. The compelling feature of PiTubeDirect is that the Pi not only emulates the second processor, it also emulates the Tube IC and its physical interface. By bit-banging out the 6502 bus protocol on its GPIO pins in real-time the Pi can be physically plugged into the Tube interface of a real BBC micro with just an inexpensive level shifter to deal with the electrical interface.  It is to all intents and purposes a direct hardware replacement for any and all of the original second processor modules, and indeed the PiTubeDirect project provides new CPU emulations which were never previously available including our own OPC Series RISC processors.


We want to bring these Acorn second processor modules to the Amstrad, both in their original form and the PiTubeDirect implementation.


The job is in two parts - a hardware interface to let us plug the co-processor boards into the CPC and then some host software running on the CPC to service all of the second processor's operating system requirements. 


At this point in the project we have a working hardware interface and some very basic (actually BASIC) host processor code.


The interface card was designed for this application but it has a number of features which make it reconfigurable to be useful for future projects.



The key features are

   
• 84 Pin PLCC socket accepts Xilinx XC9572-PC84 or XC95108-PC84 CPLDs
• IO voltage switchable between 5V and 3V3 (5V tolerant)
• On board 3V3 regulator with option to use external 3V3 supply
• 50 way MX4 Compatible CPC connector
• 12 way Digilent PMOD compatible connector
• 40 way RaspberryPi Compatible connector

It could be configured as a simple CPC-GPIO card for control applications.


It could also be configured as a generic CPC-RaspberryPi bridge card with FIFO logic and level shifting inside the CPLD. allowing a RaspberryPi running a standard Linux to provide mass storage, networking or other features to a CPC.


Those and other ideas are all for later, or for other developers maybe.


For the Z80Tube application the CPLD is programmed to provide a very simple on-the-fly translation from the CPC's Z80 bus to the Tube's 6502 bus, with a little remapping of the addresses to place the Tube registers at some convenient location in the CPC IO address space. That's not anything second processor specific in itself - you could use the card in this configuration just to hang any 6502 family peripherals on the back of the CPC but that's all we need to connect to a second processor card. And on the host computer side of things, the card is only CPC specific because of the MX4 connector and the address mapping - a minor change in the address mapping code and a different connector would let the card bring those second processor modules to MSX, Spectrum, Memotech and other Z80 computers too.

Since the PiTubeDirect is the most readily available second processor implementation the 40 way connector has been arranged so that a RaspberryPi will plug in directly (and can be firmly mounted on the back with screws); the CPLD deals with all the electrical level shifting as well as the bus protocol.  A real Acorn cheese wedge will work too but needs a cable adapter to re-organise the pins a bit.


The CPLD code for the Z80-6502 translation is relatively simple and in fact was up and running in our very first hardware debug session.


The software for this project is the more challenging part. The second processor is expecting the host to service all keyboard, screen, disk and IO routines and to deal with all command line input as if it were in an Acorn BBC Micro. As it happens the Amstrad CPC provides very similar capabilities to the Acorn machine  - the same CRTC, similar video modes, similar firmware organisation and so on. Some OS calls can be mapped directly; others will need a bit more adaptation. We've only just started looking at this but already we have enough code to boot the OPC7 Second Processor into its monitor program, run commands to dump and disassemble memory and load and run simple OPC7 test programs from CPC disks.


Currently we're prototyping the host software in Locomotive BASIC. This is quite a fun retro-computing environment, but it's not fast. When we've got a reference version of the host software up and running a port to C (SDCC) or BCPL or just directly to assembler is on the cards. 


So that's where we are at the moment: hardware working well and proof of concept level of software. Some photos attached show the hardware card and some screenshots of the OPC7 monitor program running and calculating of Pi and E to very many digits (very quickly) using the co-processor.


As usual the entire project is open source, licensed under the GPL3 and hosted on GitHub: https://github.com/revaldinho/z80tube


If you are interested in getting hold of a card, either to follow or contribute to the development of the Tube host software or to use it for other purposes - there is another thread here asking specifically about CPC-RaspberryPi bridge cards for example - then get in touch. I have a few PCBs from the initial batch which I can build up but I would need to get hold of some more CPLDs for which there is a lead time of a few weeks.


Rev.  (with thanks to @biged and Stardot.org.uk's Hoglet for helping get this project off the ground and lots of technical input particularly on the host software side of things)

[LambdaMikel]

Another mind-boggling project from you, @revaldinho   

It could be configured as a simple CPC-GPIO card for control applications.

@zhulien's idea was also to have it emulate RAM / ROM / ... and GPIO. And my impression / suspicion was that without a "custom firmware", even the RPi 3B+ would not be fast enough for that (I mean, Linux in terminal mode with C program - certainly not with Python... and without pulling ~READY waitstates of the Z80 of course  )


Of course, for GPIO or so, that's a different story. Can you comment on this please? Thanks

[revaldinho]

@zhulien's idea was also to have it emulate RAM / ROM / ... and GPIO. And my impression / suspicion was that without a "custom firmware", even the RPi 3B+ would not be fast enough for that (I mean, Linux in terminal mode with C program - certainly not with Python... and without pulling ~READY waitstates of the Z80 of course  )
Of course, for GPIO or so, that's a different story. Can you comment on this please? Thanks

Those all sound like bare-metal applications running on the PI and using the interface card as just a level shifter.


Emulating ROM is probably ok. After all that's how Duke's M4 card works using a much less powerful CPU than the one in the RaspberryPi. In fact I've also done a CPC ROM emulator using an ARM based Teensy3.6 microcontroller . Code for that is lurking in my GitHub repo under the CPIC project name (CPIC because I started off on an 80MHz PIC32 which was ok for servicing IO transactions, but not quite up to dealing with the ROM accesses themselves). PiTubeDirect itself is a bare-metal app listening to and bit banging GPIOs on a 6502 bus of course.


Emulating expansion RAM is much more tricky, maybe not doable and probably not worthwhile. There are plenty of RAM cards about particularly for the 6128 where amongst others my Old School card is very cheap to build and not much more to buy ready made (and not necessarily from me either - check eBay).


But bare metal apps aren't making the most of the CPLD on the card.


I was really thinking that if you wanted to do a Pi project then the thing to do would be to take a leaf out of Acorn's book. Configuring the CPLD as a set of FIFOs in both directions (you have up to 108 macrocells in an XC95108 device) and the CPLD would deal with all critical timing and both CPC and Pi could write and read the FIFOs at their leisure using polling or interrupts to check for FIFO data. Removing timing criticality from the Pi opens up the possiblity of running a full Linux with access to the CPC via Python or any other language and providing very high level access to features like networking or serial comms or mass storage etc.




R

[LambdaMikel]

Those all sound like bare-metal applications running on the PI and using the interface card as just a level shifter.

Yes, right?

Emulating ROM is probably ok. After all that's how Duke's M4 card works using a much less powerful CPU than the one in the RaspberryPi. In fact I've also done a CPC ROM emulator using an ARM based Teensy3.6 microcontroller . Code for that is lurking in my GitHub repo under the CPIC project name (CPIC because I started off on an 80MHz PIC32 which was ok for servicing IO transactions, but not quite up to dealing with the ROM accesses themselves). PiTubeDirect itself is a bare-metal app listening to and bit banging GPIOs on a 6502 bus of course.

I don't doubt that this is possible with the RPi 3B+, but not with Linux + C running on the RPi. I guess you will need your own custom firmware, written in bare metal ARM, and zero OS basically.

Emulating expansion RAM is much more tricky, maybe not doable and probably not worthwhile. There are plenty of RAM cards about particularly for the 6128 where amongst others my Old School card is very cheap to build and not much more to buy ready made (and not necessarily from me either - check eBay).

I guess @zhulien 's idea was also that the RAM content can basically be "computed". Which of course requires more than just maintaining a big CPC-addressed byte array in the RPi, if you want the RPi do some computation of the memory *while* it is being presented to the CPC at the same time. At least that's how I understood it.

His idea also was to ONLY do this with the RPi, no CPLD... hence, no buffering or the like, and the RPi is directly connected to the buses (maybe with tri-state able level shifters)  Of course, that requires very delicate timing then in order to avoid bus contention etc.

I was really thinking that if you wanted to do a Pi project then the thing to do would be to take a leaf out of Acorn's book. Configuring the CPLD as a set of FIFOs in both directions (you have up to 108 macrocells in an XC95108 device) and the CPLD would deal with all critical timing and both CPC and Pi could write and read the FIFOs at their leisure using polling or interrupts to check for FIFO data. Removing timing criticality from the Pi opens up the possiblity of running a full Linux with access to the CPC via Python or any other language and providing very high level access to features like networking or serial comms or mass storage etc.

A great idea for sure! It am not quite sure how one could run / delegate "tasks" on the second (emulated) CPU though. Somehow, you will need some kind of high-level protocol then, to write OP codes to the tube's CPU, and then it can process these tasks independently? Can the tupe CPU also access the CPC memory for shared memory communication?

LS

[LambdaMikel]

A great idea for sure! It am not quite sure how one could run / delegate "tasks" on the second (emulated) CPU though. Somehow, you will need some kind of high-level protocol then, to write OP codes to the tube's CPU, and then it can process these tasks independently? Can the tupe CPU also access the CPC memory for shared memory communication?

Should have read more thoroughly... I guess you already explained that.

The software for this project is the more challenging part. The second processor is expecting the host to service all keyboard, screen, disk and IO routines and to deal with all command line input as if it were in an Acorn BBC Micro. As it happens the Amstrad CPC provides very similar capabilities to the Acorn machine  - the same CRTC, similar video modes, similar firmware organisation and so on. Some OS calls can be mapped directly; others will need a bit more adaptation. We've only just started looking at this but already we have enough code to boot the OPC7 Second Processor into its monitor program, run commands to dump and disassemble memory and load and run simple OPC7 test programs from CPC disks.

So, the program in the screenshot shown is computing "e" "autonomously" on the second CPU, and the result can be retrieved via IO / buffers, from the CPC side using "OPC7" software running on the CPC (maybe RSX extensions - currently BASIC?)

That would mean there is no shared memory between the 2 CPUs, and data has to be moved. Right?

[GUNHED]

Shared memory is great. A wonder would be to have a DMA being able to access the first 64 KB of the CPC, so to copy data from outside very quick into the V-RAM. Just dreaming, that's probably not possible.

[revaldinho]

So, the program in the screenshot shown is computing "e" "autonomously" on the second CPU, and the result can be retrieved via IO / buffers, from the CPC side using "OPC7" software running on the CPC (maybe RSX extensions - currently BASIC?) [size=0px]That would mean there is no shared memory between the 2 CPUs, and data has to be moved. Right?
[/size]

Yes, that's pretty much it. The Tube is a message passing interface so you were spot on with your earlier comment that both host and client need to be running software, perhaps interrupt driven, which is handling and acting on the messages - the tube protocol.


The BASIC running on the CPC is the host code and at this early stage it's just looping endlessly and dealing with messages from the keyboard or the client and fulfilling client requests, for example the 'LOAD FILENAME' command or simply writing to screen. So the screenshot shows the CPC running this host code program, uploading OPC7 code to the client, having the client disassemble or dump its own memory to screen (back on the CPC) and of course running those little maths benchmarks.


R

[LambdaMikel]

Thanks for explanation!
Very cool -  looking forward to that Mandelbrot ( Appleman ) fractal program that I saw on the C64 in the 80s that used the 1541 floppy as copro running on the CPC    Should be possible with the tube, right?  Do you have a name for it? AmsTube?    Well, I guess Z80Tube is fine 



The ability to have a fully programmable, general purpose and fast computer at the end of the CPC that can "do anything" is very attractive. I could see to use this, for example, as a Wifi printer connector, or give the CPC internet access, or MIDI, or or or. Basically, everything that is easy to do on a RPi can be done with the CPC over the Tube then, right? Whereas there are some devices that offer some of this functionality (M4, Galaxy Board, ...), none of them are programmable and "open" or general purpose. That will be a great device for anybody that wants to do hardware tinkering with the CPC also (home automation, speech recognition, ... of course, all the challenging computations will be performed by the RPi, but who cares, it is the interface and ability to process this with the CPC over the Tube that counts)

[zhulien]

BBC Tube on CPC would be awesome... having full blown linux allows for a cool crosscompiling machine directly within the CPC

[LambdaMikel]

BBC Tube on CPC would be awesome... having full blown linux allows for a cool crosscompiling machine directly within the CPC

Btw, are you still pursuing your project, @zhulien ?
Your idea was a bit different, but also way harder to realize from a timing and CPU horse power point of view (if feasible at all).

[zhulien]

Yes still but I am not so much a hardware guy.  I can solder my circuit if you think it might work? I dont want to hijack this thread.

[revaldinho]

Yes still but I am not so much a hardware guy.  I can solder my circuit if you think it might work? I dont want to hijack this thread.

Since there seems perhaps more interest in using the Z80Tube card as a generic interface to a Pi running Linux, I will have a look at making a code for the CPLD which can support both the Acorn Second Processor interface and a FIFO mode. I think this can be done, although probably only in the larger XC95108 type CPLD.


I've put some notes on how a simple FIFO mode might work on the Github repo here:


Z80TubeFIFOSpecification.pdf


R

[Lardo Boffin]

New to the forum so apologies for bumping this one. Did this project get anywhere? It looks very interesting!

[revaldinho]

New to the forum so apologies for bumping this one. Did this project get anywhere? It looks very interesting!

Yes, this project is still a thing although it's stalled a bit. The hardware is all working but so far the host software is written in BASIC and only enough to demo the PiTubeDirect running the OPC processors (snaps earlier in the thread). It's on the to-do list to expand the host software, probably using C (via SDCC/CPCTelera) now, but I haven't got around to that yet.


There was more interest in a generic interface to a RaspberryPi rather than an Acorn specific one, so I started to write a new firmware for the Z80Tube board to make a simple FIFO interface but at the back of my mind I knew that this was always going to be an expensive board to build as the XC9572/108-PC84 CPLDs are getting very difficult to get hold of now. So, I looked for an alternative solution and came up with a different board design - CPC-CPlink - which is very much an active project. The new board uses no CPLDs or other programmable components so is much cheaper to build and actually has deeper FIFOs than I'd have been able to fit in an XC95XX device. There's a separate thread about the new board here: http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/cpc-cplink-a-coprocessor-interface-card-for-all-cpcs/