• Please review our updated Terms and Rules here

Floppy Formats for MS-DOS 6.22

Shadow Lord said:
Actually even MS does not recommend NTFS compression. The performance hit is huge because of the way the compression works. For example even moving a file on the same compressed volume gets hit by a penalty because the data is read, uncompressed, re-compressed and then written as opposed to just moving the compressed data on the volume.
Click to expand...

Microsoft does suggest that NTFS compression can be considered with servers that mainly do reads. Long article that covers when not to do it http://support.microsoft.com/kb/251186

For DOS based compression, I would recommend against using it. This is old hardware. If the vintage computer fails, I like having the option to easily transfering data off a hard disk. Since nothing after Win9x/Me can reliably read the compressed disk, you can't just install a compressed disk in an enclosure and read with a recent OS.

A number of games either were compressed executables or did tricky disk access methods. Those titles won't benefit from compressed disks or just won't work on a compressed disk. Save the challenges for playing the game; eschew disk compression.
 
Last edited:
krebizfan said:
Microsoft does suggest that NTFS compression can be considered with servers that mainly do reads. Long article that covers when not to do it http://support.microsoft.com/kb/251186

For DOS based compression, I would recommend against using it. This is old hardware. If the vintage computer fails, I like having the option to easily transfering data off a hard disk. Since nothing after Win9x/Me can reliably read the compressed disk, you can't just install a compressed disk in an enclosure and read with a recent OS.

A number of games either were compressed executables or did tricky disk access methods. Those titles won't benefit from compressed disks or just won't work on a compressed disk. Save the challenges for playing the game; eschew disk compression.
Click to expand...

Ahhmm... That is the same KB I already linked to in my OP. And that KB is hardly ringing endorsement for NTFS compression even with long reads.

What critical data do you have on a 30 year old machine that you need recovery if the HW dies? For me I loose my KQ saved games thats it...
 
Shadow Lord said:
What critical data do you have on a 30 year old machine that you need recovery if the HW dies? For me I loose my KQ saved games thats it...
Click to expand...

That's a good point. When all is said and done, it could actually be that drive compression on this generation of machine has finally come into its own. That's a hoot. :)
 
yes dos 6.22 came on 360k disks.
But an xt ( not an at) will see a 720k floppy
or a 1.44 drive with disks formatted as 720k
 
win 3.1 will install with all files in a directory preferabley NOT CALLED C:\WINDOWS.
but win 3.1 is impossibly slow on a 286/12 word 1.0 takes half an hout to do anything.
 
Shadow Lord said:
Now as for Stacker I plan to use it because I have a 20MB HDD in my 286XT and more importantly I have the co-processor board and I had always wanted to try that out. But stacker is DOS ver independent (for the purposes of this discussion) so 6.2 vs 6.21 vs. 6.22 is meaningless.
Click to expand...

If you have the coprocessor board, definitely give it a shot -- it's fun to play with. Run some tests with the board in, then take the board out and run the same tests (the software driver will run in both states). I personally found the following to be true:

- Read speeds were surprisingly good even without the board
- The board actually made reads and writes faster due to less data going off/onto the drive

The coprocessor could compress at 3MB/s and decompress at 6MB/s so on a really slow machine it's essentially transparent. (On a really fast machine, like a Pentium or higher, it *slows things down* :)

I wrote about the Stacker boards a long time ago; I believe the info is still here: http://www.oldskool.org/shrines/carny

The only drawback to using the coprocessor board is that only only Stacker 1.0 and 2.0 explicitly support it. Stacker 3.0 will use it, but the board isn't mentioned anywhere in the software or documentation so the only way you know it's working is doing a benchmark. Stacker 4.0 doesn't use it at all, which is a shame because 4.0 is the most mature version of the product that was more fault-tolerant and had better compression than 3.0 and earlier.
 
Trixter said:
The only drawback to using the coprocessor board is that only only Stacker 1.0 and 2.0 explicitly support it. Stacker 3.0 will use it, but the board isn't mentioned anywhere in the software or documentation so the only way you know it's working is doing a benchmark. Stacker 4.0 doesn't use it at all, which is a shame because 4.0 is the most mature version of the product that was more fault-tolerant and had better compression than 3.0 and earlier.
Click to expand...

Are you sure about this? I am almost positive I have 4.0 installed on my machine and it complains when I remove the board from the machine (it still runs, just complains), I could be wrong and it could be a lower version but I have 4.0 on disks so it is the most likely version I installed. I'll check later tonight and post back.

In any case don't forget the memory savings: with the board the stacker driver takes ~ 20k less memory.
 
My basis on the driver using the board or not is based on the Stacker 4.0 version that comes with PC DOS 2000. If there was an official 4.0 driver that used the board, I'd love to grab a copy! (I own both coprocessor boards).
 
Trixter said:
My basis on the driver using the board or not is based on the Stacker 4.0 version that comes with PC DOS 2000. If there was an official 4.0 driver that used the board, I'd love to grab a copy! (I own both coprocessor boards).
Click to expand...

Yes, there was an official 4.0 stacker release. I believe that was the final release. Let me check what version I am running and verify it is working with the processor board.
 
someone sent me a combination cd.
with dos 5,22 mouse and windows 3.11 in seaparate directories
I took a bootable dos 6.22 floppy with cd support
changed to the dos directory
and typed SETUP, It told me there was an error in dossetup.ini
( it does not exist on the cd)
I copied all the files in e:\dos to c:\ dos.
than I copied the files it asked for on the floppy config.sys and autoexec.bat from the directory
and edit the file to look at c:\ or c:\dos.
path was set to c:\dos.
then I ran memmaker so I had a correct ? config and autoexed.bat
I then ran setup from e:\mpouse
and setup from c: windows both worked well
I did some looking concerning dossetup.ini.
as it does not exist on the cd.
I recall dos 6.22 requires the disk labels to be exact if not the installation stops
I see similar things with this setup.
and several people trying to make a 1) bootable cd and 2) make dos install from a cd directory. I think there is likely a edited
copy of DOSETUP.ini I amanged to get it done but it was not as easy as I had first thought.

I just went thru a similar thing, but with win98se.
I have bootable cd's that need a key, including several of the original " pretty ones" and others that do not boot buy have a handy patch. I need to figure out how to make a bootable cd that HAS that small patch. I really thought I had one
I installed win 98 at leat 10 tikmes to try it out
One cd drive rejected all bootable disls including Hiren ranish and others.
I changed the HP optical drive for a smamsung and suddenly non bootimng cd's were booting. so it your cd's are bot bootable it may not be you , It may be the cd drive.
 
yping DOS 6.33 not 5.22
I tried the cd I will start another thread as this one is in another direction
 
You must log in or register to reply here.
Back
Top