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.
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.
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
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!
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.
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”?
MIKE
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
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.
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 .
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!”
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.
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.
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
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.)