RGB2HDMI profile update?

[sigma7]

sigma7 recommends substituting 3,4 for 2,3 in the geometry= line, preferring a pixel ratio of 4/3 to 3/2 (height/width).

I've not yet tried that myself, and now doubt that it would make an improvement in accurately representing the CRT image. The suggestion was based on calculations using a raster adjusted to fit most of the viewable area through the front panel in conjunction with the observation that the usual recommendation for a 3:2 aspect ratio of pixels does not look right.

Since then, anotherLISAguy measured an actual alignment graticule (a very rare service part) and we found that the "official" CRT adjustments put the aspect ratio of the pixels between 3:2 and 4:3, but closer to 3:2.

[Lisa2]

I've decided to give this another look. I can confirm that I need to turn 75R termination ON for the Lisa 1 and OFF for the 2/10.

Thank you for confirming this!   

Due to the composite video's analog signal path and 40+ year old Lisa hardware combined with variations in RGBtoHDMI builds, this solution is never going to be plug-and-play.  Some tweaking of the settings is bound to be required for each user. 

Rick

[sigma7]

Here are two RGBtoHDMI profiles that I've got working on a Lisa 1/5 for H (rectangular pixel) and 3A (square pixel) ROMs.

These are using the YUV CPLD configuration, so are stored in eg.

Profiles/6-12_BIT_YUV_Analog/Apple_/Apple_Lisa_R2_.txt
Profiles/6-12_BIT_YUV_Analog/Apple_/Apple_Lisa_S2_.txt

The underscore preceding .txt is needed for the profiles to appear as an available choice when "mono_board_detected()".

It may be that the RGB CPLD configuration would be more tolerant of variations between machines... dunno. The CPLD configuration can be changed from "Settings Menu"-"Update CPLD Menu", wherein I see BBC, RGB, and YUV options.

Some parameters in the sampling= line apply to only one of RGB/YUV, and other settings apply to both, but not all in an identical way. I'll try to document what I've mis/understood in case someone feels like taking it farther.

After barely starting to understand what the parameters are for, I'm truly amazed at the accomplishment this device represents.

I focused on trying to understand the geometry and sampling lines, so I don't know if the lines after "palette=" are relevant, unnecessary artifacts from my fiddling with options, or somehow specific to my setup.

Most experimentation was using the stock 20.37504 MHz dot clock. Since some CPU boards use the more readily available 20 MHz, I tried a variable frequency generator to see if another profile would be needed for those. I found that the device would sync to a wide range of frequencies from 19.5 to 21 MHz within a couple of seconds, so it seems the frequency specified in the geometry line doesn't need to be precise. The clock tolerance can be set as high as 100000 but it seems 5000 is sufficient. More below under "Auto-Switching".

Comparing to other published profiles, I see there is a variation in DAC-E Sync and DAC-F Y/V Sync voltages. I found this setting to have a narrow range of working values (narrow than the range of published profile values). Hence if you try any of these "known working" profiles and find it doesn't work properly, I suggest you try adjusting DAC-E or DAC-F (whichever one is not "256" = disabled) in the Sampling menu. The working range I observed is smaller than expected board to board variations due to using 5% resistors, so as Rick says, it seems probable that the profile will need to be tweaked per machine. More investigation may reveal a configuration that makes this setting less sensitive.

Rectangular Pixels (eg. H ROMs) with 3:2 pixel aspect ratio output:

Code Select Expand

sampling=2,2,2,2,2,2,2,0,1,0,4,0,0,0,0,4,0,1,1,0,77,256,256,256,44,256,256,256
geometry=88,8,720,364,720,364,2,3,0,0,20375213,896,5000,379,4,0,0
palette=Mono_(2_level)
palette_control=3
ntsc_type=2
pal_oddline=2
normal_deinterlace=1
ffosd_overlay=1
scanline_level=0
Square Pixels (3A ROMs) with 1:1 pixel aspect ratio output:

Code Select Expand

sampling=2,2,2,2,2,2,2,0,1,0,4,0,0,0,0,4,0,1,1,0,77,256,256,256,44,256,256,256
geometry=88,8,608,432,648,438,1,1,0,0,20375213,768,5000,450,4,0,0
palette=Mono_(2_level)
palette_control=3
ntsc_type=2
pal_oddline=2
normal_deinterlace=1
ffosd_overlay=1
scanline_level=0
Lisa 2/10

I tried these profiles on a Lisa 2/10 and initially had a black screen. I tried turning off the 75R terminator as suggested by Stepleton, and that did reveal the video, confirming the settings are at least close. I turned the terminator back on (to preserve signal quality in theory), and reduced the DAC-A and DAC-E values to 48 and 7 respectively (I selected the middle of the workable range of each).

eg. for my 2/10

Code Select Expand

sampling=2,2,2,2,2,2,2,0,1,0,4,0,0,0,0,4,0,1,1,0,48,256,256,256,7,256,256,256
Auto-Switching

RGBtoHDMI has a profile auto-switch feature, so that if your computer has multiple video modes, you don't have the manually select a new profile each time the computer changes modes.

As far as I can tell, this can be implemented in two ways:

• Auto-Switch between sub-profile settings in one file
• Auto-Switch between different profile files

For giggles, I tried setting up auto-switching for the Lisa to distinguish between rectangular and square pixels, and preliminary testing suggest it works. The auto-switch test appears to use the "clock tolerance" parameter of the geometry settings to determine if another profile should be considered. I found the default of 5000 for the clock tolerance was too large for auto-switching to respond correctly to the change in Lisa video.

I noticed that with auto-switching active, there was some inconvenient switching when using the RGBtoHDMI menus, so I recommend having regular single profiles for each video mode available as well if using the auto-switch technique.

eg. For Lisa 1/2

Code Select Expand

sampling2=2,2,2,2,2,2,2,0,1,0,4,0,0,0,0,4,0,1,1,0,77,256,256,256,44,256,256,256
geometry2=88,8,608,432,648,438,1,1,0,0,20375213,768,900,450,4,0,0
sampling=2,2,2,2,2,2,2,0,1,0,4,0,0,0,0,4,0,1,1,0,77,256,256,256,44,256,256,256
geometry=88,8,720,364,720,364,2,3,0,0,20375213,896,900,379,4,0,0
auto_switch=4
palette=Mono_(2_level)
palette_control=3
ntsc_type=2
pal_oddline=2
normal_deinterlace=1
ffosd_overlay=1
scanline_level=0


Thanks to Sapient Technologies for providing the RGBtoHDMI device used for this experimentation.

I'm not sure where Todd got it originally, but it looks like this one with an injection molded case, 3.5mm jack and RCA cable:
https://cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=DB-IB-1V


I'll edit this post to add/correct details as they are discovered.