On May 2, 2009, at 7:05 PM, Johnny Billquist <bqt at softjar.se> wrote:
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...
That's the real problem- first you fix the KBM then you'll need to fix
the command processor. Then Basic, etc.
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.
Yes, using the OS/8 Software Support manual for help. It's
not easy.
(Starting with getting good source, then humming enough room to add
your changes.)
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).
I think you're right. Another suggestion that comes to mind is a
simple PIC based widget that front ends tv VT05, inserting nulls as
needed.
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. :-)
I would have replied earlier, but this iPod doesn't make entering long
replies convenient.
-Rick