A: - CP/M

This is a discussion on A: - CP/M ; After 32 years it does show the prompt again. Sample session: READY DISK A A>dir *.* A>type boot.asm BOOT.ASM? A>b: READY DISK B B>dir *.* B>^C READY DISK A A> Directory search is broken, don't know why yet. I verified ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: A:

  1. A:

    After 32 years it does show the prompt again. Sample session:

    READY DISK A

    A>dir *.*
    A>type boot.asm

    BOOT.ASM?
    A>b:

    READY DISK B
    B>dir *.*
    B>^C

    READY DISK A

    A>

    Directory search is broken, don't know why yet. I verified already that
    track 2 is accessed for reading the directory.

    All sources available at ftp://ftp.unix4fun.org/z80pack/sources/cpm1975/

    Compile bdos.plm, ccp.plm and boot.asm to hex files and copy to a CP/M 2
    disk. Use sysgen.sub to write the bits with CP/M 2 sysgen onto an empty
    disk and boot from that.

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


  2. Re: A:

    Udo Munk wrote:
    >
    > After 32 years it does show the prompt again. Sample session:
    >
    > READY DISK A
    >
    > A>dir *.*
    > A>type boot.asm
    >
    > BOOT.ASM?
    > A>b:
    >
    > READY DISK B
    > B>dir *.*
    > B>^C
    >
    > READY DISK A
    >
    > A>
    >
    > Directory search is broken, don't know why yet. I verified already that
    > track 2 is accessed for reading the directory.


    In CP/M the dir function is performed entirely in the CCP (making
    BDOS calls). This limits the areas you need to check. Of course
    the disk itself has to be correctly formatted and have actual
    files.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.



    --
    Posted via a free Usenet account from http://www.teranews.com


  3. Re: A:

    On Thu, 25 Oct 2007 07:46:39 +0200, Udo Munk wrote:

    ....
    > Directory search is broken, don't know why yet. I verified already that
    > track 2 is accessed for reading the directory.

    ....

    Fixed the problem, directory scan is working now. New bdos.plm source
    available at the web server. I'm going to implement the reader port now,
    so that the loader can be used.

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


  4. Re: A:

    In article <4720383D.A8E492FD@yahoo.com>,
    CBFalconer wrote:

    > In CP/M the dir function is performed entirely in the CCP (making
    > BDOS calls).


    Except for CP/M 3 which, if you asked for anything advanced of the
    built-in DIR, would would run DIR.COM to do the fiddly bits.

    --
    Paul Martin

  5. Re: A:

    On Thu, 25 Oct 2007 02:31:25 -0400, CBFalconer wrote:

    > Udo Munk wrote:

    ....
    >> Directory search is broken, don't know why yet. I verified already that
    >> track 2 is accessed for reading the directory.

    >
    > In CP/M the dir function is performed entirely in the CCP (making BDOS
    > calls). This limits the areas you need to check. Of course the disk
    > itself has to be correctly formatted and have actual files.
    >
    > --
    > Chuck F (cbfalconer at maineline dot net)


    The problem was the DMA stuff, Torode's floppy disk controller required
    131 bytes DMA transfer instead of 128. The data is leaded by 3 bytes with
    the track and sector numbers and another byte which function is not clear
    to me, because I don't know that controller used. The Z80SIM FDC just
    wants the 128 byte data for the DMA transfer. All DMA transfers were off
    by 3 bytes, because I didn't understand it right away.

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


  6. Re: A:

    On Thu, 25 Oct 2007 14:51:00 +0200, Udo Munk wrote:

    > On Thu, 25 Oct 2007 07:46:39 +0200, Udo Munk wrote:
    > Fixed the problem, directory scan is working now. New bdos.plm source
    > available at the web server. I'm going to implement the reader port now,
    > so that the loader can be used.


    It's flying, example:

    READY DISK A

    A>dir *.*
    BYE COM
    LOAD COM
    A>load

    SOURCE IS READER

    FIRST ADDRESS 0100
    LAST ADDRESS 0132
    BYTES READ 0033
    RECORDS WRITTEN 01

    A>dir *.*
    BYE COM
    LOAD COM
    $$$ COM
    A>ren hello.com=$$$.com
    A>hello
    HELLO WORLD

    READY DISK A

    A>bye

    HALT Op-Code reached at 0101

    Well, the NASA guys might say now: the eagle has landed, again! :-)

    Bits at web server updated, I'll also put a ready to boot disk image there
    for you.

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


  7. Re: A:

    On Thu, 25 Oct 2007 07:46:39 +0200, Udo Munk wrote:

    ....
    > All sources available at ftp://ftp.unix4fun.org/z80pack/sources/cpm1975/

    ....

    There are 2 boot loaders now, boot.z80 to be assembled with z80asm and
    boot.mac to be assembled with mac80. Thought it's more stylish to use the
    ancient cross development tools for this one.

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


  8. Re: A:

    On Thu, 25 Oct 2007 11:19:29 -0800, glen herrmannsfeldt wrote:

    > Udo Munk wrote:
    > (snip)
    >
    >> The problem was the DMA stuff, Torode's floppy disk controller required
    >> 131 bytes DMA transfer instead of 128. The data is leaded by 3 bytes with
    >> the track and sector numbers and another byte which function is not clear
    >> to me, because I don't know that controller used. The Z80SIM FDC just
    >> wants the 128 byte data for the DMA transfer. All DMA transfers were off
    >> by 3 bytes, because I didn't understand it right away.

    >
    > What goes on the disk, (not necessarily in this order), is
    > track (actually cylinder), side (track in cylinder), sector, and length.
    > The length isn't the actual length but a code for the length.
    > (It might be log2(length)-7.)
    >
    > Most floppy disk controllers, though, will write whatever is
    > given by the format routine. The sector headers aren't normally
    > changed by sector writes.
    >
    > -- glen


    It doesn't look like a length byte:

    /* SELECT NON DELETED DATA */
    DATAV = 0FBH;

    I don't know what they meant with that, whatever, there won't be many
    Torode controllers around anymore, not really interesting nowadays.

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


  9. Re: A:

    Udo Munk wrote:
    (snip)

    > The problem was the DMA stuff, Torode's floppy disk controller required
    > 131 bytes DMA transfer instead of 128. The data is leaded by 3 bytes with
    > the track and sector numbers and another byte which function is not clear
    > to me, because I don't know that controller used. The Z80SIM FDC just
    > wants the 128 byte data for the DMA transfer. All DMA transfers were off
    > by 3 bytes, because I didn't understand it right away.


    What goes on the disk, (not necessarily in this order), is
    track (actually cylinder), side (track in cylinder), sector, and length.
    The length isn't the actual length but a code for the length.
    (It might be log2(length)-7.)

    Most floppy disk controllers, though, will write whatever is
    given by the format routine. The sector headers aren't normally
    changed by sector writes.

    -- glen


  10. Re: A:


    Udo Munk wrote:
    > On Thu, 25 Oct 2007 11:19:29 -0800, glen herrmannsfeldt wrote:
    >
    >

    <<< snipped >>>
    >
    >
    > It doesn't look like a length byte:
    >
    > /* SELECT NON DELETED DATA */
    > DATAV = 0FBH;
    >
    > I don't know what they meant with that, whatever, there won't be many
    > Torode controllers around anymore, not really interesting nowadays.
    >
    > Udo Munk


    Hi Udo,

    It is interesting to see that code working again after so many years!

    The SA800 Theory of Operations manual says on page 8 that "Address Marks
    are unique bit patterns use to identify the beginning of ID and Data
    fields ..." and that "there are four different types of Address Marks
    used". The value for the Data Address Mark is 0xFB and the Deleted Data
    Address Mark is 0xF8.

    The Digital Systems FDC-I Interface Manual says on page 11:

    3) The three bytes in memory starting at the DMA
    address must be set to the desired track, sector,
    and address mark (for write).

    I checked the DSI CP/M 1.3 boot loader and it doesn't bother to set
    the address mark value before reading. But the BIOS does set it.

    I think that the controller can write sectors with deleted address
    marks. But I don't know if it will read them back. Another experiment
    to try.

    Jeffrey W. Shook.


  11. Re: A:

    On Thu, 25 Oct 2007 07:46:39 +0200, Udo Munk wrote:

    ....
    > All sources available at ftp://ftp.unix4fun.org/z80pack/sources/cpm1975/

    ....

    Updated the hello example program to use Gary Kildalls trick to avoid
    reboot from a PL/M program. Might be easier to figure from this example
    than from the loader, don't know, at least we want a nice example right?

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


  12. Re: A:

    On Thu, 25 Oct 2007 16:29:50 -0400, Jeffrey W. Shook wrote:

    ....
    >> It doesn't look like a length byte:
    >>
    >> /* SELECT NON DELETED DATA */
    >> DATAV = 0FBH;
    >>
    >> I don't know what they meant with that, whatever, there won't be many
    >> Torode controllers around anymore, not really interesting nowadays.
    >>
    >> Udo Munk

    >
    > Hi Udo,
    >
    > It is interesting to see that code working again after so many years!


    Yes, sure is.

    > The SA800 Theory of Operations manual says on page 8 that "Address Marks
    > are unique bit patterns use to identify the beginning of ID and Data
    > fields ..." and that "there are four different types of Address Marks
    > used". The value for the Data Address Mark is 0xFB and the Deleted Data
    > Address Mark is 0xF8.
    >
    > The Digital Systems FDC-I Interface Manual says on page 11:
    >
    > 3) The three bytes in memory starting at the DMA
    > address must be set to the desired track, sector,
    > and address mark (for write).


    Ah, now I understand. So that actually is relevant for real FDC's, gosh I
    haven't messed with one anymore since ages. Thanks for the explanation!

    > I checked the DSI CP/M 1.3 boot loader and it doesn't bother to set the
    > address mark value before reading. But the BIOS does set it.
    >
    > I think that the controller can write sectors with deleted address
    > marks. But I don't know if it will read them back. Another experiment
    > to try.
    >
    > Jeffrey W. Shook.


    The BDOS code initializes it once and it's used for reads and writes.
    Well, this has to be tried by someone with a real FDC, my emulation
    doesn't have to bother about such details, because it uses an image file.

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


  13. Re: A:

    On Thu, 25 Oct 2007 14:31:51 -0800, glen herrmannsfeldt wrote:

    ....
    > All IBM standard controllers that I know of allow writing
    > deleted data blocks, and detecting them on read.
    >
    > -- glen


    Thanks for explaining it, I do understand know why this bytes are put in
    front of the data buffer.

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


  14. Re: A:

    Udo Munk wrote:

    (snip)

    > It doesn't look like a length byte:


    > /* SELECT NON DELETED DATA */
    > DATAV = 0FBH;


    > I don't know what they meant with that, whatever, there won't be many
    > Torode controllers around anymore, not really interesting nowadays.


    There are two forms of the DAM (data address mark), the normal form
    and the deleted data address mark. For most that I know this is
    specified in the write command. For the 1793, for example, it
    is a modifier bit of the write sector command. For read sector,
    it sets a bit in the status register.

    For each sector on disk there is an IDAM (ID address mark)
    followed by the track number, side number, sector number,
    and sector length, and two bytes of CRC. (log2(length)-7)
    Then there is a write splice gap long enough for the drive
    to turn on the head and start writing. First some X'00'
    to give the PLL time to sync up, then either data address mark
    or delete data address mark, the data bytes, and two bytes
    of CRC, followed by a gap long enough for the drive to stop
    writing, including the possibly variation in disk speed and
    clock tolerance.

    All IBM standard controllers that I know of allow writing
    deleted data blocks, and detecting them on read.

    -- glen


  15. Re: A:

    On Thu, 25 Oct 2007 14:31:51 -0800, glen herrmannsfeldt
    wrote:

    >Udo Munk wrote:
    >
    >(snip)
    >
    >> It doesn't look like a length byte:

    >
    >> /* SELECT NON DELETED DATA */
    >> DATAV = 0FBH;

    >
    >> I don't know what they meant with that, whatever, there won't be many
    >> Torode controllers around anymore, not really interesting nowadays.

    >
    >There are two forms of the DAM (data address mark), the normal form
    >and the deleted data address mark. For most that I know this is
    >specified in the write command. For the 1793, for example, it
    >is a modifier bit of the write sector command. For read sector,
    >it sets a bit in the status register.
    >
    >For each sector on disk there is an IDAM (ID address mark)
    >followed by the track number, side number, sector number,
    >and sector length, and two bytes of CRC. (log2(length)-7)
    >Then there is a write splice gap long enough for the drive
    >to turn on the head and start writing. First some X'00'
    >to give the PLL time to sync up, then either data address mark
    >or delete data address mark, the data bytes, and two bytes
    >of CRC, followed by a gap long enough for the drive to stop
    >writing, including the possibly variation in disk speed and
    >clock tolerance.
    >
    >All IBM standard controllers that I know of allow writing
    >deleted data blocks, and detecting them on read.


    Correct, also they can read sectors with deleted data marks.
    One famous one was Tandy LDOS Single density using 1771.

    Allison

    >
    >-- glen



  16. Re: A:

    >>All IBM standard controllers that I know of allow writing
    >>deleted data blocks, and detecting them on read.


    >Correct, also they can read sectors with deleted data marks.
    >One famous one was Tandy LDOS Single density using 1771.


    It's a little muddier than that...

    The two commonly ued address marks are:

    0xFB = Normal data address mark
    0xF8 = Deleted data address mark

    However there are two less commonly found alternate/user address marks:

    0xFA = Alternate/User Normal data address mark
    0xF9 = Alternate/User Deleted data address mark

    The original 1771 can read/write all four address marks.

    Many later FDC's, including the 765 and it's decendants used on the
    PC cannot differentiate between the two types of address marks
    (Standard and Alternate/User) - not can they write the Alternate/User
    address marks. All they can do is detect "Normal" .vs. "Deleted",
    and write 0xFB (Normal) or 0xF8 (Deleted).

    All TRSDOS disks use deleted data address marks for the directory
    (IIRC) - Early Tandy disks used the Alternate/User address marks, and
    when imaged/restored, these get converted to the standard address
    marks - this was even a problem for Tandy on later systems with
    double-density controllers, and there are patches available to make
    early TRSDOS versions work with the standard address marks.


    --
    dave06a@ Low-cost firmware development tools: www.dunfield.com
    dunfield. Classic computer collection: www.classiccmp.org/dunfield
    com Some stuff I have for sale: www.dunfield.com/sale


  17. Re: A:

    Jeffery;
    I am back at trying to get some of my Old CP/M stuff working.
    I have three MPU-A S-100 Cards with the Large Crystals and the Yellow Caps
    Can you test them?????
    TIA
    Bob in Wisconsin

    Contact me using without SPAM

    trebor72SPAM@execpc.com

  18. Re: A:

    Dave Dunfield wrote:

    >>>All IBM standard controllers that I know of allow writing
    >>>deleted data blocks, and detecting them on read.


    >>Correct, also they can read sectors with deleted data marks.
    >>One famous one was Tandy LDOS Single density using 1771.


    > It's a little muddier than that...


    > The two commonly ued address marks are:


    > 0xFB = Normal data address mark
    > 0xF8 = Deleted data address mark


    > However there are two less commonly found alternate/user address marks:


    > 0xFA = Alternate/User Normal data address mark
    > 0xF9 = Alternate/User Deleted data address mark


    > The original 1771 can read/write all four address marks.


    > Many later FDC's, including the 765 and it's decendants used on the
    > PC cannot differentiate between the two types of address marks
    > (Standard and Alternate/User) - not can they write the Alternate/User
    > address marks. All they can do is detect "Normal" .vs. "Deleted",
    > and write 0xFB (Normal) or 0xF8 (Deleted).


    Some of this is in the WD data sheets. The 179x describes both
    FM and MFM marks. In FM, the marks are distinguished from ordinary
    data by removing certain clock pulses that would otherwise be there.
    The 179x when formatting (write track command) can write F8 through FB,
    but there are only two choices for write sector, as you say.
    In formatting, writing the address mark also initialized the CRC
    register. FC is the index mark (an optional mark at the start
    of each track). FE is the IDAM, preceding the cylinder, track,
    sector, length, identifying the sector.

    For MFM, address marks are distinguished by a preceding A1 with a
    missing clock pulse, and writing the A1 initializes the CRC.
    For write track the 179x can write any character after the A1,
    but F8 and FB would be usual.

    The 1771 does indicate that F9
    and FA are not part of the IBM standard, but are 1771 specific.
    There are two bits in the 1771 write command to select them,
    and two bits in the status register for read. One of those
    bits (for both the command and status register) was reused
    for something else, by the time of the 179x.

    > All TRSDOS disks use deleted data address marks for the directory
    > (IIRC) - Early Tandy disks used the Alternate/User address marks, and
    > when imaged/restored, these get converted to the standard address
    > marks - this was even a problem for Tandy on later systems with
    > double-density controllers, and there are patches available to make
    > early TRSDOS versions work with the standard address marks.


    -- glen


+ Reply to Thread