I can (limited) navigate with the arrow keys and shortcuts where possible. Power key works to bring both up and down. Combinations like Cmd-Opt-P-R also register.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Q700 ADB or board kaput? Mouse clicks but no movement
- Thread starter pb3623
- Start date
I can (limited) navigate with the arrow keys and shortcuts where possible. Power key works to bring both up and down. Combinations like Cmd-Opt-P-R also register.
Yes and I’ve just done so. No change. I once read something about TechTool’s PRAM zap to be more thorough than the usual method. The problem is there is no keyboard shortcut once you launch the app so I can’t actually do the zap.
Which led led me to the aforementioned ADB renewal/resets that also had no effect. What I’m trying to do now is to get the the Easy Access and PRAM Auto-Restore control panels copied over so I can try and use Mouse Keys to control the cursor.
I’ve also pulled all the VRAM and RAM, essentially running the 040 on a bare board. Even burned a stock Q700 ROM to a SIMM and booted with it, to no avail. At this point, I’m trying to get mouse movement before the flashing ? floppy (since I see no reason to involve SCSI at this point).
Last edited by a moderator:
Bumping this in case anyone else has ideas... I worked around the issue by acquiring another Q700 but I would like to get this one working... it does have a 66 MHz crystal so the 040 and 601 PDS card run ~30% faster than stock.
Another theory - does anyone know what IC chip U54 does? It's located directly below the CPU oscillator. To install the aforementioned PowerPump card, you connect a hook to pin 1 of the oscillator, and a claw to pin 1 of U54. Both of these wires run to a ROM SIMM, which itself is connected to the actual PowerPump NuBus card.
The system doesn't chime when the claw is connected to U54. If I take it off, it boots fine (but obviously the PowerPump doesn't work). Could U54 be bad, and, depending on its function, could it be causing my ADB issues at all?
Another theory - does anyone know what IC chip U54 does? It's located directly below the CPU oscillator. To install the aforementioned PowerPump card, you connect a hook to pin 1 of the oscillator, and a claw to pin 1 of U54. Both of these wires run to a ROM SIMM, which itself is connected to the actual PowerPump NuBus card.
The system doesn't chime when the claw is connected to U54. If I take it off, it boots fine (but obviously the PowerPump doesn't work). Could U54 be bad, and, depending on its function, could it be causing my ADB issues at all?
What is the part number on U54? I've seen clock buffers in the kind of package in the diagram, but lots of other chips come in that package too.
You might also check the two diodes (D1 & D2) behind the ADB port. It can be hard to check them in-circuit, but it's worth a try. If one of them doesn't conduct in one direction, that could be a simple fix, although I agree with Powermax that it doesn't seem like the keyboard would work if you have a fundamental problem with the ADB circuitry.
You might also check the two diodes (D1 & D2) behind the ADB port. It can be hard to check them in-circuit, but it's worth a try. If one of them doesn't conduct in one direction, that could be a simple fix, although I agree with Powermax that it doesn't seem like the keyboard would work if you have a fundamental problem with the ADB circuitry.
Last edited by a moderator:
These markings are often confusing and mostly meaningless. If I had to guess, it looks like a Motorola-fabricated clock driver IC (MC74F803), similar to those used in Amiga, see this Wiki page. It seems to provide clocks for the CPU.
You'll find the datasheet MC74F803 for on the above mentioned page.
Ahh, brain melting...
But seriously, thanks for the link. Could a bad clock driver allow the machine to operate normally, with the exception of certain input registers like mouse movement?
It seems this particular chip has a fmax (Maximum Clock Frequency) of 70 MHz, so the chipped 66 MHz crystal should (and appears to be) working fine, otherwise.
How do I measure/test the IC? And would I clip it out and run trace wires from the pins to a replacement to test it before soldering? Or can it clip it on top of the existing one?
PS - looks like the PowerPump attaches to pin 8 (CP - buffered clock input) so it intercepts the signal coming from the oscillator if I'm reading the datasheet right.
Thanks!
I don't think it's possible. It's true that the ADB as a single-line bus requires precise time slices. But this leads to the following logical conclusion: if this timing is somehow broken, the whole ADB communication will become broken. Any partial failure can only happen after the ADB transceiver/decoder, either in hardware (between the ADB decoder and the CPU) or in software.
BTW, the mouse you're using, is it a compatible one? Does it work with the other Q700 board as expected?
Do you have an oscilloscope/logic analyzer?
Last edited by a moderator:
I had this issue on a SE/30 once... I had the jumpers on the IIsi pivot set wrong. One of the jumpers on that card switches between two different slot interrupt signals. Keyboard and clicking the mouse were working just fine but moving the mouse around did not do anything.
You might want to look if there either is something messing with interrupts on your board or if interrupts from the ADB chip are even reaching their destination.
You might want to look if there either is something messing with interrupts on your board or if interrupts from the ADB chip are even reaching their destination.
OK - so, along that train of thought...
Recall the original issue was due to a bad or flaky Radius PrecisionColor 24 that freaked out the minute I changed resolution or bit depth...
Let's say something got messed up in PRAM that couldn't be cleared by pulling the battery or zapping (which is why I thought the TechTool zap was more thorough - but I can't navigate it without a mouse!) - and that, as a result, Slot Manager thinks the NuBus slot(s) are populated or the interrupts are being tied up.
Is there a control panel or extension that will reset the slot assignments?
I don't know much about "legacy" (pre-OS X) AppleScript - but could someone script TechTool to launch on startup, zap the PRAM and restart? Hence, mitigate the need for a working mouse?
PS - powermax - yes, they're legit and working Apple ADB mice that work in other machines.
This would be possible if your board had EEPROM or Flash storage. It's a well-known fact that all Apple desktops in the 90s use 3.6V lithium batteries to maintain non-volatile memory. That means that PRAM (NVRAM) is actually a small amount of CMOS RAM powered either by the mains or the battery. In the case ALL power is lost (that's it - the battery was pulled and the power supply is off), the whole PRAM content is also lost. It's difficult to imagine what kind of magic TechToll can do beyond that...
FYI, PRAM is a part of the RTC IC (U92). Its part number is either 343S0042 (Motorola-made) or 344S042 (VLSI-made). I don't know which one sits on your board...
Thanks for the info. There were a lot of Moto chips on it when I had it open over the weekend. I keep bringing up TechTool because the Zap from within the app fixed a previous issue I had with this video card (which, back then, only caused a problem with booting, not ADB)... an issue that pulling the battery and unplugging the mains didn't solve - like hours... but maybe hours wasn't enough and it needed to be left overnight. At this point the board has been sitting since Sunday without power or battery so if it's still messed up, do I try to acquire replacement RTC and clock driver ICs and piggy-back them? Or replace them outright? The whole unit is in really nice shape and I would like to have a working spare or entertain the thought of selling it.
Frankly spoken, I'm out of my depth now. I think you need to gather more data on the failure of your Quadra board. Can you do some electrical analysis of your board and compare the signals it generates with a known working board? That would be very helpful. Otherwise, we won't be able to go a step beyond guessing.
Moreover, I don't think that any blind IC replacement would be a good idea, especially when the ICs in question are vintage ASICs you'll probably not be able to find any replacement for...
Unfortunately, you're reaching the point where you just about need an oscilloscope at a minimum to continue testing. A logic analyzer would be better. If this was a common problem then the most likely solution might be none. But for what amounts to a one-off problem, actual electrical diagnoses is probably necessary.
You could identify all the chips involved in the ADB bus, get a working Q700, and trade them one at a time, until the problem moves from one machine to the other. That's assuming that all your soldering is good. It's very tedious.
You could identify all the chips involved in the ADB bus, get a working Q700, and trade them one at a time, until the problem moves from one machine to the other. That's assuming that all your soldering is good. It's very tedious.
Thanks for the candor, everyone. As a last-ditch measure, I installed the Easy Access cpanel onto my 7.6.1 partition on my working Q700 and tested Mouse Keys by (IIRC) Shift-Opt-Cmd-Clear... on the bad Q700 I can enable Mouse Keys (the up-sliding beep) and can use '5' on the numpad to click but can't move... so emulating mouse movement isn't even working (and it's not software because I took the whole SCSI2SD out of my working machine)
I don't have an oscilloscope or logic analyzer, and even if I picked one up for a song, I'm wondering if it wouldn't be worth it just to pay someone to check it out at an electrical level.
And no, my soldering skills resemble those of a 5-year old - I lack the experience and right equipment to do a proper job but unless someone wants to crack at it, this might be the perfect board to train on...
I don't have an oscilloscope or logic analyzer, and even if I picked one up for a song, I'm wondering if it wouldn't be worth it just to pay someone to check it out at an electrical level.
And no, my soldering skills resemble those of a 5-year old - I lack the experience and right equipment to do a proper job but unless someone wants to crack at it, this might be the perfect board to train on...
I feel like we might be missing something easy. Larry Pina wrote a bunch of books that had helpful sections of the form, "If X is wrong with your Mac, replace Z or resolder Y". I don't think he ever did a book for a Mac as late as the Q700, but since it isn't using Egret/CUDA yet and still has distinct VIA 1 and VIA 2 chips, I think its ADB subsystem might be analogous to the older machines.
I know there was/is a PDF version of "The Dead Mac Scrolls" kicking around, but I can't remember if it covers the SE (earliest? machine with ADB bus). He also had a series of books of the form "[ ] Repair and Upgrade Secrets", where the first one was Macintosh, but there were later books for the SE/30 and I think for the Mac II.
I would check one or more of those, the ones that applied to ADB Macs, for the symptom you're having.
You might also take a look at "The Guide to the Macintosh Family Hardware" or perhaps, the appropriate chapter of "Inside Macintosh" and see if there's something fundamentally different in how the ADB bus handles keyboard input vs. mouse input. The symptoms of your problem are very strange and I feel like it should be pointing us right at something, but my knowledge of these systems was never great, and my memories are old and leaky.
I know there was/is a PDF version of "The Dead Mac Scrolls" kicking around, but I can't remember if it covers the SE (earliest? machine with ADB bus). He also had a series of books of the form "[ ] Repair and Upgrade Secrets", where the first one was Macintosh, but there were later books for the SE/30 and I think for the Mac II.
I would check one or more of those, the ones that applied to ADB Macs, for the symptom you're having.
You might also take a look at "The Guide to the Macintosh Family Hardware" or perhaps, the appropriate chapter of "Inside Macintosh" and see if there's something fundamentally different in how the ADB bus handles keyboard input vs. mouse input. The symptoms of your problem are very strange and I feel like it should be pointing us right at something, but my knowledge of these systems was never great, and my memories are old and leaky.
Similar threads
