• Please review our updated Terms and Rules here

Interested in a Qbus MSCP to ATA/IDE/SD adapter?

Design Decisions / Project goals

Design Decisions / Project goals

teve,

Well, it looks like there are some design decisions to be made. I tend toward proven designs like CHD's, but we could take it further. Rather than be everthing to everyone, though, I'd advocate setting a set of goals and agree on those from the start. I think you should take a cut at this (MSCP or not, QBUS or OMNIBUS, CPLD or FPGA or microprocessor-based, through hole or SMD).

Some observations:
I honestly don't think through-hole will cut it, and surface-mount (though a pain) will ensure parts availability now and in the future.
Second, FPGA or microprocessor will need to be decided.
It's painful that it's a 3.3V world so you either choose a 5V obsolete or almost obsolete part or do voltage translation from 5V.
If you use a micro, I think you'll need something better than an 8-bit PIC . Propeller chip?
This is likely to be done with little PC board space, so either a *really* short QBUS or a lot of blank (or breadboard) space would work. (But square inches == $ with boards)

So, just my 0.02 USD and I'd just be happy with anything that works in the end..

-Crawford
 
Well, it looks like there are some design decisions to be made. I tend toward proven designs like CHD's, but we could take it further. Rather than be everthing to everyone, though, I'd advocate setting a set of goals and agree on those from the start. I think you should take a cut at this (MSCP or not, QBUS or OMNIBUS, CPLD or FPGA or microprocessor-based, through hole or SMD).
OK, my take is:

  • Definitely MSCP. I don't want to have to write drivers or rely on others to write them. The closer to plug and play the better.
  • Qbus to start with. I'm assuming this is the most common set-up. Omnibus/Unibus/Massbus/Whateverbus can always be done later, as long as the design is modular enough. Plus I don't have an Omnibus machine to test on ;-)
  • Microprocessor/controller. I think you'd really need this to implement MSCP and any on-board configuration utilities.
  • Through-hole/SMD I'm not sure about yet.

Some observations:
I honestly don't think through-hole will cut it, and surface-mount (though a pain) will ensure parts availability now and in the future.
I'd really prefer through hole, but I'm not by any means discounting SMD as yet. I think I'll just have to see how it pans out. I hope a preliminary design and/or prototype will help here - it's early days yet.

If you use a micro, I think you'll need something better than an 8-bit PIC . Propeller chip?
Yes, 8-bit would probably be quite painful. Both ATA and Qbus are much easier with 16 bits. You'd also need either plenty of I/Os or enough supplementary logic to handle the Qbus signals (44 signals in all, most of which will be required at some point).

This is likely to be done with little PC board space, so either a *really* short QBUS or a lot of blank (or breadboard) space would work. (But square inches == $ with boards)
I'm imagining this thing as a regular length, dual height card which could be fitted with handles and has space for an on-board IDE/CF adapter. I'm really not sure what that would cost to have made - probably too much ;-)
 
The propeller chip is neat, but it has a rather unique programming style. It will take some learning, at least on my part. (On the other hand, this whole project will be big learning experience for me) I'm thinking that maybe we should go for some 32bit ARM, maybe overkill, but they are not very expensive I think. OTOH they are only surfacemount?
 
The ARM chips are what keep popping up in my searches, too. It seems hard to find the combination or large memory*, large number of I/O pins and easy-to-handle package. I was thinking there might be a PLCC version of something usable, but the pickings seem pretty slim. I'm starting to wonder if it's worth looking at separate processor/memory/etc...

* I'm thinking we'll need a fair amount to handle the MSCP queues an buffers. The RQDX3 uses 8KW (16KB) of SRAM, which is quite a lot for a uC.
 
I did miss one design criteria - flash or EPROM memory, and the ports for in-circuit programming if we go with flash.

As Lou mentions the RQDX3, that gives us the opportunity to 'reverse engineer' the implementation of the protocol with a familiar chip, which is goodness!

The mbed project http://mbed.org/ has an ARM chip presoldered to a 40 pin header.

BTW, Steve - I agree with all your chioces and the reasoning behind them. Laptop drives being a convenient size, even a vertical mount 44-pin Laptop drive + CF slot wouldn't be too hard.

Also OMNIBUS could be "Phase 2" ...

-Crawford
 
I did miss one design criteria - flash or EPROM memory, and the ports for in-circuit programming if we go with flash.
Yeah, I'd pretty much taken in-circuit programming as a given as all the modern micros seem to support it.

As Lou mentions the RQDX3, that gives us the opportunity to 'reverse engineer' the implementation of the protocol with a familiar chip, which is goodness!
The RQDX3 is a great reference design and pretty neat hardware-wise, too. The firmware can be disassembled, but the SIMH code is probably an easier starting point (unless, of course, you're more familiar with assembly than C).

The mbed project http://mbed.org/ has an ARM chip presoldered to a 40 pin header.
Very cool. There are also these pre-mounted AVRs (not necessarily for the chip, but this kind of adapter would definitely make things easier for home builders).

BTW, Steve - I agree with all your chioces and the reasoning behind them. Laptop drives being a convenient size, even a vertical mount 44-pin Laptop drive + CF slot wouldn't be too hard.
I was think about using a 44-pin header on the card. It may make sense if most people are going to be using CF or 2.5" drives as power is right there on the connector. For 3.5" drives a 44-to-40 adapter could be used. Or make two sets of holes and let the builder mount their header of choice.
 
Some more ideas to get started

Some more ideas to get started

I found a few resources that might help:

Futurelec has an ARM chip mounted on a header: http://www.futurlec.com/ET-ARM_Stamp.shtml

(Yes, it's a 3.3V part, but we'll have to deal with that with about everything.)

Anyway, that thing has a lot of I/O pins and serial download of code. Combined with a C compiler (like WinARM or gcc) it could do the trick. 128K of Flash and 16K of RAM and can run close to 60Mhz. Not bad for $28 USD.

Douglas Electronics has some wirewrap boards http://www.douglas.com/hardware/pcbs/breadboards/digital.html for prototyping, or those who just *cough* LOU *cough* like wirewrap.. ;)

-Crawford
 
I've been looking at STMicro's STR750 series:
  • 64-256KB Flash
  • 16KB RAM
  • 60MHz ARM7
  • UARTs, USB, RTC, etc.
  • 38 or 72 I/Os
  • Single 5V supply!
They seem to go for around $10-15. They come in 0.5mm pitch SMD packages, but adapters to 0.1" are out there (not sure how you'd get them on there, but I may well know a guy who knows a guy who could solder up a small batch).

The Douglas boards look great. I remember seeing their name pop up as the supplier of boards used to build PDP-11 ARAPNET interfaces. I had a rummage through my box of Qbus bits and found some kind of LSI-11 bus extenders. Only 18-bit, but I reckon I'd just need to run a ribbon cable or two to connect them to a regular prototyping board. I might have one or two spare, if anyone's interested.
 
Dev board available

Dev board available

Steve,

Looks like there's a dev board for that chip also: http://parts.digikey.com/1/parts/1135910-board-development-love-str750-str750-love.html

I always look for a dev board to make sure there's a reference design to start from... Here's the description of that board:

The I Love ST Mini Development Board contains an STR750 microcontroller, 16 LEDs, 2 skin-conductance
pads which can be used as buttons, and an STR711 controlling the USB port and the JTAG functions.
The board will run for several hours on the lithium battery mounted on the bottom of the board. No external
JTAG debugger probe is necessary. Simply connect a mini-USB cable to the board and load the KickStart
edition of IAR Embedded Workbench for ARM to Flash and debug your STR750 application.

This wouldn't be the final configuration, but it would help get it working.

-Crawford
 
As I have little experience with uC's I don't have much to add to the discussion. But the small development kits at least looks cool :)

What I have been doing is starting to read up on the MSCP protocol and it doesn't look extremely difficult. There are lots of rules, but it boils down to guaranteeing that a message can be received at the time it is sent, with some exceptions to make it more fun :) There are some requirements on the physical appearance of the hardware as well (it needs a few indicator lamps and a drive ID selector).

I'll do some more reading and start looking for source code from other places, I bet that there is something in NetBSD and in SIMH that can be useful.

Oh, and here is fun quote from /pdf/dec/disc/uda50/AA-L619A-TK_MSCP_BasicDiscFnsV1.2_Apr82.pdf:

The MSCP server may assume, in determining its maximum attention message rate, that human operators do not engage in pathological activity. That is, it may assume that cases such as an operator continuously actuating the Run/Stop switches on one or more drives will never occur.
 
Heh, it may not look the part, but the price is right! STMicro also have a few PDFs with some useful examples. I really looks like a nice little chip, assuming we can get around the fine pitch issue. I suppose one could always use the electric skillet method!

There are some requirements on the physical appearance of the hardware as well (it needs a few indicator lamps and a drive ID selector).
Yeah, we ought to put a header on this thing for a BA23 control panel. That gives you some blinkenlights and switches for on/offline and write protect. This is stuff I'd like to be able to do in software too. I was thinking of a simple CLI similar to that of SIMH, where you can attach/detach disk images, set parameters and all that business. This could be accessed by a serial port on the card itself, through the console, or both.

I've been busy sketching out schematics of the transceivers and buffers and figure it'll take a little under 20 TTL ICs to fully buffer both the Qbus and ATA sides. I have a simple address decoding circuit worked out too, using a bunch of DIP switches, 7486s and a big NAND gate. I'm however wondering if there's a better way to do that; if we want to do TMSCP too, there are two sets of addresses we'd need to respond to. Having every new IO page access fire an interrupt and then having the uC decode the address should work, but would that many interrupts end up getting us in trouble? I'm guessing that with the uC running an order of magnitude quciker than the Qbus, we'd get away with it. The big bonus of such an approach would be software-configurable CSRs and even support for multiple virtual controllers.
 
Perhaps this is not worth looking into, but I might as well mention it. I preface it by stating that I have only technician and not engineer level design skills, and so the thought of programming a controller to implement the whole MSCP protocol sounds daunting to me. (What can I say, I'm a mechanical engineer for my day job.)

RQDX3s are pretty common and work great. Perhaps one could leverage most of the RQDX3 intelligence, tapping the IDE drive adapter in at the socket for the SMC HDC9224 . I think I might have a fighting chance designing something that looked to everything upstream like a 9224 (and everything downstream of it). Maybe I could make it look like I had four RD54s attached.

I'm going to read a bit more about the 9224 from the 1985 Standard Microsystems databook copy that's on bitsavers.

Lou
 
Lou,

What you're proposing doesn't sound too preposerous. There were some adapters that spoke MSCP on one side and SCSI on the other like this one: http://www.bitsavers.org/pdf/sigmaInformationSystems/401195-B_SDC-RQD11_SCSI_Ctrl_Man_Jan89.pdf

IIRC, the RQDX3 also does the MFM encoding which is not needed for IDE interface. IDE is a straightforward block interface. I think the RQDX3 interface would have to be modified, as it was programmed with the geometry of specific drives...

-Crawford
 
Crawford,

The HDC9224 is the brain on the RQDX3 that provided the MFM encoding/decoding - it's a disk controller on a chip. This is why it is the logical place to splice in the new hardware to interface to the IDE disk (and it's in a socket!). Basically I would remove the 9224 and plug in an HDC9224/MFM disk emulator that uses an IDE disk.

It's not the RQDX3 that's programmed with the drive specific geometry, it was a the ZRQC?? formatter. I have successfully patched ZRQCH0 for a non standard RD geometry and formatted a non RD-disk to its full capacity on an RQDX3. This cannot be done with an RQDX1 or 2 however, because they have the RD51/52 geometries hard coded on the eproms.

As for MSCP/SCSI controllers, there were many, including the RQZX1 and CQD220, but these always fetch big $$$ on ebay.

Lou
 
RQDX3s are pretty common and work great. Perhaps one could leverage most of the RQDX3 intelligence, tapping the IDE drive adapter in at the socket for the SMC HDC9224.
That's an approach I'd considered, too; I'd be very interested to hear how that goes. I decided against it myself as I'd like to build something stand-alone and am personally quite interested in getting to grips with the Qbus end of things. Eventually I'd like to be able to break free of the RQDX3's limitations. I'm more software oriented myself, so implementing MSCP is something I'd consider a nice challenge and the thought of plugging into the 9224's socket sounds more daunting ;-)

Anyway, I figured it was time to post a quick update so it doesn't look like the project has stalled before it even got started.

  • Beeped out my funky bus extender card. Turns out it will be good for Q22 but I may need to run a couple of extra wires for BIAKI/BIAKO and BDMGI/BDMGO as these are jumpered to one pin per pair. For the time being I'll probably just plug it in as the last card and not bother passing the signals on (RQDX1, anyone? ;-)
  • Worked out most of the Qbus transceiver stuff and which groups of signals need to be enabled for input or output at which times.
  • Started building a prototype with some salvaged DS8641 chips and a bit of TTL to play with the Qbus interface. I worked out a double pattern PCB layout to allow either original transceiver chips or AM26S10Cs.
  • Ordered an STR750 and a through-hole adapter. I'll see if I can get someone to unite the two and otherwise give one of the homebrew methods a shot.

Just now I'm working out which pins of the uC to use for what. For the prototype I'm going to take jthiemann's advice and try using an SD card as storage. SD takes a paltry 4 I/Os as opposed to 23 required for a one-to-one ATA connection. Even with a uC with 72 I/Os they're quickly running out when stuff like a UART, JTAG and enables for the glue logic are all accounted for. ATA would require reusing pins and therefore a bit of extra buffering which I can do without right now.
 
Steve,

Glad that you're moving ahead with this. Again, I wouldn't be afraid of soldering up the STR750. I have hand soldered similar chips. Position the chip carefully and tack the outer pins. Solder the rest of the pins ignoring solder bridges at first. Follow up with solder wick to eliminate bridges. Use a magnifying glass or microscope to check the work. Takes a while, but it works.

SecureDigital (SD) cards may be an easier start, true. Sparkfun and others have SD card sockets. If you can do a block mode it would probably be easier. Someone mentioned using the FAT file system, and there are chips that can do the hard work. I just don't know if FAT and the native PDP-11 OS's will play nice for filenames, endian-ness, etc.

Good luck! Let us know when the beta testers can get involved!

-Crawford
 
Thanks, Crawford - I'll give that technique a go. I recently treated myself to a new soldering station and a nice fine tip which should come in useful for SMD stuff.

I was thinking of using FAT merely as a "container" for the disk images, which would make it much easier to transfer data to and from modern machines. I suppose if one was so inclined it would be possible (although probably rather tricky) to do some kind of file system translation for accessing individual files.
 
Nice to see that you are working on it. I have not found the time to investigate the MSCP further :( I'm rescuing some SGI iron which takes much of my brainpower right now :)
 
Back
Top