Features of different versions of TERABYTE PLUS PACKAGE'es.

[defuser]

Hi. I started the game and it ran out of memory. After looking at what the memory is occupied with, I found that HIMEM.SYS eats up 46KB, while on a clean system (On a virtual machine) about 1KB. I went to look at the difference and found that the culprit of the problem is IO.SYS. As it turned out, this one IO.SYS from the TERABYTE PLUS PACKAGE version 3.0. I have this version 3.0 package installed for a very long time to support large disks and it works otherwise quite stable all this time.

I checked previous versions of TERABYTE PLUS PACKAGE and it turned out like this:

IO.SYS from TERABYTE PLUS PACKAGE versions 1.0 to 1.3 (Inclusive).

IO.SYS from TERABYTE PLUS PACKAGE versions 2.0 to 3.0 (Inclusive).

What do you recommend to do in this case? I see a very impressive list of changes there. Can I roll it back IO.SYS before version 1.3? Or are there any other ways to solve the problem? Thank you.

[MERCURY127]

it is himem problem, not io. u accidentally mixed up himem.

Edited November 6 by MERCURY127

[jumper]

For DOS games, use a slimmer boot sequence. Or LOADHIGH some things into upper memory.

 

[defuser]

On 11/6/2024 at 1:37 PM, MERCURY127 said:

it is himem problem, not io. u accidentally mixed up himem.

Thank you for your answer, but what can actually be done in this situation? Rudolph's Readme doesn't say much about it a lot has been written:

Quote

WINDOWS VERSIONS

The Patches in this Package are based on the last official Updates of the
English Versions of the Files for Windows 98SE. The Patches appear to be
compatable with Windows 98 but extensive testing has not been done. If a
problem occurs please contact the Author.

Use with non-English versions should work but any messages produced by the
Patched Files will be in English. Use with DBCS versions such as Chinese or
Japanese is not currently supported. Do not attempt to relocalize the IO.SYS
file, it will crash.

 

53 minutes ago, jumper said:

For DOS games, use a slimmer boot sequence. Or LOADHIGH some things into upper memory.

 

Yes, so far we have to survive just like that. When I roll back IO.SYS up to version 1.3 the game works no complaints. I haven't ventured to work with large disks with this legacy IO yet... This is the configuration purely temporary and only for running this one problematic game. For normal operation, I return IO.SYS version 3.0 is back in place. It's not very convenient, but at least it works.

[defuser]

Also, on a tip from MERCURY127, I started digging to the side HIMEM.SYS and I found another solution like this: https://www.mdgx.com/umb.htm#HIR

And with it, it really turns out to free up quite a lot of memory and memory. IO.SYS from TBPPlus3 becomes less pronounced:

but now there is not enough "EMS" memory. As it turned out, this HIRAM+UMBPCI eats up exactly the same area the amount of memory that WINDOWS normally allocated to maintain EMS. Here it is (Marked "PP"):

and after applying HIRAM+UMBPCI, this area is already dealing with them:

Accordingly, Windows cannot find the required space (a contiguous free chunk). So EMS it becomes no longer available and the game starts swearing again (and of course it doesn't work). I don't succeed place both at the same time..

 

Edited November 10 by defuser

[defuser]

I suspect that this hardware is eating up so much space (video card, first of all). By the fact that under normal conditions, for example, it should be something like this:

in this case, I would be able to simultaneously place EMS and HIMEM in the upper memory...

Well, in general, okay, the option with different configurations (Game\Working), I quite like it too. Moreover, so far only one such game has come across, for which a rollback was needed IO.SYS, and all the others work. In other words, the situation is quite rare, exceptional, and potentially solvable. If there are no simple obvious paths or updates for IO.SYS, in principle, and so it will do. Thank you all.

[jumper]

If running the DOS game inside Windows, try [386Enh] LocalLoadHigh=1 in System.ini instead of the DOS LOADHIGH and UMB methods.

 

[defuser]

17 hours ago, jumper said:

If running the DOS game inside Windows, try [386Enh] LocalLoadHigh=1 in System.ini instead of the DOS LOADHIGH and UMB methods.

LocalLoadHigh=1 is generally initially spelled out. But by itself, it does not affect anything. Apparently, it needs something else to work correctly, the same UMBPCI, for example (But, I hope, not slow EMM386.EXE?). I'm trying to figure out what is missing at the minimum. After all, there is still about 64KB in any case should remain free to support EMS under WINDOWS (Without it, the game simply does not start). I'm also trying to find some substitute for EMS, which would preferably eat 32KB or less (Or even work somehow differently, but could transfer control to WINDOWS).

[jumper]

In Windows, right-click on the shortcut you use to launch the game and edit its Properties: Advanced->MS-DOS mode->Specify a new MS-DOS configuration->Configuration....

 

[defuser]

In general, yes, the problem was aggravated by a video card that was too late (I wonder if it is possible to somehow edit its vBIOS in such a way that it would take up a little less address space?). Replaced the video card. I also cleaned it up a little. And now it turned out like this (If you don't ship anything there):

It is necessary to take up all this space now in some optimal way... I prefer to play this particular game under WINDOWS (There is already a separate MS-DOS and there are games there, there are no problems, but TBPLus is not needed there). And here we need to somehow make it so that not only our patient fits in this upper memory, but also the regular "EMS Page Frame" (96 KB approximately after loading takes up a sum), so that it would also be there (The game requires it just too)! What is the best way to do this? For example, this is how they managed to take up all the space in DOSBOX (Where the dots are displayed in my screenshot, they just have a PageFrame loaded there)?

By the way, while I was testing all this a little, I noticed that in a virtual machine (Virtual PC 5.2) in no version 9x "EMS Page Frame" is loaded (Even in release 95 and the latest updated SE)! That is, games there under WINDOWS on the enable EMS tab are not available. The "1MB" card there, of course, does not look very good under WINDOWS (Although it is better than in some other virtual machines) - literally one small continuous window of 64KB in size, the rest is all smeared I don't understand how. But to load this frame, you probably need a little more (According to my estimates, really, from 72 to 96 KB). So, Windows ME under the same identical conditions manages to load the "Page Frame" into the same small window without any problems and does it quite correctly (Although the "1MB" card itself is almost identical). So, it turns out that in Windows ME this mechanism was really somewhat improved? If so, can this improvement be ported to Windows 98 somehow as well? Or does this idea not make much sense?

Edited November 12 by defuser

[defuser]

On 11/11/2024 at 8:05 AM, jumper said:

If running the DOS game inside Windows, try [386Enh] LocalLoadHigh=1 in System.ini instead of the DOS LOADHIGH and UMB methods.

 

 

On 11/12/2024 at 9:33 PM, jumper said:

In Windows, right-click on the shortcut you use to launch the game and edit its Properties: Advanced->MS-DOS mode->Specify a new MS-DOS configuration->Configuration....

 

Everything worked out. Used "LocalLoadHigh=1" + EMM386.EXE (with parameters). Now the game also starts with IO.SYS version 3.0. Returned even the old (more productive) video card. There is now enough memory, and the game starts, but only with the LH parameter (for example: "lh game.exe"). Thank you.