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

[cosam]

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 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]

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]

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]

QBus - IDE

QBus - IDE

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]

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]

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]

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]

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]

Hi Pontus,

Thought you might be interested - good to have you aboard! You might also be interested in looking at the SIMH sources, which the designer of this homebrew SCSI adapter used as a basis for the software. Some code was also borrowed from BSD Unix, which can be found on the PUPS archive. There's also a nice description of MSCP on bitsavers (/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]

Any thoughts about an Omnibus interface for us 12-bit laggards?

 

[Lou - N2MIY]

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]

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]

Hi Pontus,

Thought you might be interested - good to have you aboard! You might also be interested in looking at the SIMH sources, which the designer of this homebrew SCSI adapter used as a basis for the software. Some code was also borrowed from BSD Unix, which can be found on the PUPS archive. There's also a nice description of MSCP on bitsavers (/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]

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]

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]

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]

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]

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]

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]

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.



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.