27 Feb
2008
27 Feb
'08
9:19 p.m.
I stopped holding my breath for creation of a Q-Bus IDE
controller a long time ago. While I like to think that I
do a reasonable job troubleshooting some problems,
I'm definitely not a hardware/software engineer.
It would have been nice, but it makes more sense
these days to go Q-Bus to SATA. I would imagine
that it would be alot less hassle, and certainly alot less
real estate on the board, with the smaller connectors,
and fewer traces.
At any rate, back to the topic, Q-Bus to Compact Flash.
If you can do Q-bus to Compact Flash, then you can do
Q-bus to IDE, because CF *is* an IDE interface.
Those wonderful CF to IDE adapter boards generally don't
have any circuitry on-board, except to drive status LED's.
Right now, I have Compact flash / IDE on my Q-bus,
albeit in a round-about way.
I have older CMD SCSI controllers (CQD-200's).
Attached to those are ACard 7720U SCSI <> IDE adapters.
http://www.acard.com
The CMD controllers don't have any problems with them,
and it seems to be happy with older IDE drives that I've tried.
And finally, I have ACS IDE <> Compact Flash adpaters.
http://www.acscontrol.com
You can use any IDE <> CF adapter you want,
and you can certainly get them alot cheaper elsewhere.
I chose the ACS unit, since they were one of the few
that I could find that offered it in a 3.5" drive frame.
They also offer them in a 5.25" form factor, but I think
they're just using a readily available 3.5" to 5.25" frame.
I use a SCSI removeable chassis, so I had to modify my
Acard 7720U in order to fit everything into the tray.
There is at least one vendor that offers a direct
SCSI to CF adapter, but they were a bit pricy
compared to my homebrew version.
I have tested my configuration with CF cards
ranging from 4MB up through 2GB, and find
that it works adequately for my needs.
I could see no discernable speed increase between
using real SCSI drives, and the IDE <> CF adapter,
although I wasn't trying to do any significant benchmarking.
(The CQD-200's are kind of poky controllers anyway,
so this didn't really surprise me.)
Now, if I only I could use PUTR to dump a disk image
onto a RAW IDE device, I'd be a happy camper. . . ;-)
T
28 Feb
28 Feb
12:41 a.m.
On Thu, 2008-02-28 at 00:19 -0500, tiggerlasv at aim.com wrote:
I stopped holding my breath for creation of a Q-Bus IDE
controller a long time ago. While I like to think that I
do a reasonable job troubleshooting some problems,
I'm definitely not a hardware/software engineer.
It would have been nice, but it makes more sense
these days to go Q-Bus to SATA. I would imagine
that it would be alot less hassle, and certainly alot less
real estate on the board, with the smaller connectors,
and fewer traces.
Actually SATA is extremely exacting and needs unbelievably complicated
controller chips.
PATA, on the other hand, is just a fast parallel port. You can hook a
CF card up to anything, even a microcontroller, with just a tiny amount
of glue logic.
At any rate, back to the topic, Q-Bus to Compact
Flash.
If you can do Q-bus to Compact Flash, then you can do
Q-bus to IDE, because CF *is* an IDE interface.
Those wonderful CF to IDE adapter boards generally don't
have any circuitry on-board, except to drive status LED's.
Exactly. Simply grafting a PATA interface onto a QBus card is trivial.
Actually getting something that will either pretend to be an existing
controller or writing a device driver for the operating system in use is
much much harder.
If you really wanted to push this forwards, write me some MSCP
controller firmware for an Atmel microcontroller...
Right now, I have Compact flash / IDE on my Q-bus,
albeit in a round-about way.
I have older CMD SCSI controllers (CQD-200's).
Attached to those are ACard 7720U SCSI <> IDE adapters.
http://www.acard.com
These seem to crop up on the various sampler mailing lists I'm on, as a
way of using CF with older samplers which often have "funny" SCSI
implementations.
Gordon
1:41 a.m.
Gordon JC Pearce wrote:
Exactly. Simply grafting a PATA interface onto a QBus
card is trivial.
Actually getting something that will either pretend to be an existing
controller or writing a device driver for the operating system in use is
much much harder.
If you really wanted to push this forwards, write me some MSCP
controller firmware for an Atmel microcontroller...
I have the skillset to do this. What I don't have is the documentation
that would allow me to figure out how to talk MSCP and bit-bang Qbus.
If someone could point me in the right direction for the specs for
these, I'd be happy to write the firmware.
Peace... Sridhar
6:32 a.m.
If you really
wanted to push this forwards, write me some MSCP
controller firmware for an Atmel microcontroller...
I have the skillset to do
this. What I don't have is the
documentation that would allow me to figure out how to talk MSCP and
bit-bang Qbus. 
3:24 p.m.
On 28/02/2008 14:32, der Mouse wrote:
If you really wanted to push this forwards, write me
some MSCP
controller firmware for an Atmel microcontroller...
I have the skillset to do
this. What I don't have is the
documentation that would allow me to figure out how to talk MSCP and
bit-bang Qbus. I've seen doc on MSCP as implemented in device XYZ
in device XYZ's
manual, for at least one and I think two values of XYZ (UDA50 comes to
mind). I don't think I have any of the relevant manuals, but bitsavers
or vt100 or some such surely has at least one of them.
Bitsavers has AA-L619A-TK_MSCP_BasicDiscFnsV1.2_Apr82.pdf,
AA-L620A-TK_StorageSysDiags_1982.pdf and
AA-L621A-TK_UnibusPortDescription_1982.pdf at
http://www.bitsavers.org/pdf/dec/disc/uda50/
I'm not sure if these are the scans I did five years ago (the file dates
are later) but they're the docs you'd need.
--
Pete Peter Turnbull
Network Manager
University of York
3:53 p.m.
Pete Turnbull wrote:
On 28/02/2008 14:32, der Mouse wrote:
Excellent. Thank you. I'll see if I can give this a shot.
Peace... Sridhar
If you really wanted to push this forwards, write me
some MSCP
controller firmware for an Atmel microcontroller...
I have the skillset to do
this. What I don't have is the
documentation that would allow me to figure out how to talk MSCP and
bit-bang Qbus. I've seen doc on MSCP as implemented in
device XYZ in device XYZ's
manual, for at least one and I think two values of XYZ (UDA50 comes to
mind). I don't think I have any of the relevant manuals, but bitsavers
or vt100 or some such surely has at least one of them.
Bitsavers has AA-L619A-TK_MSCP_BasicDiscFnsV1.2_Apr82.pdf,
AA-L620A-TK_StorageSysDiags_1982.pdf and
AA-L621A-TK_UnibusPortDescription_1982.pdf at
http://www.bitsavers.org/pdf/dec/disc/uda50/
I'm not sure if these are the scans I did five years ago (the file dates
are later) but they're the docs you'd need. 
29 Feb
29 Feb
2:02 p.m.
Sridhar Ayengar wrote:
Bitsavers has
AA-L619A-TK_MSCP_BasicDiscFnsV1.2_Apr82.pdf,
AA-L620A-TK_StorageSysDiags_1982.pdf and
AA-L621A-TK_UnibusPortDescription_1982.pdf at
http://www.bitsavers.org/pdf/dec/disc/uda50/
I'm not sure if these are the scans I did five years ago (the file
dates are later) but they're the docs you'd need.
Excellent. Thank you. I'll see if I can give this a shot.
Peace... Sridhar From what I gather of looking at the MSCP protocol from
the DU(X).SYS MSCP device driver in RT-11, there may
be an easier implementation that is just as useful.
John Wilson set up an interface for an HD(X).SYS device
driver under Ersatz-11 in order to provide variable
sized devices until the MSCP emulation had been coded.
While John's version of HD: needs a bit of modification
to work well with mapped monitors, it is still only for
RT-11. On the other hand, for the past 6 months, I have
been adding additional features which include being able
to handle full 22 bit Qbus / Unibus interface for mapped
monitors.
The real HD: advantage is the simplicity of the interface.
While there are 8 I/O registers, setting them up when
interrupts are not used takes less than 20 PDP-11 instructions
including the 22 bit address. If you look at the hobby
version of E11, John includes the code for HD(X).SYS for
RT-11, although as I mentioned some changes are needed for
mapped monitors when the user buffer is above 1/4 MByte.
If anyone ever produces a Qbus / IDE (or any other PC
current drive) controller, I will gladly enhance the HD(X).SYS
device driver for RT-11 to use a DU(X).SYS translation
type table.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
2:46 p.m.
Jerome H. Fine wrote:
I am not sure if this suggestion is easier or even
useful.
Wouldn't the concern then be that it would only be supported in RT-11,
and/or it would not be bootable? One of the primary motivations for me
in this exercise would be CD-ROM booting. I'm seriously considering an
off-the-shelf solution for the ATA/ATAPI side to save myself some
effort. No sense reinventing the wheel.
Peace... Sridhar
From what I gather of looking at the MSCP
protocol from
the DU(X).SYS MSCP device driver in RT-11, there may
be an easier implementation that is just as useful.
John Wilson set up an interface for an HD(X).SYS device
driver under Ersatz-11 in order to provide variable
sized devices until the MSCP emulation had been coded.
While John's version of HD: needs a bit of modification
to work well with mapped monitors, it is still only for
RT-11. On the other hand, for the past 6 months, I have
been adding additional features which include being able
to handle full 22 bit Qbus / Unibus interface for mapped
monitors.
The real HD: advantage is the simplicity of the interface.
While there are 8 I/O registers, setting them up when
interrupts are not used takes less than 20 PDP-11 instructions
including the 22 bit address. If you look at the hobby
version of E11, John includes the code for HD(X).SYS for
RT-11, although as I mentioned some changes are needed for
mapped monitors when the user buffer is above 1/4 MByte.
If anyone ever produces a Qbus / IDE (or any other PC
current drive) controller, I will gladly enhance the HD(X).SYS
device driver for RT-11 to use a DU(X).SYS translation
type table. 
1 Mar
1 Mar
7:11 a.m.
On Feb 29, 2008, at 5:46 PM, Sridhar Ayengar wrote:
That'd be my concern as well. While I do like RT-11, my DEC OS
interests like in the areas of RSX-11 and especially RSTS/E. This is
where the whole "emulating an standard controller" comes into
play...and where I stall. I could easily build a Qbus ATA
adapter...but not so easily one that emulates something that already
exists.
-Dave
--
Dave McGuire
Port Charlotte, FL
If anyone ever
produces a Qbus / IDE (or any other PC
current drive) controller, I will gladly enhance the HD(X).SYS
device driver for RT-11 to use a DU(X).SYS translation
type table.
Wouldn't the concern then be that it would only be supported in RT-11,
and/or it would not be bootable? One of the primary motivations for
me in this exercise would be CD-ROM booting. I'm seriously
considering an off-the-shelf solution for the ATA/ATAPI side to save
myself some effort. No sense reinventing the wheel.
29 Feb
29 Feb
12:31 a.m.
On Thu, 2008-02-28 at 04:41 -0500, Sridhar Ayengar wrote:
Gordon JC Pearce wrote:
Actually any controller that would be easier to write firmware for would
be good. It would be trivial to carve up the card into multiple logical
units.
You could have, for example, four RL02s each capable of being assigned a
"pack" from the card.
What were the biggest non-MSCP-attached drives? How hard would they be
to emulate?
Gordon
Exactly. Simply grafting a PATA interface onto a
QBus card is trivial.
Actually getting something that will either pretend to be an existing
controller or writing a device driver for the operating system in use is
much much harder.
If you really wanted to push this forwards, write me some MSCP
controller firmware for an Atmel microcontroller...
I have the skillset to do this. What I don't have is the documentation
that would allow me to figure out how to talk MSCP and bit-bang Qbus.
If someone could point me in the right direction for the specs for
these, I'd be happy to write the firmware. 
28 Feb
28 Feb
6:09 a.m.
At 11:19 PM 2/27/2008, tiggerlasv at aim.com wrote:
It would have been nice, but it makes more sense
these days to go Q-Bus to SATA.
IDE to SATA dongles appeared long ago, they're < $20 USD.
Stacks of X-to-Y adapters seem flakey to me, but it might work.
- John
--
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.8/1288 - Release Date: 2/19/2008 8:47 PM
29 Feb
29 Feb
7:17 a.m.
On Feb 28, 2008, at 12:19 AM, tiggerlasv at aim.com wrote:
I stopped holding my breath for creation of a Q-Bus
IDE
controller a long time ago. While I like to think that I
do a reasonable job troubleshooting some problems,
I'm definitely not a hardware/software engineer.
It has been done. Chuck Dickman did one, I think. It's actually
really easy...device drivers are the hard part.
It would have been nice, but it makes more sense
these days to go Q-Bus to SATA. I would imagine
that it would be alot less hassle, and certainly alot less
real estate on the board, with the smaller connectors,
and fewer traces.
Ohhh noonono. The only similarity between ATA and SATA is three
letters in the acronym. SATA is a very intelligent, very complex,
and VERY VERY FAST connection. That's so far beyond "impractical"
that I don't even want to think about it.
If you can do Q-bus to Compact Flash, then you can do
Q-bus to IDE, because CF *is* an IDE interface.
Those wonderful CF to IDE adapter boards generally don't
have any circuitry on-board, except to drive status LED's.
Well, not exactly, but CF is *mostly* IDE (ATA). For nearly all
applications, they are interchangeable. One difference that comes to
mind is that CF is required to implement 8-bit transfer modes while
ATA is not. This is immaterial in most situations, but I thought it
might be a good idea to mention it.
I could see no discernable speed increase between
using real SCSI drives, and the IDE <> CF adapter,
although I wasn't trying to do any significant benchmarking.
(The CQD-200's are kind of poky controllers anyway,
so this didn't really surprise me.)
They are?? I thought they were among the fastest Qbus SCSI
adapters available.
-Dave
--
Dave McGuire
Port Charlotte, FL
5922
days inactive
5924
days old
11 comments
8 participants
participants (8)
-
gordonjcp＠gjcp.net -
jfoust＠threedee.com -
jhfinedp3k＠compsys.to -
mcguire＠neurotica.com -
mouse＠Rodents.Montreal.QC.CA -
pete＠dunnington.plus.com -
ploopster＠gmail.com -
tiggerlasv＠aim.com