• Please review our updated Terms and Rules here

RK05 disk emulator development and discussion

gwiley

Experienced Member
Joined
Nov 12, 2021
Messages
252
Location
San Diego, CA, USA
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/
 
Thanks George for all your exciting work! I am looking forward to one day being able to run emulated RK05 drives on my PDP-8/e and LAB-8/e.
Please let me know if I can help. I am reasonably competent with VHDL, but have not used it for a few years.
 
I would love to catch up here. I worked on a tester myself but I changed to another job at another university. Result was a complete stand still for over a year in my hobby. I have a working spare RK05 and also 12 and 16 sector packs as reference. I did also some measurements etc... But I love your tester/emulator combination. So I would love to build one and try to add some value here...

Let me know if you have bare board available or if I can use some Gerber files.

Regards, Roland
 
Thanks George for all your exciting work! I am looking forward to one day being able to run emulated RK05 drives on my PDP-8/e and LAB-8/e.
Please let me know if I can help. I am reasonably competent with VHDL, but have not used it for a few years.
It's getting closer to that point. Have some of the more important commands in the tester working now, and have been able to run a test writing and reading back pseudorandom data. Ran error-free this afternoon for 300k sectors. There are some random bugs to fix still.
 
I would love to catch up here. I worked on a tester myself but I changed to another job at another university. Result was a complete stand still for over a year in my hobby.
I did look carefully at your post about the tester. There was even a photo of a PCB as I recall.

I started this project mainly having focus on just the emulator, but soon realized that a configurable controller function was a critical piece of test equipment to verify that the emulator is working. A side benefit was that the tester seemed like it could also be useful to debug and test a real RK05. Downloaded the manual for the RK05 Exerciser to get a better understanding of how such a device might be used for drive testing. Then developed the tester concept that can be built by flipping the inputs and outputs of the emulator. (Unfortunately, the RK05 has 17 outputs and 20 inputs, so v2 of the emulator PCB will have one more dual driver IC.)

I should share details of the tester and the tester command set to solicit input from the group regarding functions that would be useful to debug a real drive. I don't own a real drive and have never debugged one, so can only speculate about what the tester should do. Also wanted to be able to read a disk pack to a microSD card
I have a working spare RK05 and also 12 and 16 sector packs as reference. I did also some measurements etc... But I love your tester/emulator combination. So I would love to build one and try to add some value here...

Let me know if you have bare board available or if I can use some Gerber files.
I started with 5 board sets, mostly build by JLCPCB except for the FPGA and large through-hole components. Accidentally lifted pads on the first main board while soldering the TQFP144 FPGA, not sure if I can repair it easily. For now, it's a "mechanical sample" of a built-up unit.
Both the main board and the front panel electronics have some design issues and needed improvements, most of which have been reworked. PCB design updates for these bug fixes are part-way done. The plan is to put the v2 board details on github, which will have little or no bug-fixing rework.
 
Making some progress, but a bit slower than I'd like due to time available to work on this. There's at least one unit that appears to be fully functional. It passes the tester's "Write Loop Random" test, so it reads and writes pseudorandom cylinder/head/sectors with pseudorandom data. I've run it several times overnight which reads/writes about 500,000 sectors each time. The Seek Loop test responses are correct for valid and invalid cylinder addresses. Drive Address selection for all four addresses in RK8-E mode function correctly. File Ready, RWS Ready, write protect and write protect status appear to function properly.

The OLED display works now. I switched to a different SSD1306 display library that doesn't conflict with the UART.

Lower priority things to work on:
The DC Low output has not been tested or adjusted.
microSD card reading and writing is slower than I'd like, takes about 30 seconds to load and unload. Should probably save binary data rather than hex data on the card, and also speed up the SPI link.
Verify other modes besides RK8-E mode.

two of the 5 boards build appear to be working fine:
#1 - has three damaged FPGA pads. Tried to repair it but it's quite difficult.
#2 - working fine as an RK05 emulator and has been extensively debugged and tested.
#3 - working fine as an RK05 tester
#4 - as an emulator fails the "Write Loop Random" test
#5 - as an emulator fails the "Write Loop Random" test

Currently adding capability to automatically verify interface signals, DRAM, front panel LEDs and switches. This is to verify "is it built correctly?" rather than "is it designed correctly?".
 
You can see an 8/e copying a real RK05 to the RK05 emulator here:
That's impressive. Please let us know when we can order.. parts, kit, partially assembled, complete unit?
I have dozens of 16-sector disks that I'd like to archive onto different media.
 
That's impressive.
thanks

Please let us know when we can order.. parts, kit, partially assembled, complete unit?
It would be a kit, or maybe partial kits would be useful. There's a good amount fine-pitch stuff in there so SMT assembly of boards will be done in China.

I plan to put the entire thing on github but want it to be stable first.

The same hardware works as an emulator or a drive tester, just different Pico software and different FPGA build. I was hoping it would help people save some of the real RK05's to prevent them from becoming scrap and recycled.

I have dozens of 16-sector disks that I'd like to archive onto different media.
This would be possible either as a tester, it could read the drive directly, or as an emulator a computer could copy from the real drive to the emulator drive
 
I am looking for a small self contained PDP-8/e assembly source to read and write a RK05 disk via a RK8-E controller.
I found some code snippets in the manual, but I am looking for something in ASCII source form ready to assemble to explore some poorly documented features - specifically "Read All" and "Write All" used in the context of formatting.
The diagnostic is too complex as a starting point and we don't have it in source form ready to assemble.
 
In the dumprest.zip look at the dump and restore for RK05.
http://www.pdp8online.com/ftp/software/dumprest/
Thank you David. This is just what I need.
We see some RK05 errors related to "Read All" and "Write All" reported by "maindec-08-dhrkb-e" at location 2132.
There is too much happening in the diagnostics to capture the problem on the scope.
I would like to create a small test case to exercise the functions we don't fully understand to see what the RK8-E controller actually does.
 
Have had some success with testing the RK05 emulator and learned a lot along the way.

In a prior post, @m_thompson showed his pdp-8/e copying from a real RK05 to the RK05 emulator

Have been working with @thunter0512 testing and debugging, and sending scope images, emulator log files, and FPGA binaries across the Pacific. Tom was able to get the MAINDEC-08-DHRKB-D-D RK8E Drive Control Test to pass, which tests the RK8-E controller and drive.

We learned a lot about the RK8-E, but two items that resulted in a hardware change in the FPGA:
  • Sometimes the RK8-E outputs a small glitch on the BUS_WT_DATA_CLK_L, the composite data and clock from the RK8-E to the RK05, at the same time when the Write Gate signal goes active. The emulator would intermittently see this glitch which was about a half a bit time from the next real pulse on this signal and interpret the glitch plus first real pulse as the Sync bit, and start capturing the sector data a bit too early. Implemented an FPGA feature to ignore BUS_WT_DATA_CLK_L pulses for a short time following the active-going edge of Write Gate.
  • I misinterpreted the rules for creating the BUS_RWS_RDY_L signal. This signal would briefly pulse (about 6 usec) to the not-ready state after any seek operation, even when the seek is to the same cylinder. The maindec test looks for this and will declare a failure if the drive seeks to the same cylinder and produces a not-ready status shortly following the seek command. Seek is a pulse on the BUS_STROBE_L signal. A minor fix in the FPGA code fixes this problem so the drive is always ready when it can be ready.

Now that the maindec test was passing, Tom loaded OS/8 onto the emulator drive and was able to boot OS/8.

There was also some learning about the fragile SMT FPC connectors, so those will be 0.1 inch headers on the next PCB version. I broke the FPC connector to the microSD card, but fortunately I can use that one as the RK05 Tester, just can't save and load images to/from the memory card.

The PCB has been updated with these fixes and a number of other things. Probably will order the next version of the PCB soon.
 
Great job, my compliments!
A block diagram would be very interesting for me and the others.
Regarding small glitch: I also had these problems when
developing my RL Emulator. The cause was a jitter and could
only be solved with a system clock that was 16(32) times higher
than the actual transfer clock. Everything has to be synchronized.
In any case, continued success.
 
Have had some success with testing the RK05 emulator and learned a lot along the way.

...

When I unpacked the prototype, my first reaction was "wow - this is beautifully engineered".
A lot of thought and attention to detail has gone into this design.
Congratulations and thank you to George Wiley for a job really well done!!!

The prototype now passes all diagnostics and nicely runs OS/8.

We now have a C program to convert from SIMH format to the RK05 emulator format. The reason for not just adopting the SIMH disk format was that the emulator preserves the 16-bit header word and 16 bit CRC. This provides some basic level of data integrity which does not exist in the SIMH disk format which is just the sector data without header and CRC. With the conversion utility it is trivial to convert between the formats.

I have converted the very complete and useable PiDP-8/i OS/8 disk image created by Warren Young to the RK05 emulator format. It boots "out of the box" and runs really well. Speed is impressive and is very similar to a real RK05.
Warren's website with the original PiDP-8/i OS/8 disk image is at: https://tangentsoft.com/pidp8i/wiki?name=Home

Below is a photo of the prototype emulator after booting OS/8 on a PDP-8/e, and a second photo while compiling a large BASIC program under OS/8 which does a lot of disk activity (click on a photo to see full size):

PXL_20231202_034219820.jpg

PXL_20231202_034428121.jpg
 
Last edited:
What type of meta data would be useful to store as part of an RK05 emulator disk image?

Current meta data fields and field lengths are:

Name (20 char)
Description (200 char)
Origin of original disk (100 char)
Date and Time of creation (20 char)
Creator of disk image (100 char)

Any thoughts?

Thanks
Tom
 
Checksum or other data-integrity check value?
The current disk image format has a 16-bit CRC for each sector and the cylinder number in the sector header.

The meta data I am thinking off is more to identify the origin of the disk & image. For example the "Name" field could be displayed on the OLED screen.
All other meta data could be added/edited/displayed with a small C program.

There is also a small C program to convert from SIMH to RK05 emulator format with the option to add the meta data.
 
I suggest including a magic number at the beginning of the file to make automatic identification easier.
 
I suggest including a magic number at the beginning of the file to make automatic identification easier.
hmmm, interesting idea. You're thinking a value that would be unique to determine that a file is different from any other file that's not produced via a direct copy? Could be a hash of the current date, time, and user ID, something like that?
 
Back
Top