• Please review our updated Terms and Rules here

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

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.
 
My recommendation

My recommendation

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.
 
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...
 
Update

Update

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 on Unix-like systems or Yagarto on Windows. I'm using OpenOCD 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...
 
... 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
 
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!
 
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
 
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
 
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.
 
surface mount soldering

surface mount soldering

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
 
Last edited:
Using the ACARD IDE->SCSI adapter card

Using the ACARD IDE->SCSI adapter card

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?
 
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 project. Very nicely done.

I'd really like to see this happen. I think it's totally doable.
 
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
 
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
 
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?
 
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.
 
Back
Top