As I'm polishing up the LisaFPGA code, I'm trying to throw everything at it that I possibly can to see if there are any bugs left, and I think LisaTest might've just found one. It passes just fine (other than the "write wrong parity" test) in LisaTest 3, but LisaTest 2.2 also fails the VIA test for some reason. When you're in LisaTest's "technician mode", it shows you the test number and test step number that the Lisa failed on, but I can't find any documentation into what these actually mean. Does anybody have any info on these? The logic analyzer traces of my VIAs look fine, so I'm really going to struggle to narrow it down from here without some more specifics on what (or even just which VIA) is at fault!
Edit: It reports the test error code and test step number, not the test number and test step number. Not sure how I got that wrong; I've been staring at it for 2 days now!
There is a version of LisaTest that is for the 3A ROM's (screen mod). I am fuzzy on remembering the version number, but it should be the newest version of the test.
Is it possible to setup the LisaFPG to run the 3A ROMs, and try the 3.0 test?
It can already run the 3A ROMs as-is, and it passes LisaTest 3.0 just fine. LisaTest 3.0 works on H ROMs too.
The only problem is LisaTest 2.2. Even though it passes 3.0, the fact that it fails this older one makes me think that there's still a subtle problem in my system somewhere that I need to work out. Even if it's something minor/insignificant, I'd still like to have it solved to maximize compatibility with the actual Lisa's hardware.
I also just discovered that the Preferences Window gives an error under LOS 2.0 (but not 3.0) whenever you choose the Convenience Settings or Device Connections tabs. In the case of Convenience Settings, it just barely starts drawing the screen brightness control, and then pops up a "failed to display the window" error with Redisplay and Don't Redisplay buttons. I'm wondering if this is related to whatever is causing LisaTest 2.2 to fail?
As you must know, the contrast latch does hang off of one of the VIAs, so maybe related? But the latch looks like a write-only device, so I don't see why creating the control should have any effect. Does changing the screen contrast via the secret privacy keys (shift-option-keypad 0 if I'm not mistaken) or just by waiting for the screen-saver dimming to kick in introduce any problems or odd behaviour?
That's what I was thinking at first too, but I couldn't see any way that a write-only latch would cause the test to fail. And plus, the Lisa is capable of dimming the screen both within LOS 2.0 and LisaTest 2.2, so I figured it had to be something else.
I really wanted to know what those error codes meant, so I extracted all of the files from the LisaTest diskette, found the VIA test object files, and fed them into Claude, telling it that it was a test routine that runs diagnostics on 2 VIAs in the Apple Lisa, and that I'd like to know everything it could tell me about it, including what those codes meant if it could find them. And boy, did it deliver.
It thought for about 30 minutes, and gave me a really nice document explaining all of the tests that are performed and exactly what each error and test step code means. And then I asked it to generate a fully-commented disassembly too, and that came out great as well. So now if anyone else ever has the oddly-specific problem of troubleshooting VIA issues under LisaTest 2.2, your life is now a whole lot easier!
In short, my issue (test step 5, error code 7) means that it was doing countdown tests on Timer 1 of one of the VIAs and the timer counted down slower than it was supposed to. I'm not yet sure why this might be happening, but at least I have somewhere to look now, and the disassembly is really going to help me trigger the FPGA logic analyzer at the correct points now!
I've attached the document it created as well as the disassemblies in case they're useful to anyone. I'm kind of tempted to do this on more of LisaTest's tests at some point in the future to make it more useful. It seems like it could be such a powerful piece of diagnostic software given the depth of its testing and the error codes that it reports, but without documentation on them, it's not useful for much more than "CPU board bad" and it would be great to change that.
Very interesting. Did you feed Claude anything besides the VIA test object code, like the Lisa Hardware Manual, or did it find these contextual details all on its own?
At first, I literally just told it "here's the object code, it tests the Lisa's two VIAs, figure it out." And it came up with nearly the same document that you see there, except without the proper names for all the VIA pins and those random CPU board registers. For instance, it called the COP421 bus the "parallel bus" and the COP's READY signal the BUSY signal, and just referred to the other pins by their numbers, but it still fully understood what all of the tests did and the initial output would've been completely workable as-is.
But I wanted it to have a little more context so it could name everything properly, so I just typed up a little summary of what's connected to each VIA (as well as what those vertical retrace interrupt and error/status latch addresses were) and asked it to revise. In hindsight, it probably would've been easier to feed in the boot ROM source listing or the hardware manual, but the results probably also wouldn't have been quite as good since I was more descriptive.