| |
TCE
Registered: Sep 2011
Posts: 29 |
Release id #90210 : Format II
Documentation heads up, for those interested in a quick start with this excellent facility.
Within "README.txt", under "STAND-ALONE EXAMPLE" the JSR instruction should be corrected: it's not $ffba we need to JSR to, but $ffbd (set filename properties).
Furthermore, a complete example could look like this:
processor 6502
include "format2_runtime.i"
org $080d
start:
ldx #<fmt_cmd
ldy #>fmt_cmd
lda #9
jsr $ffbd
lda #0
jsr fmt2_format ; format disk
rts
fmt_cmd:
dc.b "N0:TLR,00" |
|
| |
tlr
Registered: Sep 2003
Posts: 1703 |
Doh! Well spotted. Better correct that for format III then. :) |
| |
TCE
Registered: Sep 2011
Posts: 29 |
Hey tlr! Will there be a version III then?
BTW, I included the functionality of "Format II" in my IECHost project, for which I shall give you full credit, of course. It was pretty simple to get going with it, due to the way sources are structured.
Side question: when stepping the head all the way out, is there a reason you are adding 4 steps to the total amount to step, based on the current track under head?
I am asking because I'd really like to get rid of that rattling noise, if possible to do so, while still reliably aligning the head onto the outer track. |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
There will eventually be a format III. I have a working iteration of it but it needs to be finalized and tested.
The extra steppings are there because they are there in speeddos plus. I guess they will help if the head is slightly off when starting to step but I never tried removing it. My implementation does some step up/down initially before trying to seek headers to identify the current track. Maybe that's enough to be sure.
If the disk is unformatted there is no other way to be sure than bumping. |
| |
TCE
Registered: Sep 2011
Posts: 29 |
Thanks for the feedback. I shall do some testing without the additional stepping, but ATM I am limited to a single drive and a handful disks only. Not an extremely useful test setup I am afraid.
Re: "If the disk is unformatted there is no other way to be sure than bumping." - Fully appreciate that. However, if the drive was previously accessing a healthy DOS formatted disk, it should be possible to rely on the fact that the track number it was accessing previously is still current on the unformatted disk.
Something along those lines might come handy for batch formatting. |
| |
TCE
Registered: Sep 2011
Posts: 29 |
While testing I stumbled on a different oddity, which is happening with the vanilla version of format_c000.prg.
I first reproduced this oddity on IECHost, but then on VICE too (with true drive emulation enabled).
Essentially you can use the following "minimal" program to reproduce the issue:
processor 6502
include "format2_runtime.i"
org $080d
start:
ldx #<fmt_cmd
ldy #>fmt_cmd
lda #9
jsr $ffbd
lda #0
jsr fmt2_format ; format disk
rts
fmt_cmd:
dc.b "N0:TLR,00"
For building the example, you can go about as per below:
del test.prg test-exo.prg
dasm test.s -otest.prg
exomizer sfx $080d test.prg format2_c000.prg -o test-exo.prg -n
del test.d64
c1541 -format tlr,00 d64 test.d64 -write test-exo.prg "test"
del test.prg test-exo.prg
Once done, start the PRG on the resulting disk, test.d64: yes the program on the disk will format the disk itself. When back in direct mode, type the usual:
LOAD"*",8
At the LIST command you only get:
0 {rvs on}"
Reason being that disk name is returned as a string of zeros.
Now if you init the disk:
OPEN15,8,15,"I0";CLOSE15
And then retrieve the directory listing, things work fine.
Is this something that's expected? I have no problem initialising the disk after formatting, but I found it odd. |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
It is supposed to mark BAM as invalid to force the drive to refetch that on the next access. Apparently that's not working in your case. I'm not sure why. Will have a think... |
| |
TCE
Registered: Sep 2011
Posts: 29 |
Just to clarify, the 0-BAM read is happening with format2_test.prg as well when true drive emulation is enabled.
To reproduce: you simply press RUN/STOP after the fast format process completes, load the directory and type LIST.
I've also added a comment to the release saying that your patched version of DASM is required to assemble/make the various binaries. |
| |
TCE
Registered: Sep 2011
Posts: 29 |
Re bumping: It appears that not only the adc #4 is not required, but you might even want to to sbc #1 from DRVTRK ($22) as not doing so would attempt to bring the head on track 0, thus resulting in a single, unnecessary, "rattle".
This is the code I am successfully testing with, trying to format DOS disks:
lda $22 ;DRVTRK
bne fj_skp2
lda #45
fj_skp2:
sec
sbc #1
asl ;A=A*2
tay
If you try the above code, please do a good deal of regression testing as well. |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
Interesting suggestions. When avoiding the bump, just be extra sure to make the stepper bits the right state when at the first track.
I personally think those few bumps are an acceptable compromise making for a safer alignment.
As for the dir/bam problem you are seeing, in format III I am currently using this before exiting: lda #1
sta $1cThe idea being to flag the disk as changed, forcing a reload of the BAM on the next operation. |
| |
TCE
Registered: Sep 2011
Posts: 29 |
Re: "just be extra sure to make the stepper bits the right state when at the first track."
I shall be testing all the time with this one.
Re: "forcing a reload of the BAM on the next operation."
OK, I back-ported the change, and I am testing the code as per below:
fj_ex1:
lda #18
jsr seek_track
lda #$01 ; format ok!
fj_ex2: sta $1c ; flag the disk as changed
rts ; jmp $fddb
When leaving through fj_ex2, i.e. read error, A is 0x06, which I guess is still a suitable value for $1c?
When can we expect to see "Format III" published then, roughly? I can do some testing on RH if you need a hand with that. |
... 2 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
