• Please review our updated Terms and Rules here

Replacement firmware or downloadable code for RQDX3 to support FM RX01

Terry Kennedy said:
The other possibility is Whitesmith's C. PDP-11 C didn't come along until later (too little, too late).
Click to expand...

Yeah. And I haven't ever used Whitesmith's. But maybe you know - did Whitesmith's used psects named c$data and c$code, and at function enter you'd do a jsr r5,csv$, and function exit is through jmp cret$?
Because that's what is in the RQDX3 MACRO code, and that matches exactly what DECUS C looks like.
 
bqt said:
Yeah. And I haven't ever used Whitesmith's. But maybe you know - did Whitesmith's used psects named c$data and c$code, and at function enter you'd do a jsr r5,csv$, and function exit is through jmp cret$?
Because that's what is in the RQDX3 MACRO code, and that matches exactly what DECUS C looks like.
Click to expand...
I don't know. At Lifeboat we sold it, but all support calls were routed to Whitesmith. We did sell and support the CP/M version, but that was obviously very different.
 
Terry Kennedy said:
I don't know. At Lifeboat we sold it, but all support calls were routed to Whitesmith. We did sell and support the CP/M version, but that was obviously very different.
Click to expand...

Well. I think it's a fairly safe bet that it is DECUS C. In addition to these and a few more things, which strongly seems to suggest that it's DECUS C, it also stands to reason that DEC people might start by looking what is available and close to home when they wanted a C compiler. DECUS would be an obvious place to start looking.
I know they certainly looked at DECUS C as an option when they started working on PDP-11 C, but discarded the idea of basing PDP-11 C on DECUS C.
 
Does someone know what MSCP Opcode 24. (decimal) is? This exists in the newest ROM but not in the Source code.
 
cbscpe said:
Does someone know what MSCP Opcode 24. (decimal) is? This exists in the newest ROM but not in the Source code.
Click to expand...

Weird thing. In the RQDX3 code, op_fmt is defined as 47 (39 decimal). Which is the function to format RX33 floppies.
But in the RSX sources, OP.FMT is 24 decimal. I would suspect it is the function for formatting RX33 floppies. The RQDX3 sources either used some old, or erroneous definition.
 
I have now a first version of the disassembled binaries of the newest RQDX3 ROMs 23-339E5.bin and 23-340E5.bin. I managed to convert the addresses of all sub-routine calls to labels and matched them to the source code provided by Al. I also made section that indicates the source file that corresponds to the disassembled section. There are two exceptions, one is the local DUP program FORMAT at address 063574(8) and the C-Library Routines (except CSV$ and CRET$).

There are many similarities between the ROMs and the source code however there are also some important differences.
  1. The power-up initialisation section is much more elaborate and does a lot things more than the source code
  2. both OPCODEs, 39(10) and 24(10) mentioned in the RSX source point in fact to the same module dofmt.c (the RX33 formatting)
  3. dodte previously used in the source code is no longer referenced in the binary and is repalced by dohbe
  4. the core module opsys.mac has a new OS function which I called $setpriority which de-queues the current task, sets the priority of the task and then en-queues the task again into the runjob list. In case a task lowers it's own priority to a value lower then the priority of another task in the runjob list a context switch will take place
Thanks for the DECUS C link, I will give it a try to compile the source code. Next thing would be to replace the numbers with the true symbols, especially for the offsets and add some local labels and convert the branches and jumps to use these.
 
With regards to DECUS C, be aware that they were using something from 1983 or so, while the link I provided is for a version that have had various updates since then. I wouldn't expect big differences, but there might be a thing or two slightly changed that could cause issues.
 
That won't be a problem, the goal is not to be able to recompile the complete source to get a new binary. It's rather to understand how things work together and to convert and adapt the source to my hardware. It's also interesting to see how the PDP-11 side is interacting with the controller. As it seems there is no direct interaction via the device registers. For example when the host writes to the SA or IP register then the QBUS cycle is executed without interaction of the RQDX software, it just deposits the datum in an internal register of the ASIC and rises an interrupt. Then the rest is handled at normal process level and handshaking takes place with messages. The device register part is different to what I thought it would be. In fact this gives me more freedom in regards of my solution as this makes the part of my firmware that interacts with the QBUS cycles much simpler.

I did some preliminary tests with C Code samples and it worked, although TKB emitted a bunch if DIAG warnings regarding sections being defined multiple times. So there is still something to look at, but the task is still built and can be run. Next is to setup a disk image for simh as a development environment.
 
cbscpe said:
That won't be a problem, the goal is not to be able to recompile the complete source to get a new binary. It's rather to understand how things work together and to convert and adapt the source to my hardware. It's also interesting to see how the PDP-11 side is interacting with the controller. As it seems there is no direct interaction via the device registers. For example when the host writes to the SA or IP register then the QBUS cycle is executed without interaction of the RQDX software, it just deposits the datum in an internal register of the ASIC and rises an interrupt. Then the rest is handled at normal process level and handshaking takes place with messages. The device register part is different to what I thought it would be. In fact this gives me more freedom in regards of my solution as this makes the part of my firmware that interacts with the QBUS cycles much simpler.

I did some preliminary tests with C Code samples and it worked, although TKB emitted a bunch if DIAG warnings regarding sections being defined multiple times. So there is still something to look at, but the task is still built and can be run. Next is to setup a disk image for simh as a development environment.
Click to expand...

Yes, that is one point of MSCP. All communication is done through the ring buffers and the concept of ownership of entries in there. This is rather different from more traditional controllers. The CSR is only used at initialization, and then just poked to wake up the controller.

As for TKB. If you are just taking all the current RQDX3 sources and compiling them, I am not surprised. The c$data and c$code sections have different attributes in current DECUS C compared to what was the case in 1983. Which cause a conflict when looking at the MACRO-11 sources. Basically, you should declare the c$code psects as I,RO, and the c$data ones as D,RW
I think that is all, but you can check by just looking at the generated code from XCC to make sure.
 
Any idea which hardware register could be the address 160110, it is not defined or referenced in the source code but it is referenced quite often in the new power-up routine of the newest version of the RQDX3 controller firmware
 
Just thinking aloud here...

1. The I/O area is only partially decoded - meaning that addresses 160110 and 160210 actually refer to the same device.

2. The addresses from 160200 upwards appear to be w$... Just wondering whether 160100 could be r$... of the write equivalents.

Is the context in which your unidentified addresses are used reads or writes out of interest?

Could you post a section of the new code for us to look at?

Dave
 
Im curios what the cards really were in this lot. In the meantime I have done a bit more reverse-engineering of the RQDX3 firmware. I have updated the file at the link I have given above. Perhaps someone can use it.

The format is somewhat special as it maintains the original octal values of the disassembly as a reference. The file itself can be assembled using macro11 when first stripping these unnecessary columns using for example expand and cut

Code: 
expand -t 8 ~/rqdx3/rqdx3.das | cut -c 33-132 > rqdx3.mac
./macro11 rqdx3.mac -e lsb -l rqdx3.lst -ysl 6

I have modifed the labels so that now they are significant within the first 6 characters. The expanded and cut source assembles as well with the real MACRO-11 when copying the file to RSX-11Mplus.

For the moment I will abandon the reverse engineering as I have found enough hints that are useful for my own MSCP emulator, which of course is still work in progress, although progress is a little bit slow for the moment.
 
I responded to the problem with the MTI cards being 22M (5" drive) versions on twitter.
Hopefully they won't require a microcode prom change to work with 8" drives
Pics of the 21 and 22 are up under http://bitsavers.org/pdf/microTechnology

I also put up 21/22 and 22M brochures and the pictures are clear enough that you can
see that the 22 and 22M both have the same microcode proms on on them (1021-1027)
 
Last edited:
  • Like
Reactions: erd
Al Kossow said:
I responded to the problem with the MTI cards being 22M (5" drive) versions on twitter.
Click to expand...

Ah... I was unaware of the 22M before. What an odd product - I guess if you want to save cabinet space and money on drives and media, it makes sense, but you obviously lose the ability to read/write/exchange data with "standard" machines.
 
You must log in or register to reply here.
Back
Top