Thoughts on Q-bus to CF/IDE

There has been alot of discussion, as well as some good (and not-so-good suggestions) with regards to the construction of a Q-bus to IDE interface. No doubt a good portion of it is from people in the field with the knowlege and experience to take on such a project. Being an end-user, I tend to look at things more from the standpoint of convenience, practicality, and feasability. We don't really need to know if it CAN be done, because we already know the answer. The REAL challenge is to design something that can be readily assembled without the need for very specialized or high-end equipment, and doesn't rely on obsolete or hard to find parts. After all, what is the point of designing something really cool, if it can't be easily reproduced by the average person, without spending tons of money? At that point, it's cheaper and easier to buy something that is already made. With that said, here are some things that would be important to me, when considering the design of such a device. I've heard on more than one occasion that MSCP isn't convenient to implement because of it's bad block replacement scheme, and that it would be easier to use an older emulation. For practicality purposes, that narrows it down to either MASSBUS (RM/RP), RK05/RK07, or RL01/RL02 emulation. To that end, my questions and suggestions are based on that premise. Note that some of these things are "easier said than done", but are nonetheless "something to think about". 1.) Construction Can it be easily assembled by someone with a modicum of technical skill, and resources? Some examples would be - Will the layout be relatively simple? i.e, can it be constructed on a a single or double-sided circuit board, rather than a multi-layer board? Can it be constructed with readily available parts? i.e., parts that aren't 20 years old, or hard to find? Will components be standard DIPS, or SMT? How easy will it be to get the firmware onto the prom? 2.) Ease of use How will you tell it what it needs to emulate? Obviously, a fixed emulation would be the easiest to implement. RM05, RP06, or whatever. One capacity, one prom. However, I don't think it's that much of a stretch to create selectable emulations via dip switches. Obviously NVRAM is nicer, but may add to the overall cost and complexity. 3.) Compatability Whatever the design, I'm sure most of us will agree that it should use STANDARD, unmodified DEC drivers for operation. From what I hear, RT11 drivers are a snap to create, but I personally dread the thought of trying to add an unproven driver into an operating system such as RSTS/E or RSX. I think from a compatability standpoint, we're better off trying to "pretend to be" something that is already supported across multiple platforms, and the source code for those drivers are readily available. Going further down the non-MSCP route, I had some thoughts on some of the basic implementation - A relatively SIMPLE design would yield something like this: Basic functions could be driven by a bank of seven dip switches. You'd have to pick ONE capacity, and stick with it. Three switches would be used to select the number of drives being emulated by the controller. (1 through 8) Four switches would be used to select the drive emulation. RM02/RM03/RM04/RM05 RP02/RP03/RP04/RP06/RP07 RK05/RK07 RL01/RL02 The controller would be forced as the first (primary controller) of it's type. Address and vectoring would be tied directly to the emulation switches, and it would set itself to the primary address and vectors automatically. Starting LUN is always ZERO. Are we an RL01? Then set our address to 17774400, vector 160. (And ignore bit 3 for the number of drives on the controller !) A more advanced approach would involve using NVRAM instead of switches. (Storing the parameters ON the drive could be used as well, as long as there was some sort of redundancy and recovery feature involved, in the event of a bad sector popping up in the parameters area.) If NVRAM or disk-based parameters were used, you could select your address and vectors manually. Additionally, this would allow you to mix-and-match some of the drive capacities, effectively allowing you to emulate two RM02's, and 3 RM05's, for example. Of course, you'd still have to stay within the same general emulation. Flexible drive sizes could cause problems down the road though, particularly if you want to change the size of a drive, when there are other emulations already on the disk. To get around this problem, a fixed partitioning scheme could be implemented, based on the maximum size drive for each emulation. Let's say you wanted RM emulation. An RM05 is the largest, at ~256MB. The firmware could be set to create 8 partitions of 256MB each. (Requiring a minimum of a 2.1GB drive). Each emulated drive would start at a fixed position on the disk, regardless of size, on 256MB boundaries. Then you could change/set the capacity of any of the units without affecting the others. In this instance, the drive type doesn't determine the starting position, only the amount of space being used by a particular unit. Later, if you decide you want drive #2 to be am RM03, you simply change it in NVRAM, and format it from your operating system. The space between the end of the RM03, and the 256MB boundary is simply ignored. A mixed RL01/RL02 emulation would work the same way; taking up ~40MB of space, regardless of drive type selected. Some other ideas: 40-pin header, and a CF card slot on the front edge of the board ! It might be trivial to implement RAID 1 (mirroring) on a 2nd (identical) hard drive set to "slave", particularly if we're looking at blind writes to disk. Any thoughts or suggestions? T