Physical simulation of the RK05 disk drive

[Henk Gooijen]

I am working on a "physical simulation" of the RK05 disk drive. The idea is to have an RK05 front panel with the same dimensions as the PiDP-11/70 front panel. The RK05 front panel can then be mounted above the PiDP-11/70 front panel and thus create the "PDP-11 rack" on the desk.
The RK05 front panel has two switches (toggle switch LOAD/RUN and momentary switch WT PROT) and 8 indicator lamps (PWR, RDY, ONCYL, FAULT, WT PROT, LOAD, WT, and RD). Further "interaction" hardware is a solenoid that blocks opening the front door (when a disk cartridge is loaded and spinning).
I plan to interface the switches and indicator lamps (and solenoid) using one MCP27013 IC. This IC uses the I2C connection, thus wiring to the PiDP-11/70 is only 2 wires plus power supply. Technically, the hardware (electronics) side is not difficult, hardware (mechanically) requires some work ...

The work is of course in the software side to get things working as it is in reality (more or less).
The behavior of the indicator lamps (and solenoid) is rather straight-forward. The behavior of the WT PROT switch is also clear and easy to add.
However, for the "mechanism" behind the functionality of the LOAD/RUN switch choices must be made.
I show the choice I am thinking of using a step-by-step description of the events.
1. LOAD/RUN pushed to RUN position.
    - indicator lamp "LOAD" goes off
    - solenoid is de-activated (locks the front door)
    - start a software timer (to simulate spin up time of the drive)
    2. Software timer expires after [tbd] seconds.
        - issue to SIMH an ATTACH command for drive 0 (=> which container .dsk file ???)
        ==> ATTACH command failed -> indicator lamp "FAULT" goes on
        ==> ATTACH command OK -> indicator lamps "RDY" and "ONCYL" go on
    3. Successful read accesses -> indicator lamp "RD" goes on and off
    4. Successful write accesses -> indicator lamp "WT" goes on and off
    5. Only on track 0 -> indicator lamp "ONCYL" goes on else off

2. LOAD/RUN pushed to LOAD position.
    - all indicator lamps go off
    - start a software timer (to simulate spin down time of the drive)
    2. Software timer expires after [tbd] seconds.
        - issue to SIMH an DETACH command for drive 0
        - solenoid is activated (unlocks the front door)
        - indicator lamp "LOAD" goes on

The issue is *which* container file must be opened by SIMH when the ATTACH command is given?
In reality that is the physical disk cartridge that you insert into the drive.

Solution #1.
If you mount a physical disk drive behind the front door, you can simulate the physical disk cartridge completely. A 3.5" floppy drive does not contain the capacity of the RK05 disk (~2.5 MB). Other storage options would be a removable hard disk (Syquest) or USB sticks. The USB stick is the most convenient choice. You could make a 3D print of a scaled RK05 cartridge and put the USB stick inside that cartridge to create the ultimate RK05 simulation ...
To make the simulation "perfect", the USB stick contains only *one* RK05 container file, and all RK05 USB sticks that you use have one container file and they all have the same name! The label on the USB stick tells you which data is on the "disk cartridge" (USB stick) as it was/is in reality.
With this choice the ATTACH command is obvious as it always attaches the same file from the (different) USB stick.

Solution #2.
This solution is based on solution #1, but (a) does not waste all the space that is available on the USB stick, and (b) does not require many disk cartridge swaps (because more RK05 disk container files are on one USB stick). The problem here is that you now have to specify which container file must be opened.
The file could be specified by a new SIMH command, for example "ATTPHYS" (ATTACH PHYSICAL). To SIMH you enter the ATTPHYS command with a file name before you use the RK05. When the LOAD/RUN switch is pushed to "RUN" the RK05 ATTACH command uses the file that is specified with the previous ATTPHYS command.
If no ATTPHYS command was given, the result will be indicator lamp "FAULT" goes on, all others go off.
If opening of the specified file fails, indicator lamp "FAULT" goes on, "RDY'and "ONCYL" go on (as in reality, you can load the wrong disk cartridge ...)
If opening of the specified file is OK,  indicator lamp "RDY'and "ONCYL" go on, and "FAULT" goes off.

Choice proposal.
Although it is wasteful, solution #1 is preferred. It simulates "reality" the best and avoids adding a command (ATTPHYS) to SIMH.
Another drawback of solution #2 is that, after the ATTPHYS and actual use of the RK05 "disk", and you would want to swap the USB stick or use another file on the same USB stick, you would have to stop the PDP-11/70 simulation to enter a new ATTPHYS command in SIMH.

If you use solution #1 and have the USB stick actually behind the RK05 front door, you even cannot "by accident" pull the USB stick, because as long it is in use the front door will be locked!

How to proceed this fun project ...
I made a design using Front Panel Express (see attached image). It is just a preliminary design, and the positioning of all holes (switches, indicator lamps, ventilation slits and door opening) still needs to be aligned. Using 2 mm aluminum the cost as it is now is 200 Euro for the front panel (!), but some threaded holes at the rear side still have to be added for mounting (for example the switches).
Those threaded holes are of course invisible at the front side. However to make those threaded holes, the front panel thickness needs to be more than 2 mm. I did such a front panel (PDP8/i) using 6 mm thickness, but it will cost more (more material cutting, thus more cost they say). As long as I am designing this costs no money :)
I ordered an MCP27013 IC and when it arrives I will connect it to the PiDP-11/70.
The two switches, 8 lamps and solenoid are connected to the MCP27013.
All that remains to be done is hacking ^H^H^H^H^H^H^H modifying the SIMH software.
I will try to do this in a as-little-as-possible intrusive way to SIMH.

Got excited? Have opinions or proposals? Any comments?
I'm all ears!

BTW, I am also designing a scaled door (of course).

[Mark Matlock]

Henk,
    Your project sounds great! I'd love to have a PiDP-11/70 & RK05 replica rack mounted on my desk. If you decide to make a kit of it put me on the list.

     I've also been playing with the MCP23017 chip to re-annimate another PDP-11/70 console (this time a proper
purple and maroon one). To simplify the hardware side of this for me I'll be using three of these daughterboards from
ModmyPi (see https://www.modmypi.com/raspberry-pi/iousbanalogue-expansion-1028/gpio-expansion-boards-1029/modmypi-mcp23017-hat-32-channel-io-expansion-hat ). That will give me 96 GIOs that can be powered by +5V external of the Pi's power.

For your purposes the breadboard area on the PiDP-11/70 will work fine to hold a MPC23017, but while you
are in the software development phase, you might find this board helpful so you can use another Pi for the development, and
only start making changes to PiDP-11 mother board when everything is worked out.

I ordered an MCP27013 IC and when it arrives I will connect it to the PiDP-11/70.
The two switches, 8 lamps and solenoid are connected to the MCP27013.

All that remains to be done is hacking modifying the SIMH software.

I will try to do this in a as-little-as-possible intrusive way to SIMH.

Best,
Mark
 

[Henk Gooijen]

Thanks for the vote of confidence Mark :)
I got an MCP23017 on a breadboard last weekend.

but ... for clarity, there is no project – at least not yet. I am still investigating, although I do not see much issues in the (electrical) hardware and software. The biggest problems are in the mechanical hardware. Not so much the construction, but the cost! The front panel made in 2 mm thick aluminum is already at 200 Euro (no profit, just the actual cost), and I need a few more holes (not that much money), but I also need to increase the thickness so that you can mount screws on the rear side and not visible at the front side. On my website you can see such a front panel project for the PDP8/I . The result is great, but the cost also :(  You need threaded mounting holes on the rear side to mount the switches and LEDs, but also to mount the front door and the "cage" to hold the RK05 disk cartridge (with the USB stick), and the bracket that hold the USB "socket".

I also would like to be able to control more than one RK05 ... after all, you want to be able to copy “RK05 cartridges” :)  It will make it twice as expensive (second front panel). And then I have a choice. If I do not engrave the disk drive number ("0"), you can use the *same* panel for another drive ("1"). Just like the real RK05 drives, a number label is glued on the front panel! The advantage of not engraving the number is that the total production of (identical) panels might go over 10. That will make the panel slightly cheaper. The cost for one (at the moment) is $198.85. Discount according to FPE: 5-9 pcs $178.96, 10-19 pcs $159.08, 20-29 pcs $139.19, > 30 pcs $ upon request. So, 'more' is good in this case, but we need a nice solution for gluing the drive number on the panel.

The interface uses the I2C signals (3 pins just at one corner on the PiDP-11/70 PCB underneath the RasPi) : 3V3, SCA and SCL, and GND from the experimenter’s area on the top part. That connects to one MCP23017. That IC gives you 16 I/O lines! I got that “breadboarded” past weekend, and I can turn on/off each LED using command line commands using Gordon Henderson's "wiringPi". This week I plan to work on a C program so that I can do something like calling rk05WtProtLedOn() and rk05WtProtLedOff(), etc. from SIMH.

Additional cost will be for LEDs, switches, a solenoid and the material for the front door. To be determined is how to construct the front door (looking exactly like the real RK05 door of course). Ideas done, now searching for a shop that can bend plexiglass ...

All in all, I am not sure many guys wants this, because in the end the "RK05 disk drive" is probably costing more than the PiDP-11/70 !  Working out the ideas is not costing much so I am still having fun :)

Greetz,
Henk

[Johnny Billquist]

A couple of comments:

1) Having several images on one stick: Why don't you add a dipswitch or
some other selector on the "pack", to select which image is supposed to
be used. Expect images to be named rk05-n, and assign the appropriate
image based on the dip switch or similar selector. Since you're already
running a couple of pins for indicators and switches, this would be an
easy extension. Pick some common form factor for the USB stick, and you
can swap the stick if it develops issues, which the "pack" will be more
expensive, you will not need that many.

2) There was a field upgrade to the RK05 which a unit switch was added
on the front, so you could easily change the unit number. This could be
a nice thing to do instead of the stickers. Might be a bit more
challenging to implement in the simh framework, though.

3) Make it optional to simulate the waiting time for spinning up and so
on. The ONCYL lamp after all indicates when the device is ready. Not
everyone might want to wait an additional 5 seconds just because the
actual hardware took that long. There will also be complications when
you play around like this. Remember that people can turn off the run
switch before the disk comes online, for example.

While I could see that it would be really cute if you actually made
small packs that looked like the real thing, which you loaded into the
drive, I would most likely not be that interested anyway. An RK05 is way
too small to be of interest here. The RK05 was the perfect drive for the
PDP-8.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/429dbdae-713c-4375-83a4-aeb49a3841a0%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/429dbdae-713c-4375-83a4-aeb49a3841a0%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Paul Birkel]

-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Johnny Billquist
Sent: Monday, July 16, 2018 3:45 AM
To: pid...@googlegroups.com
Subject: Re: [PiDP-11] Physical simulation of the RK05 disk drive

A couple of comments:

...

An RK05 is way too small to be of interest here.
The RK05 was the perfect drive for the PDP-8.

Johnny

-----

It seems to me to be appropriate as well for the PDP-11/10 and -11/20-era. Consider the limitations of paper-tape or CAPS-11.

Agree that once you get to a model for which RT11 was designed that it does begin to fall short of "ideal". So in that sense it's a pretty serious anachronism for an 11/70-surrogate.

What we need is a top-loading RM03 with mini-disc-packs :->.

----

[Johnny Billquist]

On 2018-07-16 10:21, Paul Birkel wrote:
> -----Original Message-----
> From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Johnny Billquist
> Sent: Monday, July 16, 2018 3:45 AM
> To: pid...@googlegroups.com
> Subject: Re: [PiDP-11] Physical simulation of the RK05 disk drive
>
> A couple of comments:
>
> ...
> An RK05 is way too small to be of interest here.
> The RK05 was the perfect drive for the PDP-8.
>
> Johnny
>
> -----
>
> It seems to me to be appropriate as well for the PDP-11/10 and -11/20-era. Consider the limitations of paper-tape or CAPS-11.

Noone would even dream of running those systems today, much less on an
11/70. :-)
But sure, for those ones, an RK05 is appropriate. Except, of course,
paper tape systems were on paper tape, and CAPS-11 were on compact tape.
So neither ran on an RK05. :-)

> Agree that once you get to a model for which RT11 was designed that it does begin to fall short of "ideal". So in that sense it's a pretty serious anachronism for an 11/70-surrogate.
>
> What we need is a top-loading RM03 with mini-disc-packs :->.

When I first started playing with computers my school had an PDP-11/70,
with one RM03. All user accounts for four schools on that pack, along
with the system itself. Disk quotas were the story of the day. (You
started out with a 20 block quota, but people who did more than just the
school classes soon got upgraded to a huge 200 block quota.) :-)

Sites with a little more money had an RP06 or two.
Really serious sites would have had an RM05 or two.

And then came MSCP, and everything moved to that.

Johnny

[Neil Higgins]

RK05s were “the bees knees” for PDP-11s at the dawn of my memory. They looked sexy too. RL01s and RL02s came later. And there were many 3rd party products. The idea of DIP switches on the “packs” is appealing, albeit DIP switches are terrible things. Some other kind of switch? Could I offer the suggestion that you start with something 3D-printable that people can make for themselves, or send to a 3D print shop?

[Paul Birkel]

-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Johnny Billquist
Sent: Monday, July 16, 2018 4:55 AM
To: pid...@googlegroups.com
Subject: Re: [PiDP-11] Physical simulation of the RK05 disk drive

On 2018-07-16 10:21, Paul Birkel wrote:
> -----Original Message-----
> From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Johnny Billquist
> Sent: Monday, July 16, 2018 3:45 AM
> To: pid...@googlegroups.com
> Subject: Re: [PiDP-11] Physical simulation of the RK05 disk drive
>
> A couple of comments:
>
> ...
> An RK05 is way too small to be of interest here.
> The RK05 was the perfect drive for the PDP-8.
>
> Johnny
>
> -----
>
> It seems to me to be appropriate as well for the PDP-11/10 and -11/20-era. Consider the limitations of paper-tape or CAPS-11.

Noone would even dream of running those systems today, much less on an 11/70. :-)
But sure, for those ones, an RK05 is appropriate. Except, of course,
paper tape systems were on paper tape, and CAPS-11 were on compact tape.
So neither ran on an RK05. :-)

-----

Indeed :->.

It seems to me that it would be less costly -- and therefore more suitable for a mass audience, to model and 3D-print a mini-RM03 with spots for a few switches/lights on the front and a top-cavity with an embedded USB socket that would connect by cable to the PiDP-11. There are all of these mini-PC/Mac/other models/recreations that follow that paradigm so the path/approach isn't terra incognita. Then the disc-pack is a short USB stick embedded on a 3d-printed cylindrical form. (Yes, no top cover -- although I imagine that a flip-top could be worked out, even with a latch :->.)

Not sure that I'd print it to the same scale as the PiDP-11 itself - it would be about the size of a desk-side tower-case PC rather than "merely" a 2/3'rd scale 6U 19" panel severely truncated in depth! Something about 4" tall and 3" deep might be about right to establish sufficient "presence" while being printable in common 3D-printers.

paul
-----

[Johnny Billquist]

On 2018-07-16 11:17, Neil Higgins wrote:
> RK05s were “the bees knees” for PDP-11s at the dawn of my memory.

True. In the early days of the PDP-11, the RK05 was often the disk of
choice. I probably should have mentioned that in addition to paper tape
and CAPS-11, which by their very design excluded the RK05, you also had
DOS-11, which definitely did use the RK05. And that is sortof the
precursor to RT-11. RT-11, especially in the early days, would also
often be on an RK05.

> They looked sexy too. RL01s and RL02s came later. And there were many 3rd party products.

I agree. I like the looks of the RK05. I still have plenty of them. But
all connected to PDP-8 systems.
RL01/RL02 are nicer in some way, but they have never had the same
attraction.

> The idea of DIP switches on the “packs” is appealing, albeit DIP switches are terrible things. Some other kind of switch? Could I offer the suggestion that you start with something 3D-printable that people can make for themselves, or send to a 3D print shop?

No matter what kind of selector, it should at least have 8 or 16
settings. DIP switches are just so easy. And there are better or worse
quality to pick from. Some designs are pretty nice and reliable.
But I guess this is something for Henk to think about. I just made a
suggestions that at least I think would be a nice solution.

I also realized one more thing he will have to deal with. Not only will
he need to do the attach when the disk is "spun up". For some systems,
figuring out where the USB stick actually is in the system can be
non-trivial, and for some systems, you will also need to mount the USB
stick itself before it is accessible at all. Which can only be done
after it has been physically connected.
Don't know if Pi's use some automounting feature in Linux for USB
sticks. Otherwise this is also something that needs to be worked on. And
you still need to know where that stick pops up in the file system...

[Paul Birkel]

-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Johnny Billquist
Sent: Monday, July 16, 2018 5:28 AM
To: pid...@googlegroups.com
Subject: Re: [PiDP-11] Physical simulation of the RK05 disk drive

On 2018-07-16 11:17, Neil Higgins wrote:
> The idea of DIP switches on the “packs” is appealing, albeit DIP switches are terrible things. Some other kind of switch? Could I offer the suggestion that you start with something 3D-printable that people can make for themselves, or send to a 3D print shop?

No matter what kind of selector, it should at least have 8 or 16
settings. DIP switches are just so easy. And there are better or worse
quality to pick from. Some designs are pretty nice and reliable.
But I guess this is something for Henk to think about. I just made a
suggestions that at least I think would be a nice solution.

-----
There are small, cheap, reliable, rotary switches and encoders (e.g., 24-position quadrature) ... although you'll need to add a teeny-something-or-other processor (DIP-8 or SMD) for the latter. But it sounds like a PCB is needed anyway for the stick-with-DIP-approach so the added complexity is quite low and the convenience and reliability seem like they would be worth it..

paul
-----

[Neil Higgins]

I agree that 60% is a bit on the large side for 3D printing. I have an entry-level 3D printer that certainly could not handle it without some software splitting and hardware gluing.

At one stage I had a fantasy of further miniaturising the PiDP-8 with DIP switches and surface-mount LEDs ... might still be done, but I'm not "retired enough" yet. A "tiny RK-05" would be a good addition.

You might be able to handle a rotary encoder with some bits of your I2C chip - it has lots of fancy features (interrupt on change, etc.).

The mechanical side presents some unique challenges: Is there a retired/frustrated/mad industrial designer out there???

Pi's do indeed have an auto-mounting feature in Linux for USB sticks - Oscar uses that on the PiDP-8 to detect "paper tapes".

[Peter Willard]

You know, you could just use an RFID reader attached to the Pi and have programmable "tags" the pseudo cartridges would be *read* and then a specific disk becomes flagged as the one you "loaded".  Not simple, but it would add to the simulated realism while magic happens behind the scenes.

[Whit Turner]

Fun "project" if only conceptual for now. How about adding a small speaker to simulate the sounds an RK05 makes - the spin up noises, the squeaking of the positioner, even a head crash (just kidding). It could be connected to the Pi's audio out jack and wav files played during different RK05 activities.

Whit

[Jerry Weiss]

On Monday, July 16, 2018 at 9:55:05 AM UTC-5, Whit Turner wrote:

Fun "project" if only conceptual for now. How about adding a small speaker to simulate the sounds an RK05 makes - the spin up noises, the squeaking of the positioner, even a head crash (just kidding). It could be connected to the Pi's audio out jack and wav files played during different RK05 activities.

Whit

Plus a small electronic servo to simulate the vibration of seeks - synchronized to the sound effects.    The lights and sounds are nice, but the shaking always told me that my PDP11 was really "working".

Jerry

[Peter Willard]

I think i still have the door lock solenoid.  I should record it actuating.

[Johnny Billquist]

It's not just the solenoid that is making the noise. It's all the
mechanical bits around it as well. Pretty large metallic clunk when it
locks the door.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/6e718ab6-be78-439b-b68d-6e9dbb239eeb%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/6e718ab6-be78-439b-b68d-6e9dbb239eeb%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

[Jerry Weiss]

I was thinking of using an old style door chime common in the states.   

Use the "front-door " solenoid to driven from the seek commands to replicate the motion and vibration of the voice coil positioner.  

Then perhaps the 'back-door' section for the other physical effects.

Jerry 

[Neil Higgins]

Are you still there, Henk, or have we lost you? :-)

[Henk Gooijen]

Hi Johnny,

that is a good idea, but DIP switches for "daily use" ... they were not designed for that. However, as you say, the RK05 also comes with a rotary BCD switch on

the front panel, left of the WT PROT and LOAD/RUN switch. The RK05 I have seen with that BCD switch was "ugly", because the BCD thumb switch color was beige! But that is a matter of taste :)   I will search for a small (scaled :) ) black BCD switch to add to the panel. Then the BCD switch represents the drive number, and the big number at the right side can be removed. Still, kind of a pity, because that "looks" so nice (IMHO).

 

Having more "drives" will be a bit more work in SIMH, but can be done. However, with one front panel, only ONE RK05 drive (physically simulated) can be present. All other RK05 attached drives will be simulation only. Basically, the file name specified on the ATTACH command must be correct (full path to USB stick, not just a file name).

I wonder whether it is needed to be able to specify which RK05 drive in the SIMH configuration has a "physical simulated" front panel. We'll see when I get working on the SIMH "hook-ups".

 

Making the spin up/down delay configurable (down to 0) was my intention :)

Indeed, for example toggling LOAD/RUN at a bad moment in time will cause issues ... but do you remember if it was possible on a real RK05 to toggle RUN to LOAD while a WT or RD cycle was in progress?  I mean, if the operator, by accident, toggled to LOAD while there is disk access activity, was the drive logic clever enough to block the LOAD action until the access was completed?  I never tried that on my real RK05 drives.

 

Agreed that the RK05 is a small drive for an 11/70, but (IMHO) the RK05 is one of the most appealing disk drive to look at. But RP drives (with glass top "door") are also great to watch, because you can *see* the spinning disk. I have three RP03 drives (glass top door), but it will be a long time before they will spin up the first time here with a pack loaded ...

The RL01/02 drives have 2 or 4 times the capacity of the RK05, but they miss the "sexy looks" of the RK05. Although RP or RM disk drives could be done, they will take up more space on your desk. The idea of the RK05 is that you can build a "mini rack" on your desk :)  A "mini line" would also look cool!

 

Although I guess you would run RSX or RSTS on the 11/70, you can also run RT11 on it. Don't know whether DIGITAL mentioned that as an OS option for the 11/70, but you can (I did it).

Greetz,
Henk

[Henk Gooijen]

Hi Paul,

a rotary encoder will probably need some processing, and a small display to show what the drive number is. Both (rotary knob and display) are *NOT* features of a "real RK05" (as you know)! However, the BCD thumbwheel switch that Johnny mentions *IS* a real RK05 feature, I have seen it in real life :)

 

To be correct, the thumbwheel switch should have numbers 0 thru 7. The RK11 controller could at max select 8 drives (numbered 0 to 7). I know that BCD thumbwheel switches exist with 0-7, but I am not sure I can find one (that will also fit  in the panel in proportions and does not cost a small fortune). So, it will probably be a thumbwheel switch 0-9. Not sure how SIMH can cope with 8 and 9 ... maybe the thumbwheel switch has configurable stops.

Greetz,

Henk

[Henk Gooijen]

Hi Peter,

the RFID option would be possible, but "back then" it was up to the operator to *read*  the label on the disk pack and mount the correct pack in the drive.

So, I will simulate that (easier :)  ).

Big tape robots use a similar approach. They have a camera to read the bar code on the tape cartridge to check that the correct tape cartridge is grabbed.

Greetz,

Henk

[Henk Gooijen]

Hi Whit, Jerry,

yeah, adding sounds would be nice. For starters the fans of the 11/70 ... 5 fans on the top side of the BA11-F box and 4 fans at the bottom side of the card cage. Then one or two big fans in the top of the cabinet ... I guess the need for a "silence option" quickly will be asked for :)

But adding "RK05 sounds" is possible, why not?  Perhaps something for later!

 

And as Johnny says, the "clunk" of the RK05 door (un)locking cannot be overheard!

Greetz,

Henk

[Henk Gooijen]

I think that the sound of just the solenoid is not how it sounds when it is in the RK05 actually (un)locking the front door ...
I do have several RK05 units, and just powering is enough, because one or two seconds after power is applied the solenoid is activated (to unlock the door).
Adding sound (like the solenoid) would be fun though ...

Greetz,
Henk

[Henk Gooijen]

I would have to add a second account to post replies in the evening (it's now morning and I am at work sipping my first coffee) ...

[Johnny Billquist]

Hi.

On 2018-07-17 07:35, Henk Gooijen wrote:
> Hi Johnny,
>
> that is a good idea, but DIP switches for "daily use" ... they were not
> designed for that. However, as you say, the RK05 also comes with a
> rotary BCD switch on

Yes. But those are two separate things and concepts here... My
suggestion for the dip-switch or other selector was for the disk pack
itself, to select which content to present.

> the front panel, left of the WT PROT and LOAD/RUN switch. The RK05 I
> have seen with that BCD switch was "ugly", because the BCD thumb switch
> color was beige! But that is a matter of taste :)   I will search for a
> small (scaled :) ) black BCD switch to add to the panel. Then the BCD
> switch represents the drive number, and the big number at the right side
> can be removed. Still, kind of a pity, because that "looks" so nice (IMHO).

My RK05 with the unit wheel is black. Looks nice, except that the
thumbwheel and number indicator is sortof small compared to the whole
drive. So it does feel a bit out of place.
I only have one of those, though. For the rest of them, I have to go and
change the unit number on the card in the card cage.
The sticker on the real drives are just a sticker, as you noted. If
wanted, you can of course keep those around anyway.

> Having more "drives" will be a bit more work in SIMH, but can be done.
> However, with one front panel, only ONE RK05 drive (physically
> simulated) can be present. All other RK05 attached drives will be
> simulation only. Basically, the file name specified on the ATTACH
> command must be correct (full path to USB stick, not just a file name).

Right.
But I wonder if maybe you misunderstood me.
I'm not suggesting that you'd have one "physical" drive appear as
several drives inside simh. I just suggested a way for you to make more
use of that large usb stick than just have one RK05 image on it, by
having a selector on the "pack", to choose which image on the USB stick
to make available to simh, when mounted in the drive.

> I wonder whether it is needed to be able to specify which RK05 drive in
> the SIMH configuration has a "physical simulated" front panel. We'll see
> when I get working on the SIMH "hook-ups".

There are many ways of doing all kind of stuff.

> Indeed, for example toggling LOAD/RUN at a bad moment in time will cause
> issues ... but do you remember if it was possible on a real RK05 to
> toggle RUN to LOAD while a WT or RD cycle was in progress?  I mean, if
> the operator, by accident, toggled to LOAD while there is disk access
> activity, was the drive logic clever enough to block the LOAD action
> until the access was completed?  I never tried that on my real RK05 drives.

I should check the documentation, but my recollection is that the
current operation is completed before the heads are retracted.

But my comment was more along the lines of toggling the LOAD/RUN to spin
the disk up, and then toggle the LOAD/RUN again before the disk even
came online. In which case, it never should come online, but instead
unlock the door again, once the disk have stopped.

> Agreed that the RK05 is a small drive for an 11/70, but (IMHO) the RK05
> is one of the most appealing disk drive to look at. But RP drives (with
> glass top "door") are also great to watch, because you can *see* the
> spinning disk. I have three RP03 drives (glass top door), but it will be
> a long time before they will spin up the first time here with a pack
> loaded ...

RP03 - That is a nice looking, proper disk. :-)
Then you have the RP11 controller, which is another cabinet with
blinking lamps as well.

> The RL01/02 drives have 2 or 4 times the capacity of the RK05, but they
> miss the "sexy looks" of the RK05. Although RP or RM disk drives could
> be done, they will take up more space on your desk. The idea of the RK05
> is that you can build a "mini rack" on your desk :)  A "mini line" would
> also look cool!

Yes. There could be some fun things here. However, things will be in
weird scales, as the PiDP-11/70 is rather large, actually.

> Although I guess you would run RSX or RSTS on the 11/70, you can also
> run RT11 on it. Don't know whether DIGITAL mentioned that as an OS
> option for the 11/70, but you can (I did it).

I know you can. But in general yes, DEC did not suggest running RT-11 on
the 11/70.

Johnny

> > an email to pidp-11+u...@googlegroups.com <javascript:>
> > <mailto:pidp-11+u...@googlegroups.com <javascript:>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/pidp-11/429dbdae-713c-4375-83a4-aeb49a3841a0%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/429dbdae-713c-4375-83a4-aeb49a3841a0%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/pidp-11/429dbdae-713c-4375-83a4-aeb49a3841a0%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/429dbdae-713c-4375-83a4-aeb49a3841a0%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip

> email: b...@softjar.se <javascript:>             ||  Reading murder

> books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/e8e35d23-103d-4b52-bf9b-9ef3173678f1%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/e8e35d23-103d-4b52-bf9b-9ef3173678f1%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Henk Gooijen]

Ahh, yes - some misunderstandings I guess :)
On the real RK05 drive, the thumbwheel sets the drive number. This is a field upgrade. On real RK05 drives that do not have the thumbwheel on the front panel you had to change a jumper on one of the modules in the card cage at the rear side at the right to change the drive number (and glue the appropriate number label on the front).

For the simulated RK05 drive, the thumbwheel selects/sets the "loaded pack"!
This idea "came to life", because the storage capacity of a(ny) USB stick is magnitudes larger than the real RK05 disk cartridge, and it is a waste of storage capacity. Further, the "cute idea" was to 3D print a scaled model of the disk cartridge and mount the USB stick in it (at the location where the real cartridge opens for heads access).
The thumbwheel decreases the number of times that you have to swap a cartridge, but it also decreases the authenticity of how it was done "back then".

My initial thought for the thumbwheel was indeed its original usage: select the drive number. Then the front panel can be "generic", because the drive number no longer is engraved on the front plate. The engraved drive number could also be avoided by the original solution: a glue-on label.

However, if the thumbwheel switch is going to be used to select a "cartridge" (an other file on the USB stick), you are (in real RK05 actions) doing a cartridge swap. Thus, changing the number on the thumbwheel implies pushing the LOAD/RUN button to "LOAD", unlocking the front door, opening the door, removing the disk cartridge, inserting an other disk cartridge, closing the front door, and pushing the LOAD/RUN button to "RUN".
With a physical (USB) cartridge you have to do those actions yourself. If the thumbwheel is implemented the software needs to know this and execute a DETACH of the currently opened file (RK05 disk container) and close that file and then execute an ATTACH to open the new file. The filename is a fixed name with a number that matches the thumbwheel number. To get a bit closer to "reality" you could activate/deactivate the front door solenoid and change that state of the indicator lamps (RDY off, LOAD on, etc.) momentarily between the DETACH and ATTACH commands.

For clarity, the "physical" RK05 drive is represented in SIMH as *one* RK05 drive. If you have *one* "physical" drive and its assigned drive number is "0" all disk commands would reference "DK0:". After changing the number on the thumbwheel switch the command would still use "DK0:" but the contents are different.

So, the proposal is probably
- implement the thumbwheel switch to select a specific "disk container" from the "pack"
- get some glue-on (scaled) labels to show the drive number

Observation 1. You *do not* have to use the thumbwheel, just swap the cartridge :)
Observation 2. Input pins are needed so that the drive number can be read! (running out of pins ...)
The drive number can be set using jumpers.

Again, choices pops up ...
the MCP23017 has 16 I/O pins. 8 outputs for LEDs, 1 output for solenoid, 2 inputs for panel switches.
That is already 11 I/O, 5 remaining. A 10-position BCD-coded thumbwheel switch "costs" 4 inputs, thus only 1 input is left to identify the drive number (can be "0" or "1").
One output is used to drive the PWR LED. That can be done hard-wired (power on => PWR LED on). Now we can identify 4 RK05 drives. I assume that nobody would want more than 4 "physical" drives (and most likely not more than 2). If more than 4 "physical" drives are wanted, one input of the thumbwheel switch could be used (rendering position "8" and "9" identitcal to "0" and "1").
Conclusion: PWR LED driven directly and 2 inputs available to code the drive number (0, 1, 2, 3).

> But my comment was more along the lines of toggling the LOAD/RUN to spin the disk up, and then toggle
> the LOAD/RUN again before the disk even came online. In which case, it never should come online, but
> instead unlock the door again, once the disk have stopped.

Correct. My intention is indeed to simulate the behavior to the best of my knowledge. To make things simple (or at least controllable) I was thinking of implementing a state machine.

> RP03 - That is a nice looking, proper disk. :-) Then you have the RP11 controller, which is another
> cabinet with blinking lamps as well.

Correct again :)  but "proper" disk?  The capacity is just 40 MB per disk cartridge (which has 10 platters IIRC)! Indeed, the RP11 controller has a nice panel with 144 lamps (but I don't know whether all 144 are actually used, the lamp panel was sort-of generic and used for several controllers (DX11, RK11-C, ...).
So, to implement a scaled line of RP03 (or other RP drives) you would need one "rack" for the PiDP-11/70, an other "rack" for the disk controller (and lots of  outputs to drive many tiny LEDs), and 1 or more "smaller" cabs for each disk drive ... better to forget this idea ;)

greetz,
Henk

[Johnny Billquist]

Still misunderstanding. :-)

My idea was actually to put a dip switch or selector on the disk pack,
not the drive.
That way, you can only change what volume the disk pack should appear as
when the pack is out of the drive. No way to change it on the fly.
Not to mention that the change can only happen when you press the RUN
button, as that is when the attach happens.

You can, of course, also place a thumbwheel switch on the drive, as the
real thing. However, this becomes much more complicated, as you then
need to attach the drive to different devices, and if changed while the
drive is running, it needs to change right away. So that would require
on the fly detach/attach while the drive is running, and possibly in
use. A very confusing situation, which potentially might not be easy to
implement well in simh.

Yes, this will require some more electronics. But it would, I think, be
a nice solution from most perspectives.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/d44faa75-8e5d-445b-83a7-ad4e23708c71%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/d44faa75-8e5d-445b-83a7-ad4e23708c71%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Henk Gooijen]

Ahhh ... now I see the light (I hope), but also problems!
The DIP switch or whatever mechanism to signal which file to use of the many files on the USB stick must be somehow connected from the removable cartridge to the drive construction (as is for the USB connection) ... mechanically challenging and it must be a 100% reliable connection.
If I understand correctly, this "DIP switch" merely reduces the number of physical disk cartridges.
For "operator handling" it makes no difference, except that instead of removing one cartridge and inserting *another* cartridge, it becomes removing the cartridge, flip switches/jumpers on that cartridge, and then insert the *same* cartridge.

With this new insight, I would propose to forget the thumbwheel switch on the front panel!
Reason 1: as Johnny says, thumbwheel on front panel related to cartridge screams for confusion (errors)
Reason 2: I need at least two I/O (inputs) and none is available, but within thumbwheel switch ...
Reason 3: using the thumbwheel as originally on the real drive (drive number) .. how often would you
                change the drive number?  So, setting the drive number can be done "internally" with jumpers.

Ad reason 2 : I need two inputs for
  - front door open/closed detection
  - cartridge physically in place (not via USB "drive" detection)

By using one cartridge for one RK05 container file, the need for more cartridges will increase ... that will bring down the cost for one :)

[Paul Birkel]

Go old-school and use a DE9 for all signals :->.

 

From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Henk Gooijen
Sent: Wednesday, July 18, 2018 5:12 AM
To: [PiDP-11]
Subject: [PiDP-11] Re: Physical simulation of the RK05 disk drive

 

Ahhh ... now I see the light (I hope), but also problems!
The DIP switch or whatever mechanism to signal which file to use of the many files on the USB stick must be somehow connected from the removable cartridge to the drive construction (as is for the USB connection) ... mechanically challenging and it must be a 100% reliable connection.

-----

Go old-school and use a DE9 for all signals between the “cartridge” (male) and the “drive” (female).  Think of it as engaging the head-load mechanism :->.

-----

[Henk Gooijen]

A DE9 connector certainly makes sense, for several reasons!

Disadvantage
- more connection pins => more force needed to insert / remove the cartridge
  (thus the physical attachment of the DE9 to the cartridge must be strong)

Advantages
- jumpers to select a specific container file *on* the cartridge is possible
- USB stick can be anywhere "inside" the cartridge, so USB stick shape does not matter
  (a disadvantage is that you need a USB socket -- wires -- DE9 connector)
- one pin on the DE9 can be used for "cartridge physically mounted" detection

Pin assignments for the DE9: 4 (USB), 1 (detection) , 4 (file number)

[Paul Birkel]

And for verisimilitude (aka “more fun”) you could label the “drive” as an RK05F (“fixed”) and screw the DE9 in permanently while disabling any possibility of opening the door to remove the cartridge :->.  Double the disk space!

 

From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Henk Gooijen
Sent: Wednesday, July 18, 2018 5:51 AM
To: [PiDP-11]
Subject: [PiDP-11] Re: Physical simulation of the RK05 disk drive

 

A DE9 connector certainly makes sense, for several reasons!

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/df4a149c-d7c4-4424-ad10-59432cd43754%40googlegroups.com.

[Henk Gooijen]

Correct, the available storage space doubles if the drive is an RK05f.
But the fun is less, because the door is gone (it is a fixed mounted black metal plate).
And the drive number becomes "0/1" (or "2/3", "4/5", "6/7").
For SIMH the RK05f "looks" as two RK05 (or RK05j) drives, and are accessed that way, "DK0:" and "DK1:") -- if I am not mistaken.
So, the storage space *per drive* remains the same!

[Johnny Billquist]

The appearance as two drives is not simh related, but how the real hardware presented itself as well.

The purpose behind having a selector on the pack would be both to reduce the number of packs needed, but also to make use of more of the capacity of the USB stick.

Yes, fewer packs mean more expensive packs. But one pack is probably going to be cheaper that 16 packs anyway.

Johnny

Henk Gooijen <henk.g...@boschrexroth.nl> skrev: (18 juli 2018 14:46:26 CEST)

--
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

[Mike Ross]

On Monday, July 16, 2018 at 9:17:43 PM UTC+12, Neil Higgins wrote:

RK05s were “the bees knees” for PDP-11s at the dawn of my memory. They looked sexy too. RL01s and RL02s came later. 

I would favour the RP11. Now ok, that's partly because I have one - but hey, we wouldn't all be here if we weren't hooked on blinkenlights! - 
 

Didn't the very earliest versions of the RK11 controller have blinkenlights? At least as an option? That would be worth doing too...

http://gunkies.org/wiki/RK11_disk_controller#Early_RK11_version

Mike

 

[Neil Higgins]

Swooooonn ... I’m in lurve! I have never seen a disk drive contoller like THAT before.

[Jerry Weiss]

On 7/18/18 7:46 AM, Henk Gooijen wrote:

Correct, the available storage space doubles if the drive is an RK05f.
But the fun is less, because the door is gone (it is a fixed mounted black metal plate).

Most of the fun was often restored with a minor operation.  Many of the labs in our college labs did this.   We would only use packs on the drive that formatted them.
No loading mechanism to help either, so it took a bit of skill.   No failures that I recall, but having an exposed spinning pack would definitely be some sort of safety or US OHSA violation if done today.

Jerry

[Mike Ross]

Oh well, have a pic of my other RP controller - RP15, controls RP02 & RP03 for the pdp-15:

I have RP02 & RP03 disk drives as well - and a brand-new sealed-in-foil pack. What I don't have are the cables to hook the drive up to the controller :-(

Mike

[Neil Higgins]

I am reminded of the blinkenlights on the main memory banks of the KA-10 at The University of Queensland, when I was studying there. The Computer Centre had a “bad” (from DEC’s point of view) habit of buying non-DEC addons. I thnk we had Memorex(?) core and Ampex(?) tape drives. Anyway the two fridge-sized core units each had an array of orange (maybe neon, maybe incandescent) lights that was (probably) 36 wide and (maybe) 18 deep - the full width of the cabinet. They were mesmerising to watch, and I would stand in front of the glass doors of the computer centre like a kid in a lolly shop. What a nerd!

[Lee Scheel]

oh. the hours and hours I spent repairing an RP11 after a customer had backed a metal chair into the pins. That was one expensive per call bill - but the customer was an oil company so I guess they could afford it.

And yes, this would be a worthwhile blinkenlights project!

[Neil Higgins]

Maybe, all those years ago, I was looking at disk controllers, not memory banks (!) Did they also go on PDP-10s?

[Mike Ross]

Yes, the -10s did have RP10 disk controllers, with blinkenlights. They were also commonly used with IBM channel-attached disks, and the DEC controllers for those (DF10???) also had blinkenlights panels at the top of the rack. 

But Ampex certainly did make 3rd party pdp-10 memory boxes, and they did have blinkenlights. I have a photo of a stripped-out Ampex pdp-10 memory box somewhere; will try to track it down and job your memory.

[Henk Gooijen]

Nice picture Mike.
Reminds me to take a few pictures of the RP11 that I have.

Yes, the common controller for the RK05 is the RK11-D, which consist of a dedicated backplane and 4 quad-sized modules.
The controller before the RK11-D was the RK11-C, which also had a dedicated backplane but a lot of small FlipChip modules,
and of course a blinkenlight panel on which you could see the track, status, etc.
That blinkenlight panel is just a matter of driving a lot of lamps (LEDs), but first it must be checked that all that information is available in SIMH.
If it is, it is just a panel that requires a *lot* of outputs ...

[Nigel Johnson]

We shipped an RP11 to a mine in Northern Ontario, fell off the truck and a post went through the backplane. That one was not repairable!

[Henk Gooijen]

Based on memories, I have drawn a state transition diagram (well, sort of). Some details are not in it, but it shows the behavior. In plan to write the software based on this STD. If changes are needed, I will first update the STD, and then the C code ...

[Johnny Billquist]

Urg. Lots of confusion and missing states and transitions.
First of all, any reason why you are using such unorthodox symbols?
Commonly, you have diamond shapes for decision steps.

Second. It's kindof unclear when state transitions happens. Are they
edge triggered, or just levels?
For example, starting at the IDLE stage, when you press the WRITE PROT,
I would assume it's edge detected. Otherwise, it would be spinning,
toggling the write protect state the whole time the button is pressed.
However, what if you press the RUN button with the door open, and then
close the door? If the RUN button is edge detected, it means you'll be
stuck in the idle state with the door closed and the run button
depressed. What if you then release the RUN button?

And if you have a spin down time configured, and you start the loading.
The spin down delay only happens if you release the RUN button while the
disk is spinning up, and never at any other situation.

Head on cylinder is not related to track 0. It's an indication that the
heads are on the cylinder addressed. Any cylinder. So it's a light that
goes out when the heads are seeking, and goes on again when seek is
complete. So in normal operation, it will be flickering when the disk is
used, and a steady on when the disk is idle, no matter where the heads are.

Why don't you split different operations up in smaller, more manageable
pieces? The write protect, for example. That should be its own state
machine, that simply just always looks for the switch, and sets the
status bit accordingly. The LED should just be a reflection of the
status bit. Oh, and by the way, toggling the write protect switch should
clear the error indicator. Also, the error is cleared when the disk goes
through a RUN/LOAD sequence. Not that the write protect can also be
controlled by software.

Also, if no USB stick is mounted, you should detect that as soon as the
door is closed, but no later than when the RUN button is engaged. It
should not wait until the spin up delay have passed.
Basically, I would consider a pack without an USB to be no different
than no pack at all.

And why do you have a mount delay in addition to the spin delay? Not
sure what the point is there.

More points: If a write is attempted when the disk is write protected,
the fault indicator should go on.

More LEDs: There is a PWR led, which should always be on when there is
power. A RDY led, which is on when the disk have spun up, no matter what
else is happening.

I sortof gave up after a while to try and figure out all different
undefined or funny states you might get into with this diagram. Sorry.

Anyway, I assumed you wanted some feedback, since you posted it. If not,
then sorry for this whole mail, and I'll be quiet.

Johnny

[Henk Gooijen]

Am Mittwoch, 1. August 2018 14:34:01 UTC+2 schrieb Johnny Billquist:

On 2018-08-01 12:53, Henk Gooijen wrote:
> Based on memories, I have drawn a state transition diagram (well, sort
> of). Some details are not in it, but it shows the behavior. In plan to
> write the software based on this STD. If changes are needed, I will
> first update the STD, and then the C code ...

... snip lots of good comments !!

I sortof gave up after a while to try and figure out all different
undefined or funny states you might get into with this diagram. Sorry.

Anyway, I assumed you wanted some feedback, since you posted it. If not,
then sorry for this whole mail, and I'll be quiet.

   Johnny
--

Yes, I wanted feedback, and you gave very useful feedback, so thank you for that Johnny!
The drawing is not a flow diagram (then the decision would have been diamond shaped), but the drawing is "loosely" an STD.
In an STD a decision is a "transitory" state. I abused that a little to keep the drawing smaller, but for the STD actually incorrect.
The drawing helps in implementing a state machine in software and it helps to keep overview.

I realize that this way of working has its drawbacks, but you proved that it helps to get useful comments :)
But I agree that a lot of things are hidden. For example, the PWR LED is indeed always on, because it will be directly connected to the power supply :)
Your comments about edge or level triggered is clear to me, but you are correct that it does not show clearly in the drawing. Thinking how I can clarify that.
I used a few delays simply because I was thinking that it might take time (and thus the software must wait) before an action has finished. If it turns out that the action completes immediately, the delay can be neglected and will be removed.
Once again, thanks for your input Johnny ... back to the drawing table :)

[Rob Doyle]

I'll add a additional question -

Do you intend to simulate disk rotational latency and head motion?

And do you care if the diagnostics pass?

Obvious a USB device has zero rotational latency and no head motion delays.

I've implemented an RP06 disk simulator in an FPGA. Some of the KS10
diagnostics require a semi-accurate disk timing simulation to succeed.

The KS10 FPGA has two modes: "fast but sloppy" which has no delays, and
"slow but accurate" which is required to pass the diagnostic tests.

SIMH already fails many of the diagnostics and maybe you don't care.

Rob.

[Henk Gooijen]

Am Donnerstag, 2. August 2018 03:03:20 UTC+2 schrieb Rob Doyle:

I'll add a additional question -

Do you intend to simulate disk rotational latency and head motion?
And do you care if the diagnostics pass?
Obvious a USB device has zero rotational latency and no head motion delays.

I've implemented an RP06 disk simulator in an FPGA.  Some of the KS10
diagnostics require a semi-accurate disk timing simulation to succeed.
The KS10 FPGA has two modes: "fast but sloppy" which has no delays, and
"slow but accurate" which is required to pass the diagnostic tests.

SIMH already fails many of the diagnostics and maybe you don't care.

Rob.

 Hi Rob,
No, I have no intentions to even try to get diagnostics passed.
"fast but sloppy" LOL
I reviewed Johnny's remarks yesterday, and started reworking the STD.
Spending more time on it plus the suggestions of Johnny brought back
some details of how to implement an STD (did that 25 years ago for the
last time). Now I have separate controllers for spin-up, spin-down, and
for the switches and door sensor. I am still happy that I did not start
writing code but instead started drawing an STD.

BTW, I did 3 attempts to get your PDP8 VHDL on an FPGA, but every
time the project gets back in the (too long) queue "to do's" :(

[Henk Gooijen]

Using Johnny's constructive comments I now have something "working". The idea to use sub-controllers for for example spin-up and spin-down made the design a lot simpler.
The project consists of 3 major parts.
- the electronics (easy, sort-of done)
- the software (more work)
- mechanical construction (difficult, especially taking into account to create a kit)

On the software side, I have added a new command "PHYSICAL" (abbreviated "p") to SIMH. This command only accepts "RK", "RK0" or "RK1" as single argument, and must be issued *before* the ATTACH command for RK0 or RK1. This will cause the pdp11_rk.c code to call the ONCYL, WT, RD, and WTPROT LED on/off routines. I am working on that (studying the pdp11_rk.c code).
I also need to implement the ATTACH and DETACH in the "physical disk driver".

Mechanically it is a WIP.
The front panel is more or less designed. On the rear side are threaded holes to mount "stuff" onto the rear side of the front panel (without seeing the screws at the front of course). to be able to mount those screws, the front panel needs to have a certain thickness, probably 5 mm). I am working on the design of the door and the door lock mechanism. I am searching for a company that can bend plexiglass in a sort-of "stretched S" shape with good reproducibility. The door lock mechanism uses a solenoid which pulls (or pushes) a core pin. Some mechanism must change this movement to a locking pin. If I remember correctly (I really should take a look at a real RK05), the lock mechanism is above the switches, below the door. That is mechanically not so strong as the locking pin will be "on level" with the pivot point of the door. I am hoping to get a locking pin mechanism on the left or right side of the door, but there is not much room (30 mm). Above the door is difficult as the space there is just 10 mm. -- to be decided/designed ...

I found a local guy who has a 3D printer. I have a few plastic light caps from a real RK05 drive, so he can reproduce the red and milky white front caps for the indicators. I have ordered "warm-white" LEDs hoping they will be an OK replacement for bulbs. I know that later RK05 models did not use bulbs but "pale greenish" LEDs instead, but I don't like those. I have also ordered a few red LEDs with different wave lengths to choose the "deepest red" LED :)
The local guy can handle up to 40 cm in his 3D printer, so printing an RK05 cartridge is also possible ...
Nothing done on that (yet).

Attached are the STDs (not flowcharts) that helped to develop the code and the code itself. Maybe you laugh at the code, maybe not. I am always willing to learn, and sharing might help me. It is all in a preliminary state, file names will probably change, code will be cleaned up (test code removed) etc.
Anyway, any comment is welcome!

[andy]

Very exciting progress Henk... 

[Henk Gooijen]

Am Montag, 27. August 2018 17:20:17 UTC+2 schrieb andy:

Very exciting progress Henk...

Thanks Andy.
I have been reading a little in EK-RK05-OP-001_1976 ... when the drive is cycled through a run/load sequence, the WT_PROT should go off. So, I updated the "startup-conditions" STD and attached it.
I also had a look at pdp11_rk.c and have the locations where the WR and RD lights on/off calls should go. I tried it without the PiDP-11/70 (using a virtual machine with Ubuntu in it and SIMH), and I get sequences of RD and WR. The good thing is that they go "on" *and* "off" (visible by using printf's). However, till now I did not succeed seeing ONCYL going on and off, although the locations are quite clearly visible ("if func == RKCS_SEEK" ...).
I will clean up pdp11_rk.c a little and post here. Maybe another smart guy points me to my mistake(s) :)

[Henk Gooijen]

and here is the (slightly) modified pdp11_rk.c file. You can find my changes by searching for "printf".
This evening I will try again some actions while running the PDP-11 SIMH, hoping to see "ONCYL off" and "ONCYL on" ...

[Henk Gooijen]

On small update.
The guy (a colleague) of mine understood my drawing and printed one indicator cap.
It is not perfect, but can be improved. Of course this is not the correct filament, but just a test how the "thing" would come out.
The real RK05 indicator cap is some 13 mm square, and at 60% that would result in a size of 7.6 mm. As that was quite small, the printed example is 8 mm square. The "tube" at the rear side can be hot-glue mounted onto the front panel and a 3 mm LED will fit snug. If all goes well I will get the "warm-white" LEDs today ...

[Henk Gooijen]

It has been quiet on this topic, but that does not mean that nothing was done in the meantime ...

Since yesterday, I have on my desk a metal RK05 front panel with same dimensions as the PiDP-11/70.

Last week I received a package from Reichelt with the electronic parts to interface the switches and LEDs of the front panel to the Raspberry Pi using the I2C connection.

And today the small PCB arrived that I designed.  Ohh, and 2 weeks ago, the ordered L-shape aluminum profiles and aluminum plates were delivered to build the box. Forgot a few pieces, but not critical.

Sounds like almost done?  Well ..., no!

I have to drill mounting holes in the L-shape aluminum profiles and plates. Using M3 screws these profiles are mounted on the rear side of the front panel, and the plates are attached to these profiles.

Further, I still have to work on the front door. I have ideas, but at this moment I am still searching for a method to bend the "smoke glass" plexiglas in sort of a flat "S" shape, just like the real RK05 drive door has. Through this "glass" you can see the loaded cartridge, and that is what I want too!

The front door locking mechanism (using a solenoid) is also a small challenge, because there is not much space. But I am confident this will also be solved.

I also still have to do some thinking about the guidance and support for the disk cartridge. The cartridge will have a USB stick inside and 3 jumpers to select which of the 7 disk containers is the one that will be loaded (attached to SimH). The connection from the cartridge to the "solid world" (the disk drive) uses two magnetically held USB connectors.

I will be writing a manual as I make progress and post pictures.

[andy]

glad to hear you're making excellent progress!  ANy kind of photo / descriptive log (nothing fancy) would be great. I would love to mimic your steps and catch up with you :-)

cheers

Andy

[Henk Gooijen]

Op vrijdag 14 december 2018 17:09:12 UTC+1 schreef andy:

glad to hear you're making excellent progress!  ANy kind of photo / descriptive log (nothing fancy) would be great. I would love to mimic your steps and catch up with you :-)

cheers

Andy

Be careful what you wish ... this is the Season :)

Yesterday (Friday) afternoon worked for some 5 hours and today also 5 hours (!) on the aluminum L profiles and plates.

This was a "look 3 times, take measurements", check, mark and drill holes (accurately) - one profile or plate at a time. 

I realize that this is probably an issue for a kit ... but I am not planning to drill a single kit to the point that it is a "Mecano" assemble it by mounting with screws and nuts ...

To do:

- The PCB is not yet soldered, the switches (with white caps from Oscar) are not yet painted grey.

- Two door solenoids need to be ordered, but I have a working mechanical design (finally) on paper.

- The lens for FAULT indicator (red) must be made - transparent red filament is ordered. The 7 other lenses are done.

- Slide "frame" for the disk cartridge (plan on using kitchen drawer grips).

- Front door construction (still working on) -- I think I have a solution (DIY) to bend the "smoke" plexiglass.

But here are a few pictures to get an idea where I stand (the vertical side wall for the "cartridge" bay are also finished, but not mounted).

Will post a few new pictures soon!

[andy]

Looks fantastic Henk...

[andy]

Henk - I know I am going to regret asking this... <sigh... another project>  but if I wanted to get this panel rendered in 2mm aluminium any tips you can share?

cheers!

Andy 

 

[Henk Gooijen]

Thanks Andy.

I think that a panel thickness of 2 mm is too thin. Remember, there are screws mounted on the rear side of the front panel, and you do not want to see them at the front.

I chose 3 mm thickness so that the M3 screws can be mounted (threaded) 2.25 mm into the panel. Originally I wanted 4 mm thickness, but that would have increased the cost considerably, because *every* cut hole gets more expensive as more material has to be cut. So I kept the thickness at 3 mm, but from Front Panel Express you can get your front panels up to 10 mm thick ...

When you design the front panel, you can place them fairly accurate, but for 100% perfect you need to check every coordinate and correct by 0.0x mm. That is just spending some extra time, but all that matters here is the end product.

My wife "allowed" me some extra hobby time, so the PCB is soldered (but not yet tested) ...

[Stephen Casner]

On Sunday, December 16, 2018 at 6:23:14 AM UTC-8, Henk Gooijen wrote:

I think that a panel thickness of 2 mm is too thin. Remember, there are screws mounted on the rear side of the front panel, and you do not want to see them at the front.

I chose 3 mm thickness so that the M3 screws can be mounted (threaded) 2.25 mm into the panel. Originally I wanted 4 mm thickness, but that would have increased the cost considerably, because *every* cut hole gets more expensive as more material has to be cut. So I kept the thickness at 3 mm, but from Front Panel Express you can get your front panels up to 10 mm thick ...

Rather than drilling and threading a shallow hole, which is difficult, would it be feasible to use a concealed-head self-clinching stud mounted to the panel?  These are spec'd for panels as thin as 1.6mm.

Steve

[Henk Gooijen]

Steve,

as far as I know, Front Panel Express only supports some forms of studs.
I agree, panel-mounted screws would have been nice, but this also works. You just need short screws (M3x4) but I have plenty of them :)

[Whit Turner]

Really fantastic work so far, Henk. I was thinking you could design a thicker backing panel with countersunk screws for the chassis then attach a thin "beauty" panel with the artwork on it to the backing panel.

Cheers

Whit 

[Henk Gooijen]

Thanks Whit.
My first thought was "Yes, do it that way to get a thicker front panel!"  Then brains cells started to work :)
You would need to cut all holes in the thin front panel and add the engraving plus white paint, *and* cut all holes in the thick backing aluminum plate.
Cutting of any hole adds to the total cost. And setup fees are per plate. Thus the end result would be two plates, almost double cost and you get an alignment "problem" to get the two plates perfectly on top of each other.
If a thicker front panel is needed, you just ask Schaeffer, and they will make a thicker front panel. It will cost more (10 to 20%) to make for two reasons. First, the thicker aluminum plate :) and second, every cut hole is costing slightly more (because more material has to be cut).
I am pretty sure that a thicker front panel (one plate) will be cheaper than two plates.

By mounting "L" aluminum profiles against the back of the front panel using 4 mm screws the top part of the front panel is strong (it is just a 12 mm aluminum "bar" across an opening of 250 mm) and from those "L" profiles you can mount anything, such as the front door, the outer box walls and the inner box (the "cartridge bay" side walls and floor).

[Henk Gooijen]

I spent a lot of the Season holidays on working on the RK05 front door.
Update.
The first attempt of the front door looked rather nice, so I was happy ... until I discovered that the construction that I made up had just one "little" flaw: it was not possible to insert or retrieve an RK05 disk cartridge!  Might be OK for an RK05f drive (fixed cartridge), but that takes away half the fun (swapping cartridges).
The new design works better, it is possible to swap cartridges when the front door is opened. The new design also supports "door opened" detection with a light sensor.
The door lock solenoid mechanism is also finished using 2 pieces of "U"-shaped aluminum and and small aluminum plate for the arm/lock pin.
The two white front panel switches that I got from Oscar are painted and mounted on the switch bracket. And the switch bracket fits perfectly on the front panel.
In two weeks time, I have an appointment with a company that can make a 3D scan of a real RK05 disk cartridge. When I have that 3D file, I can resize it and then 3D print that cartridge :)

Also checked several movies on YouTube "how to bend plexiglass". Subsequently I built a contraption using a Nickel Chromium wire as heater element. At 15 Volts and 7 Amps the wire glows orange hot. A folding mechanism enables me to bend plexiglass and empirically I have a fitting "smoke glass" window in the front door.
I will post a few pictures (have not made them yet); maybe tomorrow ...

[Henk Gooijen]

And here are a few pictures. Taken his evening, so lighting is not perfect.

I am still waiting for a red lens for the FAULT indicator. The transparent red filament (PET-G) is difficult to use. My collegue is still experimenting for a good result.

Also, the "smoke brown" plexiglass is too light to my liking. Looking for transparent smoke brown plexiglass which is a little darker. But a label on a loaded disk cartridge must be readable through the plexiglass.

[oscarv]

That is just gorgeous...

[Todd Goodman]

Very nice!!!

[andy]

Oh that is a site to behold!

[Mark Matlock]

Henk,

   That is technology and art! WOW!

Mark

[Henk Gooijen]

Not much progress to report, but still ...
3D printing with the red PET filament finally succeeded so the lenses are now all done.
Still waiting to go for a 3D scan of a real RK05 disk cartridge.

All metal is aluminum, so easy to work on.
However, I measured and drilled holes as I made progress building the construction ... I should have made notes!
Before I take the time and effort to make drawings with position of the holes I would like to know whether this makes sense.
It will take many hours for me (I am bad at mechanical drawings) and it will also take considerable time to write an "construction manual" which includes lots of photographs to show the details.
I understand that you cannot say "I want one" without knowing at least to some extend what the cost will be. My guess is it will be +/- 400 Euro The front panel itself is more than 50% of the total cost, but that also very much defines "the looks". Not included in this cost figure is the cost of the "disk cartridge", simply because I don't know that yet, and the plexiglass in the front (pita job). The 2 USB connectors ("magnetically locking") are neither included in this list. Hmmm, I think I should make a list so that nothing gets forgotten.
But before putting much more time in this project, It makes sense (to me) to know whether there is just one person interested or "a few more".
Thanks,
Henk

[Todd Goodman]

I'm definitely interested Henk.  It looks awesome!!!

Todd

Sent from BlueMail

[Oscar Vermeulen]

Me too!

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/20f2fe3d-accc-4c57-b378-4c3c88b0bb1f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Chuck McManis]

I would definitely get one of these if you made them available! It
adds a nice touch to the box!
--Chuck

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAJAwMc0W%3D3nkZhYE0W_xZsGCHVaWhHr%3DjH33_QCmu%2BJoeapgRQ%40mail.gmail.com.

[Mark Matlock]

Henk,

    I also would want one. It would look awesome next to the PiDP-11/70!

Thanks!

Mark

[andy]

Henk - fantastic work. Actually I don't want one... I *need* one :-)

cheers

Andy

[chrom...@gmail.com]

On Friday, 13 July 2018 12:36:01 UTC+3, Henk Gooijen wrote:

I am working on a "physical simulation" of the RK05 disk drive.

 

Solution #1.
If you mount a physical disk drive behind the front door, you can simulate the physical disk cartridge completely. A 3.5" floppy drive does not contain the capacity of the RK05 disk (~2.5 MB).

I might just have a solution to that little wrinkle for you.  It'll involve an extra little retrocomputing project, but I think it *is* possible to reliably squeeze 2560KB (or even more) onto a standard 3.5" HD floppy.  You just have to get creative, instead of using a bog-standard FDC as a crutch, and use a more efficient encoding.  The transition from FM to MFM doubled usable capacity on the same physical media by doubling the minimum symbol-bit spacing between flux transitions; going up another step to EFM (8-to-14 modulation, from the CDDA standard) should give us a 50% further increase for the same reason.  Encoding and decoding EFM is a little trickier than FM or MFM, but I think we can do it with a 12MHz 65816 (some RISC MCU might also work) and a little bit of front-end hardware between the embedded CPU and the drive.

A standard PC-type floppy drive spins at 300rpm and will accept flux transition pulses at up to 500kHz on any track.  It doesn't matter if they're out of phase with previous pulses, as long as the minimum spacing meets the spec of 2µs.  The minimum transition spacing in EFM is 3 symbol bits, so we need to clock those out at 1.5MHz.  We then need to measure the timing of received pulses to within 0.66µs for correct decoding.  It's common to use a 24MHz master oscillator with an FDC, so we can count multiples of 16 cycles from that, and use simple hardware to translate between raw pulses and delta-time counts to stuff into and out of a FIFO chip.  The 65816 can be arranged to block on an empty FIFO instead of polling in software, and with a bit of clever programming, we can walk it through a decoding state machine in about 20 cycles per received pulse, just about fast enough to keep up with the theoretical maximum 500kHz pulse train.

EFM then requires 16 symbol bits per encoded byte, after adding two "merging bits" to maintain the invariant of the encoding.  This is exactly the same number of "symbol bits" that FM and MFM both require, if you count their multiplexed clock.  Allowing for 1.5% variation in spindle speed, the raw capacity per track is then fractionally over 18KB - but for safety and to maintain an adequate leadout gap, let's call it 16KB.  EFM's sync word is also commendably easy to detect, and there are two "out of band" bytes which can be used as sector delimiters.

(More details on this idea: http://forum.6502.org/viewtopic.php?f=4&t=5445&start=0)

Examination of the RK05 specs reveals that, when used with a PDP-11, it has 203 cylinders, 2 heads, 12 sectors per track, 256 words per sector, 16 bits per word.  The product of all that is 2436KB - so that's our capacity goal.  Alternatively, we could see it as 12KB per cylinder, or 6KB per track.

The TEAC 3.5" drives I'm using as a design reference specify the ability to access 82 tracks on both sides of the disk.  At 16KB per track, that gives us 2624KB per disk.  At 15KB per track - which lets us put an even 5 RK05 tracks on one 3.5" cylinder - we still have 2460KB.  That's enough to do the job!  We should even have enough margin on each track to write each RK05 half-track as a distinct physical sector, and to implement a skew per cylinder to minimise sequential access latency.

The hard part will be building the 65816, firmware, and custom logic to interface to a drive.  After that it will be easy to accommodate multiple drives attached to the single controller.  I think it's even feasible to replicate the RK11-D's ability to seek on RK05 units that aren't presently being read or written, which will be important to minimise the performance deficit between a (removable, old) hard disk and a (modern?) floppy disk.  The RK05 spins 5 times as fast and seeks about 3 times as fast as the TEAC drives…

 - Jonathan Morton

[Randy]

I don't know the roots of your design, but would an IBM PS2 style 2.88MB 3.5" FDD work as opposed to the "standard" 1.44MB? 

[Jonathan Morton]

> On 5 Feb, 2019, at 3:43 am, 'Randy' via [PiDP-11] <pid...@googlegroups.com> wrote:
>
> I don't know the roots of your design, but would an IBM PS2 style 2.88MB 3.5" FDD work as opposed to the "standard" 1.44MB?

Such a thing existed, once upon a time, but I believe both drives and compatible disks are now very difficult to obtain - otherwise I'm sure Henk would have considered that as a natural solution. The coating was changed from cobalt to barium, and the magnetic orientation changed from longitudinal to vertical, so there's no way to convert an existing 1.44MB drive or disk to the 2.88MB format, even if most modern FDCs technically support the format.

By contrast, I think my 2.5MB format can be implemented using parts that are still being manufactured (or at least available in quantity on the second-hand market) and can be assembled by hand. In fact, I'm a little surprised that nobody thought to employ EFM as a natural extension of the FM to MFM evolution in a standard FDC.

There remains the question of how to interface it to the PiDP in such a way that it adequately emulates an RK11/RK05 combination. A glance at a bootstrap code indicates busy-waiting on a status flag while the disk works, so there has to be some insulation between the host CPU and the 65816 so as not to tie the latter up in interrupts. What options are preferred?

- Jonathan Morton

[Henk Gooijen]

Randy, Jonathan,
yes I had thought of using 3.5" floppy disks. In a very early (silly) design I wanted to use common floppy disks, but as you say, the capacity is not enough to simulate an RK05 disk cartridge. For a brief moment I was considering *two* floppy drives next to each other, each floppy disk representing one surface side of the RK05 disk. Yup, brief!
I had thought of 2.88 MB floppy drives, but they are not "common" nor cheap. Another drawback (of floppies in general) is the wear and all the mechanical stuff.
But the most important reason I stopped thinking about floppy disks is the appearance. I wanted to and still do build an RK05 drive scaled to same dimensions as Oscar's PiDP-11/70. And I wanted to go all the way, so exact front panel copy with similar switches and indicator lights, same door looks (with a door locking solenoid) and ... same looking disk cartridge!
With that last point I abandoned the idea of a floppy disk.
The plan now is making a 3D scan of a real cartridge, scale down to some 19 cm diameter and 3D print it. Inside will be a USB stick (smallest capacity available is perfect). Inserting the "disk" into the "drive" comes down to plugging a USB stick in its socket. To make that easy and have "low-force" insertion, I have chosen for a USB connection that uses pins with a spring and a magnetic-coupling housing.
People on this list came up with the idea to have several disk container files on one USB stick. That would keep the number of needed "RK05 disk cartridges" low. With a few jumpers inside the cartridge (but accessible of course when the "pack" is outside the "drive") you can select which container file is "presented". With this solution you can keep the number of cartridges low, but still have the "feeling" of swapping a cartridge (as would be done in real). You have to unmount the mounted container file, remove the cartridge from the drive, set the jumpers (or DIP switches) to another container file and then mount the cartridge again in the drive.
It is my intention to reproduce the operation handling of an RK05 as well. Of course it must work with SIMH, so a small addition is needed and a few calls must be inserted in pdp11_rk.c.
BTW, controlling the panel lights and reading the panel switches with the Pi is already working (will post a short movie, but I am not good at that).

[Henk Gooijen]

>  BTW, controlling the panel lights and reading the panel switches with the Pi is already working (will post a short movie, but I am not good at that).

Made a movie, but saying "I am not good at that" was an understatement ... it's even worse. My old camera with a whopping 16 *MB* flash card (...) was full before the "sequence" was finished. Iconverted the original .MOV file to an .mp4 (size reduction factor ~18).
"nanosleep()" is not as accurate as I thought ... for timing delays (spin up of the motor etc) it is fine, but for keying morse code it is not that good.
The first example in any programming language is "hello world", so I thought for a demo I do "hell RK05" in morse code :-)

[andy]

Henk rest assured there are far worse movies out there!

Regardless this is a beautiful piece of work.  I do need more blinking lights :-)