Adventures in porting land

[jgharston]

I've been working away on my PDP11 RT11 host code for BBC BASIC for the last few weeks, specifically on passing oscli commands to the host. This is really fiddly on RT11. On almost all platforms there is some sort of external command call - what we know as OSCLI, what C programmers know as system(), etc. However, on RT11 there is no way of calling a command and - crucially - getting back to the caller. You can pass execution over to something else, but you never get back again. In RT11 it's explicit in that the method to do so is by calling EXIT ! and passing it a command to exit to.

This is similar in some ways to CPM. With that, the application has to implement all commands itself. For instance, Z80 BASIC implements *DIR, *ERA, *REN, *this, *that, etc. in support code in the BASIC binary itself. RT11 applications have to do the same. I remember that back at university on the VAXen it was also the same. As an exploratory project the first thing I wanted to do was implement the equivalent of REPEAT:INPUT "Command> "A$:OSCLI A$:UNTIL FALSE and asked my course tutor how to call an external command "for instance, if my program wants to do a DIR". His reply was: ah, here are the reference manuals, it will document how to open a device and read a directory to list it. NO! THAT'S NOT THE QUESTION I ASKED!!!!!

I was digging into the RT11 version of Kermit to get ideas, and every instance of what should be shell(command) is implemented internally in Kermit itself.

This "offends" me. In several ways. It duplicates code. All those commands are already implemented in the KMON (RT11's version of COMMAND.COM, CCP.SYS, etc.). I, the programmer, don't know what commands there are out there, so any implementation I build internally will be always be deficient in something. And it unnessessarily bulks up all application code with all that duplicated code.

I was determined to find some way of implementing system() on RT11. I was getting fed up of having to remember to catalog the directory before running BASIC, as once in BASIC I wouldn't be able to see what files I had, so at the very least I wanted to implement *. With some testing I'd successfully been able to exit BASIC and pass a command to KMON, but of course that left the me at the KMON prompt. I needed a way of not just getting back to BASIC, but getting back to the same point in BASIC at he same point at whatever BASIC was doing.

It took some effort over several weeks, digging into the RT11 code and digging though manuals, but I managed to finagle a way of passing a command "out" to KMON, and getting back again. Code along the lines of: PRINT "Choose a file:":OSCLI ".":INPUT "File: "A$ would work.

At the moment I've disabled passing anything other than "*." on to a carefully preformed "DIR" command, as any error bombs out to the RT11 KMON monitor and doesn't come back again. The next step is to try and work out how to get back after an error, but at least now I can see what I'm working with when in BASIC! It works prefectly with "real" RT11 on SIMH and E11, there are occassional problems with RT11 on UKNC, and the RT11EM emulator comes back to BASIC, and then quits the emulator. But at least it's getting there.

[dominicbeesley]

So what did you have to do (in general terms.... assume we know nothing about rt11!)

[jgharston]

Over the last month I've been going through PDP11 BASIC, combing through the source tweeking and updating the host interface code. Essentially, the BASIC is "done", and - like Richard with his - I'm reluctant to mess too much with it other than where obvious bugs show up. Everything I've been working on in the last years has been creating I/O drivers for various platforms. I've particularly been trying to capture signals on BSD2.11 - it current polls Escape instead of being interupted in the background, and any access to "bad" memory aborts instead of it being trapped and generating an error.

After a great deal of slogging - the BSD2.11 documentation is really sparse and contradictory, and I ended up disassembling test code and the kernel itself - I've got signal handling working. So reading non-existant memory wth A=?&E000 now generates an error instead of bombing out and dumping. Yay!

Try it out at https://mdfs.net/Software/PDP11/BBCBasic/

The remaining missing functionality is:
RT11: OSGBPB/BGET/BPUT/PTR/EXT - will be fiddly as the native I/O uses word transfers, not byte transfers
BSD2.9: Test for key pending, so edit/fkey detection works
BSD2.11: Background Escape testing
Would like to do:
Unix5/6: PTR/EXT - the underlying tell() call is broken, so will need to be manually implemented, wrapping around every BGET/BPUT/GBPB call

I mentioned the BASIC itself is "done". Well, other than trig/log functions. But they are completely isolated in a seperate code module, so can be worked on seperately. And I've been rolling up my sleeves re-learning transendental programming. I still can't find my "orange book", so I borrowed Cody & Waite from the library.

...I'll get back to answering Dominic's question after a cuppa.

[flaxcottage]

Great stuff JGH.

I do not pretend to understand but it sounds good. I bet if you tried to explain to me just using 3 letter words it would still be over my head.

[SteveF]

This is fascinating stuff. It makes RT11 sound really primitive, did it have much success or did it pretty rapidly get replaced with something more OS-y? (OK, not a great description. But missing something as fundamental as a way to call another program seems strange.) And I'm astounded a Unix - albeit an early one like BSD2.11 - is so tricksy to work with. I'll probably never run your BASIC on this hardware, even in emulation, but it's interesting to hear details about developing on these older systems.