Archimedes podule two port ram -> RPI

Thanks Alain, that’s great, my email address is g.cawley at uea dot ac dot uk There is no rush from my perspective as I will be very busy with teaching until December.

I will do ARM side later, with the help of David Feugey I hope… ;-)

Yep, that’s an interesting project that raises some exciting ideas in my brain :) Not really on the low level side (I’m not good enough for this) but on some higher level drivers.

Hello, some updates on the project. My first tests on rpi side where positive, I can read and write without problems to the memory. But, in between, I took into account the remarks of many people here regarding this project, and I decided to upgrade the double port memory to a 4K * 8 bits double port RAM (IDT 7134). I removed also the circuitry for the podule identification step, because it will be handled at startup by the RPI (like proposed by Theo). In this configuration, RPI will handle the /Reset line from the Archimedes until the correct t podule id is stored into address 00 of Memory, then release the /reset line, allowing the ARM to boot normally and pickup the podule id… (of course, this need to be checked when I receive the new boards (I expect them next week)
But disposing of 4k will greatly enhance the capabilities of the card when handling traffic such as Econet, discs, or what else…
The new board schematics and documentation (not complete) is available on my Github url: https://github.com/alow2004/Archimedes_RPI_DoublePort_RAM_Podule

Excellent!

Ok, so, version with 4k ram is mounted, RPI side was tested for R/W. Gavin, how can I have your address if you want to receive a board ?
I think David (Feugey) has some interesting proposals on how to write a driver for that. On my side, I just have written some I/O tests on
RPI side to check it’s working ok. I will update my gitlab space with the code also.

I have a question regarding the /Reset line of ARC machines: for this project, during the boot process of an Acorn ARM computer, the device checks for the presence of podules plugged into the backplane. To be detected, a podule needs at least to provide basic
information at startup by setting up a specific byte at address 0 of the podule space at booting
phase. Because of the minimal electronic interface option chosen, the IDT 7134 double port ram needs to
contain this information at startup. For this purpose, during initialization phase of the RPI SBC (remember that the board is switched on at the same time as the Acorn computer), the /reset line of the ARM computer is maintained low until RPI has written the starting byte into address 0 of
the SRAM. When done, /reset line is released and Acorn machine is allowed to boot. During the process, the machine will retrieve the byte written at address 0 and configure the podule properly.

But actually, I have trouble when releasing the reset line from RPI side, is there any time criticality to follow ?

P.S. Gavin & David, if you can try maybe this topic when you receive your cards…(just try resetting from RPI or reading /reset status …)

I don’t think there’s any particular timing requirements on /RESET – I think it’s just the same as the reset button on the back of the machine. If you want to reset I’d probably hold it for a second or something so it’s not going to glitch anything (bear in mind the machine is only 8MHz so it’s not hard to assert it for less than a cycle if you aren’t paying attention).

One thing to be aware of those is the /RESET signal is open drain – ie any device can pull it low, and there’s a pullup resistor on the motherboard that pulls it high. You should never drive it high, that’s the job of the pullup resistor. If you drive it high and something else tries to drive it low, they’ll fight and you’ll probably get some intermediate voltage.

It looks like the TXS0108 level shifter chip you have does support translating bidirectional open drain signals, and does its own ‘smart’ pullups (so you don’t need your own on the Pi side) but to do that you need to make the Pi /RESTART pin high impedance (eg an input) when you don’t want the A410 in reset, instead of driving it high. I couldn’t find the Pi side software to check if you’re doing that.

Another way to do this is with a simple MOSFET: gate = RESTART from the Pi, drain = /RESET to the podule bus, source = GND. Then driving RESTART high will turn on the MOSFET and pull /RESET low, resetting the machine. Driving RESTART low will turn off the MOSFET and the pullup resistor will drag /RESET high and the machine should boot. Note that it’s the opposite logic sense to the /RESTART you currently have.

Also, it looks like you haven’t wired the /PIRQ or /PFIQ lines anywhere. Is that intentional, that you have no means to generate interrupts? (these lines are also open drain so need a similar drive arrangement)

Hello Theo, regarding /reset line, your remark make full sense, I will work on it. However, I played with the board on the ARC side and made some interesting discoveries:
When the ARC boot, if there is nothing in the static RAM (wich is quite obvious at startup…), the podule is not recognized (normal behavior). But following your examples in your courses, I wrote MemoryA b 03340000 95 (podule 0 address). Then, if I type podules, the podule is recognized as Simple Podule. As expected, when I hit the reset button, the podule is still recognized as Simple Podule so Static RAM is working, but it means also that the ARC can write itself the necessary values in the Static RAM to recognize the podule, so the reset procedure maybe not mandatory. You are right regarding the IRQ lines, I did not include them in this version for sake of simplicity, but can be added later on maybe.

Using the static RAM in that way from the Arc side is handy when you want to test podule ROMs (and their loader etc). You just swapped the podule EPROM for an SRAM and then you can write it in the way you describe – you can also reboot to check the machine comes up, your filing system (or whatever) is loaded, and so on.

But it does mean you have to actively reboot the machine to detect changes, whereas your setup with the Pi driving the reset line should mean the Pi can orchestrate things. I agree you don’t need the reset line working for the time being (although be aware that if the Pi holds it high, the reset button may not work).

Also to note, you don’t need the podule recognised to use the shared memory region – the podule detection is purely for the OS to list in it *Podules, to load modules from the ROM, and for Podule_… SWIs to find it. So you can still use it for communication purposes even if it isn’t detected – but you would need to hard code the slot number in that case.