CP/M-86 1.1: HLT requested - CP/M

This is a discussion on CP/M-86 1.1: HLT requested - CP/M ; Apologies if this is something everyone else knows about and has long since corrected. I was running CP/M-86 in XDOSEMU under Linux, and I noticed that every time I ran an external command, the console from which CP/M-86 had been ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: CP/M-86 1.1: HLT requested

  1. CP/M-86 1.1: HLT requested

    Apologies if this is something everyone else knows about and has long
    since corrected.
    I was running CP/M-86 in XDOSEMU under Linux, and I noticed that every
    time I ran an external command, the console from which CP/M-86 had been
    launched printed a line reading

    ERROR: HLT requested: lina=0x72e!

    The reason is that the serial number in the CCP doesn't match the serial
    number in the BDOS, at least in my copy. There's a little subroutine at
    0051:020E that does the comparison:

    serialize:
    mov di,09DCh
    mov si,0B00h
    mov cx,6
    rep cmpsb
    jcxz ser1
    jmps badserial

    ser1: ret
    badserial:
    hlt

    What happens is that control passes to the HLT (hence the error at 51:21E,
    i.e. absolute address 0072E). Then it falls through into the next
    subroutine, which checks if the byte at SI is a delimiter, and that returns
    to the caller.
    Never knew it did that. It's obviously an easy thing to patch out - just
    replace the HLT with a RET, or fix the serial numbers.

    --
    ------------- http://www.seasip.demon.co.uk/index.html --------------------
    John Elliott |BLOODNOK: "But why have you got such a long face?"
    |SEAGOON: "Heavy dentures, Sir!" - The Goon Show
    :-------------------------------------------------------------------------)

  2. Re: CP/M-86 1.1: HLT requested

    Hello John,

    This topic might be found under 'CP/M-86 Pedigree', or some such.
    I don't know how widely this is known, but Freek, Anon and I, do know
    it.
    This is carry over code from when the 8080 CCP was translated, and
    because the commonly distributed version's S/N's don't match there is a
    ?harmless? logic leak in the program flow. This hasn't been fixed.
    Since the S/N's are bogus & don't match, it is a way to find out the
    'pedigree' of the binary in use, i.e. roughly, where the binary came
    from. As you know, Halt on the 8080 halts the processor until reset,
    on the 8086 it halts the processor until the next non-maskable
    interrupt [timer-tick].

    The other issue is the small stack size. On some newer systems the
    disk tables get overwritten so the M: drive is unavailable. I'm
    curious if this is so under XDOSEMU. [M: drv is unavailable anyways
    because it wants to use the segment area at C000h and that fails at
    initialization {or is it D000h?}]. The tables get overwritten at the
    point of the bios initialization as some RomBios calls on modern
    hardware use more stack.

    Steve

    John Elliott wrote:
    > Apologies if this is something everyone else knows about and has long
    > since corrected.
    > I was running CP/M-86 in XDOSEMU under Linux, and I noticed that every
    > time I ran an external command, the console from which CP/M-86 had been
    > launched printed a line reading
    >
    > ERROR: HLT requested: lina=0x72e!
    >
    > The reason is that the serial number in the CCP doesn't match the serial
    > number in the BDOS, at least in my copy. There's a little subroutine at
    > 0051:020E that does the comparison:
    >
    > serialize:
    > mov di,09DCh
    > mov si,0B00h
    > mov cx,6
    > rep cmpsb
    > jcxz ser1
    > jmps badserial
    >
    > ser1: ret
    > badserial:
    > hlt
    >
    > What happens is that control passes to the HLT (hence the error at 51:21E,
    > i.e. absolute address 0072E). Then it falls through into the next
    > subroutine, which checks if the byte at SI is a delimiter, and that returns
    > to the caller.
    > Never knew it did that. It's obviously an easy thing to patch out - just
    > replace the HLT with a RET, or fix the serial numbers.
    >
    > --
    > ------------- http://www.seasip.demon.co.uk/index.html --------------------
    > John Elliott |BLOODNOK: "But why have you got such a long face?"
    > |SEAGOON: "Heavy dentures, Sir!" - The Goon Show
    > :-------------------------------------------------------------------------)



  3. Re: CP/M-86 1.1: HLT requested


    On 2006-02-13 Steve Dubrovich said:

    > John Elliott wrote:
    >
    > > Apologies if this is something everyone else knows about and has
    > > long since corrected.
    > >
    > > I was running CP/M-86 in XDOSEMU under Linux, and I noticed
    > > that every time I ran an external command, the console from which
    > > CP/M-86 had been launched printed a line reading
    > >
    > > ERROR: HLT requested: lina=0x72e!
    > >
    > > The reason is that the serial number in the CCP doesn't match
    > > the serial number in the BDOS, at least in my copy. There's a
    > > little subroutine at 0051:020E that does the comparison:
    > >
    > > serialize:
    > > mov di,09DCh
    > > mov si,0B00h
    > > mov cx,6
    > > rep cmpsb
    > > jcxz ser1
    > > jmps badserial
    > >
    > > ser1: ret
    > >
    > > badserial:
    > > hlt
    > >
    > > What happens is that control passes to the HLT (hence the error
    > > at 51:21E, i.e. absolute address 0072E). Then it falls through
    > > into the next subroutine, which checks if the byte at SI is a
    > > delimiter, and that returns to the caller.
    > >
    > > Never knew it did that. It's obviously an easy thing to patch
    > > out - just replace the HLT with a RET, or fix the serial numbers.

    >
    >
    > Hello John,
    >
    > This topic might be found under 'CP/M-86 Pedigree', or some such.
    > I don't know how widely this is known, but Freek, Anon and I, do
    > know it.
    >
    > This is carry over code from when the 8080 CCP was translated, and
    > because the commonly distributed version's S/N's don't match there
    > is a ?harmless? logic leak in the program flow. This hasn't been
    > fixed. Since the S/N's are bogus & don't match, it is a way to find
    > out the 'pedigree' of the binary in use, i.e. roughly, where the
    > binary came from. As you know, Halt on the 8080 halts the
    > processor until reset, on the 8086 it halts the processor until the
    > next non-maskable interrupt [timer-tick].
    >
    > The other issue is the small stack size. On some newer systems the
    > disk tables get overwritten so the M: drive is unavailable. I'm
    > curious if this is so under XDOSEMU. [M: drv is unavailable anyways
    > because it wants to use the segment area at C000h and that fails at
    > initialization {or is it D000h?}]. The tables get overwritten at
    > the point of the bios initialization as some RomBios calls on
    > modern hardware use more stack.
    >
    > Steve



    I'd almost forgotten about that stack size issue, Steve. Thanks
    for the reminder. The default stack space allocated by "CP/M-86
    For The IBM" is insufficient for many contemporary PCs.

    However, since I installed "CP/M-86 For The IBM" using Freek's
    'CVV' hard disk driver -- which also increases the available stack
    space -- I haven't experienced a single occurence of CP/M-86 losing
    its disk tables.

    So here's a "heads-up" for those who've done a standard install of
    "CP/M-86 For The IBM" on a 'modern' (386-and-up) machine:

    If you regularly have problems during a session, where CP/M-86 seems
    to "get confused," stops working and requires a reboot -- it's
    probably a stack space issue.

    The problem can be cured by using Freek Heite's 'CVV' hard disk
    driver, or by loading his '144FEAT2' floppy disk driver. Both of
    them increase the amount of available stack space -- which should
    eliminate the trouble.


  4. Re: CP/M-86 1.1: HLT requested


    > >
    > > This is carry over code from when the 8080 CCP was translated, and
    > > because the commonly distributed version's S/N's don't match there
    > > is a ?harmless? logic leak in the program flow.


    I doubt that Kildall had a direct hand in the S/N code 'cause:

    Keep
    It
    Logical
    Don't
    Accept
    Logic
    Leaks

    I suppose on the reverse of the coin could be:

    Gain
    Advantage
    Through
    Exterminating (sic)
    Superiors

    Actually there is Serialization Code out there in one of the source
    trees:
    GREBESER.A86 for an OEM to use to serialize his offering. It works by
    directly patching the diskette image.

    I have an original CP/M-86 for the IBM PC [no hard drive support] in
    which
    the serial numbers are in binary, not in ascii at all, but their value
    matches the ascii product S/N's.




+ Reply to Thread