• Please review our updated Terms and Rules here

RK05 disk emulator development and discussion

I don't suppose you have a schematic or any other documentation for the external power supply, do you? Mine's dead, and debugging it blind will be hard.

I've also daydreamed about making an SMD emulator. I came to the same conclusion about needing to keep at least an entire cylinder in RAM to meet head-change latency requirements. I'd consider keeping the entire disk contents in RAM and loading/saving the RAM contents to nonvolatile storage at spin-up/spin-down, as well as periodically saving dirty sectors.
 
Yes, in order to be able to emulate an actual drive’s performance, I’m keeping the entire drive image in RAM and the cylinder is being kept in the Zina 7020 block RAM.
 
Is there a document somewhere that describes the .rk05 format?
I see there is a utility to convert simh RK05 images to emulator images, but it seems to be limited to (16-sector) PDP-8 images, which is great for PDP8 use... but I'm wanting to use this to emulate a 12-sector (16 bit) pack. So I would like to be able to create a blank, unformatted, 12-sector pack.
 
Nevets01 said:
Is there a document somewhere that describes the .rk05 format?
I see there is a utility to convert simh RK05 images to emulator images, but it seems to be limited to (16-sector) PDP-8 images, which is great for PDP8 use... but I'm wanting to use this to emulate a 12-sector (16 bit) pack. So I would like to be able to create a blank, unformatted, 12-sector pack.
Click to expand...
The ".rk05" disk container consists of a container header and sector data.

The RK8E style ".rk05" sector data is simple:

2 bytes little endian cylinder number
512 bytes sector payload
2 bytes little endian CRC16

The disk container header contains a bunch of settings controlling the behaviour of the FPGA - see C function "write_image_file_header()" and lines 68 - 77 of RK05Util.cpp.

This header will have to be specific for each type of disk controller. My initial focus was RK8E only, but I have started thinking about a clean way of extending this to other formats. There will be support for Xerox Alto, DG 4047/4049 and RK11-D/E.

If you need something quickly, then it wouldn't take much effort to hack the source files to support your 12-sector format. If you can wait, then I will add the functionality to support all formats. I would appreciate your help testing this.

Update: I forgot to say that utility "RK05Simh2Bin" will create a blank (all zeroes) formatted disk image when you specify a SIMH input file with zero length. This means the disk container image will have a valid header and the required number of sectors - as described above but all sector data will be zeroes. Nevertheless the disk image container header, sector count and sector format is controller specific.
 
Last edited:
thunter0512 said:
The ".rk05" disk container consists of a container header and sector data.
Click to expand...
For pdp-8 I have been distributing .rk05 files for a long time
http://www.pdp8online.com/ftp/images/os8/
might be better to pick a different extension so people don't try to use my image with your emulator or your images with SIMH and my dumprest. Since you say files are specific to controller .rk8e may be better.
 
djg said:
For pdp-8 I have been distributing .rk05 files for a long time
http://www.pdp8online.com/ftp/images/os8/
might be better to pick a different extension so people don't try to use my image with your emulator or your images with SIMH and my dumprest. Since you say files are specific to controller .rk8e may be better.
Click to expand...
Thanks David, I was not aware of your ".rk05" disk image extension.

The disk images are specific to the controller, but the emulator is generic with emulation parameters loaded from the disk image header. The embedded firmware currently searches for a file with the extension ".rk05", and if it finds one opens it and checks the signature and version and then loads the disk image header and then downloads the emulation control parameters found in the header into the FPGA.

The reason for only looking at the extension is so that you can use nice descriptive file names without the need for a separate ".ini" file which points to the actual disk image. The assumption is that you will only put a single file with the extension ".rk05" onto the SD card. If there are multiple such disk images files on the SD card, then a random file will used by the emulator.

The supplied RK05 utilities don't care for the file extension, but the emulator firmware does. One possible solution would be to simply open the first and hopefully only file on the SD card without requiring a specific file extension, but that is just another can of worms. Alternatively I could try opening multiple file extensions like ".rk8e", ".rk11d", ".rk11e", ".alto" and ".dg404x" but this would slow the startup and be confusing if the image header does not match the file extension.
 
Last edited:
I made a table of the values for each of these controllers but it has many other related parameters so it would probably be confusing and could be simplified. Will upload that soon
 
Since the emulator takes a new format (new to me, anyway), it would perhaps be best if it had a new extension, to minimize confusion with the many legacy file formats. I'd suggest ".rke", since I don't know about anything else currently using that extension. Perhaps it could look for a ".rke" file, then look (as it does now) for ".rk05"?
 
thunter0512 said:
The ".rk05" disk container consists of a container header and sector data.

The RK8E style ".rk05" sector data is simple:

2 bytes little endian cylinder number
512 bytes sector payload
2 bytes little endian CRC16

The disk container header contains a bunch of settings controlling the behaviour of the FPGA - see C function "write_image_file_header()" and lines 68 - 77 of RK05Util.cpp.

This header will have to be specific for each type of disk controller. My initial focus was RK8E only, but I have started thinking about a clean way of extending this to other formats. There will be support for Xerox Alto, DG 4047/4049 and RK11-D/E.

If you need something quickly, then it wouldn't take much effort to hack the source files to support your 12-sector format. If you can wait, then I will add the functionality to support all formats. I would appreciate your help testing this.

Update: I forgot to say that utility "RK05Simh2Bin" will create a blank (all zeroes) formatted disk image when you specify a SIMH input file with zero length. This means the disk container image will have a valid header and the required number of sectors - as described above but all sector data will be zeroes. Nevertheless the disk image container header, sector count and sector format is controller specific.
Click to expand...

Sorry @Nevets01 I just realised that I got the 512 bytes sector payload wrong - that should have been 384 bytes - i.e. (256 * 12) / 8.
Of course these numbers are only for the RK8-E (PDP-8/e).
 
Last edited:
Trying to figure out what could possibly need to be different between the an emulation of the same drive with the same disk pack, on two different controllers, I looked at:
thunter0512 said:
lines 68 - 77 of RK05Util.cpp.
Click to expand...
is...
char controller[100] = "RK8-E";
int bitRate = 1440000;
int preamble1Length = 120;
int preamble2Length = 82;
int dataLength = 3104;
int postambleLength = 36;
int numberOfCylinders = 203;
int numberOfSectorsPerTrack = 16;
int numberOfHeads = 2;
int microsecondsPerSector = 2500;
Click to expand...
Okay, so controller is just an identifier string.

bitRate, numberOfCylinders, NumberOfHeads, and microsecondsPerSector are all things that wouldn't change from drive to drive... though them being redefinable would make this useful for emulating other drives that aren't necessarily compatible (e.g. Diablo 44).

numberOfSectorsPerTrack would obviously change on a pack-to-pack basis.

That leaves preamble[1|2]Length, dataLength, and postambleLength. What are these? From the names, and the fact that I haven't been able to find any mention of them in the RK05 or Diablo 31 manuals, it sounds almost like the 'preamble' and 'postamble' are sequences of data written onto the disk by the computer, (rather than something inherent to the drive), and instead of just writing all the data that would normally be written onto the disk pack, onto the image file, the emulator is detecting that data on a write operation, excluding it from the data written to the image file, and generating a synthetic preamble and postamble when reading the data back. Is that guess correct?
That approach would certainly explain the need for a controller-specific (and possibly software-specific if there are platforms that leave the pre/postamble up to the software) header, so the emulator knew what data to ignore on a write operation, and what data to generate on a read operation, since these would differ depending on the controller/computer/software.

Either way, thank you for the info!
 
Nevets01 said:
Trying to figure out what could possibly need to be different between the an emulation of the same drive with the same disk pack, on two different controllers, I looked at:

is...

Okay, so controller is just an identifier string.

bitRate, numberOfCylinders, NumberOfHeads, and microsecondsPerSector are all things that wouldn't change from drive to drive... though them being redefinable would make this useful for emulating other drives that aren't necessarily compatible (e.g. Diablo 44).

numberOfSectorsPerTrack would obviously change on a pack-to-pack basis.

That leaves preamble[1|2]Length, dataLength, and postambleLength. What are these? From the names, and the fact that I haven't been able to find any mention of them in the RK05 or Diablo 31 manuals, it sounds almost like the 'preamble' and 'postamble' are sequences of data written onto the disk by the computer, (rather than something inherent to the drive), and instead of just writing all the data that would normally be written onto the disk pack, onto the image file, the emulator is detecting that data on a write operation, excluding it from the data written to the image file, and generating a synthetic preamble and postamble when reading the data back. Is that guess correct?
That approach would certainly explain the need for a controller-specific (and possibly software-specific if there are platforms that leave the pre/postamble up to the software) header, so the emulator knew what data to ignore on a write operation, and what data to generate on a read operation, since these would differ depending on the controller/computer/software.

Either way, thank you for the info!
Click to expand...
@Nevets01 Which host controller would you like to use?

I can create a small utility which creates the appropriate header for your controller and fill the actual disk images with all zeroes. This should allow you to use the platform specific utilities to low-level format the disk and subsequently write/read to/from it. This may be a good interim solution before we can figure out the low-level format used by the different host controllers. Note that until now only the RK8-E sector format has been verified. Other formats may require some debugging.
 
For my SMD/ESDI drive emulator, I don’t even try to figure the on disk format. I just have the “raw” number of bytes per track and the timing for the address marks. It doesn’t care what the controller does between the address marks. This is mainly because there are too many controllers with different on-disk formats to try to emulate.

The RK05 is a bit different since the number of controllers is a much smaller space. I haven’t looked at what data actually flows between the controller and the drive in a long time but it might be easier to just do what I’m doing. If someone wants to extract an image for use by say SIMH the that could be a post-processing utility.
 
Nevets01 said:
Trying to figure out what could possibly need to be different between the an emulation of the same drive with the same disk pack, on two different controllers, I looked at:

is...

Okay, so controller is just an identifier string.

bitRate, numberOfCylinders, NumberOfHeads, and microsecondsPerSector are all things that wouldn't change from drive to drive... though them being redefinable would make this useful for emulating other drives that aren't necessarily compatible (e.g. Diablo 44).

numberOfSectorsPerTrack would obviously change on a pack-to-pack basis.

That leaves preamble[1|2]Length, dataLength, and postambleLength. What are these? From the names, and the fact that I haven't been able to find any mention of them in the RK05 or Diablo 31 manuals, it sounds almost like the 'preamble' and 'postamble' are sequences of data written onto the disk by the computer, (rather than something inherent to the drive), and instead of just writing all the data that would normally be written onto the disk pack, onto the image file, the emulator is detecting that data on a write operation, excluding it from the data written to the image file, and generating a synthetic preamble and postamble when reading the data back. Is that guess correct?
That approach would certainly explain the need for a controller-specific (and possibly software-specific if there are platforms that leave the pre/postamble up to the software) header, so the emulator knew what data to ignore on a write operation, and what data to generate on a read operation, since these would differ depending on the controller/computer/software.

Either way, thank you for the info!
Click to expand...
If I remember my Diablo 44 bits correctly, preamble1 is a bit pattern saying "sector header coming up", then there's some header bytes that get written by the formatter, preamble2 is a bit pattern saying "sector data coming up", and postamble is just a gap to deal with variations in spindle speed, write speed by the controller, etc. so that a "slow" write doesn't spill over and corrupt the following sector.
 
Terri Kennedy said:
If I remember my Diablo 44 bits correctly, preamble1 is a bit pattern saying "sector header coming up", then there's some header bytes that get written by the formatter, preamble2 is a bit pattern saying "sector data coming up", and postamble is just a gap to deal with variations in spindle speed, write speed by the controller, etc. so that a "slow" write doesn't spill over and corrupt the following sector.
Click to expand...
Most of the controllers that I've looked at that work with the Diablo Model 31 and RK05 have the following format and timing:
1717917746471.png

It has an all-zero preamble of some length followed by a Sync Bit which is a "1", followed by some other fields and data, followed by an all-zero postamble.
The Read Gate and Write Gate go active between the sector pulses. That is, except for the Data General controller which keeps Write Gate asserted past the sector pulse.
Bit rates vary. I've seen 1.440, 1.545, and 1.600 Mbps.
 
ggs said:
For my SMD/ESDI drive emulator, I don’t even try to figure the on disk format. I just have the “raw” number of bytes per track and the timing for the address marks. It doesn’t care what the controller does between the address marks. This is mainly because there are too many controllers with different on-disk formats to try to emulate.

The RK05 is a bit different since the number of controllers is a much smaller space. I haven’t looked at what data actually flows between the controller and the drive in a long time but it might be easier to just do what I’m doing. If someone wants to extract an image for use by say SIMH the that could be a post-processing utility.
Click to expand...

Another difference is that the RK05 doesn’t have the servo clock that both SMD and ESDI drives have as a timing reference. In that sense the RK05 is more like a Shugart SA800 floppy drive with built in FM data separator.
 
Sure. My point was that since the RK05 is hard sectors (12 for PDP-11 and 16 for PDP-8), you shouldn’t need to know what the controller is doing for the meta-data.
 
I agree it should be possible to have it format-agnostic, except that you need to to know the bit rate that the controller is expecting. Unlike magnetic media a simulator need to know the bit rate ( unless you over engineer it and sample the signal at lets say 10x and the reconstruct the bit stream ). What I meant was that unlike SMD / ESDI where the drive is in charge of clocking the controller is in charge for RK05 which means that we at least must match that in the simulator. So some metadata about the controller has to be known by a RK05 emulator.
 
MattisLind said:
I agree it should be possible to have it format-agnostic, except that you need to to know the bit rate that the controller is expecting. Unlike magnetic media a simulator need to know the bit rate ( unless you over engineer it and sample the signal at lets say 10x and the reconstruct the bit stream ). What I meant was that unlike SMD / ESDI where the drive is in charge of clocking the controller is in charge for RK05 which means that we at least must match that in the simulator. So some metadata about the controller has to be known by a RK05 emulator.
Click to expand...
I agree you need to specify the bit rate as that drives a lot of things but you should know that by the density of the pack and it's rotational speed (50Hz drives spin the platter at the same speed as 60Hz drives because the pulley on the motor is of different sizes...they're marked with the intended line frequency).

But my argument is that you only need to specify the bit rate. You don't need to specify pre/post ambles as that's all managed by the controller and not the RK05 drive.
 
gwiley said:
For continued discussion of RK05 disk emulator topics. Creating a new thread in case members prefer to comment here. I have no expectations except to have an opportunity share what I've worked on and to learn from those who share their comments, questions, anything.

There's another thread with lots of related discussion here: https://forum.vcfed.org/index.php?threads/rk05-disk-emulator.1242248/
Click to expand...
Hi. I would PM you, but the forum won't let me do that yet. Are kits still available for this emulator? I have a couple of PDP-11s that would love it -- and it is possible that even my PDP-12 would love it.

Jay Jaeger

JRJ
 
You must log in or register to reply here.
Back
Top