• Please review our updated Terms and Rules here

Replacement firmware or downloadable code for RQDX3 to support FM RX01

Hunta said:
PDP-11/23 - KDF11-A
PDP-11/23+ - KDF11-B

KDF11-A rev A support 18 bits
KDF11-A rev C and later support 22 bits
I have two KDF11-A and they can work with 4088 kb of memory

KDF11-B support 22 bits
Click to expand...

The distinction between 11/23 and 11/23+ is not purely which CPU board or revision. It's also which backplane, where an 11/23 only have an 18-bit address backplane.
So it's still a case of an 11/23 is 18-bit, while the 11/23+ is the 22-bit system.
 
Terry Kennedy said:
Does the 9224 have an onboard data separator? If not, the external data separator circuitry may not support / be configurable to handle FM.
Click to expand...

Terry,

SMC line up is 9224 Universal Disk controller
9226 Hard disk MFM data separator
9216 Floppy Disk FM & MFM data separator.

But looking at the RQDX3 schmatic, it only uses the 9224 UDC plus a discrete PLL.
 
Chuck(G) said:
Don't think I follow--there are a few codes in the 177x and 179x that can write specific AMs with missing clock bits, but they're fairly restricted. The 1781 is the exception, but it's a "roll your own decoder/encoder" chip and not very common. My WD databook from 1984 doesn't even cover the 1781. It was a bit buggy and not popular. Among it's other "interesting" capabilities was the alternate interpretation of the "N" byte in CHRN address headers. You could have a disk with 64 byte sectors, for example.
Click to expand...
I may be misremembering or have a bit-flip error somewhere.
 
Oldcoder said:
SMC line up is 9224 Universal Disk controller
9226 Hard disk MFM data separator
9216 Floppy Disk FM & MFM data separator.

But looking at the RQDX3 schmatic, it only uses the 9224 UDC plus a discrete PLL.
Click to expand...
That would seem to make the whole thing academic if there's no FM data separator on the board.
 
bqt said:
The distinction between 11/23 and 11/23+ is not purely which CPU board or revision.
Click to expand...

From RESORC sources

Code: 
;+
; ** PDP 11/23 and PDP 11/23 PLUS **
;-
.ASSUME PDP.23 EQ PDP.24+1
10$: INC R1                     ;Assume an 11/23.
        MOV #11$,R5             ;If we trap, then it is an 11/23.
        BIT #100,@#LKS          ;RT-11 has the clock on.
        BEQ 11$                 ;If 0 or we trap, its an 11/23.
        BIT #40,@#LKS           ;Is the clock from an MXV-11B LCCR?
        BNE 11$                 ;Yes, then it isn't an 11/23 plus!
        MOV #PLUS.23,R1         ;Clock is 1 so its an 11/23 plus.
11$: MOV R1,R0                  ;General return, put type into R0.
        RETURN                  ;Go return to the caller.
From RESORC point of view, 11/23 has not line clock CSR on CPU board at all (only on external board, for example - MXV11-B) - KDF11-A, but 11/23+ has - KDF11-B

I do not know if PDP-11/23 was released with a 22-bit backplane, but KDF11-A were both 18-bit and 22-bit. And because - it is possible that there were also PDP-11/23 with a 22-bit backplane.But for now - it is only possible.
 
Grab a systems handbook instead, which includes both the 11/23 and 11/23+. The difference from a system point of view is addressing size. Code tries to detect what system it is, the code is not the definition of the system.

Code sometimes needs to do very weird things to tell what model it believes it is. A label at the front of the cabinet simply tells because that is what was put together at manufacturing. The label in general is correct. The code, if it disagrees, simply failed to figure it out correctly.

One of my favorite tricks is (should be 11/73 vs. 11/83) where some detection code simply runs three NOPs, and then check the cache hit register to see if you have Qbus memory or PMI memory. It got to be some variant of the KDJ11B, since that's the only one with PMI memory. Tricky way to differentiate between the PMI memory being placed before or after the CPU actually. Which would make it an 11/73 or 11/83. You can't just check the CSRs of the memory, since they are the same. And CPU board *might* be the same (but don't have to be).

But for manufacturing, no trickery was needed. It was very clear if it was an 11/73 or 11/83 from their point of view.
 
Thanks. Very cool, just had a short look into it and found that this even has a lot of comments. This will definitively help to reanimate my MSCP controller project. Provided I find time.
 
As far as I know, DEC was the only vendor to do this.

Chuck, Also my DATAPOINT 1800 uses this RX02 pre format.
Sadly they only made a initialize and DOSGEN software to transfer a RX01 to a RX02 mixed type floppy.
Never a Format. I know this from the developers them selves.So have to use Pre-Format RX02.
The 1800 it self can not read RX01 type, there should be software, I have not.

C.10.2 Size of a diskette (Datapoint 1800)
there are 77 tracks each contains 13 256 byte sectors (physically 26 128 byte sectors).
First track is not used to help provide compatibility with IBM equipment, additionally the logical last sector on each track (sector 12 counts from 0) is not used by DOS.C

RQDX3 I manage to build in to my PDP1123 with 2x ST225's
RX33 I used a TEAC FD-55GFR, just fiddle with the jumpers.
Can't find at the moment the info to build, but Line-Time-Clock and 18/22 Bit can be done at the back plane PDP11/23.

The build, Its in Dutch but pict's will tell enough.
http://www.transistorforum.nl/forum/index.php?id=48087

As to use RX01 with RQDX3 may me look into the Imagedisk Software?
That uses a 1,2MB settings also and can convert to 77 track SD (RX01).

As in a PC a 1,2MB drive can read/write a 360k disk, should PDP11 also I think read RX01 in RX02 mode.
The RX02 drive it self you have to physical strap it to RX01 but may be with RQDX3
and a software convert like they did with Imagedisk you could think of that.

May be just an address redirect from RX02 to RX33 in the RT11 software?
So PDP thinks it is talking to RX02 controller but in fact its the RQDX3?

Info:
Digital Equipment Corp. RX01 [7]

SS/SD, soft sectored 77 tracks, 26 sectors per track, 2002 sectors per diskette, 128 bytes per sector
capacity 256,256 bytes
48 tracks per inch
bit density 3200 bits/inch at inner track
 
What is the actual goal of running your own code in the RQDX3? Just being able to read and write RX01/RX02 disks would be much easier with a standard 8" Floppy Drive and a 3rd party controller that emulates a RXV11 or RXV21. Most of these 3rd party controllers even had a formatter routine (somehow hidden).
 
I should point out that if we talk about real RX02 floppies, there are no problem at all formatting them. They are standard SS/SD formatted. So, just RX01 formatted. Which is the standard IBM format. However, I don't believe the RX01 can reformat any random floppy to SS/SD, so you need that format already on the drive.

For use as an RX02, the drive can flip between RX01 and RX02 mode on a floppy at any time. There is nothing special, or extra needed to get into RX02 format.

And people seem to continue thinking that hooking any 8" floppy to an RQDX3 would be somewhat easy. I'll believe that when I actually see it. This is not a PC!
 
bqt said:
And people seem to continue thinking that hooking any 8" floppy to an RQDX3 would be somewhat easy. I'll believe that when I actually see it. This is not a PC!
Click to expand...

You've got the sources now, so the guy who started this can knock himself out. RX01 single-sided format will be possible, RX02 will not using the hardware
on the board, assuming you can get the controller set up to use a 500KHz clock.

If it were me, I'd just find a dual-wide RX02 clone controller and be done with it.
 
Thanks for posting that Al.

I am tempted now to add an RS232 buffer to the J1 'panel' interface (using a drive select signal as the transmit and a drive ready signal as the receive) and turning the RQDX3 into a small computer by 'bit banging' the serial lines.

It seems to have everything you need, ROM, RAM, a disk controller (which you can still use with the bit-banged RS232 serial port if you are careful) and a timer...

Unfortunately, I don't have the time!

Dave
 
Al Kossow said:
You've got the sources now, so the guy who started this can knock himself out. RX01 single-sided format will be possible, RX02 will not using the hardware
on the board, assuming you can get the controller set up to use a 500KHz clock.

If it were me, I'd just find a dual-wide RX02 clone controller and be done with it.
Click to expand...

All depende on the definition of "possible". Sure, connecting the cable, and theoretically getting the controller itself to extract bytes is possible. But doing that through some application downloaded over DUP remains to be seen. I strongly doubt it. Of course, if you rewrite the whole microcode then you're getting closer to making it happen, but you still have the problem that any PDP-11 software will not expect an RX01 on a RQDX3. And yes, RX02 is still totally out of the question.

I would definitely go for locating a clone controller.
 
Al Kossow said:
You've got the sources now, so the guy who started this can knock himself out.
Click to expand...

I spent some time reading the source code. The source is really very nicely written, and has a lot of comments. And it does not exceed my level of understanding C :). The only thing missing is a make file or some sort of script how to compile and taskbuild it. And most likely a DCT11 specific header file (I could not find any definition of t$power, I assume that is the power-up address used for the T11 on the RQDX3). It would be interesting to be able to compile and link it. But definitively not to be able to add RX01 support. That's much better done with a clone controller as you said.
 
I also only now looked a little at the sources. Very interesting.

I sent a couple of comments on the simh mailing list, but through I'd post them here as well.

Two observations:
1. Interesting that it is done in C. I didn't actually expect that.
2. It strongly looks like it was done in DECUS C. Also unexpected. (Although, if you wanted C on a PDP-11 back then, there weren't that many options available. And DECUS C isn't half bad, if you just accept primitive K&R.)

Does anyone know anything more about the story behind this? DEC was fond of BLISS, and there certainly was BLISS that targeted the PDP-11. Some parts of RSX is written in BLISS.
 
bqt said:
Does anyone know anything more about the story behind this? DEC was fond of BLISS, and there certainly was BLISS that targeted the PDP-11. Some parts of RSX is written in BLISS.
Click to expand...
The only information I'm aware of is Digital Technical Journal No. 2, March 1986, pp 66-74 "The RQDX3 Design Project" and all is says is "The microprocessor should be able to be programmed in a high-level language. Much of the code for this module would be written in the C programming language."
 
Al Kossow said:
You've got the sources now, ...
Click to expand...

Do you know if they are complete and to which ROM version they match? And do you know which Compiler should be used and are there some build instructions.
Also there are labels that are used and I cannot find, like the already mention t$power and there is also a reference to the local dup program "FORMAT", so I assume there should be
a corresonding module.

At the moment I'm comparing the source code against the disassembly of the ROM Images 23-339E5.bin and 23-340E5.bin. So far I could match quite a lot.

Don't get the wrong idea, I don't want to modify the code (although it should be straightforward now when using the ROM disassembly) it's just to learn about MSCP as
a preparation for my MSCP controller.
 
cbscpe said:
Do you know if they are complete and to which ROM version they match? And do you know which Compiler should be used and are there some build instructions.
Also there are labels that are used and I cannot find, like the already mention t$power and there is also a reference to the local dup program "FORMAT", so I assume there should be
a corresonding module.

At the moment I'm comparing the source code against the disassembly of the ROM Images 23-339E5.bin and 23-340E5.bin. So far I could match quite a lot.

Don't get the wrong idea, I don't want to modify the code (although it should be straightforward now when using the ROM disassembly) it's just to learn about MSCP as
a preparation for my MSCP controller.
Click to expand...

The C parts are most likely compiled with DECUS C. The assembler parts with MACRO-11.
 
You must log in or register to reply here.
Back
Top