You can use a tools such as KDiff3 to check for file differences, for a game's binary files the differences themselves won't be interesting, but you can just give it two directories and it'll say which files are different.

I also use HxD to compare individual files all the time. When it finds a difference it will display them side by side so you can visually see them in Hex format. I actually use it to make configuration changes internally within files for one of the POS systems we support at my work.

First of all, check for viruses.

I recommend free Dr.Web "CureIt" tool for Windows and native Dos Dr.Web version for MS-Dos, because modern antiviruses like Nod32 can't catch some old viruses for Dos. After you run exe first time on machine with virus, it make file corrupted.

https://free.drweb.com/cureit/

I had initially suspected some sort of boot virus like ANTI CMOS A, but ive found no evidence. If it was a virus, it only could have already been on the boot sector and/or floppies ive used, all which I formatted on a modern computer anyway.

Ive actually made some progress, and some things have put me off track.

So far, I appear to have it sorted, but want to replicate the problem again to be sure.
What I know so far:

Booting off a basic DOS floppy with no config.sys or autoexec.bat entries, the game works fine.

Some of the games such as rockford appear to have the glitch sprites and must be corrupted, I tested this in DOSBOX and the game has the same garbled sprites.

This "corrupted game" actually works fine too on the DOS machine as it turns out.

I disabled himem.sys and the game ran fine on my (fresh) DOS install.

My mate gave me a CF card that boots into DOS and uses himem.sys, and the game ran fine from booted off that.

I thought perhaps my system was corrupt, so I replaced my DOS files with his and still had the problem.

Only thing I had not changed was the Autoexec.bat and config.sys files.

Then the game ran fine off my system.

I will grab the "working files soon so you can see what Ive got.

I dont know what is so different with his entries than mine, but clearly there must be a difference with a switch for himem.sys? I need to take a closer look, but honestly ive never ran into so many problems like this before.
Ive ran this same game on other 386 machines with no problems, so not sure whats wrong here.

Here is the "working" autoexec.bat and config.sys files.

If anyone can shed any light on why the config on these files would work, I'd be keen to know!

Autoexec.bat

1LH /L:0;1,43920 /S C:\WINDOWS\SMARTDRV.EXE
2LH /L:1,27952 MSCDEX.EXE /D:CD001 /L:W
3SET TEMP=C:\TEMP
4SET BLASTER=A220 I5 D1 T4
5PATH=C:\NET;C:\;C:\WINDOWS;%PATH%
6LH /L:0 c:\dos\mouse.exe
7menu

config.sys

1DEVICE=C:\DOS\HIMEM.SYS
2DEVICE=C:\DOS\EMM386.EXE RAM
3BUFFERS=33,0
4FILES=90
5DOS=UMB
6LASTDRIVE=Z
7FCBS=4,0
8DEVICEHIGH /L:1,40800 =C:\COMMAND\OAKCDROM.SYS /D:CD001
9DOS=HIGH
10STACKS=9,256
11rem C:\NET\IFSHLP.SYS

Below are the "faulty" files from the original setup I had.
I was getting the same results from a fresh DOS install after a format and everything

1DEVICE=C:\WINDOWS\HIMEM.SYS
2DEVICE=C:\DOS\EMM386.EXE RAM
3BUFFERS=33,0
4FILES=90
5STACKS=9,256
6DOS=UMB
7LASTDRIVE=E
8FCBS=4,0
9DEVICE=C:\SB16\DRV\CTSB16.SYS /UNIT=0 /BLASTER=A:220 I:5 D:1 H:5
10DEVICEHIGH /L:1,10416 =C:\SB16\DRV\CTMMSYS.SYS
11DEVICEHIGH /L:1,12048 =C:\DOS\SETVER.EXE
12DOS=HIGH
13DEVICEHIGH /L:1,40800 =C:\DOS\OAKCDROM.SYS /D:MSCD001
14DEVICE=C:\WINDOWS\IFSHLP.SYS
15

1SET SOUND=C:\SB16
2SET BLASTER=A220 I5 D1 H5 P330 T6
3SET MIDI=SYNTH:1 MAP:E
4C:\SB16\DIAGNOSE /S
5C:\SB16\SB16SET /P /Q
6LH /L:0 C:\DOS\SMARTDRV.EXE /X
7@ECHO OFF
8PROMPT $p$g
9PATH C:\WINDOWS;C:\DOS
10SET TEMP=C:\DOS
11LH /L:1,29472 c:\MOUSE\MOUSE.COM
12LOADHIGH=C:\DOS\MSCDEX.EXE /D:MSCD001

Well, I see that the working files are not loading the IFSHLP.SYS driver, that may be somehow related to your problem. If I recall correctly WFW3.11 is the one who adds that line, it's a 32-bit filesystem driver.

Now, I'm not sure if that is indeed the direct cause of your issues, or maybe it conflicts with SMARTDRV? I never use WFW or IFSHLP.SYS so I am just speculating.

nzoomed wrote on 2020-08-15, 00:27:

Comparing the two copies, they all report the same file sizes, but is there any program I can run on windows that can compare the two copies of files and see if there is any difference?

If you just want to determine whether the files are different, you can compress them with PKZIP. PKZIP automatically calculates and stores the CRC32 for each file in the archive. Files that differ by even a single byte will have a different CRC32. Most other archiving programs have similar functionlity - or you can just find a standalone utility for calculating CRC32 values.

In fact, if you want to be sure your files are not being corrupted when they are copied to your 386, just copy the original .zip file and decompress it on your 386. If the .zip file is corrupt, PKUNZIP will tell you.

Caution:

Many times I had few old programs vanish (no alerts) even they were not infected as windows 10 deletes the 16bits and early 32bit programs deemed not compatible with windows 10 (!!). One of them was Paint Shop Pro 5.0 by JASC which I had legally on optical disc and the box for years as it was very decent to use. Oh well, was forced to use what I can get with microsoft's and i don't like their interface.

And yes, this happens with some payware software especially from China. I paid and got license for ZXW schematic for my work repairing phones and they were infected, only way is find clean one indirectly from different websites, and use the license on it. Now no body have the clean one and the ZXW website also is infected, I quit and refused to pay again as long as ZXW developers say disable your malware scanner to use ZXW. No no!! No way in chance! Biggest problem with this is ZXW is the best one out there that has each component in detail when hovered over each. Others don't have this all important detail.

Cheers,

Turns out smartdrv in autoexec.bat is the problem.
The other autoexec had a different path to smartdrv.exe and was not even loading.
When fixing it and pointing to the correct path, my problem returns.

Any idea why disk caching would be an issue?

It could not be syncing to disk properly

held wrote on 2020-08-24, 08:27:

It could not be syncing to disk properly

Would a hardware fault cause that or just dome sort of incompatibility?
I'm pretty sure I've had Rockford working on another machine with smartdrv going.

I dont have much experience with DOS other than when I played games as a kid 🤣

Reading from the wiki it keeps frequently used data in upper memory.
So I would suggest running a memcheck, it may be faulty memory.

held wrote on 2020-08-24, 11:37:

Reading from the wiki it keeps frequently used data in upper memory.
So I would suggest running a memcheck, it may be faulty memory.

I had earlier suspected faulty memory and have not only run several memtest86 tests, but also swapped out different RAM to try and all tests fine.
Not too sure what it is at fault, but im not sure if its necessary to use on a 386 or not but would like to work out if its a fault or not.

The file structure you are choosing to use when u burn the CD could be corrupting the file names.

nzoomed wrote on 2020-08-24, 21:40:

I had earlier suspected faulty memory and have not only run several memtest86 tests, but also swapped out different RAM to try and all tests fine.
Not too sure what it is at fault, but im not sure if its necessary to use on a 386 or not but would like to work out if its a fault or not.

nzoomed wrote on 2020-08-19, 05:44:

[…]
Show full quote

Copy code to clipboard

1LH /L:0;1,43920 /S C:\WINDOWS\SMARTDRV.EXE
2LH /L:0 C:\DOS\SMARTDRV.EXE /X

Now this could be me, but if SMARTDRV uses upper memory to cache frequently used data,
loading itself into that same upper memory region could be a reason.

Try loading SMARTDRV without the LH.

held wrote on 2020-08-26, 05:16:

Now this could be me, but if SMARTDRV uses upper memory to cache frequently used data, loading itself into that same upper memor […]
Show full quote

nzoomed wrote on 2020-08-24, 21:40:

I had earlier suspected faulty memory and have not only run several memtest86 tests, but also swapped out different RAM to try and all tests fine.
Not too sure what it is at fault, but im not sure if its necessary to use on a 386 or not but would like to work out if its a fault or not.

nzoomed wrote on 2020-08-19, 05:44:

[…]
Show full quote

Copy code to clipboard

1LH /L:0;1,43920 /S C:\WINDOWS\SMARTDRV.EXE
2LH /L:0 C:\DOS\SMARTDRV.EXE /X

Now this could be me, but if SMARTDRV uses upper memory to cache frequently used data,
loading itself into that same upper memory region could be a reason.

Try loading SMARTDRV without the LH.

OK, ill try that. I know that if i load SMARTDRV simply by typing it as a command, it causes the same issue.