A314 - The RPi co-processor Official thread - Page 2

NorthWay · 25 April 2019, 18:38

So you have taken an interesting idea and run with it. Can I ask your opinion on something I have tried "shopping around" many many years back:
Could you imagine an A4000 cpu card with a connector cable to the chipram SIMM slot on the motherboard? Basically putting something like 2M SRAM on board and force the addressing to go locally and not to the chipmem bus? (Hitting the replacement chipmem as fast as you can while still serving data over the SIMM slot.)

madlax · 25 April 2019, 18:47

This is so cool!

deladrevoc · 25 April 2019, 19:10

Internet radio would be quite cool

Eriond · 25 April 2019, 21:37

Quote:

Originally Posted by NorthWay

Could you imagine an A4000 cpu card with a connector cable to the chipram SIMM slot on the motherboard?

I'm no expert on the 32-bit machines, but my guess would be that you would not gain that much performance by allowing faster CPU access to chipram. It (the CPU) would still have to wait for the comparably slow custom chips to complete whatever task they are given.
In order to see a real performance boost, you would probably need to re-create your own faster versions of the custom chips, in a FPGA for instance. Because if you just overclock the existing ones, you'll run into all sorts of timing related issues (like illegal video timings etc.).
So, if you choose to go down that route (New CPU board, new custom chips, new ways of accessing the memory) you might just as well do a new Amiga model

AndrewNC · 25 April 2019, 22:34

Fantastic project! Just ordered some PCBs, can't wait to get one up and running!

madlax · 25 April 2019, 23:13

Quick question, does it work with Vampire?

kolla · 25 April 2019, 23:16

Quote:

Originally Posted by madlax

Quick question, does it work with Vampire?

Should work with V2 as long as you don't use Core3 (or whatever it is called, the "AGA core".)

madlax · 25 April 2019, 23:28

Quote:

Originally Posted by kolla

Should work with V2 as long as you don't use Core3 (or whatever it is called, the "AGA core".)

Would it be possible to also use the USB ports on the Pi for the Amiga? Like keyboard, mouse or external storage.

NovaCoder · 26 April 2019, 01:35

This is pretty cool, nice to see something different in the Amiga space

Heywood · 26 April 2019, 04:22

Quote:

Originally Posted by madlax

Would it be possible to also use the USB ports on the Pi for the Amiga? Like keyboard, mouse or external storage.

At least for the external storage piece I suspect that the "PiDisk - A remote file system that resides on the RPi, and can be further shared from that platform using for instance SMB." software could do this.

For Mouse and Keyboard, it may be worth taking advantage of the bluetooth capability of the Pi otherwise you need to snake cables through the trapdoor or something but there would most likely be a need to develop the software to make it work and this might suggest that it would really only work for system friendly software.

-----

One of my questions is how does the solution deal with asynchronous boot sequencing/timing of the Pi and Amiga? I imagine you need to kick off a task/thread to poll/wait for contact with the other device.

Niklas · 26 April 2019, 08:24

Quote:

Originally Posted by AndrewNC

Fantastic project! Just ordered some PCBs, can't wait to get one up and running!

Yay, that's great to hear! Growing the user base by 50%!

kolla · 26 April 2019, 08:26

Quote:

Originally Posted by Heywood

One of my questions is how does the solution deal with asynchronous boot sequencing/timing of the Pi and Amiga? I imagine you need to kick off a task/thread to poll/wait for contact with the other device.

Good question, though my experience is that the pi is up and running before the Amiga even has figured out what device to boot from.

Niklas · 26 April 2019, 08:46

Quote:

Originally Posted by madlax

Quick question, does it work with Vampire?

I don't know the answer to that I'm afraid as it hasn't been tested.

Quote:

Originally Posted by madlax

Would it be possible to also use the USB ports on the Pi for the Amiga? Like keyboard, mouse or external storage.

There is no special support for USB-attached storage today, but using the a314fs file system should work as it stands. However, we were talking about that the functionality of the file system handler (a314fs) could be extended so that a device (e.g. USB0: ) is mounted in AmigaDOS, and then when a USB memory stick is inserted in the RPi it looks to AmigaDOS as if a diskette was inserted in USB0:, and similarly if the USB stick is removed it looks as if the diskette was ejected.

For keyboard and mouse there is no software support today, but it could be written.

Eriond · 26 April 2019, 09:10

Quote:

Originally Posted by Heywood

One of my questions is how does the solution deal with asynchronous boot sequencing/timing of the Pi and Amiga? I imagine you need to kick off a task/thread to poll/wait for contact with the other device.

We have made boot floppies with a very short startup-sequence: They basically start up the PiDisk file system, then assign all the system directories over to PI0: and continue the boot process from there.

The time spent during floppy access on the Amiga, is enough for the RPi to boot up and start the A314 daemon which in turn launches the PiDisk filesystem.
This is of course primarily a concern for cold boot situations; a warm boot (Ctrl-A-A Reset) does not affect the RPi, so in those situations the A314 daemon is already available.

AndrewNC · 26 April 2019, 09:21

Quote:

Originally Posted by Niklas

Yay, that's great to hear! Growing the user base by 50%!

I've ordered parts to build up two of them, but will have some spare PCBs available for sale if anyone else wants to build their own. Should be somewhere around £12-£15 GBP per board (4 layer boards so a bit pricier than normal).

Niklas · 26 April 2019, 09:42

Quote:

Originally Posted by Heywood

One of my questions is how does the solution deal with asynchronous boot sequencing/timing of the Pi and Amiga? I imagine you need to kick off a task/thread to poll/wait for contact with the other device.

Great question. It is designed to work regardless of the timing when booting up. I'll explain how it works.

First, you should know that the trapdoor expansion has essentially two buses going through it: a DRAM bus, and an RTC bus. The A314 looks like regular DRAM memory and RTC chip to the Amiga, but the RTC bus is also slightly subverted. If a particular bit in a particular RTC register is toggled then the RTC emulation switches bank to a new set of A314 registers that only the a314.device knows about. These registers are known as CMEM registers. CMEM registers can hold information, but some of them are also involved in controlling interrupts.

On the Amiga side:
- When a program on the Amiga wants to communicate with the RPi it loads a314.device (after that a314.device remains in memory until reboot).
- When a314.device loads it allocates a block of MEMF_A314 memory, i.e. memory on the board that can be accessed by the RPi. This block of memory is called the "communication area".
- a314.device writes the address of the communication area (the base address) to a set of CMEM registers (each CMEM register is 4 bits, so 5 CMEM registers are used to store the base address).
- a314.device writes to CMEM registers to interrupt the RPi to notify that the base address has been written. This interrupt may not be seen by the RPi if the RPi has not booted yet.
- When the program on the Amiga wants to connect to a service on the RPi, it calls a314.device, which writes a CONNECT packet to the com-area, and then generates an interrupt notifying the RPi that a packet has been written. Again, this interrupt may not be seen if the RPi hasn't booted yet.
- The program (via a314.device) waits until it receives a CONNECT_RESPONSE packet back from the RPi.
- Each program that connects to a service allocates a separate logical channel that are multiplexed over the shared communication channel, so there can be many outstanding connect requests.

On the RPi side:
- When the RPi boots up, systemd will start a314d as a service (daemon).
- a314d will read the base address from CMEM registers (via the SPI bus).
- If a base address had been written then a314d will know where the communication area is, otherwise it'll just wait until it gets interrupted with a notification that the base address has been written.
- Once a314d knows where the com-area is, a314d will read the queue pointers to see if the Amiga has sent it a packet.
- If a packet has been written to the com-area it will be read and processed. If the packet is a CONNECT packet, a314d will see which service is being connected to; there is a table of services that are registered, and this table also contains information so that a service can be loaded on demand if it wasn't started yet. In this sense, a314d is a bit like inetd, a super-daemon.
- A CONNECT_RESPONSE is sent back to the Amiga, by writing the packet to the communication area and then writing to CMEM registers to generate an interrupt at the Amiga.

This way, if the Amiga boots up first a314.device will write request packets for the RPi and then wait until response packets are available, and then later when the RPi boots it will see those request packets and respond to them. If the RPi boots up first it will see that the Amiga hasn't booted yet (no base address has been written) and simply wait until it is interrupted with a notification that the base address has been written.

project23 · 26 April 2019, 12:08

This project is incredible, and i'll be printing some PCBs this month for sure...

A quick question:

The Pi has direct access to the chip ram, is that right?

Okay so iirc fastram or no, the graphics rendering on the Amiga is via chipram?

So on the Pi side, would a developer be free to tinker around with that ram to achieve whetever visual effects they're interested in on the Amiga side?

Where i'm going with this, is the ability to start work on something that would essentially render a windowed Pi native app on the workbench screen - such as a chat client or a web browser.

Perhaps even development into something akin to the ECS indy? Which I believe also has direct memory access.

Maybe a bit more hardware would be required for this, but the point is that the access would be there to develop with - or even monitor the actual memory in realtime using the Pi video out?

Am i talking out of my ass here? lol

John

Niklas · 26 April 2019, 12:55

Quote: