> On Feb 19, 2016, at 4:58 PM, Will Senn <will.s...@gmail.com> wrote:
>
> Given the following test program that I wrote (GETC.MAC):
>
> .title getc
>
> .mcall .exit
>
> TKS = 177560
> TKB = 177562
> ;TPS = 177564
> ;TPB = 177566
>
> begin:
> inc TKS ;set the ASR read enable bit
> getc:
> tstb TKS ;is a character available?
> bpl getc ;loop until there is
>
> movb TKB,R0 ;put the character into register 0
>
> .exit
>
> .end begin
>
> I would expect the console to wait until I typed a single character and then
> for the program to exit. What is happening is that the program appears to
> accept any number of characters and only ends when I type CTRL-C twice.
>
> Here are some questions that arise:
>
> 1. Is it reasonable to expect to be able to read directly from the ASR
> Keyboard buffer while running RT-11 in SimH or does this somehow compete with
> the running OS? (I can print characters using the ASR Punch Buffer just fine)
No, that is not reasonable. Not without extra work. You're messing with a
device that has already been set up by the terminal driver.
When running in kernel mode, as you are in RT11, you can definitely get around
this, but it requires more work. Specifically, you'd have to disable terminal
interrupts so the appearance of a character doesn't wake up the driver. For
best results, you would also have to restore the terminal CSRs on exit so the
terminal driver is given control again.
Alternatively, you could block out interrupts by raising the processor
priority, then lowering it back to 0 before exit. That works because
interrupts are level sensitive in PDP11s (as they are in all sane interrupt
architectures), so the fetching of the received character will cancel the
interrupt request, which means that lowering the priority just before the .exit
will have the right result (no interrup to confuse the driver).
paul
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
