F-Prot FP-DEF.ZIP now too big for 1.44M

On Thu, 12 Feb 2004 12:10:39 +0100, Frederic Bonroy
>cquirke (MVP Win9x) wrote:

>> F-Pror FP-DEF.ZIP now too big for 1.44M

>> I've been waiting for this to happen and wondering how F-Prot would
>> deal with it (e.g. split SIGN.DEF into FD-DEF.ZIP and SIGN2.DEF into
>> FP-DEF2.ZIP, which has been my strategy).

>Hmm... what's the problem? If you want to create boot disks, simply put
>sign.def and sign2.def each on their own floppy and the rest on a third
>floppy. On boot-up copy everything onto a ramdisk and you are done.

No, you don't understand

It's not a case of "duh, how do I run this thing", it's a matter of
how I update what I currently use to automate the updating of field
diskettes and so forth. I prefer to use the archives as-is rather
than pull out .def files are store them uncompressed, and usually I
use a three diskette set; boot/engine, gen data, macro data.

So now the set will be the same boot/engine, but the updater will
create gen/macro data and worm/macro data (duplicating macro data
because I can, really - I like the redundancy, typically using pairs
of sets in case bad disks arise in the field).

To do this, I need to update my FP.BAT to extract Sign2.def from the
new FP-DEF2.ZIP, which I've done, and the updater to unpack FD-DEF.ZIP
and create the new FP-DEF.ZIP and FP-DEF2.ZIP (done) before copying
those to the data diskettes (what I still need to do).

Another approach would be to use a standard EBD, a second diskette
with engine and Macro.def, and another two data diskettes for the
extracted Sign.def and Sign2.def respectively. I prefer 3 diskettes,
tho, as well as what I have in place to extract F-Prot to RAM disk and
run from there (so I can pull the diskettes are use on other PCs).

I guess it's only a problem if your SOP required FP-DEF.ZIP to be on a
single diskette, rather that working with the larger extracted files.



>---------- ----- ---- --- -- - - - -
Consumer Asks: "What are you?"
Market Research: ' What would you like us to be? '
>---------- ----- ---- --- -- - - - -
 >> Stay informed about: F-Prot FP-DEF.ZIP now too big for 1.44M 

On Fri, 13 Feb 2004 20:15:13 GMT, null.TakeThisOut@zilch.com wrote:
>On Fri, 13 Feb 2004 22:16:32 +0200, "cquirke (MVP Win9x)"

>>Either way, RAM disk is the way to go for speed!

>But don't forget to load smartdrv as well.

I didn't, but that is biting me when I use my current modified EBD on
olde PCs with 8M RAM - the "12M" RAMdrive leaves no room for SmartDrv,
when then fails to load. I may add a "Puny PC" option to the [Menu] !



>---------- ----- ---- --- -- - - - -
Consumer Asks: "What are you?"
Market Research: ' What would you like us to be? '
>---------- ----- ---- --- -- - - - -
 >> Stay informed about: F-Prot FP-DEF.ZIP now too big for 1.44M 

On Thu, 19 Feb 2004 06:51:27 GMT, jason.mangiafico RemoveThis @verizon.net (JM)
>>On Sun, 15 Feb 2004 04:01:23 GMT, jason.mangiafico RemoveThis @verizon.net (JM)

>>>>I find 1.44M flaky enough without going higher-density

>>>Going from 1.44MB to 1.72MB doesn't actually increase the data density on
>>>thedisk. It's reducing sector overhead, cluster overhead, and s bit of
>>>file system overhead. It's letting you use what would be wasted space.

>>I'm interested in how this works, as I found it verrrry difficult to
>>change sector size on diskette (in mid-'80s I had a need to read alien
>>1024-byte-sector diskettes on the PC; never found how, even in asm)

>fdformat.exe is a DOS utility the lets you do this.

I think that's what I used...

>Max values for DOS

>Sectors per track: 21
>Sectors per cluster: 16 (fat12 max)
>Tracks: 83 (physical limit for many disks)
>Root directory entries: minimun: 16

>Increasing sectors per track shrinks inter-sector gaps, less waste, more
>space available for storage. This is where the majority of the space
>comes from. 21 is limited by DOS, but many controllers can safely go 24.

Roocky Gush's ZX Spectrum diskette interface got 42-43 tracks a side
(or 84 tracks on 80-track pre-HDD) and 5 sectors a track. As the
sectors were 1024 bytes and each side managed separately (to support
single- ore dual-head drives), that's close to your 21 sectors. The
capacity was 412k for a "360k" disk and 814k or so for 80-track.

His interface left Track 0 (sectors 0-4) unused as a parking track.
Sector 5 was the "FAT", sector 6 the directory page. Later revisions
allowed multiple directory pages, as pointed to by system variables
MaxPage and CurrentPage in sector 5 (which held system variables as
well as the chaining information).

>Each track added to the disk will give you additional 20k or so. Many disks
>work safely up to 83 tracks. Many drives can go to 85 tracks.

>>Fiddling cluster size is unlikely to get you that sort of gain (even
>>if larger clusters shring FAT size), and I can't see any other free
>>lunch within the rest of the file system structure.
>>That's what I assumed it was a data density thing.

I'm surprised there's so much inter-sector wastage. Doesn't shrinking
this cause reliability issues? I guess the Gush scored well there by
virtue of 1k sectors, discarding half the gap problem without having
to reduce the gap itself.

>Data Density refers to how close the bits are packed together in the tracks,
>regardless of anything else. For example, a 720k disk has 80 tracks, and a
>1.44MB disk also has 80 tracks. Bits on a 720k disk are farther apart than
>on a 1.44MB disk.

Yes, and that AFAIK is hardwired; both linear and track spacing. The
800k diskettes we used with the Gush had the same linear density as
the "360k" disks - the controller Gush used predated 286-era High
Density - but had 80 rather than 40 tracks (pushable, but then he
throws away Track 0 so loses some of the gains)

>FDFORMAT.EXE increases space by shrinking inter-sector gaps.

OK.



>--------------- ---- --- -- - - - -
"We have captured lightning and used
it to teach sand how to think."
>--------------- ---- --- -- - - - -
 >> Stay informed about: F-Prot FP-DEF.ZIP now too big for 1.44M