Date: 2009-01-20 15:15:22
Hallo allemaal, Another update. I had this (not so) new idea: use extra RAM to store the BAM. The "not so" because that is what the IEEE drives do as well (AFAIK): they use seperate buffers for the BAM and directory. Isolating the routines that do something with the BAM was relatively easy. The next thing was to tell them to use (in the 1541 not existing) buffer 8 at $0B00. To my suprise things still didn't work out as I thought :( And again things went wrong with copying files. I created a sequential file where the first sector is filled with A's, the second with B's, the third with C's, etc. etc. I copied several times. The length of the copied files varied randomly. Until the last sector every sector contained the values as should. But the last one contains the BAM. And that really puzzles me. As said before the used RAM is unknown to the original 1541 routines. So IMHO it cannot be read by accident. Thus it has to be the reading of the BAM sector itself. And now I have to find out what event tells the 1541 to read this sector instead of the one of the original file. What makes things difficult is this randomness of the length of the copied files. The only thing I can think of is that the interrupt is involved in one or another way. But in what way? I also have a new debug weapon (at least new to me): the extra RAM. This morning I found the place (I think) where the data to be copied is loaded. Somewhere at the start of the copy routine I erase buffer 6 at $0900. And just before the actual loading routine I place this piece of code: stx debug1 ; temporary storage for X ldx BUF6 ; load pointer inx lda Track sta BUF6,X ; save value inx lda SECTOR sta BUF6,X stx BUF6 ; save pointer ldx debug1 ; restore X After the copy process address $0900 contains the number of sectors loaded (times 2) and from $0901 on I can see what track/sector is loaded every time. If indeed the BAM sector is loaded, then I have to find out what triggers the routine to load it. If it isn't loaded, my assumption that the 1541 doesn't know the extra RAM is wrong. I hope to find out more this evening...... -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| URL: Ruud.C64.org De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. APG Algemene Pensioen Groep NV is gevestigd te Heerlen en is ingeschreven in het handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617 The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose it's contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. APG Algemene Pensioen Groep NV is registered in the trade register of the Chamber of Commerce Limburg, The Netherlands, registration number: 14099617 Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.