Last year, a bunch of us OSI hackers go together at the July 22 - 23 2023 Swapfest and Repair Workshop at System Source Computer Museum in Hunt Valley, MD and worked on my CD-23 disk system. A writeup on the work done there can be read here. We got back together at System Source’s January 27 - 28 2024 repair workshop and did some more hacking! The setup was basically the same as before:

• Lambda LPT-7202-FM triple-voltage power supply
• Burgess’s OSI 580 backplane
• Burgess’s OSI 510C CPU board
• One of my universal RAM boards
• Burgess’s OSI 590 disk controller
• Burgess’s OSI 525 dual port RAM board

Here’s everything, set up against the back wall, with my ThinkPad X201 for terminal and support:

The CD-23 spindle lock was removed, and the drive rotated by hand to ensure nothing had been damaged in transit. The 590 board was cabled to the drive, and power applied. Here’s the CD-23 with the belt cover off and powered up (you can see the light on the small HP supply for -5V):

We started with a basic system check: getting the Challenger 3 board set tested, running the OSI memory test on main memory, and then running the same test on the 595 board’s dual-port memory. Everything checked out, so we loaded the experimental C3DUMP Mark Spankus had provided last time and worked on making sure the CD-23 was still talking to the OSI.

Last time, we’d encountered problems with no data fill of the dual-port RAM from the OSI 590 board. Between the and the January 2024 workshop, I’d removed all the chips from the 590 board, cleaned it, and generally went over it. Several of the chips left their pins in the sockets of the 590 board, and were replaced from inventory, except one buffer I didn’t have on hand, which got soldered into a DIP header. In talking with Bill Dromgoole and Crawford Griffith, we decided there was a pretty good chance that one of those weak pins had been causing the issues all along, and that going back to testing where we’d left off was a solid idea.

Initial testing at the January 2024 workshop seemed positive, but something still wasn’t right. Now we were consistently getting data fill from the 590 board, into the 595 dual-port RAM, but it was nonsense! After many tests, replacement of a suspect LM311 comparator, and more testing, we decided to step back and test the 595 board again. Despite having passed tests that morning, it was now giving errors. Fortunately, Bill Dromgoole had brought a spare 595 board with him, and we were able to put it into my system and verify that it was indeed functional. We let the OSI memory test grind away at it for a while to improve our chances of getting a stable system.

We reloaded C3DUMP and started another drive dump. To our amazement, actual data started coming across! Here’s a view of the X201 capturing some of it:

This was the first time in 30 or more years that data had been extracted from the CD-23, and it seemed to have some meaningful information. We did a small capture, and ran strings against it, immediately seeing some likely data. We then did a larger dump and, using a combination of strings and hexdump found some definite data that positively had to be coming off of the CD-23:

 00021db0  20 20 20 44 55 50 20 50  48 49 47 48 20 40 20 3e  |   DUP PHIGH @ >|
 00021dc0  20 49 46 20 43 52 20 20  2e 22 20 4e 4f 20 53 55  | IF CR  ." NO SU|
 00021dd0  43 48 20 52 45 43 4f 52  44 22 20 20 43 52 20 20  |CH RECORD"  CR  |
 00021de0  44 52 4f 50 20 30 20 20  20 20 20 20 20 20 20 20  |DROP 0          |
 00021df0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
 00021e00  20 45 4c 53 45 20 52 45  43 4f 52 44 20 44 52 4f  | ELSE RECORD DRO|
 00021e10  50 20 31 20 54 48 45 4e  20 20 3b 20 20 20 20 20  |P 1 THEN  ;     |
 00021e20  20 20 20 20 20 20 20 20  20 20 20 20 20 20 3a 20  |              : |
 00021e30  50 45 4e 44 20 20 20 20  20 20 20 20 28 20 54 65  |PEND        ( Te|
 00021e40  72 6d 69 6e 61 74 65 20  74 68 69 73 20 54 61 73  |rminate this Tas|
 00021e50  6b 20 29 20 20 20 20 20  20 20 20 20 20 20 20 20  |k )             |
 00021e60  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
 00021e70  20 20 20 43 52 20 2e 22  20 53 55 52 45 20 22 20  |   CR ." SURE " |
 00021e80  41 53 4b 20 49 46 20 20  20 20 20 20 20 20 20 20  |ASK IF          |
 00021e90  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |

FORTH code! We know Burgess was doing FORTH development on the Ohio Scientific, and he does recall using the CD-23 with the Challenger 3 with FORTH. Since we now had a definite confirmation that we were getting valid data, we wrapped it up for the night with the idea that we’d dump as much data as possible starting first thing the next day. That went well, until C3DUMP stopped for no apparent reason:

We’re not sure why this happened, but we did get about 2.3 MB from the CD-23. That data, and a general overview of the workshop, was forwarded to Mark Spankus for analysis and suggestions.

Despite this success, we never got the CD-23 to respond in a meaningful way to a H boot at the H/D/M? prompt. We’re not sure if this is due to a problem with the boot block(s) on the CD-23, a problem with the boot ROM (I changed it out with a fresh copy when debugging the OSI 510C board), or something else. More hacking to follow!

Thanks to Bill Dromgoole for providing the pictures used in this writeup, and to everyone who helped for continued support and interest!

FORTH programs recovered