Philipp Hachtmann <hachti at hachti.de> wrote:
Hi. As a first general comment, I should point out that is was years
since I played with this, so all I write is from hazy memories. I could
check it all out, but that would take some time, so I'll just write away
for now, and hopefully this will be enough to set you on the right path
yourself. :-)
> I just try
to get a VT05 working with my PDP-8/e.
> Having a tuned KL8E interface at 2400 baud.
And I begin to think about
switching everything to 300 baud :-(
In a way, that is your only option, yes. Sad as it might seem.
> I need
fill characters....
> Found a KL8E.PA in the OS/8 V3D sources. It is a two page handler and
> works.
Yes, it works with applications using the TTY handler
It works with applications that don't do explicit termimal I/O, but
instead do file I/O and the output (or input) is actually the terminal.
That's the only situation where the terminal driver is involved. The
terminal driver is really not adapted to use as a general terminal I/O
handler, but only to use as one output/input alternative when you do
file I/O.
So it will never be, or do, what you want in this situation.
You need to
use BUILD to make a new system image, with your device
driver included. However, you also need to understand many programs do
I/O to the console without going through that device driver, but talks
directly with the console.
So it might be that there is no easy solution to your problem.
And the very first
of these "bad" programs is the OS/8 keyboard monitor!
That's just the beginning of it, however...
Yes, the keyboard monitor doesn't use a handler,
it just uses TLS to print what it wants to print.
This explains why my DIRECT output works fine with the KL8E handler with delay turned on.
But I
don't get the prompt properly (sometimes). The keyboard monitor implementation looks
very straight
forward.
So there are a few new problems on my way to a working 2400 baud VT05:
How to correctly assemble the keyboard monitor? There is at least one undefined symbol in
the source
code (V3D).
Can't make any comments on that. I think I have all the sources
somewhere, and they are also probably on the internet, but I have never
tried building the whole system from scratch.
When I have the binary - how to put that onto my
system device?
That's another story. I can't remember for sure, but I think you can do
this with build.
The software support manual, OS/8 manual and
"Introduction to programming" did not really help me.
They explain *some* procedures, but only in a step by step way. They tell about building
from paper
tape using "CODNFIG" tapes (what IS that???) or the build program. They
reference paper tapes that
contain "several binaries" - but don't explain WHICH binaries. Just that
the user has to load all of
them... So in the end I did not find out how an OS/8 system is initally built.
In your case, you probably want to use BUILD.
The BUILD program can do it, I know. But where does it
take the keyboard monitor from? The "OS8.BN"
binary is not included in the installation - but I can spawn new systems using BUILD. So
it must
somehow *contain* the OS/8 binary.
I could imagine that one has to load several binaries on top of each other to pull
together the core
image that comes as BUILD.SV. But where can I find the instructions?
All the relevant bits and pieces are in the OS/8 handbook. But in short,
build can take a current system image and use as a base for the new one
if I remember correctly. So it don't contain the OS/8 binary itself.
That would be pretty dumb, by the way. It would make upgrading
difficult, since you'd have to match BUILD.SV to whatever OS image you
were using.
BUILD can also replace device drivers in your system. That is fixed
blocks on the system disk, I think.
All in all I cannot understand why I'm getting in
such deep trouble while trying to get my VT05
working. It is a VT05 B with the "high speed" option, sold for $$$ by DEC.
Their TTY handler also supports the odd ends of the VT05 - but why doesn't the
keyboard monitor?
Either I am completely wrong or their software really did not fit their hardware.
In other places (VR14 display), they have built in the strangest device drivers into
their software,
just ready to use and plug and play. Why shouldn't they have supported their high
speed VT05? It is
from 1974, OS/8 V3D is newer than that...
To make a long story short. The PDP-8 wasn't exactly a top of the line
product by the time the VT05 came out. OS/8 was written before this, and
it is those limitations that you are hitting. V3D wasn't exactly a
redesign of the system. Just some fixes. The problem you are looking at
goes straight to the core of the system design. There is nothing you
could do about that short of totally rewriting the whole system. And
then it wouldn't be OS/8 any more.
In short, all programs that do terminal I/O specifically in OS/8 do it
themself. No device driver is ever involved. And all programs knows
this. So there is no way you can change that paradigm. All programs
would still do it that way, even if you did redesign the monitor.
There is possibly one path to relief, however. Unless my memory fails
me, the KL8-JA (and maybe the KL8-E as well) have a jumper to insert 4
(I think it was) fillers after a LF. This is a hardware fix for your
problem, and is what DEC did.
In short, there is no software solution to the problem within OS/8. But
there is a hardware solution (unless my memory fails me).
Best wishes, currently a bit frustated,
Philipp :-)
:-)
Funny that noone else around seems to be able to answer. I thought there
were atleast some people with experience from older systems around. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol