• Please review our updated Terms and Rules here

Rules for writing and executing downloadable code onto RQDX3 T11

Oldcoder

Member
Joined
Feb 28, 2021
Messages
49
Is anybody aware of any documents that give guidance on writing code for embedded T11 s such as on RQDX3 controller cards?

In particular I am looking for:
1) How to download code onto RQDX3 - checksums, execution addresses, handshaking
2) Any Interrupt rules - how long interrupts can be turned off on the T11.
3) Any source examples of such code, I understand that some of the XXDP modules download code onto the RQDX3 for the T11.
4) Commented source code for the RQDX3 embedded firmware.
I already have the standard DEC T11 OEM programmers guide - this details creating new T11 based standalone cards not reprogramming the RQDX3 and other controllers.

Thanks

Peter
 
Not that I am aware of.

Bitsavers has the standard RQDX3 User Manual - that defines the address areas that the ROM and RAM exist at - and hints at the I/O devices.

The schematics are available as well.

I would have thought you could work out the ROM start address from the T11 manual and the schematics.

The address decoding etc. is all done within a gate array - so a bit of 'playing' with firmware, test code and either an an oscilloscope or a logic analyser to identify the addresses of the I/O devices.

To my knowledge there is no disassembly of the firmware.

Dave
 
As far as I know, you cannot really download any significant amount of code to the RQDX3, if at all (I have not even seen any mention of such capabilities).
The normal firmware sits in a couple of 27256 PROMs (I think it's 27256, but it might be some other in he 27-series).
As such, you'll need to write your firmware, find a couple of blank proms and program them. Plug into the card, and run.

In general, there are no hard limits on how long you have interrupts off. But of course, response times might suffer, and you might also miss events if you disable interrupt for too long.
 
Isn’t it a major problem that there is a gate array about which very little is known as far as I understand.

The RQDX1 and RQDX2 used standard PROM memories, plenty of PAL chips and Am2942 chips instead. Could perhaps be easier to reverse engineer.
 
Isn’t it a major problem that there is a gate array about which very little is known as far as I understand.

The RQDX1 and RQDX2 used standard PROM memories, plenty of PAL chips and Am2942 chips instead. Could perhaps be easier to reverse engineer.

That might be a problem, but I would argue that more generally, not having proper documentation of the RQDX (any model) actual hardware is a bigger problem. The drawings can help some, but there are subtleties in here that will be hard to figure out.

And I am actually not aware of any XXDP diagnostics that would download any code into the RQDX, when I think about it. Most diagnostics are the same for all RQDX controllers, with the exception of the formatting, which more or less have to be different between the RQDX1/2 and the RQDX3, since they use different formatting on the physical disk, even when using the same actual disk.
But none of them would "download" any microcode. They are all either exercising the controller and/or disk, or formatting the disks. There aren't really any other kind of diagnostics. And formatting is the more controller specific functionality, for good reasons. The exercising diagnostics are the same for all RQDX controllers (and also the RUX controller).
 
Just to clarify,

I was hoping to download T11 PDP11 binary code to execute on the embedded T11 processor chip on the RQDX3 not change its microcode instruction set.

To change the way it configures the 9224 FM/MFM controller chip or failing that create some new ROMs based on the originals for the RQDX3.

My mistake, I thought that XXDP downloaded the formatting code onto the RQDX3 card. I have only used XXDP not seen the sources for it.

Peter
 
Just to clarify,

I was hoping to download T11 PDP11 binary code to execute on the embedded T11 processor chip on the RQDX3 not change its microcode instruction set.

To change the way it configures the 9224 FM/MFM controller chip or failing that create some new ROMs based on the originals for the RQDX3.

My mistake, I thought that XXDP downloaded the formatting code onto the RQDX3 card. I have only used XXDP not seen the sources for it.

Peter

Ok. Well, sadly I do not think it does anything like that, and the capability that you are hoping for does not exist, I think.
The RQDX1/2 have the different acceptable hard disk parameters in the rom image itself, which really limits which hard disks can be used with those controllers.
The RQDX3 instead stored various information about the disk on the disk itself, so that you could potentially use the controller with more different variants of hard disks. However, the formatting program then needs to know a bit more about different disk models, in order to create the actual meta-content on the disk while formatting.

In addition then, obviously, at formatting, the software need to be able to bypass the normal operation of the controller and have a more direct access path to the disk content. Especially for the RQDX3, since it has this meta-information on the disk, which is totally invisible to software during normal operation.

The type of parameters I'm talking about here are: sectors per track, tracks per cylinder, interleave to use, skew to use, location and handling of bad block replacements (remember, MSCP always presents error free media), serial numbers. There might be more things that I'm not remembering now. And for the RQDX1/2, things like sectors per track and such physical properties of the disk are stored in tables inside the controller firmware instead.
 
In addition then, obviously, at formatting, the software need to be able to bypass the normal operation of the controller and have a more direct access path to the disk content. Especially for the RQDX3, since it has this meta-information on the disk, which is totally invisible to software during normal operation.

If memory serves, you can't actually format a drive with the RQDXx controllers, for example taking a Maxtor XT-2190 and turning it into an RD54. The VAXStation 2000's embedded controller does have the requisite firmware.

CW
 
If memory serves, you can't actually format a drive with the RQDXx controllers, for example taking a Maxtor XT-2190 and turning it into an RD54. The VAXStation 2000's embedded controller does have the requisite firmware.

CW

Well, first of all, the RQDX1 and RQDX2 are not compatible in the on-disk format with the RQDX3 or the VAXStation, or any other controller. So there is no way to move an RD53 from qn RQDX1 to an RQDX3, or to a VAXstation 2000, or the other way around.

Second, what you write is not entirely true, but for a long time, the VAXstation was the only customer equipment available that had this capability. Internally at DEC, they had more tools to do this, including variants running under XXDP or whatnot. But they were carefully kept away from customers.

Third, we also need to clarify what we mean by formatting. If we talk about actual low level formatting, I don't know if the VAXstation does it, and I don't know if the RQDX3 does it. They might just be writing the meta-data needed for the controller to then be able to use the disk.
 
If memory serves, you can't actually format a drive with the RQDXx controllers, for example taking a Maxtor XT-2190 and turning it into an RD54. The VAXStation 2000's embedded controller does have the requisite firmware.

CW

Not sure about RX50 or other floppy disks but RQDX3 under XXDP will low level format an ST277 (60 Mb RLL) drive into the equivalent of an ST251 (40 Mb MFM) drive.

RQDX3 Controller User Guide Ch 3, gives details for reformatting a Harddisk on RQDX3 using XXDP module ZRQC??.

There is a copy on Bit-Savers

Peter
 
Last edited:
Please look at my post requesting information on DUP protocol.

The RQDX3 Controller user Guide lists 2 DUP functions implemented on RQDX3:

Execute local program - runs a program stored in ROM.
Execute supplied program - loads a program into RAM and starts executing it.

But provides no further information.

There is 8 KW of RAM and 16 KW or ROM.


Peter
 
Well, as I said in the other thread (do we now have three threads about this same topic?), DUP documentation was never properly released, and even if you were to figure that bit out, you are still stuck with the problem that you don't know how to write anything that would run on the RQDX3.
 
If memory serves, you can't actually format a drive with the RQDXx controllers, for example taking a Maxtor XT-2190 and turning it into an RD54. The VAXStation 2000's embedded controller does have the requisite firmware.
If you mean the controller cannot format a drive without assistance from a utility program, you are correct. However, XXDP includes a utility (ZRQC?? IIRC) to format the drive. In customer mode it only knows about officially-released DEC drives*. If you ask for "extended commands" or something like that, it asks you for the normal CHS parameters and then more cryptic things like "Number of XBNs?" The controller and OS driver (remember, the Q-bus MSCP controllers are host-initiated bad block replacement, so the OS driver needs to know some gory details) handle bad block replacement and make some assumptions which you can violate with your custom format parameters. You are correct that the VAXstations have the "warm and fuzzy" format program in their console ROM. But bear in mind that VAXstation console ROMs can approach (or exceed) the total 4MB addressable memory of a PDP-11.

* Terry's Trivia Time again (maybe I should trademark that): The ZRQC formatter asks you what kind of drive you have which is straightforward except for the RD52, which asks the rather cryptic question "1 or 2 LEDs". That's because of the RD52 saga, which I was involved with to a great extent. The RD52 was supposed to be an Evotek ET-5540 and DEC signed a high volume OEM purchase with Evotek - in fact, they were the only customer that committed to buying more Evotek drives than my company did. The Evotek was an incredibly elegant design (the company was started by some ex-IBM engineers that worked on the 3380 and follow-on drives) that was thoroughly permeated by problems. It was a "design too far" like the DCJ11 was for DEC. The goal was to produce a stepper-motor drive with the speed of a voice coil actuator but the cost of a stepper motor actuator. Unfortunately, Evotek had no shipping product to keep them funded during the over-extended development. In no particular order, some of the problems were:
  • The drive took the 5.25" form factor spec literally. It was just at the maximum allowable dimension in every possible way. In many chassis it wouldn't fit at all. In most of the others, you had to remove the drive's faceplate and then put it back on once the drive was in the case.
  • The drive had a dynamic spindle brake (a solenoid with a piece of cork on the end that rubbed on the spindle). The brake's default state was applied, with power-on retracting it. Unfortunately, the connector for the brake was a 2-pin .1" part right at the corner of the drive, meaning that when a customer installed the drive, there was a pretty good chance of dislodging the connector. That meant that instead of spinning up when powered on, the customer was greeted with the smell and smoke of the spindle motor hybrid sacrificing itself.
  • The drive suffered from jitter at the end of seeks. A workaround was to delay I/O for several ms after a seek if the operation was a write, to prevent off-track writes, and to retry without reporting an error if the operation was a read, both to give the heads time to settle down. The solution to this was to "stiffen" the head carriage assembly. That is an excellent idea, unfortunately the implementation was a disaster. The solution was to place a 4-prong plastic clip on the external post of the stepper motor, with a spring squeezing those prongs against the stepper motor shaft to increase drag. This had the side effect of making it much harder to drive the stepper motor. The hybrid that drove the stepper was from the same manufacturer (has a "T" and an "X" in the name and was a specialist in mixed-signal hybrids, but this problem wasn't their fault) as the spindle motor hybrid. The stepper hybrid worked a lot harder because it had to produce continuously changing outputs. The incoming inspection failure ratio was around 50% and the on-board failure rate brought that up to around 90% once the seek stiffener clip was added.
  • The heads would be dislodged when the drive was shipped, causing media and head damage. The solution to that was to place a T-shaped piece of plastic (bright red, with "Remove before use" illegibly molded into the plastic) with a rubber pad on the back that pressed against the stepper motor. We called these the "magic mushrooms". They solved the immediate problem, but customers often forgot to remove the magic mushroom before installing the drive, causing the stepper hybrid to burn out.
This nonsense went on for the better part of a year, despite my efforts (and presumably DEC's) to straighten things out. We got so sick of them sending us dud pre-production units that it got to the point that I had to fly out to Fremont and test / inspect each drive before bringing it back with me on the return flight.

Eventually their investors told them to ship drives in any condition (similar to CMI hard drives in the IBM PC) or the plug would be pulled. Specifically, "No more redesigns!". I was out there when that edict came down. I asked one of the designers why they chose these expensive, unreliable (in this application) hybrids and Tom said it was because they'd used them at IBM. Of course, IBM has whole teams intended to make designs manufacturable and repairable, which Evotek didn't. I said "Why not use sets of Darlington drivers?" and you could practically see the light bulb over his head light up. We midnight-engineered (literally) a new PCB with a 6821 (IIRC) and 3 dual Darlington arrays (which collectively took up less PCB space than the hybrid they replaced) that also moved the spindle brake solenoid connector to a more protected location. I took advantage of the space savings to add some other goodies, like making the activity LED dual-color so it would be obvious if it was blinking a fault pattern or just indicating activity. We got some drives that were close to the original specification (they missed a little bit on the seek time because of the stabilizer clip) and still had the problem of needing to ship with the "magic mushroom", but were otherwise very good drives. But by then it was too little, too late and Evotek was closed down and the sputtered media part of the company was sold to someone else.

This left DEC scrambling for a 40GB drive because in the OEM game of musical chairs, if you're late to the party you're often left standing without drives. DEC signed a last-minute deal with Quantum for their Q540 drive to be used as the RD52, but Quantum didn't have enough spare production capacity to fill those orders. So DEC bit the bullet and signed another deal with Atasi for their 3046 drive. It had a bit more capacity (hidden when formatted as an RD52) and was a lot more expensive. As far as I know, it was also the only ST506-interface drive to ever use a linear voice coil for the head actuator (rotary voice coils eventually took over from stepper motors).

The Quantum Q540 has a single LED. The Atasi 3046 has 2. That's why the DEC format utility asks.
 
So DEC bit the bullet and signed another deal with Atasi for their 3046 drive. It had a bit more capacity (hidden when formatted as an RD52) and was a lot more expensive. As far as I know, it was also the only ST506-interface drive to ever use a linear voice coil for the head actuator (rotary voice coils eventually took over from stepper motors).

Seagate did as well. Compare the ST-4051 circuit layout with the 3046 and you'll see some interesting similarities.
 
Seagate did as well. Compare the ST-4051 circuit layout with the 3046 and you'll see some interesting similarities.
Interesting is an interesting way to describe it. ;)

Seagate tried buying Atasi in 1983 but that fell through. Atasi sued Seagate for patent infringement (oddly, most of the court records I found were of Seagate objecting to Atasi's law firm). Eventually Atasi went to Tandon (IIRC) and that went to WD (likewise).
 
Back
Top