| |
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? |
|
... 5 posts hidden. Click here to view all posts....
|
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Thanks, both of you! So, as the drive has no idea where the head is positioned, it has to read the header block in order to find out. However, it also doesn't know what density to select. Which means that it'll have to cycle through different densities, until it successfully reads the header. There's no problem then. (Except running out of memory :) |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
One more thing:
- I use the approach of KM's loader to find the data block. However, the routine needs some data at $24. It's the contents of the header block that is searched for. Once it's found, the data block is at the next sync-mark. What I don't know is what routine is used to create this data? The header scanner routine is at $F527. I thought about making my own routine, but I have only a few bytes left. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Cybernator wrote:
"[...] So, as the drive has no idea where the head is positioned, it has to read the header block in order to find out. However, it also doesn't know what density to select. [...]"
you have to keep track about where the head is. if you use the seek jobcode, you know that you're on track X. so if you move the head 2 halfsteps up, you're on track X+1. even changing disks does not affect this because the head is not moved by this.
Cybernator wrote:
"[...] What I don't know is what routine is used to create this data? The header scanner routine is at $F527 [...]"
the key routine is at $F50A:
this routine first encodes a header like it is expected (track and sector is taken from jobcode t&s, header id is taken from $12/$13). then it searches for a sync signal, reads the GCR data from disk after the sync and compares it with the previously encoded header and if this doesn't fail it will search for a second sync signal. after that the subroutine returns and you can start reading the sector gcr data.
typical search block, read GCR and decode routine:
; search for block
JSR $F50A
; read first 256 GCR bytes
LDY #$00
loop1: BVC loop1
CLV
LDA $1C01
STA $0300,Y
INY
BNE loop1
; read remaining bytes
LDY #$BB
loop2: BVC loop2
CLV
LDA $1C01
STA $00FF,Y
INY
BNE loop2
; decode GCR data
LDA #$03
STA $31
JSR $F8E0
; checksum test
LDA $3A
LDY #$00
loop3:
EOR $0300,Y
EOR $0380,Y
INY
BPL loop3
this routine only works if the disk is initialised, the head is on a know track/sector and the header has no read error. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
It also works very nicely with tracker 36-40 :) I know SounDemon uses job code $e0 to read a sector (I think) which has some setup but gets the motor working and moves head over desired track & sector, ie if $e0 is used in $00 then code is executed at $0300 or something. I think Inside Commodore DOS or something have a brief explanation of major ROM routines are one of the more common 1541 disassemblies does. Maybe aay41? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
yes, the above code is used with $E0 jobcode and buffer 0 ($0300)... it's obvious because of all this STA $0300,Y and that LDA #$03 / STA $31 |
| |
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 |
