Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user mjj ! (Registered 2018-02-17) You are not logged in 
CSDb User Forums


Forums > CSDb Entries > Release id #90210 : Format II
2018-01-22 22:35
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"
2018-01-23 08:23
tlr

Registered: Sep 2003
Posts: 1156
Doh! Well spotted. Better correct that for format III then. :)
2018-01-23 18:21
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.
2018-01-23 19:59
tlr

Registered: Sep 2003
Posts: 1156
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.
2018-01-23 20:33
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.
2018-01-27 20:06
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.
2018-01-27 20:54
tlr

Registered: Sep 2003
Posts: 1156
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...
2018-01-29 20:36
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.
2018-02-05 21:31
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.
2018-02-06 11:02
tlr

Registered: Sep 2003
Posts: 1156
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     $1c
The idea being to flag the disk as changed, forcing a reload of the BAM on the next operation.
2018-02-06 18:14
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Dr.Science/Atlantis
STE'86
G-Force
Groepaz
InuYaksa/Hokuto Force
Heavy Stylus/RGCD
nice/Nigaz
Steppe
Guests online: 66
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 The Shores of Reflec..  (9.6)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Pandemoniac Part 2 o..  (9.5)
2 Daah, Those Acid Pil..  (9.5)
3 Dawnfall V1.1  (9.5)
4 Synthesis  (9.5)
5 Treu Love [reu]  (9.5)
6 Merry Xmas 2017  (9.5)
7 FMX Music Demo  (9.4)
8 Dawnfall  (9.4)
9 Tribute to Bob Wakelin  (9.3)
10 Hardware Accelerated..  (9.3)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Finnish Gold  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.5)
2 Newscopy  (9.4)
3 Peter  (9.3)
4 A Life in Hell  (9.2)
5 Elwix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.249 sec.