2H, a homemade 208k 3" disc format tool

[cngsoft]

Back in the day there were several attempts at expanding the default format of the typical 3" floppy,  40 tracks × 9 sectors × 512 bytes. Besides commercial protections (such as Dinamic's tracks of 5 sectors of 1 kB each, or the Speedlock format where each track held a single 6 kB sector) there were pokes that forced AMSDOS to use 42 tracks and even resident tools that relied on custom formats of 10 sectors per track.

In recent years, as I used my real CPCs less and less, and was often using just one floppy where I'd save things sent from the PC through the parallel port (you may remember Marco Vieth's CPCEMU: among other things it included the layouts of a PC-CPC cable and file transfer tools to be used on both sides), test them on the real machine, then erase them, save new things... the 178k DATA format became a bigger annoyance.

That's how I decided to write my own resident tool that also contained its own disc formatter, and so I got 2H.BAS, that gave me up to 208 kB of useable space by using the same sectors for the "normal" catalogue and the "expanded" one, at the expense of requiring the resident tool to be the very first file on the disc to ensure that it would be correctly read both from the normal DOS and the expanded mode.

So, why not sharing it? The source code is exactly 2048 bytes long and the resulting file is 384 bytes long, 256 plus the AMSDOS header.

Code Select Expand

cpct = 0
init = $170
exec = 0

; HEADER
org init-$80
ds $12
db cpct
ds $02
dw init
ds $01
dw last-init
dw exec
ds $24
dw last-init
ds $01
dw cpct+(hi init)+(lo init)+(hi exec)+(lo exec)+2*((hi (last-init))+(lo (last-init)))
ds $3B
; BASIC
dw boot-$-2,1,$1C83,boot,$C001
filename db "2H"
filename_ db ": run to toggle 208K mode, push Shift and Control to format disc."
ds 3

boot ld a,($BC9B)
cp $DF
ret nz ; DISC INSTEAD OF TAPE?
ld hl,($BC9B+1)
inc hl
inc hl
ld a,(hl) ; AMSDOS' ROM NUMBER
ld (select03+2),a
ld (format06+2),a
ld hl,($BE7D)
ld a,h
or l
ret z ; AMSDOS COMPATIBLE ROM?
ld e,(hl) ; CURRENT DISC DRIVE
push de
ld a,$C1 ; DEFAULT DATA FORMAT
db $DF;RST3
dw select03
ld hl,5 ; A=0,BC=0,DE=XDPB+$13
add hl,de
pop de
; xor a
cp (hl)
jr z,main
ld (hl),a ; SET DYNAMIC FORMAT
quit ld de,last
jp $BC9B ; CAT
main dec (hl) ; SET 208K FORMAT
push hl
pop ix
ld (ix-24),40  ; RECORDS/TRACK: 36
ld (ix-19),209 ; ++KBYTES/SIDE: 179
; ld (ix-11),b;0 ; CATALOG TRACK: 0
; ld (ix-9),$C1  ; 1ST SECTOR ID: $C1
ld (ix-8),10   ; SECTORS/TRACK: 9
ld (ix-7),7    ; GAP#3, RD/WRT: 42
ld (ix-6),22   ; GAP#3, FORMAT: 82
ld a,21 ; PRESS SHIFT...
call $BB1E
ld a,c
cp 160 ; ...AND CONTROL!
jr nz,quit

ld a,"["
call $BB5A
ld d,0
doatrack ld hl,last
push hl
ld c,2;bc
ld a,$C1
dosector ; CHRNCHRN...
ld (hl),d
inc hl
ld (hl),b
inc hl
ld (hl),a
inc hl
ld (hl),c
inc hl
add 5 ; C1C6...
ld (hl),d
inc hl
ld (hl),b
inc hl
ld (hl),a
inc hl
ld (hl),c
inc hl
sub 4 ; C6C2...
cp $C6
jr nz,dosector ; 16,27,38,49,5A,*6B*
pop hl
db $DF;RST3
dw format06
ret nc
ld a,"#"
call $BB5A
inc d
ld a,d
cp 42
jr c,doatrack
ld hl,filename
ld de,last
ld b,filename_-filename
call $BC8C
ld hl,init
ld de,last-init
xor a
call $BC98
call $BC8F
ld a,"]"
call c,$BB5A ; OK!
filedone jp $BC92

select03 dw $C039
db 7
format06 dw $C042
db 7

align $270
last
end


It was written for the AS80 compiler, but it should be easy to adapt to other compilers.

2H.BAS relies on AMSDOS' ability to switch the format detection routines on and off. When run on a freshly booted CPC, 2H.BAS disables those routines and forces its own 208k format on the DOS, allowing access to all that space but forbidding the usage of other types of discs; when run again, it enables back those routines, so the 208k format is no longer supported, but normal discs can be used again.

When 2H.BAS is run with SHIFT and CONTROL down (these keys don't interfere with RETURN; I chose both to avoid accidental keypresses) it formats the disc inside the current drive with its custom method and saves a copy of itself. A progress bar is shown as the process goes on, so users can see what's happening and know whether everything's alright.

Notice that these 208k floppies show seemingly normal CATalogues but all the files inside them (besides 2H.BAS itself, always on the first track, right after the catalogue) won't be immediately useable because they're stored on a 10-sector layout but the default DATA format assumes 9 sectors: loading and saving will result in gibberish and corruption.

That being said, I'm still wary of certain things, such as assuming that everyone has AMSDOS, or using 7 and 22 for the GAP#3 constants, where the DATA format would use 42 and 82; someone more FDC-savvy might spot further weaknesses in the listing and suggest corrections. What do you think?

[TFM]

... it formats the disc inside the current drive with its custom method and saves a copy of itself...

Great! The first virus on disc for the CPC 

[cngsoft]

Great! The first virus on disc for the CPC 

Well, that's a way to look at it. But since it's not really infecting any files, I'd rather call it a Trojan horse...

Now seriously, a thing that bugs me deeply is that real floppies formatted with 2H.BAS often develop "Read Fail" errors on track 0 (in most cases, whenever they have to read the directory for a CATalogue or because they're trying to open or create a file) so I'm fearing that the GAP#3 values I chose aren't reliable. Back in the day I chose them after some trial and error, but it looks like I didn't try hard enough  What do we know about the GAP lengths? How shall we calculate safe values for them?

[cngsoft]

Speaking of the GAP#3 values, I just remembered a little thing.

Back in the day, when the famous Discology hadn't been pirated by everyone yet, my favourite disc copier was Turbo Copy III v1.4 (1986) by David Nardi & Marc Maulin, who later made Discology itself. TCOPY3 anticipated features that Discology made famous, but still was smaller and simpler: for example, it didn't use the extra memory on 128k machines as a temporary buffer.

When I wanted my tool LPTCPC to send (or receive) whole disc images thru the parallel cable, I needed to do research on the GAP#3 parameters required by the raw FDC commands: to be able to read 6k/8k tracks (yes, it can dump Hexagon and 1990 Speedlock discs!) I couldn't rely on the DOS calls. Discology was too complex for me to disassemble, so I chose TCOPY3 instead:

* When it's going to format a track, TCOPY3 calculates the GAP parameter as  (6100-(sector_size+62)*sectors_per_track)/sectors_per_track+1; too high values would be capped to 82, too low ones to 1 (fun fact - despite this sanity test, they actually forgot to handle negative numbers!). Thus the typical 9*512 track would be calculated a GAP of (6100-(512+62)*9)/9+1 = 104 and then capped to 82; similarly, a 10*512 track (like those used by 2H.BAS) would be assigned a GAP of 37. Interestingly, the 6100 constant would be lowered to 2800 if certain floppy disc drives were detected.
* When it's reading and writing sectors, TCOPY3 simply sets the GAP parameter as 1.

Any thoughts on the logic and validity of these mathematics?

[TFM]

Hi!


The problem is when writing sectors using (f.e.) AMSDOS, it will use a number of bytes of the GAP. Now when the GAP in the format is small, a number close to that, then the sector id of the next sector get's overwritten when writing data to disc.


Solution: Reduce the bytes written in GAP#3 when writing a sector.

[cngsoft]

Well, in that case let's accept the TCOPY3 values as safe. Here's the new source with the updated values and a couple of optimisations:

Code Select Expand

cpct = 0
init = $170
exec = 0

; AMSDOS
org init-$80
ds 18
dw cpct
ds 1
dw init
ds 1
dw last-init,exec
ds 36
dw last-init
ds 1
dw cpct+(hi init)+(lo init)+(hi exec)+(lo exec)+2*((hi (last-init))+(lo (last-init)))
ds 59
; BASIC
dw boot-$-2,1,$1C83,boot,$C001
filename db "2H"
filename_ db ": run to toggle 208K mode, push Shift and Control to format disc."
ds 3

boot ld a,($BC9B)
cp $DF
ret nz ; DISC INSTEAD OF TAPE?
ld hl,($BC9B+1)
inc hl
inc hl
ld a,(hl) ; AMSDOS' ROM NUMBER
ld (select03+2),a
ld (format06+2),a
ld hl,($BE7D)
ld a,h
or l
ret z ; AMSDOS COMPATIBLE ROM?

ld e,(hl) ; CURRENT DISC DRIVE
push de
ld a,$C1 ; DEFAULT DATA FORMAT
db $DF
dw select03
ld hl,5 ; A=0,BC=0,DE=^XDPB+19
add hl,de
pop de
cp (hl)
jr z,main
ld (hl),a ; SET DYNAMIC FORMAT
quit ld de,last
jp $BC9B ; CAT
main dec (hl) ; SET 208K FORMAT
push hl
pop ix
ld (ix-24),40  ; RECORDS/TRACK (36)
ld (ix-19),209 ; ++KBYTES/SIDE (179)
; ld (ix-11),b;0 ; CATALOG TRACK
; ld (ix-9),$C1  ; 1ST SECTOR ID
inc (ix-8);,10 ; SECTORS/TRACK (9)
; 20130830: GAP#3 7/22 FAIL!!!
ld (ix-7),1    ; GAP#3 RD/WRT (42)
ld (ix-6),37   ; GAP#3 FORMAT (82)
ld a,21 ; PRESS SHIFT...
call $BB1E
ld a,c
sub 160 ; ...AND CONTROL!
jr nz,quit

ld d,a
ld a,"["
call $BB5A
doatrack ld hl,last
push hl
ld c,2
ld a,$C1
dosector ; CHRNCHRN...
ld (hl),d
inc hl
ld (hl),b
inc hl
ld (hl),a
inc hl
ld (hl),c
inc hl
add 5 ; C1C6...
ld (hl),d
inc hl
ld (hl),b
inc hl
ld (hl),a
inc hl
ld (hl),c
inc hl
sub 4 ; C6C2...
cp $C6
jr nz,dosector ; 16,27,38,49,5A*6B
pop hl
db $DF
dw format06
ret nc
ld a,"#"
bit 0,d
call nz,$BB5A
inc d
ld a,d
cp 42
jr c,doatrack
ld hl,filename
ld de,last
ld b,filename_-filename
call $BC8C
ld hl,init
ld de,last-init
xor a
call $BC98
call $BC8F
ld a,"]"
call c,$BB5A; OK
filedone jp $BC92
select03 dw $C039
db 7
format06 dw $C042
db 7

ds $270-$
last
end
Tested on a real CPC, where it worked like a charm on a 3" floppy. The source still fits in 2048 bytes!

[Gryzor]

Resurrecting this interesting thread Is there a compiled file anywhere?

[Velktron]

It was possible, alright, but repeated use of such "super disks" also sent the drive head out of alignment, especially if more than 41 tracks were used 

[Gryzor]

Ah - oooops!!!


Didn't Discology also go up to 42?

[Bryce]

It was possible, alright, but repeated use of such "super disks" also sent the drive head out of alignment, especially if more than 41 tracks were used 

What exactly caused the heads to go out of alignment? Reading/writing 42 tracks doesn't require the drive to do anything it wasn't designed to do.

Bryce.

[||C|-|E||]

If something like this was possible in a reliable way, maybe I would be able to fit our adventure game in a 3"  . Well, I am actually thinking that 200 kas is still way too little for that, but it would be great to be able to expand the capacity of the old discs

[CraigsBar]

What exactly caused the heads to go out of alignment? Reading/writing 42 tracks doesn't require the drive to do anything it wasn't designed to do.

Bryce.

I used Parados 41 format. (203k - 10 sectors per track) on several 3 Inch disks over many years with no I'll effects.

[Velktron]

If something like this was possible in a reliable way, maybe I would be able to fit our adventure game in a 3"  . Well, I am actually thinking that 200 kas is still way too little for that, but it would be great to be able to expand the capacity of the old discs

I thought I read the explanation somewhere -in the wiki?- that using any number of tracks beyond the standard 40 caused the head block to smash against a part of the drive's structure, and doing so repeatedly eventually sent the head out of whack. I remember Amstrad CPC users posting complaints in the venerable PIXEL magazine of how they felt cheated by using 42-43 track disks while slowly killing their drives without realizing it.... 

BTW, that didn't happen with all makes of 3" drives: some were more prone than others. In any case, the issue was related to the number of tracks. Increasing the number of sectors per track should be safer -at least from this perspective- but apparently less popular than the "quick and dirty" way of formatting 41, 42 or 43 tracks to get some extra KBs capacity.

[Gryzor]

I have the same memory as @Velktron , so it my well have been something in PIXEL...

[arnoldemu]

With code it's possible to try and make the drive seek past track 42.
It is certainly audible and it may be the head hitting the plastic of the disc sleeve.
I've not let it do it long enough to confirm if it puts the head out of alignment.

[||C|-|E||]

Something similar happened with the Dreamcast when copying in a single CD games that came in two discs. I even remember using some software to prevent the problem 

[Gryzor]

Hm, but DC used the GD-ROMs and pirated copies actually left out or compressed stuff to fit on 80-min CDs...

[Bryce]

With code it's possible to try and make the drive seek past track 42.
It is certainly audible and it may be the head hitting the plastic of the disc sleeve.
I've not let it do it long enough to confirm if it puts the head out of alignment.

Send me the code and I'll run it on an opened drive to see what it's hitting.

Bryce.

[arnoldemu]

Send me the code and I'll run it on an opened drive to see what it's hitting.

Bryce.

[arnoldemu]

The code uses drive A. It needs a disc in the drive.
It will seek to track 0 first to give the FDC a reference point, then seek out to track 90.
So plenty of time to see the head hammering itself.

When I heard it on my CPC many years ago, it sounded like it was stepping back and forth.

I heard it because I wrote some bad fdc code!!! LOL.

I am happy for Bryce to run it because if it does break the drive then he can repair it.
Others be really careful.



Can I post the code to burn out the tape relay next? 

[CraigsBar]

Does zap't'balls not try that when you hit the multiface stop button.

Oh and hero quest which produces tape relay drums. That was quite a shock after u ran it first time after tape modding my 6128+

[Bryce]

Full marks for the name of the file.

Bryce.

[arnoldemu]

@Bryce: Any news on the results?

[Gryzor]

@Bryce any news on the results? 😀

[TotO]

Is it possible to format a floppy disc by using 6 sectors size-3 per track? (6144 bytes)