Date : Wed, 27 Mar 1991 09:47:31 GMT
From : usc!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!actrix!ewen@apple.com (Ewen McNeill)
Subject: Amstrad BIOS problems -- Moderately Long
[To those who are not interested in the nitty gritty of a fairly
annoying bug in a patch to the Amstrad Bios, please skip this message
now. Anyone else, feedback is very welcome to ewen@actrix.gen.nz, or to
this group]
After seeing various peoples thoughts about what the problem with the
Amstrad BIOS which causes certain programs not to work properly, I did
some experimenting with my Amstrad.
The hardware concerned was an Amstrad CPC6128, with serial interface,
512K of extra ram. For the entire of the test, I used David Goodenough's
unzip program (wonderful program, despite the problems that Amstrad
has), and a 20K Zip file which I picked up somewhere.
The first thing I tried was removing all my extra hardware, and using
the original boot disk. Unzip from A to B drive, worked fine. The next
thing was to reintroduce the hardware. The Unzip still worked fine. I
then went back to my normal boot disk (with silicon disk patch), and
tried the same thing. It worked fine.
Then I started experimenting with variouus combinations of drives, and
came up with the following results:
ZIP file Output file Error?
A A No.
A B No.
B B No.
B A No.
C C No.
C B No.
C A No.
A C Yes.
B C Yes.
These results did not change with various pieces of hardware plugged in,
or various patched versions of the CP/M Plus file. Obviously the C
drive doesn't exist under unpatched versions, so that couldn't be
tested.
However, this does rule out one possibility, of the patched mentioned in
the Serial Interface "Book of Spells" (for the uninitiated, this book
has a picture of a wizard on every page... talk about annoying!). I
have tried this patch, and it didn't help. I have also tried the patch
for double sided drives (I have one), and it didn't help either.
Because of the way that unzip works (decompresses to default drive),
decompressing to C drive required a command sequence like:
A>c:
C>a:unzip a:zipfile.zip e
This means that C drive is the current drive. This seemed to be the only
time when the bug showed up. I am not sure whether this bug applies to
writing, or not, I suspect that it doesn't. [Other evidence supports
this, see below]
This leads me to the following conclusion: There is a bug in the patch
for the silicon disk which causes problems when the silicion disk is the
current one, and one of the other drives is read from. This bug is an
occassional one, which appears apparently at random. This suggest
something like interupts being enabled at the wrong time, or whatever.
BTW, every time I have had a failure in this manner (a "faulty" block in
a file), I have been logged into C drive (I usually do -- it is a good
temporary drive), and reading from a floppy drive (usually B). This
tends to confirm my research of today.
I am continuing my disassembly of the PATCHER.COM program. I have
sorted out most of the program which does the actual patching, but
sorting out the bits that are patched over is more of a problem. I am
using DazzleStar (my first time, it looks good) to do the disassembly,
and it allows me to declare various bits as instructions, bytes, words
etc. Very powerful. If anyone wants a copy of the DazzleStar temporary
file (which will allow you to look through PATCHER.COM too), let me
know.
I would appreciate someone else trying to duplicate my results. This may
well explain why one poster didn't have any problems, and others of us
have. In the mean time, I would advise unzipping either from the floppy
drives to the floppy drives, or totally in the ram drive.
For your reference, other programs which are affected by this bug: ZDE,
Nsweep (only on certain sized files), LT29, FCRLZH, NULU. There are
probably plenty more, but those are the ones that I have run across so
far.
Any suggestions accepted by Email, or to this group.
--
Ewen McNeill. Email: ewen@actrix.gen.nz