Image Map Image Map
Page 3 of 6 FirstFirst 123456 LastLast
Results 21 to 30 of 56

Thread: CP/M question...

  1. #21
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,062
    Blog Entries
    20

    Default

    In 1960s and 70s, tape was pretty much it--and while it may have been 7- or 9-track, there were very few conventions.

    For example, you may be given a 9-track tape from a system. Very often, the density isn't mentioned (800 NRZI, 1600 PI, 6250 GCR--and rarely, 3200 PE), so there's the first hurdle. But then, what does the data on the tape mean? You might think that you're transferring 8-bit bytes, but that's not a given. In my cases, not even the track-edness is mentioned, so Kyread is very useful.

    For example, I'm handling tapes from a Univac 1100-series mainframe. That's 36-bit words, 6-bit characters framed two words in 9 frames packed 6/2 4/4 2/6... but the same data can appear on an identically-appearing tape and be 7-track 556 bpi. The character set if printable characters is probably Univac Fieldata, which isn't the same as IBM BCD or CDC Display code (all 6 bit codes). If the tape contains machine-dependent data, such as floating point words in binary, you have to decipher the floating point format.

    Then there's record structure--fixed-length, delimited, control-word or something totally bizarre, such as CDC 00008, but only in the low-order 12 bits of a 60 bit word.

    My first run-in with DEC interchange was a tape given to me by a DEC CE from a PDP-10 system that contained the source for the "Advanture" game. 36-bit words, so 6 frames on 7-track tape per word, but for some odd reason, packed 5 7-bit ASCII characters, with the sign bit unused. It was FORTRAN, with a database file (travel tables), so it wasn't too difficult to get running on a CDC 6600.

    You get the idea--like the dog walking on its hind legs, as Boswell's quote of Samuel Johnson put it, it's not done well, but you're surprised that it's done at all.

    It keeps life interesting.
    Last edited by Chuck(G); November 11th, 2017 at 05:11 PM.

  2. #22
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    3,407
    Blog Entries
    1

    Default

    Made me happy I did not encounter 9-track until much later when routines to import and export standard tape formats were available. I had enough problems massaging distant mainframe data into the necessary local structures without also having to figure out the physical tape format.

    There was something a bit strange in retrospect having two non-IBM systems required to use an IBM format solely to enable data exchange. That applies to both big tape and floppy disks.

  3. #23
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,062
    Blog Entries
    20

    Default

    A lot of non-IBM systems used HASP RJE. For example, we used it between a VAX 11/750 and a CDC Cyber 180. And SDLC/HDLC was all over the place.

    Sort of like an Uzbek conversing with a Peruvian in English because English is everywhere.
    Last edited by Chuck(G); November 11th, 2017 at 08:04 PM.

  4. #24
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    705

    Default

    As far as 8-bit cp/m systems are concerned, what is the sector size in:

    a) single sided, double density
    b} double sided, double density

    Thank you

    ziloo

  5. #25
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    3,407
    Blog Entries
    1

    Default

    Quote Originally Posted by ziloo View Post
    As far as 8-bit cp/m systems are concerned, what is the sector size in:

    a) single sided, double density
    b} double sided, double density

    Thank you

    ziloo
    For which computer? The 8" single density had typically 128 byte sectors with double bringing that up to 256 bytes; 5.25" typically might have 256 byte, 512 byte, or 1024 byte sectors though I am sure someone did the 128 byte sector as well. At least CP/M used multiples of 128 bytes which keeps from having to deal with some of the really weird formats. I can't think of a system that had different sector sizes for single sided versus double sided at the same density but I would not be surprised if there was one.

    The shareware version of 22Disk lists a large number CP/M formats in detail.

    Variety: Good for the diet; bad for data exchange.

  6. #26
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,062
    Blog Entries
    20

    Default

    Yeah, including some oddballs, such as 128byte double-density (MFM) to 1024 in general. Organized in a wide variety of ways.

  7. #27

    Default

    As I recall, CP/M always used 128 byte buffers and used a de-blocking interface for other sector sizes. At least that is what I recall.
    I also think, most expected the first track to be 128 byte SD sectors. After that is was what ever the desired sector size was. The sector
    size is really just a function of the BIOS and as I recall, CP/M expect 128 byte buffers at a time ( as I recall ).
    Dwight

  8. #28
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,062
    Blog Entries
    20

    Default

    Dwight, your first item is correct. CP/M's bdos interface assumes 128 byte sectors , but your second is not--many many formats used the same sector size throughout. Curiously (or not) PC/MS DOS 1.x's FCB operations also assumed 128 byte sectors.

  9. #29
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    705

    Default

    Quote Originally Posted by Chuck(G) View Post
    .... Organized in a wide variety of ways.
    Quote Originally Posted by krebizfan View Post
    ... Good for the diet; bad for data exchange.
    For a single-sided single density 8" diskette everything is nice in the FCB table; but
    when the diskette capacity is double density, then things begin to get complicated:

    1- For single density: The record count (RC) in the FCB is the actual record count;
    2- For double density: The RC is not the actual record count but is related to it by
    some obscure algorithm.

    Would you please explain...


    Terminology: A record is equivalent to 128 bytes; while sector size may vary from
    one system to another, the record size is always 128 bytes.



    ziloo
    Last edited by ziloo; November 14th, 2017 at 02:07 PM.

  10. #30
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,062
    Blog Entries
    20

    Default

    It's more complicated than that. You can certainly have MFM floppies in which the one-byte record count is the actual count in the extent. But there's also an overflow field in the 13th byte (counting from 1) of the directory entry. So, although the RC byte records values of 0-127 128-byte blocks, it can overflow into the EX byte.

    The whole thing is based on having 16 bytes per extent to enumerate the blocks belonging to a file. A block is a power-of-2 multiple of 128 bytes in length, the smallest being 1024 bytes (8 128 byte sectors). So, if each allocation byte in a directory entry can describe a block of 8 sectors, you have 16*8 or 128 sectors. This worked well for single-density, single-sided 8" floppies with a capacity of (77*26)/8 = 250 blocks, but falls apart for larger disks (e.g. double-sided).

    So, CP/M gives you two choices (or a combination thereof). You can extend the block numbering to 16 bit quantities, but only hold 8 block ordinals in a directory entry. Or you can make the allocation block size larger by a power of 2 and have larger blocks, but waste more space in a block. Or you can combine both, if for example, you're working with a hard disk. In any case, when there are more than 128 128-byte "logical" sectors, in a directory entry you record the overflow in the EX field.

    So, for example, a double-sided 8" single-density floppy could use an allocation block size of 2048 and still keep 16 block ordinals in a directory entry.

    The EX field is actually divided into two fields--the low-order one relates to the overflow from the RC fiield; the upper-order bits relate to the directory ordinal.

    So, for example, a directory entry describing 256 blocks would use the low-order bit of the EX field as overflow and the bits to the left of it to number directory extents. The EXM value in the BIOS DPB for the drive is a mask that indicates where the division is.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •