Subject: Bootable RX01 diskette image?

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 27 Jun 1994 14:49:09 GMT

My X-windows PDP-8/E emulator now has an almost working RX01 emulation,
and I need to test it out.  Perhaps the most interesting test would be
to get a bootable RX01 diskette image and see if I can run something
from the thing.  Anyone willing to mail me such a goodie?  I'd suggest
compressing and uuencoding it for transit, and please tell me what format
it's in.

The format that would be easiest to digest would be a literal byte stream
image of the entire disk, 128 bytes per sector, starting with sector 1
track 0 and going all the way to sector 26 track 76.  With that kind of
data, I can manufacture an emulated disk image quite quickly (assuming
that the application doesn't care about deleted data sectors).

					Doug Jones
					[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 28 Jun 1994 16:01:53 GMT

In article <[email-masked]>,
>compressing and uuencoding it for transit, and please tell me what format

The easiest way to get a bootable RX01 image is to use PDP-8 ENCODE 
format.  RX01 boot conventions are such that track 0 is ignored, and the 
rest of the disk is read in 12-bit mode, thus the last 1/4 of each sector 
is ignored.  (I think that when you write in 12-bit mode, the last 8 bits 
sent are replicated 32 times to flesh out the data.)

Assuming that OS/8's standard RX01 handler was used with ENCODE.SV in 
image mode, the contents of the file are the logical records of the OS/8 
layout which in turn implies that the sectors are referenced in 2:1 
interleave order, each track identically laid out, etc:

1,3,5,7,9,11,13,15,17,19,21,23,25,2,4,6,8,10,12,14,16,18,20,22,24,26

in terms of sector order of the data.  Thus, the binary level of the file 
is the data for each sector's first 96 bytes in the proscribed sector 
order for all tracks 1 through 76.  (Thus wasting all of track 0 and the 
last 1/4 of every other sector on the entire diskette.)

It would be useful to create a utility that converts the output of ENCODE 
into a byte stream.  The only assumption needed is that the data 
represents multiples of 192 bytes represented as multiples of 128 12-bit 
words.  Data lost would be device-dependent, such as the mapping 
described above for RX stuff, or the DECtape phenomena where each 128 
12-bit word set excludes the 129th physical word for each block, etc.

So, a pair of conversion utilites to/from ENCODE format seems to be a 
useful thing unto itself, and a solution to your specific, etc.

ENCODE format is itself documented as part of the Kermit-12 collection 
available on watsun.cc.columbia.edu or sunsite.unc.edu, etc.  See the 
file k12mit.dsk for a "roadmap" of the related files, etc.

cjl