17 Aug
2009
17 Aug
'09
2:04 p.m.
Roger Holmes wrote:
Thank you.
Was there ever any other interface cards which
fitted into the three
slots?
The Dual Parallel card is the most common one.
There was a quad port serial for use with Xenix
There was the SunRem SCSI card, which sometimes was attached to an
actual SCSI card (that would eat up two slots worth of space) but
would
only work for Macworks
There was some sort of network card for it as well, but that never
made
it, and yes, with MacWorks you can use LocalTalk on serial port B
instead.
There may have been others. One guy has some strange 3 port Parallel
Card, but no drivers for it. I suppose I
might leave Mac OS on it and load up MacWrite and MacPlot
(which I wrote) or even an early MacDraft (for which we were European
distributors and which I still maintain). Maybe I will put Lisa OS on
the other Lisa when I retrieve it from my brother's shop where I had
it running stock control, reading from a bar code reader and
controlling a till (cash register) drawer and printing receipts to an
Apple dot matrix printer until the whole system was retired.
Incidentally it replaced an Apple /// doing the same job using a
floppy auto-changer with five 1.2MB floppy disks in it instead of a
hard drive. The bar code reader was a one bit input device originally
hooked up to an Apple ][ but re-connected to parallel cards on
the ///
and then the Lisa and the device driver re-written.
You could always split the
hard drive in half and use the environments
window to switch between Lisa Office and MacWorks if you want both.
Did you write the bar code driver yourself? Was it for MacOS or Lisa
Office System?
Thinking about it, I'm fairly sure it was in MacOS by the time Lisas
were cheap enough for my brother's budget. Getting at a one bit input
from MacOS was easier too. I think I had it generate an
interrupt
every time there was a change from black to white or vice-versa and
used the system clock to measure the time, and hence the distance
assuming a reasonably constant acceleration. It used the guard bars at
each end to find the start and end speeds and assumed constant
acceleration in between. The decoding algorithm was based on the
Apple ][ code which came with the reader, which I disassembled and re-
coded, probably in 68k assembler, but maybe Pascal. The Apple ][ code
just polled the games port and you had to call it when you expected a
bar code to be read. The MacOS version just processed interrupts
whenever they occurred and when it found a valid 8 or 13 digit EANA
code or a local 6 digit item number of the locally printed labels, it
told the host application. I think it generated key events including a
carriage return so the app thought the user had typed a bar code in,
which they could do by hand if necessary.
Roger Holmes.