| |
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" |
|
... 2 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
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: 1787 |
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: 1787 |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: 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.
There's some code in the DOS that uses an lsr $1c for test and clr so it needs to be $01.
I'm kind of busy with other stuff at the moment so format III will have to wait a bit. I might take up your offer for testing though. ;) |
| |
TCE
Registered: Sep 2011
Posts: 29 |
Might be handy to have visibility on something I am testing at the moment, so I will post it here. No action required.
Because I am using the Format II code through my IECHost device, the drive code is stored entirely in ROM and cannot be patched before being sent to the drive. I'd have to copy configurable sections to RAM first, patch and send that instead, but I'd rather proceed as per below.
I created a C64 demonstrator that sends the drive code to the 1541 unchanged, by means of a one-bit bootloader, running in the drive's RAM, within page #1. However, the bootloader does not execute the main drive code: In fact, I patch the drive's RAM starting at $06fc with a "M-W" loop, setting the number of tracks, etc. Finally, I execute the main drive code with a "M-E" (at $0300). |
| Previous - 1 | 2 - Next |
