Subject: PDP 8 emulator standards

From: [email-masked]
Date: Mon, 29 Nov 1993 04:33:00 GMT

With the number of "full function" emulators being developed, I wonder if
we ought to try to agree on some standards.

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).

    I have core image files sitting around in this format containing
    RIM, RIM+BIN and RIM+BIN+FOCAL, and if people will agree to support
    this format (or any other equally sensible standard), we can
    exchange "core images" of our machines.

    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.

2) A proposed standard for representations of paper tapes to be mounted
    on emulated high speed tape readers and punches:  This is easy -- 8
    bit wide by however long is needed binary files.  Most emulators
    allready do this, it's so obvious.

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.

    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?

4) And what about DECtapes?  I'll tackle a DECtape format someday, and
    I've previously proposed a natural one -- each pair of lines on tape
    makes up one 6 bit data byte, with the two extra bits used to hold
    the mark track.  Probably the file should start with the word DECtape,
    with the data followiing that, starting with the end-of-tape zone.
    It won't make for fast emulation, but it would be very high fidelity.

---

From: [email-masked] (Greg Ewing)
Date: Tue, 30 Nov 1993 02:06:57 GMT

In article <[email-masked]>, [email-masked] writes:
|> With the number of "full function" emulators being developed, I wonder if
|> we ought to try to agree on some standards.
|> 
|> 4) And what about DECtapes?  I'll tackle a DECtape format someday, and
|>     I've previously proposed a natural one -- each pair of lines on tape
|>     makes up one 6 bit data byte, with the two extra bits used to hold
|>     the mark track.  ...
|>     It won't make for fast emulation, but it would be very high fidelity.

This sounds like a good format to use for interchange. An emulator
wanting more speed could convert it to/from an internal format when
the tape was mounted/unmounted.

Now - are those 6-bit bytes big-endian or little-endian?
We could get into quite a religious war on that one :-)

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of Japan Inc.|
[email-masked]	   +--------------------------------------+