• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Lapis ProColorServer hanging in 7.5.5?

eharmon

Well-known member
Can’t you just add a name to the mode in ROM?
I'm not actually sure why catdecl is crashing yet, it might be something more deeply weird, I haven't looked through the code except to comment some sections out. If it's just missing names (and those are also needed by DM 2.0), that's likely an avenue, yeah!
 

eharmon

Well-known member
Alright I found the bug in catdecl, it initializes a variable guarded by hasVidNames, then tries to use that variable without the same guard. This patch fixes it (sorry for the ugly code block, the normal code block seems broken on the forum):

diff --git a/catdecl.c b/catdecl.c index 53ad1da..1d93ff1 100644 --- a/catdecl.c +++ b/catdecl.c @@ -138,10 +138,12 @@ int main(int argc, char *argv[]) { sRsrcVidNameEntry *videntry = NULL; printf("\tVideo Mode %d:\n", vidmode->modeid); - TAILQ_FOREACH(videntry, &boardrsrc->vidNames, next) { - if(vidmode->modeid == videntry->modeid) { - printf("\t\tMode Name: %s\n", videntry->name); - break; + if(iter->hasVidNames) { + TAILQ_FOREACH(videntry, &boardrsrc->vidNames, next) { + if(vidmode->modeid == videntry->modeid) { + printf("\t\tMode Name: %s\n", videntry->name); + break; + } } } printf("\t\tDev Type: %d\n", vidmode->devtype);

So catdecl has definitely never encountered a video DeclROM without mode names, because it crashes when it does.

I had a theory as to why DM 2.0 hangs forever: is it spinning waiting for a response from the decl about its modes and interpreting an empty result as the same as no response? I don't see how it could have parallel execution here though, given the DeclROM should be the code responding and it's just memory mapped for processor to execute. So why would it retry if it gets nothing back? It doesn't seem like it would be compensating for a race condition. Pure conjecture though.
 

eharmon

Well-known member
I think gpch 144 in the System file has the offending code for DM 2.0, it's the only place I can find the exact assembly around the code to call _DMGetDisplayMode. From other threads, it appears the gusb/gtbl/gpch contain patches installed at boot time (essentially slipstreamed extensions/enablers?).

Naively deleting it was a bad idea, I think because it's still referenced in the gtbl? I'm not really sure how to map a gtbl entry to the gpch.

Per the HFS+ backport hack, there's a lot of resources involved in setting up a patch, which unsurprisingly is all-or-nothing: https://github.com/elliotnunn/HFSPlusBackport/blob/master/make.py

I haven't found any good documentation on how this works though.
 
Last edited:

eharmon

Well-known member
I read up some more on DeclROMs (thanks 622 page NuBus reference) and I'm starting to fear the driver itself isn't properly responding to GetMode calls, but I'm still not sure.

I still haven't found any INIT-based drivers for this card either, which could potentially work around bugs in the initial driver before DM attempts to query the card. Even if they do exist somewhere, if they weren't updated for 7.5 that might be a dead-end and still require hacking the card, DM, or the driver.
 

eharmon

Well-known member
Alright, first the tl;dr:
  • Good news: I managed to hack the ROM to, I believe, successfully add the video mode entries.
  • Bad news: It doesn't fix compatibility with 7.5.3+, which probably confirms my theory the problem with these cards is in the driver, or both the driver and the lack of the video modes.
Putting together decltools and the NuBus reference manual, I was able to hand-edit the ROM to insert the video mode entries within the resource directory.

To accomplish this I discovered a convenient property: the last directory entry for the display sResource (4 bytes) referenced a 4 byte value directly proceeding the directory itself. This meant that instead of moving the entire directory and fixing the offsets, I could move that specific 4-byte value to a new location, slide the final entry back by 4 bytes, and modify it’s offset to point at the new location where the data was stored.

This gave me one more position to insert a directory entry, meaning I could insert the new modes data into a blank space in the ROM, add the new directory entry in the new spot, and add a directory entry pointing to it. (Don't forget to update the CRC after!)

I picked up an AT28C256 which is pin compatible with the original ST27C64A (the board also claims to support ST27C256, so extra address lines don't cause problems), flashed the ROM onto it, and to my surprise the system booted up the first time with the card still working...but only in 7.5.1.

So my belief now is the driver itself isn't responding to a call DM 2.0 expects, at least not properly. The video modes may also be a requirement, but they don't itself fix the problem, even if they are. Unfortunately the NuBus manual predates DM 2.0 and I've been unable to find any manual for the DM 2.0 requirements for drivers, which might shine a light on the spec changes that break compatibility with older cards.

I suspect all cards which hang in 7.5.3+ are the same root cause as the Lapis issues.
 

jajan547

Well-known member
Not sure if I'm any help here but I recently just read the ROM from a Lapis II Dual Page. The chip used was a 27C64A I also included this ROM below, let me know if it helps, if not at least its up.
 

Attachments

  • Lapis II Dual Page DSII-21LA.zip
    965 bytes · Views: 1

eharmon

Well-known member
Not sure if I'm any help here but I recently just read the ROM from a Lapis II Dual Page. The chip used was a 27C64A I also included this ROM below, let me know if it helps, if not at least its up.
Thanks! More dumps definitely help. It seems to use the same driver as it also reports as Display_Video_Apple_LAPISDisplayServerII, which I suspect all these cards share to some degree. Based on the date in the vendor info, it's older and probably has the same bug: 7/24/91 3:00 PM kcf.
 

eharmon

Well-known member
For variety I went back to looking at System hacks and actually found a working path to getting 7.5.3 running:
  1. Using ResEdit, open the System 7.5 Update file on your 7.5.3 installation.
  2. Open the System 7.5 Update file from 7.5.1.
  3. Copy gpch #144 from the 7.5.1 file to the 7.5.3 file. Overwrite when prompted by ResEdit.
  4. Save.
  5. Copy the Monitors control panel from 7.5.1 install into the 7.5.3 System Folder, replacing the original copy.
Boot into your copy of 7.5.3 and everything should work, no more hangs.

I suspect this should work for any video cards which hang in 7.5.3+, not just Lapis models.

This doesn't work for 7.5.5 which hits a bus error during boot after replacing the resource in the System file (and, weirdly, draws the menu bar before boot even completes so things are definitely off the rails). Either the older gpch is totally incompatible with 7.5.5, or another set of resources needs to be replaced as well.
 
Top