CP/M 1.4? - CP/M

This is a discussion on CP/M 1.4? - CP/M ; I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at Gaby's archive web site is missing the following files: submit.com load.com dump.com Do we have a complete 1.4 binary disk anywhere, so that I can build ...

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

Thread: CP/M 1.4?

  1. CP/M 1.4?

    I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at
    Gaby's archive web site is missing the following files:

    submit.com
    load.com
    dump.com

    Do we have a complete 1.4 binary disk anywhere, so that I can build a
    complete one for that release?

    Thanks,
    Udo Munk
    --
    The real fun is building it and then using it...


  2. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 05:07:29 +0200, Udo Munk
    wrote:

    >I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at
    >Gaby's archive web site is missing the following files:
    >
    >submit.com
    >load.com
    >dump.com
    >
    >Do we have a complete 1.4 binary disk anywhere, so that I can build a
    >complete one for that release?


    I do it will be a while before I can set that system up. Space
    and time is the issue.

    What's missing is PIP, STAT, ASM, ED, DDT and DUMP.asm

    I'd expect there is another disk on line elsewhere that has those
    missing parts. DUMP.asm is in the manuals and they are online.

    The NS* V1.4 Lifeboat edition had:
    ASM
    DDT
    DUMP.COM
    DUMP.ASM
    ED
    SYSGEN (NS* NS specific NSYSGEN)
    NRELOC (NS* specific relocator)
    STAT
    PIP
    SUBMIT
    USER.ASM
    (user IO, PRN, PUN, RDR, CONOUT, CONIN, CONSTAT)

    And maybe HORUSER.ASM (NS* specific serial parallel IO)

    Allison

    >Thanks,
    >Udo Munk



  3. Re: CP/M 1.4?

    I think that load, dump and submit were the same across versions 1.3 to
    2.2. But I'm pretty sure that I have version 1.4 here, although I'll
    have to look for it. (Have it as in I bought it back in the 1970's, not
    as in I have an archive copy from some library). In fact, I have 1.33
    from an Imsai system.


    Udo Munk wrote:
    > I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at
    > Gaby's archive web site is missing the following files:
    >
    > submit.com
    > load.com
    > dump.com
    >
    > Do we have a complete 1.4 binary disk anywhere, so that I can build a
    > complete one for that release?
    >
    > Thanks,
    > Udo Munk


  4. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 11:06:20 -0400, Barry Watzman
    wrote:

    >I think that load, dump and submit were the same across versions 1.3 to
    >2.2. But I'm pretty sure that I have version 1.4 here, although I'll
    >have to look for it. (Have it as in I bought it back in the 1970's, not
    >as in I have an archive copy from some library). In fact, I have 1.33
    >from an Imsai system.


    Good point. I know LOAD and DUMP are identical from 1.4 to 2.2.
    I suspect DDT and ASM are as well also ED.

    PIP and STAT if memory is right are foward portable (1.4 works on 2.2)
    but not fully safe for reverse.

    Allison

    >
    >
    >Udo Munk wrote:
    >> I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at
    >> Gaby's archive web site is missing the following files:
    >>
    >> submit.com
    >> load.com
    >> dump.com
    >>
    >> Do we have a complete 1.4 binary disk anywhere, so that I can build a
    >> complete one for that release?
    >>
    >> Thanks,
    >> Udo Munk



  5. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 11:06:20 -0400, Barry Watzman wrote:

    > I think that load, dump and submit were the same across versions 1.3 to
    > 2.2. But I'm pretty sure that I have version 1.4 here, although I'll
    > have to look for it. (Have it as in I bought it back in the 1970's, not
    > as in I have an archive copy from some library). In fact, I have 1.33
    > from an Imsai system.


    I got the bits from the IMSAI disk at the DRI archive site, those do work
    OK on 1.4. The program submit.com was modified, it has an IMSAI copyright
    additional to the DRI copyright. Also load.com doesn't look like the
    original DRI version, it starts with 3 NOP's. So I sure would appreciate
    to get the original 1.4 DRI binaries, thanks.

    Udo Munk
    --
    The real fun is building it and then using it...


  6. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 16:24:56 +0000, no.spam wrote:

    ...
    > PIP and STAT if memory is right are foward portable (1.4 works on 2.2)
    > but not fully safe for reverse.
    >
    > Allison


    The 1.4 stat doesn't work correct on 2.2:

    C>stat *.*

    RECS BYTS EX D:FILENAME.TYP
    64 240K 1 C:ASM.COM
    50 242K 1 C:BIOS.ASM
    8 254K 1 C:BIOS.HEX
    81 234K 1 C:BIOS.PRN
    15 252K 1 C:BOOT.ASM
    3 254K 1 C:BOOT.HEX
    26 248K 1 C:BOOT.PRN
    2 254K 1 C:BYE.COM
    1 254K 1 C:CLS.COM
    64 240K 1 C:CPM63.COM
    38 246K 1 CDT.COM
    2 254K 1 CUMP.COM
    48 244K 1 C:ED.COM
    18 250K 1 C:LOAD.COM
    70 238K 1 C:MOVCPM.COM
    66 238K 1 C:PIP.COM
    24 250K 1 C:STAT.COM
    7 254K 1 C:SUBMIT.COM
    8 254K 1 C:SYSGEN.COM
    2 254K 1 C:SYSGEN.SUB
    BYTES REMAINING ON C: 0K

    C>

    Udo Munk
    --
    The real fun is building it and then using it...


  7. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 13:56:08 +0000, no.spam wrote:

    > On Sat, 27 Oct 2007 05:07:29 +0200, Udo Munk
    > wrote:
    >
    >>I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at
    >>Gaby's archive web site is missing the following files:
    >>
    >>submit.com
    >>load.com
    >>dump.com
    >>
    >>Do we have a complete 1.4 binary disk anywhere, so that I can build a
    >>complete one for that release?

    >
    > I do it will be a while before I can set that system up. Space
    > and time is the issue.


    No need to hurry, this is not important stuff, but I sure would like to
    have a correct 1.4 disk. Many thanks in advance.

    > What's missing is PIP, STAT, ASM, ED, DDT and DUMP.asm
    >
    > I'd expect there is another disk on line elsewhere that has those
    > missing parts. DUMP.asm is in the manuals and they are online.


    I had googled for other 1.4 disk, but I couldn't find any :-(
    Yep, load.plm and dump.asm are in the 1.4 manual, so I could type those in
    to have the correct versions. Interestingly there is a long paragraph
    where Kildall explains the 0FAH origin for the load program. Also the
    missing lib parts of the 1975 loader are listed there.
    I never read the 1.4 manuals before, but once again I saw: reading the
    manuals will help.
    ....
    > Allison


    Udo Munk
    --
    The real fun is building it and then using it...


  8. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 21:40:25 +0200, Udo Munk
    wrote:

    >On Sat, 27 Oct 2007 16:24:56 +0000, no.spam wrote:
    >
    >..
    >> PIP and STAT if memory is right are foward portable (1.4 works on 2.2)
    >> but not fully safe for reverse.
    >>
    >> Allison

    >
    >The 1.4 stat doesn't work correct on 2.2:


    I did allow for the possibility that my wetware had dropped a few
    bits. At some point I have to check and see if STAT V2.2 works
    on 1.4.. I think not as well. It's the disk size/geometry thing and
    which accounts for the biggest differnce between 1.x and 2.x.

    Allison
    >C>stat *.*
    >
    >RECS BYTS EX D:FILENAME.TYP
    > 64 240K 1 C:ASM.COM
    > 50 242K 1 C:BIOS.ASM
    > 8 254K 1 C:BIOS.HEX
    > 81 234K 1 C:BIOS.PRN
    > 15 252K 1 C:BOOT.ASM
    > 3 254K 1 C:BOOT.HEX
    > 26 248K 1 C:BOOT.PRN
    > 2 254K 1 C:BYE.COM
    > 1 254K 1 C:CLS.COM
    > 64 240K 1 C:CPM63.COM
    > 38 246K 1 CDT.COM
    > 2 254K 1 CUMP.COM
    > 48 244K 1 C:ED.COM
    > 18 250K 1 C:LOAD.COM
    > 70 238K 1 C:MOVCPM.COM
    > 66 238K 1 C:PIP.COM
    > 24 250K 1 C:STAT.COM
    > 7 254K 1 C:SUBMIT.COM
    > 8 254K 1 C:SYSGEN.COM
    > 2 254K 1 C:SYSGEN.SUB
    >BYTES REMAINING ON C: 0K
    >
    >C>
    >
    >Udo Munk



  9. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 22:22:02 +0000, no.spam wrote:

    > On Sat, 27 Oct 2007 21:40:25 +0200, Udo Munk
    > wrote:


    >>The 1.4 stat doesn't work correct on 2.2:

    >
    > I did allow for the possibility that my wetware had dropped a few
    > bits. At some point I have to check and see if STAT V2.2 works
    > on 1.4.. I think not as well. It's the disk size/geometry thing and
    > which accounts for the biggest differnce between 1.x and 2.x.
    >
    > Allison


    Won't work either:
    A>d:stat

    Wrong CP/M Version (Requires 2.0)
    A>

    Can't be a disk geometry/size problem, I'm using IBM compatible 8" SD
    disks only. Right now it's not clear to me why I won't work, but the
    reason probably can be found in the 1.4 BDOS source.

    Udo Munk
    --
    The real fun is building it and then using it...


  10. Re: CP/M 1.4?



    Udo Munk wrote:
    > On Sat, 27 Oct 2007 13:56:08 +0000, no.spam wrote:
    >
    >

    <<< snipped >>>
    >
    >
    > No need to hurry, this is not important stuff, but I sure would like to
    > have a correct 1.4 disk. Many thanks in advance.
    >
    >
    >>What's missing is PIP, STAT, ASM, ED, DDT and DUMP.asm
    >>
    >>I'd expect there is another disk on line elsewhere that has those
    >>missing parts. DUMP.asm is in the manuals and they are online.


    What about http://www.cpm.z80.de/download/cpm14-b.zip? It has everything
    except DUMP and SUBMIT.

    Jeffrey W. Shook

    >
    >
    > I had googled for other 1.4 disk, but I couldn't find any :-(
    > Yep, load.plm and dump.asm are in the 1.4 manual, so I could type those in
    > to have the correct versions. Interestingly there is a long paragraph
    > where Kildall explains the 0FAH origin for the load program. Also the
    > missing lib parts of the 1975 loader are listed there.
    > I never read the 1.4 manuals before, but once again I saw: reading the
    > manuals will help.
    > ...
    >
    >>Allison

    >
    >
    > Udo Munk


  11. Re: CP/M 1.4?

    Barry Watzman wrote:

    > I think that load, dump and submit were the same across versions 1.3 to
    > 2.2. But I'm pretty sure that I have version 1.4 here, although I'll
    > have to look for it. (Have it as in I bought it back in the 1970's, not
    > as in I have an archive copy from some library). In fact, I have 1.33
    > from an Imsai system.
    >
    >
    > Udo Munk wrote:
    >
    >> I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at
    >> Gaby's archive web site is missing the following files:
    >>
    >> submit.com
    >> load.com
    >> dump.com
    >>
    >> Do we have a complete 1.4 binary disk anywhere, so that I can build a
    >> complete one for that release?
    >>
    >> Thanks,
    >> Udo Munk


    The CP/M 1.3 versions of load, dump and submit from DSI seem to be
    different from the the later ones. I wrote a little AWK script to
    check the CRC of the files on some system disks I found images for
    and here is the result. The utilities written in PL/M seem to have
    been compiled with a different compiler after CP/M 1.3.


    # Comparison of files in some CP/M distribution disks.
    #
    # ----------------- CRCs ---------------------
    # ver-mfg asm ddt dump ed load pip stat subm xsub
    # -------------------------------------------------------
    # 1.3-DSI__a adb2 93ec 707f 2cff 0283 284b af10 97d6 ----
    # 1.3-DSI__b adb2 93ec 707f 2cff 0283 284b af10 97d6 ----
    # 1.4-DRI 6908 de09 524d cf67 b286 d1c1 e518 d0d7 ----
    # 1.4-Tarbel 6908 de09 ---- cf67 b286 d1c1 e518 ---- ----
    # 2.0-DOSC 9f8c 0b99 524d f060 b286 e5ba 6331 4f87 240a
    # 2.0-LeCroy 9f8c 0b99 524d f060 b286 c8b7 6331 4f87 240a
    # 2.2-CCS__a 9f8c 9d65 524d f060 b286 1cff 6331 4f87 9068
    # 2.2-CCS__b 9f8c 9d65 524d f060 b286 1cff 6331 4f87 9068
    # 2.2-Jade_a 9f8c 9d65 524d f060 b286 1cff 6331 4f87 9068
    # 2.2-Jade_b 9f8c 9d65 524d f060 b286 1cff 6331 4f87 9068
    # 2.2-Tarbel 9f8c 9d65 524d f060 b286 1cff 6331 4f87 9068
    # 3.0-DRI-1 ---- ---- 9d3a 875a ---- d634 ---- ---- ----
    # 3.0-DRI-2 ---- ---- ---- ---- ---- ---- ---- 8562 ----

    Jeffrey W. Shook

  12. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 19:28:45 -0400, Jeffrey W. Shook wrote:

    ....
    > What about http://www.cpm.z80.de/download/cpm14-b.zip? It has everything
    > except DUMP and SUBMIT.
    >
    > Jeffrey W. Shook


    This is the one I used, LOAD also is missing.

    Udo Munk
    --
    The real fun is building it and then using it...


  13. Re: CP/M 1.4?

    On Sat, 27 Oct 2007 05:07:29 +0200, Udo Munk wrote:

    > I just build a bootable CP/M 1.4 disk for z80pack. The binary disk at
    > Gaby's archive web site is missing the following files:
    >
    > submit.com
    > load.com
    > dump.com
    >
    > Do we have a complete 1.4 binary disk anywhere, so that I can build a
    > complete one for that release?


    I got the missing bits, thanks Jeff!

    A complete and bootable CP/M 1.4 is available:
    ftp://ftp.unix4fun.org/z80pack/cpm14.tgz

    Enjoy,
    Udo Munk
    --
    The real fun is building it and then using it...


  14. Re: CP/M 1.4?

    On Sun, 28 Oct 2007 00:52:18 +0200, Udo Munk
    wrote:

    >On Sat, 27 Oct 2007 22:22:02 +0000, no.spam wrote:
    >
    >> On Sat, 27 Oct 2007 21:40:25 +0200, Udo Munk
    >> wrote:

    >
    >>>The 1.4 stat doesn't work correct on 2.2:

    >>
    >> I did allow for the possibility that my wetware had dropped a few
    >> bits. At some point I have to check and see if STAT V2.2 works
    >> on 1.4.. I think not as well. It's the disk size/geometry thing and
    >> which accounts for the biggest differnce between 1.x and 2.x.
    >>
    >> Allison

    >
    >Won't work either:
    >A>d:stat
    >
    >Wrong CP/M Version (Requires 2.0)
    >A>
    >
    >Can't be a disk geometry/size problem, I'm using IBM compatible 8" SD
    >disks only. Right now it's not clear to me why I won't work, but the
    >reason probably can be found in the 1.4 BDOS source.


    It is, V2.0 and later have variable allocation and map sizing. It was
    the big change to the BDOS and BIOS. So programs under V2.X can
    actually determine allocation size and number of allocation blocks per
    disk. Under 1.4 this was a fixed value and burried in the BDOS.

    If you happen to be running SSSD disk then the tables in V2 match
    1.4 but the data needed by stat in 2.X will not exist and stat V1.4
    assumes standard 1.4 disk (1950 allocation blocks). THe problem is
    STAT V2 looks for the data and if it's there it would fail so it does
    a call to report version BDOS function 12.

    I might add I've found STAT off my Horizon CP/M 1.4 disks does not
    work right with 8" SSSD. May be that Horizon SSSD is only 86K or
    so per disk. I foudn that out a logn time ago when rebuilding a
    system for 1.4.

    Allison

    >
    >Udo Munk



  15. Re: CP/M 1.4?

    I do have both CP/M version 1.33 (Imsai) and 1.4 (Generic DR), as well
    as 2.0, 2.1 and 2.2. I can send you the files you want, but I probably
    can't get to it for a week or so, this week is bad for me. Drop me an
    E-Mail privately. Be sure to tell me what you need in the E-Mail.


    Udo Munk wrote:
    > On Sat, 27 Oct 2007 11:06:20 -0400, Barry Watzman wrote:
    >
    >> I think that load, dump and submit were the same across versions 1.3 to
    >> 2.2. But I'm pretty sure that I have version 1.4 here, although I'll
    >> have to look for it. (Have it as in I bought it back in the 1970's, not
    >> as in I have an archive copy from some library). In fact, I have 1.33
    >> from an Imsai system.

    >
    > I got the bits from the IMSAI disk at the DRI archive site, those do work
    > OK on 1.4. The program submit.com was modified, it has an IMSAI copyright
    > additional to the DRI copyright. Also load.com doesn't look like the
    > original DRI version, it starts with 3 NOP's. So I sure would appreciate
    > to get the original 1.4 DRI binaries, thanks.
    >
    > Udo Munk


  16. Re: CP/M 1.4?

    There were major differences between version 1.4, which had all of the
    disk parameters hard coded, and version 2.x, which used the DPH and DBP
    tables. Stat is probably not truly compatible between version 1.x and
    2.x, in either direction, although for a standard 8" SSSD disk, it's
    possible that they would APPEAR to work.


    no.spam@no.uce.bellatlantic.net wrote:
    > On Sat, 27 Oct 2007 21:40:25 +0200, Udo Munk
    > wrote:
    >
    >> On Sat, 27 Oct 2007 16:24:56 +0000, no.spam wrote:
    >>
    >> ..
    >>> PIP and STAT if memory is right are foward portable (1.4 works on 2.2)
    >>> but not fully safe for reverse.
    >>>
    >>> Allison

    >> The 1.4 stat doesn't work correct on 2.2:

    >
    > I did allow for the possibility that my wetware had dropped a few
    > bits. At some point I have to check and see if STAT V2.2 works
    > on 1.4.. I think not as well. It's the disk size/geometry thing and
    > which accounts for the biggest differnce between 1.x and 2.x.
    >
    > Allison
    >> C>stat *.*
    >>
    >> RECS BYTS EX D:FILENAME.TYP
    >> 64 240K 1 C:ASM.COM
    >> 50 242K 1 C:BIOS.ASM
    >> 8 254K 1 C:BIOS.HEX
    >> 81 234K 1 C:BIOS.PRN
    >> 15 252K 1 C:BOOT.ASM
    >> 3 254K 1 C:BOOT.HEX
    >> 26 248K 1 C:BOOT.PRN
    >> 2 254K 1 C:BYE.COM
    >> 1 254K 1 C:CLS.COM
    >> 64 240K 1 C:CPM63.COM
    >> 38 246K 1 CDT.COM
    >> 2 254K 1 CUMP.COM
    >> 48 244K 1 C:ED.COM
    >> 18 250K 1 C:LOAD.COM
    >> 70 238K 1 C:MOVCPM.COM
    >> 66 238K 1 C:PIP.COM
    >> 24 250K 1 C:STAT.COM
    >> 7 254K 1 C:SUBMIT.COM
    >> 8 254K 1 C:SYSGEN.COM
    >> 2 254K 1 C:SYSGEN.SUB
    >> BYTES REMAINING ON C: 0K
    >>
    >> C>
    >>
    >> Udo Munk

    >


  17. Re: CP/M 1.4?

    Barry Watzman wrote:
    > There were major differences between version 1.4, which had all of the
    > disk parameters hard coded, and version 2.x, which used the DPH and
    > DBP tables. Stat is probably not truly compatible between version 1.x
    > and 2.x, in either direction, although for a standard 8" SSSD disk,
    > it's possible that they would APPEAR to work.
    > snip

    I have a bunch of CP/M 1.4 Floppies from my Old DATA BANC System. Not
    sure they are readable but I could fire up my Compu-Pro 8/16 and see if
    they can be read. Seems to me there is a 4 Sector SKEW on them.
    Might have some of the stuff you guys are looking for
    TIA
    Bob in Wisconsin

  18. Re: CP/M 1.4?

    On Sun, 28 Oct 2007 06:40:48 -0500, "Robert J. Stevens"
    wrote:

    >Barry Watzman wrote:
    >> There were major differences between version 1.4, which had all of the
    >> disk parameters hard coded, and version 2.x, which used the DPH and
    >> DBP tables. Stat is probably not truly compatible between version 1.x
    >> and 2.x, in either direction, although for a standard 8" SSSD disk,
    >> it's possible that they would APPEAR to work.
    >> snip

    >I have a bunch of CP/M 1.4 Floppies from my Old DATA BANC System. Not
    >sure they are readable but I could fire up my Compu-Pro 8/16 and see if
    >they can be read. Seems to me there is a 4 Sector SKEW on them.
    >Might have some of the stuff you guys are looking for
    >TIA
    >Bob in Wisconsin


    Standard CP/M 8"sssd V1.4 distribustion has a 6 sector skew. If it
    is on another media then all bets are off. For example the NS*
    Lifeboat V1.4 has deblocking as NS* controller is 256bytes/sector
    and skewing has to be applied differently.

    Allison


  19. Re: CP/M 1.4?

    On Sun, 28 Oct 2007 03:04:11 +0000, no.spam wrote:

    > On Sun, 28 Oct 2007 00:52:18 +0200, Udo Munk
    > wrote:

    ....
    >>Can't be a disk geometry/size problem, I'm using IBM compatible 8" SD
    >>disks only. Right now it's not clear to me why I won't work, but the
    >>reason probably can be found in the 1.4 BDOS source.

    >
    > It is, V2.0 and later have variable allocation and map sizing. It was
    > the big change to the BDOS and BIOS. So programs under V2.X can
    > actually determine allocation size and number of allocation blocks per
    > disk. Under 1.4 this was a fixed value and burried in the BDOS.


    Yes, I know this from writing the BIOS's for the various versions and from
    modifying the 1975 BIOS/BDOS.

    > If you happen to be running SSSD disk then the tables in V2 match 1.4
    > but the data needed by stat in 2.X will not exist and stat V1.4 assumes
    > standard 1.4 disk (1950 allocation blocks). THe problem is STAT V2
    > looks for the data and if it's there it would fail so it does a call to
    > report version BDOS function 12.


    Hm, 8" SD standard disks have 1944 blocks, wondering why you say 1950?

    Seem that 1.x stat looks directly into BDOS tables because 1.x doesn't
    have BDOS function 31 to return the address of the disk tables. If this
    stat and the BDOS don't match, it shows some garbage.
    ....
    > Allison
    >>Udo Munk


    I did a little experiment to see if the 1.4 stat would work with the 1975
    versions, but guess what, displays garbage too, this bits are not matching.

    For running 1.x programs on the 1975 system I modified the boot loader
    to leave a JMP to the BDOS entry at address 5. The 1975 system doesn't
    initialize anything in page zero, has not been invented yet. With this one
    can run some of the 1.x programs like stat on the 1975 version. Don't try
    ddt tho, it destroyes the boot loader in page zero.

    The 1975 bits at the web server are updated, if anyone wants to play with
    this.

    Udo Munk
    --
    The real fun is building it and then using it...


  20. Re: CP/M 1.4?

    On Sun, 28 Oct 2007 17:13:12 +0100, Udo Munk
    wrote:

    >On Sun, 28 Oct 2007 03:04:11 +0000, no.spam wrote:
    >
    >> On Sun, 28 Oct 2007 00:52:18 +0200, Udo Munk
    >> wrote:

    >...
    >>>Can't be a disk geometry/size problem, I'm using IBM compatible 8" SD
    >>>disks only. Right now it's not clear to me why I won't work, but the
    >>>reason probably can be found in the 1.4 BDOS source.

    >>
    >> It is, V2.0 and later have variable allocation and map sizing. It was
    >> the big change to the BDOS and BIOS. So programs under V2.X can
    >> actually determine allocation size and number of allocation blocks per
    >> disk. Under 1.4 this was a fixed value and burried in the BDOS.

    >
    >Yes, I know this from writing the BIOS's for the various versions and from
    >modifying the 1975 BIOS/BDOS.
    >
    >> If you happen to be running SSSD disk then the tables in V2 match 1.4
    >> but the data needed by stat in 2.X will not exist and stat V1.4 assumes
    >> standard 1.4 disk (1950 allocation blocks). THe problem is STAT V2
    >> looks for the data and if it's there it would fail so it does a call to
    >> report version BDOS function 12.

    >
    >Hm, 8" SD standard disks have 1944 blocks, wondering why you say 1950?


    77 tracks 26 sector per track.
    Raw space is 77*26=2002 sectors available.

    Of those 2 tracks are reserved for system.
    That leaves 75*26 sectors equaling 1950 sectors available.

    However CP/M 8"SSSD uses 1k allocation spaces so there are only
    243 allocation blocks (1944 used allocation blocks) because the
    remaining .75 of an allocation (6 sectors) are unused. Of those 243
    2 are reserved for directory leaving 241 allocation (241K) blocks
    for actual file space.

    >Seem that 1.x stat looks directly into BDOS tables because 1.x doesn't
    >have BDOS function 31 to return the address of the disk tables. If this
    >stat and the BDOS don't match, it shows some garbage.


    It may be hard coded inside stat or stat has a "inside address"
    so it knows where that diata is inside the BDOS.


    >> Allison
    >>>Udo Munk

    >
    >I did a little experiment to see if the 1.4 stat would work with the 1975
    >versions, but guess what, displays garbage too, this bits are not matching.
    >
    >For running 1.x programs on the 1975 system I modified the boot loader
    >to leave a JMP to the BDOS entry at address 5. The 1975 system doesn't
    >initialize anything in page zero, has not been invented yet. With this one
    >can run some of the 1.x programs like stat on the 1975 version. Don't try
    >ddt tho, it destroyes the boot loader in page zero.


    You mean pre 1.4, correct? I know 1.4 does init page 0.
    >
    >The 1975 bits at the web server are updated, if anyone wants to play with
    >this.


    Should be interesting.

    Allison

    >Udo Munk



+ Reply to Thread
Page 1 of 2 1 2 LastLast