info-mac@utcsrgv.UUCP (info-mac) (05/11/84)
Date: Thu 10 May 84 00:39:09-EDT
From: Michael Rubin <uw-beaver!RUBIN@COLUMBIA-20.ARPA>
Subject: Speculations, ramblings and flame (long)
To: info-mac@SUMEX-AIM.ARPA
Fairly easy software hack: a printer driver called by the vertical blanking
interrupt, so you could compute while printing? Only problem is it would
periodically have to read more data off disk, and I don't know if interrupt
routines are allowed to do that.
All the documents say the mouse is handled at such a low level that there's
just no way to move the cursor somewhere else or even confine it to a
particular area. Now, I can't really believe that, since the mouse just
outputs a pulse for every 1/90 inch of vertical or horizontal movement, and
anyhow the cursor is obviously confined to the limits of the screen. Perhaps
the cursor is a sprite and handled entirely by the video interface, but that
seems real unlikely. Now it may be that the mouse handler is entirely in ROM,
with no trap vector so it can be overridden like the Quickdraw routines.
However, the current mouse position is certainly not in ROM, so there has to be
an appropriate magical POKE that will do the job....?
Now that the Apple IIC ("Apple II, crushed") is out, will the FlatMac be
far behind? Well, it will have to wait for a 512x342 liquid-crystal display
because there's no way the Mac can output to a TV set or even a standard
monitor (it doesn't use ordinary video signals). Apple is having enough
trouble getting Sharp to make a 560x192 LCD for the IIC -- all they want to
build are 640x200 displays for IBM-PC's and clones. Figure about 18-24 months
for LCD production to catch up enough that odd sizes can be ordered. BTW, does
anybody know how thick the IIC's LCD is going to be? All the magazine photos
show a 3/4 front view with the unit tilted up, so the back might be anywhere
from flat to pyramid-shaped.
Since the Mac CPU board is just under 9x9 inches (and contains the entire
workings of the machine except for the power supply and video electronics), it
would fit in the same size case as the IIC. The disk drive is about 3/4"
thicker, so the case would have a bulge in back. However, the drive is also
narrower, which would leave about two inches of space behind the keyboard --
just right for a trackball, and perhaps a small nicad battery pack (that room
might be needed for a board to control the LCD).
Thoughts on the next machine in the Apple 32 line: The Mac is a neat
architecture except for lack of virtual memory, but it's I/O-bound. The floppy
is none too fast, and the IWM disk controller grabs the entire CPU during disk
operations, which is nasty if you want to do serious multitasking. A
Winchester can theoretically transfer data at 500Kbytes/sec, five times faster
than the serial port can theoretically receive it. Now if the disks were only
memory-mapped like the video, stealing half the memory cycles, they would be
capable of at least the same transfer rate as the video -- 22Kbytes every 1/60
second, or 1200 Kbytes/sec! Well, this could be done by turning off the screen
during disk I/O, but that would be even uglier than turning off interrupts.
Hmmm.... the video DMA uses only one fixed piece of memory, near the low end.
If the machine has at least two ranks of memory chips (256Kbytes of 64K chips,
or 1Mbyte of 256K chips), the memory bus could be cut in half during the memory
cycles reserved for DMA. Then while the video hardware was reading the low
bank of memory, the disks (or any other devices) could be reading and writing
their buffers in high memory. Some more complex disk controller than the bare
IWM would be needed, equivalent to an ordinary S-100 or Multibus DMA disk
controller. Perhaps the IWM could be operated by another custom chip or just
some PAL's and shift registers.
Another useful addition might be a smarter video controller, one that could
handle multiple bit planes and put them in arbitrary places on the screen
(basically giant sprites). This would be nice for windows, but great for
animation. Oops, if the bit planes are transparent and you have N of them at
one point on the screen, that means N memory accesses per pixel time. On the
other hand, most of them probably wouldn't be transparent, and even one extra
bit plane would help a lot.
--From the butane torch of:
Mike Rubin <Rubin@Columbia-20.ARPA>
-------