| |
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? |
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
As far as I can tell it does nothing. It is often used to move heads and start the reading process and you finish with your own GCR read, $1xx bytes to some buffer and $01b7-$01ff or something then some ROM routine to convert. I'm sure others will have better knowledge but Inside something hosted by STA has it. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Oops, seems I was thinking of the buffer execute, not seek but I'm sure seek does not harm buffer contents as it does not read sector data, I'd guess only the sector header stuffs. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Seems that I'll have to remove all FDC jobs from my loader.
Seek works the first time, but not later... So, I'll use my own code. Another question pops:
- Is the track density important only when writing, or both at read and write ?
KM's loader doesn't seem to be selecting different densities (at least I couldn't find part of the code that does that). However, it uses a ROM routine to find the begining of the data block. I'm not sure if this routine maybe selects the densitiy. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
density is important. A number of loaders use a ROM routine that reads the header which also sets appropiate density. I'm sure this routine is also 40 track compatible. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
density should be set on both, reading and writing. you can read density 0 when you have density 1 selected but it will not work too reliable... and density 2 wouldn't work at all.
you really should set the right density, no matter what you do... except for copy protections :) |
| |
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 |
... 5 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
