RPi Zero 2 Support

[ryanm101]

https://thepihut.com/collections/featured-products/products/raspberry-pi-zero-2

The Raspberry Pi Zero 2 W incorporates a quad-core 64-bit Arm Cortex-A53 CPU clocked at 1GHz. At its heart is a Raspberry Pi RP3A0 system-in-package (SiP), integrating a Broadcom BCM2710A1 die with 512MB of LPDDR2 SDRAM. This upgraded package provides the Raspberry Pi Zero 2 W with its generous increase in performance.

[c0pperdragon]

I guess this could be nice upgrade path for the whole RGBtoHDMI project. I am pretty sure Ian already has something in mind for this....

[ryanm101]

I'm thinking the extra cores might allow mixing the audio data into the hdmi stream

[IanSB]

@c0pperdragon @ryanm101

Initially the Pi zero 2W was disappointing and didn't work at all well with the lower bit depth computers like the BBC and not at all with the 12bpp systems like the Amiga and Atari ST. There were two main problems

1. The memory has greater latency which led to glitches even at low bit depths
2. Reading the GPIOs on the Pi zero 2W is much slower than on the original Pi zero so getting 12bpp support for the Amiga and Atari working seemed impossible as the core couldn't be overclocked enough.

The only viable option was to see if reading the GPIOs from the GPU was any faster so I wrote some benchmarking code and got the following results:

Original Pi zero: ARM: GPIO read = 44ns, MBOX read = 40ns, Triple MBOX read = 47ns (15ns/word) GPU: GPIO read = 31ns, MBOX write = 9ns RAM: Cached read = 3ns, Uncached screen read = 96ns

Pi zero 2W: ARM: GPIO read = 60ns, MBOX read = 55ns, Triple MBOX read = 120ns (40ns/word) GPU: GPIO read = 35ns, MBOX write = 10ns RAM: Cached read = 2ns, Uncached screen read = 115ns

(MBOX are mailbox registers used to communicate between the ARM and the GPU)

As you can see from the above, reading the GPIOs in the zero2W was 36% slower which explained why it didn't work as 60ns is very close to the time for an Amiga pixel (69ns) not leaving enough time for anything else

Fortunately reading from the GPU was much faster so I moved the capture code into the GPU and now everything works on the Pi zero 2W as well.

This new code also runs on the Pi zero and has the benefit that almost no overclocking is required and it also means options like double height capture work for all 12 bit profiles so there may be scope for further image processing as well

Double height capture means that variable intensity scan lines are always available and the high res menu font will be used although you can change back to the old 8x8 font in the settings menu if you prefer.

I've released this new GPU capture code as Beta43 here: https://github.com/IanSB/RGBtoHDMI/releases

This is suitable for the original Pi zero / zeroW as well as the Pi zero 2W so please test and report any issues.

[solarmon]

@IanSB

Wow! Nice work! Thank you!

[ShoresOfNowhere]

@IanSB that's terrific!

I'll test this ASAP on my Amiga 500!

Thanks!

[c0pperdragon]

This is very good news, as I expect the Pi Zero to be soon phased out in favor of the Pi Zero 2.

[ShoresOfNowhere]

@IanSB It seems to work perfectly on my A500! I'm using @c0pperdragon 's denise interface board and a Pi0.

By the way, can this mean that now we have some free cpu cycles that can be used to sample stereo audio and add it to the HDMI out? I know, I'm becoming greedy... ;)

[IanSB]

@c0pperdragon

This is very good news, as I expect the Pi Zero to be soon phased out in favor of the Pi Zero 2.

In theory, the Pi zero and Pi zero W should still be manufactured for a few more years as this page https://www.raspberrypi.com/products/raspberry-pi-zero/ says "Raspberry Pi Zero will remain in production until at least January 2026" However it may become even harder to find one than it is now if the dealers decide to only stock the new zero 2W (There is a similar page for the Zero 2W which states January 2028)

BTW the new GPU software also works on the Pi2 and Pi3 / Pi3+ which isn't very useful for the standard models but the Pi3A and Pi 3A+ are smaller and will mechanically fit inside the Amiga so could be used as an alternative it any type of Pi zero is out of stock. (I haven't tested this as I don't have a 3A+ at the moment)

[ryanm101]

That's amazing @IanSB great writeup and it's really cool the move to GPU has improved the overall performance in the long run and expanded compatibility.

It's a shame about those initial findings on performance, though interesting that 'faster' hardware is not always better depending on your use case / tolerances.

Out of curiosity what are the metrics for the new GPU based code?

I wonder if a dedicated board with connector for the CM4 would be a worthwhile project, though i suppose the CM4 is likely overkill in terms of raw power.

[IanSB]

@ShoresOfNowhere

By the way, can this mean that now we have some free cpu cycles that can be used to sample stereo audio and add it to the HDMI out? I know, I'm becoming greedy... ;)

It's certainly a lot more possible than it was before as are other things

The main issue is getting the audio data into the pi zero. There is a peripheral that is designed to receive data from an audio A to D already built into the zero hardware but it uses GPIO pins that are already being used for video capture so either the board would have to be resdesigned or some other way of getting the audio in using something like a raspberry Pi pico which already has A to D converters built in.

[IanSB]

@ryanm101

Out of curiosity what are the metrics for the new GPU based code?

I haven't really done any specific performance measurements but obviously the overall performance is a lot better mainly due to the decoupling of the capture side (i.e. reading the GPIOs on the GPU) and the render side (writing to the screen on the ARM).

Although the GPU is faster at reading the GPIOs it's two cores (VPUs) are slower than the ARM overall for basic register based data manipulation because it only runs at 400Mhz vs 1000Mhz for the ARM, plus the ARM can do things in a single instruction that would take three instructions in the VPU. The VPU does have a lot of vector instructions which can manipulate arrays of pixels in parallel which would be a lot faster than the ARM but in this case they aren't really useful.

The GPU code is very minimal and just sits in a loop reading the GPIOs and packing two video samples into a single 32 bit word for writing to the mailbox registers basically acting as a FIFO buffer. The ARM then reads those registers and renders the result to the screen.

I wonder if a dedicated board with connector for the CM4 would be a worthwhile project, though i suppose the CM4 is likely overkill in terms of raw power.

I haven't finished support for Pi 4 type hardware yet so I don't know how well that is going to perform.

[ryanm101]

By the way, can this mean that now we have some free cpu cycles that can be used to sample stereo audio and add it to the HDMI out? I know, I'm becoming greedy... ;)

It's certainly a lot more possible than it was before as are other things

The main issue is getting the audio data into the pi zero. There is a peripheral that is designed to receive data from an audio A to D already built into the zero hardware but it uses GPIO pins that are already being used for video capture so either the board would have to be resdesigned or some other way of getting the audio in using something like a raspberry Pi pico which already has A to D converters built in.

I suppose as this is bare metal this might be a nogo.. but what about a USB A-D converter via the OTG as a PoC? Initially i'd not worry about size constraints, as i'm sure once there is a couple of solutions clever people here will fix that particular issue, i mean if there isnt enough power / time to do the mux the idea will still be dead in the water.

[solarmon]

@IanSB

Just quickly tried it on my Pi0 W v2 on a CPLD based RGBtoHDMI board and it is working nicely - I haven't noticed any issue yet, but I haven't tested much yet.

Thank you once again for making this happen!

[solarmon]

@IanSB

Just tried on a Raspberry Pi 3A+ and it seems to be working great too!

[c0pperdragon]

@IanSB

The enhanced capabilities of the Pi Zero 2 gives me an idea for an internal HDMI solution for the C64 which could look very much like the adapter solution for the Amiga: By a CPLD in a pickup-board under the VIC-II, the data communication can be monitored and forwarded to the Pi in a suitable format. There the inner workings of the VIC-II are then emulated and the picture is generated just like for the RGBtoHDMI. The amount of data transfered would be somewhere in the range of 12-14 bits at 2 MHz.

Using a 5V-tolerant CPLD in BGA-package (one of the series that are used in the RGBtoHDMI already), this would be a pretty cheap device from the hardware perspective, while not exactly easy to manufacture.
The real work is of course in the software that needs to emulate the VIC-II. I don't know how this could fit into the RGBtoHDMI project, so I wanted to hear your thoughts on this.

Reinhard

[ShoresOfNowhere]

@c0pperdragon have you seen the vicII kawari project?

http://accentual.com/vicii-kawari/

[c0pperdragon]

@c0pperdragon have you seen the vicII kawari project?

http://accentual.com/vicii-kawari/

Yes, I know the kawari. This aims to provide a VIC-II replacement. My idea would keep the original the VIC and just sniffs the data lines as was done with my C64 component video mod board.

[ShoresOfNowhere]

@c0pperdragon have you seen the vicII kawari project? http://accentual.com/vicii-kawari/

Yes, I know the kawari. This aims to provide a VIC-II replacement. My idea would keep the original the VIC and just sniffs the data lines as was done with my C64 component video mod board.

I own your c64 comp mod board, my c64 loves it! :)

[IanSB]

@c0pperdragon

The real work is of course in the software that needs to emulate the VIC-II. I don't know how this could fit into the RGBtoHDMI project, so I wanted to hear your thoughts on this.

Do you intend to write the VIC-II emulation part yourself or is that something you want me to do?

[c0pperdragon]

I am not altogether sure, if this whole approach would actually fit the RGBtoHDMI project at all. Maybe I will just eventually build some dedicated software exclusively for this C64 mod. I have also in mind to support audio as well by means of software emulation of the SID. All this is highly specialiced and I think it is best to not try to integrated this into a one-size-fits-all solution. Maybe I could re-use some bits and pieces from the RGBtoHDMI software, mainly your GPU sampling routines and the part that drives the HDMI hardware.

My ideas of the hardware side of things are pretty far already. With a CPLD running with the C64 pixel clock and 5 wires to the Pi (1 clock, 1 data sync line and 3 data bit) I could transfer all relevant bus data into the Pi. With 24bit per cycle (at approx 1MHz), this sould be doable. My question right now is basically if it is possible to do the sampling via the GPU in a kind of asynchonous manner, so the CPU can retrieve the data in bursts while building each individual scan line. Also the GPU would need to permantenly fetch data without interruption so nothing is missed even in the horizontal blanking area.

[solarmon]

@IanSB

Is audio mixing really a viable option with the Pi Zero W 2?

On the RGBtoHDMI board on the CDTV Video Slot that I'm working on, the audio signals seem to be available on the Video Slot connector, so it could easily be fed to the Pi header.

Otherwise, if it is not possible, I might see how I can also integrate a separate HDMI audio injector board in to the design.

[IanSB]

@solarmon

Is audio mixing really a viable option with the Pi Zero W 2?

I think so as a core could be dedicated to the task but I haven't looked at the practicalities of getting the raw audio data into the Pi in any detail yet.

[IanSB]

I've just released Beta 45 of RGBtoHDMI: https://github.com/IanSB/RGBtoHDMI/releases Please give it a try and report any issues

This version is a release candidate for the next stable release which will be the first stable one to support the Pi zero 2W. It also now works fully on all Pi models including the Pi4 (except the original Model A and B with the 26 pin GPIO header).

It would be useful if someone could confirm that FFOSD and grey screen standby still work as I don't have the necessary hardware to check those.

[solarmon]

@solarmon

Is audio mixing really a viable option with the Pi Zero W 2?

I think so as a core could be dedicated to the task but I haven't looked at the practicalities of getting the raw audio data into the Pi in any detail yet.

@IanSB

That is great to hear!

I assume the L and R audio channels could/would be fed to two separate GPIO pins on the Pi? On my RGBtoHDMI CDTV board, the L and R audio signals are available on the Video Slot - so it could be easily be routed to GPIO pins on the Pi header.

If we allocate the GPIO pins now, then I can update the design on my RGBtoHDMI CDTV board, in anticipation for this feature.

[solarmon]

I've just released Beta 45 of RGBtoHDMI: https://github.com/IanSB/RGBtoHDMI/releases Please give it a try and report any issues

This version is a release candidate for the next stable release which will be the first stable one to support the Pi zero 2W. It also now works fully on all Pi models including the Pi4 (except the original Model A and B with the 26 pin GPIO header).

It would be useful if someone could confirm that FFOSD and grey screen standby still work as I don't have the necessary hardware to check those.

@IanSB

Thank you. I'll see if I can find some time to get that tested.

I can donate hardware to you to allow you to test it in future - PM me if you are interested.

[c0pperdragon]

Just gave the firmware a go with my C64 and my Raspberry Pi Zero (1). Works out of the box with the provided profile. No calibration needed.

[IanSB]

There was a bug in the raspberry pi firmware which resulted in the core voltage being set too high on the pi zero. Raspberry Pi have now fixed this bug but if you have tried beta42 to beta49, those releases had the buggy firmware so please upgrade to beta51 which has the fixed version of the firmware:

https://github.com/IanSB/RGBtoHDMI/releases

Some more details on the bug are here: https://github.com/raspberrypi/firmware/issues/1667