DEC VT05 with OS/8 -- basic system rebuild?

[Rick Murphy]

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