Subject: Re: PDP 8 emulator standards

From: [email-masked] (Charles Lasner)
Date: 12 Dec 1993 23:48:02 GMT

In article <[email-masked]>,
 <[email-masked]> wrote:
>With the number of "full function" emulators being developed, I wonder if
>we ought to try to agree on some standards.

I'm all for that!

>
>1) A proposed standard for the core image file, saved on emulator
>    shutdown and loaded on startup:  I am using Lasner's IPL file
>    format, with the added rule that line 1 of the file may begin
>    with the characters #!, followed by the absolute path name of
>    the emulator (thus allowing the system to be named and run by
>    the name of its core image file under UNIX).

Got a problem with that one.  The data characters of the .IPL format are 041
through 140 or ! through `.  The file format starts with leader outside that
range thus lower-case comments are allowed.  Codes 000-040 are always ignored
so that nul's and space characters can always be added, etc.

By starting with #!, you are stating there is no leader, and that these two are
the first data word for loading into location 0000.  Usually a path name would
be lower-case, thus a trailer situation ensues, and the loading is terminated.

Remember, the IPL format was designed to allow a minimal loader for the real
PDP-8 using printable characters to avoid binary problems.  By ignoring
spaces, nul's, CR, LF, etc. it allows the files to be "friendly" to virtually
any system.  Your suggestion undermines this.

So, I suggest you use your format as an appendage to be removed from a "real"
IPL file.

>
>    Lasner's IPL format allows comments, and a nice standard use
>    for these comments would be to indicate what devices the core
>    image expects to be supported by its emulator.

The leader must be lower-case.  The first character in the character
set from ! through ` is the first data character.  The next time a
lower-case character is seen means that the trailer has occurred.  At
that point, anything could be added.  In Kermit-12 release files, there
are lower-case comments at the beginning and mixed-case comments at the
end.

>3) A proposed standard for representing RX01 diskettes emulated on a
>    host system.  I'm using C streams for this, with random access to
>    128 byte blocks of the stream representing sectors of the disk.
>    Sector zero of the stream is reserved.  The first 4 bytes of the
>    file must be rx01.  I haven't started to deal with any uses for
>    other bytes, but the following suggest themselves:
>
>    1) an indication of how the disk is formatted -- specifically, how
>       are the sectors interleaved.  The actual address of the sector
>       in the file is computed by adding the sector number to the track
>       number times the number of sectors per track, but access latency
>       depends on the interleave factor.

RX01 disks are *never* interleaved.  The software requests the sectors in an
appropriately interleaved order.  Not a concern of an emulator, other
than to make good access to the sectors when referenced in a mapped
manner that's implicitly mapped 2:1 expressly, possibly augmented by a
stagger factor (usually 6).

>
>    2) a bit table of which sectors are "deleted".  This feature of the
>       RX01 is one I don't intend to support, but I suppose we should
>       reserve space for the table anyway.  Does it even fit in 128
>       bytes?  Is it worth supporting?

In theory, any and all sectors could be marked as deleted.  The returned
status during a read would show this if appropriate.  Thus you need enough
bits to represent 77 x 26 sectors' deletion status.  There is no reason not
to support the feature; you just support the function to write a deleted-data
segment so that it reads back correctly with the status set.  Only incidentally
more complicated than the read/write basic requirement, and needed to pass the
diagnostics!

cjl