[LoneCrusader]

rloew, on 24 February 2010 - 02:35 PM, said:

The Patches can easily be combined so they can be done in a single sequence.
Add the PATCHMEM.EXE file from my RAM Limitation Patch package to the FIX95CPU Floppy, and run the RAM Patch after the FIX95CPU script completes.

Yes, it can easily be added to the floppy and even the script, provided one already has a copy of PATCHMEM. I was mainly addressing the distribution issue.

This post has been edited by LoneCrusader: 24 February 2010 - 02:46 PM

[dawong]

LoneCrusader, on 24 February 2010 - 10:44 AM, said:

DUN14-95.EXE is too large to fit on a floppy disk, so there is no way to have it on the same "Disk" as the batch file. One solution to this might be to use an ISO editing program and add DUN14-95 to the bootable FIX95CPU.ISO...

I made a combination boot disc that has the original MS .exe's in the non-bootable area, and combines the two patches on one disc. This disc is all you need for VPC 7 and may be useful for some regular installs. Use it as normal for a boot disc, and type PATCHA for the 95ALL version of the batch file and PATCHBC for the 95B&C version. DUN14-95 is automatically placed in a folder on the C drive when one of the patch programs is executed. Users with virtual programs other than VPC 7 can install Win 95 normally by turning off hardware virtualization, and then the patches can both be installed from within Windows.

Files (note different web address than previously, sorry):
Instructions
Boot Disk (self extracting archive)

I could only test patches for 95 OSR 2, because I don't have 95A, and the microsoft update patches for OSR 2 to 2.1 and 2.1 to 2.5 are no longer on the update site.

Also, I could not reproduce the 2.1 Ghz IOS error, perhaps because I never had the network running until after I had the DUN14-95 patch installed. Which program do you have to run to get this second problem?

Quote

While I agree it would be convenient to have the CPU and RAM fixes combined, RLoew's RAM patch is not free, so it cannot be distributed in such a manner. It is the only method of installing more than 512 MB of RAM on a 9X system that I personally recommend however. I have been using it for over a year on my 98SE system with 1.5 GB of RAM. If you decide to purchase a copy, it is worth every penny.

It works great with VPC also. FWIW, all four virtualization programs I tried would boot with <=946MB but not >=947MB of RAM, but could get to >3GB (limited by the programs, not the RAM patch) with patch installed.

[LoneCrusader]

dawong, on 01 March 2010 - 06:08 AM, said:

Files (note different web address than previously, sorry):
Instructions
Boot Disk (self extracting archive)

I could only test patches for 95 OSR 2, because I don't have 95A, and the microsoft update patches for OSR 2 to 2.1 and 2.1 to 2.5 are no longer on the update site.

Also, I could not reproduce the 2.1 Ghz IOS error, perhaps because I never had the network running until after I had the DUN14-95 patch installed. Which program do you have to run to get this second problem?

Could you post the Instructions in a .TXT file?

I did not have 95 or 95A to test either, however rloew confirmed that the new method for the B & C patch does not work on the older systems because WININIT cannot be called manually. I kept v1.1 in the package for anyone who might want to experiment with it on the older 95 versions, or who may have not got the 1.2 disk inserted before the IOS error is displayed (WININIT is called before/during this).

There is no 2.1GHz "IOS" error, it is the "NDIS" error. To reproduce it, all you need to do is try to install 95 on a >2.1GHz system using only the AMDK6UPD.EXE files, and leave out the NDIS.VXD from DUN14-95.EXE.

[dawong]

LoneCrusader, on 01 March 2010 - 09:50 AM, said:

Could you post the Instructions in a .TXT file?

OK, it is at www.virtualuser.net/files/win95/Win95VPC7.txt

If the width or format is wrong, let me know.

[rloew]

LoneCrusader, on 24 February 2010 - 10:44 AM, said:

DUN14-95.EXE is too large to fit on a floppy disk, so there is no way to have it on the same "Disk" as the batch file.

It is possible to create a Bootable Floppy Image on a CD/DVD of up to 36MB. The required geometry is 1024 Cylinders 2 Heads 36 Sectors.
I use my own CD/DVD burner. I do not know if any other CD writer will support this.

[LoneCrusader]

rloew, on 01 March 2010 - 11:43 PM, said:

LoneCrusader, on 24 February 2010 - 10:44 AM, said:

DUN14-95.EXE is too large to fit on a floppy disk, so there is no way to have it on the same "Disk" as the batch file.

It is possible to create a Bootable Floppy Image on a CD/DVD of up to 36MB. The required geometry is 1024 Cylinders 2 Heads 36 Sectors.
I use my own CD/DVD burner. I do not know if any other CD writer will support this.

FIX95CPU and DUN14-95 could both fit on a 2.88MB floppy, so as long as one was using strictly floppy or cd images for their setup, it would not be a problem. However, it would be a problem for anyone who actually needed to write FIX95CPU to a floppy disk.

[Usher]

rloew, on 01 March 2010 - 11:43 PM, said:

It is possible to create a Bootable Floppy Image on a CD/DVD of up to 36MB.

I wonder how did you format FAT12 disk to 36 MB size instead of well known 32 MB limit.

rloew, on 01 March 2010 - 11:43 PM, said:

I use my own CD/DVD burner. I do not know if any other CD writer will support this.

Any other CD burner supports 32 MB boot disk image.

This post has been edited by Usher: 02 March 2010 - 01:59 PM

[rloew]

Usher, on 02 March 2010 - 01:59 PM, said:

rloew, on 01 March 2010 - 11:43 PM, said:

It is possible to create a Bootable Floppy Image on a CD/DVD of up to 36MB.

I wonder how did you format FAT12 disk to 36 MB size instead of well known 32 MB limit.

Early implementations of DOS may have had a 32MB limit, namely the 16 bit sector count.
With the newer 32-Bit Sector Count, FAT12 can easily handle 128GB. DOS 7 and Windows 9x have no problem with it.
My modded IO.SYS raises the FAT12 limit to 512MB, 16GB with larger Sectors.

The limiting factor is the CD Boot Floppy emulation.

This post has been edited by rloew: 02 March 2010 - 11:45 PM

[dencorso]

rloew, on 02 March 2010 - 11:43 PM, said:

Early implementations of DOS may have had a 32MB limit, namely the 16 bit sector count.
With the newer 32-Bit Sector Count, FAT12 can easily handle 128GB. DOS 7 and Windows 9x have no problem with it.

Wonderful, RLoew!
Let me get technical...
You mean: set the word at offset 0x13 in the BPB to 0x0000 and use the dword at offset 0x20 to hold the sector count? Simple as that? Wow!
I always suspected this should be possible, but never actually tried it...
And you say DOS 7.0, 7.1 and 8.0 support it natively. Great! Did you test it with DOS 6.xx? It may also support it.
Besides images, it can mean an oldish 128 MB pendrive or a Zip100 formatted to true FAT-12!!! And 128 MB would use 96 sectors per FAT, right?

[rloew]

dencorso, on 03 March 2010 - 12:20 AM, said:

rloew, on 02 March 2010 - 11:43 PM, said:

Early implementations of DOS may have had a 32MB limit, namely the 16 bit sector count.
With the newer 32-Bit Sector Count, FAT12 can easily handle 128GB. DOS 7 and Windows 9x have no problem with it.

Wonderful, RLoew!
Let me get technical...
You mean: set the word at offset 0x13 in the BPB to 0x0000 and use the dword at offset 0x20 to hold the sector count? Simple as that? Wow!
I always suspected this should be possible, but never actually tried it...
And you say DOS 7.0, 7.1 and 8.0 support it natively. Great! Did you test it with DOS 6.xx? It may also support it.
Besides images, it can mean an oldish 128 MB pendrive or a Zip100 formatted to true FAT-12!!! And 128 MB would use 96 sectors per FAT, right?

Haven't tried DOS 6.xx but I am pretty sure it would.

FAT12 is limited to 4086 Clusters so it never uses more than 12 Sectors per FAT. Any more Clusters would be recognized as FAT16.
128MB FAT12 Partitions need to use 32K Clusters.

[Mijzelf]

rloew, on 03 March 2010 - 01:16 AM, said:

FAT12 is limited to 4086 Clusters so it never uses more than 12 Sectors per FAT. Any more Clusters would be recognized as FAT16.
128MB FAT12 Partitions need to use 32K Clusters.

rloew said:

My modded IO.SYS raises the FAT12 limit to 512MB, 16GB with larger Sectors.

So this gives 4MB clusters? 

This post has been edited by Mijzelf: 03 March 2010 - 08:16 AM

[rloew]

Mijzelf, on 03 March 2010 - 08:15 AM, said:

rloew, on 03 March 2010 - 01:16 AM, said:

FAT12 is limited to 4086 Clusters so it never uses more than 12 Sectors per FAT. Any more Clusters would be recognized as FAT16.
128MB FAT12 Partitions need to use 32K Clusters.

rloew said:

My modded IO.SYS raises the FAT12 limit to 512MB, 16GB with larger Sectors.

So this gives 4MB clusters? 

Yes.
256 Sectors per Cluster. 16K Bytes per Sector. This works only for DOS. I have not made a Large Sector Patch for Windows, just the 256 Sector Patch.
So the current limit for modded Windows 9X is 512MB for FAT12.

[dencorso]

rloew, on 03 March 2010 - 01:16 AM, said:

dencorso, on 03 March 2010 - 12:20 AM, said:

And 128 MB would use 96 sectors per FAT, right?

FAT12 is limited to 4086 Clusters so it never uses more than 12 Sectors per FAT.
Any more Clusters would be recognized as FAT16.
128MB FAT12 Partitions need to use 32K Clusters.

Of course! I must learn to curb my enthusiasm long enough to think things over more, before I post.

128MiB uses 12 sectors per FAT12 and a Zip100 (which has 100,663,296 bytes = 96 MiB) uses 9 sectors per FAT12.
Here is how to calculate it: 96 MiB = 196,608 sectors (of 512 bytes) = 3,072 clusters (of 32 kiB or 64 sectors). Now, since each entry in a FAT12 is 1.5 bytes long, we have 3,072 x 1.5 = 4,608 bytes; dividing that by 512 bytes (= 1 sector) we get 9 sectors per FAT12.

I have just succedded in creating a FAT12 SuperFloppy out of a Zip100, and it works!

BTW, the FAT article in the Wikipedia (link) gives 4078 clusters as the maximum for FAT12, and their reasoning seems correct to me.

[rloew]

dencorso, on 03 March 2010 - 10:40 PM, said:

BTW, the FAT article in the Wikipedia (link) gives 4078 clusters as the maximum for FAT12, and their reasoning seems correct to me.

4078 is based on the standards.

DOS and Windows computes the number of available Clusters then tests it against a threshold. If below, assume FAT12. If above, assume FAT16.
To complicate things further, DOS and Windows do not even use the same threshold. DOS uses 4086 and Windows uses 4085. A partition could be interpreted as FAT12 by DOS and FAT16 by Windows.

FAT16/FAT32 discrimination is even worse. DOS uses 65526 as a threeshold, Windows tests the 16-Bit # of Sectors per FAT field.

[jaclaz]

I am surely missing a point , but what is the practical need/advantage of having a FAT12 "super-floppy" instead of a FAT16 one?

jaclaz

[rloew]

jaclaz, on 04 March 2010 - 04:48 AM, said:

I am surely missing a point , but what is the practical need/advantage of having a FAT12 "super-floppy" instead of a FAT16 one?

jaclaz

I have seen some problems with SCANDISK when using FAT16 on A:.

[dencorso]

jaclaz, on 04 March 2010 - 04:48 AM, said:

I am surely missing a point , but what is the practical need/advantage of having a FAT12 "super-floppy" instead of a FAT16 one?

There is no actual need for a superfloppy Zip100, that I know of. I used it as a model, to learn how to do it, since there are older cameras and other devices that use FAT12 only SD cards. However, since I don't have any 128 MB SD card, I thought the Zip100 is a good enough model. Nowadays, 128 MB SD cards are not easy to find new, so it may be a long time before I can get one, even if used, and I wanted to test it right away.

[LoneCrusader]

I had originally thought that somehow I was the first person to discover how to fix this problem in Windows 95, because I remember searching for a solution a few years back (Old post at Annoyances.org) and was unable to find one.

However, recently I discovered this thread Windows 95 unofficial patches by Petr wherein he obviously had identified the problem, along with a solution. I am amazed at some of the hostility given to his solution and some obvious misinformation in that thread.

[submix8c]

LoneCrusader, on 14 March 2010 - 01:22 PM, said:

I am amazed at some of the hostility given to his solution and some obvious misinformation in that thread.

Misinformation - perhaps due to confusion. Hostility - personal perception only. The solution/patch was for RTM and requested further investigation into the later OEM versions.

Forgot to mention - all in that thread (but one) have been around a long time, are extremely knowledgeable, and have high respect for one another.

This post has been edited by submix8c: 14 March 2010 - 02:50 PM

[LoneCrusader]

submix8c, on 14 March 2010 - 02:28 PM, said:

Misinformation - perhaps due to confusion. Hostility - personal perception only.

I do not think that I would be the only one to perceive certain responses in that thread as hostile. And the idea that "NDIS.VXD 4.00.1113 does not fix any version of 95" is blatantly incorrect, as my experiments and the results of others can now confirm.