>> I think the elevator hack involved the AI Lab PDP-6 (or maybe, later,
I can supply definitive bits here (I have read the code involved). The actual
interface to the elevator was in one of the PDP-11 front-ends on the MIT-AI
KA10 (memory escapes me as to whether it was the TV11 or the XGP11 or what,
don't have time right at the moment to go look - I suspect the former).
There was actually a table in the PDP-11 code that ran the Knight TV's
(perhaps the first bit-mapped display system) so that one only needed to type
'<Whatever>-E', and the code knew which floor that Knight TV console was on,
and automagically sent the elevator to that floor (3, 8 or 9).
>> I wouldn't be surprised if it migrated to the Lisp machines, too
Yes, but that would have just been a network client talking to a server; the
actual hardware interface remained, I am pretty sure, on the -11.
I have an 11/05 with ASR 33 for I/O. I am using the M9970 console card to
make the connection. I have loaded papertape BASIC into core (16K) and it
boots up from 000 000 to the TTY, I can type in programs, etc.
Question - I'd like to switch over to a VT 50 in 20ma mode. Not sure if
this is possible based on what I read here:
Anyone successfully connect a VT 50 or 52 to a 11/05 or 11/10 over to the
EIN M7856 for printer and typewriter only, leaving the M9970 for program
i/o to save and load programs?
>Noel Chiappa wrote:
> > From: Jerome H. Fine
> > both DEC and DSD needed a bounce buffer managed by software
>Love that term, "bounce buffer" (I wrote a whole package to support them in a
>packet switch I did) - I'm officially adopting it, right now! :-)
Hey - anything that anyone writes is automatically copyrighted.
So first you need permission to use that! I will try and figure out
who the person was that first used that phrase so we can both use it.
I did not mention that the concept worked quite well with the DEC
RX02 and the DSD RX03 when a PDP-11/73 was used. But when
version 1.0 of that device driver was used with a PDP-11/23, the
transfer rate was painfully slow because the interleave gap was
not long enough relative to the time needed to bounce the buffer.
Since the DMA silo had already been emptied into the bounce buffer,
the solution was to immediately initiate the next READ into the silo
and then bounce the buffer (for a READ request, of course). That
allowed the READ of the next sector on the floppy media to be
performed by the controller while the CPU was performing a
transfer out of the bounce buffer into the user buffer one word
at a time. I don't need to test the timing on any slower CPU since,
as far as I know, none support an MMU which would be required
to use a Mapped RT-11 monitor.
I may have the exact details and terminology incorrect - it was about
20 years ago.
Just figured I'd post something about my tinkering yesterday.
I got an M8830 from Paul Anderson. This is the crystal-contolled clock
for the Omnibus PDP 8 machines.
Yesterday, I had a chance to try it out.
First, I checked the power supply pins to make sure no shorts or
anything like that and all was good.
A quick visual inspection showed no obvious issues.
It was already jumpered for a 50Hz interrupt rate, so I went ahead and
plugged it into the backplane.
Powered the 8/e system up, and ran a few tests from the front panel to
make sure the board was responding to its IOTs, and all seemed well.
Booted up OS8 from RK05, and mounted up the multos8.rk05 drive via the
Copied the MULTOS8 .SV files onto my SYS: volume, and although not
configured exactly for my system, I figured they'd be close enough.
I then stopped the serial disk server, and fired up Kermit on the laptop
connected to the second serial port on the 8/e. Then, I typed R MULTOS
on the console, and it said something to the effect that I needed to set
the date first.
I generally don't bother setting the date at boot time, so I set the
date to a valid date, and tried again.
This time it gave a welcome message.
I checked the accumulator, and it was counting off time as it should. I
checked the MQ register, and it was static, but then waited for the
accumulator to overflow, and then the MQ incremented by 1, as it should.
I pressed CONTROL-H on the console terminal and hit RETURN, and there
was the . OS8 prompt!
I went to the laptop connected to the other serial interface, and since
there was no MULTOS 8 password file on the SYS: device, typed CONTROL-H
there, got the login prompt, hit RETURN, and low and behold, another .
I played around with it for a while, and found that because of some of
the config differences in how MULTOS8 was built on the pack image, some
things were acting strange but in general, it definitely was timesharing
between the two users.
I could run concurrent things on both terminals, and the response was
I intend to make a build of MULTOS 8 to match my system's configuration,
and tinker with it some more when I get time.
Next I want to replicate the ETOS Timeshare Board (thanks to Vince and
Jack for reverse-engineering the board and making a nice schematic!)
I'm accumulating parts to build one on an Omnibus prototype board.
Once I get that built, then it'll be time to try out ETOS, which uses
the improvements in trapping IOTs and dealing with field change
instructions that really improve timesharing performance over MULTOS 8.
I am also in the process of getting ready to image some old RK05 packs
that belong to Paul Anderson that may hold some interesting ETOS stuff.
The packs have been sitting around for quite a long time, and the
platters are very dusty. They are going to require some good cleaning
before they can be put in a drive, but hopefully, once I get them
cleaned up, I'll find some good things relating to ETOS.
I'll post updates here with my progress.
The Old Calculator Museum