LisaList2

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. (See spreadsheet attached or link to google sheets below.)

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 (narrower 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:
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:
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
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
AC Coupling might help with creating a universal profile?

We've observed that a major difference between the composite video of the Lisa 1/2/5 and the Lisa 2/10 is a voltage offset. As a result, profiles developed so far may work for one model but do not work on the other. Since the shapes of the composite video signals are very similar other than the voltage offset, it may be that using the AC coupling option could solve the problem of making profiles that work for multiple machines.

Here are preliminary examples of profiles that use the AC coupling option, and in my limited testing (with one Lisa 2/10 and one Lisa 1/5), they work with both models.

These profiles are also the ones in the LisaAutoSwitch_.zip file attached.

As above, I still don't know if the lines after "palette=" are relevant, unnecessary artifacts from my fiddling with options, or somehow specific to my setup.

Lisa_AC_Coupled_Rect_.txt
sampling=1,1,1,1,1,1,1,0,1,0,4,0,0,0,0,4,1,1,1,1,87,256,256,256,256,47,61,256
geometry=88,8,720,364,720,364,2,3,0,0,20359472,896,900,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
genlock_speed=1
genlock_adjust=4
Lisa_AC_Coupled_Square_.txt
sampling=1,1,1,1,1,1,1,0,1,0,4,0,0,0,0,4,1,1,1,1,87,256,256,256,256,47,61,256
geometry=88,8,608,432,648,438,1,1,0,0,20375213,768,900,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
genlock_speed=1
genlock_adjust=4
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 two sub-profile settings in one file
• Auto-Switch between different profile files in one folder

AutoSwitch Method 1

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
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

AutoSwitch Method 2

By adding a file named "Default.txt" containing one line to a subfolder of otherwise normal (non auto-switch) Profiles, the autoswitch feature can switch between 2 or more sets of parameters.

eg. Default.txt contains
auto_switch=1

The attached zip is an autoswitch folder set up with two profiles (for Rectangular and Square pixels). These profiles are set to AC coupled, so may be a good starting point for both Lisa 1/2/5 and Lisa 2/10s. To use, unzip, and copy the resulting "LisaAutoSwitch_" folder to the /Profiles/6-12_BIT_YUV_Analog/Apple_/ folder of the Pi's card. Start up the RGBtoHDMI and use "select profile" to pick one of the profiles in the copied folder. You may need to tweak the sampling settings DAC-A, DAC-F for your particular Lisa.

Hardware Used

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
The CPLD board inside is labelled "RGBtoHD Mono+ LumaCode Iss.4 c 2018-24 Hoglet & IanB"

Documentation

Google sheets/attachment with info: https://docs.google.com/spreadsheets/d/1MQWPjfv43FGFSYOz6U3-sRAH9wJHWWzMEabpCMYLOIw/edit?usp=sharing

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

Yeah, I mainly wanted to get the idea out there into the world with what I know of the requirements in case it occurs to anyone else. I may give it a shot at some point in the future once it becomes more feasible to auto-sync the code to an emulated Lisa for compilation.

I think creating a sync tool/daemon that can be run under Workshop is probably my higher priority now that I've written my lisafs filesystem access tool. At least I can rapidly iterate most of what's needed using FreePascal first.

Quote from: Eschaton on February 05, 2026, 11:50:38 PMAnother thing that would be neat would be a port of the Lisa OS to another system with a 68020+PMMU or 68030 (or better). Having spent a lot of time recently looking over filesystem and other code, the Lisa OS is quite reasonably structured; the areas that would be most affected are:

Probably not something that I have time to mess around with, especially with the LisaFPGA project and all, but it would be awesome if someone looked into this! Imagine being able to run LOS on another machine...

Another thing that would be neat would be a port of the Lisa OS to another system with a 68020+PMMU or 68030 (or better). Having spent a lot of time recently looking over filesystem and other code, the Lisa OS is quite reasonably structured; the areas that would be most affected are:

• System startup and exception handling
• Device drivers
• Anything VM/MMU-related
• Anything that has explicit dependencies on display size

Of the above, the only thing that might present an interesting challenge is the VM/MMU stuff, and even then it shouldn't be that challenging because Lisa's MMU is just offset/limit style (like the 68451) and it's straightforward to emulate one using the more sophisticated PMMU.

I suppose there's also the issue of block storage that doesn't support a tag or label, but these days I'd just expect to burn an extra block per block on that. And at the application level it doesn't seem like there'd be any obstacle to remaining binary compatible with the existing Lisa OS and Workshop. (The latter would probably need binary patching to handle a different screen size. But probably not much more than that, it seems just as insulated from the hardware as every other application.)

I don't want to minimize the amount of work such a project would require, but it also wouldn't really be a research project, just a project with a sizable but concrete set of well-understood tasks to complete.

The seller, Calvin, is the same person who also made and sold me a modern PSU replacement. I have several examples that he made, and their performance has been inconsistent. Still, a genuinely impressive effort and they mostly work. I'm sure he's improved on them since.

I would be curious to see the innards of his replica mouse. As with the replica bezels made by MacEffects, I would feel a lot better about them if they had "replica" or similar markings. While I don't expect anyone to intentionally try passing them off as originals, and they can certainly be discerned from the real thing upon close inspection, someone who inherits one down the line might be unaware of the origin and assume it is genuine. Slippery slope, that.

Just saw this ebay listing: "Classic Lisa's Mouse 1:1 Replica":
https://www.ebay.com/itm/366177513413 . Seller located in Hong Kong.

It looks really authentic on the pictures, even has the usual dirt on the label. I assume the photos are of the replica, I don't see a good reason for them to post photos of a real mouse.

Someone put a lot of effort into making this, similar to the Lisa 1 front bezel replica, but this is even more complicated, as it has a PCB inside, along with numerous plastic pieces.

Quote from: AlexTheCat123 on February 05, 2026, 01:08:17 PMThanks, let's sure hope so! And thank you for your very generous donation!

No thanks needed — just happy to help clear a hurdle.

Thank you for giving this platform the second chance it deserves. This time, no landfills.

Quote from: coffeemuse on February 04, 2026, 05:52:39 PMAt least waiting on the LisaFPGA boards is just a patience test. Here's hoping good luck is on your side and the boards make it out before the factory closes.

Thanks, let's sure hope so! And thank you for your very generous donation!

Quote from: AlexTheCat123 on February 04, 2026, 05:30:43 PMHaving to wait on the LisaFPGA boards is just an inconvenience, but the board I need for school is actually really important, so I paid extra for expedited manufaturing on both boards to get my school one here fast because their site said that it would go into production before the 24th if I did that. But then on my order history page, it ended up saying that it wouldn't go into production until the 24th again!

Quote from: AlexTheCat123 on February 04, 2026, 05:30:43 PMI reached out to their customer service (who are really good by the way) and it turns out that this was a bug in the site; you weren't supposed to be able to pay extra to get an order in before the holiday if you placed your order after the 2nd. Given that it was a bug on their end, they're going to try their best to honor what the site said and squeeze me in before the factory closes, but if not then they'll just refund me the expedited fee. So we might end up getting the LisaFPGA boards earlier than March, but it's all just going to depend on whether they're able to get me into production quickly.

Fingers crossed that JLC's customer service comes through and gets you squeezed in before the holiday shutdown. That's a rough spot to be in with your school project deadline on the line. Hopefully the fact that it was a bug on their end works in your favor.

At least waiting on the LisaFPGA boards is just a patience test. Here's hoping good luck is on your side and the boards make it out before the factory closes.

Wow, I've gotten over $700 in donations since making my post last night. That's way more than I could've ever imagined; thank you so much to everyone who pitched in!

I just placed the order a couple hours ago, but I have some slightly unfortunate news about the timeline of things. Unbeknownst to me until I was about to place the order, JLC just closed down their 6-layer production line for the Chinese Spring Festival, and they won't even start fabricating my board until the 24th. So it probably won't be here until March 10th or so. If only I had placed my order two days earlier; if I had, then they would've put it into production now instead of waiting. But I just didn't know at the time. This is also a really big problem because I ordered a 6-layer board that I need for one of my classes at the same time, and I'm not going to be able to get my assignment done before the deadline if they wait that long!

Having to wait on the LisaFPGA boards is just an inconvenience, but the board I need for school is actually really important, so I paid extra for expedited manufaturing on both boards to get my school one here fast because their site said that it would go into production before the 24th if I did that. But then on my order history page, it ended up saying that it wouldn't go into production until the 24th again!

I reached out to their customer service (who are really good by the way) and it turns out that this was a bug in the site; you weren't supposed to be able to pay extra to get an order in before the holiday if you placed your order after the 2nd. Given that it was a bug on their end, they're going to try their best to honor what the site said and squeeze me in before the factory closes, but if not then they'll just refund me the expedited fee. So we might end up getting the LisaFPGA boards earlier than March, but it's all just going to depend on whether they're able to get me into production quickly.

If only it was a 2-layer or 4-layer board; those production lines are only closed from the 16th to the 19th and if I placed the order now, it would probably be done well before then anyway! But I don't even want to imagine having to design something around a super-dense FPGA with only 4 layers to work with...