RX8E / RX28 Technical Question

[BitWiz]

I'm trying to determine the purpose of the Density bit on the RX28 (M8357) Load Command Instruction (67X1)

Bit 03 is the density bit. However, I cannot see this bit used on either the RX8E or Roland's M8357R schematic anywhere and looking at the connections going to the RX02 drive itself, there is no density signal.

It is my impression that you select RX01 (single density) or RX02 (double density) with a dip switch on the controller board in the drive itself.

Am I wrong or just crazy?

 

[vrs42]

I think that the density bit (as well as the other command bits) are latched from the DATA bus into the shift register, and are sent to the controller inside the floppy drive to do their magic. Likewise, values read onto the data bus by status/input IOTs are shifted in a bit at a time from the controller.

I have not looked at the state machine inside the controller to see how any of the functions are implemented.

Vince

 

[BitWiz]

Does that mean that there is no difference between the RX8E and RX28 controllers except for the name?

Thanks

 

[Roland Huisman]

yes the controllers are identical.

The combination from a RX01 and a M8357 is called RX8E
The combination from a RX02 and a M8357 is called RX28

 

[AK6DN]

Roland and Vince are 100% correct in their replies.
There is only one physical M8357 board, called RX8E or RX28 depending on attached drive.

The 'density' bit in the CSR is used by the drive controller software to select SD/DD mode in operating on sector data; the M8357 card does not care.
The drive firmware is responsible for transferring the correct number of data bytes.

Strangely though, 8b/12b mode, and DMA/PROGIO mode, have physical wires in the interface for those selections.
They could have easily been made bits in the CSR function (actually 8b/12b already does) and passed to the drive controller in the same way.
But they weren't, and I can't see any reason why that had to be separate wires. Except 'DEC'.

 

[BitWiz]

The main reason for my question is the RX02 technical manual has two different sections for the RX8E and the RX28 and separate code for each.

One additional question. For OS/8 can the RX02 driver read single density disks or do I need to have two OS/8 builds, one for single density and one for double density?

 

[vrs42]

One additional question. For OS/8 can the RX02 driver read single density disks or do I need to have two OS/8 builds, one for single density and one for double density?

I have recommended elsewhere that folks trying to get OS/8 working on RX02 reconsider, or at least be very careful. The drivers for V3D and other common OS/8 versions are absolutely *not* compatible. If you insert them and try to boot them in an RX02 drive that doesn't have the internal switch set to RX01 compatibility, you will likely corrupt your boot media.

This is because bits that should have been reserved weren't, to save code space. So the single density bootstrap will leave bits set that do nasty things when interpreted by an RX02.

Likewise, the OS/8 system device driver. This means it is not even safe to use the RX28 bootstrap code to boot your average OS/8 single density media in an RX02.

Newer versions of the drivers exist, and it is (just) possible to upgrade an OS/8 configuration with the new drivers, then use the RX28 bootstrap (exclusively) to boot single density or double density media. But it is a pain.

I do not recall offhand whether the new system drivers can handle both media types, but I suspect not. That may be a non-system device feature. (Which means, to answer the original question, two builds may still be required.)

Vince

 

[MauriceH]

As I have a lack of a RX01 drive, I am in project (Just starting) to hook up a SA801 (in SA800 mode, 801 is a 32sec hardsector) and so was looking at the signalling
between M7744 the processor of the RX02 and the , say, drive it self M7745.
I have a spare M7744 RX02 CPU.
There you find the "DRV READ 2F L", "DRIVE LOCK CLK H" , those lines I can not transfer to the SA800 (or any other common).
Those 2 lines are from cpu to the RX02 drive R/W logic in a RX02 unit.
Think those lines are that FM2M needed coding.
And have to be constant switching to read/write at sector level.

The RX02 mode is not compatible with other standard drives since the headers are always in single density mode but the data is written in double density mode.
In double density mode the standard MFM encoding was modified from the standard to prevent false header detection in data.

So in my conclusion it is the CPU M7744 that at 1 point decide to read or write in RX01 or RX02 mode.
The CPU in the RX02 handles in my opinion the format, and that is why you can not use directly any common drive to a DEC system.
As a part of the control logic is in the drive , M7744 cpu, and not as f.i. an IBM system all on the drivercard in the computer.
As I see it the M8357 + M7744 together has to be seen as a "normal" say MFM Harddisk card PC like.
M7745 + mechanic is to be seen as a "normal" floppy drive.

TS his question were to look for that data handling RX02, I think in that RX02 M7744 cpu board.

 

[vrs42]

TS his question were to look for that data handling RX02, I think in that RX02 M7744 cpu board.

I seem to recall that Tony Duell (I think it was him) has deciphered the state machine implemented by the bit slice processor in there. It may be possible to Google up the disassembled "source code". I've never had to look at the insides of the RX02 that closely.

Vince

 

[daver2]

It might be worth double-checking the active state of the signals.

I see on the RX they might be active high, whereas I am sure on the majority of disk drives they are active low...

Just worth a check.

Dave

 

[AK6DN]

The DEC RX02 Technical Manual on bitsavers has a detailed description of the microcode flow charts of the RX02 bitslice CPU drive controller.
The flows are very complete and detailed, I used them when developing the RX02 emulator code when questions on functionality needed to be resolved.
There is also a program I have "rx02dis.c" from Charles Dickman August 2012 that reads the RX02 proms and disassembles the microcode.
You can get it here: http://www.chdickman.com/rx02/ about halfway down the page, under "RX Documentation" are links for the program and its output.

Here is what the output looks like:

addr inst function
----- ------ ----------------------------------------------------
0000: 141446 R8 = (R8 - R8)
0001: 000253 jmp 0253
0002: 010327 jsr 0327
0003: 163420 Rc = 2 * (Rc)
0004: 056406 if not DAT SIGN goto 0006
0005: 031000 hold FLAG
0006: 010747 jsr 0747
0007: 165460 Rd = (Rd - 1)
0010: 057403 if not DAT ZERO goto 0003
0011: 134004 q = (R7 + R7)
0012: 157420 Rb = 2 * (Rb)
0013: 056415 if not DAT SIGN goto 0015
0014: 031000 hold FLAG
0015: 046017 if WRT DAT L goto 0017
...

 

[gwiley]

I have recommended elsewhere that folks trying to get OS/8 working on RX02 reconsider, or at least be very careful. The drivers for V3D and other common OS/8 versions are absolutely *not* compatible. If you insert them and try to boot them in an RX02 drive that doesn't have the internal switch set to RX01 compatibility, you will likely corrupt your boot media.

This is because bits that should have been reserved weren't, to save code space. So the single density bootstrap will leave bits set that do nasty things when interpreted by an RX02.

Well... I can confirm that this is true. (not that I ever had doubts about it)

Came back from a 1+ week trip, momentarily forgot which of two systems (8/M and mini-Omnibus-backplane) was configured for RX01 and which was RX02, tried to boot OS8 and it didn't boot. Swapped every board from the working 8/M over to the non-booting mini-backplane system. Still didn't boot OS8. Put all working boards back in the 8/M... now the 8/M won't boot OS8 anymore.

I had clearly been not so smart... TWICE! I think I selected the wrong bootloader on the M847.

I'm using M8357R and RX02 emulator in both systems.

Fortunately, I recall reading a post long ago cautioning about corrupting an RX02 image... searched the DEC forum and found this post again. So, copied the good OS8V3D.RX2 from my Windows 10 machine onto the microSD card and the 8/M now boots OS8! Made a copy of the working microSD for the mini-backplane system and it now boots OS8 too. I think I'll just run both systems in RX02 mode from now on to avoid this confusion and headache again.

 

[vrs42]

Well... I can confirm that this is true. (not that I ever had doubts about it)

Indeed. Even with both your systems set for RX02, you'll need to be careful to label all your RX01 media and to never boot from them, nor from media of unknown type. I believe the only safe access to RX01 media from an RX02 drive that isn't in compatibilty mode would be with the non-system RX02 device driver. (Well, the RX02 system driver presumably won't scribble them, but I don't think it will read them either.)

Vince

 

[BitWiz]

Vince,

Would you recommend booting off an RX02 system disk or an RX01 system disk. I vaguely recall discussing this with you and you saying that creating an RX02 OS/8 boot disk is difficult (I don't recall why).

 

[AK6DN]

In this directory: https://github.com/AK6DN/rx02_emulator/tree/master/disk_images
There are OS78V4 and OS8V3D RX02 bootable images, and an OS8V3Q RX01 bootable image.

And for reference, here are the OS8V3D RX02 and OS8V3Q RX01 console and emulator debug logs for booting and doing a 'dir' command:
In this directory: https://github.com/AK6DN/rx02_emulator/tree/master/documentation/lab_trace_logs/pdp8

 

[vrs42]

Vince,

Would you recommend booting off an RX02 system disk or an RX01 system disk. I vaguely recall discussing this with you and you saying that creating an RX02 OS/8 boot disk is difficult (I don't recall why).

AFAIK, if your drive hardware is set for RX02, the only safe way to boot is from an RX02 system disk. Booting from an RX01 diskette will cause the diskette to destroy itself, since it has the RX01 second stage boot and drivers on it, and booting will run them.

Once you've booted the RX02 system disk, the non-system RX02 driver is sophisticated enough to figure out the density of the inserted diskette, which means you can use RX01 media in drive 1.

I don't know it for sure, but I strongly suspect that the RX02 system driver cannot operate correctly if the boot disk media is actually RX01. That would require it to understand which sector size to use, etc. and there just isn't room in there for much sophistication.

It is also imperative to never use the RX8E bootstrap, and always use the (slightly longer, IIRC) RX28 bootstrap.

Vince

 

[gwiley]

In this directory: https://github.com/AK6DN/rx02_emulator/tree/master/disk_images
There are OS78V4 and OS8V3D RX02 bootable images, and an OS8V3Q RX01 bootable image.

I've been booting my 8/M and mini-omnibus-backplane systems with the OS8V3D.RX2 image (from the folder at the link above) using the RX02 emulator for the drive and using the boot code in the "M847-extended-version-V1.1" board, boot selection 03, RX02 (RX28, M8357 RX8E card at 675x).
Floppy controller in each system is an M8357R.