(last updated: 25-Sep-2017)
The current configuration is in its original 'as acquired' condition and includes:
The main chassis in a deskside pedestal
VR241-A 14" color monitor (s/n Y4D0431697)
LK201BA keyboard (s/n B04120EIW5)
BCC17 chassis to monitor cable
18-Aug-2012
While driving through town, I saw some small lawn signs pointing the way to an estate sale. There I found a number of interesting items but one that I was most pleased with was finding this DEC Rainbow in a corner, complete with a DEC VR241-A color monitor and keyboard. An old Epson wide-carriage dot-matrix printer was also nearby but I left that behind; I have two narrow-carriage dot matrix printers already.
The main unit, in the optional desk-side tower enclosure, monitor and keyboard were marked $5 each, but as luck would have it, I had arrived at the tail end of the three-day sale and everything was 50% off! So I snagged the entire setup for just $7.50!
At the same time, I also snagged the following SCSI HDDs which have hand-written labels that suggest they are from an Apple Macintosh system:
- DataFrame XT40 (contains Lapine Titan LT200 MFM drive, 20MB), ADDR 0? - Apple (Quantum Pro LT) Maverick 540S, DataStor enclosure, ADDR 1, (0,1,2,3 work; 4,5,6,7 don't, due to broken pin) - Quantum Fireball TM3200S, NO-NAME enclosure, ADDR 6 (fixed) - Quantum Fireball TM2110S, BARE-DRIVE
18-Aug-2012
My usual method came into play, vacuuming all surfaces, then wiping with Windex. Then, a piece by piece disassembly, vacuuming and Windexing as I went. This 30-year old system had a bit of accumulated dust, but it was not at all dirty considering the age of the system. It was easily cleaned, and had no 'grime'.
A quick inventory of the manuals and other items, revealed no operating system floppies, sadly. I do have floppies for WordPerfect 4.2, and DBase III.
Time to call it a day, but a little more time spent with Google turns up a number of great resources giving information, a Rainbow FAQ, and diskette images.
http://www.classiccmp.org/rainbow/ http://rainbow-100.com/ ftp://ftp.update.uu.se/pub/rainbow/ http://www.fpns.net/willy/pdp11/decmicro.htm
This last is from my old friend Will Kranz!
19-Aug-2012
My usual habit when working with a newly acquired old system is to make a copy of the hard disk contents, either imaging the disk sector by sector, or at least doing a file by file copy. I mean to do the same with this system, though it will be hard to get a sector by sector copy, given that the hard disk is an old ST-412 MFM drive which can't be easily moved to another system with tools for imaging.
Prior to solving that problem, though I did assemble the system, connectiong the monitor and keyboard, and powered up. I was most pleased to see the "TESTING..." message appear on the screen. After a few moments, the Main Boot Menu appeared but with an error:
See Owner's Manual - MESSAGE 7 - Drive A
I was hesitant to try to boot to the hard disk, so I just tried out the terminal mode and ran the more extensive self tests.
Having no experience with this system, I wondered if there should be a floppy in the drive. Time to download some bootable disk images.
I snagged the copies of the CPM-86/80 and MS-DOS operating system floppies from www.classiccmp.org/rainbow and related tools for decompressing and the Teledisk program to restore the images to a real floppy disk. I used my CompuAdd 316s system as a host for restoring the images to floppy disks. I only restored the MS-DOS image at first, just so that I could try it in the system.
Well, I kept getting the MESSAGE 7 error.
After locating the appropriate manual, the message indicates problems with the floppy drive cable, or the drive itself. I reopened the case and removed, then replaced the floppy cable at both ends, making sure that each connector was firmly seated.
At power up, this time there was no error! Great! At this stage it was a snap to boot from the MS-DOS boot floppy. No problems. I now felt confident enough to try a directory of the hard disk. It turns out it is known as the E: drive under MS-DOS, and it appears that the system has MS-DOS 2.11 only on it...no CP/M. I spent a little more time exploring the system, but now I really need to make a copy of the hard disk.
There is one note to make at this point. Though this system is running MS-DOS, it IS NOT an IBM PC clone, and cannot run IBM PC software. The hardware is altogether different. Most MS-DOS software that doesn't use the hardware in any special way will work, otherwise, it's a no go.
21-Aug-2012
I needed to figure out a way to move data onto and off of this system. The floppy drives and the communication port were the obvious choices. In previous PDP-11 and VAX antique computer adventures I knew that there were some tools for reading and writing RX50 diskettes, but I couldn't remember the details. Some web searching refreshed my understanding, particularly about a tool called PUTR. I also learned that there were some other tools that were new to me, such as RX50DRVR.SYS dos device driver that allows a PC with a 1.2MB 5-1/4" drive to read and write RX50 diskettes in the A: drive. In the end, this one was to prove itself invaluable.
My first attempt was with PUTR. I had used PUTR in the past to read and write files into and out of various DEC PDP-11 and VAX related disk image files. I had the hope of creating an image file, inserting communications tools, and then writing that image to a floppy. Well, it was a non-starter. I could format a floppy in the RX50 way, but I couldn't mount it to add files. I'm not sure how useful PUTR is here, unless I missed some important README information. I couldn't figure it out.
Okay, time to try to get Kermit (see next section) on this system, somehow, someway. The answer was RX50DRVR.SYS. This is a device drive that is installed via the CONFIG.SYS file:
DEVICE[HIGH]=RX50DRVR.SYS
That's all there is to it! Wow, so easy after all the trouble I went to trying to use PUTR. RX50DRVR gives me a new drive letter (D: in my case, while working on CompuAdd) which is the first floppy (ala Drive A:). All you have to do is copy files to and from drive D: and you're done! I had some blank floppies that I had already formated on the Rainbow, so it was really just a matter of finding the tools that I wanted to use.
By the way, some of the blank floppies that I was using throughout this effort were 'flippies', or ones where I had cut a notch on the opposite side so that the floppy was usable upside-down in my Apple II system's disk drives, giving me that much more storage on one-sided floppies. As it turns out, the way the RX50 drive detects whether a floppy is inserted or not is by sensing the diskette envelope at exactly the same spot where a flippy's writable notch is cut. Ouch! It took me a long time to figure this one out, which include a partial disassembly of the RX50 drive itself! This was definitely one of the times where you slap yourself on the forehead and wonder at your stupidity or bad luck. I finally covered the flippy notch with a label and they work just fine now!
21-Aug-2012
Time to get a copy of the hard disk contents. A direct sector-by-sector image would be difficult to do, given the MFM ST412 interface, so I settled for getting a file-by-file dump of the drive.
There is no simple way to move files to and from this system without disturbing the hard disk contents. I want to snapshot it first. So, I couldn't make a huge ZIP file and somehow get that off. There was a software package called POLY-COMM on the hard drive, but a little web research suggests that it had a proprietary format for file transfer, and I wasn't up to figuring that out.
Evenutally, I settled on Kermit since a web search showed that there was a version for the Rainbow and almost every other system in the world. Seemed like a good choice, though I have never used Kermit before.
ftp://kermit.columbia.edu/kermit/bin/mskermit/
After finally figuring out which binary was for the DEC Rainbow (msvrb1.exe) I downloaded a copy via FTP on CompuAdd saving to an RX50 diskette. Finally, with this diskette, I had a useable tool for transferring files to another system! Sure, I needed to get Kermit or some compatible software on the target machine, but after all of these troubles, it'll be easy.
Making sure that the Kermit I had on RX50 floppy actually ran (it did), I then cabled Aero-6 running Windows95 via the short DB9-to-DB25 cable, mated with a Female-to-Female gender changer and I was in business.
And, a little good fortune came my way. I fired up HyperTerm on Aero-6 and learned that it was capable of sending and receiving files using the Kermit protocol. Good! A little experimentation showed that I could send multiple files at a time using wildcards in the filespec on the sending machine.
So, with all this ready, I started a complete send of the entire harddisk using:
MS-Kermit> SEND E:*.*
which worked pretty good for a while. Eventually I noticed that there were more and more retries, and after about 15000 packets with a count of almost 5000 retries, the flow stopped, and the Rainbow terminated the transfer with an error indicationg that it had had too many retries. With this trouble part way through the E:WP directory, where the target system hung in the receive mode and I couldn't cancel or kill it. I eventually had to reboot Aero-6.
So, with that being a possible problem again, I chose to send smaller groups of files at one time. I sorted the list of files according to file extension, then sent each file group individually. It let the system 'reset' between groups.
As I went along, some groups (most of them) experienced a good number of retries, too, but once in a while I got lucky and the transfer went cleanly, with no retries.
With all of the regular files copied, there are still two hidden files to copy from the root director: IO.SYS and MSDOS.SYS. I used:
ATTRIB E:*.*
to identify any hidden files, and these are the only two. In order to copy them, I'll have to re-set the hidden and system attributes, but since we're down to the final two files, I'm ready for this first modification to the filesystem:
ATTRIB -h -s E:*.SYS
then I copied these two files (MS-DOS 2.11) to Aero-6, again using Kermit.
Next, confirm that I got a good copy of everything, then reset datetime stamps on each file, then archive all of it.
24-Aug-2012
After copying the files transferred by Kermit I noted that the datetime stamp for each file had been altered to the datetime of each file's transfer. I want to preserve the disk contents completely, so I must reset the timestamps to their original values. Given that my target storage server was Linux-based, this seemed like a job for a shell script that used the touch utility. I wrote a small bash shell script that reads in an MS-DOS directory listing and resets the timestamps to each file and directory.
Some notes on this script. It runs only on one directory at a time, so it is best to run the script on the lowest subdirectories first, then work back up the tree to the root. This way, any changes in the branch directories that might alter the directory's modtime are fixed as we work back up the tree.
The shell script is stored with these files, for future reference and use in case this kind of operation is required again.
03-Sep-2012
At kermit.columbia.edu I found an old Kermit for the Rainbow running CP/M-80/86. They have a binary and other files, including an Intel hex file that can be transferred as text then converted to binary once on the target system using the CP/M utility hex2bin(?????). Since I have not found any means of transferring the binary via the serial ports -- I can *write* to the AXO: device and see the output on, say, a PC running HyperTerm (9600,8,n,1), but if I try to *read* from AXI: it just hangs...nothing -- I need another way to get the hex file over.
Since both MS-DOS and CP/M use the same fundamental disk format (80 tracks, 10 sectors per track), even though the filesystems differ, I hope to write a disk on the MS-DOS side, sector-by-sector as necessary, that can be read by the CP/M side. This way I can bootstrap Kermit onto the CP/M system.
At first I had a faint hope that the BIOS calls would be the same as an IBM PC, but alas, they are not. The BDOS of MS-DOS is the same (INT 21), but not the BIOS. I can't use INT 13 to do direct reads and writes to the floppy. A lot of web searching finally turned up a cheatsheet that pointed me in the right direction, and I've saved this document in my pile of Rainbow material. The rainbow provides a direct-access facility using INT 65.
I used DEBUG to test this function and I learned enough to use it, found that the function seems to read only a single sector no matter what I put into the sector count field, and I wrote, with DEBUG, the following little program to read a trackful of sectors as a part of my explorations:
0100: MOV BX,0140 ; command buffer 0103: MOV AX,CS 0105: MOV DS,AX 0107: MOV [014A],AX 010A: MOV AX,1000 ; sector contents buffer 010D: MOV [0148],AX 0110: MOV AL,01 0112: MOV [0142],AL 0115: INT 65 ; read sector 0117: MOV AX,[0148] ; update buffer offset 011A: ADD AX,0200 ; for next sector 011D: MOV [0148],AX 0120: MOV AL,[0142] ; update sector # 0123: INC AL 0125: MOV [0142],AL 0128: CMP AL,0B ; do all ten sectors 012A: JNZ 0115 ; in a track 012C: MOV AX,[0144] ; update track # for 012F: INC AX ; next run 0130: MOV [0144],AX 0133: INT 200140: DB 00 ; command to read sectors 0141: DB 11 ; drive unit (MS-DOS) 0142: DB 01 ; sector # 0143: DB 01 ; physical drive # 0144: DW 0000 ; track # 0146: DW 0001 ; sector count # 0148: DW 1000 ; sector buffer offset 014A: DW xxxx ; sector buffer segment
Using this capability, my plan is to blank-format a CP/M floppy, then write a file to that floppy that is exactly the same size (in sectors) as the hex file, then under MS-DOS and using that file layout as a template, write the hex file sector-by-sector to the CP/M disk. Then, with that file readable under CP/M, I should be able to read and convert the hexfile to a binary that I can then use to tranfer to and from CP/M to my heart's content.
04-Sep-2012
Well, with some fiddling, that plan is exactly what I did. Here are some details.
I found that a blank CP/M disk (which has the same low-level format as the MS-DOS disk) starts its Directory/FCB region at the start of Track 2 in Sector 1. This region is 8 sectors, then the data region starts at Track 2 Sector 9.
CP/M (fortunately!) writes a file contiguously, sequentially if it can, which is so with a newly formated blank disk. So the first file starts at Track 2 Sector 9, then Track 2 Sector 10, then Track 3, Sector 1, and so on.
File space is allocated in 2048-byte, or 4 sector, chunks. Each chunk is listed in the file's directory/FCB and if there are more than 16 chunks, another directory entry is used with the same filename which lists the next batch of 2KB chunks.
The hex file that I wanted to store on the CP/M disk was 39,131 bytes (76.427... , or 77, sectors) long. This would require 19.106..., or 20, chunks of space on the disk. 20 chunks times 2KB is 40KB in all. So I needed to take a freshly formated CP/M disk, copy or otherwise allocate 20 chunks worth of data to it, which would then allocate the directory entry(ies) and allocate the disk space which would save some trouble. Then I simply replace those sectors with the hex file and I would have a contiguous, sequential file readable under CP/M. I found that my main system disk had two files that together amounted to 80KB, which equates to the 20 chunks. I used PIP to copy them to my blank disk:
A> PIP B:C86XRB.H86=ASM86.CMD[R],DDT86.CMD[R]
Since these source file were 'system' files, the target file also was flagged as a 'system' file and it was not visible in a normal directory listing. I used MAINT to change the flag do 'directory', making it visible.
I now had everything ready for the actual transfer. I cobbled together a Q&D program using DEBUG's internal assembler. This works, in the actual transfer, but for some reason doesn't terminate as expected. When the source file from the MS-DOS side has reached its end, it should terminate, but instead the routine just keeps writing the same sector over and over to the rest of the CP/M disk, even trying to write past beyond Track 79. I had to reboot when that happened, but a scan of the disk showed that the file had indeed been copied over.
{listing here}
The last action was to place an EOF marker (ASCII CTRL-Z '1A') at the end of the file data. I should have done this already, appending a series of '1A's to the source file, but I hadn't so I just fixed the target by reading in the sector (Track 10 (0A), Sector 5) then locating the true end of the file, placing a series of '1A's after, then writing the sector back out to disk.
Finally, I was ready to go. I rebooted the system into CP/M, then ran the GENCMD command to convert the hex file to an executable binary file:
A> B: B> A:GENCMD C86XRB
And that was it! In a minute or so, the system returned and I now had a C86XRB.CMD in the directory. Of course, I ran it right then and there, and it came up! I had bootstrapped Kermit onto the system. I can now move files to and from this system, while working under CP/M.
To test Kermit, I transfered the two Zork 1 files, which I had downloaded (see next paragraph) from Aero-6, a Win95 system using HyperTerm. Not a problem at all, worked without a hitch, and I now am playing Zork 1 on the system!
Interesting archive site for this system (or CP/M in general):
http://www.retroarchive.org/
08-Aug-2014
First, the AUX port is the one used by KERMIT automatically. I don't see any way within KERMIT to select the PRINTER port, for example. It is unclear to me whether KERMIT sets the port parameters (speed, parity, etc.) when it initializes or if it uses the port configuration set via the CP/M-86 command SETPORT. In any case I was successful using KERMIT to transfer files both to and from a PC (WinXP) running HyperTerm. HyperTerm has the ability to send and receive individual files using the KERMIT protocol.
So, here's how:
- Connect the Rainbow's AUX port to the PC using a null-modem cable.
- Fire up HyperTerm on the PC. Port was configured with 9600,n,8,1,Xon/Xoff.
- Fire up C86XRB.CMD on the Rainbow.
- On the Rainbow, enter "SET FILE BINARY".
- Then simply do Send/Receive or Receive/Send.
It's as easy as that!
There isn't much HELP in this version of KERMIT, but the companion PDF documentation gives all the details for usage.
21-Sep-2014
In recent days I have learned a bit more about this system, and had a complete and accurate copy of all files on the hard disk. As it turned out, there was a second MS-DOS partition (F:) that contained Lotus 123 v1.0 and all of those files were also backed up. Sadly, though, without the original diskettes, 123 refuses to run. Copy protection at its best.
In any case, even though I could not locate sufficient information for me to do a low-level sector-by-sector backup of this system, I was ready to move things around a bit. Two key discoveries made me ready:
One, I discovered a set of factory original floppy images on Dave Dunfield's site (http://www.classiccmp.org/dunfield) that included CPM-86/80 v2.0, MS-DOS 2.11, Winchester disk utility, and Learning The Rainbow introduction. This enboldened me to go ahead with manipulation of the system as received. Also, somewhere along the way I came across an image of MS-DOS 3.10b for the Rainbow. On that disk, MS-DOS 3.10b (but not the MS-DOS 2.11 disk) I found FDISK, which allows the paritioning of the hard disk into multiple MS-DOS and CP/M partitions, though it only allows one partition to be bootable.
And, two, I have been working with the system running CPM-86/80 enough that I was confortable with that environment and was ready to install it onto the hard disk.
In addition, I located a goodly amount of Rainbow materials, hints, and tricks, along with software and disk images of various kinds on the Update Computer Club's FTP site (ftp://www.update.uu.se) in Sweden. This had a number of tools that looked promising including a third-party WUTIL (Winchester Utility) that apparently has a primary loader, then a secondary loader that allows one to select which partition to boot from. This might allow me to have a 'dual-boot' setup with my choice of MS-DOS or CP/M with just a keystroke.
In the end, I played it safe...for now.
The hard disk contents, with its two MS-DOS partitions, were reorganized into various subdirectories, and freeing up drive F:. Then using the MS-DOS 3.10b FDISK I deleted this second MS-DOS partition and created a CP/M partition in its place. Then I tagged the CP/M parition as the bootable parition.
Once rebooted into CP/M using a system floppy, I copied all system and user files from the floppy to the hard disk. Then used LDCOPY to install the boot loader to the CP/M parition. Then, I organized my files into various USER spaces with the following layout:
User 0: CP/M system and user files User 1: Adventure games: ZORK, etc. User 2: Kermit-86 for Rainbow User 3: BASIC and MBASIC (discovered on the web)
So, now I have a bootable CP/M-86/80 system. If I need to boot to MS-DOS, I can just boot from a floppy. Or, I can reverse the roles of CP/M and MS-DOS using FDISK again, and then boot MS-DOS from the hard disk, and CP/M from a floppy. I'll work with the system this way for a while, until I'm bold enough to try the third-party WUTIL that has the primary and secondary loaders.
Copyright © 2006-2025 Jared Blaser. All rights reserved.