[Simh] Subject: Re: something strange with simulated RK05 drive ?

[Paul Koning]

> On Feb 12, 2020, at 11:33 AM, Henk Gooijen <henk.gooijen at hotmail.com> wrote:
> 
> Thanks for responses, I learned a few things!
> (I can only respond when I am at home, sorry for the delay)
>  
> The first (big) eye opener for me was that RK11 registers in SIMH are
> of course *not* the same as the RK05, duh!  Good to know for future
> projects!

The same goes for most other disks and tapes, basically anything with multiple units per controller would make this distinction in one way or another.

> I knew about the error conditions on the RK05 drive that turn on
> the FAULT indicator, but in SIMH_PiDP-11/70_simulated-RK05 it is
> difficult to break the positioner glass or have a burned-out lamp 😊
> So maybe the FAULT indicator lights up for a few reason that could be
> plausible, but are in fact not correct as they are RK11 errors and not
> RK05 drive errors!  Maybe I can get away with saying that the simulated
> "RK05 drive" is a drive plus controller …

It should be limited to problems that are not programming issues.  For example, loss of signal on the USB connection would be a possible reason.  Bad disk address should not be.
 
> What I also learned is that (at least in SIMH) you do not need to
> FORMAT a new RK05 disk (container file)!  Just an .INIT RK0: will do!
> However, initially I could not get the RK05 simulation working, so
> I got stuck on FORMAT (the reason was a stupid mistake on my side).
> When I enter the .FORMAT RK0:  command, I see the ONCYL, RD and WT
> LEDs flash and flicker for quite some time. When I enter .INIT RK0:
> ONCYL flashes once, and RD and WT flash briefly.

That fits: it is writing a blank directory, so it only writes the directory blocks.

> I tried in a "virgin" SIMH environment and Bob is (of course) correct.
> You do not need to FORMAT an RK05 in SIMH!  But it does actually format.
> However, it does so until it goes outside the range of valid cylinders.
> I guess that can be fixed, but as Bob says: don't do that 😊
> On my (long) "to do" list: "why format tries to write cylinder 203"?

I don't have the code so this is just a wild guess: perhaps it wants to be able to deal with drives of varying cylinder counts by stepping until it gets an error, then say "I guess that must be the end of this drive".
 
> I understand that the behavior of the lamps on my "simulated RK05"
> completely depends on how I added code for that in pdp11_rk.c.  But it
> seems OK to me, because when I boot RT-11 from that simulated RK05 drive
> ONCYL and RD flash most of the time, but WT also flashes a few times.
> Long ago I booted a (real) 11/34 using Don North's tu58em with diagnostic
> printout and (to my surprise) during the boot a few writes occurred.

Curious, because I'm pretty sure you can boot RT11 (at least V2) on a write-locked system disk.  Other operating systems might complain, though; for example, you can't boot a RSTS OS if the disk is write locked.  (But in late versions, a write locked disk is treated as a distribution device, which is only read by the initialization code.)
 
> At the moment I cannot verify with a real RK05, because the temperature
> in my "museum" is a bit low to run a real RK05 (just 10 degrees Celcius).
> My current implementation turns on the FAULT lamp for several reasons.
> - for the RK11 errors (so I need to check and somewhat improve that),
>   although the errors are not likely to occur in SIMH, unless you are
>   programming access to the registers directly and make a mistake ...
> - if the drive (or software!) sets the drive to "read-only" (thus the
>   WT-PROT lamp goes on), and you do some write action, for example, try
>   to delete a file, the FAULT lamp goes on.
>   Toggling the WT-PROT switch or (RT11 command) .SET RK0 LOCKED will
>   turn on the WT-PROT lamp. Toggling again or .SET RK0 WRITEENABLE will
>   turn off the WT-PROT lamp.

I don't understand what .SET RK0 WRITEENABLE can be.  The manual says that there is a write protect command, but that's a set, not a toggle.  In my experience, the only way to enable write after a write lock is with the switch.

	paul