Current sampling is a single parameter, explode this out to multiple parameters (with a common prefix like s_xxx samp_xxx or sampling_xxx).

Push the sampling parameter loading/saving down into the respective cpld implementation classes.

Due to the change in sync edge used.

My concern was this is meaningless in the context of the Atom CPLD, and if the Atom CPLD ever reached V3 then there may be unexpected consequences.

It's not used much:

defs.h:#define BIT_OLD_CPLDV1V2      0x08000000  // bit 27, indicates old CPLD v1 or v2
macros.S:        tst    r3, #BIT_OLD_CPLDV1V2
macros.S:        tst    r3, #BIT_OLD_CPLDV1V2
macros.S:        tstne  r3, #BIT_OLD_CPLDV1V2
macros.S:        tst    r3, #BIT_OLD_CPLDV1V2
macros.S:        tst    r3, #BIT_OLD_CPLDV1V2
rgb_to_fb.S:        tst    r3, #BIT_OLD_CPLDV1V2
rgb_to_hdmi.c:        extra |= BIT_OLD_CPLDV1V2;

More generally, we need to be review anything in main code base that is conditional on the CPLD version. It's more than likely wrong to be doing it this way, because version numbers are highly CPLD specific.

Instead, we need to extend the cpld "driver" interface in cpld.h to provide the required information in a clean way.

The only place it's really safe to check the cpld cpld version is a cpld specific driver.

Lines to look at include:

geometry.c:97:   if (((version >> VERSION_MAJOR_BIT ) & 0x0F) <= 1) {
geometry.c:101:   } else if (((version >> VERSION_MAJOR_BIT ) & 0x0F) == 2) {
osd.c:1589:   if (((cpld->get_version() >> VERSION_MAJOR_BIT) & 0x0F) < 2) {
rgb_to_hdmi.c:722:   if (((cpld_version_id >> VERSION_MAJOR_BIT) & 0x0f) < 3) {

EGA outputs inverted Vsync compared to CGA so composite sync will be inverted.
Sync inversion should be detected and can also be used to switch between CGA & EGA

If it can be done in bare metal, perhaps read the monitor's capabilities by EDID and adjust automatically?

In linux, you'd use tvservice -d edid.dat ; edidparser edid.dat

Perhaps TAG_GET_EDID_BLOCK in rpi-mailbox-interface.h is a clue.

The hope being that this removes the need to adjust the config file for different monitors.

In Mode 0-6 here's an example calibration:

INFO: Calibrating modes 0..6
DEBUG: sample point 0: diff:  sum = 0 mean = 0, min = 0, max = 0
DEBUG: sample point 1: diff:  sum = 9280 mean = 928, min = 86, max = 1842
DEBUG: sample point 2: diff:  sum = 7132 mean = 713, min = 330, max = 2486
DEBUG: sample point 3: diff:  sum = 5668 mean = 566, min = 290, max = 884
DEBUG: sample point 4: diff:  sum = 0 mean = 0, min = 0, max = 0
DEBUG: sample point 5: diff:  sum = 0 mean = 0, min = 0, max = 0
INFO: Setting sp_default = 0

Now, you can see at several positions the sampling is error free. In this case an offset of 0 is picked for the default sampling point (sp_default), because none of the later positions improve on that.

There is actually room for improvement here. If you re-order the measurements, it's cleared that actually offset 5 would have been a better choice, because it's in the centre of the minima:

DEBUG: sample point 2: diff:  sum = 7132 mean = 713, min = 330, max = 2486
DEBUG: sample point 3: diff:  sum = 5668 mean = 566, min = 290, max = 884
DEBUG: sample point 4: diff:  sum = 0 mean = 0, min = 0, max = 0
DEBUG: sample point 5: diff:  sum = 0 mean = 0, min = 0, max = 0
DEBUG: sample point 0: diff:  sum = 0 mean = 0, min = 0, max = 0
DEBUG: sample point 1: diff:  sum = 9280 mean = 928, min = 86, max = 1842

My current thought is to stop using cmdline.txt, and replace it with:

• a base config file for common settings
• one or more machine (or system) specific config files

Or maybe three levels:

• a base
• a machine type specific (e.g. Beeb)
• a machine instance specific (e.g. Dave's Issue 3 Beeb)

The same multi-line syntax the config.txt would be used

A particular setting could be set at any level, and the mode specific specific file would override the base file. I'm thinking these would just be read in order.

The system would search the SD card for these files, and populate a menu that would allow allow the user to easily select a new configuration.

Initially these files would be managed manually.

Later, any updated settings could optionally be written back to the currently selected configuration. (This needs careful thinking through. How to track what has changed, and is different to the value in the base config).

Sounds simple, but I bet it's not!

One wrinkle is how to deal with machines that have different modes (like the Beeb with Mode 0..7 and Mode 7). Are these done with separate files? Or with sections within a file (like config.txt allows conditional filters):
https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md

Seems this should be possible.

Advantage is that the core clock speed can remain at 400MHz.

Not clear that it can be set via the firmware property interface.

So would need to include some code to set the PLL registers directly.

Possible code to do this here:
https://github.com/F5OEO/librpitx/blob/8d0ff49fa7d7dc5f98c83a9876000254ae9edbaf/src/gpio.cpp#L139

If Six bits = On and FB Bits/pixel = 4 then the palette is slightly messed up when the OSD comes up. This is because capture_line_sixbits_4bpp captures 4 bit pixels.

At the very least, it's confusing that we have very similar options in both the geometry and sampling menu.

The one in the sampling menu ("Sample mode") specific to the "Normal CPLD" and controls the hardware sampling rate / size:
"Normal (3bpp)",
"Double (6bpp)",
"Half-Odd (3bpp)",
"Half-Even (3bpp)"

The one in the geometry menu ("Pixel sampling") controls how the software pixel copy loops handle each pixel:
PS_NORMAL, // Each sampled pixel is mapped to one pixel in the frame buffer
PS_NORMAL_O, // Odd pixels are replicated, even pixels are ignored
PS_NORMAL_E, // Even pixels are replicated, odd pixels are ignored
PS_HALF_O, // Odd pixels are used, even pixels are ignored
PS_HALF_E, // Even pixels are used, odd pixels are ignored
PS_DOUBLE, // pixels are doubled

Some of the pixel sampling options were useful for the Atom (using the Beeb adapter) with older CPLDs.

A second consideration is it allows a 2x width and 2x height frame buffer to be used, to get the better looking OSD font.

The benefit of rationalising this would be to reduce the size of capture line tables, meaning there is more change they could all be fully implemented.

In the capture line table, we have the following tables (15 in total):

• default (4bpp and 8bpp) x (normal vs normal_odd vs normal_even vs half_odd vs half_even vs double)
• mode 7 (4bpp)
• atom (4bpp and 8bpp)

Each table has 8 entries:

• 3bpp vs 6bpp (pixel samples)
• Off vs Fast vs Inband vs NTSC artifacting (palette control)

Show capture filename?

Are any unconnected RGB inputs floating or do they have internal weak pullups/downs?

If the buffer is >= 325 lines high there is a crash when double height selected (i.e make buffer 672x 650). Perhaps there is insufficient memory allocated for such large buffers?

PLLH is used to generate the HDMI pixel clock.

Not clear at the register level how to change this.

From the config file, it seems it's possible to specific the HDMI pixel click in hdmi_timings:

hdmi_timings=<h_active_pixels> <h_sync_polarity <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>

<pixel_freq> is in Hz

This value is probably used to set PLLH.

Should palettes be driven by txt files like modes and profiles or at least have the option for additional custom palettes in this way?

It seems that Saved Profiles use DOS line endings, and our original profiles use windows line endings.

dmb@quadhog:/media/dmb/67FC-977D/Saved_Profiles$ find . -name '*.txt' | xargs file
./BBC_Micro.txt: ASCII text, with CRLF line terminators

Just in case is causes obscure bugs in the future, we should pick one and stick to it

dmb@quadhog:/media/dmb/67FC-977D/Profiles$ find . -name '*.txt' | xargs file
./Atom.txt:                         ASCII text
./Atom_CPLD.txt:                    ASCII text
./BBC_Micro.txt:                    ASCII text
./BBC_Micro_24MHz.txt:              ASCII text
./Custom_1.txt:                     ASCII text
./Custom_2.txt:                     ASCII text
./Default.txt:                      ASCII text
./Electron.txt:                     ASCII text
./Oric.txt:                         ASCII text
./UK_101.txt:                       ASCII text
./ZX80-81.txt:                      ASCII text
./OAK_OTIVGA/CGA_Graphics.txt:      ASCII text
./OAK_OTIVGA/CGA_Text.txt:          ASCII text
./OAK_OTIVGA/Default.txt:           ASCII text
./OAK_OTIVGA/EGA.txt:               ASCII text
./OAK_OTIVGA/MDA.txt:               ASCII text
./PC/CGA.txt:                       ASCII text
./PC/Default.txt:                   ASCII text
./PC/EGA.txt:                       ASCII text
./PC/Hercules.txt:                  ASCII text
./PC/MDA.txt:                       ASCII text
./TSENG_ET3000AX/CGA.txt:           ASCII text
./TSENG_ET3000AX/CGA_Keen.txt:      ASCII text
./TSENG_ET3000AX/CGA_on_VGA.txt:    ASCII text
./TSENG_ET3000AX/Default.txt:       ASCII text
./TSENG_ET3000AX/EGA.txt:           ASCII text
./TSENG_ET3000AX/EGA_on_VGA_25.txt: ASCII text
./TSENG_ET3000AX/EGA_on_VGA_28.txt: ASCII text
./TSENG_ET3000AX/VGA_Graphics.txt:  ASCII text
./TSENG_ET3000AX/VGA_Text.txt:      ASCII text

The Pi Firmware supports HDMI CEC, as do most TVs (on my LG it's called SIMPLINK)

Some things we could try:

1. Give RGBtoHDMI a friendly name

By setting the cec_osd_name property

2. Automatically switch the TV on from standby when powering up

Maybe this happens automatically on some TVs; it doesn't on mine

3. Relay remote control commands from the TV

This might allow you to navigate the Pi's menu system using the TV Remote.

(this obviously requires lots of work on the Bare Metal side)

I think I just damaged a CPLD by plugging the 'hat' PCB back into an unpowered Pi while being connected to the computer RGB & sync source. (This was on a PC so Pi powered via 5v supply)

I have done this multiple times but after doing it this time, the Vertical sync was very jumpy, mostly when pressing the buttons but occasionally when it was just sitting there.
The source had +ve Hsync (mostly low) and -ve Vsync which would be mostly high so maybe allowed enough current to flow to cause issues.

I tried reprogramming the CPLD but that didn't help so I replaced it and so far that appears to have fixed it so we definitely need some protection on the inputs. Any thoughts on the best approach for this? Diodes or something else?

Ian suggested this based on his experience of the ZX80, which stops generating Sync when it's busy.

The wait_for_vsync code would need to be adapted with a timeout (how long?)

Dave

It takes about 40 seconds to write a capture to a sandisk card and it seems to hang up completely when writing to kingston or verbatim cards (waited a few mins).

TinyPNGOut is uncompressed, so a Mode 0--6 screen ends up ~1064KB.

Worth trying a switch to LodePNG...

See https://lodev.org/lodepng/

dmb@quadhog:~/atom/RGBtoHDMI/src/scripts$ grep HAS_MULTICORE ../*.[chS]
../armc-start.S:#ifdef HAS_MULTICORE
../armc-start.S:#ifdef HAS_MULTICORE
../armc-start.S:#ifdef HAS_MULTICORE
../armc-start.S:#ifdef HAS_MULTICORE
../arm-exception.c:#ifdef HAS_MULTICORE
../capture_line_atom_4bpp.S:#ifndef HAS_MULTICORE
../capture_line_atom_8bpp.S:#ifndef HAS_MULTICORE
../capture_line_mode7_4bpp.S:#ifndef HAS_MULTICORE
../defs.h:#define HAS_MULTICORE
../rgb_to_hdmi.c:#ifdef HAS_MULTICORE
../rgb_to_hdmi.c:#ifdef HAS_MULTICORE

BigEd: Just a tiny thought Dave: to avoid the problem of the vsync bar potentially being off screen, could you add in a second bar which is, I don't know, 150 lines later? Then one or other of them would always be visible.

I'd suggest staring with the following:

• feature
• improvement
• bug

There's a reasonable initial list already set up (click the wheel icon next to labels)

You can still buy 1280x1024 monitors (unlike 1600x1200) and they seem to be quite common. They are closer to 4:3 than current widescreen monitors and should be ideal for the beeb as integer scaling from 640x256 is straightforward. However each mode on the BBC has a different horizontal position so you either have to capture more than 640 pixels which eliminates simple integer scaling or manually adjust the delay after each mode change. Maybe some sort of automatic adjustment could be implemented. This issue also affects PCs where the text and graphics versions of the same resolution have different offsets due to the character ROM delay. I have seen this sort of auto adjustment on LCD monitors following a mode change when the image moves left and right by a few pixels but the main issue with the BBC is detecting the mode change as there isn't always going to be a sync disturbance. It might have to be an auto adjust triggered by one of the configurable buttons.

e.g. Once an hour

See this post for why:
https://stardot.org.uk/forums/viewtopic.php?p=230515#p230515

Effectively reverting this commit: f369754

Dave

Used to detect a Vsync pulse.

Originally this was 6144ns, but Ian needed a larger value for the UK101 and ZX80.

Currently set to 8000ns.

Probably this should be configurable.

The delay value selected by calibration in modes 0-6 is wrong, should be 5 on a Master 128 but comes up with the wrong value so the in band demo doesn't work.
It selects 8 in 3bpp mode and 2 in 6bpp mode it should be 5 in 3bpp mode and 1 in 6bpp so maybe related to the new CPLD design. It seems to work OK in mode 7.
Note I think the blank pixels in each character cell on the 8x8 and 12x20 fonts are in different places.

EDIT: Note the in band demo doesn't work in 6bpp mode so you have to use the debug lines to check it

Currently this is hard-coded at 4.

So a 384MHz Core Clock gives a 96MHz CPLD Clock.

Other ratios are allow more flexibility in sampling clocks while still maintaining a reasonble core clock (which affects system performance).

Note, the framebuffer should be always be at least 500 pixels wide, or the OSD looks awful. This implies for older machines that are e.g. 256x192 that each pixel should be sampled twice.

Dave

I've been testing mode7 at 192 MHz clock rate with a new mode 7 half odd/even sample loop and it seems to be completely stable. Although this is well out of spec it is potentially useful for those beebs with a very asymmetric 12 Mhz clock as it doubles the resolution and it removed the last twinking pixels on one of my systems. Unfortunately with double the psync rate there is no time to read memory and so deinterlacing doesn't work.
Could this be implemented in the CPLD with a switch that enabled half odd/even mode? (i.e. put every other pixel in the shift reg and halve psync)
This would work with the existing capture loop without any changes.

To get most benefit you would probably need to increase the offsets to 4 bits to make full use of the double resolution and there's not enough registers to do that but maybe worth some experimentation.
The odd/even bit would be acting as the global MSB of all offsets (or maybe acting as the global LSB would be better?)

Calibrating with double height off has cursor generated errors

Not sure how this would work though...

How would a capture be initiated? All buttons are in use for menu navigation.

Possibly we could use the link (and spare gpio) as a 4th switch.

This allows us to get rid of the sampling7 and geometry7 params, which were always a bit of a bodge.

This is a precursor to #74 and #75

Ian, is there any reason this is a bad idea? (will mode switching be much slower, for example?)

Add support for detecting long and short button presses:

• A short button press action could happen on release
• A long button press action could happen on the "long press detection" timeout

Make the binding of the various actions to buttons configurable.

Actions would be:

• menu launch
• hdmi calibration (i.e. genlock)
• auto calibration (i.e. sampling clock calibration)
• take screen shot

Any others?

This would fix #49

Possible issue with spaces?

On one of my Master's the latest CPLD(s) no longer yield perfect calibration results.

Working back through the different CPLDs, this was introduced in v3.0:

Here's version 2.3:

INFO: Calibrating mode: 7
INFO:                            A      B      C      D      E      F   total
INFO: value = 0: metrics =     376    209    505   2237    247   1574    5148
INFO: value = 1: metrics =    1519      4     75     42   6112    440    8192
INFO: value = 2: metrics =       0    163   2046    471      4      8    2692
INFO: value = 3: metrics =    9909      9     18      6  11377      0   21319
INFO: value = 4: metrics =     104      0      0      0    863      0     967
INFO: value = 5: metrics =       0      0      0      0      0      0       0
INFO: value = 6: metrics =       0      0      0      0    219      0     219
INFO: value = 7: metrics =       0      2  12500      0      0    209   12711

Here's version 3.0:

INFO: Calibrating mode: 7
INFO:                            A      B      C      D      E      F   total
INFO: value = 0: metrics =       0    275      0      0      0      0     275
INFO: value = 1: metrics =       0     11      0     52   8369      0    8432
INFO: value = 2: metrics =    3781   1718   1616    112     66   1439    8732
INFO: value = 3: metrics =    1431     14     80     99   1827      1    3452
INFO: value = 4: metrics =     152      0   2219      6     31    235    2643
INFO: value = 5: metrics =    8331      0   2617      0      0      0   10948
INFO: value = 6: metrics =      56      0      2      0      0      0      58
INFO: value = 7: metrics =       0      8      0      0      0      0       8
INFO: Enabling half pixel delay
INFO: sp_offset = 3 3 3 3 3 3; half = 1; delay = 0; rate = 0
INFO: Optimizing calibration
INFO: sp_offset = 4 4 3 4 4 3; half = 1; delay = 0; rate = 0
INFO: Optimization complete, errors = 16

And here's the latest, version 6.1:

INFO: Calibrating mode: 7
INFO:                            A      B      C      D      E      F   total
INFO: Locked
INFO: value = 0: metrics =    4087   2130   1914    101     48   2095   10375
INFO: value = 1: metrics =    1519     12    106     90   1538     12    3277
INFO: value = 2: metrics =     160      0   1692      4     29    307    2192
INFO: value = 3: metrics =    9076      0   3297      0      0      2   12375
INFO: value = 4: metrics =      72      0     51      0      0      0     123
INFO: value = 5: metrics =      18      0      0      0      0      0      18
INFO: value = 6: metrics =     200      0      0      4      0      0     204
INFO: value = 7: metrics =      17      0     37   7812      0      0    7866
INFO: sp_offset = 5 5 5 5 5 5; half = 0; delay = 0; rate = 0; rate = 0
INFO: Optimizing calibration
INFO: sp_offset = 5 5 5 5 5 5; half = 0; delay = 0; rate = 0; rate = 0
INFO: Optimization complete, errors = 12

The main thing that changed here is the reference was changed from the falling edge of hsync to the rising edge. I wonder if the rising edge is slower?

I'm tested with the latest software from dev in all cases:

• program CPLD
• hit reset to restart the firmware
• hit auto calibrate

There may be multiple things going on here: in 6.1 compared to 3.0, there is no error free position at all in column A.

Switching to the 192MHz profile does improve it:

INFO: Calibrating mode: 7
INFO:                            A      B      C      D      E      F   total
INFO: value = 0: metrics =       0      0      5     25    168    650     848
INFO: value = 1: metrics =     171      0   2248      7     33      7    2466
INFO: value = 2: metrics =    8794      0  12756      2      0     10   21562
INFO: value = 3: metrics =   11465      0      5      0      0      0   11470
INFO: value = 4: metrics =      66      0    113      0      0      0     179
INFO: value = 5: metrics =      39      0      0      0      0      0      39
INFO: value = 6: metrics =       0      0      0      0      0      0       0
INFO: value = 7: metrics =      23      0      0      0      0      0      23
INFO: sp_offset = 6 6 6 6 6 6; half = 0; delay = 0; rate = 3; rate = 0

But this does feel like we might have taken a step backwards.

This needs further investigation.

Tried this a couple of days ago, and it nearly worked, but some of the OSD messages were lost.

According to info online the HDMI clock can run mach faster than 165Mhz to allow for higher resolutions. I tried using that to generate 70Hz 1080p to a HDMI 2.0 TV but it didn't work so maybe other registers need to be changed or different divisors used.
Some support for using >165Mhz has been added but is currently disabled
see here:
https://www.raspberrypi.org/forums/viewtopic.php?t=172057
which mentions hdmi_pixel_freq_limit

It would be great to look at Rob's Doom port, and see what it would take to get it running with RGBtoHDMI.

From trixster:

On the Atom the picture from cold is great and after an auto calibration it’s pretty much perfect but it certainly seems to degrade after a while, I guess as the machine warms up. Like something is drifting and errors start to creep in. An auto calibration or two after that does not get it back to perfect again, and sometimes it will choose maybe 2 for the offset, then 5, then 3 etc.. some kind of semi-continuous sampling and auto correction would maybe be in order?

Not sure if this is worth trying.

I was thinking in the vsync interval we could copy the current frame buffer to a massive memory buffer.

A 672x540 8-bpp frame buffer is 354KB. The Pi Zero has 512MB of RAM. Lets guess that 384MB is currently free. That's enough for 1110 frames (@25hz) or 2220 fields (@50Hz), which is 44 seconds.

(If we could do some simple compression on the fly, we could possibly do more.)

I'm guessing there is @20 blank lines, between the active region and the vsync pulse, which is 1.28ms.

Some memory benchmarks here:
http://www.roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks.htm#anchor9

        Raspberry Pi CPU 700 MHz, Core 400 MHz, SDRAM 400 MHz

     Memory Reading Speed Test 32 Bit Version 4 by Roy Longbottom

               Start of test Mon May 20 10:25:17 2013

  Memory   x[m]=x[m]+s*y[m] Int+   x[m]=x[m]+y[m]         x[m]=y[m]
  KBytes    Dble   Sngl  Int32   Dble   Sngl  Int32   Dble   Sngl  Int32
    Used    MB/S   MB/S   MB/S   MB/S   MB/S   MB/S   MB/S   MB/S   MB/S

       8     538    640    930    602    731   1094   1230    465    465 L1
      16     568    602    787    602    731   1023   1000    426    507
      32     292    256    310    276    262    330   1066    426    547 L2
      64     276    238    276    262    238    292    341    269    284
     128     189    170    193    182    170    200    222    196    204
     256     140    129    142    136    129    144    138    119    124 RAM
     512     138    127    138    134    127    144    131    111    119
    1024     136    127    138    134    127    144    124    111    119
    2048     136    127    138    132    128    144    128    111    121
    4096     136    128    138    134    126    144    128    111    119
    8192     138    127    138    136    127    144    126    111    119

                End of test Mon May 20 10:26:06 2013

 Max MFLOPS   71    160            38     91
 Max MIPS                  725                  645    423    320    320
 Max MOPS                  233

In terms of data rates, 354KB in 1.28ms is 276MB/s.

That would half if we worked with 270 line fields (138MB/s).

And half again in 4bpp mode (79MB/s).

Dave

Current geometry is a single parameter, explode this out to multiple parameters (with a common prefix like g_xxx geom_xxx or geometry_xxx).

Push the geometry parameter loading/saving down into the geometry class.

Changes are possible under 4 menus:

• processing
• settings
• geometry
• sampling

The challenge is:

• tracking what has changes
• deciding which level of profile a particular change belongs in

By level of profile, we mean either:

• /Default.txt
• /SomeProfile.txt
  or
• /Default.txt
• /SomeProfile/Default.txt
• /SomeProfile/SomeSubProfile.txt

A possible starting point is that all changes should be saved to the most specific level of profile that currently exists. i.e. the default files are manually maintained.

Can we think of any exceptions where this is clearly wrong?