[Simh] Interdata Emulation

[Davis Johnson]

J. David Bryan wrote:

>For some reason, delivery of your message was delayed until the 10th.  Are 
>you still having trouble?
>
>  
>
Probably somthing to do with a new list member making a first 
submission. Not realy important - gave me some time to persue some other 
problems.

>>The Interdata SIMH documentation says that a non-attached disk appears
>>as "not ready". My command file looks like: 
>>
>>    set cpu 832
>>    set dm0 msm300
>>    att -e dm0 dm0.dsk
>>    att mt0 boot.tap
>>    d 78 85a18540
>>    set cpu hist=100
>>    set br 954a
>>    boot mt0
>>    
>>
>
>I don't know anything about the Interdata machines, but your command file 
>looks reasonable to me.
>
>I note without understanding this comment in the Interdata simulator 
>documentation:
>
>  "To boot OS16/32, the hex form of the operating system file's
>   extension must be placed in locations 7E:7F." 
>
>I gather that you're accommodating that requirement?
>  
>
I'm booting from tape, so some other considerations apply. The "d 78 
85a18540" is required for booting the OS from tape. SIMH will boot 
diagnostics from tape without this extra initialization. The OS boot 
from tape does some strange things. The Auto Load instruction reads the 
first 80 bytes of an about 1.5k boot loader from the tape. Naturaly all 
sorts of data overruns occur in the data path from the tape drive as the 
tape keeps spinning. Those first 80 bytes of the tape get the drive 
reset and read the whole block this time somewhere higher in memory. 
This bootloader can load an os off of tape or disk, thus in addition to 
the locations that need to be initialized for the autoload instruction 
(and are initialized by the SIMH boot command), locations need to be 
initialized to tell the boot loader where to find the OS. In this case 
on the same tape as the bootloader. I get the OS to load and start just 
fine. It is a credit to SIMH that it handles this tape drive abuse just 
fine.

>Although I know nothing about your machines or the fidelity of the SIMH 
>simulation, from extensive work with the HP 2100 simulators, I can 
>recommend that a good place to start would be with the original Interdata 
>system diagnostics, if they are available to you.  Running the HP 
>diagnostics against the simulator resulted in 83 bugs being reported and 
>fixed.  SIMH now runs the HP RTE series of multiuser, multiprogramming 
>operating systems flawlessly, whereas they wouldn't boot when I started.  
>Tracking down problems one at a time via the diagnostics proved far easier 
>than trying to determine why an interrupt-driven RTOS wouldn't run.
>
>  
>
There are two Interdata disk controlers supported by SIMH, I've got one 
working in both OSs, the other fails in both OSs.

Running diagnostics is next, before I make too much noise on the list.

I will, however give a quick synopsis here:

Single stepping the OS driver I discover that basicly what is happening 
is that the driver does a "Sense Status" instruction to the device and 
gets back a "Device Not Ready" status and gives up. The Interdata SIMH 
documentation says that "Device Not Ready" is returned if a file is not 
attached. Stepping through the SIMH code that implements the SS 
instruction looks like that is indeed what is happening - the SS 
instruction thinks there is no device attached. Given that the Interdata 
IDE disk controler is reputed to pass diagnostics (which I should be 
able to try in the next day or two) it is reasonable for me to suspect 
that my having somthing set up wrong is at least as likly as a bug in 
the code.

Actual details later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20060212/d92e2120/attachment-0003.html>