CP/M filesystem quesions - CP/M

This is a discussion on CP/M filesystem quesions - CP/M ; Group: comp.os.cpm Date: Tue, Oct 16, 2007, 10:06am (CDT+7) From: peter.dassow@NOSPAM.z80.eu (Peter*Dassow* script: > ... sector numbers per track are changing, … Not correct. For CP/M disks Commodore 64 used 17 sectors for all 35 tracks. The directory on track ...

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

Thread: CP/M filesystem quesions

  1. Re: CP/M filesystem quesions


    Group: comp.os.cpm Date: Tue, Oct 16, 2007, 10:06am (CDT+7) From:
    peter.dassow@NOSPAM.z80.eu (Peter*Dassow*

    script:

    > ... sector numbers per track are changing, …


    Not correct. For CP/M disks Commodore 64 used 17 sectors for all 35
    tracks. The directory on track 18 only contained one file entry: 'CPM'
    on track 1, which contains the boot files and CP/M directory.

    Since I/O had to be handled by 6510 and custom chips (VIC, etc), this
    must have been _one_ of the most custom XIOS ever made. ((-;

    salaam,
    dowcom

    To e-mail me, add the character zero to "dowcom". i.e.:
    dowcom(zero)(at)webtv(dot)net.

    --
    http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE

    MSWindows is television,… Linux is radar.


  2. Re: CP/M filesystem quesions

    bud schrieb:
    >
    > Group: comp.os.cpm Date: Tue, Oct 16, 2007, 10:06am (CDT+7) From:
    > peter.dassow@NOSPAM.z80.eu (Peter Dassow
    >
    > script:
    >
    >> ... sector numbers per track are changing, …

    >
    > Not correct. For CP/M disks Commodore 64 used 17 sectors for all 35
    > tracks. The directory on track 18 only contained one file entry: 'CPM'
    > on track 1, which contains the boot files and CP/M directory.
    >
    > Since I/O had to be handled by 6510 and custom chips (VIC, etc), this
    > must have been _one_ of the most custom XIOS ever made. ((-;
    >
    > salaam,
    > dowcom


    I am not sure if you already visited my documentation about the disk
    structure. The "logical" sector numbers per track do not change, but
    physically they do (inner tracks have a smaller number of sectors than
    outer tracks).
    I am sure I told you the truth, because I wrote a Windows program to
    interpret the disk structure (of an "physical" disk image) to read out
    each cp/m file - and this worked very well.


    It's true because the floppy drives have their own cpu boards (with the
    6510 you mentioned) that this floppy format looks very crude.
    But they made it because they wanted to get the most "space" from each
    single disk ... I am still unsure if this was really neccessary, think
    about other GCR (CPU coded not floppy disk controller coded) formats
    from Apple or even from early PC compatibles like the Victor.

    Regards
    Peter
    ---
    * Visit my new site about CP/M related computers at http://www.z80.eu

  3. Re: CP/M filesystem quesions


    Group: comp.os.cpm Date: Wed, Oct 17, 2007, 11:28pm (CDT+7) From:
    peter.dassow@NOSPAM.z80.eu
    (Peter*Dassow*(remove*the*NOSPAM.*for*direct*answe r))

    script:

    >I am not sure if you already visited my >documentation about the disk

    structure.
    > The "logical" sector numbers per track
    >do not change, but physically they do
    >(inner tracks have a smaller number of
    >sectors than outer tracks).


    That is true for the standard C=64 disk format, which is GCR encoded.
    For CP/M the boot files reprogram the drive to eliminate GCR and fix
    (only) 17 sectors per track. This according to the 'CP/M for the
    Commodore 64 User's Guide'.

    >I am sure I told you the truth, because
    >I wrote a Windows program to interpret
    >the disk structure (of an "physical" disk
    >image) to read out each cp/m file - and
    >this worked very well.


    Can't comment on the validity of your program.
    I must first go by the info provided by the people who designed, built
    and wrote the manual for the C/PM cart . Why would they bother to say
    they did something that they didn't? The change was necessary so the
    1541 could read third-party CP/M disks.

    >It's true because the floppy drives have
    >their own cpu boards (with the 6510


    [6502 on the drives. 6510 for the C=64. bud]

    >you mentioned) that this floppy format
    >looks very crude. But they made it
    >because they wanted to get the most
    >"space" from each single disk


    Irrelevant to C=64 CP/M. 136KB non-GCR on the CP/M diskette is the same
    amount of 'raw data' as 170KB GCR on a standard C=64 diskette. (8 bytes
    raw is converted to 10 bytes GCR.)

    >... I am still unsure if this was really
    >neccessary,


    Commodore may have thought it necessary for the PETs, which were in the
    era when FM was still prevalent. For compatibility C= kept it in later
    machines. (My opinion is that GCR [8:10] requires 'the format' to have
    reasonable space. 'The format' requires GCR to assure data integrity in
    'close quarters'. Catch 22.)

    >think about other GCR (CPU coded not
    >floppy disk controller coded) formats
    >from Apple or even from early PC
    >compatibles like the Victor.


    Still irrelevant to C=64 CP/M. Vis-a-vis Apple GCR, it is 3:4, so
    _slightly_ less 'efficient' than Commodore.

    salaam,
    dowcom

    To e-mail me, add the character zero to "dowcom". i.e.:
    dowcom(zero)(at)webtv(dot)net.

    --
    http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE

    MSWindows is television,… Linux is radar.


  4. Re: CP/M filesystem quesions

    bud wrote:
    >
    > Group: comp.os.cpm Date: Wed, Oct 17, 2007, 11:28pm (CDT+7) From:
    > peter.dassow@NOSPAM.z80.eu
    > (Peter Dassow (remove the NOSPAM. for direct answer))
    >
    > script:
    >
    >> I am not sure if you already visited my >documentation about the disk

    > structure.
    >> The "logical" sector numbers per track
    >> do not change, but physically they do
    >> (inner tracks have a smaller number of
    >> sectors than outer tracks).

    >
    > That is true for the standard C=64 disk format, which is GCR encoded.
    > For CP/M the boot files reprogram the drive to eliminate GCR and fix
    > (only) 17 sectors per track. This according to the 'CP/M for the
    > Commodore 64 User's Guide'.
    >
    >> I am sure I told you the truth, because
    >> I wrote a Windows program to interpret
    >> the disk structure (of an "physical" disk
    >> image) to read out each cp/m file - and
    >> this worked very well.

    >
    > Can't comment on the validity of your program.
    > I must first go by the info provided by the people who designed, built
    > and wrote the manual for the C/PM cart . Why would they bother to say
    > they did something that they didn't? The change was necessary so the
    > 1541 could read third-party CP/M disks.
    >
    >> It's true because the floppy drives have
    >> their own cpu boards (with the 6510

    >
    > [6502 on the drives. 6510 for the C=64. bud]
    >
    >> you mentioned) that this floppy format
    >> looks very crude. But they made it
    >> because they wanted to get the most
    >> "space" from each single disk

    >
    > Irrelevant to C=64 CP/M. 136KB non-GCR on the CP/M diskette is the same
    > amount of 'raw data' as 170KB GCR on a standard C=64 diskette. (8 bytes
    > raw is converted to 10 bytes GCR.)
    >



    I do not want to discuss this further, because I really analyzed the
    floppy disk image files manually.
    It's true that the CP/M disks have 136KB capacity and the non-CP/M disks
    have more capacity.
    I do not know why you aren't able to see that there is a difference
    between a logical view and a physical view at a floppy disk image.
    They (Commodore) used only 17 sectors for each track, but the outer
    tracks have still more than 17 sectors, even if you are only able to use
    17 sectors with the C64 CP/M BIOS. It's a question of what the CP/M bios
    is able to do and what is physically used.
    Believe me, Commodore does not invent a new floppy format just for CP/M,
    they only simplified the format by using a fixed sector number.

    Regards
    Peter

  5. Re: CP/M filesystem quesions

    Peter Dassow (remove the NOSPAM. for direct answer) wrote:
    > bud wrote:
    >> Group: comp.os.cpm Date: Wed, Oct 17, 2007, 11:28pm (CDT+7) From:
    >> peter.dassow@NOSPAM.z80.eu
    >> (Peter Dassow (remove the NOSPAM. for direct answer))
    >> script:
    >>
    >>> I am not sure if you already visited my >documentation about the disk

    >> structure.
    >>> The "logical" sector numbers per track do not change, but physically
    >>> they do (inner tracks have a smaller number of sectors than outer
    >>> tracks).

    >>
    >> That is true for the standard C=64 disk format, which is GCR encoded.
    >> For CP/M the boot files reprogram the drive to eliminate GCR and fix
    >> (only) 17 sectors per track. This according to the 'CP/M for the
    >> Commodore 64 User's Guide'.
    >>
    >>> I am sure I told you the truth, because I wrote a Windows program to
    >>> interpret the disk structure (of an "physical" disk image) to read
    >>> out each cp/m file - and this worked very well.

    >>
    >> Can't comment on the validity of your program.
    >> I must first go by the info provided by the people who designed, built
    >> and wrote the manual for the C/PM cart . Why would they bother to say
    >> they did something that they didn't? The change was necessary so the
    >> 1541 could read third-party CP/M disks.
    >>
    >>> It's true because the floppy drives have their own cpu boards (with
    >>> the 6510

    >>
    >> [6502 on the drives. 6510 for the C=64. bud]
    >>
    >>> you mentioned) that this floppy format looks very crude. But they
    >>> made it because they wanted to get the most "space" from each single
    >>> disk

    >>
    >> Irrelevant to C=64 CP/M. 136KB non-GCR on the CP/M diskette is the same
    >> amount of 'raw data' as 170KB GCR on a standard C=64 diskette. (8 bytes
    >> raw is converted to 10 bytes GCR.)
    >>

    >
    >
    > I do not want to discuss this further, because I really analyzed the
    > floppy disk image files manually.
    > It's true that the CP/M disks have 136KB capacity and the non-CP/M disks
    > have more capacity.
    > I do not know why you aren't able to see that there is a difference
    > between a logical view and a physical view at a floppy disk image.
    > They (Commodore) used only 17 sectors for each track, but the outer
    > tracks have still more than 17 sectors, even if you are only able to use
    > 17 sectors with the C64 CP/M BIOS. It's a question of what the CP/M bios
    > is able to do and what is physically used.
    > Believe me, Commodore does not invent a new floppy format just for CP/M,
    > they only simplified the format by using a fixed sector number.
    >
    > Regards
    > Peter


    Well, just one last shot to your head... for the c128 version, they
    reused all the sectors almost... instead of fixating the sector count, a
    BIOS translation was done instead, giving you more space... IMHO that's
    how they should have done it on the 64 cart... but then, I'm biased, and
    believe the 128 was what the 64 should have been, and never bought a
    64... I went from the vic direct to c128, cuz to me, the 64 seemed like
    a pointless 40 column vic... note at the time the 64 came out, I had 2MB
    ot static RAM on the vic that was windowed in 8k at a time... it wasn't
    pretty, and was very expensive for me to do that... another reason why I
    bypassed the crusty 64 I guess...

  6. Re: CP/M filesystem quesions


    Group: comp.os.cpm Date: Thu, Oct 18, 2007, 7:25pm (CDT+7) From:
    peter.dassow@NOSPAM.z80.eu
    (Peter*Dassow*(remove*the*NOSPAM.*for*direct*answe r))

    script:

    >…Commodore does not invent a new
    >floppy format just for CP/M, they only
    >simplified the format by using a fixed
    >sector number.


    OK, now I understand. Same format, only sectors 0-16 used. Saved code
    for reprogramming. Good to know. Thanks for the info.

    salaam,
    dowcom

    To e-mail me, add the character zero to "dowcom". i.e.:
    dowcom(zero)(at)webtv(dot)net.

    --
    http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE

    MSWindows is television,… Linux is radar.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2