A314 - The RPi co-processor Official thread

[Eriond]

it's been a year in the making, but now we have finally released it to the public. The A314 co-processor memory expansion with accompanying software.

The A314 connects to the Amiga 500's trapdoor expansion connector and provides your machine with up to 1 MB of extra memory (depending on your hardware revision, Agnus chip version and the usual limitations). But wait, there's more: You will also get a battery backed-up real time clock!
Yeah... right. You may think to yourself that you already got that, and it's called the A501. Obviously we didn't spend a year to produce yet another A501 clone. We did something more.

The A314 will replace your current memory expansion, and to that extent it will do so by emulating a normal DRAM bus. The same goes for the RTC, it is also emulated. But why bother emulating chips that are readily available? Because we wanted to allow transparent DMA at full bus speed without wait states. If you have that, you could for instance connect an accelerator module, or using Amiga terminology - a co-processor.

We figured that if we could allow for a SBC (Single Board Computer) to transfer data to and from the Amiga, it could handle and off-load all sorts of common tasks that are overwhelming for the old m68k processor. A typical such SBC is the Raspberry Pi, which is the device we have chosen to build our support software for. You could choose a different SBC with a compatible GPIO header, like the TinkerBoard or the ODroid with Shifter shield, but then you'll have to adapt the support software/drivers yourself.

Bundled with the A314 is a software and driver suite, that will allow for seamless interaction from within the Amiga OS. It is written to be compatible with Kickstart 1.2, in order to include as many A500 owners as possible. The support software is built around a communication driver that allows for multiple concurrent data-streams. To this date we have created the following using that driver model:

PiDisk - A remote file system that resides on the RPi, and can be further shared from that platform using for instance SMB.
Pi - A CLI tool for executing remote commands on the RPi, delivering the results back to the Amiga, or just opening a remote Bash shell.
Videoplayer - A demo for showing off FMV (Full Motion Video) capabilities.
RemoteWB - A web-based remote desktop host, that allows you to connect to your Amiga's workbench from wherever in the world, with nearly zero performance penalty on the Amiga side.

The last two applications are creative ways of showing what you can do if you have access to the Amigas chip memory. That is the truly unique feature of our device; it allows you to directly read and write to the same memory area that the customs chips use, and do it at their speed of operation, but from a completely asynchronous platform.

We sure hope this has sparked some interest, and maybe some ideas that you would like to realize using this device. For this purpose we have given the complete project to the public domain under a CC0 license. We are currently busy writing documentation in the form of support manuals that will become available little by little
We also acknowledge that building circuit boards with fine-pitched SMD components isn't for everyone, so we decided to give away a very small number of boards to those of you that are skilled in Amiga programming, and could act as both beta testers and willing to be ambassdeours for this project.
PM me if you are interested, and tell me about your ideas.

[alpine9000]

Cool project!

[gulliver]

Absolutely fantastic!

Do you plan a ZorroII implementation so that we can use other Amiga models (A4000, A3000, A2000, and even A1200+busboards)?

Afterall, the A500 trapdoor expansion has nearly everything to implement a ZorroII slot.

[kolla]

I don’t think there is full access to chipram from zorro bus?

[Niklas]

Originally Posted by kolla

I don’t think there is full access to chipram from zorro bus?

That's right; that's one of the unique features of A314 that the RPi can read and write directly into the Amiga's chip memory (well, the chip memory that sits on the A314).

Of course there are many features that could be implemented without access to chip mem, so a Zorro version could still be interesting. The feature I find most useful is that the AmigaDOS command line is extended with the commands from the RPi bash, so for example I can do "pi wget http://aminet.net/<file>" to download a file to the shared file system, and then go ahead and unpack and run those files.

[kolla]

Originally Posted by Niklas

Of course there are many features that could be implemented without access to chip mem, so a Zorro version could still be interesting.

Indeed.

The feature I find most useful is that the AmigaDOS command line is extended with the commands from the RPi bash, so for example I can do "pi wget http://aminet.net/<file>" to download a file to the shared file system, and then go ahead and unpack and run those files.

Right. I do this too, using rsh, and my command is RPi, but pretty much the same.
(and my script accepts a TO/K so you can for example do 'RPi TO RAM:test "curl -sL http://aminet.net/<file>"', maybe a feature for you to implement in "pi" as well)

Some time ago I put some of my scripts on gitlab, feel free to use for inspiration, or criticise or whatever

https://gitlab.com/kowoba/amiga-scripts

PS: and if you look at the "Aminet" script, you notice how I use a zsh-function on the pi to generate amigaguide from aminet INDEX/RECENT files, for example...
https://gitlab.com/kowoba/amiga-scri...ter/Aminet#L49..

Execute S:RPi TO T:AMINET_RECENT.guide "${_RCURL} ${AMINET}/RECENT | zsh -l -c aminet2guide"

(I just checked my s:shell-startup, I have more than 20 aliases that uses the RPi script, to access git, ssh, curl, slack, kubectl, vagrant etc directly from Amiga shell, so super useful.
Another thing I was playing with last summer, was an arexx module for DOpus Magellan that via the RPi script, runs ansible and kubectl on the pi to create and control remote vhost instances and kubernetes clusters from DOpus Magellan... crazy fun )

[hooverphonique]

Originally Posted by gulliver

Afterall, the A500 trapdoor expansion has nearly everything to implement a ZorroII slot.

I think you're mixing things up - the expansion connector on the left side is close to being a zorro slot, but the A314 is for the trapdoor, which is nothing like a zorro slot

[Niklas]

Originally Posted by kolla

Right. I do this too, using rsh, and my command is RPi, but pretty much the same.

I'm not quite clear on how your setup works, but perhaps one difference (?) is that on A314 there is also a shared file system, so I can do the following from a CLI:

1.PiDisk:> pi pwd
/home/pi/a314share
1.PiDisk:> makedir test
1.PiDisk:> cd test
1.PiDisk:test> pi pwd
/home/pi/a314share/test
1.PiDisk:test> pi vc ../helloworld.c -o hello
1.PiDisk:test> hello
Hello World!

So the Linux command is invoked in the RPi directory corresponding to the PiDisk-directory that you are standing in. This is also seen in this screenshot (that also shows the workbench being remoted to a web browser): https://github.com/niklasekstrom/a31...b-compiler.png. Perhaps this is also handled by your script?

Another thing that the pi command does is that if you are running an interactive program (for example midnight commander, using "pi mc") and then you resize the CLI window, then the pty terminal size on the RPi is also updated so that the drawing is adjusted to fit the new size (as seen in these two images: https://imagebin.ca/v/4eu4h8ip28fw https://imagebin.ca/v/4eu4r8A8hZtZ).

Originally Posted by kolla

Another thing I was playing with last summer, was an arexx module for DOpus Magellan that via the RPi script, runs ansible and kubectl on the pi to create and control remote vhost instances and kubernetes clusters from DOpus Magellan... crazy fun )

Indeed, lots of fun to be had

[kolla]

Originally Posted by Niklas

I'm not quite clear on how your setup works, but perhaps one difference (?) is that on A314 there is also a shared file system

I also have shared filesystem(s) (the pi is sharing various over NFS, amiga using ch_nfs to mount them), but that is not related to the RPi script. I suppose your shared filesystem does not depend on a TCP stack or anything, but is pretty much instantly available using a custom "scsi.device" or file system handler?

so I can do the following from a CLI:

1.PiDisk:> pi pwd
/home/pi/a314share
1.PiDisk:> makedir test
1.PiDisk:> cd test
1.PiDisk:test> pi pwd
/home/pi/a314share/test
1.PiDisk:test> pi vc ../helloworld.c -o hello
1.PiDisk:test> hello
Hello World!

So the Linux command is invoked in the RPi directory corresponding to the PiDisk-directory that you are standing in. This is also seen in this screenshot (that also shows the workbench being remoted to a web browser): https://github.com/niklasekstrom/a31...b-compiler.png. Perhaps this is also handled by your script?

Not from my script, but since I mount my home directory on the pi, /home/kolla as "kolla:" on the Amiga, all you show above I do too

Another thing that the pi command does is that if you are running an interactive program (for example midnight commander, using "pi mc") and then you resize the CLI window, then the pty terminal size on the RPi is also updated so that the drawing is adjusted to fit the new size (as seen in these two images: https://imagebin.ca/v/4eu4h8ip28fw https://imagebin.ca/v/4eu4r8A8hZtZ).

Very cool - this is much more interesting - and this is with the Amiga not even using a TCP-stack?

The rsh command I use is limited to firing off a command and print out the result - it is not interactive, and certainly does not deal with terminal emulation etc. For this I currently log in to the pi using telnet, though since Amiga console variant of "ANSI" is rather limited, I prefer using more compliant options, like AmTelnet, or Term via telser.device.

[kolla]

It would be awesome if the a314 could provide a "uae style" bsdsocket.device for the real Amiga, rendering any TCP stack on the Amiga redundant, hehe.

[Niklas]

Originally Posted by kolla

I suppose your shared filesystem does not depend on a TCP stack or anything, but is pretty much instantly available using a custom "scsi.device" or file system handler?

Correct, it's a file system handler, L:a314fs, source is available here: https://github.com/niklasekstrom/a31...oftware/a314fs

Originally Posted by kolla

Not from my script, but since I mount my home directory on the pi, /home/kolla as "kolla:" on the Amiga, all you show above I do too

I guess then you are used to these niceties

Originally Posted by kolla

Very cool - this is much more interesting - and this is with the Amiga not even using a TCP-stack?

Yes.

[Niklas]

Originally Posted by kolla

It would be awesome if the a314 could provide a "uae style" bsdsocket.device for the real Amiga, rendering any TCP stack on the Amiga redundant, hehe.

That is indeed mentioned here: https://github.com/niklasekstrom/a31...-in-the-future

[kolla]

I should have read the github page more thoroughly (but I am "busy at work, heh")

Impressive, the concept of the pi "owning" the chipram opens a world of opportunities, like you demonstrate with the videoplayer - maybe the videoplayer already does this.. an Amiga program that opens an intuition "pi screen" (or more?), to which the pi can write whatever it wants (and maybe take input too, when screen is "active"?). I am imagining lamiga-n to flip between Amiga programs and among them, "pi" screens, maybe even draggable...

[kolla]

Btw - I suppose there's nothing preventing similar hardware for the A600 trapdoor?

[Heywood]

Looks quite interesting - I was curious about the A600 aspects as well, if there's concern about real estate I guess a Pi ZeroW would work and be software compatible.

There are quite a few possibilities this could open up such as an arexx/restapi IPC bridge (not sure what kind of problem that might actually solve but the concept sounds interesting)

[Niklas]

Originally Posted by kolla

Impressive, the concept of the pi "owning" the chipram opens a world of opportunities, like you demonstrate with the videoplayer - maybe the videoplayer already does this.. an Amiga program that opens an intuition "pi screen" (or more?), to which the pi can write whatever it wants (and maybe take input too, when screen is "active"?). I am imagining lamiga-n to flip between Amiga programs and among them, "pi" screens, maybe even draggable...

Yes this is how the video player works. It uses normal Amiga screens, so they are draggable and can move to front/back, and have multiple open at the same time, as seen in this screenshot: https://imgur.com/a/DvJ9eZ6. The menu bars used for dragging the screens are there but not rendered, due to the SCREENQUIET flag in the NewScreen structure: https://github.com/niklasekstrom/a31...oplayer.c#L362.

If you come to think of some other cool application of this (that the RPi can read and write directly to chip mem) then please do let us know!

Originally Posted by kolla

Btw - I suppose there's nothing preventing similar hardware for the A600 trapdoor?

We haven't really discussed the possibility of A314 for A600, but if the signals on the expansion port are the same, and a RPi fits inside the A600, then I suppose it should be doable.

[kolla]

Originally Posted by Heywood

There are quite a few possibilities this could open up such as an arexx/restapi IPC bridge (not sure what kind of problem that might actually solve but the concept sounds interesting)

Yes, it does, it could open all kinds of possibilities for integration, using the Amiga as front-end/user-interface for RaspberryPi, and easily give the Amiga access to "modern life" services. For example, the shared filesystem, that is directly usable from the Amiga, can also (wholly or partly) be synchronised to cloud storage, git repos etc. An AREXX port could give the Amiga a peek into the systemd/dbus/whatever message/notification system of the Linux running on the Pi, which then could trigger things to happen on the Amiga. I do some dirty tricks for such things to happen, using named pipe files ("sockets") on shared filesystems, but with proper implementation, this could be done a lot cleaner

[kolla]

Originally Posted by Niklas

Yes this is how the video player works. It uses normal Amiga screens, so they are draggable and can move to front/back, and have multiple open at the same time, as seen in this screenshot: https://imgur.com/a/DvJ9eZ6. The menu bars used for dragging the screens are there but not rendered, due to the SCREENQUIET flag in the NewScreen structure: https://github.com/niklasekstrom/a31...oplayer.c#L362.

Woohoo! Awesome!

If you come to think of some other cool application of this (that the RPi can read and write directly to chip mem) then please do let us know!

The obvious answer would be ... an xorg server driver, hehe

We haven't really discussed the possibility of A314 for A600, but if the signals on the expansion port are the same, and a RPi fits inside the A600, then I suppose it should be doable.

I believe they are pretty much the same, yes, and as mentioned ... Pi ZeroW is very tiny

[Eriond]

Although I haven't discussed an A600 version with Niklas, I have ordered a reasonable amount of 80-pin 1.27mm pitch card edge connectors...
But for once in my life, I'd like to try and see how it feels to complete one project before starting up the next one!

[kolla]

Originally Posted by Eriond

But for once in my life, I'd like to try and see how it feels to complete one project before starting up the next one!

Fully understandable

(And I, for once in my life, will soon have space for a permanent A500 setup, just bought a new bigger apartment today!)