PDA

View Full Version : Interested in a Qbus MSCP to ATA/IDE/SD adapter?



cosam
January 15th, 2010, 06:58 AM
I've been thinking about putting together a Qbus MSCP to ATA/IDE adapter for a while now; mostly just brainstorming, but as my supply of remaining functional MFM drives begins to dwindle, maybe it's time to do something concrete about it. SCSI adapters tend to be expensive (if buying a commercial one) or pretty complicated to build at home. I also think it'd be really convenient to be able to use one of those handy CF/IDE adapters to put a few GB of storage right on the card. The availability of small IDE disks is also a nice bonus (yes, you can still find small SCSI disks, but they're not quite as common).

I'm aware of this similar project (http://www.chd.dyndns.org/qbus_ide/) which looks nice. Pretty much everything is done by one big CPLD, but it would appear that you need a specific driver to talk to it. I wonder if it's feasible to emulate, for example, an RQDX3 which a lot of operating systems support out of the box. If it could also do TMSCP, you could even read and write tape images, meaning you could do full bare-metal installations.

So how much interest is there in such an adapter? I know if this was already available for a reasonable price I'd have bought/built at least one or two by now. There appears to be enough documentation out there on the Qbus and the MSCP protocol itself to design and build a working controller, but I know that if I had to do it all myself, we'd be a few years further down the line before anything resembling a functional card came to fruition. If you're at all interested in either using or possibly even contributing to the development of such an interface, please let me know.

Cheers,

jthiemann
January 15th, 2010, 08:28 AM
Why IDE? I would consider SD cards: current technology, cheap, no need to worry about mounting brackets... The interface is reasonably well documented on thar intertubes, and for prototyping an old floppy drive edge connector will do as a socket. Interface the QBUS to a small uController that has SPI interface, and you're all set without mucking about with FPGAs.

cosam
January 15th, 2010, 09:00 AM
SD? Why not, indeed! I initially thought of ATA as it's simple and I have some experience interfacing to it. The bulk of the work is likely to be handling the MSCP stuff; the physical storage could be pretty much anything.

I too have a preference towards uC's as opposed to FPGAs, although that is again more of a familiarity thing. There's a fair bit of code required to implement MSCP, which would likely be easier to do in C or assembler than in logic gates. I suspect there will be a reasonable amount of logic required too, though, so an FPGA or CPLD is by no means out of the question.

Crawford
January 15th, 2010, 09:02 AM
Steve,

Yes! I'm in for a Qbus/IDE interface. Using Chuck's design, I even started putting one into EagleCAD, until I ran into some limitations of the free EagleCAD version. (It's hard to do a Qbus form factor with the 4"x3" limitation of the free version).

My opinion is that if we could design a PCB, using non-obsolete parts, that would be best. IIRC, Chuck's design uses the old buffer chips that are no longer available. Then send the PCD design off to one of the many PCB shops for a group buy.

BTW, once you get and IDE interface working, there are many IDE -> whatever (SecureDigital, Compactflash, etc) adapters that will work.

-Crawford

cosam
January 15th, 2010, 11:09 AM
Using Chuck's design, I even started putting one into EagleCAD, until I ran into some limitations of the free EagleCAD version. (It's hard to do a Qbus form factor with the 4"x3" limitation of the free version).
I've never tried Eagle, but I was quite impressed with KiCad. I've only really tinkered with it up to now, but it seems pretty capable and, being free, there are no limits to worry about.


My opinion is that if we could design a PCB, using non-obsolete parts, that would be best. IIRC, Chuck's design uses the old buffer chips that are no longer available. Then send the PCD design off to one of the many PCB shops for a group buy.
Yep, definitely a PCB and, as far as possible, readily available parts. I was wondering about those buffers and had already assumed the worst. I'm not adverse to borrowing a few bits from old Qbus boards, but I'd rather not if I don't really have to.

Crawford
January 15th, 2010, 04:44 PM
Steve,

I'll have to look back at the EagleCad drawing, but I believe I found an equivalent Differential buffer chip. Inevitably, they are Surface Mount Devices (SMD), but that's just what almost everything is these days.

-Crawford

cosam
January 16th, 2010, 03:55 AM
Hi Crawford,

I'm not far through the Qbus docs, but I was under the impression that it was an open collector bus. I'm wondering whether it's possible to use some 74-series logic with open collector outputs as (part of) the buffer. I'd prefer through-hole parts where possible but, as you say, SMD is the norm these days.

pontus
January 16th, 2010, 09:43 AM
I'm in! I would probably buy one or two and if I can contribute to the project, I will. I don't know much about hardware design but I do coding for a living.

cosam
January 16th, 2010, 01:14 PM
Hi Pontus,

Thought you might be interested - good to have you aboard! You might also be interested in looking at the SIMH (http://simh.trailing-edge.com/) sources, which the designer of this homebrew SCSI adapter (http://www.wintersweet.com/mscpscsi/) used as a basis for the software. Some code was also borrowed from BSD Unix, which can be found on the PUPS (http://minnie.tuhs.org/PUPS/) archive. There's also a nice description of MSCP on bitsavers (http://bitsavers.org/) (/pdf/dec/disc/uda50/AA-L619A-TK_MSCP_BasicDiscFnsV1.2_Apr82.pdf).

Other things which would need coding would be some kind of setup utility that could be run from the card, much like the software found in commercial SCSI adapters, to allow one to partition/configure the available storage. However, just allocating a fixed amount of raw storage would allow us to skip this step for early revisions.

A nice "icing on the cake" feature would be to support filesystems on the physical storage device. Imagine copying disk images to a CF/SD card on your PC, then being able to assign them as actual devices on your PDP-11 or VAX :-)

Cheers,

jackrubin
January 17th, 2010, 04:58 AM
Any thoughts about an Omnibus interface for us 12-bit laggards?

Lou - N2MIY
January 17th, 2010, 05:13 PM
Jack,

If you've looked through CHD's website, you'll see that he also mentions an omnibus IDE controller that he built. It was PIO (not data break). Also, he could not manage to fit an OS/8 handler for it in two pages, so he wrote a big handler that sits in field 7 that is called from the little OS/8 handler. (This reminds me of how the IDE controller in the SBC6120 works. Bob has a little OS/8 handler that calls the big handler that resides in 6120 panel memory.) I thought about asking Chuck for more info on the IDE controller, since he did get it working. Also, I built his 32k SRAM omnibus memory and it works quite nicely: http://www.vintage-computer.com/vcforum/album.php?albumid=2&attachmentid=2430 .

Crawford,

If you ever make a run of boards of Chuck's qbus-IDE interface, I'll certainly pitch in. It may not be MSCP, but he did write RT-11 handlers for it. I wish though that instead of the 8838s or some non-through hole substitute you might use 7438s and 7404s. I notice that he doesn't really take advantage of the separate disable A and B (NORed) on the 8838. Basically, I think each 8838 can be replaced by one 7438 and one 7404 the way Chuck is using them. I would really prefer the through hole route, even if it means more sockets / real estate.

JTAG programmers are getting pretty cheap now, so this is a project that's definitely on my to do list (but behind some other big projects...)

Lou

jackrubin
January 17th, 2010, 07:10 PM
Lou,

I know about Chuck's memory/IDE board but haven't followed up with him on it. Glad to see that you got it running since he made it sound so preliminary. Maybe I'll give it a try and also follow up with him about the IDE. I was thinking the same way you were, about snagging Bob's IDE handler if Chuck's wasn't working. Got a lot more to learn about this "simple" machine before I get that far though.

Jack

pontus
January 17th, 2010, 11:12 PM
Hi Pontus,

Thought you might be interested - good to have you aboard! You might also be interested in looking at the SIMH (http://simh.trailing-edge.com/) sources, which the designer of this homebrew SCSI adapter (http://www.wintersweet.com/mscpscsi/) used as a basis for the software. Some code was also borrowed from BSD Unix, which can be found on the PUPS (http://minnie.tuhs.org/PUPS/) archive. There's also a nice description of MSCP on bitsavers (http://bitsavers.org/) (/pdf/dec/disc/uda50/AA-L619A-TK_MSCP_BasicDiscFnsV1.2_Apr82.pdf).

Other things which would need coding would be some kind of setup utility that could be run from the card, much like the software found in commercial SCSI adapters, to allow one to partition/configure the available storage. However, just allocating a fixed amount of raw storage would allow us to skip this step for early revisions.

A nice "icing on the cake" feature would be to support filesystems on the physical storage device. Imagine copying disk images to a CF/SD card on your PC, then being able to assign them as actual devices on your PDP-11 or VAX :-)

Cheers,

All good suggestions, I'll start reading up on the subject.

As file system, FAT would probably be quite simple to handle, but is it good enough for the purpose?

What uC do you have in mind? It might be a limiting factor.

I too would want mass storage for the Omnibus, that might be a followup project?

cosam
January 18th, 2010, 02:05 AM
I wish though that instead of the 8838s or some non-through hole substitute you might use 7438s and 7404s. I notice that he doesn't really take advantage of the separate disable A and B (NORed) on the 8838. Basically, I think each 8838 can be replaced by one 7438 and one 7404 the way Chuck is using them. I would really prefer the through hole route, even if it means more sockets / real estate.
I've been looking at this stuff in particular as it's the part I'm least familiar with. I'm sure a 7438 or similar could be used to drive the bus, assuming it can sink enough current. What I'm not so sure about is the bus receivers. The DC characteristics are described in the Qbus specs:

Nominal voltage: 3.4V
Maximum low voltage: 1.3V
Minimum high voltage: 1.7V

Although I suspect that typical values would be within the thresholds for normal TTL, spec-wise it's quite a way off.

cosam
January 18th, 2010, 02:29 AM
As file system, FAT would probably be quite simple to handle, but is it good enough for the purpose?
I think FAT(32?) would do fine. It's probably the most universal when it comes to writing data from different OSes. I don't think we're going to be asking a great deal from the file system, it just needs to be able to handle a few files of several MB a piece. Long file names would be nice, though.


What uC do you have in mind? It might be a limiting factor.
I've really no idea yet. I've only messed with little PICs and am more used to separate CPU, memory, etc. Hopefully someone can help steer us in the right direction in this department ;-)

One possibly influential factor is whether we're going to be doing DMA or not, and on which interfaces (Qbus and/or ATA). I'm not sure if you need to do DMA on the Qbus in order to be "RQDX compatible", but it certainly sounds like a nice feature. Should one leave this up to the uC or a separate controller? If the latter, what do you do about shared memory? Is DMA on the ATA side worth bothering with if using PIO and a fast uC?

pontus
January 18th, 2010, 06:13 AM
I think FAT(32?) would do fine. It's probably the most universal when it comes to writing data from different OSes. I don't think we're going to be asking a great deal from the file system, it just needs to be able to handle a few files of several MB a piece. Long file names would be nice, though.


I agree



I've really no idea yet. I've only messed with little PICs and am more used to separate CPU, memory, etc. Hopefully someone can help steer us in the right direction in this department ;-)

One possibly influential factor is whether we're going to be doing DMA or not, and on which interfaces (Qbus and/or ATA). I'm not sure if you need to do DMA on the Qbus in order to be "RQDX compatible", but it certainly sounds like a nice feature. Should one leave this up to the uC or a separate controller? If the latter, what do you do about shared memory? Is DMA on the ATA side worth bothering with if using PIO and a fast uC?

I'll talk to a fellow geek for suggestions, it might even spark his interest in the project :)

Another thing to think about is the development environment, it might be nice to get something going within SIMH to do testing of the uC code. By the looks of it, it emulates QBux Vax:en.

Crawford
January 18th, 2010, 09:43 AM
Folks,

I got my schematic dug up, and I used AM26S10CDIL16 (AM26S10C) for the buffers. They seemed like the closest match to the now-obsolete 8838's. It's pretty much Chuck's schematic, with some informed guesses about where some of the lines go (not everyting was labelled on Chuck's schematic).

I'm intrigued about the idea of making it look like an MSCP so it will 'just work' with everything but have little clue as to what that would entail.

-Crawford

cosam
January 18th, 2010, 10:22 AM
I got my schematic dug up, and I used AM26S10CDIL16 (AM26S10C) for the buffers. They seemed like the closest match to the now-obsolete 8838's.
Nice find! According to TI's site, they're even still available in DIP.


It's pretty much Chuck's schematic, with some informed guesses about where some of the lines go (not everyting was labelled on Chuck's schematic).
Aah, I thought I was missing something on that schematic!


I'm intrigued about the idea of making it look like an MSCP so it will 'just work' with everything but have little clue as to what that would entail.
A lot of it will be doable in software, once we can get a uC talking to the Qbus. MSCP is a lot like a network protocol (and was in essence used as such in some VAX clusters) so it's a matter of decoding the incoming packets, performing the relevant storage and housekeeping actions, and sending back responses. This is what makes the RQDX driver of SIMH an interesting reference - this is basically what we need to be doing, only the interfaces are to real hardware as opposed to software.

cosam
January 18th, 2010, 11:00 AM
Another thing to think about is the development environment, it might be nice to get something going within SIMH to do testing of the uC code. By the looks of it, it emulates QBux Vax:en.
Interesting idea. Although there are always things you couldn't really test in simulation, it would definitely be useful for the protocol handling and housekeeping side of things. If one went so far as to simulate the ATA interface at register level (there must be code out there for this somewhere) it could become quite a comprehensive test bed!

cosam
January 20th, 2010, 05:13 AM
Ok, here's a quick block diagram of what I'm playing with at the moment. The buffer on the ATA interface might be overkill, or there may need to be an extra one on the Qbus transceivers depending on how they're implemented.

2995

The address/interrupt decoding stuff deserves some extra explanation. Communication to and from ATA (assuming PIO mode) is completely within the uC's control, as is writing to the Qbus. The only potentially time-critical operation is reading from the Qbus, or more accurately, detecting that the bus master is trying to talk to us. I'm thinking of using an interrupt to handle this in a timely fashion, as opposed to polling the Qbus for "our" address. In my head it sounds good, but please do feel free to shoot this idea down if need be ;-) I'll draw up some schematics of what I have in mind for this part.

Crawford
January 20th, 2010, 05:14 AM
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

cosam
January 20th, 2010, 07:47 AM
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 ;-)

pontus
January 21st, 2010, 02:33 AM
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?

Lou - N2MIY
January 21st, 2010, 02:48 AM
To keep this in perspective, with regard to microcontroller power required, the RQDX3 got the job done nicely with a T-11.

cosam
January 21st, 2010, 02:54 AM
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.

Crawford
January 21st, 2010, 04:34 AM
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

cosam
January 21st, 2010, 05:20 AM
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 (http://www.kanda.com/products/kanda/KANMEGDEV2561.html) (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.

Crawford
January 22nd, 2010, 12:27 PM
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

cosam
January 22nd, 2010, 02:29 PM
I've been looking at STMicro's STR750 series (http://www.st.com/mcu/inchtml-pages-str7.html):

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.

Crawford
January 26th, 2010, 09:19 AM
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

pontus
January 26th, 2010, 09:38 PM
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.

cosam
January 27th, 2010, 02:01 AM
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
Heh, it may not look the part, but the price is right! STMicro also have a few PDFs (http://www.st.com/mcu/familiesdocs-86.html) 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 (http://wb9ipa.qrpradio.com/smt/smt.htm)!


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.

Lou - N2MIY
January 27th, 2010, 05:44 PM
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

Crawford
January 28th, 2010, 08:12 AM
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

Lou - N2MIY
January 28th, 2010, 03:44 PM
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

cosam
February 11th, 2010, 02:01 AM
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 (http://www.st.com/mcu/devicedocs-STR750FV1-86.html) and a through-hole adapter (http://www.futurlec.com/SMD_Adapters.shtml). 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.

Crawford
February 11th, 2010, 03:03 AM
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

cosam
February 11th, 2010, 04:41 AM
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.

Crawford
February 12th, 2010, 11:32 AM
Steve,

Using FAT as the container makes sense. I saw this a while ago http://hxc2001.free.fr/floppy_drive_emulator/index.html#SDCARDFloppyemulator . Even thought it is a floppy disk emulator, it works with an SD card, is read/write, and appears to work with disk images 'as-is'. The ability to drop disk images on an SD card, then just use them seems very nice.

-Crawford

pontus
February 12th, 2010, 01:33 PM
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 :)

cosam
February 19th, 2010, 01:40 PM
I got the uC in yesterday and the QFP adapter arrived today, so I had a crack at soldering them up. One thing to look out for is to ensure you don't nudge the pins when removing the excess solder. Just 1/4mm either way and the pin ends up between the pads and shorts to its neighbour. A quick wiggle with a pointed soldering iron tip is enough to fix that though. I also managed to lift a couple of traces on the adapter, but I should be able to bridge the gaps with a bit of Kynar wire. Except for that, three of the four sides check out fine. On the fourth I have a bunch of shorts. Looks like the solder got in behind the pins where the solder wick can't get at it. Adding more solder and starting again hasn't worked yet, so I'll probably tease out a few strands of wick and see if I can poke them through the gaps.

PDP11GY
March 1st, 2010, 11:19 PM
Hello,
Sounds very interesting your project. I already was on the think it over, too but I decided to realizie a RL02 Simulator which is much more complicated based on the serial and MFM de,-encoding protocoll. You may have a look to my home page ( pdp11gy.com ) . My recommendation: Forget all this wire-wrap stuff and use ARM-7 and FPGA environment. The MSCP protocoll is realtive easy ( comparing to the RL02 protocoll ) because you only have to deal with blocks and this can be realized based on a ARM-7 MCU with attached SD-Card reader. Details you will find on my home page, chapter 1. Good luck ... und forget the wire-wrap and soldering area ... this time realy is over.

cosam
March 2nd, 2010, 12:48 AM
My recommendation: Forget all this wire-wrap stuff and use ARM-7 and FPGA environment.
As much as I'd like to get up to speed on FPGAs, CPLDs and such, there's already enough to figure out in this project without adding teaching myself Verilog or VHDL to the equation. I am using an ARM7 uC though. The current prototype is all through-hole (except for the uC) on 0.1" stripboard with a good old rats nest of wires. It's only about 100 gates and the majority of those are buffers. If it works out, one could always bang out an FPGA equivalent. You're still left with the bus transceivers though, so there's always going to be something to solder.


The MSCP protocoll is realtive easy ( comparing to the RL02 protocoll ) because you only have to deal with blocks and this can be realized based on a ARM-7 MCU with attached SD-Card reader.
Yeah, the MSCP part isn't too hard; it's talking to the Qbus that's going to take some work. I'm pretty sure I've figured out the hardware part, which mainly boils down to which of signals you need to be able to drive in which situations (the bus transceivers have a common enable so you need to do everything in fours). The software involves wiggling about 40 different signals and getting the timing right. We'll see...

cosam
March 5th, 2010, 06:11 AM
It's a bit of a good news/bad news update this time. The good news is that I have the uC development environment all set up and working. It's based on the GNU tool chain, so you can use the likes of GNU ARM (http://www.gnuarm.com/) on Unix-like systems or Yagarto (http://www.yagarto.de/) on Windows. I'm using OpenOCD (http://openocd.berlios.de/web/) to program the uC via JTAG. I still need to further automate the flashing process and I haven't played with the debugger yet, but I have successfully run C code on the chip and all looks good.

The "bad" news is that the uC isn't going to be fast enough to interface directly to the QBus transceivers. There are some tight timing constraints which can only feasibly be met in hardware. The handshaking stuff for basic QBus reads and writes isn't too tricky, but DMA is going to require a dedicated controller and a bit of memory shared between this and the uC. A PIO-based prototype may be on the cards, but for DMA I'm maybe going to be biting the FPGA bullet a little earlier than I'd planned...

Crawford
March 5th, 2010, 11:22 AM
Steve,

Bummer that the ARM chip won't cut it.

Some FPGA options I've seen:

Altera - http://www.knjn.com/ShopBoards_RS232.html
Xilinx - http://www.sparkfun.com/commerce/product_info.php?products_id=8458

One (possible) good thing is that a FPGA design might offer a lot of flexibility for other peripherals at little extra cost: Serial I/O, VGA, PS/2 keyboard, etc).

But, I guess we should get the IDE interface working first...

-Crawford

dave_m
March 5th, 2010, 03:10 PM
... but DMA is going to require a dedicated controller and a bit of memory shared between this and the uC.
Steve,
I'm not sure how much data you need to buffer in RAM, but a simple device that may help is a First-In First-Out (FIFO) memory. Not much in the way of address control is needed except for the starting address which is setup before the burst transfer. Here is a spec sheet on a typical device:

http://focus.ti.com/lit/ds/symlink/sn74alvc7804.pdf

-Dave

cosam
March 5th, 2010, 03:52 PM
I'm not sure how much data you need to buffer in RAM, but a simple device that may help is a First-In First-Out (FIFO) memory. Not much in the way of address control is needed except for the starting address which is setup before the burst transfer.

Something like that could be just the ticket. Even if a block of data didn't fit, it could always be split into chunks with minimal housekeeping. One could even be as sneaky as to put the start address in the first word or two of the FIFO and have the DMA controller read it out... Thanks for the pointer!

PDP11GY
March 6th, 2010, 02:31 AM
Hello Steve,
Don't know exactly which MCU you are using, but normaly there is a PLL included which should be able to bring the MCU 4 times faster running. Concerning FIFO . that can be very simple realized via FPGA . I am using ALTERA MAXII and the MegaWizard Plug in manager included in Quartus II software. More details on my home page. Good luck and best regards, Reinhard

Crawford
March 8th, 2010, 09:10 AM
Steve,

I thought about this some more, and as Lou mentioned, the 'reference design' is the M7555 controller that used a T11 processor (16 bit PDP-11 type), that was certainly well under 20Mhz.

It seems that a modern 32-bit RISC would kick an old DEC microcontroller to the curb, and be more than enough to do this design, given what DEC did with the M7555.

If you don't mind me asking what was the exact issue with the timing using the ARM chip?

-Crawford

cosam
March 8th, 2010, 12:20 PM
Yes, the RQDX's processor runs at (I think) 7.5MHz but it doesn't control the QBus directly. The T11 handles the MSCP encoding/decoding and has a general supervisory role. The QBus end is handled by a bunch of logic which can meet the timing requirements. For example, a device must be able to reply within 8ns when addressed, otherwise a bus timeout will occur. If the reply is to a read operation, it then has 125ns to make the data available. A 60MHz ARM could probably handle the data transfer time if it didn't need to do anything else. In our case the uC could be busy doing all manner of other tasks and would need to be interrupted. The time allowed to respond would likely have elapsed before the uC even reaches it's interrupt handler.

If one were to handle the PIO QBus parts (i.e. the user addressable registers) in hardware it may be possible to do DMA under direct uC control, with a little supplementary logic to arrange bus mastership. Then again, if the amount of logic warrants the use of some kind of PLD, adding a (relatively) simple DMA controller would be more elegant and should provide better performance.

On that front, I'm actually getting to grips with Verilog much more quickly than I thought I would. I'll see if I can bang something workable out, even if it's not the most efficient or elegant design ever.

dave_m
March 22nd, 2010, 08:34 AM
Hi cosam,
I hope you have been following the issues of the XTIDE tech support thread in the vintage computer hardware topic. Proper soldering of fine pitch surface mount parts is not really for amateurs. With some training and good equipment, it can be done but most guys will just jump in and screw up the job and then complain about the 'bad design' (to you).

If SMD must be used, you should consider solutions like using ready made piggy-back boards or having a professional fab house produce the finished product. Unfortunately this will lead to higher costs.

Personally for home brew projects like this that will be built by people of unknown skill, I would use DIPs and give the builders a good chance at success. A board even chock full of obsolete PLDs DIPs would have a good chance at fab success and still allow fixes to be made without circuit board mods.

However the parts would have to be chosen carefully to make sure they are still widely available and that normal programming equipment can program them. That may not be an easy task. Just my two cents. Best of luck on your project. It is a noble thing for you do. And this coming from a Data General NOVA man! :)
-Dave

Sid76
August 11th, 2010, 10:41 PM
Recently, I've purchased IDE to SCSI adapter from ACARD.
I know that some people successfully use it on their VAX emulators.
I don't have the emulator but real peace of hardware based on
KA620 VAX running DEC's real-time VAXELN operating and Dilog's MQ759 SCSI controller.
Unfortunatelly, it's not plug-and-play (it works on PC WIN and Linux) like I hoped.

Does anybody have a similar configuration working?

Twylo
July 3rd, 2012, 02:13 PM
Sorry to revive yet another very old thread, but I only just stumbled across it.

With my recent acquisition of a couple Q-bus machines, I've become pretty interested in a project like this. My wish-list would include:


No special software drivers required (i.e., looks like a standard MSCP card at 17772150, uses the DU driver)
Uses commonly available, non-obsolete parts
Uses SD, CompactFlash, or USB sticks for storage


All of this is within the reach of hobbyist developers nowadays. Bus control can be implemented in a CPLD, storage management can be a simple microcontroller, development environment can be absolutely no-cost.

Using modern parts almost certainly dictates 1.8V or 3.3V for the CPLD, and that does complicate things because it means logic level shifting for the 5V bus lines, but that's the price you pay (there are lots of techniques for handling that, you just need to balance part count and cost with efficiency and ease of implementation).

There are quite a few sources for inspiration out there, too. I just found this, for example: http://www.mscpscsi.com/ Unfortunately no word on that page as to availability, and the page hasn't been updated since 2009 :(

Also look at the CFFA3000 (http://dreher.net/?s=projects/CFforAppleII&c=projects/CFforAppleII/main.php) project. Very nicely done.

I'd really like to see this happen. I think it's totally doable.

jackrubin
July 3rd, 2012, 03:29 PM
Once you tag yourself as "DEC and Commodore Enthusiast" we can take you more seriously! :>)

But - I'd like to see it happen but I can't do it. Can you? I'd expand the list of features to include a few alternate addresses as well, but otherwise, yes!

And don't forget the UNIBUS version.

Jack

Twylo
July 3rd, 2012, 03:41 PM
Once you tag yourself as "DEC and Commodore Enthusiast" we can take you more seriously! :>)

Heh! Well, at the moment all of my C64s and PETs are in my storage unit, and my PDP-11s are in my garage, workshop, and office. So I think that label fits pretty well right now! ;)


But - I'd like to see it happen but I can't do it. Can you? I'd expand the list of features to include a few alternate addresses as well, but otherwise, yes!

I think I can. I'm comfortable doing hardware design, VHDL or Verilog, and microcontroller programming. Free time, of course, is the limiting factor in any project :(

The one thing I hate doing most is reinventing the wheel. Any time I can use someone else's work or contribute to it, I much prefer that over original design! I hope cosam is still willing to share what he's done on his project.


And don't forget the UNIBUS version.

One thing at a time! :) I do have that 11/35 that needs storage, though...

-Twylo

PG31
July 10th, 2012, 10:40 AM
I think this is a great idea, SD cards are very cheap. Just wish I had the skills to design/build the project myself.

marmotking
November 13th, 2013, 12:28 PM
I want to vote for this project too, although I'm late to the party. Isn't DSSI also MSCP based? Could it or something similar be used to replace DSSI drives as well?

Crawford
November 27th, 2013, 05:34 AM
Folks,

Well it looks like someone has used a Raspberry Pi to do an MFM to SD card emuilator:
http://hackaday.com/2013/11/26/raspberry-pi-emulates-an-amiga-500-floppy-drive/

It's for an Amiga 500 AND emulates floppies, but still, it looks like it's 95% what we'd want...

tingo
November 29th, 2013, 12:35 PM
This one is even more interesting, he is using it for the TRS-80, and he is using SPI hardware to generate the clock and data signal (if I understood things correctly): http://virtualfloppy.blogspot.ca/
Forum thread: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=41&t=34143

marmotking
January 3rd, 2014, 02:04 PM
Oh, a unibus version would be great. Especially for the large early VAXen that I have to bring up. Although I'd vote for an ATA drive for that since I'm not sure that CF would be the best choice for a virtual memory intensive system like VMS...unless one wanted to do the work of wear leveling I'd be afraid that VMS would chew up a CF in an hour.

Al Kossow
January 3rd, 2014, 06:15 PM
Oh, a unibus version would be great.

Brad Parker seems to be the last person working on something like that

http://www.heeltoe.com/retro/udisk/

marmotking
January 3rd, 2014, 07:50 PM
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
January 4th, 2014, 01:59 PM
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.

Uniballer
May 2nd, 2014, 05:10 AM
Although I no longer have any DEC equipment, I am sympathetic to this problem.


Why not emulate an RK05?
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
May 2nd, 2014, 07:12 AM
IMO, MSCP would definitely be the way to go for both PDP-11 and MicroVAX.

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
May 2nd, 2014, 08:49 PM
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

Uniballer
May 3rd, 2014, 03:06 AM
This assumes you are going to run software that supported MSCP, and have a computer with an MSCP bootstrap.
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.


Depends on what you intend to do with the computer once it's running, of course.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).