Rick, Yes, I was dealing specifically with the KL8E handler. I would agree that simh should probably provide a better emulation - that would be the best fix. Until then, I’ve modified the KL8E handler to use KRB instead of KRS. This bandaid is doing what I need for now - XON/XOFF is working. (I’m a neophyte in the world of simh, PDP-8, and teletype, and am enjoying digging into the guts of things. Last time I used assembly language was 1977 - SWTP 6800.)
Thanks, Bill > On Jun 5, 2016, at 6:14 PM, Rick Murphy <[email protected]> wrote: > > At 08:54 PM 6/5/2016, William Wuttke wrote: >> Problem: >> >> When using a teletype on a serial port, XOFF will stop a directory listing >> (and others), but once that happens, the PDP-8/simh will no longer respond >> to keyboard input. Iâm using a Model 33 ASR on a PiDP-8 (raspberry pi) >> hardware serial port. >> >> Investigation: >> >> All documentation says XON and XOFF should work from the console. Well, it >> does and it doesn't. > > Any documentation that says that about OS/8 is inaccurate. > > Many programs simply push character output as fast as the native baud rate > and never checks for any keyboard input (other than perhaps for control-c.) > > > >> If using "screen", it works, but apparently the XON/XOFF functionality lies >> somewhere other than in the KL8E handler. > > That's probably happening within screen, where OS/8 never sees the input, > with buffering being handled by the native OS. > >> The typing stops when XOFF is sent. Then when XON is sent, you can see some >> buffered text appear on the screen fast, then the typing slows down to >> normal speed. (I set the tto unit wait value to 20000 to closely approximate >> real 110 baud serial output. Otherwise, a directory listing gets buffered up >> an about 3 seconds, but takes 2-3 minutes or longer to print out on the >> teletype. This also allows me to Control-C to quit the listing.) It looks >> like "screen" is buffering the text. > > Assuming you're using something like "TYPE FILE.TX", which CCL converts to > PIP TTY:<FILE.TX. So, the KL8E handler gets used here. > >> If using the teletype, XOFF stops the typing, but XON does nothing - the >> machine is locked up in a loop at this point with 7623 in the accumulator >> (it works as coded). Looking at the KL8E handler, the tty check routine uses >> KRS to read a character, never resetting the keyboard flag. Apparently, >> since the KL8E had no buffering, if an incoming character is not read, it >> would be overwritten by the next incoming character, clearing the keyboard >> flag during the time that the character was not valid, then setting it after >> the character was assembled into the keyboard buffer. It looks like the KL8E >> handler was written depending on this behavior. However, it looks like the >> simh tti is acting like a modern UART, buffering up the input, and moving >> through the buffer as characters are read. The KRS instruction is for all >> purposes a "peek" at the next character in the buffer, which is exactly what >> the tti is doing. It keeps "peeking" at XOFF (7623 - 7600), which never >> really gets removed from the buffer. However, it really needs a "read", to >> advance to the next character. At least, that is what it looks like. > > This sounds like a SIMH defect. KRS should read the last input character, as > there's no buffering on the real hardware. > >> Fixes? >> >> I'm going to attempt to mod the KL8E handler to fix this, but might not have >> much luck since it already pretty much fills up its allotted two pages. It >> is filled with all sorts of assembly language trickery to fit into two >> pages. In my way of thinking, the simh KL8E is really âmodifiedâ >> hardware, and OS/8 can be easily adapted to new hardware. I think I have a >> fix, using KRB instead of KRS - I donât think that using KRS was a good >> idea anyway, but on a real PDP-8 it would catch the XON as soon as it >> happened. >> >> Or, could a mod to simh do the trick? Could the KRS be modified to act like >> a KRB, but just ORâing the keyboard buffer with the accumulator instead of >> clearing the accumulator it first? How would this affect other PDP-8 >> software that relies on KRS without subsequently clearing the keyboard flag? >> How common is the use of KRS in this way? I guess in this day and age, >> trying to eliminate all the buffering going on would probably be a real >> pain. And, the buffering on the input actually eliminates the need use the >> teletype Reader Control with simh. >> >> Does anyone have any ideas? > > If the SIMH KRS doesn't read the last input character, it needs fixing. > Changes to the KL8E handler will only fix TYPE and DIR, and leave lots of > other problems. Seems like a simple SIMH fix to drain the input buffer every > time KRS is executed will fix this. > -Rick > _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
