Al Kossow
Documentation Wizard
Brad Parker seems to be the last person working on something like that
http://www.heeltoe.com/retro/udisk/
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Interested in a Qbus MSCP to ATA/IDE/SD adapter?
- Thread starter cosam
- Start date
Brad Parker seems to be the last person working on something like that
http://www.heeltoe.com/retro/udisk/
marmotking
Experienced Member
Ya, I actually exchanged some emails with him. He said he's started moving forward on it again and I volunteered to test it with a VAX 750 which I'm in the process of getting fired up at this point. Last I heard he was testing it with an 11/44.
jfwRT11
New Member
Why not emulate an RK05? it is a much simpler interface; a few registers, address, count, direction. MSCP is a whole pile of messaging and protocols. Or any other non-mscp interface. True the MSCP interface supported devices larger than 65K blocks, but that is their only advantage.
Although I no longer have any DEC equipment, I am sympathetic to this problem.
IMO, MSCP would definitely be the way to go for both PDP-11 and MicroVAX. IIRC any size disk up to about 2TB can be supported by the protocol (as opposed to supporting RK's or RP's). Although with the smaller IDE disks drying up maybe the plan should be to go for USB 2.0. It is much faster than the QBUS and will be around for a long time. Unfortunately, the vintage DEC market is really small and engineering costs would have to be absorbed somehow, even if somebody was willing to write the firmware in their spare time.
Do you think it would be feasible to embed an ARM-based Linux system (for the USB stack) on a dual-height board and implement MSCP completely in software (e.g. an mscpd)? Or would there be an easier way?
I doubt the VAX ever was able to boot from an RK05. Not sure about RSX-11M-PLUS. So that really limits the utility of building a QBUS RK emulator. Whatever hardware development is done needs to be able to be shared across as much of the vintage DEC community as possible.
IMO, MSCP would definitely be the way to go for both PDP-11 and MicroVAX. IIRC any size disk up to about 2TB can be supported by the protocol (as opposed to supporting RK's or RP's). Although with the smaller IDE disks drying up maybe the plan should be to go for USB 2.0. It is much faster than the QBUS and will be around for a long time. Unfortunately, the vintage DEC market is really small and engineering costs would have to be absorbed somehow, even if somebody was willing to write the firmware in their spare time.
Do you think it would be feasible to embed an ARM-based Linux system (for the USB stack) on a dual-height board and implement MSCP completely in software (e.g. an mscpd)? Or would there be an easier way?
Al Kossow
Documentation Wizard
This assumes you are going to run software that supported MSCP, and have a computer with an MSCP bootstrap.
An RL02 would get you back into the mid-70's timeframe, but even that wouldn't let you bring up the original UNIX V7.
Depends on what you intend to do with the computer once it's running, of course. Early Unix, RT11, RSX or RSTS may
have to be left for simulators.
TiggerLAS
Experienced Member
I'm more of an idea man, so I can only contribute some "things to think about"
during the process, and potential enhancements (whether they are easy, or complex.)
Here they are -
Most DEC controllers only support up to 4 physical drives.
(RQDXn, UDA/KDA50's, etc.)
Some DEC operating systems are capped at (just under) 2GB per physical drive.
This is true of RSTS/E, though I'm not sure if this is true for VMS,
or any of the non-DEC operating systems.
In any event, control over emulated drive size will be needed, as well as
a setting for the number of drives per controller, as well as the starting LUN.
To simplify things, one could use a short table to specify unit numbers
and block sizes, and let the controller figure out the rest.
DU0, 400175 (RA60)
DU1, 237208 (RA80)
<blank>
DU3, 800 (RX50)
Lowest drive number would be your starting LUN.
In actual operation, the list would need to be validity-checked
before being committed to wherever configuration data is stored.
If you're going to do TMSCP by adding a second media port,
then make it so that the 2nd port can be MSCP or TMSCP.
You'll also need to be able to enable or disable the 2nd port,
in case you don't want the extra controller showing up.
What about Ready / Write Protect?
"Coolness factor" items, which should be considered -
-----------------------------------------------
As much as I hate using the "L" word, or even worse the "W" word,
I think you should start with Windows/Linux/DOS accessibility.
Not direct access, obviously, but with a small program
designed to load devices images onto the media, from
Simh, E11, or some other emulator.
The media would need a special area reserved for device information,
so that it knows what kind of volumes are stored on it.
This would eliminate any headaches involved with getting
operating systems onto the actual hardware.
Additionally, it could negate the need for a (controller based) user interface entirely.
-----------------------------------------------
Include a bootstrap at 17773000, which could
auto-boot DU0, or perhaps the VTServer stub.
-----------------------------------------------
Reserve some space on the CF/SD/USB media,
and ADD TU58 EMULATION to the device, so that
folks can have XXDP, or an RT11 distro onboard.
They could then use that for diagnostics,
or as an intermediate boot device, for systems
that don't have an MSCP bootstrap at their disposal.
-----------------------------------------------
And of course, the "beyond way cool factor" -
Approach the device from a very generic standpoint,
which could offer several of the more common emulations,
particularly for those with older operating systems to support.
DU/RL/RK/RM/RP for disks, MU/MS/TM/TS for tapes.
Providing multiple emulations on the same media
would be problematic at best, so each slot would be
limited to a single emulation.
A board with two media slots could be set for
MSCP emulation on slot 1, and RL11 emulation on slot 2.
I think this could be accomplished by making a set of routines
to handle the functions that are common to all disk/tape controllers,
and then have a "middle man" to perform the actual emulation,
by interacting with the other (common) routines.
Basically, you'd create a routine to handle all of the Q-Bus I/O,
including CSR, Vector, BIRQ, and data transfers, etc.
Then create a routine to handle all interaction
with the CF / SD / USB media, including drive sizing, etc.
Finally, create the various portions of emulation-specific code
that interacts with them, and provides the actual translations.
Store all controller / volume-specific information
in a reserved section of the CF/SD/USB media.
Upon controller initialization, this section is accessed,
providing the configuration information needed to proceed.
The controller will then load the appropriate emulation-specific code
to act as an intermediary between the QBus, and the media.
In actual use, the controller would query the media, which would respond with -
"Hey, I'm supposed to be an RL11, at 17774400, Vector 160, BIRQ 4, with
Unit 0 (RL01) Unit 1 (RL01) Unit 2 (RL02) Unit 3 (RL02) attached".
The controller would do the rest.
Not enough EEPROM space for the code for the various emulations?
No problem -- store the emulation-specific code in the reserved space
of the media, and load it at initialization instead, thereby cutting down
tremendously on the amount of EEPROM space needed.
Alternately, you could create just enough initialization code
to access the media in the first slot, and load the entire
operational code from the reserved space on the media.
Keep in mind that I know nothing about Q-Bus mechanics,
operating system drivers, device programming, etc.
Therefore, I do not know what kind of effort would be needed
to accomplish all of this. I do know, however, that it can be done
during the process, and potential enhancements (whether they are easy, or complex.)
Here they are -
Most DEC controllers only support up to 4 physical drives.
(RQDXn, UDA/KDA50's, etc.)
Some DEC operating systems are capped at (just under) 2GB per physical drive.
This is true of RSTS/E, though I'm not sure if this is true for VMS,
or any of the non-DEC operating systems.
In any event, control over emulated drive size will be needed, as well as
a setting for the number of drives per controller, as well as the starting LUN.
To simplify things, one could use a short table to specify unit numbers
and block sizes, and let the controller figure out the rest.
DU0, 400175 (RA60)
DU1, 237208 (RA80)
<blank>
DU3, 800 (RX50)
Lowest drive number would be your starting LUN.
In actual operation, the list would need to be validity-checked
before being committed to wherever configuration data is stored.
If you're going to do TMSCP by adding a second media port,
then make it so that the 2nd port can be MSCP or TMSCP.
You'll also need to be able to enable or disable the 2nd port,
in case you don't want the extra controller showing up.
What about Ready / Write Protect?
"Coolness factor" items, which should be considered -
-----------------------------------------------
As much as I hate using the "L" word, or even worse the "W" word,
I think you should start with Windows/Linux/DOS accessibility.
Not direct access, obviously, but with a small program
designed to load devices images onto the media, from
Simh, E11, or some other emulator.
The media would need a special area reserved for device information,
so that it knows what kind of volumes are stored on it.
This would eliminate any headaches involved with getting
operating systems onto the actual hardware.
Additionally, it could negate the need for a (controller based) user interface entirely.
-----------------------------------------------
Include a bootstrap at 17773000, which could
auto-boot DU0, or perhaps the VTServer stub.
-----------------------------------------------
Reserve some space on the CF/SD/USB media,
and ADD TU58 EMULATION to the device, so that
folks can have XXDP, or an RT11 distro onboard.
They could then use that for diagnostics,
or as an intermediate boot device, for systems
that don't have an MSCP bootstrap at their disposal.
-----------------------------------------------
And of course, the "beyond way cool factor" -
Approach the device from a very generic standpoint,
which could offer several of the more common emulations,
particularly for those with older operating systems to support.
DU/RL/RK/RM/RP for disks, MU/MS/TM/TS for tapes.
Providing multiple emulations on the same media
would be problematic at best, so each slot would be
limited to a single emulation.
A board with two media slots could be set for
MSCP emulation on slot 1, and RL11 emulation on slot 2.
I think this could be accomplished by making a set of routines
to handle the functions that are common to all disk/tape controllers,
and then have a "middle man" to perform the actual emulation,
by interacting with the other (common) routines.
Basically, you'd create a routine to handle all of the Q-Bus I/O,
including CSR, Vector, BIRQ, and data transfers, etc.
Then create a routine to handle all interaction
with the CF / SD / USB media, including drive sizing, etc.
Finally, create the various portions of emulation-specific code
that interacts with them, and provides the actual translations.
Store all controller / volume-specific information
in a reserved section of the CF/SD/USB media.
Upon controller initialization, this section is accessed,
providing the configuration information needed to proceed.
The controller will then load the appropriate emulation-specific code
to act as an intermediary between the QBus, and the media.
In actual use, the controller would query the media, which would respond with -
"Hey, I'm supposed to be an RL11, at 17774400, Vector 160, BIRQ 4, with
Unit 0 (RL01) Unit 1 (RL01) Unit 2 (RL02) Unit 3 (RL02) attached".
The controller would do the rest.
Not enough EEPROM space for the code for the various emulations?
No problem -- store the emulation-specific code in the reserved space
of the media, and load it at initialization instead, thereby cutting down
tremendously on the amount of EEPROM space needed.
Alternately, you could create just enough initialization code
to access the media in the first slot, and load the entire
operational code from the reserved space on the media.
Keep in mind that I know nothing about Q-Bus mechanics,
operating system drivers, device programming, etc.
Therefore, I do not know what kind of effort would be needed
to accomplish all of this. I do know, however, that it can be done
Last edited:
Good point. The smallest 11 I ever actually used for anything was an 11/04 with 16KW and RX02s running RT-11, but most of my time was spent with 22-bit machines with MSCP disks running M-PLUS. My own 11/73 had an RQDX1 running an RD52 and an RX50, and an Emulex DM01 running two Seagate ST-4096's.
Um, nothing. I got rid of my 11/73 when I was moving in 1999 after I realized that I hadn't turned it on since 1991 or so (the last time I had paid work on a PDP-11).
oktology
Experienced Member
Did this go anywhere?
pbirkel@gmail.com
Veteran Member
https://retrocmp.com/projects/qbone is the best currently-shipping match, I think.
+1 for qbone, there has been some chatter in the ccmp discord about getting the QSIC project started again (or perhaps replaced) but nothing is available atm
oktology
Experienced Member
Yikes that doodad ain't cheap. For the price I could grab an Emulex SCSI card and a SCSI2SD with cash to spare. :/
it isn't, but the advantage of the qbone is that it's a fully-fledged diagnostics platform as well, you can twiddle all sorts of low-level bits and run diags from xxdp far more easily than usual. imo it's well worth the money, but if you're just looking for a device emulator then i can definitely understand the apprehension