Lapis ProColorServer hanging in 7.5.5?

I've installed a Lapis (Pro?)ColorServer (8?), in my SE/30 and I'm seeing weird behavior, some good, some bad:

• Contrary to internet reports, it doesn't appear to require a driver to work at a basic level. Immediately from the boot screen the external display is used, which is nice. Whoever owned it last also has it set on 640x480 67Hz so it fortunately works over VGA.
• When booting 7.1, it appears in Monitors control panel as a generic 8-bit 640x480 display and the color depth can be configured normally. It sees both monitors.
• However, 7.5.5 hangs at boot. It makes it all the way to the desktop and deadlocks. The mouse can be moved but Finder never loads.
• If you load without extensions, it boots fully but running the Monitors control panel manifests the same behavior. The mouse can be moved but Finder no longer responds.

I suspect whenever the Monitors control panel is INIT'd, it's somehow confused by the card and stalls, and running it manually leads to the same behavior?

Interestingly, the Macintosh Garden driver archive includes a copy of the Monitors control panel for 7.5.5 so I tried replacing the original copy with that and adding in the extensions but that doesn't seem to help.

I did find this thread by cheesestraws referencing similar behavior, but again, it happens even with no driver at all, so I'm not really sure something deeper isn't happening here: https://68kmla.org/bb/index.php?threads/lapis-procolorserver-24-ii-and-system-7-5.34297/

Further, a later edition of the manual for the LC version(also on Macintosh Garden) references 7.5 and still has SE/30 installation instructions, so it definitely seems to be compatible, but I can't seem to find the right combination of drivers to make 7.5 happy.

The card seem curious, they have an onboard EPROM, I dumped mine and sure enough it specifically references 640x480. There's another ROM image floating out there for what looks like the 8*16 model, which is slightly different.

I'm not really aware of how PDS operates, but is the boot ROM actually augmented by the card's ROM? I notice what look kinda like drivers in the device ROM itself, I'm wondering if they conflict directly with memory space used by Rominator (there's one in there) or something 7.5 simply doesn't expect? That makes me curious if an EPROM upgrade might actually fix the issue (mine is dated 92, the one from the internet is 93).

Any thoughts?

did Lapis ever even write drivers for system 7.5.x?

my understanding when I looked into this a few years ago (had the same or a similar model card) was that getting lapis cards running on anything higher then 7.1 is pretty unlikely.

there should a DeclROM on the card, its what lets the Mac use it without software drivers. its a long shot but all I can suggest is see what ROM version you have and see if there was ever a later ROM released that might work.

Hah, I think that was my first thread here.

This is anecdotal, but a number of Lapis cards seem to have ... various issues running on > 7.1, and I don't get the impression that they were very enthusiastically updated. I've not looked into why they don't work. But at this point if I got a Lapis card I wouldn't be surprised if it was 7.1 and less only.

And yes: basic drivers are in the ROM on the card itself, to make it as near plug and play as possible. This is a general theme with Mac cards later than the SE. You can usually tell what they are by using something like TechTool to see what functions they provide, and they often don't need any on-disc drivers to function (though, as with graphics cards, often they work better with extra software)

Chopsticks said:

did Lapis ever even write drivers for system 7.5.x?

Click to expand...

Per the manual uploaded by cheesestraws, at least some of their cards were likely supported, because they make passing reference to 7.5:

If your monitor brand/type has Multiple Resolution sup-port, and system 7.1 or 7.5 is installed on your Macintosh, a resolution change (or “switch on the y”) function is supported by the LC 2421.

Click to expand...

there should a DeclROM on the card, its what lets the Mac use it without software drivers. its a long shot but all I can suggest is see what ROM version you have and see if there was ever a later ROM released that might work.

Click to expand...

Ah! I thought that was just a NuBus thing, I need to do some more reading.

I do wonder if a newer ROM would work, or even trying the 8*16 ROM with it despite it being, I think, only an 8.

I'm also really curious if forcing 7.5 to use an older Monitors control panel might work in a perverse way.

eharmon said:

Ah! I thought that was just a NuBus thing, I need to do some more reading.

Click to expand...

They designed the expansion system so that you can write ROMs in the same way for NuBus and PDS cards, even, so if your hardware engineers were up to it you could use the same, or very similar, ROMs on different expansion slots.

eharmon said:

Per the manual uploaded by cheesestraws, at least some of their cards were likely supported, because they make passing reference to 7.5:

Click to expand...

Yeah, the LC ones I have claim to support 7.5. But I get the impression (and again, this is only anecdotal) that they are the exception rather than the rule.

For reference, from my card's ROM:

Copyright
1990,1991 Lapis Technologies Inc
LC-COL8-LCA 1x4 srsc one
LC-COL#7.1Gn 4 VRAM 1 sizes
03/03/92 2:00 AM djb
Display_Video_Apple_LAPISDisplayServerII

Click to expand...

And an 8*16 ROM I found:

Lapis ProColorServer
16 PDS
PDSr32-PC16 1M 7sizes
analog monsense r32 bit adr PDS ProColor 16 1MEG
2/8/93 pc16pds10 SCB
Copyright
1992,1991,1990 Lapis Technologies Inc

Click to expand...

Surprisingly different. I wonder if this is actually a DisplayServer II/PDS?

This just props up my conviction that Lapis' branding was all over the place .

cheesestraws said:

This just props up my conviction that Lapis' branding was all over the place .

Click to expand...

Yeah it's a disaster. All the DisplayServer drivers also seem unhappy as they chime on boot up and/or display an X through their icon.

Using the Monitors control panel from 7.1 seems like a bust. It runs no problem, doesn't hang like the 7.5 version, and lets me configure the card. But the system still hangs on boot with extensions loaded.

The fact that loading with no extensions works is so, so odd to me. Disabling all extensions in Extensions Manager doesn't work, so I really wonder if it's a conflict with one of the base extensions 7.5.5 always leaves enabled. It totally, totally works fine if you hold Shift on boot though.

I guess now I drag basic extensions out one-by-one until it stops hanging!

Well that doesn't work either, with no extensions and no control panels, it still hangs.

Disabling extensions must disable functionality in the system file as well? I wonder if that's documented anywhere.

Does Disk Tools do it?

cheesestraws said:

Does Disk Tools do it?

Click to expand...

Ooh good question. Just tried it and it boots no issues (once I patched it for IIsi ROM support). Very curious.

I'm putting myself through a crash course in MacsBug. The system is definitely in an endless loop checking something(?), which is why it isn't actually locked up and the mouse moves.

ROMBase is $40800000 and it appears to be caught in a loop around $4080DB7C, so I'm guessing Finder is stuck in a loop in a Toolbox call?

Maybe with another 4 hours I can figure out how to find out what call it made .

With just naive stepping all the way through, I see something like:

• Call _DMGetDisplayComponent at $000C11C6
• Call _DMGetDisplayMode at $000C1200
• Then we spend a bunch of time in _Status, _vGoDriver, _vWaitUntil, _vSyncWait, bouncing in and out of Dispatcher and the Process Manager.
• We MIGHT set a MemErr, which is then picked back up by _FlushEvents? I'm not quite sure I follow it.
• Later it looks like we might clear MemErr and bounce through a bunch of handlers.
• Unclear about those two.
• Then we loop again, once again calling _DMGetDisplayComponent from something in the system heap.

So unsurprisingly, it seems like the system is trying to get some sort of display properties, failing, and incorrectly handling that error so it loops back on itself instead of failing, giving up, or continuing. Setting a breakpoint on _DMGetDisplayComponent shows we loop around every few seconds.

But I'm not sure exactly what _DMGetDisplayMode is trying to do or why it's not working. Or if I'm reading the disassembly correctly around the potential MemErr. Or how to map those addresses to the actual System to get a better offline disassembly.

There's a header in the SuperMario ROM which defines the functions involved, but they're presumably implemented in the system: https://github.com/elliotnunn/super...oj.1994-02-09/Interfaces/CIncludes/Displays.h

I think DisplayManager 1.0 was new for 7.5.1 and 2.0 for 7.5.2, per this game development guide (page 47): https://ubm-twvideo01.s3.amazonaws.com/o1/vault/GD_Mag_Archives/GDM_AprMay_1996.pdf

Installing the DM 2.0 SDK was even possible on 7.5.1 for testing, apparently. I wonder if that's the difference, that the 7.5.3 Disk Tools (which I tried) doesn't include Display Manager, which is somehow confused by the driver not exposing some information?

I might try a 7.5 original install to see if it works...

Triple self-reply, but it's worth an entirely new post: 7.5 boots just fine!

So, contrary to popular belief, Lapis cards do work on 7.5, but presumably not later versions, even 7.5.1 might not work, but I'll check and edit if it does. I'll also try installing the Display Enabler on 7.5 to see if it manifests the same behavior.

So I think my hunch above is correct. Display Manager was embedded into the System in later versions of 7.5 and isn't compatible with the Lapis cards, somehow it's confused by them and gets stuck in an endless loop trying to read their properties.

I wonder if it can just be ripped out of the System file? If I were smarter, I bet the endless loop could be patched too, since it just seems like a bug. The fact that 7.5.3's Disk Tools image works either means Display Manager remained optional and was removed for space, and/or it has the corresponding calls patched out when it was built too...hard to tell.

All that said, the driver is missing an sResource Name in TattleTech. Part of me wonders if there's just a bug where empty names cause things to break. It couldn't be that simple though, could it?

Oops, exceeded the edit limit, so make that a quadruple reply while I learn things live

Installing Display Manager onto 7.5 via the Display Enabler does, in fact, cause the same hang on boot. Stepping through the debugger the flow looks basically the same, we step through _DMGetDisplayComponent and get stuck.

Looking at MemErr it seems like it was a red herring. Now that I've learned such basic things like printing memory locations, it seems that it's being set to zero so nothing is wrong.

The Display Enabler has a crazy amount of code with a bunch of inits, I can't imagine how you'd excise it from later versions of 7.5. Seems more like it needs a patch to stop misbehaving but I can't yet see what it's doing wrong, let alone how to patch it out.

Final musing for tonight: @cheesestraws, I ran your declfoo tool on my ROM dump, just to dump some more information:

id 0x01 @ 0x00100c
sRsrcType => 0x00001c
sRsrcName => 0x000020
"8 Bit Color 640x480"
BoardId => 0x000342
PRAMInitData => 0x00002c
PrimaryInit => 0x000034
Code for 68020: 462 bytes starting at 0x00105c
VendorInfo => 0x00020a

id 0x80 @ 0x0012ba
sRsrcType => 0x0000dc
sRsrcName => 0x0000e0
"Display_Video_Apple_LAPISDisplayServerII"
sRsrcDrvrDir => 0x000110
sRsrcHWDevId => 0x000002
MinorBaseOS => 0x000100
MinorLength => 0x000100
field 0x80 => 0x00087a
field 0x81 => 0x0008c6
field 0x82 => 0x000912
field 0x83 => 0x00095e

Click to expand...

It's curious that it DOES have an sResourceName, but it doesn't seem to show up in TattleTech which is....odd. It just shows as blank.

I think I got it wrong above, Display Manager 1.0 shipped in 7.1(.2?), and 2.0, which some sources claim is only for newer machines, with 7.5.2(?). Why 2.0 seems to break everything remains unclear. But I'm wondering if neutering the gestalt values to lie that we only have 1.0 might work? The hang occurs after the progress box disappears, which would make me think it's not in an INIT but when something in the system chooses to call out to DM, perhaps even Finder?

eharmon said:

It's curious that it DOES have an sResourceName, but it doesn't seem to show up in TattleTech which is....odd. It just shows as blank.

Click to expand...

The RAM copy of the sResources that things like TattleTech use isn't quite the same as just the whole set from ROM, it's edited a bit. Specifically, the initialisation code in ROMs for graphics cards is encouraged, per the Apple documentation, to remove sResources it doesn't want the system to try to use.

My declfoo tool isn't very good, btw: you might be better off with bbraun's 'catdecl' tool from here: http://synack.net/~bbraun/declrom.html

A quick thought: have you tried deleting the 'scrn' 0 resource from the System and seeing if it'll boot without errors then?

cheesestraws said:

The RAM copy of the sResources that things like TattleTech use isn't quite the same as just the whole set from ROM, it's edited a bit. Specifically, the initialisation code in ROMs for graphics cards is encouraged, per the Apple documentation, to remove sResources it doesn't want the system to try to use.

My declfoo tool isn't very good, btw: you might be better off with bbraun's 'catdecl' tool from here: http://synack.net/~bbraun/declrom.html

A quick thought: have you tried deleting the 'scrn' 0 resource from the System and seeing if it'll boot without errors then?

Click to expand...

I gave catdecl a try, and amusingly it crashes while reading the video mode...that's kinda suspicious given the hang:

Format block:
bytelanes = 0xf
testpattern = 0x5a932bc7
format = 0x1
revision = 0x1
crc = 0x39d6734c
length = 4096
offset = -4076
Resource 1
sRsrcType: 1 0 0 0
sRsrcName: 8 Bit Color 640x480
BoardId: 66
PrimaryInit: cpuid: 2 len: 474
VendorInfo:
VendorID: Copyright �1990,1991 Lapis Technologies Inc
PartNum: LC-COL#7.1Gn 4 VRAM 1 sizes
Date: 03/03/92 2:00 AM djb
Resource 128
sRsrcType: 3 1 1 645
sRsrcName: Display_Video_Apple_LAPISDisplayServerII
RsrcDrvrDir:
id: 0, len: 1906
sRsrcHWDevId: 2
MinorBaseOS: 0x0
MinorLength: 0x1fc00
Video Mode 128:
[1] 77746 segmentation fault ./catdecl -I lapis.rom

Click to expand...

I'm gonna take a side trip to see what's making it crash since that's pretty curious.

I haven't tried wiping scrn, I'll give that a go too.

EDIT: If I don't print the Mode Name, it doesn't crash anymore:

Video Mode 128:
Dev Type: 0
Page Count: 1
Video Parameters:
vpBaseOffset: 4
vpRowBytes: 80
vpVersion: 0
vpHRes: 0x480000
vpVRes: 0x480000
vpPixelType: 0
vpPixelSize: 1
vpCmpCount: 1
vpCmpSize: 1
vpPlaneBytes: 0
Video Mode 129:
Dev Type: 0
Page Count: 1
Video Parameters:
vpBaseOffset: 4
vpRowBytes: 160
vpVersion: 0
vpHRes: 0x480000
vpVRes: 0x480000
vpPixelType: 0
vpPixelSize: 2
vpCmpCount: 1
vpCmpSize: 2
vpPlaneBytes: 0
Video Mode 130:
Dev Type: 0
Page Count: 1
Video Parameters:
vpBaseOffset: 4
vpRowBytes: 320
vpVersion: 0
vpHRes: 0x480000
vpVRes: 0x480000
vpPixelType: 0
vpPixelSize: 4
vpCmpCount: 1
vpCmpSize: 4
vpPlaneBytes: 0
Video Mode 131:
Dev Type: 0
Page Count: 1
Video Parameters:
vpBaseOffset: 4
vpRowBytes: 640
vpVersion: 0
vpHRes: 0x480000
vpVRes: 0x480000
vpPixelType: 0
vpPixelSize: 8
vpCmpCount: 1
vpCmpSize: 8
vpPlaneBytes: 0

Click to expand...

That's ... interesting.

Can’t you just add a name to the mode in ROM?