Raspberry Pi Pico as Akiko on Clockport

[Gorf]

After some reading of the specs of the new "Raspberry Pi Pico" microcontroller I came to the conclusion that this 4€ board might be a good fit for the Amiga Clockport (with some level-shifters of course)


But what exactly would be the best use-case?
Obviously it could provide the "basics": port expansion, SPI and I2C...
All of this already exists in other form of course...

One could add some SPI Flash to the mix and provide a storage device - most users with a Clockport will already have other solutions.

But how about some kind of co-processor?

That is why I chose the provocative title for this thread.
Obviously it is not possible to provide a binary compatible Akiko C2P functionality this way - but you could use the PiPico to do some batch processing including C2P routines.

Additionally to its two ARM M0 cores the RP2040 has two fast integer divider units that work in parallel to the M0 cores and two "interpolators" that provide some DSP-like functionality:

"The interpolators are used to accelerate audio operations within the SDK, but their flexible configuration makes it possible to optimise many other tasks such as quantization and dithering, table lookup address generation, affine texture mapping, decompression and linear feedback."

https://datasheets.raspberrypi.org/r...-datasheet.pdf

Ok - so this thread is obviously just a proposal for some brainstorming.
What are you thoughts?
What else could this board be used for in an Amiga and how could it be implemented?

[britelite]

Originally Posted by Gorf

Obviously it is not possible to provide a binary compatible Akiko C2P functionality this way - but you could use the PiPico to do some batch processing including C2P routines.

The bandwidth would be a huge problem for C2P applications, so that's definitely not something you'd want to use it for.

[Matt_H]

The clockport is an 8-bit port, isn't it? But there are 3 additional unpopulated pin headers surrounding it. Would populating them and using them all together allow for a 32-bit expansion? (My understanding is that the original design intent was to offer a 1200 configuration with 1MB chip RAM and to use those headers for an additional 1MB... but I don't know if other expansions were conceptualized via the complete port).

I believe the CD1200 added an Akiko via the trapdoor, so it's certainly possible to add one to the architecture without having to grab signals by soldering wires all over the board.

[Gorf]

@ britelite

Yes the A1200 Clockport has some stupid wait-states ... some other Clockports on expansion cards are faster ...
As far as I could find out the max speed is about 1 MB/s ... so I see your point for C2P.
Would still be enough for some audio-applications or other more complex calculations that are not that real-time critical but would block the 68K for a long time ... encryption decryption eg.

@Matt_H

As far as I know the unpopulated are indeed for the 1MB ChipRAM expansion, that ended up to be already on the board - so nothing you can really do with it.
Except maybe depopulate the 2nd MB from the motherboard, and attach something like the A314 to the unused headers ...

But that would be a job for a real Pi and not the Pico ...

There you probably could implement something like a Akiko - but the registers would live in the Chip-Ram space

[hooverphonique]

Originally Posted by Gorf

As far as I could find out the max speed is about 1 MB/s ... so I see your point for C2P.

I'm not sure where I have this info from, but IIRC, the speed is more like 150kB/s.

[Daedalus]

The clockport waitstates are a little annoying alright, but you can still easily beat 150kB/s. After all, a typical 16-bit stereo, 44.1kHz audio stream needs around 172kB/s, and the clockport audio cards available back in the day could do 48kHz full duplex, which is around 380kB/s. So 1MB/s is probably not an unreasonable guess, but the CPU overhead is disproportionate because of the waitstates, so I'm not sure it would be worthwhile offloading processing to a standard clockport module...

Adding a signal from one of those Gayle adaptors could significantly speed it up, because there are actually 3 decodes that relate to the clockport. The RTC and Spare decodes both have the waitstates and are the ones actually connected to the port. The Net_CS one is not connected to the header sadly, but offers the same access without the waitstates. This is at 0xD90000 instead of 0xD80000, and is the port used by the A604n for example to give faster access to USB controllers.

Yep, the other pins of the clock port headers are directly connected to the Chip RAM chips, and are of little use as a result. Losing chip RAM is a high price to pay for any peripheral. If you were really looking to hook something fast up to an A1200 and the trapdoor slot wasn't an option, the next best thing is probably going to be the ROM sockets with a Gayle hook-up, as used by the FastATA. The full 32-bit data bus is available there, and enough decoded space to do what you need.

[Gorf]

Originally Posted by hooverphonique

I'm not sure where I have this info from, but IIRC, the speed is more like 150kB/s.

From this forum of course

http://eab.abime.net/showthread.php?t=78373

I got over 700k/sec with RapidRoad USB on A1200 Clockport

The theoretical max speed of the clockport is just over 1MB/s.

[Gorf]

Originally Posted by Daedalus

T
Adding a signal from one of those Gayle adaptors could significantly speed it up, because there are actually 3 decodes that relate to the clockport. The RTC and Spare decodes both have the waitstates and are the ones actually connected to the port. The Net_CS one is not connected to the header sadly, but offers the same access without the waitstates. This is at 0xD90000 instead of 0xD80000, and is the port used by the A604n for example to give faster access to USB controllers.

In the A1200 ... would a simple wire from AA-Gayle pin 16 (Net_CS) be sufficient?

[Daedalus]

Yeah, that's all you would need, the rest of the signals are the same. If that signal was available on the clockport instead of Spare_CS, every clockport device would be capable of running faster.

[Gorf]

Originally Posted by Daedalus

Yeah, that's all you would need, the rest of the signals are the same. If that signal was available on the clockport instead of Spare_CS, every clockport device would be capable of running faster.

As long a it is just a matter of soldering a single wire from one pin to the PiPico-Board ... problem solved.
(Even my CyberstormPPC expected A3000 users to do so back in the day...)

So what speed could we expect without wait states? Is it still bound to DMA cycles? 3.5 MB/s?

[Daedalus]

Indeed. For neatness I'd like to have a board piggybacked on Gayle with all the typically used connections easily accessible on pins, but I've also soldered wires directly to chip pins on my on A1200 so I can't lecture

I haven't calculated the speed myself,, but the complete Spare_CS cycle is 7 or 8 clocks long IIRC, so reducing that by 3 will give you a not-quite doubling of potential speed. Maybe 1.8MB/s if we take 1MB/s as the Spare_CS theoretical maximum, at a vague estimate.

[Gorf]

7-3 = 4
Four 14MHz cycles equals a 3.5 MHz clock ...
3.5 MHz times one byte equals 3.5 MB/s

[Daedalus]

Indeed, but by that same token you would have 2MB/s with a 7 clock cycle. Remember that the CPU can't have every cycle - it's only every second cycle at best.

[Gorf]

true ... however:

this speed or even less should be enough for a couple of things.
How about some Datatypes that use the Pico as decoder?

Even mp3 should be possible to do on the M0 (and we have two of them):

https://forum.arduino.cc/index.php?topic=591006.0

[Daedalus]

Yep, lower bandwidth, less critical stuff it would be ideal for. There are already MP3 decoders for the clockport, but having a more flexible one that delivers the audio data back to the Amiga and/or can also do datatype decoding would be very cool!

[pandy71]

Guys but there is IDE connector (16 bit, ready to use) - in fact Pico could be used in transparent way as: first accelerated IDE controller (byte swap on RP2040) and secondly do some data processing so not only C2P but also for example HAM conversion especially that both CPU cores can be easily overclocked over 400MHz. small RAM is a bit of challenge but... With help of the PIO and after adding some parallel to serial and serial to parallel (like 74HCT595 and 74HCT597) limited number of I/O on Pico can be workarounded. In fact i'm thinking on using Pico as sound card (capable to capture Paula data too so first setp to Paula emulation/extension), also as scandoubler with features (Pico is capable to do DVI in software so i can imagine 12 bit RGB capture, 24 bit output, Pico as intelligent RAMDAC something like DCTV, HAME-E, P2C - even in Shires single video line will require less than 5KB), side to this it looks like very neat CIA 8520 replacement (Pico has USB host so it should be possible to hook USB keyboard and emulate regular Amiga KB natively as CIA). Most challenging seem to be a MC68k emulation - Pico with PIO and DMA should be capable to nicely emulate at least MC68000. Last idea is floppy HD (so MFM encode/decode in PIO, Paula DMA to send/receive RAW uncoded data with 500kbps speed so twice faster floppy and no fuzz with PC HD at all), Pico connected to floppy port could be used o simulate more than 4 floppies (SEL1, SEL2, SEL3 is in fact 3 bit so 8 devices can be addressed also other lines are connected to CIA so i can imagine some nibble mode I/O).

[alexh]

I know that Akiko isn't really the subject of this thread, but you have to remember that the C2P in the real Akiko was added for systems that had no fast RAM. (i.e. plain CD32) When you have fast RAM (like most A1200's), C2P is faster using the CPU than an Akiko.

[pandy71]

Originally Posted by alexh

I know that Akiko isn't really the subject of this thread, but you have to remember that the C2P in the real Akiko was added for systems that had no fast RAM. (i.e. plain CD32) When you have fast RAM (like most A1200's), C2P is faster using the CPU than an Akiko.

Well, this could be Akiko Plus with some elements of the primitive GPU (like transformations, interpolation, color space conversion etc), i bet way faster than MC68060 capability... Pico has something that may do this possible - PIO together with DMA may be a missing key to provide Amiga widely available extension to 30 year old functionality.

[cheshirenoir]

I keep wondering if it could be the basis for a floppy drive buffer to allow high density floppy drives to be used as Amiga FDDs without modification. Hold the data until Gary / Gayle are ready and trickle it across. Sort of like a buffer.
I assume it's impractical, but, y'know, just putting it out there :-)

Chesh

[pandy71]

Originally Posted by cheshirenoir

I keep wondering if it could be the basis for a floppy drive buffer to allow high density floppy drives to be used as Amiga FDDs without modification. Hold the data until Gary / Gayle are ready and trickle it across. Sort of like a buffer.
I assume it's impractical, but, y'know, just putting it out there :-)

Chesh

Gary in terms of the floppy has nothing to do except simple logic to control motor. Data from Paula can be stored partially (FIFO) in Pico (it has 264KB of RAM where required maximum amount of RAM to buffer whole track is 12.5KB .

One of companies offered similar solution to provide HD floppy for Amiga without special floppy drive that is able to spin with lower speed (150 RPM vs normal 300RPM), they use DRAM as FIFO buffer and principle was easy, track was sent to FIFO - from floppy drive with normal speed and from Amiga with half of speed, introduced latency was approx 100ms (half of track). In fact using Pico as smart FIFO offer possibility to provide very slow (500kbps) HDD (but with DMA). USB or FLASH card (SD etc) can be presented to Amiga as floppy with more than 160 tracks (and perhaps more than 11/22 sectors).