Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
Sharedoc wrote:OK, I tried to install for Win98, but it fails to open \system32\drivers for copying file
Sharedoc,
Yes, as I suspected. Even if the OS directory structure were the same under win9x/win3x, the piix4.sys driver would not load under win9x/3x
Are there a significant number of folks that would still want to run the legacy Windows codes on their ThinkPads? I could either write the code for a DOS/Win9x/Win3x driver, or just publish the southbridge register bits that need to be twiddled. Are the number of users running the newer windows OS on the 600 series in the minority? What do you think?
Sharedoc wrote:Difficult to say how many legacy Win98 users there are out there.
Whatabout a pure dos DeepSleep utility that can be inserted in autoexec.bat in Win98?
To my understanding this would be quite simple extracting the core part of the SpeedStep driver.
The code to do the DeepSleep call from DOS is only a handful of x86 assembler lines. The larger piece of code is finding the location of the H/W and the base address for the ACPI register ports, in this case the southbridge H/W. Since IBM/MS DOS was written prior to widespread use of plug-and-play/configurable PCI device bridges, it provides no services for PCI configuration (must be done by the BIOS - and the BIOS can choose pretty much any location - although it is likely a fixed location for a given version of the TP BIOS). The most portable way of doing this is to query the PCI configuration registers directly for the vendor ID and device type, then read the base address location from the device table. I can probably find some code that I wrote some years back that does this.
The great aspect of testing a DOS driver is the whole system can be booted from a floppy disk
Hi,Spent some time reading thru this thread,but as a total dumbo you sort of lost me quite early on.
I have 600e,upgraded to p3 500,sorted 127 problem,everything works fineMany thanx all)but can anyone tell me if i should have l2 cache enabled or not,i have software to do this.but not sure if method used is ok.
I've only tested it under PC DOS 7.0 on my TP600e 2645-55U. It only looks for one acpi bridge type (the piix4, id= 0x71138086). If IBM used other types on the 600e series I will need to add those device IDs to the utility. The "/d" option can be used to display all the bridge IDs up to the point that a match is found - or all of them if no match.
wmarcusm, so with your deepsleep util. Do we need to hardware mod the cpu?? or pretty much just stick the cpu, say a p3 650 in there and then just run the util?
ProtoColD wrote:wmarcusm, so with your deepsleep util. Do we need to hardware mod the cpu?? or pretty much just stick the cpu, say a p3 650 in there and then just run the util?
ProtoColD,
If used in a TP 600e, you need to modify the MMC-2/P3 per Sharedoc, et al, discussion in this thread. The 600e series motherboard does not support the SpeedStep signals (and likely does not contain the required BIOS routines). The combination of modifying the cpu and using the DeepSleep utility will put the P3 in the higher clock rate state (performance setting). This is not "true" SpeedStep of course - the cpu multipliers are not selected dynamically based on power demand (battery or AC for example). A true SpeedStep emulation could be done on the 600e, but it would require additional mods to the motherboard, and additional driver software (or a BIOS update) to handle the power management functions (lcd open/close, AC plug in/out, etc.).
DOS DeepSleep does not produce the desired outcome when used in Windows98 autoexec.bat.
I can see the SpeedStep utility is run as part of autoexec.bat, but when the Windows98 finishes loading, the processor speed is lower speed.
Propably there is a switch back to lower speed within Windows after executing the dsleep in autoexec.bat
Hmm... the cpu transition from real mode to protected mode during the win98 boot process most likely is the reason (unless the DeepSleep driver is not executed until after the switch to protected mode). You can try an experiment. You should be able to set the high clock speed using the utility in dos, do a warm reboot back to dos and check the speed - it should still be set to the high multiplier. Repeat same process, but now boot win98. If the speed is reset after the win98 boot, then the real to protected transition is the suspect. Looks like we may need a vxd driver to put the processor in DeepSleep after the boot process.
