| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Job codes'n buffers
Ok dudez! Need some help here.
Does the "seek" FDC job use the buffer? I mean to move the head, the drive needs to read the header block in order to find out where the head is positioned. I'm not sure though, if this data is stored in the buffer or somewhere at zero-page.
Anyone? |
|
... 10 posts hidden. Click here to view all posts....
|
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Oops! Seems that I've totally forgotten $0200. I kept saying: "They should have given the drive at least 256 bytes more", and seems that they did. ;)
The problem was that the drivecode could not be written at $0200 using M-W... No idea why. However, I could use this place for one of the buffers, and as I said, I forgot about it. :)
Ok, the loader doesn't use _any_ ROM routines now. (except for the GCR conversion tables, which are not routines :).
The protocol works (thanks Lasse!), and the program is loading into memory. However, seems that every 12th byte is corrupted. After some debugging, seems that the problem is the GCR reader, not the transfer, so I can't blame Lasse. ;-D
Strange thing is: why _every 12th_ byte? ... :/
Still, I'll have to check the routines you mentioned. I have to use some of them, and free some memory. Otherwise, there will be no place for the turn-disk checker (or whatever you call it).
Regarding the GCR reader, only one thing crosses my mind: maybe the GCR decoder takes too much time. The GCR data is partially decoded on the fly (I mean while reading the disk surface). 5 GCR bytes are _partially_ decoded at each iteration (which gives 4 binary bytes. 12 is perfectly dividable by 4. :-) Which means that a byte is corrupted each 3rd iteration).
So I have to ask one more thing. ;)
- What is the average time that needs to pass untill new data is available at $1C01 ? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
the time available for a GCR byte is ofcourse different for different speedzones. in theory you have 32, 30, 28 or 26 cycles for every byte.
BUT this only applies for writing! on reading this is way more difficult because it depends on the drive motor used to write the disk and the drive motor used to read the disk. for example, on a standard 1541 you have about 300 rpm while a 1571 often has more than 320 rpm. this means that you have even less cycles time to be safe. you cant do much more than reading a byte from $1C01 and storing it into memory (the loop above already uses 18 cycles).
|
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Graham wrote:
> on reading this is way more difficult
> because it depends on the drive motor
> used to write the disk and the drive
> motor used to read the disk.
Is this the reason why +H2K only works on 1541-II ?
What's the real difference between these drives anyway? (apart from the ROM). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
possible differences:
1. different maximum head speed
2. different rotation speed
3. different rotation acceleration
4. different mhz for cpu in c64 and 1541
incompabilities due to no.1 happen quite often due to people using too fast head movements which only work on a few drives.
no.4 is due to different clocks for c64 and 1541 cpu. there are small differences from quartz to quartz and very tight timing in IEC transfer routines may fail due to these.
no.2 only is a problem when you use disks formatted on other drives... |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
You guys rule! ;-D
Yups! It's working. My very first disk loader! ;-D
It's still needs some finalizing before I release it for beta testing. However, I experienced the first problems:
- I tried it with a 1541 (old) that sometimes has reading/writing problems... It worked. ;-)
- Then I tried another 1541 (old) in much better condition. Worked aswell.
- The 1541-II test: The first time I ran it, it said file not found. :-( I tried it a few more times, and worked well.
- Also works in CCS (and I believe VICE too).
I guess the first time it didn't read the directory as supposed. Maybe I move the head too fast, so it eventually ended on a half track.
I hate this kinda bugs. They are really hard to fix. (unless you know exactly what the problem is).
Btw, a turn disk checker is not yet implemented, 'cause I have used all the available RAM. (not counting zero, and first page). |
| Previous - 1 | 2 - Next |
