Subject: Re: Archive files newly arrived

From: [email-masked] (Charles Lasner)
Date: 31 Jul 1994 10:41:16 GMT

In article <[email-masked]>,  <[email-masked]> wrote:
>
>OK, so if I have a machine with an RX50 drive (ie on an RQDX3 on a uVAX II)
>that I can do block-for-block copies to, are these images any use to me?

At least indirectly.

The problem with teledisk format is that it's proprietary.  IF you could 
figure out every nuance of the file format, you could recover the RX50 
data, etc.

However, teledisk format is far too complicated for this to be of any 
practical value, etc.  It's used currently because hardware-qualifying 
PC's can be used to format media and create copies of RX50's.  The 
program is readily available to these machines, albeit associated with a 
licensing problem, etc.  In the future, a more open format will be used 
that encourages interchange, etc.

DECmates, as well as most of DEC's systems with RX50's, cannot format
media, thus the PC is a reasonable place to turn to format diskettes. 
There are numerous programs that can do it to at least a minimally viable
extent.  (However, there are no current programs that do *all* of what
would be desirable!  Unlike the -11 and VAX world, all of the other
machines that use RX50 could benefit from alternate format options
regarding stagger and interleave.  The DECmate probably has the largest
number of desirable variants that are system-specific, but even the
Rainbow can benefit from some format variations.  The -11 and VAX world
can be congratulated for being the most consistent.  All major systems
there use the same software mapping of presumed standard media, thus there
is no need for variants, etc.)

So, if you want a PC channel to distribute your uVAX floppy RX50 images 
as binary files of the entire media, teledisk is a viable choice.  For 
the present, this is what the DECmate group has done.

In the future, the DECmate will be using a format that it can handle 
itself under OS/278.  To avoid writing pragmatic and redundant utilities, 
such a program has to wait until a more fundamental problem is solved, 
namely the ability to do raw reads and writes through OS/278 handler calls.

Present OS/278 restrictions are that handlers can only access tracks 01 
onward on a diskette, and additionally, each sector involved in a 
transfer is read in 12-bit mode, which means that only 3/4 of the data is 
accessible.  This is fine if all you want to access is the non-bootable 
file data area of an OS/278 non-system floppy.

But to create a DECmate bootable diskette requires 100% of the data in 
every sector, including sectors 1-10 on tracks 0, 78, 79.  Diskettes 
"alien" to the DECmate will tend to have other usage of these same 
tracks, and you dare not leave them out of a claimed copy of a diskette, etc.

Current OS/278 has only kludgy limited ability to access the rest of the 
diskette data, consisting of internal routines in a few programs, none of 
which provide user access to anything resembling a generic call, etc.  
(In essence, a few programs have internal subroutines used as required.  
Quality of I/O handling varies widely, etc.)

There is a solution to this problem which has been discussed elsewhere, 
namely to allow OS/278 to access P?S/8-written handlers, which include a 
handler being developed for complete access to RX50.  Using an approach 
some people know as a "TSR" it is possible for OS/278 to get "help-out" 
RX50 support from P?S/8 handlers

Once this is accomplished, RX50 files wihtout restrictions can be 
generated using a variety of methods on DECmate hardware.  The principal 
candidate currently is PDP-8 ENCODE format which is documented in the 
Kermit-12 distribution.  Other machines should be able to support ENCODE 
decoders/encoders allowing this to become a more general method of 
interchange, etc.

Got any volunteers to write ENCODE utilities for other machines (VAX, PC, 
etc.)?

cjl

---

From: [email-masked] (Don Stokes)
Date: 1 Aug 1994 11:21:55 GMT

>figure out every nuance of the file format, you could recover the RX50 

So is there any chance of just getting the raw disk image in ZIP or whatever
format so that those of us who can do a bit-for-bit copy onto a real RX50
can use it without having to futz around with that brand-M bootstrap and
a commercial package that I don't want or need?

How about disk images of the DECmate backup format for thems of us with
hard disk DECmates?

-- 
Don Stokes, Network Manager, Victoria University of Wellington, New Zealand.
[email-masked](work) [email-masked](home) +64 4 495-5052 Fax+64 4 471-5386

---

From: [email-masked] (Charles Lasner)
Date: 5 Aug 1994 17:33:50 GMT

In article <[email-masked]>,
>a commercial package that I don't want or need?
There are several efforts in this direction.  teledisk represents a poor 
choice due to all of its "baggage" etc. but it does exist.

One such effort involves creating (on a PC) a format that is just about 
what you want.  The file starts with a header block that describes the 
disk geometry.  The rest of the file is the raw 8-bit data in the normal 
order of the disk.  Thus, in the RX50 case it would be the 800 sectors of 
the RX50 in the order track 0 sectors 1,2,3,4,5,6,7,8,9,10 then track 1, 
etc.  RX50 would be a normal case, but it's not geared specifically to it.

Note that this effort includes no form of compression, which admittedly 
is easier to deal with for your purposes.

but since storage is a concern for an archive, files should be 
compressed, or should be self-compressing.  PDP-8 ENCODE format is a good 
step in that direction.  I would like to see others implement encoders 
and decoders of it for other machines, etc.  Eventually the DECmate 
version will be viable; the PDP-8 version is currently.

>How about disk images of the DECmate backup format for thems of us with

Not a bad idea.  However, there is a problem: you have to specify a 
volume size for the backup set.  Do you want volumes created that barely 
serve as the data itself, or do you want volumes created with loads of 
empty space past the data that represents someone's notion of a good size 
for a volume?  Additionally, there is the whole question of whether the 
data is also a bootable volume since invariably the data is in the format 
of some specific OS such as OS/278, COS, WPS, CP/M-80, MS-DOS, etc.

Consider a small example:

There is a program now available on sunsite called GTE that makes the 
DECmates II and up into a VT-240/241 if you have the relevant graphics 
hardware and optional color monitor.  Even without the extra hardware, 
you still get a good VT-220 emulator with a whole lot less bugs than the 
slushware terminal emulator, etc.

Consider all of the possibilities for archiving:

1)	It's already there in a .zip of a teledisk file of the 
release/install disk.  The user has to put the program up and deal with 
it, etc.

2)	Someone could install it and thus there is a hard disk volume or 
diskette copy.  We could archive the bootable diskette, but it's not 
worth it because it's so easy to create one from the install diskette, 
except perhaps on (your!) DECmate III+.  However, a hard disk volume 
version can be created on either a DECmate II w/HD or on the DM III+.  
You could archive a backup copy of that volume.

However, it turns out that this is not necessarily the best choice.  The 
program can be transferred directly to an exiting OS/278 system and run 
with "R GTE" because in reality, the bootable volume or diskette is 
really a self-starting OS/278 stripdown system, etc.

Additionally, the install program creates GTE on a volume slightly too 
large, thus disk space gets wasted.  A knowledgeable user can create 
their own custom size volume with OS/278 on it, then move GTE.SV there 
and do it themselves as a minimal size application, etc.

So, which of the several forms the above suggest would you want to be in 
the archive?  Note that the average user can navigate through the 
provided install diskette now archived, etc.  The results are likely 
acceptable to all but sophisticated users, etc.

Other programs will tend to suggest even more complicated 
configurations.  I'm open to any reasonable solution.

cjl