[Simh] Reading directly from console in RT-11

Will Senn will.senn at gmail.com
Sat Feb 20 12:25:15 EST 2016



Sent from my iPhone

> On Feb 20, 2016, at 11:00 AM, Paul Koning <paulkoning at comcast.net> wrote:
> 
> 
>> On Feb 19, 2016, at 4:58 PM, Will Senn <will.senn at 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
> 

Great answer and helpful. I'll give both approaches a shot. If I understand my environment correctly, RT-11 is single user, single job (well, most of the time anyway). So, it oughta be safe enough to try this without messing things up beyond needing to restart if I have logic errors? That is, the file system isn't involved or caching or anything that would cause inconsistency as a result of an infinite loop or crash? Not that I would ever code such things :)!

Thanks,

Will


More information about the Simh mailing list