niklasekstrom/a314

A314, a trapdoor expansion that lets you use a Raspberry Pi as a co-processor to an Amiga 500

A314

What is it?

The A314 is an expansion board for the Amiga 500 that goes in the trapdoor expansion slot. A Raspberry Pi (RPi) is attached to the A314, and the A500 and the RPi can communicate through a shared memory.

We have constructed a communication protocol through which associated processes on each platform (Amiga and RPi) can allocate logical channels, carried over one physical SPI channel. The protocol is handled by a driver on each side (a314.device on the Amiga and a314d on the RPi). The drivers are responsible for alerting receiving processes of incoming data via an interrupt.

What can you do with it today?

We have implemented a few services that run on the RPi and on the A500:

• a314fs is a file system that is mounted in AmigaDOS as a device, PI0:
  The volume in PI0: is called PiDisk:, and is mapped to a directory in the RPi.

• pi is a command that lets you invoke executables on the RPi from the AmigaDOS CLI. For example, if your current working directory is on PiDisk: and you run "pi vc hello.c -o hello", then the vc program (the VBCC cross-compiler) is executed on the RPi with the given arguments. It will cross-compile “hello.c” into the Amiga executable file “hello”. The resulting binary is immediately accessible through the a314fs.
  You may also launch Interactive applications using the pi command, such as "pi mc -a" which will run Midnight Commander. Running pi without any arguments is equivalent to "pi bash" and will present you with a bash prompt from the RPi.

• PiAudio lets the RPi stream audio samples directly to the shared chip memory, from where Paula plays those samples. PiAudio is integrated with ALSA on the RPi so that any program that plays audio through ALSA can be used, i.e. "pi mpg123 -a amiga song.mp3" plays song.mp3 using the program mpg123 to the Amiga.

• RemoteWB works by moving the Workbench bitplanes over to the chip memory on the A314. This requires that the A500 has at least a 8372 Agnus. During drawing of each frame on the Amiga, the RPi reads those bitplanes, encodes them into a GIF image, and transmits that image to a web browser through a web socket. The web browser in turn, returns key presses and mouse movements back to the Amiga through the same web socket. In effect, this becomes a web browser based remote control application, comparable to VNC but with near zero performance impact on the Amiga CPU!

• VideoPlayer is a simple program that displays a sequence of images on the A500 by letting the RPi write bitplanes directly to the shared memory (this again requires that the A314 memory is chip memory, and not "ranger" memory).

• ethernet is a SANA-II driver that forwards Ethernet packets to the network interface of the RPi. Together with an Amiga TCP/IP stack this provides network access to the Amiga.

What could it potentially be used for in the future?

Here are some services that we have considered but not gotten around to implement:

• Networking through a bsdsocket.library implementation that forwards socket operations to the RPi and executes those operations there. This would give a higher degree of offloading than using the SANA-II driver with a TCP/IP stack running on the Amiga.

• Your ideas?

Do you want to get involved?

If this sounds interesting, you'll probably want an A314 of your own to play with. We have released all the information needed to make a board, freely available in this GitHub repository.

In the Hardware directory there are schematics and Gerber files that can be used to produce a PCB.

The Verilog source code used to generate a programming object file (.pof) for the Intel MAX 10 FPGA is available in the HDL directory. You'll need a USB-Blaster download cable (or a clone) to connect to the JTAG connector on the A314 board. You can compile the design using the Quartus Prime Lite Edition.

The source code for the software that runs on the Amiga and on the RPi is available in the Software directory.

If you have an idea about something cool to make using the A314, but you don't have the means to build a PCB on your own, then we have a small number of pre-built boards that we plan to hand out, given the idea sounds interesting enough. Send a message to Eriond on EAB and describe what you would like to make, and perhaps you can get one.

There used to be an IRC channel for discussing A314, but we have since moved to Discord. Here's the invite link.

a314's Issues

Add power buffer to allow for proper RPi shutdown

Add a power buffer to the A314 5V power line, possibly in the form of a supercap, in order to maintain a short-lived supply to the RPi after the Amiga has been powered off. Also connect a "power sense" to an unused GPIO pin, to trigger proper shutdown procedure on the RPi.

Improved error handling needed

Currently there are several places in the code of a314.device and a314fs that assumes that an A314 is present, and there is no good error handling otherwise. It shouldn't be too hard to fix this.

Probably start with a314.device and make it probe for the presence of A314, and then make it return useful error codes if it can't find an A314.

Create Linux installer for A314 for pre-existing setups

Enable users with pre-existing SD cards to auto-magically install and configure the A314 software.
Increases:

• ease of use
  Removes:
• blockers to adoption

Should be additionally shipped on pre-built image to aid re-installation.
Not doing: Version updates (new ticket).

Create a preconfigured boot floppy

It would help if there was a preconfigured floppy that could be download with all software on it needed to boot up an A314 board.

a314fs crashes with yellow screen if directory does not exist

Hi everyone!

First off: great work, I'm really impressed by the whole project, especially the professional-looking hardware design!

Today I tried to get mine working, it's a Rev. 1.1 I bought off AmiBay.
My System: A500+, Kick 3.1, TF536 68030/50MHz, Indivision ECS V2

The A314 is jumpered to 2MB mode and Amiga Test Kit is reporting 2M Chip, memory test runs flawless. INT2 is connected.

After working out I had to explicitly enable the SPI bus on the Pi, I was able to use the pi command and videoplayer.

When I try to use a314fs, though, the Amiga crashes (Blinking LED of death, Yellow Screen).

mount PI0: seems to work fine but once I either cd PI0: or click PI0: in DirOpus, the crash occurs.

Any idea how I can narrow down what's wrong? I thought about removing the accelerator and trying it on plain 68000 but I'd have to scavenge the CPU from another machine.

EDIT2: Sorry, nevermind, my fault. I had to copy a314fs.conf file to /opt/a314 and create the a314shared directory. Now everything works fine. I am leaving this issue up though as I believe a314fs should handle this error more gracefully than throwing a Guru. Also apparently I can report compatibility between A314 and TF536, yay! :)

EDIT: a314eth.device is working great as well (even with an old version of MiamiDX I had lying around). So I guess if a314fs refuses to work with my setup, FTP file transfer is just fine. :)

Idea: Make Chucky add this to the ReAmiga1200 and ReAmiga3000 motherboards in the future

By being able to access chip-RAM the same ways on these new-school remakes of Amiga motherboards there should be a solid user-base that would be able to benefit from A314 :D

I guess the guys behind Amy and remakes of varius A4000 PCB's could do it too.

Just a crazy idea.

PCB standoff holes for securing Raspberry PI

I noticed that the image a314_with_rpi.jpg shows a Raspberry Pi (model unknown) dangling from the GPIO pins - modern Raspberry PI (later revision 1 plus models and later IIRC) have common hole placements for standoffs, would it be possible to incorporate at least one if not two of the standoff holes on the top of the board so that the Raspberry Pi can be secured properly to the board (as one would a normal Raspberry HAT).

Likewise on both the A500 and A600 boards having at least one standoff hole that conforms with a Raspberry Pi Zero would also be most helpful.

A2000 support?

Great work...

Amiga 2000 support should be fairly straight forward... Has a version for the A2000 commenced? Do I need to produce an adapter board of sorts for the A500 version to fit in an A2000? Unlike the A600, space shouldn't be an issue here.

I already have a raspberry PI mounted on a blank PCB in an unoccupied slot inside my A2000 case. A2000 supplying only power. Also using some KVM switches and sum A234 and more for I/O... Running AmiBerry... Need to have some Ami-Pie sex happening soon... Faster File transfers?, Perhaps shared storage and more... I do have an A500... I would rather install the A314 in the A2000... Currently sourcing components for build... Thanks guys...

The repo shouldn't contained compiled binaries; instead make releases

Currently the compiled binaries are included in the Git repository. It turns out it's easy to forget to compile one binaries after a change, and then the source and binaries are out of sync; this has already happened and led to unnecessary trouble shooting. Probably remove the binaries from the repo and make proper releases (that can be hosted on GitHub as well.)

Include 2MB of ram and use it as chipmem with 2 extra pins for RAS/CAS

It could be a good idea to add 2MB and use A314 for keeping the entire chipmem in A314. This could have many advantages like full control of the chipmem contents (autoboot may be possible creating the required structures on chipmem).

Check out this card that swaps expansion memory with on board chipmem:
http://www.boobip.com/hardware/A500_2MB/A500-_chip_RAM_mod

Mobo memory could be used as ranger/slow mem.

It would be even better if a Gary adapter was used so more addresses could be accessed. That way expansions could be mapped to memory, e.g. a window of 4MB of memory for RTG memory.

Implement support for ACTION_DISK_INFO and ACTION_INFO to a314fs

Implementing support for the two INFO commands isn't as trivial as one might think at first. This has to do with how the PiDisk volume is presented to the AmigaOS.
Normally a volume is the whole logical space on a physical disk, or in the case of a partitioned disk, part of that space. But generally, the AmigaOS assumes that it has exclusive control over that space, and as such it only asks for two key parameters: Total blocks and Used blocks, assuming that the obvious third parameter, Free blocks, can be calculated using the first two.
In the case of A314fs, where the presented volume (usually) is a sub-folder on the Raspberry OS disk, the "Total" amount of block presented to AmigaOS isn't necessary equal to the actual amount of blocks on Raspberry OS disk. Or is it?
This really depends on what the user is expecting to see when they, for instance open a PiDisk window on the WorkBench.
Consider this: The first time you open a PiDisk (after initial installation of A314), the a314shared folder on the RPi is empty. Let's assume you are using a 16GB SD card, where apx. 4GB is used by the Raspberry OS. What should the title bar of the PiDisk window display?
a) 0% full, 12 GB free, 0KB in use
b) 25% full, 12 GB free, 4GB in use
Option "a" may seem intuitive if you're only interested in the Amiga-part of things, but then you have to consider that the free space can suddenly change - regardless of any files you may, or may not have added to the volume, depending on what is happening over at the Raspberry side. Not so intuitive, and maybe confusing. "b" on the other hand makes no sense from a Amiga point of view; "how can there be 4GB in use when I can't see any files?"
One way to circumvent the issue, could be to create a real partition on the RPi SD card, that is exclusive to the AmigaOS, and this is where the a314fs.conf would point to.
There is (at least) one more thing to consider, and that is how the different sizes (Total, Used) are forwarded to the AmigaOS. It uses a concept of "blocks", not bytes, and accompanying these blocks is a conversion factor called "BLOCKSIZE", indicating number of bytes per block. The variables holding the sizes are of type LONG, ie. 32bits. This puts an upper limit on what can be reported back to the AmigaOS, depending on which blocksize is chosen. As storage media evolves, we see increasingly large SD cards, and it can be tempting to choose a large blocksize to accomodate for a very large Volume size. But this will then be at the expense of "resolution" or granularity; adding small amounts of data to the volume won't cause any changes in the reported used space, thus there is no visible change in usage to the Amiga user.

HowTo for flashing FPGA from Raspi on V1.2

Would be nice if there is a HowTo... I've never flashed a device from a Raspi.

Attempting to move directory into subdirectory of itself should be an error

Using WB 2.1 and a directory structure of a/b/c you can drag a into c without any error message on a314fs. This triggers a 202 object in use error when done on other devices.

Fortunately Linux refuses to do the impossible move on a filesystem level.

It is up to ACTION_RENAME_OBJECT to not allow this:

In particular, the RENAME_OBJECT action allows
moving files across directory bounds and as such must ensure that it
doesn't create hidden directory loops by renaming a directory into a
child of itself.

The generated BOM is not in a format that works with suppliers

Can we get an export of the BOM that works with octopart and/or digikey?

Alter footprint for IC11 to improve solderability

Due to the boards DIY nature, the footprint of IC11 should include a stopmask at the bottom layer to allow for through-PCB-heating reflow process as shown in this video: https://www.youtube.com/watch?v=d-f-SBC0GrU
Adding such a stopmask won't affect other mounting methods of the component.
To further enhance the through-PCB-heating process, a GND polygon should be placed in layer 3 (power layer) beneath the IC. This should assist heat conductivity through the board at that specific location.

Does that board also allow CHIP RAM extensions?

It is not very clear if that board also offers true chip RAM extension to allow A500 rev6A to get 1 MB or A500+ to get 2 MB. Moreover, there are some moddings which allow to get 2 MB on an A500 ev6A involving the change of an Agnus chip.

There is also the case of the Boobip board which allow a clever way to maximize the chip RAM size and getting the rest as slow RAM. I wonder if it would be possible to make A314 compatible with the Boobip in such a way you only need a Gary adapter board, connecting cables and jumper wires (for full 2MB mod) while A314 may acte as the memory board.

Discrepancy in how 'rename' to same name works in a314fs

AmigaDOS is fine with renaming a file to the same name it already has, example:
3.Ram Disk:> rename test test
Same command in a314fs causes an error:
3.PiDisk:> rename test test
Can't rename test as test because object already exists

Same when attempting to rename using Workbench.

Implement ACTION_SET_COMMENT and ACTION_SET_PROTECT in a314fs

Currently ACTION_SET_COMMENT and ACTION_SET_PROTECT are unimplemented in a314fs.py.

Implementing those requires the given information to be stored somewhere where the information can be retrieved later when listing files (Examine and ExNext).

Solutions used by emulators:

• UAE used _UAEFSDB.__ files (https://www.amigaforever.com/kb/13-182)
• FS-UAE uses .uaem files (https://fs-uae.net/using-hard-drives)
• WinUAE uses a feature of NTFS, alternate streams, to store a stream named _UAEFSDB.__ with the information

Perhaps it could also be possible to store the information as extended attributes (http://man7.org/linux/man-pages/man7/xattr.7.html) on the Raspberry Pi file system.

a314eth.device should avoid calling AllocSignal() on the schedule of the client, which happens to be the TCP/IP stack

I know, a314eth.device is still new :-)

Some rules for device drivers are peculiar, and the device init/exit code still needs work.

But for network device drivers for which the TCP/IP stack (or Envoy) is the only client, there are additional perils. If you call AllocSignal() in the device open/close function, it may actually fail. You don't know how many free signals are still available for the taking.

At the minimum, please check if AllocSignal() returns failure.

If the point is just to have a signal for communicating with the unit Process, you can avoid calling AllocSignal() altogether by using SIGB_SIGNAL (and its corresponding flag SIGF_SIGNAL) instead. There are some precoditions for doing so, though.

Happy to help you out if you want me to :-)

The latest versions of Raspbian are not working with A314

It seems that something has changed in the latest versions of Raspbian in a way so that the communication with A314 is not working any longer. The latest version that has been tested and known to work is from February 2020.

Places I can think of to start looking is changes that were made to the SPI driver, or something with the device tree. Investigate.

From the bottom of this list, https://en.wikipedia.org/wiki/Raspberry_Pi_OS#Version_history, it seems that two versions of Raspbian were released in February, then a version in May, and then a version in August (all in 2020). The version in August has upgraded the kernel from 4.19 to 5.4.51. It would be helpful to know if the problem exists in the May version, or if the problem were introduced with the move to the new kernel version.

Log unimplemented a314fs actions in Linux

Currently one has to use a debug enabled build of the amiga a314fs filesystem to notice if any unimplemented file system calls are performed.

Unsupported calls should be forwarded to the Linux a314fs.py and logged instead of silently terminating in the filesystem handler on the Amiga.

Amiga 1200 version

Really cool board, makes me want to swap my a1200 for an a500 (almost ;) ). I know the expansion port differs in the a1200 but would it theoretically be possible to have a similar expansion board for the a1200? This looks like a really cool way to get a modern linux combined with the old amiga I especially liked the cross compile and pi command line features that and the drive mounting and gfx/chip memory sharing gives endless possibilities. So the trick to share the chipmem ram is that possible on the a1200 also? Maybe we need to emulate a 68020 as well to allow this on a1200?

Component kits?

Is there somewhere I can get already sourced komponent kits? I already have the PCB on the way, but just sourcing a few components (if you're not a die-hard electronics hoarder) is quite boring. :) I'm looking forward to be USING my A314 and start developing interesting things A.S.A.P. :) And not being used to sourcing, it feels both time consuming and quite pricy ordering just a few components here and there (or a shit-load of them that will just lay around).

A zip-loc with all the things needed for the build for sale? Someone? :) - I could also go for a already built one if anyhone have one extra.

Add jumper that disconnects RAS0

It is possible to cut traces on JP3 on the A500 motherboard, and thereby disable the on-motherboard DRAM. In that case, A314 should respond to DRAM-requests for RAS0 as well as RAS1. But if the firmware is modified so that A314 responds to RAS0-requests then there will be collisions when running on an A500 whose JP3 traces are not cut. Therefore a jumper on A314 would be useful to disconnect RAS0 when the JP3 traces are not cut.

This jumper would also be useful for A500+, so that a single FPGA programming file can be used regardless if the A314 is going to be used in an A500 or an A500+.

Raspian usecase?

Hello,
Thanks for this innovative contribution.
I wanted to ask about use-cases for the a314. I am wondering if this device would make it possible to use the Amiga 500 as a peripheral dock for an Amibian based Raspberry Pi? Either using the Pi’s HDMI output or the a500s graphics via the shared graphics memory? Either way, using all the Amigas IO devices (floppy, mouse, ports, etc) as devices exposed to Amibian through the a314 device. This would allow a great old school user experience while enabling a much broader and more modern set of functionality that emulation provides.
Is this part of your concept or otherwise on the roadmap?

Raymond

Add jumper that either connects EXMEM to ground or leaves it disconnected

The mod that makes A500 rev 6A get 1 MB chip mem (instead of 0.5 MB chip and 0.5 MB slow) which is described here, https://s6.postimg.cc/53hat1xkh/A500_6a_1_MBCHIP.png, requires soldering two jumpers on the motherboard. By adding a jumper on A314 it would be possible to avoid soldering JP7; however JP2 still needs soldering.

Replace GetA314MemBase with a more generic function

Currently the a314.device driver exports a function named GetA314MemBase, which returns a memory base address, such that the A314 memory starts at this position in the Amiga memory map.

However, this is a bit restricting. If the A500's internal DRAM is disabled it is possible to let A314 take over all memory, but in that case the memory mapping could be more complicated. For example, the 0-0.5 MB chip mem could be mapped to 0-0.5 MB A314 memory, but $c00000-$c80000 is mapped to 0.5-1MB A314 memory.

A more general solution would be to let a314.device export a function that takes an Amiga address and returns the corresponding A314 address. This would replace GetA314MemBase completely. Thus, all existing applications would have to be updated (which is still easy because they are all in this repository).

Provide Amiga OS Installer for A314 drivers etc.

Enable non-technical users to install and configure A314 software onto their Amiga OS through a familiar point and click interface.

Increases:

• ease of use

Removes:

• blocker to adoption

Ref: InstallerLG git repo.
Tests provide LHAs containing Installer examples for syntax reference.
https://github.com/sodero/InstallerLG/wiki/Test-status
E.G. ImageFX32.lha:Install_3.2

AHI Audio via Raspi?

First of all, the a314 is a realy nice idea!
To use the trapdoor expansion slot in that way could bring complete new possiblitys to the Amiga500 :-)

As I read about piaudio the first idea was, why it is not the other way? For Amiga500 there is no modern soundcard available so I was thinking it would be very nice to have a ahi.device or something to play amiga audio through the soundcard of the raspi :-)

V1.2 BOM is wrong

This is why you should machine generate the BOM. Your resistor pack in the BOM has the wrong quantity (3 instead of 4)

Create script that validates the installation on the Pi

There are a number of settings and configurations that are needed on the Pi in order to run successfully. A script should be written that is run on the Pi and checks to see that all configurations are in order, and informs the user if something is missing and how to fix it.

Eventually this program could be extended to also fix the issues, and perhaps do the complete installation.

Default directory for "pi" command should mimic behaviour in linux terminal

When a user executes the "pi" command in a Amiga shell in order to access the Raspbian shell, the default working directory is set to root ("/"), while opening a terminal in Raspbian sets it to /home/[user]/.
To avoid confusion, the pi command should mimic the Raspbian behaviour, by placing the user in their home directory.

Implement networking through bsdsocket.library

Write a bsdsocket.library that forwards network calls to the RPi.

The API seems straight-forward enough: https://wiki.amigaos.net/amiga/autodocs/bsdsocket.doc.txt.

Each time bsdsocket.library is opened a new Library structure should be allocated, initialized and returned, in accordance with the description of bsdsocket.library/OpenLibrary in the linked document.

USB access via ANAIIS

This would grant access to the Pi's USB ports from ANAIIS, a USB stack for the Amiga which is compatible with the stock 7MHz 68000 CPU. They provide a libusb-based proxy driver for running on UAE which should serve as a good foundation. There is far less API here to implement than BSD sockets.

http://aminet.net/package/driver/other/anaiis_hostusb

JTAG pin header is slightly too close to trapdoor pin list

The JTAG connector cannot be inserted all the way down on the JTAG header, because the connector hits the pins on the trapdoor pin list. The JTAG connection works fine anyway, but if the JTAG pin header is moved 1 mm (or so) away from the trapdoor the problem will likely go away.

Implement more dynamic method for detecting A314 memory ranges

The current code for deciding which memory ranges are provided by A314 is fairly inflexible, and it has proved to cause problems on several occasions.

As an example, an A500+ with a Vampire has both 2MB chip memory and 0.5MB slow mem at address 0xc00000. This combination was not anticipated and therefore didn't work correctly. A fix for this particular configuration was easy to make, but in general it would be nice to have a more dynamic method of detecting which memory ranges are provided by A314.

One method I have been considering is that when a314.device is starting it could disable interrupts (and maybe DMA as well?) and then put the A314's FPGA in a special detection mode, and read and write to potential A314-addresses, and at the same time communicate with the FPGA through the clock port, to find out if a particular address is handled by A314.

The reason why DMA might have to be disabled is that the blitter can write to memory, and a write by the blitter during the detection procedure could be mistaken for a write by the CPU. Disabling all DMA, even bitplanes, could make for a slightly annoying user experience, if the screen goes blank (for a short period). It may be possible to only disable blitter DMA, but this is still not completely unproblematic since the copper could start blitter DMA, so maybe disabling both blitter and copper DMA would work (this needs some experimentation).

Another method would be to have a configuration file that is stored in DEVS: or S:, that describes which memory ranges are mapped to A314. This is less dynamic but avoids performing the detection procedure each time the Amiga boots up.

Program FPGA firmware from RPi

It chould be possible to connect additional pins from the RPi pin header to the FPGA JTAG pins, and then use the RPi for programming the FPGA firmware.

The program described on this page has been used successfully to program the firmware: https://weekly-geekly.github.io/articles/343524/index.html

There should be some information that tells a314d if a valid base address is available or not

Currently, a314d may read the base address from CMEM, and get the default value (0) although a314.device has not written a base address yet. There should be some bit that tells if the base address was actually set to zero, or if no base address has been written yet.

Make a314d check spidev.bufsiz setting.

We've got experience that this setting is very important and that users are missing out on setting it correctly.

a314d should check this on startup, and refuse to run if not set correctly. Maybe just start in a minimal mode without services so that a314.device won't hang on the amiga side? Investigation needed.

if not spidev.bufsiz=65536 then log.error "spidev.bufsiz not set to correct value, check spelling?"

Migrate all Python 2 code to Python 3

Python 2 will stop being maintained shortly: https://pythonclock.org/.

There are pieces of the software that are written in Python, and most of those pieces are targeting Python 2. These should be converted to Python 3. I don't expect this to be a lot of work.

Create pre-built PI image

Enable users to write a pre-built PI image with the A314 software installed and configured.
Increases:

• ease of use

Removes:

• blockers to adoption

Raspian lite doesn't come with some required python libs

If you add

sudo apt install python3-distutils python3-dev

to your build instructions or the build script it will make sure they are present and you won't get:

**bpls2gif.c:5:10: fatal error: Python.h: No such file or directory
 #include <Python.h>
          ^~~~~~~~~~
compilation terminated.**

or

cd bpls2gif ; python3 setup.py install
Traceback (most recent call last):
  File "setup.py", line 4, in <module>
    from distutils.core import setup, Extension
ModuleNotFoundError: No module named 'distutils.core'

It should be possible to enable debugging output for a314d without recompiling

Currently one has to change hard-coded flags in a314d.cc and recompile to enable debug output. This should be possible to do with either a argument passed when starting, or with a variable in the a314d.conf file.

Can the SPI bus be made to run at 100 MHz?

Today the SPI bus that connects the Raspberry Pi and the FPGA runs at 66 MHz (T=15 ns). As the RPi runs at a core clock of 400 MHz, this means that a divider of 6 is used (400/6=66). The next smaller divider that is possible is 4, which would give a SPI bus frequency of 100 MHz (T=10 ns).

Is it possible to run the SPI bus at 100 MHz? Further experiments are needed.

One issue I know of already is that if the SPI bus runs at 100 MHz then the SPI protocol that is used today has to change. There are 4 SPI cycles of padding from when the last bit of the address arrives until data should be ready to send back to the RPi, during a READ_MEM_CMD; this means that today there is 4*15 = 60 ns available to read out the data from the SRAM. This is almost exactly what is available in the worst case, which is if the Amiga happens to have started a read just before the SPI read arrived. Certainly 4*10 = 40 ns would not be enough, so the SPI protocol must be modified.

But before going into that a simpler experiment should be to see if the signal quality is good enough to support a 100 MHz SPI frequency.

Create an audio device in Linux (running on the RPi) that outputs sound via Paula

I'm not sure how hard this would be, but if possible it could be nice to make a sound device for Linux, running on the RPi, that writes the sound samples to A314 memory and then sets it up on the Amiga side so that the sound is played by Paula. I'm guessing this would allocate two of the four Amiga audio channels.

For a314fs, make it possible to remove a volume from a device (i.e. PI0:) and later insert volume again.

As the title says. Moreover, it could be nice to support multiple devices (PI0:, PI1:, ...) and be able to decide, through a config file on the RPi, what volume should go in each. The contents of a volume should be mapped to some directory on the RPi.

Add setting to pi command that sets TERM env var to something other than ansi

Today, picmd.py always sets TERM=ansi before invoking a program. Sometimes, for example if the workbench is set to 2 bitplanes (4 colors) this might not be what you want. There should be a setting in /etc/opt/a314/picmd.conf so that the TERM variable is set to something else, for example vt100.

It could be possible that the Amiga pi command sends the number of bitplanes to picmd on the RPi, and the TERM environment variable is set based on the number of bitplanes, i.e. <3 bitplanes => tty, >= 3 bitplanes => ansi.

Use ctrl-c to shutdown Amiga apps

Today remotewb and videoplayer are shut down by entering "exit" in the console. Instead they should use ctrl-c. Also add message "Press ctrl-c to exit...". This message should be added to piaudio also.

A600 support

Would be nice to add support for Amiga 600, or if it is allready supported, validate it by test and clarify the support in documentation and description of the project.

Docker suggestion

Hi, great project

You could reuse my dockerfile and docker code to give people build environments for the drivers...

Take a look

https://github.com/terriblefire/cdtv.device