rloew

OMG!!! It took quite some time to read this (and the corresponding links to further information), but it is certainly an eye-opener! One of the references however, http://support.microsoft.com/kb/923332/en-us , has been deleted by MS! Fortunately, the Portuguese version hasn't been deleted (yet), so I read that instead and posted the following feedback : "Firstly, WHY HAVE YOU DELETED THE ENGLISH VERSION OF THIS KB?! Secondly, how on Earth did you figure that a starting offset of 2048 sectors for the boot record would solve alignment problems (and hence performance issues), when this is not a multiple of 63, hence isn't the start of a track (cylinder & head combination) and thereby invite incompatibility with existing O/S and tools?! Since the new large sectors are a binary multiple of 512 bytes, the new offset should have been a binary multiple of 63!" The background to all this is that drive manufacturers have started to use 4K sectors internally, translating them into 8 regular sectors to the outside world. The implication is that all your major disk structures, also file clusters, must be aligned to the internal 4KB sectors to achieve best performance. Put another way, we need to make all our boundaries divisible by 4KB (or 8 regular sectors), as well as whatever other constraints already exist (ie., as per this thread). So, the 128MB partition quanta we've just been discussing is fine. However, the normal 63 sector offset (corresponding to 1 track) for the boot sector isn't, this needs to increase to 63x8=504 (regular) sectors. This wastes an extra 7 tracks (441 sectors, or 221kB) but still maintains proper CHS boundaries. What MS did instead with Vista (and now 7), is follow the 4KB multiple requirement (for performance), while totally ignoring the CHS boundaries that most of the existing O/S seem to require, and chosen a huge 2048 sector (1M) offset to the boot sector. Just a little more thought and they could easily have met all requirements. (Maybe someone rather stupid, thought 1MB was a nice round figure?) Joe. There is no need to deviate from the CHS standards to align Disk I/O in Windows 9x. I have already added alignment options to my Partitioning and Formatting tools. At the most, you may need to waste one Cylinder.

Emulating the instructions you identified can be done although a simple emulation is only approximate. I assumed that patching them would probably lead to a succession of additional problem instructions. Have you been able to determine precisely all of the P6 instructions used by mjpegtools?

Why?

i gave up a realtek network card .i will try to via vt6130 pcie network card Sec channel can to use DVD-rw is fine~ anyway thank you a suggest The RTL8111 NIC, I was referring to, is the one built into the Motherboard not a separate card. My Gigabyte MA78GM Motherboard also uses it.

The RTL8111 Network Driver uses a lot of low memory, try my RAM Limitation Patch Demo with the /M Option. Using the Secondary SATA Channel will require my SATA Patch to be used in Native mode. The only PCIe Video Card I have seen without the shutdown problem is the 7100GS. This level of compatability seems to be common to a number of motherboards. I have one like it.

XMS RAMDisks such as XMSDSK.EXE are managed by the Windows Memory Manager. This ties up System Arena space which is limited to 1 GiB total. There is not enough space in your configuration to support a 512MiB RAMDisk so Windows crashes during boot. Replacing HIMEM.SYS with HIMEMX.EXE will allow you to boot since it delays recognition of the space used by the RAMDisk, but it will crash if you fill up the RAMDisk. I have written non-XMS RAMDisks that do not have this issue as they are not managed by Windows.

I disassembled it to test the bare SATA Drive. It wasn't easy. None of the BIOSes recognized it as 3TB. They all said it was 801GB. They also wrap around at 2TiB back to Zero so a DDO is required to use it. The SI 3512 and the JMicron SATA Cards correctly recognize the drive as 3TB and properly handle requests above 2TiB. I have a Patched IO.SYS that support Partitions above 2TiB.

I received a Seagate 3TiB Go Flex External Drive with USB 2.0 this morning. It uses 4KB Sectors at the USB Interface, while using 512 Byte Sectors at the Internal SATA Interface. None of the BIOSes I have tested support it. So Booting from it and/or running DOS without a Driver requires BIOS modifications. Windows 98SE, with ME USB Drivers and the necessary Patches, does support it, so the drive is useable as an USB External. I have yet to disassemble it to test the bare SATA Drive.

For an independent assessment, try my RFDISK Demo. It is designed for Drives up to 512TiB so it will definitely support 1TB. The Demo is Read Only.

I have attached my P6CPU.VXD. This is an emulator, not a Patch. It only handles CMOV Instructions, and a single PREFETCH code, and can be considered Alpha code. Use at your own risk. The Logger will crash if more than 16384 distinct addresses are emulated. Place P6CPU.VXD in your WINDOWS\SYSTEM Folder and add the following line to the [386Enh] Section of your SYSTEM.INI File: DEVICE=P6CPU.VXD P6CPU.ZIP

This is still unresolved. When larryb123456 installs his Pentium III and retests the Flash Player, I will be ready for the next step. My older P6CPU.VXD Emulator will handle these. Since it is not a Patcher, it will not affect any File Caches. I don't know if there are other instructions that would need emulating.

On my AMD K6-3+ CPU GOM Player runs fine beside the internal codec and the useless redundant "screen ratio" setting. I am quite satisfied with picture quality and behaviour. Not surprised. The K6-3+ obviously supports CMOV Instructions. This is similar to the differences between the Pentium II and Pentium III Processors.

Your Registry may be too large. Try my RAM Limitation Patch Demo using the /M Option to see if it helps.

I don't have the mjpeg utilities so I don't know if CMOV Instructions are the issue. You would have to examine the Illegal Instruction Details to get the OP Codes of the failing Instructions. I have two versions of my software. 1. The Patcher discussed in this Thread that Patches the three Instructions known to cause problems with Flash. 2. The Emulator I wrote to handle GOM. It emulates CMOV Instructions and one specific PREFETCH Instruction. I don't know if either or both would handle the mjpeg utilities.

GOM Player uses instructions that are not supported on K6-2 Processors. KernelEx will not help with this issue. I wrote an Emulator for the problem Instructions. This allowed it to run but was way too slow. I ended up using the Emulator log to manually Patch the GOM Player

Possibly. It would be just one more possible timing issue to consider. Not the instructions currently being Patched. I did say Alpha above. This File Cache behavior is a "Feature" Microsoft bragged about when Windows 98 was released. Read Only Code is not supposed to be altered in any way. The file copying issue only affects executables that are already causing errors. Well behaved Programs are not affected. Taking advantage of it, may allow permanent Patches to be applied so there would be no actions by the Patcher and it could be disabled. I have no intentions of altering the File Cache behavior. Of course it still exists. If necessary, all of the caches can be flushed with a single instruction. Been there. Done that.

Not even Beta. More like Alpha. That one is not a Patch. CMOV Instructions would be very difficult to Patch dynamically. The Instructions are emulated. Only Read Only Code Blocks are run from Cache. A Compressed application has to create it's own Code Blocks dynamically. These would not be treated as File Cache since they do not correspond to Disk data.

You are describing the exact opposite of the possible problem here. Here the Videos play fine on faster modern CPUs but not on the older Pentium IIs. Timing problems are entirely possible but for different reasons than you described. This is why it was suggested to test with a Pentium III of exactly the same speed, to minimize any speed improvement in the CPU.

I suspect it has to do with the SSE Instructions that use the F2 or F3 Prefix to distinguish them from other Instructions. These originally were the REPZ/REPNZ Prefixes for String Instructions. Processors generally ignore these prefixes when applied to unexpected Instructions rather than Fault them. So older ones will use the unprefixed Instructions instead. An Instruction Boundary Aware scan would be needed to find them. Patching them depends on what actually exists in the code. The three documented problems were easy to Patch. The Pentium III tests will help narrow things down. @jds: It is a bit premature to publish a Patch that has not been proven to work.

You might want to tone down your remarks. The programs you are complaining about are FREE. As for the commercial software industry, money is the reason why they are in the business in the first place. Would you go to work if you didn't get paid? I sell a number of Programs and Patches for DOS and Windows 9x. It's not enough to live on. I understand. My development system uses a 450MHz AMD K6-2 and I still use it. Unfortunately, I think most violin repair shops would go out of business if they had to stock spare parts for Stradivarius and other Classical violins. I have no immediate plans to continue. It does not appear to be a viable solution. The Explorer would have to be Patched to flush the cache. I use a separate Program to do that. My original VXD emulated the "illegal instructions". It had to, since the CMOV instructions used by the GOM Player cannot be easily Patched. It was way too slow. I ended up adding a logger to record the Addresses of the "illegal instructions" so that I could manually Patch the GOM DLL later.

Actually I am one of them. My development system uses an AMD-K6. The P3CPU Patcher is a rewrite of one I wrote previously to allow the GOM Player to run on it. It has a different set of incompatable commands. Unfortunately the CMOVcc commands cannot be Patched automatically and emulating was too slow, so I added a logger to create a list of instructions that needed Patching manually.

The problem probably was discovered and fixed in the later OSes. Check for any newer updates and if none, try any newer ME Versions if there are any. If the ME Versions don't load, they can be probably be Patched. These three files are part of DirectX.

Try disabling the PATA IDE Controller.

This doesn't sound like "Native" Mode. "Native Mode only uses one Interrupt for both Channels. You may be looking at the PATA Interface. The SATA controller may be in Compatability Mode and have no driver.

I wrote a Patch for Windows 98 that supports SATA in "native mode". Otherwise you will probably need to use PATA Drives. Does the BIOS have a "Raid" Mode for SATA?