1bit mode

[drmpwagner]

Is is possible to use RGBtoHDMI for a somewhat simpler but probably unusual case. The monitor for an old computer is gone and a replacement is not available anymore. I would like to interface the old hardware to a HDMI screen. It is a black&white only system with a resolution of 1024 by 809 and a 38.7 Hz refresh. The active picture is surrounded by a border that can have a defined bit-pattern. All in all its a 1216 by 925 pixel. That sums up for a Pixelclock of roughly 45Mhz and a H-Sync of about 35.8 kHz. (These are all first numbers, I have to verify porches etc. with a calibrated oscilloscope). However, my question is: would it be doable with the given CPLD and a 1-bit fork of the code (and probably a 1bit Buffer board), or am I asking to much from the hardware?

[IanSB]

However, my question is: would it be doable with the given CPLD and a 1-bit fork of the code (and probably a 1bit Buffer board), or am I asking to much from the hardware?

I think it could be made to work but it might require a different approach to sampling the pixel data and change of CPLD design. At the moment it runs the sampling clock at 6x or 8x the pixel clock which would be 270Mhz or 360Mhz and the CPLD maxes out at around 170-200Mhz. There are faster versions of the CPLD which might help but another alternative would be to reduce the sampling points to 3 or 4 which would lead to a sampling clock of 135Mhz / 180 Mhz.

As an alternative, if the pixel clock is available, a variation of the CPLD could be designed to run at the pixel clock rate so only 45 Mhz. Twelve bits are transferred at a time from the CPLD to the Pi so at 1BPP that would result in a transfer rate of only 3.75 Mhz and the transfer rate currently maxes out at ~15 Mhz so that seems possible.

[IanSB]

Just had another thought:

If the pixel shift register is accessible, (which would usually have an 8 bit input), you could hook up the 8 bit board in parallel to those bits and it would then look like an 8 bit per pixel source running at 5.625 Mhz. That should work with the existing CPLD and would only require a custom capture loop to remap the incoming data to an appropriate video mode.

[drmpwagner]

Thank you very much for your comments.

As for the first suggestions, I already thought that with only a black and white signal, the sampling rate could be lower, although is must be at least twice the pixel clock as far as I know. The transfer rate should leave enough headroom.

As for the second suggestion, I am not sure whether the shift register is accessible, I fear not. Even is such an interface is possible it will not be 8 bit per pixel but rather 8 pixel transfer in a row (no need to shift).

I made the initial calculations from the available specs as I do not have the computer yet. It will come without a monitor, just with a video signal to analyze - that will be fun!

However, I was wondering whether I can start with the basic design shown here, i.e. CPLD and Raspi. It will not just be new control software, I will have to change the CPLD configuration as well, as it will be probably faster in black and white only? Your number convinced me it is worth a try. Choosing another CPLD will be much more difficult.

As I am new to CPLDs any useful pointers would be highly appreciated.

Stay safe!

[IanSB]

As for the first suggestions, I already thought that with only a black and white signal, the sampling rate could be lower, although is must be at least twice the pixel clock as far as I know.

This project samples in an unusual way: Rather than sample at > 2x the pixel clock frequency with an antialiasing filter which is the normal style of sampling for unknown signals, it synchronously samples at just the pixel clock frequency which only works if the sample rate exactly matches the original pixel clock rate. This means that the details of the orginal signal such as number of clock cycles per line must be known exactly although they can be "fine tuned" to get them exact visually with suitable test content being displayed. In order to get the sampling phase correct, it runs the CPLD clock at 6x or 8x the pixel clock frequency which gives 6 or 8 points on each pixel to sample the video. If you sample at the edges of each pixel, you will get noise but if you sample in the centre of each pixel you will get a reliable sample of the orginal signal and selection of the right one of these 6 or 8 points is done during calibration setup (which only needs to be done once)

The reason for this approach is that you end up with a bit exact digital representation of the original frame buffer in the Pi's frame buffer so it's like the signal is digital "all the way" even though it may pass through an analog stage. Normal sampling can't do that and you end up with an approximation of the original frame buffer with all the artifacts of analog sources like noise and ringing.

As you can see this means 6x45 (270Mhz) or 8x45 (360Mhz) and that is too much for the standard 10ns rated CPLD which starts to fail at around 170Mhz. There is a 5ns rated version of the CPLD that might work but I've not tried it.

As an experiment, I tweaked the CPLD design to use 3x (135Mhz) and 4x (180Mhz) instead of 6x and 8x and that seemed to work in the brief test I did and it might be usable on the standard CPLD although I'm not certain that will give enough adjustment range for reliable operation.

The other question is how is the video signal output and at what levels? (e.g. composite video and sync, separate video and sync, 1vPP or TTL etc)

The standard input to the board is TTL but there is an optional analog board that contains comparators to level slice the input to produce a few TTL levels. That might work up to 45 Mhz but it is a bit marginal.

EDIT: There is a source I can try this with: I have an Acorn Archimedes and in addition to it's normal RGB analog output, it has a special 1024x1024 mono ouput with a pixel clock of 48 Mhz which is a reasonable approximation of your signal above. I'll try that once I've finished my current work on the Amiga.

[IanSB]

FYI High clock rates are now supported by adding x3 and x4 clock multipliers as well as the original x6 and x8 and also by adding a 1 bit per pixel option (on the green input) so the latest builds should now work with your system. However you will probably still need a way to extract the sync and mono video at TTL levels similar to the existing analog board which probably can't handle the bandwidth of a 45 Mhz signal. A similar design using faster comparators could be substituted. See https://github.com/hoglet67/RGBtoHDMI/pull/158/commits/956af488caee978852711def0e9ffc866de6ba9b