Amiga SBC Common Framework

It seems the Amiga community is really picking up speed for enslaving Raspberry Pi to service as a co-processor and or accelerator for the Amiga. Not to mention the many distros of emulators that have already been embracing the Pi for a number of years.

Just to mention a few of the Amiga Pi projects I have dipped my toes into are the a314 Coprocessor and now waiting on a PiStorm32 board. That said though, I am not here writing specifically about those projects. I am here to toss out some concepts that the Amiga community can potentially embrace to open up access to a greater number of Single Board Computing Devices.

Standardize SBC Expansion Boards.

The first move I suggest is to acknowledge and standardize hardware interfaces that are to be used to the Amiga to link with Pi’s. These boards can become universal and support multiple community projects. These boards can serve as the gateways. In a lot of ways, we have this already with the a314 Clockport Coprocessor and PiStorm Expansion boards. Call it almost done! One area that both boards can enhance is interfaces on both boards for 26 Pin GPIO access. This way regardless of whether your SBC has 40 or 26 pin interfaces, your covered. Yes, there are issues that need to be addressed if we do that, lets segue into them now.

Next, we need some frameworks developed. These frameworks cover SBC to Amiga interface mappings. So basically they standardize communication to the Amiga by allowing mapping configs to exist for the various SBC’s. So to accomplish and get started, you take 5-10 popular and capable Pi Alternatives and compare Pin Mappings. MS Excel could be used to start and then later exported to a CSV and then a flatfile map can be created or mapping config files.

Eventually a simple graphical config tool can be created to select the SBC and Model to move the correct GPIO.config file into the active config directory. More on this later. sample code that may help accelerate -https://github.com/RPi-Distro/raspi-config

Abstraction Layers

Once we have a hardware standard we need some communication standards. We need to define standard messaging and data exchange between our Amiga and our SBC. This defines what the Amiga expects in the form of how it and the SBC will communicate and what is allowed to be communicated. This can continue to evolve over time as new ways of enslaving our SBC are created.

UNIT TEST Facilities

Also we need a development API for testing communications For raw development we can create an emulator to test communications and data exchange integrity. What this does is make sure on the SBC we have a version of the Amiga API on the local SBC side we can test with by sending and receiving communications and data and looping it back. What goes in should be what comes back out exactly. This is a crude utility for unit testing. Example code that may help – https://github.com/cbrake/linux-serial-test.

AMIGA API

An actual Amiga API will be needed as well to take the messages and data and render it to the Amiga and its devices for processing. This allows any developer to reuse the API for any tools or programs. The developer will be able to subscribe to the API to send and receive messages as well as any services that have been available for Amiga usage.

This also needs a loopback function. This will be needed for integration testing to make sure the Amiga is receiving and can send back what it has received. This facility is also used to test and iron out timing differences that may vary between the different SBC’s, clock speeds. The idea is that communications and data transfer starts at a fairly aggressive speed and then falls back or leans forward until the break points are resolved or reached. This sets a baseline and then the speed can be set to a safe level for reliability.

The facility allows for any SBC to test between any Amiga and uniquely self optimize speeds for messaging, data transfer and processing. If the speeds are off, data may drop, or get garbled.

SBC Abstraction

Back on the SBC side we want to think in terms of services. These services will/can be used across multiple Linux distributions. You need this abstraction layer to be successful. So instead of directly calling Pi network Hardware, the API’s would look to available network services that can be accessed by the Amiga on any SBC someone cares to work on accessing its services.

We need this for Audio, Video, Devices and CPU Processing and any other SBC features we wish to exploit.

As a part of that you also need calibration routines. These routines will test your SBC based on the mapping for the pins and adjust timings to the most optimal level minus 10% or some other variable to give it a little breathing room. So these calibration routines help define quality of audio, quality of video and modes, network speeds, etc. Keep in mind that each SBC can be different and could also be running different versions of Linux. Calibration routines help account for these differences and uniquely tune your Amiga to your SBC.

Please note, I am not an engineer or a software developer by trade, what has been presented is very loosely presented at a high -level to conceptually describe the kinds of work that would need to be done to open up all kinds of different SBC’s.

Once you develop this framework it could be used to enslave any faster SBC’s such as AMD and Intel Based devices. Keep in mind that the most like use here is for accelerators and offloading. You Amiga has to keep up with the SBC so for now there are some practical limits.

https://www.shlomifish.org/open-source/portability-libs/

USE Cases

Relieve pressure on escalating prices for popular SBCs

Open the possibility to better Internet for Amigas by outsourcing those functions in large part to the SBC.

Potentially open the door to multicore processing for the Amiga by focusing on the API to prioritize requests to the SBC slave.

Run amiga Virtual Machines on the SBC and window it back to the Amiga via Bitmapping.

Many other things we haven’t thought of yet!

Happy Amiga Fun!

EverStaR