Kaypro Format - CP/M

This is a discussion on Kaypro Format - CP/M ; I seem to recall back in it's heyday, and I may be wrong, but it seemed that just about all CP/M software was available in Kaypro format. Was that because the Kaypro was the most popular or because the Kaypro ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 27

Thread: Kaypro Format

  1. Kaypro Format

    I seem to recall back in it's heyday, and I may be wrong, but it seemed
    that just about all CP/M software was available in Kaypro format. Was
    that because the Kaypro was the most popular or because the Kaypro
    format was generic enough for other computers to read?

    Bill H - www.ts1000.us


  2. Re: Kaypro Format

    I don't think I'd say that Kaypro was "THE" most popular anything, but
    it had, along with many other brands, reached "critical mass". There
    was no single standard format for 5.25" media, so generally you had to
    get a model specific format. In general, computers only read their own
    formats.


    Bill H wrote:

    > I seem to recall back in it's heyday, and I may be wrong, but it seemed
    > that just about all CP/M software was available in Kaypro format. Was
    > that because the Kaypro was the most popular or because the Kaypro
    > format was generic enough for other computers to read?
    >
    > Bill H - www.ts1000.us
    >


  3. Re: Kaypro Format

    On 10 Jan 2006 15:40:53 -0800, "Bill H" wrote:

    >I seem to recall back in it's heyday, and I may be wrong, but it seemed
    >that just about all CP/M software was available in Kaypro format. Was
    >that because the Kaypro was the most popular or because the Kaypro
    >format was generic enough for other computers to read?
    >
    >Bill H - www.ts1000.us


    Not quite. Several factors at work. One being Kaypro format was
    nothing special and many other machines did same. the other was most
    kaypro owners had uniform or one of the other multiformat programs.
    Turborom also could havedle more than one format.

    Oh Kaypro was really two maybe three formats! There was 40tr SSDD,
    40tr DSDD and some say 80track dsdd also. If you had turborom with
    personality card the latter was possible (also worked with 720/781k
    3.5" floppies).

    Other machines that were compatable with 40tr DSDD:

    Ampro (LB LB+ and later)
    SB180
    PC 360k was same media and base format (9spt/40tr/2sided/512bytes)

    I'm sure there were others but I forget. Maybe others can extend
    the list.

    Anywho if you had DD 40tr 2 sided there were a very good likelyhood
    that the system with could read other media that was 40tr 2sides DD.
    Where the significant difference was seen in data and program transfer
    rather than bootable media. Bootable media had to match the hardware
    but often even if the media didn't boot it was readable. For example
    most Ampro with amprodsk could read (data and files) VT180, Rainbow,
    SB180, Kaypro, and bunches of others that were digestable with 5.25
    40tracks.


    Allison

  4. Re: Kaypro Format

    On 10 Jan 2006 15:40:53 -0800
    "Bill H" wrote:

    > I seem to recall back in it's heyday, and I may be wrong, but it
    > seemed that just about all CP/M software was available in Kaypro
    > format. Was that because the Kaypro was the most popular or because
    > the Kaypro format was generic enough for other computers to read?


    One oddball feature of the Kaypros was that the sector numbering began
    with 0, while most other systems began with 1. That allowed the
    Ampro/SB180/On! format with 10-512 byte sectors (beginning with 1) to
    co-exist with Kaypro 10-512 byte sectors in auto-select systems by
    sensing for a 'sector 0' which signified Kaypro.

    Hal

  5. Re: Kaypro Format

    On Wed, 11 Jan 2006 09:26:43 GMT, Hal wrote:

    >On 10 Jan 2006 15:40:53 -0800
    >"Bill H" wrote:
    >
    >> I seem to recall back in it's heyday, and I may be wrong, but it
    >> seemed that just about all CP/M software was available in Kaypro
    >> format. Was that because the Kaypro was the most popular or because
    >> the Kaypro format was generic enough for other computers to read?

    >
    >One oddball feature of the Kaypros was that the sector numbering began
    >with 0, while most other systems began with 1. That allowed the
    >Ampro/SB180/On! format with 10-512 byte sectors (beginning with 1) to
    >co-exist with Kaypro 10-512 byte sectors in auto-select systems by
    >sensing for a 'sector 0' which signified Kaypro.
    >
    >Hal


    I don't think so.

    Allison



  6. Re: Kaypro Format

    On Wed, 11 Jan 2006 12:37:56 GMT
    Allison-nospam@nouce.bellatlantic.net wrote:

    > On Wed, 11 Jan 2006 09:26:43 GMT, Hal wrote:


    > >One oddball feature of the Kaypros was that the sector numbering
    > >began with 0, while most other systems began with 1. That allowed
    > >the Ampro/SB180/On! format with 10-512 byte sectors (beginning with
    > >1) to co-exist with Kaypro 10-512 byte sectors in auto-select systems
    > >by sensing for a 'sector 0' which signified Kaypro.

    >
    > I don't think so.


    Yes Allison, it's true. I have SS and DS Kaypro (natively formatted)
    from Alpha and Beta testing DateStamperII and BackGrounder from Bridger
    Mitchell who did most (if not all) of his work on Kaypros. Believe me,
    Sector numbers are from 0 thru 9.

    The auto-select routine in Ampro Little Boards and SB180s (as well as
    the Oneac On! and others) follows, in part, the following algorithm:

    Home heads (done twice for 795 controllers)
    Step in twice with No verify
    Read Sector ID
    If Track=1 then drive is 40 track (it double-stepped)
    ...
    If Sector Size=512 bytes
    Search for Sector 0 (Alternatively read 10 sequential ReadIDs
    checking for Sector 0)
    If found, Then Kaypro 40 track
    Else Ampro 40 track

    Logic in this flavor is also incorporated in the B/P Bios code.

    Hal

  7. Re: Kaypro Format

    On Wed, 11 Jan 2006 19:51:10 GMT, Hal wrote:

    >On Wed, 11 Jan 2006 12:37:56 GMT
    >Allison-nospam@nouce.bellatlantic.net wrote:
    >
    >> On Wed, 11 Jan 2006 09:26:43 GMT, Hal wrote:

    >
    >> >One oddball feature of the Kaypros was that the sector numbering
    >> >began with 0, while most other systems began with 1. That allowed
    >> >the Ampro/SB180/On! format with 10-512 byte sectors (beginning with
    >> >1) to co-exist with Kaypro 10-512 byte sectors in auto-select systems
    >> >by sensing for a 'sector 0' which signified Kaypro.

    >>
    >> I don't think so.

    >
    >Yes Allison, it's true. I have SS and DS Kaypro (natively formatted)
    >from Alpha and Beta testing DateStamperII and BackGrounder from Bridger
    >Mitchell who did most (if not all) of his work on Kaypros. Believe me,
    >Sector numbers are from 0 thru 9.
    >
    >The auto-select routine in Ampro Little Boards and SB180s (as well as
    >the Oneac On! and others) follows, in part, the following algorithm:
    >
    > Home heads (done twice for 795 controllers)
    > Step in twice with No verify
    > Read Sector ID
    > If Track=1 then drive is 40 track (it double-stepped)
    > ...
    > If Sector Size=512 bytes
    > Search for Sector 0 (Alternatively read 10 sequential ReadIDs
    >checking for Sector 0)
    > If found, Then Kaypro 40 track
    > Else Ampro 40 track
    >
    >Logic in this flavor is also incorporated in the B/P Bios code.
    >
    >Hal


    Save for one thing. The source for the Ampro 3.8 bios doesn't
    confirm that. So considering I had to edit my bios for a 45mb SCSI
    it's vaguely familiar.

    Of course that would make formatting or creating a kaypro disk
    impossible for any system using 765based FDC. It's not supposed
    permit sector number 0. The spec says it's not supposed to work
    and tends to cause sector not found errors. That and IBM thought it
    was a lousy idea for the standard 8" formats.

    I'm still trying to get B/P bios to work on SB180. The orignial
    and one I wrote works so I know the hardware is good.


    Allison

  8. Re: Kaypro Format

    On Wed, 11 Jan 2006 20:42:11 GMT
    Allison-nospam@nouce.bellatlantic.net wrote:

    > Save for one thing. The source for the Ampro 3.8 bios doesn't
    > confirm that. So considering I had to edit my bios for a 45mb SCSI
    > it's vaguely familiar.


    I think my Ampro has one with mods by either Joe Wright or Bruce Morgen
    and has the code. It may be in the E: drive section, but it's been
    years since mine has been powered up, and for the time being, I can't
    even get to it (my reason for slow cleaning out).

    > Of course that would make formatting or creating a kaypro disk
    > impossible for any system using 765based FDC. It's not supposed
    > permit sector number 0. The spec says it's not supposed to work
    > and tends to cause sector not found errors. That and IBM thought it
    > was a lousy idea for the standard 8" formats.


    Agree. I don't know of another system that did it, but there was a way
    to get the 765-based (including the 9266 used in the SB180/SB180FX) to
    get it to work, but it's not pretty. An even worse one was a system
    that used a byte of 0FFH instead of the 'standard' 01H for the index
    sector byte reserved for the 'Head' value for the second (head 1) side.
    I could never read those disks on anything but WD controllers.

    > I'm still trying to get B/P bios to work on SB180. The orignial
    > and one I wrote works so I know the hardware is good.


    Let me know what your problems are (EMail addr is good) and I'll try to
    help.

    Hal

  9. Re: Kaypro Format

    >>> >One oddball feature of the Kaypros was that the sector numbering
    >>> >began with 0, while most other systems began with 1.


    >>> I don't think so.


    >Save for one thing. The source for the Ampro 3.8 bios doesn't
    >confirm that. So considering I had to edit my bios for a 45mb SCSI
    >it's vaguely familiar.


    Kaypro disks are indeed numbered from sector 0 to 9. They also
    appear to be interleaved 4:1. Another "interesting" thing about
    Kaypro disks is that side-1 has the head field set to 0, and the
    sectors are numbered 10-19 (someone along the way must
    have thought it would be cool to think of a DS disk as one big
    logical track).

    Here is my IMDU utilitiy /D output for an image made from an
    original master Kaypro disk:

    IMageDisk Utility 1.09
    IMD 1.01: 3/08/2005 9:41:23
    KAYPRO MASTER
    CP/M version 2.2
    Copyright 1983 by Digital Research, Inc.
    S-BASIC
    Copyright 1983 Non-Linear Systems, Inc.
    0/0 250 kbps DD 10x512
    0 8 3 6 1 9 4 7 2 5
    D D D D D D D D D D
    0/1 10 18 13 16 11 19 14 17 12 15
    HD: 0 0 0 0 0 0 0 0 0 0
    D D CE5 D D C00 D CE5 CE5 D
    1/0 0 8 3 6 1 9 4 7 2 5
    C00 D D D C00 D D D C00 D
    1/1 10 18 13 16 11 19 14 17 12 15
    HD: 0 0 0 0 0 0 0 0 0 0
    D D D D D D D D D D
    ... remaining tracks deleted ...
    80 tracks (40/40), 801 sectors (0 unavail, 524 data, 276 compressed)

    Note the sector numbering, and the presense of a "Sector Head map"
    record for the side 1 tracks indicating that it actually indicates head 0.

    >Of course that would make formatting or creating a kaypro disk
    >impossible for any system using 765based FDC. It's not supposed
    >permit sector number 0. The spec says it's not supposed to work
    >and tends to cause sector not found errors. That and IBM thought it
    >was a lousy idea for the standard 8" formats.


    No it doesn't - although it's officially not recommended, I have never
    yet encountered a 765 which had trouble with it. ImageDisk has no
    trouble reading/writing Kaypro disks.

    When I first designed my Cubix 6809 system, it was my first design
    with a 765 controller, and not knowing any better I numbered the
    sectors from zero ... Used a number variations of that system for
    many years, and never had disk problems (and never did change
    the sector numbering).


    >I'm still trying to get B/P bios to work on SB180. The orignial
    >and one I wrote works so I know the hardware is good.


    SB-180 also has an interesting sector numbering - as you can
    see from the IMDU otput below, sectors are numbered from
    17-26 with an interleave of 2:1 (at least the heads are indicated
    correctly):

    IMageDisk Utility 1.09
    IMD 1.06: 28/09/2005 7:38:31
    SB180-20
    ZCPR System Master
    1 of 4
    0/0 250 kbps DD 10x512
    17 22 18 23 19 24 20 25 21 26
    D D D D D D D D D D
    0/1 D D D D D D D D D D
    1/0 D CE5 D CE5 D CE5 D D D CE5
    1/1 CE5 D CE5 D D D D D D D
    ... remaining tracks deleted ...
    80 tracks (40/40), 800 sectors (0 unavail, 630 data, 170 compressed)


    Dave

    --
    Dunfield Development Systems http://www.dunfield.com
    Low cost software development tools for embedded systems
    Software/firmware development services Fax:613-256-5821


  10. Re: Kaypro Format

    >Agree. I don't know of another system that did it, but there was a way
    >to get the 765-based (including the 9266 used in the SB180/SB180FX) to
    >get it to work, but it's not pretty.


    As noted above, I've never had trouble getting a 765 to work with sector
    number 0. I don't think this is as big an issue as is being made out.

    >An even worse one was a system
    >that used a byte of 0FFH instead of the 'standard' 01H for the index
    >sector byte reserved for the 'Head' value for the second (head 1) side.
    >I could never read those disks on anything but WD controllers.


    I would be very interested in knowing what ImageDisk does when
    presented with these disks - It will maintain a "sector head map"
    when the head values don't match the physical head selection,
    and can even handle different head values among the sectors
    on a single track/side (by mapping them individually). In the
    Kaypro example I just posted, you could see that it was generating
    a "sector head map" to indicate that the sectors on side-1 were
    actually numbered as 0 - unless FF is a special case to the
    controller (perhaps the controller checkes that the value is 0/1?)
    this should not matter to ImageDisk...

    If you could check this for me, I would very much appreciate it.

    --
    Dunfield Development Systems http://www.dunfield.com
    Low cost software development tools for embedded systems
    Software/firmware development services Fax:613-256-5821


  11. Re: Kaypro Format

    On Thu, 12 Jan 2006 09:34:23 GMT, Hal wrote:

    >On Wed, 11 Jan 2006 20:42:11 GMT
    >Allison-nospam@nouce.bellatlantic.net wrote:
    >
    >I think my Ampro has one with mods by either Joe Wright or Bruce Morgen
    >and has the code. It may be in the E: drive section, but it's been
    >years since mine has been powered up, and for the time being, I can't
    >even get to it (my reason for slow cleaning out).


    Yes, Edrive is there and thats very useful with the DOS utility.

    >Agree. I don't know of another system that did it, but there was a way
    >to get the 765-based (including the 9266 used in the SB180/SB180FX) to
    >get it to work, but it's not pretty. An even worse one was a system
    >that used a byte of 0FFH instead of the 'standard' 01H for the index
    >sector byte reserved for the 'Head' value for the second (head 1) side.
    >I could never read those disks on anything but WD controllers.


    One of the really nice features of WD controllers is they allowed
    all manner of bad things.

    >Let me know what your problems are (EMail addr is good) and I'll try to
    >help.


    I put it aside a while ago. When I get back to it. I know the
    problem is in the floppy drivers as I keep getting all mannor
    of errors from the FDC. I just didn't troubleshoot it deeply
    at the time. FYI: that system uses 3.5" 720/718k floppies.

    Allison


  12. Re: Kaypro Format

    >>An even worse one was a system
    >>that used a byte of 0FFH instead of the 'standard' 01H for the index
    >>sector byte reserved for the 'Head' value for the second (head 1) side.
    >>I could never read those disks on anything but WD controllers.


    >I would be very interested in knowing what ImageDisk does when
    >presented with these disks - It will maintain a "sector head map"
    >when the head values don't match the physical head selection,
    >and can even handle different head values among the sectors
    >on a single track/side (by mapping them individually). In the
    >Kaypro example I just posted, you could see that it was generating
    >a "sector head map" to indicate that the sectors on side-1 were
    >actually numbered as 0 - unless FF is a special case to the
    >controller (perhaps the controller checkes that the value is 0/1?)
    >this should not matter to ImageDisk...


    I just did a test where I manually inserted a sector-head-map
    indicating all FF values for the head into a .IMD image and then
    created a physical disk from it. Upon re-reading that disk, the
    new .IMD exactly matches the original (ie: the FF values were
    both written to and read back from the head values in the sector
    headers) - so I don't think this is a major issue with the 765
    controller either.

    Perhaps there is something else about these disks which is
    causing trouble - I would still be very interested in getting to the
    bottom of it, as I am endevoring to make ImageDisk work with
    as many "odd" formats as possible.

    Dave

    --
    Dunfield Development Systems http://www.dunfield.com
    Low cost software development tools for embedded systems
    Software/firmware development services Fax:613-256-5821


  13. Re: Kaypro Format

    On Thu, 12 Jan 2006 13:21:51 GMT,
    Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield)
    wrote:

    Media compatability even between systems using very similar
    hardware was/is one of the main problems I've encountered
    for the last 30 years. Even now when I drag out a box there is
    a box of media associated with it that is unique to it. Often the
    media box is larger than the system!

    >Kaypro disks are indeed numbered from sector 0 to 9. They also
    >appear to be interleaved 4:1. Another "interesting" thing about
    >Kaypro disks is that side-1 has the head field set to 0, and the
    >sectors are numbered 10-19 (someone along the way must
    >have thought it would be cool to think of a DS disk as one big
    >logical track).


    Maybe why the ampro using amprodsk is one of the few machines
    that can read kaypro native media using a program to set up
    the FDC for compatability.

    I never willingly program floppy systems to produce a sector zero
    or munge the field bits as it is likely to induce errors.

    >Here is my IMDU utilitiy /D output for an image made from an
    >original master Kaypro disk:
    >
    >IMageDisk Utility 1.09
    >IMD 1.01: 3/08/2005 9:41:23
    >KAYPRO MASTER
    >CP/M version 2.2
    >Copyright 1983 by Digital Research, Inc.
    >S-BASIC
    >Copyright 1983 Non-Linear Systems, Inc.
    > 0/0 250 kbps DD 10x512
    > 0 8 3 6 1 9 4 7 2 5
    > D D D D D D D D D D
    > 0/1 10 18 13 16 11 19 14 17 12 15
    > HD: 0 0 0 0 0 0 0 0 0 0
    > D D CE5 D D C00 D CE5 CE5 D
    > 1/0 0 8 3 6 1 9 4 7 2 5
    > C00 D D D C00 D D D C00 D
    > 1/1 10 18 13 16 11 19 14 17 12 15
    > HD: 0 0 0 0 0 0 0 0 0 0
    > D D D D D D D D D D
    > ... remaining tracks deleted ...
    >80 tracks (40/40), 801 sectors (0 unavail, 524 data, 276 compressed)
    >
    >Note the sector numbering, and the presense of a "Sector Head map"
    >record for the side 1 tracks indicating that it actually indicates head 0.
    >
    >>Of course that would make formatting or creating a kaypro disk
    >>impossible for any system using 765based FDC. It's not supposed
    >>permit sector number 0. The spec says it's not supposed to work
    >>and tends to cause sector not found errors. That and IBM thought it
    >>was a lousy idea for the standard 8" formats.

    >
    >No it doesn't - although it's officially not recommended, I have never
    >yet encountered a 765 which had trouble with it. ImageDisk has no
    >trouble reading/writing Kaypro disks.


    I've found higher error rates usually sector not found errors. I
    consider what kaypro did to be just bad.

    >When I first designed my Cubix 6809 system, it was my first design
    >with a 765 controller, and not knowing any better I numbered the
    >sectors from zero ... Used a number variations of that system for
    >many years, and never had disk problems (and never did change
    >the sector numbering).


    Using the 9216 helps there but the 765 is not spec'ed for it.

    It was one of the odd things Tim and I discovered about formats
    along the way.

    >>I'm still trying to get B/P bios to work on SB180. The orignial
    >>and one I wrote works so I know the hardware is good.

    >
    >SB-180 also has an interesting sector numbering - as you can
    >see from the IMDU otput below, sectors are numbered from
    >17-26 with an interleave of 2:1 (at least the heads are indicated
    >correctly):


    I considered that a oddity as well. Everyone wanted to use a generic
    FDC/Floppy but prevent interchange it would appear. Yet almost
    without fail an interchange tool is provided.

    Begs the question why not program the floppy correctly instead of
    playing games? If there was any one serious handicap to program
    development and interchange it was the CP/M exchange media
    problem. CP/M was a software bus short circuited by similar but
    incompatable media. Often the solution short of transfer by serial
    line was if you were lucky enough to have 8" and could do SSSD you
    could. I have more than a dozen systems with 5.25" floppies and I
    think four of the soft sectored systems can exchange media without
    resorting to an exchange media program like multidsk or uniform.
    Even that's because I rewrote the bios. After a while I resorted to
    leaving out floppies and using either romdisk or fast serial protocal
    to use disk resources on on of the bigger CP/M crates.


    Allison

  14. Re: Kaypro Format

    On Thu, 12 Jan 2006 13:30:16 GMT,
    Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield)
    wrote:

    >As noted above, I've never had trouble getting a 765 to work with sector
    >number 0. I don't think this is as big an issue as is being made out.


    I've used imagedisk from early versions on for experimenting and
    it works. Why, I'm still not sure. Bullet proof programming no
    doubt.

    >I would be very interested in knowing what ImageDisk does when
    >presented with these disks - It will maintain a "sector head map"
    >when the head values don't match the physical head selection,
    >and can even handle different head values among the sectors
    >on a single track/side (by mapping them individually). In the
    >Kaypro example I just posted, you could see that it was generating
    >a "sector head map" to indicate that the sectors on side-1 were
    >actually numbered as 0 - unless FF is a special case to the
    >controller (perhaps the controller checkes that the value is 0/1?)
    >this should not matter to ImageDisk...
    >
    >If you could check this for me, I would very much appreciate it.


    Right now no facilities to test that. I only have the NS* hard
    sector based systems out and in use.

    Allison

  15. Re: Kaypro Format

    On Thu, 12 Jan 2006 13:30:16 GMT
    Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield) wrote:

    > >Agree. I don't know of another system that did it, but there was a
    > >way to get the 765-based (including the 9266 used in the
    > >SB180/SB180FX) to get it to work, but it's not pretty.

    >
    > As noted above, I've never had trouble getting a 765 to work with
    > sector number 0. I don't think this is as big an issue as is being
    > made out.


    It's not a big thing, but it takes a few extra bytes of code. IIRC if
    you read a number of sectors sequentially that span a track, the sector
    number auto-increments, but wraps to 1 on a new track. This must be
    decremented in software before a read (or a table-lookup).

    > >An even worse one was a system
    > >that used a byte of 0FFH instead of the 'standard' 01H for the index
    > >sector byte reserved for the 'Head' value for the second (head 1)
    > >side. I could never read those disks on anything but WD controllers.

    >
    > I would be very interested in knowing what ImageDisk does when
    > presented with these disks


    The particular system this troublesome format came from had a byte of
    '0' in the ID record for head 0, but 'FF' for head 1. When you check
    it, be sure you are using double-sided disks and drive.

    Hal

  16. Re: Kaypro Format

    On Thu, 12 Jan 2006 12:46:10 GMT
    Allison-nospam@nouce.bellatlantic.net wrote:

    > On Thu, 12 Jan 2006 09:34:23 GMT, Hal wrote:


    > One of the really nice features of WD controllers is they allowed
    > all manner of bad things.


    And good things. I used the raw track read feature (and counted bytes)
    to identify Gap1, 2, 3 and 4a/b sizes for some oddball formats.
    Couldn't seem to do this with 765 controllers that had hardwired sizes
    for most gaps.

    > >Let me know what your problems are (EMail addr is good) and I'll try
    > >to help.

    >
    > I put it aside a while ago. When I get back to it. I know the
    > problem is in the floppy drivers as I keep getting all mannor
    > of errors from the FDC. I just didn't troubleshoot it deeply
    > at the time. FYI: that system uses 3.5" 720/718k floppies.


    If that is your format, you need to adjust the disk data definitions to
    either hardwire the format (AUTOSEL == FALSE) or install your format in
    the DPB.LIB file while removing conflicting formats for the
    autoselector. Since one goal of the B/P Bios effort was to have a
    common base of utilities and formats for a number of systems (to clear
    the clutter of different 'stuff'), we adopted the Ampro LB/SB180/On!
    formats (as previously stated) which were non-conflicting. From memory:
    40-track
    SS - 512 byte sectors numbered 1..10
    DS - 512 byte sectors numbered 17..26
    80-track
    SS - 1024 byte sectors numbered 1..5
    DS - 1024 byte sectors numbered 17..21

    The algorithm can then use 512-byte sectors for 40-track drives (home,
    then step in 2 tracks to see if it is an 80-track drive double-stepping)
    and 1024 byte sectors for 80-track drives. Comparing the sector number
    to 16 (10H) will tell if it is double-sided (No Carry) or Single-sided
    (Carry Flag set).

    For B/P Bios on systems that support High-Density, this also adds some
    more, including
    3.5" DS - 512 byte sectors numbered 1..18 (1.44 MB)
    and DS - 1024 byte sectors numbered 49..59 (1.76 MB)

    The algorithm here is extended by trying to read a sector ID in high
    density failing to the Ampro formats on error, else checking these
    formats (the 1.76 MB format is offset by 30H since 20H was used by
    Malcolm Kemp in his XBIOS for SB180s to signify an 800KB (80track DSQD)
    format with no system (to gain another 10KB of data storage).

    Allison, for your 720/718k format, probably the easiest thing would be
    to remove the 40-track SS format and insert yours modifying the bits in
    the extended DPB to signify 80-track DS in the appropriate format
    (DPB.LIB should have all the data explanations). I had added that
    format when first doing the P112 port in '95 and the IBM 1.44 MB format
    when porting it to the SuperIO S100 card for the Imsai2.

    Hal

  17. Re: Kaypro Format

    On Thu, 12 Jan 2006 19:53:58 GMT, Hal wrote:

    >On Thu, 12 Jan 2006 13:30:16 GMT
    >Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield) wrote:
    >
    >> >Agree. I don't know of another system that did it, but there was a
    >> >way to get the 765-based (including the 9266 used in the
    >> >SB180/SB180FX) to get it to work, but it's not pretty.

    >>
    >> As noted above, I've never had trouble getting a 765 to work with
    >> sector number 0. I don't think this is as big an issue as is being
    >> made out.

    >
    >It's not a big thing, but it takes a few extra bytes of code. IIRC if
    >you read a number of sectors sequentially that span a track, the sector
    >number auto-increments, but wraps to 1 on a new track. This must be
    >decremented in software before a read (or a table-lookup).


    Side effect of the internal controller of the 765 that drives the
    serial engine.

    >The particular system this troublesome format came from had a byte of
    >'0' in the ID record for head 0, but 'FF' for head 1. When you check
    >it, be sure you are using double-sided disks and drive.


    Often it just hangs waiting for something it will never see. If the
    data sep is free running it may fall through on seeing index twice
    but don't count on it.

    Allison

  18. Re: Kaypro Format

    On Thu, 12 Jan 2006 20:19:32 GMT, Hal wrote:

    >Allison, for your 720/718k format, probably the easiest thing would be
    >to remove the 40-track SS format and insert yours modifying the bits in
    >the extended DPB to signify 80-track DS in the appropriate format
    >(DPB.LIB should have all the data explanations). I had added that
    >format when first doing the P112 port in '95 and the IBM 1.44 MB format
    >when porting it to the SuperIO S100 card for the Imsai2.


    The most direct is no autosense as the prefered format is 720k/3.5"
    (512b/9spt/80tr/2h). Like I said right now I'm not looking at it and
    when I revisit it I have two different sets of code I know works
    (as delievered SB180 and my driver/bios using 512byte sectors).
    At the time I was looking at B/P bios it was for the banked portion
    to get a larger TPA as the hard disk (via SCSI adaptor) eats space
    with the disk tables(20mb scsi). Since it's a been a few years
    since I messed with it and rarely use that system. I need to get
    back to it and revamp the EPROM, BIOS and repackage in a
    more convenient smaller case with a 3.5" 42mb scsi disk rather
    than a SCSI host adaptor/st225 combo.

    As I've said before the prefered format here is 512b/9SPT/2side/80tr
    as I can do that with 3.5" drives. Base format on media is sectors
    start with 1-9 each side, no funnies, no skew. the last item, skew
    is because I buffer at least one sector and theres little point in
    skewing if the next sector is likely in the buffer. I've been in the
    process on and off for years of getting all my CP/M systems to that
    format between other projects. So far:

    AmproLB Modified bios (3-8 as base)
    SB180 (my bios)
    VT180 (board set up as standalone and 2side mod added, my bios)
    S100 (my banked Z80 system with multiple controllers my design and
    bios)

    The idea being I can read read files without worry on any system
    and reduce media to one primary type.


    Allison

  19. Re: Kaypro Format

    >>When I first designed my Cubix 6809 system, it was my first design
    >>with a 765 controller, and not knowing any better I numbered the
    >>sectors from zero ... Used a number variations of that system for
    >>many years, and never had disk problems (and never did change
    >>the sector numbering).


    >Using the 9216 helps there but the 765 is not spec'ed for it.


    I've seen you mention this before, however my "bible" used for
    developing my code for the 765 is the datasheet from the 1982
    NEC databook, and I cannot find any reference, specific or
    otherwise to it not supporting sector #0.

    As far as the hardware goes, the controller is already synced by
    the time it scans for C, H and R ... This is just "data" to the bitstream,
    and a 00 value should be read just as easily as a C=00 or H=00
    value (or a whole sector filled with 00 for that matter). If there were
    a function in the chip logic which rejected R=00 then I would expect
    it to simply fail - not "be less reliable" which suggests a hardware
    reason.

    The only sector-0 issue I know of with the 765 is that it "wraps" to
    sector 1 if you use multi-sector operations spanning a track - but I
    would guess that this is for compatibility with IBM formats, not for a
    hardware reason.

    If there were a true hardware reason to not allow 00 in the header,
    then why not also avoid 00 in the C and H values - after all it would
    be completely reasonable to call them cylinders 1-78 or heads 1
    and 2. I strongly suspect that it was just an arbitrary decision by IBM
    to numbers the 26 sectors on a track as 1...26.

    Can you provide a specific reference to the NEC document which
    indicates that use of sector-0 is disallowed on the 765. Or failing
    that, a description of why this particular header value is "special"?
    Just curious... (inquiring minds want to know!)

    --
    Dunfield Development Systems http://www.dunfield.com
    Low cost software development tools for embedded systems
    Software/firmware development services Fax:613-256-5821


  20. Re: Kaypro Format

    On Fri, 13 Jan 2006 13:39:25 GMT,
    Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield)
    wrote:

    >I've seen you mention this before, however my "bible" used for
    >developing my code for the 765 is the datasheet from the 1982
    >NEC databook, and I cannot find any reference, specific or
    >otherwise to it not supporting sector #0.


    The source is the original jinglish manual I have. About .75" thick
    and far more comprehensive than data sheet.

    >As far as the hardware goes, the controller is already synced by
    >the time it scans for C, H and R ... This is just "data" to the bitstream,
    >and a 00 value should be read just as easily as a C=00 or H=00
    >value (or a whole sector filled with 00 for that matter). If there were
    >a function in the chip logic which rejected R=00 then I would expect
    >it to simply fail - not "be less reliable" which suggests a hardware
    >reason.


    Goes back to IBM design of the 8" SSSD 128 byte format and friends.
    They were alergic to too many ones or zeros in the header field.
    I suspect that with mid 1970s hardware that may hve had issues with
    peak shift.

    >The only sector-0 issue I know of with the 765 is that it "wraps" to
    >sector 1 if you use multi-sector operations spanning a track - but I
    >would guess that this is for compatibility with IBM formats, not for a
    >hardware reason.


    Hence my comment on "bullet proof programming". As vendor
    at the time (early 80s) it was easier to tell non-magnetics aware
    people never use sector "0" than explain that it wraps to 1 because
    the IBM format spec used to say start with 1.

    >If there were a true hardware reason to not allow 00 in the header,
    >then why not also avoid 00 in the C and H values - after all it would
    >be completely reasonable to call them cylinders 1-78 or heads 1
    >and 2. I strongly suspect that it was just an arbitrary decision by IBM
    >to numbers the 26 sectors on a track as 1...26.


    Its was IBM that was allergic to long strings of zeros. I suspect
    it was also their internal programming conventions at work.

    >Can you provide a specific reference to the NEC document which
    >indicates that use of sector-0 is disallowed on the 765. Or failing
    >that, a description of why this particular header value is "special"?
    >Just curious... (inquiring minds want to know!)


    It really starts with the fact that most digital engineers of the time
    doing floppy systems being far less knowledgeable of floppies in
    general and the background of why IBM specified things the way they
    did. Their belief (at that time) was magnetic media was error prone
    and efforts were required to insure minimal risk of errors where
    possible.

    Nothing publicly available other than the original IBM spec and the
    765 design being specific to that spec in behavour. What I did see
    (back then) is poorly designed data seperators would barf easily
    and loose lock and most of those designs failed due to poor settling
    time so during the ID fields the system (FDC and data sep) would
    be more error prone with long strings of 1s or 0s. The usual problem
    was damping was greater in one direction than another (most common
    with moto 4044 Phase detector designs). It's the irregular
    transistions in the gaps that unsettle the dataseps (PLL). Since
    only cylinder 0 is "0" and rare is there a sector FFh or track FFh
    there was implied mix or 0s and 1s if the sector is not 00h. Those
    cases we'd hear from the designer twice, first being intermittent
    sector zero not found errors and then 'it seems to wrap to sector 1 on
    multisector". Usually if we tols him/her to fix the PLL that solved
    one of the complaints. If we told him to assign first sector as 01h
    and fix the PLL that usually solved it, sometimes their pll would
    behave better with only the sector numbering change. Though that
    was really hiding a problem. With the availability of DPLL (digital
    synthetic PLL) such as 9216, 9229 and discrete designs the problem
    was far less an issue as their lock lime is very short and they have
    excellent transient reponse.

    If you write a routine that always sets sector then it's ok, if you
    count on rollowover you get burnt. That was the real spec issue.


    Allison




+ Reply to Thread
Page 1 of 2 1 2 LastLast