A314 - The RPi co-processor Official thread

[Eriond]

Originally Posted by project23

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.

Funny enough, that is exactly how this project started over a year ago. I wanted to make the Amiga my daily driver, so I began thinking about what applications I would need to accomplish that? Today it's hard to do any work without an internet connection and a web browser. But the Amiga with it's m68k processor quickly becomes overwhelmed by modern HTML5 pages. I knew that the RPi, being cheap and readily available, could do it with ease. So all I needed was some hardware that could insert a pre-rendered bitmap of a web page into the chipmem, and then just let the OCS chips do their thing - tada - and my webpage would be available on my Amiga workbench.

It proved to be more complicated than that, but with the assistance of a software wizard ( Yes, mr. Niklas) we managed to do some initial testing.

Then we came to the conclusion it wasn't worth persuing that goal, due to the OCS chipsets graphic capabilities. In todays world it's easy to forget how high resolution our screens have; even a simple smartphone often has FHD. And then you have the colour depth...

To make a long story short; we realized that a modern web page became so crippled when rendered in HiRes/nolace/16col, you could barely make out the writing. The images suffered from banding and colour reduction artefacts in general, to such extent they would in certain circumstances be completely worthless.

I hope I haven't scared you off by this, because there are other examples where image insertion into chipmem has worked out beautifully. Just do remember that the OCS has its limitation, being a 30+ years old technology.

[project23]

Thanks for the replies guys. I think i'd still love to have a tinker - it just seems like such a powerful combination with a lot of potential. Even if its just offloading tasks. Plus the daemon code isn't all that lengthy so it should be feasible to work through it and understand how things are working.

At the very least, i'd like to try and get one of these things running. I am after some programming projects at the moment, and this sounds like a great opportunity to do at least something interesting - no matter how simple.

I've worked with similar pin-pitch I think three or four times now, and i'm getting a bit more confident with it. Is it possible for me bugger things up? Of course it is! But who cares, its fun! haha

Dropped ya a PM there Eriond, cheers!

Thanks for the replies guys,

John

[AndrewNC]

Any ideas on compatibility with the ACA500+? I've just got mine running happily at 42MHz after replacing my PSU, would be great to have both running on the same machine.

[Mick]

Could this be used to offer HDMI video output via the Pi board? the framebuffer is stored in memory right?

The same question goes for USB keyboard/mouse and LAN support I suppose but I think HDMI output by itself would be fantastic.

[project23]

Originally Posted by Mick

Could this be used to offer HDMI video output via the Pi board? the framebuffer is stored in memory right?

The same question goes for USB keyboard/mouse and LAN support I suppose but I think HDMI output by itself would be fantastic.

Hah! I literally just asked this in PM.

Okay so as far as I understand it, the Pi side is all software. So you'd be at the mercy of whatever graphics options linux provides. I can't personally see a problem with the idea of a sort of desktop manager taking drawing calls from a daemon listening to them from the Amiga.

That said, I have no idea how the monitor/gfx drivers on the Amiga side work. If it's possible to write a driver that simply sends workbench gfx requests over the shared memory, then theoretically this could be picked up by the Pi and rendered on the Pi side.

However - you'd be limited by the speed of the interface with the Pi, but i'm not sure this is a concern?

Overall it'd be a pretty big project in my opinion. Whether you could cut out the desktop manager part by simply having the daemon draw primitives directly to the X session - i'm just not sure. But either way it'd be a pretty big task.

Alternatively you could do something similar to the web interface showcased above, and have X just repeatedly render the inbound screen from the Amiga. This would be a much easier task, but you'd be limited in terms of graphics capabilities.

Honestly I think you hit the nail on the head with the USB support - to begin with adding support for say, a simple USB mouse will probably be the easiest way for someone to get to grips with interfacing a custom Amiga driver with the Pi.

Personally, I plan on simply studying the source for the daemon, and going from there, working on very simple examples until I know what i'm doing, but I really am eager to see where this can all go!

I'm not affiliated with the devs in any way though, and all of what I just said could be incorrect - i'm just thinking out loud here!

Cheers,

John

[Niklas]

Originally Posted by Mick

Could this be used to offer HDMI video output via the Pi board? the framebuffer is stored in memory right?

The same question goes for USB keyboard/mouse and LAN support I suppose but I think HDMI output by itself would be fantastic.

Did you read about the RemoteWB application we have? Here's a photo of RemoteWB in action: https://imagebin.ca/v/4f3EeL7azSms.

I think maybe this is related to what you are asking for. The bitplanes used by Workbench are moved from A500-on board-memory to A314-memory, and then each frame the RPi reads those bitplanes, encodes them as a GIF image, and sends the GIF to a web browser via a web socket. The web browser takes the mouse and keyboard events and sends those back to the Amiga, so that the Workbench is controlled by those mouse and keyboard events. Instead of sending the image to a web socket it could be written to the HDMI output.

There are limitations with this approach though. There needs to be software running on the A500 that runs in the background and informs the RPi of where the bitplanes are stored, etc. The RPi does not have direct access to the custom chip registers, so there is no way for the RPi to get this information without some cooperation from software on the A500. Therefore this could not work with, for example, a game that takes over the Amiga.

[project23]

That would be fine in my view... Rgb output for games and HDMI for workbench.

I wonder if rather than using the bitplanes method, a driver of sorts could be written to divert graphics calls to the Pi via shared memory... Offloading the whole process and using the Pi as a sort of graphics card... With software either side to make it happen?

Again I'm really not familiar with how the Amiga graphics/monitor drivers work and what kind of requests they receive from workbench.

[Eriond]

Originally Posted by Mick

Could this be used to offer HDMI video output via the Pi board? the framebuffer is stored in memory right?

The same question goes for USB keyboard/mouse and LAN support I suppose but I think HDMI output by itself would be fantastic.

Regarding the HDMI output; It could, but there are physical limitations. Let me explain:
As you might have seen from the pictures, the A314 is actually a HAT placed on top of the RPi, and then the whole package is turned upside-down and shoved into the trapdoor compartment.

There reason for this design is to have the USB and Ethernet ports accessible. But that came at the cost of loosing access to the power port, HDMI connector and audio jack, because all of them are now facing the Amigas RF shield next to the floppy. We had to push the RPi as far up as possible to get clear from the keyboard. Even now, I had to print thin (0,5mm) custom insulators that protect the soldering side of the RPi GPIO pins from coming into contact with the metal tray of the A500's keyboard.
If anyone can figure out a more clever mechanical approach, please let me know. I'm not entirely satisfied with how it looks right now, but it was the best we could conceive at the time.

Sending mouse movements and keypresses from the RPi to the Amiga is already accomplished by Niklas' RemoteWB code. What's missing is to capture that data on the RPi from physically attached devices, but that should be a reasonable task for someone who's interested in writing their own code for the A314 driver model.

[Mick]

Originally Posted by Niklas

Did you read about the RemoteWB application we have? Here's a photo of RemoteWB in action: https://imagebin.ca/v/4f3EeL7azSms.

That looks great for remote access but yeah I was thinking more along the lines of Indivision where you can just hook it up to a TV and get a display in realtime. I see now it was mentioned earlier but a lot of the technical jargon is over my head.

Can you not add a socket to sandwich between for example Denise to gain access to the RGA(?) bus/registers?

[project23]

Now that I think about it, a full graphics card application would probably require addressable space in excess of what is available via chipmem.

Perhaps as mick suggests, one day in the future the hardware could be adapted to make use of the rgb bus similar to the Indy. I'll stop prattling on about graphics options now hahaha.

I'd settle for simply being able to code Pi side drivers for mouse support.

Graphics or no, the possibilities for this thing are pretty endless I think.

John

[Eriond]

Originally Posted by Mick

Can you not add a socket to sandwich between for example Denise to gain access to the RGA(?) bus/registers?

On the A600, one already has access to the RGA bus at the trapdoor expansion connector. Guess what I'm planning for next...

[project23]

Originally Posted by Eriond

On the A600, one already has access to the RGA bus at the trapdoor expansion connector. Guess what I'm planning for next...

Ahh you utter legend. I'll keep my A600 on standby lol.

[gulliver]

Hi Eriond,

Since Lukas Hartmann is also developing an open source Amiga expansion (in his case a Gfx card with audio and other expansion features), it would be great if you could both agree to define a common open source API to address ARM boards.

In this way you could both benefit from each others work and pave the way for a more compatible future for us all.

He already mentioned he would be more than happy to talk with you (translated from german when talking about your A314 board):

..."Pretty cool and surprising stuff. I especially like the "pi" command idea! Seems like 2019 is the year of Amiga ARM expansions, with my ZZ9000 being one of them. It would make sense to coordinate some kind of compatibility for our different hardware approaches, maybe."...

He can be contacted here:
https://mntre.com

He is also a user in the A1k.org forum with the nickname "mnmtm".

[project23]

Can I just ask a quick question.. Sorry I know I'm really hounding you guys today...

Am I right in thinking that where this thing will utterly shine right now is in any application that requires sequential access of large amounts of memory?

Take for example the mp3 player example. As I understand it you'd have the pi decode the audio, down sample it to something Paula can handle, then dump it to shared memory in a kind of short buffer. Say, 200k or thereabouts?

On the Amiga side you'd play the first 100k, then as the second 100k plays you'd have the pi overwrite the first part of the buffer with the third 100k and so forth and so on as the song plays.

Essentially the player should use no more than a 200k buffer as far as the Amiga is concerned, but this would be constantly changed by the pi.

Am I understanding that correctly?

John

[Eriond]

I am far from being a software expert, so Niklas is the one that could answer this in more depth, but essentially yes, that is how I would imagine it to work. Although we would probably do not need that much buffer space, because:

The A314 is designed to work in two different modes, depending how intrusive the installation process is allowed to be. If the end user doesn't feel comfortable to open more than the trapdoor hatch while installing, it will work in a VBlank interrupt mode, meaning the Amiga will check those previously mentioned communication buffers at 50Hz/20ms.

But if the user accepts installing an extra lead from the INT2 pin via a small hook to any INT2 location on the motherboard (we normally use pin 21 of the odd CIA, see attached picture), then the communication process is more event driven, and is slightly more "responsive". This matters the most for small packet transfers, but could be of importance even when streaming audio. If I remember it correctly, Paula has 4 DMA slots each raster line. Not sure how much data she manages to gather during each slot, but it can't be that much.

That is why I think a mp3 player implementation probably will get by with two buffers the size of 2 channels x number of sample bytes played during two screen drawing periods ~40ms/25Hz.
I'm on thin ice here, but a playback rate of 8kHz = 8000 samples x 2 (stereo) x 1byte/sample => ~16kB/s. Buffers according to my previous train of thoughts -> 1/25 x 16kB = 640bytes?


(btw, that picture gives you a hint of how tight the space is between the RPi's HDMI port and the RF shield)

[project23]

Ah I see what you mean now - very tight indeed! No worry as the USB slots alone will provide for enough fun.

That's an insanely small buffer, which perhaps just goes to emphasise how powerful the A314 (only just got that name BTW, lol, nice touch) is in this kind of application.

I mean 640bytes is essentially free.

So I take it the int2 line is useful for filesystem access and the like? I was wondering how that was implemented.

Cheers,

John

[Niklas]

Originally Posted by project23

So I take it the int2 line is useful for filesystem access and the like?

The INT2 cable is optional.

What happens is the following: when a314d sends a packet to the Amiga, a314d writes the packet to the com-area, and then writes to a CMEM register (A_EVENTS) to set a bit (A_EVENT_R2A_TAIL) that signals that a new packet has been written. This will make the INT2 pin active (driven low). If an INT2 cable is attached, Paula will notice this and invoke the shared INT2 interrupt handler, which calls the interrupt server of a314.device. The interrupt server will read and clear A_EVENTS, and the INT2 pin will then stop being driven low.

If no INT2 cable is attached then the a314.device interrupt server will instead be invoked by the VBlank interrupt handler, which fires once every 20 ms. The effect (of not having an INT2 cable) is that the delay from when a314d writes a packet until a314.device notices that will be somewhere between 0 to 20 ms. By attaching the INT2 cable there is no such delay.

Originally Posted by project23

I was wondering how that was implemented.

I realize now that I should really write a document that describes this In the mean while you could look at the source code and if you have any specific questions feel free to ask here or pm me.

[project23]

Ah I see, that makes sense.

Sorry I'm at work at the moment which is why my replies are so short and question filled.

I've had a quick look at the source code but will give it a good going over during the weekend. I fully intend on understanding how this works so I can start playing with it.

I'll drop ya a line with my many questions once I've done some proper reading!

Thanks again,

John

[Eriond]

Originally Posted by gulliver

...it would be great if you could both agree to define a common open source API to address ARM boards.

Thank you for your suggestion. I will make contact with Lukas to see if there is a common ground for our projects. I will post any such outcome after we have had a proper discussion developer to developer.

[kolla]

But why use paula for audio when you can use the pi audio output? AHI can output to a dedicated file, that is a socket/named pipe on the shared filesystem, where pulseaudio/jack/whatever can pick up the stream...