niklasekstrom / a314 Goto Github PK
View Code? Open in Web Editor NEWA314, a trapdoor expansion that lets you use a Raspberry Pi as a co-processor to an Amiga 500
License: Creative Commons Zero v1.0 Universal
A314, a trapdoor expansion that lets you use a Raspberry Pi as a co-processor to an Amiga 500
License: Creative Commons Zero v1.0 Universal
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.
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.
This is why you should machine generate the BOM. Your resistor pack in the BOM has the wrong quantity (3 instead of 4)
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.
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+.
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?
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.
Can we get an export of the BOM that works with octopart and/or digikey?
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.
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.
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.
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.
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?"
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.
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:
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.
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.
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.
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.
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
Hi, great project
You could reuse my dockerfile and docker code to give people build environments for the drivers...
Take a look
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. :)
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.
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.
Would be nice if there is a HowTo... I've never flashed a device from a Raspi.
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.
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.)
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.
Enable users to write a pre-built PI image with the A314 software installed and configured.
Increases:
Removes:
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).
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.
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.
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.
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 :-)
Enable users with pre-existing SD cards to auto-magically install and configure the A314 software.
Increases:
Should be additionally shipped on pre-built image to aid re-installation.
Not doing: Version updates (new ticket).
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.
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.
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 :-)
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.
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.
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.
Enable non-technical users to install and configure A314 software onto their Amiga OS through a familiar point and click interface.
Increases:
Removes:
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
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.
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.
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 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 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.
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...
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.