PrintStar's Blog
Ramblings of a Fortran Nut
January 19, 2009 by Jeff

Rainbow Disk Image Utilities

The first half of RetroChallenge Winter Warm-Up 2009 has resulted in the Rainbow Disk Image Utilities. These utilities can be used to generate disk images from RX50 floppy disks on a Rainbow 100 and write images back to disks. The image utilities are compatible with the RAW image format, a popular standard in GNU/Linux and *BSD (via the dd utility) and on MS-Windows/DOS (via the Rawrite utilities). While the programs were tested with Rainbow-formatted floppies, the utilities should work with any disks or images conforming to the RX50′s 80 tracks – 10 sectors/track – 512 bytes/sector format. The archive containing version 0.1 is located at:

The utilities are, coincidentally, also compatible with the output of the wTeledisk utility by Will Kranz. The utility allows the conversion of Teledisk disk images (like the ones found on the Update archives) to RAW image format. The combination of the Rainbow Disk Image Utilities and wTeledisk can be used to recreate boot floppies from any of the Rainbow disk images on Update on an actual Rainbow 100 running MSDOS 2.11 or higher. The utilities were tested and shown to work with both MSDOS and CP/M-86/80 boot disk images. The wTeledisk utilities can also be run on the Rainbow for purists.

Share and enjoy!

  •   •   •   •   •
January 11, 2009 by Jeff

A Skewed View of Disk Geometry

My image programs (reading and writing) were both working in the last post, but I still could not write images created with wteledisk successfully. While simply ignoring the issue would be easier, I personally did not want to be responsible for creating all new and incompatible Rainbow disk images.

After doing a bit of research, I noticed a minor detail on Will’s (of wteledisk fame) page about DEC personal computers. My own ignorance bit me again, as I was unaware of the differences between physical and logical sectors. Apparently the interrupt 0×65 on the Rainbow, which I’m using to directly access disk sectors, operates using logical disk addressing. The addressing is the problem.

Will’s page mentions that the Rainbow applies sector skewing, meaning the logical address != the physical address on disk. Interestingly, the Rainbow manual also mentions that the sectors are skewed (logically) if the track number is greater than one. The manual, at least in the section I was reading, does not expound upon this statement. The wteledisk page clearly states that the resultant images are ordered by physical sector. The only reason my test image, a CP/M boot disk, appeared to work was that the file system index must reside within the first two tracks of the disk, which are unskewed.

To figure out how to “unskew” the sectors on higher tracks, I needed to find some sort of documentation. Rather than flip through hundreds of pages in the Rainbow technical manuals, I remembered a helpful software package that would have had to address the skewing problem. Years ago, M. Warner Losh created a driver for the Rainbow 100 called ImpDrive, which allowed the Rainbow to use standard 3.5″ 720KB drives and 5.25″ 360KB drives. Warner had published the source code as well as the binary device driver for MSDOS, and his code would need to handle the physical/logical addressing issue.

Sure enough in the C code, the answer to unskewing lay:


static u_char unskew[] = {0,1,6,2,7,3,8,4,9,5,10};

...

/*
* The damn driver will help me by doing the skewing for
* me. However, I can outsmart it :-)
*/
if (z80.track >= 2)
z80.sector = unskew[z80.sector];

I implemented the array above in my own code to convert the physical to logical sectors and vice versa during image creation and writing. Voila, success!

I tested the images with both a MSDOS and CP/M boot disk. Both images worked flawlessly!

  •   •   •   •   •
January 7, 2009 by Jeff

A New Utility Leads to Success

My image writing software appears to be correct. I’ve looked over the code, and everything seems to make sense. And yet, my program fails to write a bootable CP/M disk. As mentioned earlier, I suspected problem might be the actual RX50 floppy drive on the Rainbow. I decided on a two-part check:

  1. Attempt to use the program on another known working Rainbow
  2. Swap out the suspected floppy drive for another mechanism

The first step, using the software on another Rainbow, proved to be problematic. I planned to use my tower-mounted Rainbow, which was used in this summer’s Retrochallenge. However, I quickly realized that I didn’t have the necessary disk space (400kB) to store an image to write. Luckily, that Rainbow has a 720kB 3.5 inch floppy drive attached. After moving an image over to the other system, the image writing took forever because it was reading the image from one floppy and writing to another drive, a slow process. Once the image was written, it suffered the same problems as the image written on the original Rainbow.

Swapping the RX50 floppy drive on my Turbow box led to the same results: the CP/M directory was slightly mangled and the disk would not boot. The CP/M boot disk contained a text file, so I booted into CP/M from the hard disk and printed the text file to the screen. Sure enough, the contents were incorrect. I compared the contents to an original, and it became clear something was wrong.

The final variable was the actual disk image in use. I was using a CP/M-86/80 Version 2.1 boot disk in Teledisk image format. The image was converted to a RAW format using wTeledisk, which is based solely on reverse engineering the Teledisk file format. The image appeared to be the correct size, but I couldn’t personally attest to its integrity.

Rather than attempt to further debug my image writing software (which was so simple I was convinced it was functioning correctly), I decided to write an image creation program. By imaging floppies directly, the final unknown, the integrity of the image file itself, would be eliminated. I extended my floppy access routines to include the ability to directly read sectors from the drive, and I wrote a simple program to create images.

I fired up the image creator on an MSDOS 3.10b boot disk, and the image was generated in about 2 minutes, slightly faster than recreating floppies from images. The first pass failed because one sector turned out to be bad, creating a missized image. After a quick modification to write zeros to the image if a sector fails to read, an image of the proper size was generated. A subsequent writing of the image to another floppy resulted in success. The new floppy was readable!

I then attempted to boot the Rainbow off the new floppy, and I was greeted (eventually) by a DOS prompt. All programs on the floppy appeared to run, meaning that the disk write was actually sucessful.

The above success, however, is still incomplete as it requires new images for all OSes to be created on an actual Rainbow. I’m torn at this point as to whether I should continue pursuing the Teledisk images or whether I should just generate new images from scratch.

The software is also far from done. First, the programs are quite ugly and ungainly. Both the creator and the writer could use some serious polish to make them appear Rainbow-y. Also, I’m concerned that the image program won’t be usable in most circumstances. I think a serial version, where the image is read from a serial port, might be more advantageous. Finally, I hope to create an image of a boot disk containing the software itself.

  •   •   •   •   •
January 3, 2009 by Jeff

The Beginning of Winter Warm-Up

Winter Warm-Up started this past week, and I’ve begun work on my challenge. I plan to first tackle writing disk images to the RX50 drive on a Rainbow. Most Rainbow images ship in Teledisk format, as I explained in an earlier post. The wTeledisk utility can convert the obscure format into RAW images, similar to those created using the dd command in GNU/Linux or UNIX. Sounds great!

In my search to find the format of the RAW image file, I stumbled across a library for dealing with floppy images called libdsk. The library handles a suprising number of disk image formats directly, including RAW and Teledisk. The library even has a 16-bit DOS makefile! Awesome!

Well, while the library seems perfect, the makefile is specifically design to use Pacific C. Pacific C is a free (as in beer) DOS compiler from HI-TECH Software. Pacific C seems “nice,” but some testing today has shown that it does not run on the Rainbow. I would prefer to do as much compiling as possible on the Rainbow since I went through the trouble of installing the Turbow accelerator for this contest. So I attempted to port the library to Turbo C.

Now when I say port, I really mean, “Mangle the makefile until it works.” I finally created a makefile that worked, but some of the quirks of Turbo C started to show. Namely, Turbo C occassionally neglects to do anything at all. A few of the object files ended up not actually containing any data or code. No errors are produced, and an object file exists, but there’s no code in the object.

To solve this little compilation issue, I decided to switch to Microsoft C 5.1, another famously quirky compiler. My big beef with the Microsoft compiler is that the version of make that Microsoft created is almost useless. Anyway, using Borland’s make, I was able to compile the whole of libdsk, but some problems remained.

My first fear was the libdsk would flat-out reject the RAW RX50 images. Not surprisingly, a simple test program returned error code -5, meaning the RAW driver rejected the image. The problem stems from the fact that libdsk makes explicit assumptions about disk formats, and RX50 is not listed.

I think the best route to take now is to use libdsk’s RAW driver as a reference and create a much simpler program that can read sectors from the file. Writing the disks shouldn’t be too bad in theory as the Rainbow BIOS provides raw floppy writing calls via interrupt 0×65.

As an aside, I’ve mentioned that my Rainbow is using the Turbo-286 accelerator. This relatively rare Rainbow accessory replaces the Rainbow’s 8088 CPU with a daughter card containing a 286 chip and some interface logic. I’ve posted an album of my Turbow addon as mounted on the Rainbow for all to see. The Turbow can be enabled and disabled via a simple program from CP/M, MS-DOS, or VENIX (which might not exist…). I’ll post more about this rare accessory another time.

  •   •   •   •   •
December 27, 2008 by Jeff

My RetroChallenge Project

After a bit of work, my Turbow-powered Rainbow is now up and running mounted to a beautiful E.T. stand. The hard disk problems were solved by a Mitsubishi 535-U00 40 MB hard disk. Over the last few days, I’ve formatted the hard disk and installed CP/M-86/80 and MS-DOS 3.10b. Most utilities are also ready, but I still need to set up Turbo C and the Suitable Solutions Turbow and ClikClok utilities.

My RetroChallenge project will address one problem I ran into while setting up the Rainbow. I could not find my Concurrent CP/M master disks. Concurrent CP/M is a multitasking version of CP/M, although 8-bit programs are not able to run on it. All Rainbow master disk images are stored in Teledisk images. Teledisk was a disk imaging program created by Sydex which could read and write a myriad of disk formats on standard PC hardware. While Teledisk is generally still available, the program does not work reliably on PC hardware beyond 486/33MHz systems.

While I have plenty of Rainbow’s available, I have almost no dated PC hardware. My last remaining 386 fell victim to a failed battery, which ruined quite a few contacts on the board. The Teledisk file format has already been deciphered, allowing standard disk images to be created. However, writing an RX50 is very difficult on standard PC hardware.

Therefore, I plan to write some software that will be able to write disk images to RX50s directly on a Rainbow. The Rainbow does provide some interrupt routines to directly write disk sectors, so the project shouldn’t be too difficult.

I also plan to play around more with uIP, a TCP/IP stack that I previously ported to MS-DOS systems using FOSSIL drivers. My previous version was quite limited in that it could not handle multiple connections well and used only the dated 0.6 version. I plan to update to at least 0.9 and possibly try to speed things up.

More information should be available soon! Good luck to everyone on the Winter Warm-Up!

  •   •   •   •   •