MONTARON@FRP8V11.BITNET (Alexandre Montaron) (03/22/91)
Hello| I'm happy (in fact no) that someone else has found the bug... which replace a good sector (a CPM's block of 128 bytes) by anything else... But if you typed ^C (equal to Bdos fnct number 13) it will work perfectly| I thought it is because of my ram-disk (DK'tronics 256Ko)... because one of my friend has a CPC w/o ram-disk and all work well| I've a clue about the bug All read & write disk access pass throught buffer (see BCB=Buffer Control Blk) There's at all 32Ko of buffer (as tou can call cache disk|) located on bank number 2 if i remember well. If the patch of the ram-disk alter this area it will bug when CPM attempt to save this block (perhaps it's the patch itself|) Because ^C flush (but not save) all buffer to disk... I think the answer is near | Make a list of BCB, search buffer & verify content of all buffer... to solve the bug you have to minimize buffers... It's my opinion... What do YOU thing of this ? I've the OPERATOR's AND PROGRAMMER's GUIDE for the AMSTRAD CPC6128 & PCW8256 by Digital Research Inc. & Amstrad Consumer Electronics plc... it's a very good book but it doesn't talk about the BIOS... and BCB (buffers) are manage by the BIOS (see also DPH=Disk Parameter Header... which contain a pointer to the first BCB...) I've an other book which talk about the BIOS but it's very short | Does someone have a better book which talk about programming (not using|) CP/M+ include BIOS part please... Thanks... I hope i've forgetten anything... Alex Montaron <MONTARON@FRP8V11.BITNET>
ewen@actrix.gen.nz (Ewen McNeill) (03/25/91)
In article <9103220804.AA26926@ucbvax.Berkeley.EDU> MONTARON@FRP8V11.BITNET (Alexandre Montaron) writes: > Hello| I'm happy (in fact no) that someone else has found the bug... > which replace a good sector (a CPM's block of 128 bytes) by anything else... > But if you typed ^C (equal to Bdos fnct number 13) it will work perfectly| Oh, no, it is not just anything else. It is always the same. I had a 360K file which I was reading through after putting it through a naughty program (text file, BTW). There were 15 problems in it (15/2000 or so is not too bad, but not too good). Everytime there was the same string. Always. This has happened in the past. The string includes some NULLs (0), as well, but basically starts like this "s^L^s|FF|FFx@ff<fff<<`<....". Everytime. Most annoying. It also makes me think that it is actually program which is being put in, probably because someone failed to save a register, or something. > I thought it is because of my ram-disk (DK'tronics 256Ko)... because one of > my friend has a CPC w/o ram-disk and all work well This is interesting. I haven't been able to test it without the ram disk, because I have had the software installed for ages (and it is hard to test for something which is intermittent). At one stage I did think that it was something to do with the patch put on for the ram disk, and I started disassembling that. I ran out of time (near end of year, and I am a student....:-( It looks as though I should go back to this. Thought -- how old is your CPC? Mine is a model A. I wonder if this has anything to do with the problem (ie, a bug fix in later versions?). > I've a clue about the bug > There's at all 32Ko of buffer (as tou can call cache disk|) located on bank > number 2 if i remember well. If the patch of the ram-disk alter this area it > will bug when CPM attempt to save this block (perhaps it's the patch itself|) > Because ^C flush (but not save) all buffer to disk... This sounds like what I was thiking of, although I hadn't got as far as exploring the buffering. If you are able to do what you are suggest please do so. For my part, I will continue my disassembly of the patch. dk'tronics are too far gone to be able to fight about the reverse engineering, or help with a bug fix. > I've the OPERATOR's AND PROGRAMMER's GUIDE for the AMSTRAD CPC6128 & PCW8256 > by Digital Research Inc. & Amstrad Consumer Electronics plc... it's a very > good book but it doesn't talk about the BIOS... and BCB (buffers) are manage > by the BIOS (see also DPH=Disk Parameter Header... which contain a pointer to > the first BCB...) I've an other book which talk about the BIOS but it's very > short | Indeed it is sad. What do you have which talks about the BIOS? We really need something which talks about the Amstrad BIOS, or better still a disassembly. I will ask someone who does a lot of CP/M programming here if they have any good books. Anyway, I am pleased to see that I am not alone. This also tends to suggest to me that I was on the right track disassembling the patch for the silicon disk. If I can only find the disk it was on (1 of about 200....) I will go back to it. BTW, are there any other Amstrad CPC owners out there with this problem? -- Ewen McNeill. Email: ewen@actrix.gen.nz