03/07/88: RE: SPARKLIES Re: Msg 39004 by Delphi, | Category: Delphi - CoCo 3 Graphics | 13 comments - (Comments are closed)

RE: SPARKLIES Re: Msg 39004

39041 7MAR88-1547 CoCo 3 Graphics
RE: SPARKLIES (Re: Msg 39004)
From: HARDWAREHACK To: ARTFLEXSER

Art, you may be interested to know that the bug in the COPY command also
exists in the RS-DOS 1.1 rom. The bug is ACTUALLY in the CLOSE routine.
When an I/O error occurs during COPY, the FCB pointers are pointing to
the wrong place and the close function blows the stack away, causing
the COCO to crash. There is a simple fix for that bug which I implimented
in RGB-DOS and I will be glad to give you the source for that fix if
you are interested. It is only 5 or 6 lines of code… nothing big.

..Roger.

13 comments to RE: SPARKLIES Re: Msg 39004

  • pucc_unknown

    39057 8MAR88-0111 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39041)
    From: ARTFLEXSER To: HARDWAREHACK

    Thanks, Roger. I WOULD be interested in seeing that fix for the CLOSE bug.

  • pucc_unknown

    39060 8MAR88-0119 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39057)
    From: MARTYGOODMAN To: ARTFLEXSER

    And I would be interested in the resultant updated ADOS!

    —marty

  • pucc_unknown

    39066 8MAR88-0151 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39060)
    From: ARTFLEXSER To: MARTYGOODMAN

    Sorry on that, I doubt that I could fit anything further into
    ADOS-3; every last byte is used and the code has been gone over and re-gone
    over to prune every last extra byte I could find out of it.
    But, if the fix is REAL, REAL short (say, 4 or 5 bytes), I might think about
    squeezing it in somehow.
    Fitting that code into an 8K EPROM was a real shoehorning job!

  • pucc_unknown

    39071 8MAR88-1215 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39066)
    From: HARDWAREHACK To: ARTFLEXSER

    Art, when I put in the fix for the CLOSE bug, I stuck it in the part of
    the code that parses the FILENAME/EXT:DRIVE from a BASIC line. Because
    RGB-DOS out of necessity has to parse multi-character drive numbers
    (like this: LOAD”PROGRAM:34″), the part of that routine that allows the
    reverse syntax ( LOAD”3:PROGRAM” ) was no longer possible to use. Therefore,
    the code that looks for the second character to be a “:”, then checks the
    first character for a range of 0 to 3 was NOP’d out. It wasn’t possible to
    distinguish between the first character being a drive number or part of
    the filename if there was more than 1 digit. That NOP’d out area is where
    I put the fix for the CLOSE bug, and it just fits with NO bytes to spare!
    You can put that in ADOS since it won’t take up any more ROM space, that
    is if you don’t mind losing the (useless) ability to put the drive number
    first in a filename.

    By the way, I have heard that when a DSKINI is done, the precompensation
    flag does not get reset and subsequent DSKINI’s will format a disk
    wrong. I looked thru the DSKINI code very carefully and it seems like
    the flag DOES get reset. Before a DSKINI is actually done, the code
    restores the drive to track zero. In doing that, DSKCON is used and
    DSKCON AND’s OFF the precomp bit, then checks for track 22 and OR’s it
    back ON if necessary. It seems like the act of restoring the head to
    zero in DSKINI would reset the precomp bit and therefore NOT cause
    the “Precomp bug”. Am I wrong??

    ..Roger.

    P.S. I will be glad to mail the source for the CLOSE bug fix, and I
    will include the addresses for both 1.0 and 1.1 RS-DOS. If I mail it
    to Spectro-Systems address in RAINBOW, will you get it?

    ..Roger.

  • pucc_unknown

    39083 8MAR88-2153 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39066)
    From: MIKEWARD To: ARTFLEXSER

    It’s rare that I get to suggest anything about YOUR programs
    that I can’t resist .

    Seriously, are there any features of ADOS that seemed like
    a good idea at the time but turned out to be used very
    little or perhaps not at all? Just woolgathering actually.
    Might be an oportunity to make some room if possible by
    some “pruning”?

    MI KE

  • pucc_unknown

    39074 8MAR88-1832 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39071)
    From: DONHUTCHISON To: HARDWAREHACK

    Roger,

    I covered “The DSKINI Bug” a while back in a paper in the Hardware Hacking
    topic of the database called (interestingly enough) “The DSKINI Bug”. Much
    the same article (also authored by me) was published in Under Color shortly
    before it went under… hope my article didn’t have anything to do with THAT!

    Anyway, *I* would like a copy of that source code also, in my MAIL box
    if that’s convenient.

    Don

  • pucc_unknown

    39097 9MAR88-0123 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39071)
    From: ARTFLEXSER To: HARDWAREHACK

    Roger, to me the ability to put the drive number first is more important than
    to have the fix for the obscure close bug (since users may well encounter
    software that employs the drive-number-first syntax), so I’ll pass on that
    suggestion of where to put th
    e fix, though I WOULD be interested in seeing the fix.
    Yes, the SpectroSystems address in Rainbow would do just fine, as it is my home
    address.
    The DSKINI fix I use in ADOS and ADOS-3 is a zero-byte fix
    consisting merely of replacing, at $D4FF, (in RSDOS 1.0) LDA #0, STA $EA with
    CLR $EC, CLR $EA. I no longer
    recollect the rationale exactly, but I do believe that it does the trick. I
    based it on the 1.1 revision that Microsoft made.
    I think you are mistaken in thinking that there is no bug, since DSKCON’S
    restore sequence does not appear to contain a CLR $EC to update the
    track number.

  • pucc_unknown

    39235 12MAR88-2010 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39071)
    From: HARBIE To: HARDWAREHACK

    INTERESTINGLY ENOUGH your question has the seed of it’s own reply .

    if you look over the code very carefully without the ffix you’ll find that when
    the dskini hits the head restore , the track pointer of the diskcon block is
    still pointing at whatever the last accesed trtack was , if you had just done
    another dskini th
    is will be the highest track . now if you follow the restore , as you noted the
    precomp flag is out then or’ed in if the trak is higher then 22 . in this case
    , it will be . now note this which is the heart of the whole problem , this
    registe
    er ram image is saved in memory with the precomp bit set .
    now in any normal set-up this would not be important sincc the next track
    access for a read or write would set it back straight (which is why doing a dir
    between dskini ssolves the bug) but if you go back to the dskini routine you’ll
    find tha
    t the write trtack is >>>not< << done using dskcon , it has it's own disk
    routine which does it’s own precomp check using (and there’s the kicker)
    >>>>the register ram image< <<< and it does not and it uot if the track is lower
    then 22 , it only or’s
    ‘s it in if it’s higher then 22 . ssincec we just saw in the restore that the
    precomp bit is already on in the ram image , the whole write track will be done
    with the precomp enabled C.Q.F.D (ce qu’il fallait demontrer , lit
    erally translate as what was to be demonstrated or more loosely TADAAAAA!)

    hope that made sense .

  • pucc_unknown

    39098 9MAR88-0131 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39083)
    From: ARTFLEXSER To: MIKEWARD

    Hey, nice to hear from you!! I really hate to prune any existing features out,
    especially to merely make room for a fix for a pretty obscure bug.
    My current favorite place to squeeze out a few bytes is to abbreviate the
    message that appears in place of RSDOS’ AE ERROR:
    “File exists – replace?”, instead using simply “Replace?”.
    I have a feeling that anything I eliminated would cause somebody, somewhere, to
    say “Hey, that was my favorite feature!”

  • pucc_unknown

    39108 9MAR88-1519 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39097)
    From: HARDWAREHACK To: ARTFLEXSER

    Art, in looking over the code for RS-DOS 1.0, I see where the DSKINI
    bug comes from and yes, a CLR $EC would fix it. I work with RS-DOS 1.1
    and that was fixed in 1.1 so I didn’t see it.

    By the way, I have a question that I have been wanting to ask you…
    why did you write ADOS based on 1.0 rather than 1.1?

    …Roger.

  • pucc_unknown

    39109 9MAR88-1525 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39074)
    From: HARDWAREHACK To: DONHUTCHISON

    Don, I would be happy to send you the source for the “CLOSE” bug. I would
    send it to your EMAIL box, if I knew how. Maybe you could leave me your
    address in MAIL and I will send it to you via US Mail?

    …Roger.

  • pucc_unknown

    39112 9MAR88-1812 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39109)
    From: DONHUTCHISON To: HARDWAREHACK

    It’s pretty easy to send files through the MAIL system here. Just upload
    the file to your workspace, then get into MAIL either by entering /MAIL from
    WOrkspace, or by entering MAIL from the CoCo SIG prompt.

    If you’re trying to send the file called COPYPTCH.TXT, for example, then just
    type SEND COPYPTCH.TXT at the MAIL prompt. You’ll be asked for
    a username and then a subject, and that’s it! Simple, huh?

    Anyway, I’ll send you my address in case that’s easier for you.

    Don

  • pucc_unknown

    39120 9MAR88-2116 CoCo 3 Graphics
    RE: SPARKLIES (Re: Msg 39108)
    From: ARTFLEXSER To: HARDWAREHACK

    Roger, there were two reasons for basing ADOS on the 1.0 version rather than
    1.1. First, at the time ADOS was introduced, 1.1 had come out rather recently
    and there was quite a bit of old software
    that wouldn’t run under it. So, I could promote ADOS as curing “1.1
    compatibility headaches”.
    Second, the 1.0 ROM was shorter, even allowing for the fact that a DOS command
    would have to be added. This permitted me to jam in more features than I
    otherwise would have been able to, although it meant sacrificing
    a few minor pluses that 1.1 has over 1.0: a slightly faster interpret loop,
    and a few fixes for obscure bugs in 1.0. (Though I did incorporate the shorter
    bug fixes into ADOS.)