mouse cursor vblank task doesn't work!?

[bigmessowires]

This question is mostly for bbraun, but I'm posting here in case others have help suggestions too.

A couple months back in the "Another IIci ROM hack" thread, bbraun described his progress developing a bootable ROM disk: viewtopic.php?f=29&t=16544&start=575#p162903 He was having a problem where after booting from the ROM disk, the mouse cursor didn't move: "I still have the problem of no cursor movement. As I noted before, the rawmouse low global gets updated, so it looks like interrupts are working, but the CrsrTask isn't getting called." I'm wondering-- did you ever discover what was going on here?

Last fall I built a prototype Mac Plus replica in an FPGA, booting from a read-only floppy disk image implemented in the FPGA board's ROM. It booted the System 6.0.8 Finder successfully, and you could exercise the Mac and run programs for a minute or two, but then it would freeze-up. I never looked into the cause of the freeze-ups further, until today. It turns out it's virtually the identical problem that bbraun encountered!

What I'm seeing is that the mouse interrupt handler still gets called when the mouse is moved, and the low-memory mouse position global variable MTemp gets updated correctly, but the vblank task that actually redraws the mouse pointer at the new position never gets called. In the Mac Plus ROM, this VBL task is at $401E86. If I set a breakpoint there, it gets hit repeatedly when the Mac is at the question-mark disk screen, waiting for a System floppy to be inserted. But after booting into the Finder, that cursor VBL task never gets called, even when the mouse is responding and moving normally. So it seems that System 6.0.8 actually patches the ROM and replaces the cursor VBL task with a new one loaded from disk, which then resides at an unknown location in RAM. And for reasons unknown, after a minute or two of activity in the Finder, that RAM-based cursor VBL task stops getting called, so the mouse pointer stops moving on the screen.

So... I'm not sure how to go about troubleshooting this further. Without even knowing where the RAM-based cursor task is, I can't set a breakpoint in it, and I don't have a disassembly to examine it. Bbraun's experience suggested this somehow had something to do with the disk driver. Can anyone think of anything else that might cause this behavior? Maybe if another VBL task got stuck in an infinite loop and never completed, it might prevent the cursor VBL task from ever getting called? Or maybe the task is getting ejected from the task list entirely somehow? Any suggestions on other tests I might try running, to see if I can narrow down the problem further?

 

[bigmessowires]

Hmm, looking at this further, when my mouse cursor freezes it looks like the VIA VBL interrupt handler itself stops getting called. So that suggests there's either something wrong with my VIA implementation, or some other interrupt is continuously firing and preventing the lower-priority VIA interrupt from ever getting handled, or something of that sort. Time to dig a little deeper...

 

[bbraun]

I didn't ever resolve the issue, unfortunately. I've kinda back burner'd the project in favor of waiting for the ROM SIMM programmer from dougg3.

To work around the issue, I ended up adding my own VBL task to the VBLTask queue that ended up just calling through the low memory global pointer (0x8ee) to whatever the registered CrsrTask was. So in my case, the VBLTask queue was getting processed which leads me to assume the VIA interrupt that triggers VBL processing was firing correctly, and the registered CrsrTask was correct and working since my own VBL task was calling it, just for whatever reason the normally registered CrsrTask was not being invoked.

One odd thing I did notice in the .Sony driver was the SonyVars at 0x134 contained function pointers to various driver functions, which presumably exists as a patch point for the System to provide its own implementations.

 

[bigmessowires]

OK, sounds like it's a totally different problem then, even though the symptoms are similar. I looked deeper into my problem, and it seems that the CPU is stuck forever at priority level 1, presumably in some interrupt handler that never completes, so the next VBL interrupt never gets processed. I don't have enough diagnostic info to tell exactly what it's doing, unfortunately.

That's interesting about the Sony driver function pointers. I don't believe the Mac System software patches the Sony ROM routines at all. I could be wrong, but if it did patch them, then anything that used a custom ROM to replace the drive (like Mini vMac or your ROM disk) wouldn't work.

 

[bbraun]

What I seem to see is SonyVars global variable has function pointers to some driver functions. The ROM driver resource doesn't point to those, it points to stub routines that bounces through the function pointers in the SonyVars. So replacing the ROM driver would be fine, and the System could update SonyVars, the System's routines just wouldn't get invoked since the replacement ROM driver wouldn't refer to SonyVars. The only problem with the System patching SonyVars is if the replacement ROM driver decided to hijack that global pointer for its own purposes and start storing data that the System could possibly overwrite.

Anyway, that's going from memory, and I don't know if the System ever patches SonyVars, so take it all with a grain of salt.