Oh, I must be getting confused then. After developing for Lisa we continued to use the Lisas as hosts to develop software for the Mac using a serial cable to send the software and to run the debugger on the Lisa screen and the target software on the Mac. I think at first we had Lisas with twiggy drives so we could not write Mac discs on the Lisa, but maybe I've got it wrong again. I do know that Apple loaned us a Mac with a 5 1/4 inch slot in it for a twiggy drive, though there was a 3 1/2 inch installed in it. That would probably be worth something now. Back to the crashes, I remember they really made you jump out of your chair, the screen went haywire and the horrible sound it made like hitting bone with a coarse circular saw. Though the Lisa was black and white, the phosphor must have been made of a mixture of two, as you could get a purple effect if you crash made the screen flash at a particular frequency, and on another time it seemed to make one flash of pale green, though maybe thats the 'Pink Elephant' effect. Even with only square wave output you can make more than beeps, my old mainframe built in 1962 can play crude music. Not that Handel and Bach wrote crude music, it was the rendition which was crude. Yes thats all the system routines allow anyway, I just checked (on Lisa). As both 128k Macs and Lisa had a single built in CRT I can't see why the refresh rates would have been programmable, but thats just how it appeared. The only other option I can think of is we had somehow managed to do something which had affected the power supply rails, but the machines rebooted OK so there was no permanent damage. Could switching the position of the framebuffer between frames full of ones and ones full of zeroes cause this perhaps? I remember you could get the spark gap capacitors to fire on old monitors on the Apple ][ when you rapidly changed the screen image. The screen image would expand and contract while this happened. Maybe the UK firm was merely selling one of these under licence. The Lisa Pascal compiler had an option for "automatic stack expansion". IIRC, this was off when compiling for Mac and on when compiling for Lisa. Each routine started with something like LINK A6,#constant where the constant was the space for the local variables and maybe the parameters too. If automatic stack expansion was on, the compiler would then generate the weird instruction, which was not useful to the program but would apparently cause the allocation of more stack space if necessary. I have just found the reference in the manual: "6.6.1 The Run-Time Stack Automatic stack expansion code makes procedure entries a little complicated. To ensure that the stack segment is large enough before the procedure is entered, the Compiler emits code to 'touch' the lowest point that will be needed by the pocedure. If we 'touch' an illegal location (outside the current stack bounds), the memory management hardware signal a bus error that causes the 68000 to generate a hardware exception and pass control to an exception handler. ... then allocate enough extra memory to the stack that the original instruction can be reexectuted without problem. To be able to back up, the instruction that causeed the exception must not change the registers, so a TST.W instruction with indirect addressing is used." It then goes on to talk about a compiler fudge factor and what gets generated if more than 32k of extra space is needed on the stack, and what is needed if working in assembly language. Best regards, Roger Holmes.