Date: 2007-12-27 08:34:01
Hallo Matt, > i think you need to sync the pc to these times?? Not at all. These timings only exists so the drive can make optimal use of the storage of a track. The PC doesn't do this at all: it just dumps 9 sectors of 512 bytes on every track (360 KB version). Some programs abuse these timings as a kind of copy protection: they rewrite some parts of the disk with another speed then the original one. If read > anyway if i send someone this book can they scan it to pdf??? No problem. But realise that, having a sheetfeeder, I'll have to cut the back of the book. If interested, send me a PM. Hallo allemaal, I found some time to test IDE1.ASM and it partly works. Partly because I have a very strange error and I haven't found the cause yet. At http://www.baltissen.org/files/ide1.asm you'll find the sources. When formatting the disk, the stored ID is replaced by zeros. I solved this problem by replacing the ID with pre-programmed values; just look foor " lda #'R'" in the source. 40 lines above you'll find the marker @@10. At this point things are fine. So somewhere in these 40 lines is a subroutines that causes the trouble. The funny thing is that I can save and load a file W/O any trouble. But when trying to format the disk for the second time, the process ends up with a writing error on track 18, sector 0. When checking, things look allright. I have the idea that whatever changes the stored ID, also changes other Zeropage values, causing the "compare aftre writing" routine to go wrong. My idea for the moment: I use X or Y in a subroutine W/O checking if it holds a value needed for other routines. The only tool I have at the moment is my so called POSTcode display: two intelligent 7-segments display connected to the free A-port. This enables me to have a look at certain values but a far from ideal tool. I need some help with a very weird behavior. At marker &&&12 you'll find the subroutine FormatTrack. Somewhere down you'll find the line "; cli". The weird thing is that when I remove the semicolon and thus give the command to enable interrupts, the drive won't change tracks any more. Changing tracks is done by the Interrupt routine so I can imagine that SEI without CLI would cause this problem, but no, only CLI does. Anyone has an idea? As you can see, I'm at work. But next week I have a week oof, thus more time to work on the project :) -- ___ / __|__ / / |_/ 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. Stichting Pensioenfonds ABP is gevestigd te Heerlen en ingeschreven bij de Kamer van Koophandel Zuid Limburg onder nummer: 41074000 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 its 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. Stichting Pensioenfonds ABP, having its registered office at Heerlen, is registered in the Traderegister of the Chamber of Commerce Zuid Limburg (Maastricht), the Netherlands, registration number: 41074000 Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.