Archimedes podule two port ram -> RPI

Hello, I found the very interesting articles on Podules designing from Theodore Markettos (http://www.markettos.org.uk/riscos/podules/), and I decided to design a real Podule card, using also a HIGH SPEED 7130SA/LA 1K X 8 DUAL-PORT 7140SA/LA STATIC SRAM to act as a memory buffer between the A440 and the RPI, with this configuration, any two computers can write/read the memory in an asynchronous way (even if some handshaking are setup using L_int and R_Int signals from the IDT7130 device. By doing this, I don’t need anymore the AKA10 interface to be present for the 1Mhz BUS operation.

I have created a GitHub entry for this project, a first draft of the schematic is available as a png image, next files will follow shrortly
https://github.com/alow2004/Archimedes_ … /tree/main

Hello, i uploaded new version of schematics and first printouts of the PCB (Top, Bottom and placement layer). I will verify complete board, then upload Kicad files as next step. After verification complete, I will order some samples of the print and begin construction.

Your link seems to be broken, I think you mean https://github.com/alow2004/Archimedes_RPI_DoublePort_RAM_Podule

I started designing something similar during lockdown but never had time to finish. Your setup looks good – pretty similar to what I was thinking of. I think it was the same family of IDT dual port RAM chips. Your design looks sensible.

Are you using the Pi’s Second Memory Interface (SMI), which gives you an interface that looks a lot like the SRAM interface? The SMI pinout looks a little different to yours – 18 data bits but fewer address bits. Lack of address bits means you may need to bank-switch the SRAM, but the whole thing happens in hardware, whereas I think with your setup you’re driving the cycle from GPIO software (set address, set data, toggle write line, unset data, unset address) which will be much slower. There’s not a lot of documentation on SMI but various articles have figured it out, eg this one

One other trick is that if you can arrange the SRAM to take up the bottom chunk of podule space, you can software define the expansion card ID register that lives at address 0. If the Pi sets this up ahead of time, you can appear to the Archimedes as any kind of podule because the ID register is software defined. Everything else is then just a matter of Pi software. The Pi software would also have to include in this the interrupt status bits, but it’s generating those so that’s doable.

By controlling the bottom part of podule space, you can present a podule ROM to the system, and you can thus cause arbitrary software to be loaded into the A440 at boot time. So if you need to load drivers for your hardware, you can push them through this interface. You will probably need to provide a podule loader routine to tell the Pi how to page a larger ROM size within the small address space window you have available, but that’s not too complicated once the communication is established. The only downside to this approach is that modules loaded from a podule ROM take up system RAM, so you don’t save any RAM over loading them from disc – to do that you’d need to build your own OS ROM (Stardot has a project for that).

For the record, I don’t see why this design won’t work on a Risc PC too – it won’t use the extra capabilities of the Risc PC but that probably doesn’t matter given Pi GPIO performance.

Hello, very glad to see YOU giving tips on my project :-) I was effectively very happy to read your articles about podule working. Like you noticed, my approach is very simple as I don’t use the SMI approach (lack of knowledge in this area) so the process will be much like you described. I though of sharing the memory also for podule id&config reading, but I was afraid to have booting problem due to the fact that then, ARM needs to wait that the RPI has finished booting AND put information into the shared ram (but maybe I’m wrong).
You are right, the GitHub url is not correct, you gave the correct one: https://github.com/alow2004/Archimedes_RPI_DoublePort_RAM_Podule
It should work on a riscpc I think (I don’t have one :-). I am waiting for a first batch of PCB for this first implementation, if you want, I can send you one board.
Would you like to help me a bit on the software side also to create the ‘bridge’ software on ARM or RPI side ? I already though of a communication ‘protocol’ between the ARM and RPI, I will also put my ideas about it in the GitHub space

At present I don’t have a working machine with a podulebus, so not sure it would be much use sending me one.

On the software side, what help do you need? I don’t have time to write code but I’m happy to answer questions.

I think the first thing I’d do is get some code to successfully read and write the SRAM from the Pi.

Then inspect the SRAM from the A440. Use *Memory as a quick and dirty way to do it – eg I think *Memory 3240000 is podule 0 with 2MHz IOC cycles, &3340000 is 8MHz IOC cycles, &3244000 is podule 1 at 2MHz, &3248000 podule 2, etc.

Once you have communication working you need software at both ends to use the SRAM as a mailbox to communicate. You’d need a driver for each type of communication, eg one for storage, one for networking, etc.

As to the shared memory protocol that’s up to you… write some data into the SRAM and triggering an interrupt at the other side would be the traditional way to do it.

VirtIO is a way that hypervisors do this kind of thing. Maybe there are some lessons to learn there, although they typically have much more RAM to play with – here you only have ~2KiB visible at a time, so ideas about handing around memory pages from host to VM don’t really apply here.

Edit: just seen the notes you committed a few minutes ago. I think I would suggest using a message-based interface, rather than reserving precious SRAM for fields which aren’t always updated. In other words, rather than laying out the SRAM with a static map (bytes N/N+1 are mouse X, etc), have one end generate a message that’s ‘Mouse pointer moved’ and have something at the other end interpret and acknowledge it.

While a static map would be ok as a starting point, you’re still going to need something at the other end to receive it and signal that it’s done so – and especially for any buffered input (eg keyboard). Reserve a few bytes for message header fields and then use the rest of the SRAM for the payload (it looks like you only have 1KiB, which isn’t much).

you’re still going to need something at the other end to receive it and signal that it’s done so

Maybe some lessons from how the Tube worked?

Isn’t it rather limiting to only have two bytes for the SWI number? Loads of SWIs would be inaccessible (for example in the 40xxx range: Wimp, MIDI, ColourTrans, Debugger, FileCore, Draw, Podule…) and you couldn’t specify any X-form OS SWI (for example XOS_Module is &2001E).

Maybe some lessons from how the Tube worked?

Possibly, although that was a FIFO and this is shared memory.

The other example I was thinking of was the Pi’s mailbox property interface: you have two sides communicating via shared memory and ‘doorbells’ to tell the other side that there’s a message for it.

Your’e right , a message based interface will be more efficient due to the limited memory buffer I dispose, I will review this part, good point also regarding the SWI number, but message based protocol will change that also.I will effectively begin simply by checking that reading and writing from each side is ok, then I will also check the interrupt generation from the IDT chip triggered by writing at a specific address, and released by reading at another address. If I encounter problems, I will definitely come back to ask some help :-)
Thanks for your advices!

If the messaging was based on something like the machine to machine messaging in ZeroMQ then you’d end up with,potentially, the ability to put several machines around your local network and not just one internal to the RPC case.

One further thought questioning your original assumptions… why have you gone for a 1KiB SRAM? Podule space gives you 4KiB of 8-bit wide address space, or 8KiB of 16-bit wide space. Even if you don’t want to use the lower half of the address space to implement podule ROMs and such, you could still have 2KiB.

Sizes of things that might be relevant here:
512 bytes: IDE disc block
1518 bytes: Ethernet packet
2048 bytes: CD disc block

There’s nothing to stop you splitting a transaction into multiple pieces, but it’s quicker and a lot easier to send something in one go.

Yes again, you’re perfectly right. But I wanted to begin with something easy to setup on electronic level, that’s why the IDT 7130, despite its low memory size was a perfect beginning development. However, I also already checked there is also another chip IDT 7024 that is 4K * 16 bits wide that should fit very well in a design, but it’s a big 86 pins package (or IDT 7025 8k * 16 bits 100pins…) so will require some more work to design. But it will be probably a next level version. Let’s just begin with the simple one, after, given the acquired experience, I will maybe step to the other.

Hello, i have a question (probably for @Theo…), the podule connector allows address A2 to A15, however, when accessing podule (in byte mode), max memory space allowed is 4K (up to A13), can I still send a full address (A2-A15) and still have the /PS active ? (my idea is to use A15 by e.g. to generate an INT for RPI side ?

Something like A15 & /PS & /WR = INT for RPI …

You would have to check the schematics, which could change behaviour between machines, but A13-A15 give the podule slot number, ie &0 is podule 0, &4000 is podule 1, &C000 is podule 3, etc. While you might be able to steal their address space if you don’t have them, the /PS strobe is only decoded for your physical slot, and that has critical timing information so you can’t generate it just from the address.

I understand that the four modules are addressed effectively by A14,15 (wich give 4 podules), I suppose A13 is not accounted into that ? or maybe riscpc machines had possibilities to have 8 slots ?

By the way, there is also a signal /EXTPS available on the podule connector, do you know how to use it as apparently it’s an External Podule Select signal ? (reported as /S7 on the podule backplane…)

After some research, I saw that the /ST signal (labelled /EXTPS on the podule connector) is directly linked to the IOC chip, where I also found that the /S6 signal was even not used.
I suppose that, by handling correct configuration of the IOC, I could be capable of driving those signals high or low. I will try to find some documentation on the IOC chip, I suppose some registers there are used to activate those lines…

I received the first versions of the board this week, so I put some pictures of them on the GitHub space for the one that are curious… ;-)

Oh my god, hand soldering SMCs. 😱

At least they’re not Ball Grid Array components…

I confirm, I pushed my soldering capacities to the max. I don’t think I can do much smaller… :-)
Firsts tests seems to be ok, I just have to change BUSY line on ARM side tied to VCC and add inverter logic for the OE signal (level converters are using positive OE signals, while IDT 7130 is using negative logic (GND), but inverters are already available on the board so it’s a little adjustment…
I’m currently writing the first tests and functions (in c) for testing the board on RPI side. I will do ARM side later, with the help of David Feugey I hope… ;-)

Excellent – Kudos to Alain!

I had been considering a project along these lines, mainly due to the lack of good options for replacement hard drives for the Archimedes and RPC, so the plan was to use some of the Raspberry Pi’s (Zero 2 W) micro SD card for storage (with the possibility of also piggy-backing on the Pi’s linux network stack and the USB port). However work pressure, the lack of documentation on the SMI and the lack of Raspberry Pi Zero 2 W’s meant I never got further than thinking about it. I am really glad someone has made some practical progress!

I like Theo’s idea about using the shared ram to supply the drivers, but that may not be practical if the PiDrive was the boot drive. Perhaps have a small bootstrap EEPROM and the majority of the drivers/software supplied by the Pi?

The place where I was planning to start was to get two Raspberry Pis to pass messages between each other via shared memory so that I could understand the SMI interface, which would require much less soldering. I did my degree in electronics, and used to teach it, but I have been masquerading as a computer scientist for the last 25 years, so I have forgotten most of it (or at least it is mostly cache misses), so I would like to get back to some electronics at some point.

I used to have an Atomwide(?) APEC podule for interfacing experiments, but there doesn’t seem any information about it anymore – does anyone know of anything similar (for the RiscPC)? I will read the Archive article – sounds a good place for me to start.

As is already spoke with David Feugey, I already have 10 prototype boards, when I have finished the firsts tests, if someone want a board, just tell me, I will send it to you (just the board, I don’t have components for everyone! :-) ) for free (well, maybe the sending cost but it’s just a letter after all…)
There are already some bugs that I checked on the board, but nothing really difficult to fix.

By the way, the board also contains a serial eeprom that can be selected linked to the rpi if people wants to use it as HAT descriptor, or configured to be used by the ARM side on it’s I2C lines. Maybe some software can be stored there for the drivers…

I would very much like to have a board when you are satisfied with the initial testing – I would still like to work on this as time and energy become available.

Ok Gavin, i will send you a board when I finish testing mine, I hope to have enough time to finish it before end of the month, but I need to have your address for sending, how can we proceed on this site ?