Multi-purpose podule with a Raspberry Pi

[myelin]

An idea I've been batting around for a while, after acquiring an A3000 and reading all the threads about IDE and networking podules, is to make a simple podule (well, mini-podule) that contains a flash chip, a CPLD, and a header for a Raspberry Pi.

The mini-podule interface has 35 pins, and we want most of them (everything except CLK2 and C0, C1, AFAICT). This leaves 20 pins free on an XC9572XL-xxVQG64, which should be plenty for the Pi's IO.

This should be pretty flexible -- the CPLD can buffer communications between the A3000 and the Pi, so the Pi can just run Linux and doesn't need something realtime like PiTubeDirect. I've read that TTL levels are OK on the podule/IOC interface, so this would hopefully allow the CPLD to do all the level shifting, resulting in a fairly sparse board.

Have I missed anything here? This feels like it shouldn't be a particular hard project, and while it's very much not authentic, it might be a nice gap filler for those of us who would like both a hard drive and networking in our machines. It could potentially provide fast SD card access, large amounts of buffer RAM, networking, USB etc. I'm hoping that it should be possible to modify RPCEmu's (ArcEm's?) HostFS module to communicate with the podule, or to make a native implementation of the ArcEm_HostFS SWI that passes the request to the Pi, to get an easy filesystem implementation.

Throwing this out here for feedback!

[danielj]

I think it sounds like an excellent idea!

[flaxcottage]

This sounds excellent - I think.

BITD I thought I understood electronics but now everyone talks way above my head.

[marcusjambler]

Can someone please clear up what the difference is between this project and the RPI module available on ebay from time to time

https://www.ebay.co.uk/itm/PiPOD-Ultra- ... Sw44BYIksn

[Phlamethrower]

With the PiPOD there's no electrical connection between the Pi and the "host" computer (except possibly power?). All the communication between the two is via ethernet. I'm not sure what the software is like - the PiPOD falls into the "completely pointless" category for me. It's essentially the equivalent of buying a sports car and then supergluing it to the inside of a truck.

meylin's idea is for all the communication between the host & Pi to be via the podule interface, similar to Pi-based coprocessors on the beeb. This will result in much tighter integration with the host, including the potential for it to be used to emulate existing IDE/network/etc. podules. But I'm not sure whether that's part of myelin's plan or whether it'll just present a completely custom interface to the host (at which point, I'd rather just use the Pi directly and run an Archimedes emulator on it - but I know you lot are more attached to your old hardware than I am )

[marcusjambler]

the PiPOD falls into the "completely pointless" category for me. It's essentially the equivalent of buying a sports car and then supergluing it to the inside of a truck.

That is the impression I had also

Thanks for the explanation phlamethrower.

[RobC]

I think the idea with PiPod is to use VNC to have the RiscPC desktop appear on the Pi under RO5. I suppose it fulfils a purpose for those who still want to use their RiscPCs but also want HDMI, USB etc.

[myelin]

meylin's idea is for all the communication between the host & Pi to be via the podule interface, similar to Pi-based coprocessors on the beeb. This will result in much tighter integration with the host, including the potential for it to be used to emulate existing IDE/network/etc. podules. But I'm not sure whether that's part of myelin's plan or whether it'll just present a completely custom interface to the host (at which point, I'd rather just use the Pi directly and run an Archimedes emulator on it - but I know you lot are more attached to your old hardware than I am )

The plan right now is to just present whatever interface I can implement in the little CPLD... initially something completely custom, just a small FIFO in either direction, with some sort of framing over the top that I can use to pass ArcEm_HostFS SWI data. That minimizes the software work because I can just run an Archmedes emulator's filesystem code on the Pi, and you get a 16GB hard drive.

I'm unlikely to want to implement this myself, but it would also be possible to modify PiTubeDirect to handle all the I/O, which might make it possible to emulate other podules. No Linux though, so I don't know how easy it would be to perform network operations. If bare-metal Pi code can perform network operations, access the SD card, and access the USB ports, this might be a really good option though.

Another option would be to put an FPGA and some buffers on there instead, which would allow much more flexibility, although I'm unlikely to have the time to make such a PCB any time soon

[myelin]

It looks like Circle (bare-metal Pi programming environment) has network, USB, and SD card drivers, plus some other possibly useful bits and pieces, so the approach of using the CPLD as a level shifter and doing everything in the Pi may actually work, as long as the drivers for current podules use slow-enough accesses.

Access-wise I imagine fast IOC reads are the worst. Timings are:

- MEMC accesses: flexible; the CPLD can stretch them out.
- Slow read: about 187.5ns from /PS to /PRE, data must be ready about 312.5 ns from /PRE
- Medium read: about 62.5 ns from /PS to /PRE, data must be ready about 312.5 ns from /PRE
- Fast read: about 62.5 ns from /PS to /PRE, data must be ready about 187.5 ns from /PRE

A more reliable thing to do would be to put an FPGA on board that's big enough to emulate whatever we're trying to do. I'd probably go for something in the Lattice MachXO2 series, because they have a nice range of cheap pin-compatible chips that would be easy to mix and match depending on requirements.