MiSTer FPGA Forum

chimaera wrote: ↑Wed Aug 05, 2020 6:32 am The versions of EMM386.EXE/HIMEM.SYS in MSDOS 6.22 contains some bugs, especially when used with slowdown apps. These bugs were fixed in the Windows 98 SE version of DOS.
The Drivers can be downloaded here:
(My Firefox says the site contains malware, but my antivirus didnt find anyting. If you dont trust the zip, pull the files yourself from WIN98SE)
https://www.legroom.net/files/howto/msdos/mem98se.zip
They replace the original files in the C:\DOS\ directory. Dont forget to make backups of the original files.

Also, there is an open source version of HIMEM.SYS called HIMEMX (used in FreeDOS),
It can be downloaded here:
https://sourceforge.net/projects/himemx/

Lastly, there is an even newer version of CTMOUSE.EXE than the one floating around on the internet.
It fixes some bugs, but can only be obtained from the C:\FDOS\ folder in FreeDOS.

These updated drivers should be a good fit in your list.

That's all really good info. Thanks!

I didn't realize that with EMM386.EXE and HIMEM.SYS. I went ahead and added copies from my Win98SE install as well as the open-source one.

I also pulled the ones from PC-DOS 7.1 as well, since IBM continued doing development on DOS up until 2008. Those versions also seem to be compatible with MS-DOS 6.22, from some quick tests.

Regarding CuteMouse, the one I have in GitHub is 2.1b4, which I pulled from the CuteMouse site. It appears to be the same as the one included in FreeDOS 1.3 RC3 (same SHA256 sum), so I think it's good there.

Coffea wrote: ↑Wed Aug 05, 2020 2:32 pm Windows 9x Video driver (from dev branch) in disk image img format

Thanks!

Kreeblah wrote: ↑Wed Aug 05, 2020 11:03 pm That's all really good info. Thanks!

I didn't realize that with EMM386.EXE and HIMEM.SYS. I went ahead and added copies from my Win98SE install as well as the open-source one.

I also pulled the ones from PC-DOS 7.1 as well, since IBM continued doing development on DOS up until 2008. Those versions also seem to be compatible with MS-DOS 6.22, from some quick tests.

Regarding CuteMouse, the one I have in GitHub is 2.1b4, which I pulled from the CuteMouse site. It appears to be the same as the one included in FreeDOS 1.3 RC3 (same SHA256 sum), so I think it's good there.

Thanks!

Oh Im sorry about cutemouse. I should have double checked it.

I'll have to check out the PC DOS drivers!

chimaera wrote: ↑Thu Aug 06, 2020 4:46 am

Kreeblah wrote: ↑Wed Aug 05, 2020 11:03 pm That's all really good info. Thanks!

I didn't realize that with EMM386.EXE and HIMEM.SYS. I went ahead and added copies from my Win98SE install as well as the open-source one.

I also pulled the ones from PC-DOS 7.1 as well, since IBM continued doing development on DOS up until 2008. Those versions also seem to be compatible with MS-DOS 6.22, from some quick tests.

Regarding CuteMouse, the one I have in GitHub is 2.1b4, which I pulled from the CuteMouse site. It appears to be the same as the one included in FreeDOS 1.3 RC3 (same SHA256 sum), so I think it's good there.

Thanks!

Oh Im sorry about cutemouse. I should have double checked it.

I'll have to check out the PC DOS drivers!

No worries! I'm curious whether the PC-DOS ones fix the compatibility issues as well. I haven't used any slowdown programs, so I'm not sure what to look for there. If you test them out, would you mind reporting your findings?

The EMM386 issue, atleast on real hardware, is that it can cause system freezes when using slowdown software like SLOWDOWN (http://bretjohnson.us/) with for example the utility CPUCACHE in SLOWDOWN(details in SLOWDOWN docs). Reducing speed is good for older titles like FirePower, Castlevania, Castle Wolfenstein, Sopwith and more.

According go a forum post: (https://www.speedguide.net/forums/showt ... XE-problem)
"The problems are related to SLOWDOWN's ability to manipulate (Disable/Enable) the CPU's L1 Cache. More specifically, the problems are related to bugs in certain versions of Microsoft's HIMEM.SYS & EMM386.EXE, the Extended & Expanded Memory Managers."

I have installed the PCDOS drivers, but I havent gotten go test them with slowdown yet. But I havent got any issue using them so far. Ill repor back when I have tried SLOWDOWN properly.

I have done some testing with SLOWDOWN, and it seems to freeze the core while using any version of EMM386/himem.sys. I guess it is because of the way it manipulates the cache. MOSLO works for now though.
I Will do further testing as the core advances.

chimaera wrote: ↑Sat Aug 08, 2020 7:59 am I have done some testing with SLOWDOWN, and it seems to freeze the core while using any version of EMM386/himem.sys. I guess it is because of the way it manipulates the cache. MOSLO works for now though.
I Will do further testing as the core advances.

Are you trying games that require something slower than the 15mhz setting?

Really old pc games require it, they will run at unplayable speeds without it. Moslo emulates 4.77Mhz, but it can also slow down the system with a percentage. SLOWDOWN does the same but are more configurable.

What needs slower than 15MHz? It's ideal even for the Gold Box games. I can't imagine slower than that.

rhester72 wrote: ↑Sat Aug 08, 2020 5:58 pm What needs slower than 15MHz? It's ideal even for the Gold Box games. I can't imagine slower than that.

The IBM PC 8088 was introduced in 1979 and had a clock speed of 4.77Mhz to about 10Mhz. DOS was introduced in 1980. There are alot of games from this era that are compatible with IBM PC and MSDOS 6.22, except for the unplayable speed caused by the programmed dependency of clock speed. This problem is remedied with two programs, MOSLO and SLOWDOWN, and probably more.
There are even "newer" games(Fire Power, 1988) that has that kind of bad programming.

If you want other games than the ones I already stated in previous posts, i'll add to the list:
Beyond Castle Wolfenstein
Airborne Ranger
Contra
Rush n attack.

I

chimaera wrote: ↑Sat Aug 08, 2020 7:27 pm

rhester72 wrote: ↑Sat Aug 08, 2020 5:58 pm What needs slower than 15MHz? It's ideal even for the Gold Box games. I can't imagine slower than that.

The IBM PC 8088 was introduced in 1979 and had a clock speed of 4.77Mhz to about 10Mhz. DOS was introduced in 1980. There are alot of games from this era that are compatible with IBM PC and MSDOS 6.22, except for the unplayable speed caused by the programmed dependency of clock speed. This problem is remedied with two programs, MOSLO and SLOWDOWN, and probably more.

Part of me thinks the best solution is a separate 8086 core designed for close replication of original timings. It’s just not worth trying to get AO486 to do something even the real systems it’s trying to replicate couldn’t be bothered to do.

deepthaw wrote: ↑Sun Aug 09, 2020 4:15 pm

chimaera wrote: ↑Sat Aug 08, 2020 7:27 pm

rhester72 wrote: ↑Sat Aug 08, 2020 5:58 pm What needs slower than 15MHz? It's ideal even for the Gold Box games. I can't imagine slower than that.

The IBM PC 8088 was introduced in 1979 and had a clock speed of 4.77Mhz to about 10Mhz. DOS was introduced in 1980. There are alot of games from this era that are compatible with IBM PC and MSDOS 6.22, except for the unplayable speed caused by the programmed dependency of clock speed. This problem is remedied with two programs, MOSLO and SLOWDOWN, and probably more.

Part of me thinks the best solution is a separate 8086 core designed for close replication of original timings. It’s just not worth trying to get AO486 to do something even the real systems it’s trying to replicate couldn’t be bothered to do.

Most/all x86 systems had a TURBO button on the front panel, that toggled the clockspeed to 4.77 MHz. They could definitely be bothered.

ToothbrushThreepwood wrote: ↑Sun Aug 09, 2020 5:21 pm

deepthaw wrote: ↑Sun Aug 09, 2020 4:15 pm

chimaera wrote: ↑Sat Aug 08, 2020 7:27 pm

The IBM PC 8088 was introduced in 1979 and had a clock speed of 4.77Mhz to about 10Mhz. DOS was introduced in 1980. There are alot of games from this era that are compatible with IBM PC and MSDOS 6.22, except for the unplayable speed caused by the programmed dependency of clock speed. This problem is remedied with two programs, MOSLO and SLOWDOWN, and probably more.

Part of me thinks the best solution is a separate 8086 core designed for close replication of original timings. It’s just not worth trying to get AO486 to do something even the real systems it’s trying to replicate couldn’t be bothered to do.

Most/all x86 systems had a TURBO button on the front panel, that toggled the clockspeed to 4.77 MHz. They could definitely be bothered.

What they throttled down to was motherboard-dependent. in the era of the 486, those few that still had turbo buttons usually throttled to AT frequencies (but not performance levels, obviously).

deepthaw wrote: ↑Sun Aug 09, 2020 4:15 pm

chimaera wrote: ↑Sat Aug 08, 2020 7:27 pm

rhester72 wrote: ↑Sat Aug 08, 2020 5:58 pm What needs slower than 15MHz? It's ideal even for the Gold Box games. I can't imagine slower than that.

The IBM PC 8088 was introduced in 1979 and had a clock speed of 4.77Mhz to about 10Mhz. DOS was introduced in 1980. There are alot of games from this era that are compatible with IBM PC and MSDOS 6.22, except for the unplayable speed caused by the programmed dependency of clock speed. This problem is remedied with two programs, MOSLO and SLOWDOWN, and probably more.

Part of me thinks the best solution is a separate 8086 core designed for close replication of original timings. It’s just not worth trying to get AO486 to do something even the real systems it’s trying to replicate couldn’t be bothered to do.

That could be a sollution, but if it doesnt work in this core that is supposed to emulate a 386, then the core still isnt cycle-accurate.

To be clear:
The tools worked on real hardware. MoSlo works as intended in the latest official release of ao486. SLOWDOWN doesnt, it locks the system. This is probably because of problems with the implementation of L1 cache in ao486 and how SLOWDOWN manipulates it.
Himem.sys and EMM386.exe in the MSDOS release version 6.22 contained bugs that can lock the software in certain real hardware, which could break the software in ao486. Potentially other software could break to. The fix to this is to use Himem.sys and EMM386.exe from Windows98 SE, which is compatible with MSDOS. Himem.sys and EMM386.exe from PCDOS probably also patch this bug, but I have not been able to verify it.

Even if I did not care about those old games, I would still use newer updated versions of these files(PCDOS versions), because they seem to free the most memory in my preliminary tests. They are also fully compatible with win3.11, which JEMM386 seems not to be (it breaks sound in windows 3.11).
The upside with JEMMX/JEMM386 though is that it frees even more memory than EMM386 and are Open source and still developed (https://github.com/Baron-von-Riedesel/Jemm).

The core has seen some incredible improvements lately, and I am fully confident that the developers will improve this core even further.

In the meantime, i Think it is a great thing to compile a list with the latest, bugfree and most useful drivers and utilites for msdos.
Kudos to Kreeblah for starting this thread.

rhester72 wrote: ↑Sun Aug 09, 2020 6:17 pm

ToothbrushThreepwood wrote: ↑Sun Aug 09, 2020 5:21 pm

deepthaw wrote: ↑Sun Aug 09, 2020 4:15 pm

Part of me thinks the best solution is a separate 8086 core designed for close replication of original timings. It’s just not worth trying to get AO486 to do something even the real systems it’s trying to replicate couldn’t be bothered to do.

Most/all x86 systems had a TURBO button on the front panel, that toggled the clockspeed to 4.77 MHz. They could definitely be bothered.

What they throttled down to was motherboard-dependent. in the era of the 486, those few that still had turbo buttons usually throttled to AT frequencies (but not performance levels, obviously).

Ah yes. In the 486 era the 4.77 MHz wasn’t a standard anymore, so they usually just halved the clock speed, depending on how you fiddled with the jumpers. I can’t remember any pre-pentium PCs from my childhood that didn’t have a turbo button, but that might just be an oddity.
Anyway, it’s a bit of a luxury problem with the core. I don’t know if it’s necessary to fork into a whole new core to solve it, though. I would guess that a lot could be solved by just being able to choose a clock speed lower than what is currently available, but I have no idea about the feasibility or ramifications of that.

Isn't the core's CPU running 3 times slower than normal? So if you run at 15Mhz, in essence it would performs like a 5 Mhz CPU?

For some reason i can't get the mouse working, i tried the latest MS Driver (mouse.exe), it's complaining it can't finde a mouse right away. Tried cutemouse then, it loads, reports it's binding to PS/2 port but no mouse works later. Tried various USB Ports for my mouse and varios cores (cache33, cache 34 und cache 41 and "original" ao486 core). Tried with no EMM386/QUEMM loaded and with it, makes no difference either.

Is there anything neccessary to do before loading the driver?

thank you, kind regards

Jan

@janosch,
could you try cutemouse /p (to fore the PS2) and if it still does not work try with cutemouse /V ?
When you say the mouse is not working, is it with a game, windows or purely in dos like with NC , Qbasic etc ?

Hi Kathleen,

did not work either in DOS and Games, but using /p with cutemouse it does work now (tested with "edit" from MSDOS 6.22 and Syndicate by Bullfrog). Thanks a lot, you really made my day, finally able to play Syndicate!

Kind regards

Jan

Now that the sound card is switched from an SB2.0 to an SB16, has anybody had any luck with any SB16 drivers with Windows 3.1? It seems that the lack of an ASP implementation is causing issues with the ones I've tried, though I'm pretty sure there were SB16 revisions that didn't have an ASP at all, so I'd imagine that there are some that should work somewhere.

I installed the sb16 3.1 drivers and got the same asp thing, noticed in github that asp is not implemented so removed it from dos startup files and the message goes away. That did not fix everything though. Wave and FM still didn't work. FM was listed as a voyetra in the drivers and i believe IRQ was conflicting. I removed sbpro2 startup lines and made sure sb16 was proper defaults, however I had no success and reverted to sbpro2 drivers.

I haven't tried the Windows 3.1 driver yet from this driver cd but the Windows 95 and Dos drivers have been working for me: http://vogonsdrivers.com/getfile.php?fi ... enustate=0

How do I use the Windows 95 modem driver as a null modem cable? Please advise. I've never done this before.