ewen@actrix.gen.nz (Ewen McNeill) (03/27/91)
[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