Hi guys, hopefully someone can help me out here. A friend of mine working on their Mac II in MacsBug, debugging the sound for a game they wrote, is noticing that something keeps stealing interrupts. Like an interrupt will occur but stepping through it and trying to RTE from the interrupt will hose the machine. Same with NMI's, if you enter the debugger and end up in MacsBug code, stepping thru the code hoses the machine. I did a little research and noticed that although the Mac II is not a fancy machine, just a CPU, RAM, and ROM, basically like old fashioned PC's, it DOES have a large black GLU chip that I can't find any info on. Sure enough, this is connected to the interrupt mechanism pins of the 68020 chip. Does anyone know anything about this chip or what it does? It also appears to provide timing for the NuBus slots based on the pins its connected to but the chip is a black box to me, I need to know what it's doing on the bus.
-
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.
Mac II Tech questions
- Thread starter IIsi
- Start date
Dennis Nedry
Well-known member
If you're having problems with returning from interrupts, maybe the stack is becoming corrupted somehow. Not an equal number of pushes and pulls, pushing the value at an address rather than the actual address, etc. You also could be out of memory and the stack is being overwritten.
Charlieman
Well-known member
Helper for NuBus Mastering? Does this provide any guidance:
http://docs.info.apple.com/article.html?artnum=2186
http://docs.info.apple.com/article.html?artnum=2186
Charlie, that was a good start, thanks. I know there is no Nubus Controller in these old macs, the CPU does all the work (I think). Dennis, the stack is intact, I mean that something other than the CPU is manipulating data in memory, and generally, by using the ISP and MSP, and keeping an eye on what the int level in the SR is, and values of various registers, you can see where interrupts are coming from, and who services them, etc. But I have this sixth sense that something other than the CPU is doing the work of sorting out what goes to who. I can't quite put my finger on it. Macsbug is a weird and wonderful program, and generally is very good about stepping through instructions and updating registers and memory, while letting VBL tasks and interrupt handlers and page faulting go on in the background. In this case though, just on this machine, stepping through some instructions gets you a hang or bus error. I wonder if it has to do with VM? Maybe the page fault handler is getting interrupted, and can't page memory that the debugger is using? I'll trying disabling VM and trying again, but I would still like to get my hands on the pinout/description for the GLU chip, it's the only thing on the board I know nothing about.
EDIT: I actually might have answered my own question. It seems that upon entry to the debugger, the page fault exception handler is in one of two places. So sometimes when I break into the debugger, im in real memory, sometimes I'm in the application's VM, and sometimes I am in the Debugger's VM, possibly even its own exception handler. I can;t step through that because if I need a page of memory, I'm currently stepping through the program that is doing the paging for me which could be bad.
EDIT: I actually might have answered my own question. It seems that upon entry to the debugger, the page fault exception handler is in one of two places. So sometimes when I break into the debugger, im in real memory, sometimes I'm in the application's VM, and sometimes I am in the Debugger's VM, possibly even its own exception handler. I can;t step through that because if I need a page of memory, I'm currently stepping through the program that is doing the paging for me which could be bad.
I have to assume since the SE/30 is basically a modified IIx, that the GLU chip in the SE/30 that is detailed here is similar or identical to the one in the II? Except the two had a MMU chip which was connected between the 68020 and the address bus connected to the ram. The IIx and Se/30 didn't since they have a built in MMU. It looks like some of the strobe signals are generated by the GLU though for the SE/30....RAS is Row address strobe and CASLL/UM/LM/UU are Column address strobes. This may get me what I need!! The IPL0-2 pins are indeed routed to the GLU, so this chip DOES have some part in the interrupt mechanism (at least in the IIX and SE/30).
I figured this out. Nubus cards have user (well, programmer) installable Interrupt exception handlers and "follow up" code that you can attach to a slot or sRsrc structure. Mundane activities that are related to the Nubus cards themselves can "steal" interrupts. Most Nubus activities are only interruptable by an NMI (Level 6 interrupts, or so it seems according to MacsBug) and apparently, these routines don't like to be MacsBugged while the 68020 is writing to Nubus Super Slot space. Either that or the actual level 6 interrupt routine is doing something funky. In any event, the only Nubus devices present in the II are the 8 bit display card and a SCSI controller, which I removed, and the problem goes away. So it must be something in this cards ROM because there are no drivers installed for it and I know Nubus ROMs can contain executeable code. Arghhhh.
Yes, but I still wonder why it happened, like why exactly. Now if I furiously mash the debugger switch, I no longer end up in code where the Interrupt level is 6, so I am guessing it was the fact that I was entering the debugger code in a noninterruptable routine. (Non interrupt safe?) lol.
In case anyone else cares, I found the answers to my questions:
"The general logic unit (GLU) chip performs support
functions for the microprocessor in the Macintosh II, IIx,
and IIfx. It provides address decoding, chip select, RAM
refresh, CPU, SCC, and VIA clock signal generation and
NuBus, VIA, SCC, power, and NMI switch interrupt handling.
Operating System Support (OSS) Chip
Some of the support functions the operating system support
(OSS) chip performs include I/O device decoding and timing,
interrupt prioritization and masking, a 56-bit system
counter, bus timeout logic, and interface support for the
real-time clock chip."
This is actually sort of confused, above it should read II/IIx/IIcx/Se30 and then list the IIfx above the next heading for OSS, as it is the only Mac with that chip.
"The general logic unit (GLU) chip performs support
functions for the microprocessor in the Macintosh II, IIx,
and IIfx. It provides address decoding, chip select, RAM
refresh, CPU, SCC, and VIA clock signal generation and
NuBus, VIA, SCC, power, and NMI switch interrupt handling.
Operating System Support (OSS) Chip
Some of the support functions the operating system support
(OSS) chip performs include I/O device decoding and timing,
interrupt prioritization and masking, a 56-bit system
counter, bus timeout logic, and interface support for the
real-time clock chip."
This is actually sort of confused, above it should read II/IIx/IIcx/Se30 and then list the IIfx above the next heading for OSS, as it is the only Mac with that chip.
OK. I need some help guys. I got another Mac II, in very good physical shape, but it doesn't boot. At all...totally dead. Logic board looks clean. These machines are notorious for not booting if the two PRAM batteries are dead. They charge a large yellow 1000uF cap seated on a platform with the batteries and this is what discharges and turns the machine on. I don't have extra batteries, so I charged the cap with some AA batteries. No deal. I did notice some of the silver SMC caps near the power button "weeping" an odd smelling clear oily substance, but it wasn't on the caps themselves, but the traces near them, so I dunno if the caps leaked and then the stuff moved? Should I try buying some PRAM batteries? Or do you think I need to recap this thing?
Similar threads
