ruud.baltissen_at_apg.nl
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.