Lisa (was Re: Olivetti M20)

Roger Holmes roger.holmes at microspot.co.uk
Thu Jan 18 14:04:22 CST 2007


> Date: Wed, 17 Jan 2007 13:31:05 -0500
> From: Ray Arachelian <ray at arachelian.com>
> Subject: Lisa (was Re: Olivetti M20)
> To: General Discussion: On-Topic and Off-Topic Posts
> 	<cctalk at classiccmp.org>
> Message-ID: <45AE6B69.7020506 at arachelian.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Roger Holmes wrote:
>>>
>> Well OK 5k dollars is not much, but in January the following year for
>> 10k, Apple's Lisa had several of the above, though I have to admit I
>> have seen some spectacular crashes as it was possible to corrupt the
>> sound buffers and also to seriously derange the CRT scanning.
> Erm, I'm not sure how this is possible as the Lisa had no sound  
> buffers
> at all.  All it had was a bunch of resistors hooked up to a latch in
> order to act as a volume control for the VIA's shift register.  It
> beeped in the same way as the Commodore PET.  That is by setting  
> timer2
> on the VIA and setting a value in the SR, then setting the ACR to loop
> the data in the SR.  There was no sound buffer, there was no way to  
> play
> anything other than beeps.

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.

>
> Nothing is available to the OS to derange the CRT scanning.  All  
> you can
> do is enable interrupts on the vertical retrace, or disable said
> interrupts, and you can also select which 32K of memory to use as the
> framebuffer.  That's it.

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.

>
>
>> The compiler generated some strange code to 'touch' the new top of
>> stack on subroutine entry so the OS could allocate all the extra  
>> space
>> in one go rather than in little bits. One enterprising British
>> software house even got Unix running on a Lisa with the (then)
>> optional 5MB profile hard disk. It wasn't C.A.P. but one of the other
>> big ones of the time.
> There were two.  Microsoft/SCO Xenix, and UniPlus.  I'd love to get my
> hands on UniPlus, but it seems to be rare.  If this was something  
> else,
> it would be wonderful to get a copy of it.

Maybe the UK firm was merely selling one of these under licence.

>
> I'm not sure what the strange code is about, I suspect something to do
> with the MMU.  If you'd access a page that wasn't mapped to your
> process, the OS would either load it from disk, or allocate more MMU
> pages to your process, thus getting more memory.

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.








More information about the cctalk mailing list