Raspberry Pi Zero W on clockport, anything out there?

[eXeler0]

Originally Posted by Promilus

8><———
So now you have it... there are alternatives for what you are trying accomplish either feature-wise (wifi, sound, usb) or hardware-wise (so using definitively clockport but on different hardware than RPi). But you should be aware of how poorly that interface suits those needs.

I hear you, but to be clear, I was talking about a €10 RbPi ZeroW here and at that cost I wouldn’t call it overkill even if its power isnt fully utilized. It brings a lot of power and connectivity at a ridiculously low price so other alternatives would not be cheaper for the hardware itself (including the interface PCB).
But sure enough, if RBPiZero is a poor match and some other solution is better that that would be the preferred option. But since no such solution seems to exits anyway, it probably means the software side of it is a mountain too high to climb. The work needed for drivers on both sides (Amiga, RBPi/other solution) isnt gonna magically appear (Looking at you Google code generating AI)

[Niklas]

Originally Posted by eXeler0

I hear you, but to be clear, I was talking about a €10 RbPi ZeroW here and at that cost I wouldn’t call it overkill even if its power isnt fully utilized. It brings a lot of power and connectivity at a ridiculously low price so other alternatives would not be cheaper for the hardware itself (including the interface PCB).

This sounds like a reasonable idea to me.

Originally Posted by eXeler0

The work needed for drivers on both sides (Amiga, RBPi/other solution) isnt gonna magically appear (Looking at you Google code generating AI)

Adapting the A314 software (probably a314fs, ethernet and disk drivers are the most relevant) to this thing should be fairly straight-forward.

Building an interface card using a CPLD and maybe some memory doesn't sound hard, but of course someone still has to put in the time to actually design and build it, or else it won't happen.

[Promilus]

@eXeler0

I was talking about a €10 RbPi ZeroW here

Yes, I know, so let me be clear about that as well. I can hardly find any such boards available in stock in both local and global distributors (like Farnell) and those which are available from scalpers doesn't cost 10 euro but much more. That's why I'm rather skeptical about anything that's hardly available atm.

@Niklas - yes, but your design access memory nearly directly and with full width (16bit data path) while you can't do that with clockport devices. I guess it would take an ugly wrapper first to make it "fairly straight-forward" to adopt drivers from your project. When you think about that then one fairly straight-forward solution would be to dump clockport altogether and make card (for A1200 and CD32 which doesn't have chip ram add-on) with fastram and use RAM buffer located at some part of ranger mem (so it wouldn't collide in any 3rd party software) to share data between RPi and Amiga. That'd also allow full 32bit access for full 32b 68k making it even faster (and not constrained by chipset timing). But with that - you're just one step from PiStorm.

[eXeler0]

Originally Posted by Promilus

@eXeler0

Yes, I know, so let me be clear about that as well. I can hardly find any such boards available in stock in both local and global distributors (like Farnell) and those which are available from scalpers doesn't cost 10 euro but much more. That's why I'm rather skeptical about anything that's hardly available atm.

yea, availability is shit right now, but you suggest pistorm as a better alternative and that is not available at all for A1200 afaik?
I did manage to buy a couple of pi zeros for rgb2hdmi projects a while ago however, and it was at normal price, but yea, situation isnt good atm.

[Daedalus]

To be fair, availability problems are across the board - a semi-custom device using a microcontroller or even a CPLD + USB controller for example is likely to be affected by chip availability too, so it's in no better a state than the Pi Zero in that regard.

[Promilus]

@eXeler0

yea, availability is shit right now, but you suggest pistorm as a better alternative and that is not available at all for A1200 afaik

I've only pointed out PiStorm as solution which is in active development (with PiStorm32 being version for A1200) in contrast to clockport solutions which were ideas few years back and stayed that way (most likely for reasons already discussed).

@Daedalus - yes, many chips are hardly available nowadays but while there's no good alternative for RPi you can get plenty of chips having similar features from different vendors. So it's not a single source solution. Same goes with FPGA - you work on Intel devices and they become scarce? You can swap to Xilinx or Lattice or some smaller companies as well. When it comes to ARM SoCs... it's either Broadcom which is fairly powerful and cheap or things like i.MX with decent documentation, but expensive and lacks performance or things like Allwinner which is powerful but lacks proper documentation, or Rockchip which has documentation, is powerful but costly. BTW I don't really care all that much about IC shortages etc. It'd be good opportunity for the world to to reevaluate usage of microchips and how much of it goes to silly consumer electronics you can live without.

[Niklas]

Originally Posted by Promilus

When you think about that then one fairly straight-forward solution would be to dump clockport altogether and make card (for A1200 and CD32 which doesn't have chip ram add-on) with fastram and use RAM buffer located at some part of ranger mem (so it wouldn't collide in any 3rd party software) to share data between RPi and Amiga. That'd also allow full 32bit access for full 32b 68k making it even faster (and not constrained by chipset timing). But with that - you're just one step from PiStorm.

The interface I had in mind would be quite a bit simpler than that. I was thinking of the clockport as essentially a slightly faster parallel port. Using a simple CPLD and a small 8-bit SRAM it would be possible to share this memory between the Amiga and the Pi, and that way let them communicate. As you pointed out, reading and writing to this memory would not be like accessing normal memory, so that's where the services have to be modified to work with this interface.

[alexh]

Originally Posted by Niklas

The interface I had in mind would be quite a bit simpler than that. I was thinking of the clockport as essentially a slightly faster parallel port. Using a simple CPLD and a small 8-bit SRAM it would be possible to share this memory between the Amiga and the Pi, and that way let them communicate.

Can't you just wire the clockport directly to Pi GPIO (via level shifters) and handle everything in SW on the Pi?

[Daedalus]

Originally Posted by Promilus

@Daedalus - yes, many chips are hardly available nowadays but while there's no good alternative for RPi you can get plenty of chips having similar features from different vendors. So it's not a single source solution. Same goes with FPGA - you work on Intel devices and they become scarce? You can swap to Xilinx or Lattice or some smaller companies as well. When it comes to ARM SoCs... it's either Broadcom which is fairly powerful and cheap or things like i.MX with decent documentation, but expensive and lacks performance or things like Allwinner which is powerful but lacks proper documentation, or Rockchip which has documentation, is powerful but costly.

Of course you can pivot to a different chip, but that takes time and in many cases would be a significant or almost complete redesign, not to mention porting firmware and rewriting drivers. You can't just plug in a vaguely similar chip and expect it to work. For a hobby, that's not always as easy or as feasible as you seem to think. The chip I use for my Solas board has been out of mainline stock for over a year now. I started redesigning for a chip that was stocked and had similar capability, but guess what? After a few months that too was out of stock with over a year's lead time. Just as well it happened after only a few weeks' worth of my time had been spent - if I'd spent 6 months of my limited spare time redesigning the board and rewriting all the firmware and software, only for that chip to also disappear at the prototype stage, I'd be very tempted to abandon the project entirely. I don't have that time to waste, so instead I'll just wait until the original chip becomes available again in a year or two.

BTW I don't really care all that much about IC shortages etc. It'd be good opportunity for the world to to reevaluate usage of microchips and how much of it goes to silly consumer electronics you can live without.

Like custom Amiga peripherals?

[Promilus]

Like custom Amiga peripherals

Custom amiga peripherals are just few thousand units tops. And there are billions of smartphones, smartwatches, damn, earphones, cars etc. produced every year and you're made to believe it's essential to replace your fully working device with new model... Which leaves the world with increasing number of electronic waste and shortages of rare earth elements used for fancy new smartphones instead of e.g. cheaper batteries for electric cars and hybrid PV systems.

We've been rather carefree in how we use our resources and energy... it's going to change, rather sooner than later. This crisis is just contributing factor to re-evaluate some things and that's also going along with UE policy regarding electronic device longevity, repairs etc. BTW Amiga does not contribute to e-waste Far from that.

[Niklas]

Originally Posted by alexh

Can't you just wire the clockport directly to Pi GPIO (via level shifters) and handle everything in SW on the Pi?

I don't know if it's possible to get Linux to be "real-time enough" to serve this purpose..?

I read this article, https://www.suse.com/c/cpu-isolation...xample-part-5/, and it seems to say that it is possible to isolate a CPU core and run a single task on that core, and that task gets to run uninterrupted.

However, at the end of the article it says: "Note this desired result only happens with ideal settings on a perfect machine in a perfect world. Random noise is likely to be found on the trace and therefore the next article will be about disturbance chasing and troubleshooting." This makes me a bit suspicious that it may not work fully in practice. So maybe a CPLD is still good to implement the synchronous interface towards the Amiga.

[Promilus]

Linux - not really, bare metal - probably. As you said - it's better to access SRAM when amiga isn't and use that small 64K space for data exchange. It ain't that bad. NeoRAM for C64 uses 256B! And it can have 0,5-2MB of RAM! That's how small the window for data exchange is. 64K is capacity-wise rather ok but 8bit interface is limiting a lot. Especially when your CPU has 32b data bus.

[Daedalus]

Originally Posted by Promilus

Custom amiga peripherals are just few thousand units tops. And there are billions of smartphones, smartwatches, damn, earphones, cars etc. produced every year and you're made to believe it's essential to replace your fully working device with new model... Which leaves the world with increasing number of electronic waste and shortages of rare earth elements used for fancy new smartphones instead of e.g. cheaper batteries for electric cars and hybrid PV systems.

Indeed, but without that industry of creating incredibly cheap parts and manufacturing processes, Amiga expansions using just a few hundred of those parts simply would not be possible. Think of such peripherals as a happy byproduct of that industry.

[Niklas]

Originally Posted by Promilus

64K is capacity-wise rather ok but 8bit interface is limiting a lot. Especially when your CPU has 32b data bus.

Yes, I agree, the bandwidth would be quite limited compared to what the processor is capable of. But I'm thinking of this in the context of "what can be achieved by connecting a Pi Zero through the clock port (specifically)". It may not necessarily be the ideal solution, but it's a fun exercise.

Here's a possible layout for such an interface board. U1 is XC9572XL, IC1 is IS63WV1288DBLL-10TLI, IC2 is SN74LVC573APWRE4. Component cost perhaps around €30.

[Krashan]

Originally Posted by eXeler0

I realize that, also I guess my original question has been answered at this point - meaning nothing like this has been done so far

I've had connected Pi Zero to a clockport and got bidirectional low-level data transfer. Project was scrapped due to lack of time.

[eXeler0]

Originally Posted by Krashan

I've had connected Pi Zero to a clockport and got bidirectional low-level data transfer. Project was scrapped due to lack of time.

Hi, @Krashan thanx for sharing, anything learned during the project that might be worth mentioning?

[Niklas]

I uploaded my attempt at a design here: https://github.com/niklasekstrom/clockport_pi_interface. It's currently a PCB and Verilog for the CPLD. There is no software yet, but the design is similar to A314, so if it gets built it should be straight-forward (Promilus ) to adapt the software to it.

[eXeler0]

Originally Posted by Niklas

I uploaded my attempt at a design here: https://github.com/niklasekstrom/clockport_pi_interface. It's currently a PCB and Verilog for the CPLD. There is no software yet, but the design is similar to A314, so if it gets built it should be straight-forward (Promilus ) to adapt the software to it.

Wow, @Niklas, that was fast. You´re a magician.

[Krashan]

Originally Posted by eXeler0

Hi, @Krashan thanx for sharing, anything learned during the project that might be worth mentioning?

You need some simple hardware for interfacing, and then FIQ (fast interrupt) on the Raspberry is fast enough to handle clockport read cycle. It assumes bare metal of course.

[Niklas]

I soldered up my design and adapted the A314 software for it. It works well! The design, including software, is available on GitHub.





I only had a Pi 3A at home, but a Pi Zero 2W would obviously fit best.

Promilus, here's the changes needed to adapt the disk service, it's 10 lines added and 17 lines deleted.