Kaypro Format - CP/M

This is a discussion on Kaypro Format - CP/M ; >Nothing publicly available other than the original IBM spec and the >765 design being specific to that spec in behavour. The 765 data sheet does ot say that it is specific to the IBM spec. It says it is compatible ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 27 of 27

Thread: Kaypro Format

  1. Re: Kaypro Format

    >Nothing publicly available other than the original IBM spec and the
    >765 design being specific to that spec in behavour.


    The 765 data sheet does ot say that it is specific to the IBM spec.
    It says it is compatible with IBM 3740 and System 34 formats (ie:
    it can do them). If there is nothing "publically available" which states
    that sector 0 is a no-no for the 765, than this function would not appear
    to be "out of spec." for this device.


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


    A bad PLL is a bad PLL - I'm not sure I would buy this argument for
    !sector-0 because of several reasons:

    1) The 3740 header is: FE c h r ss
    In worst case of C=0 H=0 R=1 and ss=128 this would
    be: FE 00 00 01 00 CRC
    or 24 zero bits (iirc bytes are big endian on the media)
    With R=0 we get: FE 00 00 00 00
    which is 33 zero bits - so S=01 gives a big improvement
    right! - but WAIT Why not make H=1 or 2 instead of insisting
    that S=1 then we get FE 00 01 00 00 crc
    which gives us 16 zero bits. Since H can only be 1 or
    2 (in this case), we get a maximum of 17 "worse case".
    Surely this would have made more sense if this were
    truly the reason.

    2) The whole point of encoding FM or MFM is to insure there
    are adaquate transitions - if a data separator is so bad that
    it can't track 24 consecutive 00's, then it's going to have a
    real problem with a 128 byte sector of 00s (let along a 1K
    sector) - In other words, if this were the reason, it would be
    a "wart" in a spec for the specific purpose of hiding only
    one aspect of a seriously flawed design that could not
    possibly work "normally" anyway.

    3) Notwithstanding the above - if it's a data separator issue.
    then it is not a problem with the 765 itself.

    So, it would appear to me that the 765 is fine with R=0, with the
    one caveat that you have to be careful of it's "doing the IBM
    compatible thing for you" (ie: wrapping to 1) - This has been
    my experience with it.

    Why IBM originally chose to number the sectors from 1 is
    probably just a matter of the personal taste of whoever speced
    the sector mapping (I know lots of computer people who still
    count from 1).


    Anyway - it's really a moot point. The IBM formats are long established
    and well entrenched - and I agree with your assertion that we would all
    be better off if the various vendors has just followed it. If I were developing
    the CUBIX file system now, with my current level of experience, I would
    have numbered the sectors from 1 without even thinking about it.

    Dave

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


  2. Re: Kaypro Format

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

    >>Nothing publicly available other than the original IBM spec and the
    >>765 design being specific to that spec in behavour.

    >
    >The 765 data sheet does ot say that it is specific to the IBM spec.
    >It says it is compatible with IBM 3740 and System 34 formats (ie:
    >it can do them). If there is nothing "publically available" which states
    >that sector 0 is a no-no for the 765, than this function would not appear
    >to be "out of spec." for this device.


    Other than the IBM spec which was very public. It's more a case of
    people designed and implemented some great products in software
    and likely just didn't know. Often not knowing is not bad either as
    good ideas outside the box result.

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

    >
    >A bad PLL is a bad PLL - I'm not sure I would buy this argument for
    >!sector-0 because of several reasons:
    >
    >1) The 3740 header is: FE c h r ss
    > In worst case of C=0 H=0 R=1 and ss=128 this would
    > be: FE 00 00 01 00 CRC
    > or 24 zero bits (iirc bytes are big endian on the media)
    > With R=0 we get: FE 00 00 00 00
    > which is 33 zero bits - so S=01 gives a big improvement
    > right! - but WAIT Why not make H=1 or 2 instead of insisting
    > that S=1 then we get FE 00 01 00 00 crc
    > which gives us 16 zero bits. Since H can only be 1 or
    > 2 (in this case), we get a maximum of 17 "worse case".
    > Surely this would have made more sense if this were
    > truly the reason.


    However the serializer inserts transistions and it's the long patterns
    that result especially for MFM. Though you did point out on of the
    known pathological cases. Consider this what is C0/H0/S0 most often
    used for. It turns out to be the least likely seen of all.

    >2) The whole point of encoding FM or MFM is to insure there
    > are adaquate transitions - if a data separator is so bad that
    > it can't track 24 consecutive 00's, then it's going to have a
    > real problem with a 128 byte sector of 00s (let along a 1K
    > sector) - In other words, if this were the reason, it would be
    > a "wart" in a spec for the specific purpose of hiding only
    > one aspect of a seriously flawed design that could not
    > possibly work "normally" anyway.


    True but, there is pattern senstivity even with transistion insertion.

    >3) Notwithstanding the above - if it's a data separator issue.
    > then it is not a problem with the 765 itself.


    You bet! though Precomp was also important.

    >So, it would appear to me that the 765 is fine with R=0, with the
    >one caveat that you have to be careful of it's "doing the IBM
    >compatible thing for you" (ie: wrapping to 1) - This has been
    >my experience with it.


    You understand and that's why you were able to make imagedisk work.

    >Why IBM originally chose to number the sectors from 1 is
    >probably just a matter of the personal taste of whoever speced
    >the sector mapping (I know lots of computer people who still
    >count from 1).


    The old is that 10 or 11?

    Agreed, rare are those that fully understand the nuances.

    The "one little item" was when speaking to me as NEC back then
    was the other caveat. "It does IBM spec, that isn't so, your results
    are not controlled or guarenteed.". The vendor spec thing.

    As to sector zero. Well If I had my way and didn't know the content
    of the IBM spec I'd have gone with zero myself. Two things added
    together to dissuade that. First being the nominal spec and the
    other being CP/M and the example bios had the logical sector as
    zero biased and used that as an index into the sector translate
    table (skew) that was one biased. When in Rome do the Roman thing.

    Crappy PLL is as you said broken. No excuses there but it's an analog
    thing and back then many didn't understand that (or bus ringing).

    765 programming.. Know it all too well. Guess what, from my
    perspective as a mostly hardware person, it's a pain to program
    with it's irregular length instructions. The other peice of it is
    the people that complained the loudest were implementing every
    instruction that chip could do and the 99% needed were Format,
    READ, WRITE, SEEK, REcalibrate, Sense interrupt, and Specify.
    Sure there are special apps like image disk that need READ
    DIAGNOSTIC and READ DELETED for some stuff.

    >Anyway - it's really a moot point. The IBM formats are long established
    >and well entrenched - and I agree with your assertion that we would all
    >be better off if the various vendors has just followed it. If I were developing
    >the CUBIX file system now, with my current level of experience, I would
    >have numbered the sectors from 1 without even thinking about it.
    >


    If you were doing it now you'd skip the floppy and use a CF card
    which is LBA zero biased. ;-)


    Allison


  3. Re: Kaypro Format

    >>The 765 data sheet does ot say that it is specific to the IBM spec.
    >>It says it is compatible with IBM 3740 and System 34 formats (ie:
    >>it can do them). If there is nothing "publically available" which states
    >>that sector 0 is a no-no for the 765, than this function would not appear
    >>to be "out of spec." for this device.


    >Other than the IBM spec which was very public.


    You missed my point - just because the 765 is "IBM compatible"
    doesn't mean it is limited or bound by the IBM spec (unless the
    manufacturer says it is which they didn't). My laptop has a sticker
    proudly proclaiming that it's "Windows compatible", however it is
    not limited to running winblows (thank god). NEC documents the
    sector number as a byte, and does not specify any restrictions
    on this value in any of the official specs. that I have seen.


    >However the serializer inserts transistions and it's the long patterns
    >that result especially for MFM. Though you did point out on of the
    >known pathological cases. Consider this what is C0/H0/S0 most often
    >used for. It turns out to be the least likely seen of all.


    (Except under Cubix where 0/0/0 is the root of the directory :-)

    Read my previous message - the point was that if you were making
    the spec to reduce the length of the zero-bit string in the header,
    there are obvious better things you could have done - this suggests
    that this was not the reason.



    >True but, there is pattern senstivity even with transistion insertion.


    But to suggest that the format was designed specifically to allow
    general purpose disk system that cannot support 25 zero bits (but
    can support 24 zero bits) in a row simply does not make sense.
    Such a disk system would be useless, as runs of zeros often occur
    in both data and program code.



    >The "one little item" was when speaking to me as NEC back then
    >was the other caveat. "It does IBM spec, that isn't so, your results
    >are not controlled or guarenteed.". The vendor spec thing.


    Not sure where this quite is from, but it's not in the databook or any
    other NEC published spec. that I have been able to locate.



    >As to sector zero. Well If I had my way and didn't know the content
    >of the IBM spec I'd have gone with zero myself.


    Which is what I did - I hadn't looked at the IBM spec, and just went
    with the 765 datasheet - zero makes more sense, as it works out
    in the modular arithmetic needed to calculate C/H/S better.


    >If you were doing it now you'd skip the floppy and use a CF card
    >which is LBA zero biased. ;-)


    :-)


    I don't see much more to be gained by continued tossing of this back
    and forth, so lets just agree to disagree - You assert that using sector
    number 0 is is "out of spec." for the NEC chip. I assert that I have yet
    to see any NEC documentation or specificaion which states this, nor
    have I found a 765 controller (or even a clone) which doesn't support
    this. Innuendo from third party references, sales droids and "support
    engineers" who may or may not have known the detailed specification
    for the device aside, point me at an offical NEC spec. which states
    that sector number 0 is not supported by the device, and I will be
    happy to change my assertion.


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


  4. Re: Kaypro Format

    On Sat, 14 Jan 2006 12:36:51 GMT,
    Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield)
    wrote:

    >>>The 765 data sheet does ot say that it is specific to the IBM spec.
    >>>It says it is compatible with IBM 3740 and System 34 formats (ie:
    >>>it can do them). If there is nothing "publically available" which states
    >>>that sector 0 is a no-no for the 765, than this function would not appear
    >>>to be "out of spec." for this device.

    >
    >>Other than the IBM spec which was very public.

    >
    >
    >You missed my point - just because the 765 is "IBM compatible"
    >doesn't mean it is limited or bound by the IBM spec (unless the
    >manufacturer says it is which they didn't). My laptop has a sticker
    >proudly proclaiming that it's "Windows compatible", however it is
    >not limited to running winblows (thank god). NEC documents the
    >sector number as a byte, and does not specify any restrictions
    >on this value in any of the official specs. that I have seen.


    Spec sheet marketing.

    The problem with spec sheets is that often they say what it is
    guarenteed to do and if it also does something else not specified
    no problem. Of course if they change the part problems may
    ensue if unspecified behavours are now illegal.

    Here is an example of something not on the 8085 datasheet regardless
    of vendor.

    Hex 8085 Meaning
    ---------------------
    08 SUB HL-BC
    10 Shift right HL
    18 Rotate right DE
    28 Add HL and Immidiate nnnn into DE
    38 Add SP and Immidiate nnnn into DE
    CB ReSTart on Overflow to 0040h
    D9 Load [DE] from HL
    DD Jump on 'Not X5'
    ED Load HL from [DE]
    FD Jump on 'X5'

    They are however found in every 8085!

    >>However the serializer inserts transistions and it's the long patterns
    >>that result especially for MFM. Though you did point out on of the
    >>known pathological cases. Consider this what is C0/H0/S0 most often
    >>used for. It turns out to be the least likely seen of all.

    >
    >(Except under Cubix where 0/0/0 is the root of the directory :-)


    And it works too. But that's not commonplace, usually the first
    tracks are for booting or other househeeping.

    >Read my previous message - the point was that if you were making
    >the spec to reduce the length of the zero-bit string in the header,
    >there are obvious better things you could have done - this suggests
    >that this was not the reason.
    >
    >
    >
    >>True but, there is pattern senstivity even with transistion insertion.

    >
    >But to suggest that the format was designed specifically to allow
    >general purpose disk system that cannot support 25 zero bits (but
    >can support 24 zero bits) in a row simply does not make sense.
    >Such a disk system would be useless, as runs of zeros often occur
    >in both data and program code.


    It wasnt designed for that. The IBM spec was bullet proof it's
    implmentation level where the problems creep in. It's a design
    Issues at the system level that most well designed PLLs needed between
    8-20 transistions to lock up. bad or noisy PLLs don't lock they sort
    of wander around the zero point in an under or more typically over
    damped way. Often that would also be pattern sensitive.

    >>The "one little item" was when speaking to me as NEC back then
    >>was the other caveat. "It does IBM spec, that isn't so, your results
    >>are not controlled or guarenteed.". The vendor spec thing.

    >
    >Not sure where this quite is from, but it's not in the databook or any
    >other NEC published spec. that I have been able to locate.


    True enough, I was there when the book was being written. I also
    have all the ap notes and did Apps engineer training. Like intel
    there was the book, the appnotes and the real story.

    >>As to sector zero. Well If I had my way and didn't know the content
    >>of the IBM spec I'd have gone with zero myself.

    >
    >Which is what I did - I hadn't looked at the IBM spec, and just went
    >with the 765 datasheet - zero makes more sense, as it works out
    >in the modular arithmetic needed to calculate C/H/S better.


    It does. However starting in the CP/M world thats the boot block
    or the first tracks of the OS to load.

    >I don't see much more to be gained by continued tossing of this back
    >and forth, so lets just agree to disagree - You assert that using sector
    >number 0 is is "out of spec." for the NEC chip. I assert that I have yet
    >to see any NEC documentation or specificaion which states this, nor
    >have I found a 765 controller (or even a clone) which doesn't support
    >this.


    We agree it does work. It however is not "in spec" only unspecified
    and happens to work.

    > Innuendo from third party references, sales droids and "support
    >engineers" who may or may not have known the detailed specification
    >for the device aside, point me at an offical NEC spec. which states
    >that sector number 0 is not supported by the device, and I will be
    >happy to change my assertion.


    Ah, but this is the rare case where inuendo refers to me personally
    as both Apps enginner and product engineering. Which is how I
    happen to have more docs available to me than most plus the
    inside line. Not being under time limited NDA anymore helps.
    However my files and docs were preserved and I still refer to them.

    The real case here is the product was designed in Japan and made
    avalable to the USA for sale. How it was documented was a side effect
    of the US side being a mere 80 people and the translated docs being
    horrid at best to read. Since the competition was WD1793 it was an
    issue that the two operate differently and things accepted as normal
    there were not done on 765. So there was a marketing effort to "not
    say you cant". The side effect was lots of hands on time with
    designers (bigger companies) early on and then lore set it on how it
    should be. Lacking docs that support otherwise is the problem.


    Allison







  5. Re: Kaypro Format

    >Here is an example of something not on the 8085 datasheet regardless
    >of vendor.
    > ... snipped ...
    >They are however found in every 8085!


    The difference (to this discussion) being of course that the Intel datasheets
    for the 8085 specifically list these as invalid opcodes - It dosn't matter what
    they do, use of them is officially "out of spec." for that device.

    What I have been trying to get across is that I have yet to see a NEC
    datasheet which states anything other than "R is a byte" (and last time
    I checked, a byte could be 00-FF).


    >>But to suggest that the format was designed specifically to allow
    >>general purpose disk system that cannot support 25 zero bits (but
    >>can support 24 zero bits) in a row simply does not make sense.
    >>Such a disk system would be useless, as runs of zeros often occur
    >>in both data and program code.


    >It wasnt designed for that. The IBM spec was bullet proof it's
    >implmentation level where the problems creep in.


    But your arguments to date have been "it can only be used within the
    bounds of the IBM spec" (a fact not found anywhere on the datasheet)
    because of these reasons ... This would seem to imply that the IBM
    spec was developed for the same reasons (which is what I disagree
    with).


    >True enough, I was there when the book was being written. I also
    >have all the ap notes and did Apps engineer training. Like intel
    >there was the book, the appnotes and the real story.


    Ok - I did not realize that you had worked for NEC ... so you obviously
    have access to inside information not published in the spec.


    >Ah, but this is the rare case where inuendo refers to me personally
    >as both Apps enginner and product engineering. Which is how I
    >happen to have more docs available to me than most plus the
    >inside line. Not being under time limited NDA anymore helps.
    >However my files and docs were preserved and I still refer to them.


    I guess the part I am having difficulty understanding is how exactly
    the "inside line" and material covered by NDA can be considered
    part of the specification for what is supposed to be an openly
    documented device. By definition, the spec is what you tell the
    world about how it works (and I agree completely that parts do not
    always work the way they are speced).

    To my way of thinking, a procedure using the cabibilities of the part
    as documented in the datasheet, and not violating any constraints
    outlined in the datasheet which does not work is not due to it being
    "out of spec" - it is due to a "broken design". In other words, the
    procedure is within spec. the part isn't. This remains true until such
    time as the vendor publishes a new specification which identifies
    constraints bounding the conditions causing the failure. As far as I
    am aware, this has not happened with the 765.


    So if I understand it correctly, NEC has internal documents and
    proprietary/undisclosed material which state that use of a sector
    number of 00 does not work on the 765 - yet this information does
    not appear in the published specifications or datasheets. To me
    this indicates either a broken design, or a broken spec.

    In this light,, I can not see how anyone from NEC can justifiably
    make statements like "I consider what kaypro did to be just bad".
    since apparently the true specifications for the part were never
    published.


    There are other aspects of the 765 which are obviously designed to
    make it easy to implement IBM formats, which also have software
    issues, and require workarounds if you are not using those formats
    - such as the fact that the recalibrate command fails if track-0 is not
    reported after 77 steps. Yet I don't see people jumping in and saying
    "thats out of spec" everytime someone mentions using an 80 track
    drive - I don't see how this really differs from the sector-0 issue. (From
    the datasheet it's easy to see that all you need to do is issue two
    recal commands and as the device is speced, it will work).

    I think we are just arguing semantics - as a NEC engineer, you view
    the "spec" as the internal documentation. As an "outside" engineer,
    I view the spec as what you publish. What you are saying is that the
    published information is lacking a crutial bit of information (ie: the
    spec is broken). Hopefully we can agree on that and then have
    nothing further to say on the subject, so I will bow out as this thread
    has already gone too long.

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


  6. Re: Kaypro Format

    On Sat, 14 Jan 2006 18:14:48 GMT,
    Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield)
    wrote:

    >>Here is an example of something not on the 8085 datasheet regardless
    >>of vendor.
    >> ... snipped ...
    >>They are however found in every 8085!

    >
    >The difference (to this discussion) being of course that the Intel datasheets
    >for the 8085 specifically list these as invalid opcodes - It dosn't matter what
    >they do, use of them is officially "out of spec." for that device.


    Save for intel was goiving out NDAs and wink/nod they'd be there.
    And the point is the sheet and reality often are not quite the whole
    story.

    >What I have been trying to get across is that I have yet to see a NEC
    >datasheet which states anything other than "R is a byte" (and last time
    >I checked, a byte could be 00-FF).


    Right, unless your were under NDA back then. You would have been told
    then what you already found out.


    >>>But to suggest that the format was designed specifically to allow
    >>>general purpose disk system that cannot support 25 zero bits (but
    >>>can support 24 zero bits) in a row simply does not make sense.
    >>>Such a disk system would be useless, as runs of zeros often occur
    >>>in both data and program code.

    >
    >>It wasnt designed for that. The IBM spec was bullet proof it's
    >>implmentation level where the problems creep in.

    >
    >But your arguments to date have been "it can only be used within the
    >bounds of the IBM spec" (a fact not found anywhere on the datasheet)
    >because of these reasons ... This would seem to imply that the IBM
    >spec was developed for the same reasons (which is what I disagree
    >with).


    Seems lost in layers of conversation but largely true.

    >>True enough, I was there when the book was being written. I also
    >>have all the ap notes and did Apps engineer training. Like intel
    >>there was the book, the appnotes and the real story.

    >
    >Ok - I did not realize that you had worked for NEC ... so you obviously
    >have access to inside information not published in the spec.


    We'd discussed this off line before. I figured there was a
    disconnect.

    >>Ah, but this is the rare case where inuendo refers to me personally
    >>as both Apps enginner and product engineering. Which is how I
    >>happen to have more docs available to me than most plus the
    >>inside line. Not being under time limited NDA anymore helps.
    >>However my files and docs were preserved and I still refer to them.

    >
    >I guess the part I am having difficulty understanding is how exactly
    >the "inside line" and material covered by NDA can be considered
    >part of the specification for what is supposed to be an openly
    >documented device. By definition, the spec is what you tell the
    >world about how it works (and I agree completely that parts do not
    >always work the way they are speced).


    I was trying to highlight wat was written and published was at best
    a bit thin on detail and those under NDA got to pick the brains and
    get answers from Japan.

    >To my way of thinking, a procedure using the cabibilities of the part
    >as documented in the datasheet, and not violating any constraints
    >outlined in the datasheet which does not work is not due to it being
    >"out of spec" - it is due to a "broken design". In other words, the
    >procedure is within spec. the part isn't. This remains true until such
    >time as the vendor publishes a new specification which identifies
    >constraints bounding the conditions causing the failure. As far as I
    >am aware, this has not happened with the 765.


    Hint, there was pandering to larger (really large) vendors, they only
    dealt with contracted specs not some loose datasheet. They expected
    and got the product engineers ear and even a visit from/to Japan if
    warrented.

    >So if I understand it correctly, NEC has internal documents and
    >proprietary/undisclosed material which state that use of a sector
    >number of 00 does not work on the 765 - yet this information does
    >not appear in the published specifications or datasheets. To me
    >this indicates either a broken design, or a broken spec.


    Broken spec. We know it works with a caveat your done it. You also
    found out what happens with multitrack read. that was incorrectly
    specified. If you were told that MT works as expected IF R=1
    rather than R=0 as starting sector the issue would be a bit moot.

    >In this light,, I can not see how anyone from NEC can justifiably
    >make statements like "I consider what kaypro did to be just bad".
    >since apparently the true specifications for the part were never
    >published.


    That was made in light of IBM Format spec knowledge where
    sector 00 was not used.

    >There are other aspects of the 765 which are obviously designed to
    >make it easy to implement IBM formats, which also have software
    >issues, and require workarounds if you are not using those formats
    >- such as the fact that the recalibrate command fails if track-0 is not
    >reported after 77 steps. Yet I don't see people jumping in and saying
    >"thats out of spec" everytime someone mentions using an 80 track
    >drive - I don't see how this really differs from the sector-0 issue. (From
    >the datasheet it's easy to see that all you need to do is issue two
    >recal commands and as the device is speced, it will work).


    That in my mind was broken but.. in 1980 the only drives with more
    than 40 tracks were 8" and that was 77 tracks. FYI: the upd7265
    that recal was changed to 256 max and IDAM was removed to
    accomodate SONY/ISO 3.5" drives. Try and find a 7265!

    >I think we are just arguing semantics - as a NEC engineer, you view
    >the "spec" as the internal documentation. As an "outside" engineer,
    >I view the spec as what you publish. What you are saying is that the
    >published information is lacking a crutial bit of information (ie: the
    >spec is broken). Hopefully we can agree on that and then have
    >nothing further to say on the subject, so I will bow out as this thread
    >has already gone too long.


    We can agree the spec is incomplete (broken).

    Also that starting with sector 0 while viable was not IBM complient
    and while accepted was a pseudostandard that caused problems
    long term. I say this from the point I was at where if it didn't
    fly on NS* hardsector it was useless to me or meant extreme
    contortions to get from one system to another. Then once I had
    softsector I had to do multiple drives and formats for the same
    reason. In my case to get (this late 1979!) to get from a 8" SSSD
    disk a LSI-11 (really!) was used to read and serially transfer the
    disks data sector by sector to a V1.4 Lifeboat on NS* system.

    Further the initial issue and complaint was the plethora of randomly
    concevied (TRS80 deleted data mark on SD disks is the poster child)
    formats was a hinderence to software developement. I'd go further
    and say where format was extremely platform specific (Apple, TRS80,
    Northstar) there were very good developments that were unique to that
    world as it wasn't easily portable. Again I'm applying a very CP/M
    centric view where within the common operating system one could still
    be orphaned from software exchange. I'll grant that once modem/BBSs
    and file transfer software became more available the issue softened
    some.

    If anything after the rant is over, I tend to agree with you
    completely.

    Allison



  7. Re: Kaypro Format

    Allison-nospam@nouce.bellatlantic.net wrote:
    > On Fri, 13 Jan 2006 13:39:25 GMT,
    > Dave.Dunfield@use.techsupport.link.on.my.website (Dave Dunfield)
    > wrote:


    I've enjoyed reading comments from both of you about floppy data stream
    decoding
    and designs of the early floppy disk era. It's an informative
    discussion. I have a few comments to add:

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


    I concurr that some early floppy disk controllers were not well
    designed. Anyone interested can look at schematics and design notes
    from any number of S-100 floppy disk controller cards. You might also
    look at early floppy drive schematics: some of them included data
    decoders/encoders.

    Regarding specifications for floppy formats, let's see what Shugart
    said in "SA800 Series Diskette Storage Drive - Double Density Design
    Guide - Application Note" #3900 10/77. It's very specific about bit
    fields, encoding and efficiency - the issues mentioned in this thread.
    It mentions the "ID field" as including an ID as a "four byte address
    containing cylinder number, head number, record number and record
    length". Cylinder and record refer to track and sector, respectively.
    There are tables for optimized record lengths versus number of records,
    from 1 to 32 records (for both single and double density).

    The term "record number" and "number of records" are both used in the
    document. There is no reference to values for the ID field for any of
    those four parameters.

    Let's see..Shugart's "SA800/801 Diskette Storage Drive - OEM manual"
    says the diskette "can be written interchangably between any SA800 and
    IBM 3741/42, 3747 and 3540". For recording format it says "...for a
    detailed discussion..the designer should read one of the following: IBM
    Compatibility Manual, Shugart Associates Double Density Design Guide,
    SA801/901 Track Formats". There is no discussion of format in this
    document.

    Shugart's "SA800/801 Diskette Storage Drive - Theory of Operations"
    does provide bit-level descriptions of format. Section "2.5 - Tracks"
    says "the tracks are numbered 0-76". Section 2.7 discusses track
    formats, and mentions the "ID field" as described earlier but not the
    values in that field. That lack may be deliberate, as for instance in
    desribing the CRC for each field (2.7.3) it mentions a "generator
    polynomial" but does not give the specific one.

    The Shugart SA800 Service Manual of 1981, interestingly enough, shows
    the ID field as "track number, zeros, sector, sector length" bytes.
    Also, the above Shugart docments discuss hard sector formats, and I
    note by its absence any "ID" field. The hard sector format is simply a
    gap, data, and a gap; one apparently counts sector holes from the index
    hole to obtain a record or sector position.

    I don't have the Shugart "track formats" document for SA800 drives.
    There is apparently a similar document for SA400 drives.

    I do have a CDC (Control Data) application note 75897469 Jan 1980,
    "5.25 inch FDD format considerations and controller compatibilities".
    It says "an industry standard for 5.25 double density has not been
    defined: however a de facto standard format has resulted from the LSI
    controllers being designed for 5.25..as well as full-sized [8-inch]
    data rates." Most of the issues in this document are about field gaps.
    It's an informative document as it surveys a number of floppy
    controller boards and FDC chips. The CDC document refers to a number of
    incompatibilities among various LSI controller chips. The reference
    page list several documents, including as follows:

    IBM Compatibility Reference Manual, Shugart, 39002 (likely a Shugart
    doc & number);
    IBM One-Sided Diskette OEM Information, IBM, GA21-9190-3;
    IBM Two-Sided Diskette OEM Information, IBM, GA21-9257-1;
    ANSI draft 5 5.25" MEdia Standard, ANSI, X3B8/78-150
    ECMA 130mm Media Standard, ECMA, TC19/78/17

    >From all this, I conclude that IBM set the format standards initially;

    later the standards were de facto set by the FDC chip manufacturers,
    not always consistently. That is consistent with comments in this
    discussion thread.

    In my opinion, the description of "track zero" may have been reinforced
    by the necessity of a signal line and a circuit called "track zero".
    Any floppy controller needs to know when the head has reached one end
    of its range: this end has to be called something, and "zero" is what
    it's been called. Meahwhile, the beginning of a track (or the detection
    of it) has been refered to as the "index hole", not by some numeric
    designation. So it could be the "zeroth" or the "first" sector, in
    principle.

    I may have more documents about this subject; anyone is welcome to
    check my on line inventory and ask for more information or to request
    my copy service for these documents. Allison and Dave are welcome to
    copies of the Shugart or CDC documents I described in detail, for the
    asking.

    Herb Johnson

    Herbert R. Johnson, voice 609-771-1503, New Jersey USA
    web site
    domain mirror
    ** hjohnson@njcc.com and njcc.com/~hjohnson are EXPIRED **
    my email address: hjohnson AAT retrotechnology DOTT com
    if no reply, wait & try: herbjohnson ATT comcast DOTT net
    "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    S-100 IMSAI Altair computers, docs, by "Dr. S-100"


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2