stanwebber wrote on 2022-04-19, 04:57:

my systems freeze when i try to load either umbpci.sys or hiram.exe and i don't understand why. […]
Show full quote

my systems freeze when i try to load either umbpci.sys or hiram.exe and i don't understand why.

first, umbpci which has considerably more documentation...my amd k7 system should be supported as it is chipset independent. umbpci correctly identifies my cpu as supported and installs itself, but then it just locks up. the only thing i can identify as a potential conflict are these bios settings:

Video BIOS Shadow
Setting to enabled, the video BIOS will be copied to the system memory and increase the video speed accordingly.

C8000-CBFFF/CC000-CFFFF/D0000-D3FFF/D4000-D7FFF/D8000-DBFFF/DC000-DFFFF Shadow
Setting to enabled, the extended ROM data located at the respective address range will be copied to system memory.

i sort of understand the video bios setting, but the other one is nonsensical to me. um, do want to cache system memory in other parts of the exact same system memory to improve performance? what should these items be set to?

Which video card are you using?

Video card BIOS ROM usually starts from C0000 and doesn't necessarily end at C7FFF.

second, i don't grasp how to use hiram.exe at all. am i supposed to load this with himem.sys or what? and in which order? is it supposed to provide umb's in real dos mode like umbpci? the documentation available is threadbare. i'd like to use hiram.exe on a pentium system without a pci bus, but it locks up this and my k7 system instantly as well. can someone show me a working example?

HIRAM isn't necessary, but in your system it can be used to enable UMB just after loading UMBPCI. It is only useful to load HIMEM.SYS into high memory.

Like this:

1DOS=HIGH,UMB
2DEVICE=C:\UMBPCI\UMBPCI.SYS
3DEVICE=C:\HIRAM\HIRAM.EXE
4DEVICEHIGH=C:\DOS\HIMEM.SYS

third, does anyone know if the xmgr or himemx alternatives load themselves (partially) high by default or do they always reside totally in conventional memory like himem.sys?

No, it resides in conventional memory like HIMEM.SYS without using the trick I mentioned with HIRAM.

Edit: XMGR.SYS does have the /W command line switch which allows to load itself into high memory provided that UMBPCI is loaded prior.

video card is a radeon 9800 non-pro. i don't know if it's the video bios, but umbpci is detecting something occupying the whole c0000 range as its self generated include switch starts at dxxxx something.

i mostly ask about hiram.exe because my pentium system is incompatible with umbpci since there is no pci bus. it's hiram.exe or nothing (or some other alternative i've yet to discover)

stanwebber wrote on 2022-04-19, 06:30:

video card is a radeon 9800 non-pro. i don't know if it's the video bios, but umbpci is detecting something occupying the whole c0000 range as its self generated include switch starts at dxxxx something.

Very likely that is the BIOS ROM of the Radeon 9800 is taking 64KB seeing that UMBPCI can't use the entire C0000 range.

i mostly ask about hiram.exe because my pentium system is incompatible with umbpci since there is no pci bus. it's hiram.exe or nothing (or some other alternative i've yet to discover)

The only alternative that I know besides HIRAM and UMBPCI is RDOSUMB.

If keeping real mode isn't a priority, EMM such as EMM386 and QEMM can be also used to enable UMBs.

There is also UMB_DRVR and The Last Byte memory manager

i seriously need an expert on this stuff. i have tried every iteration of settings i can think of and have gotten absolutely nowhere. at this point i would be happy to get as little as /i=d800-dfff working, but it is looking hopeless.

there is scant little information online about getting this working on a kt133a chipset...one guys says it's incompatible; another guy says he's never had problems on any of his boards. that's pretty much it.

stanwebber wrote on 2022-04-20, 03:43:

i seriously need an expert on this stuff. i have tried every iteration of settings i can think of and have gotten absolutely nowhere. at this point i would be happy to get as little as /i=d800-dfff working, but it is looking hopeless.

there is scant little information online about getting this working on a kt133a chipset...one guys says it's incompatible; another guy says he's never had problems on any of his boards. that's pretty much it.

UMBPCI works perfectly with my Abit KT7A v1.3 (VIA KT133A) so there is no general incompatibility with your chipset. It would be very helpful if you attach or list the content of your Config.sys and Autoexec.bat here. The point is maybe not UMBPCI freezes your system but something that you want to load after it. Not every TSR/driver is compatible with it.
Also as a first step you should disable all shadowing options in BIOS. You do not need them.
In the package of UMBPCI you can also find a utility named UMBCHK. You can use it to determine if UMBPCI can be used and what way on your system. You should remove/comment out both UMBPCI and EMM386 from your config.sys then run UMBCHK.

i think i have it more or less sorted out now, but it easily took more than 50 reboots of trial and error. there's no isa-dma in shadow ram with athlon chipsets so basically you can't load much of anything besides dos in high memory. falcosoft, as you correctly ascertained it was everything coming after umbpci that was causing problems.

i was dead in the water until i discovered the dos=noauto parameter. dos=umb, which is kinda mandatory, basically tries to load everything into upper memory in spectacular failure whether you want it to or not. noauto put a stop to that requiring an explicit devicehigh.

autoexec.bat gave me problems too. for some reason after the first loadhigh, anything else set high would freeze up. didn't matter which either...everything can load high, by itself, but not in combination with anything else.

in any case getting dos loaded high was the critical part. i get 613kb free even with hdd cache and cdrom driver loaded. i also discovered that xmgr and himemx can load my big aweutil tsr into upper memory by default.

bios settings had no impact whatsoever. it either worked or didn't work no matter what they were set to. i don't understand any of it anyway so i disabled all of them figuring at least it would give me more l2 cpu cache.

getting realmode umb's for the p54c system is an academic excercise at this point and the kt133a has sapped all of my curiosity. the ess688 soundcard is non-pnp anyway so with qemm + hdd cache + y2k fix + univbe + mixerset + ctmouse + doskey + softmpu i still get 629kb free so i can call it a day.

oh yeah, once i got everything working i tried that umbpci > hiram > devicehigh=himem trick, but it fails miserably. himem.sys always complains about another memory manager and exits. it's win98se 7.1 so maybe it needs another version of dos.

btw, falcosoft, you're the guy! (1 of 2) i was referencing about the scant kt133a umb information i could find from this post here:

Re: X58 PC+ Yamaha744 sound card-pure Dos7.1- compatibility list and research, work in progress- gurus needed

maybe i have enough posts to direct message on vogons now...

oh hey, thanks for your definitive info on the virtualmidisynth forum as well.

stanwebber wrote on 2022-04-20, 20:37:

oh yeah, once i got everything working i tried that umbpci > hiram > devicehigh=himem trick, but it fails miserably. himem.sys always complains about another memory manager and exits. it's win98se 7.1 so maybe it needs another version of dos.

That trick works fine in the DOS version that comes with Windows 98 SE and have it used like that on my Socket 7 computer. Here is what MDGx said about this trick:

The trick is that HIRAM implements the function "Request XMS-UMB" without HIMEM.SYS, while UMBPCI does it the "official" way, by […]
Show full quote

The trick is that HIRAM implements the function "Request XMS-UMB" without HIMEM.SYS, while UMBPCI does it the "official" way, by extending HIMEM.SYS with this function.
When HIMEM.SYS loads, DOS takes all XMS UMBs from HIRAM.EXE, and HIRAM deactivates its XMS function to allow HIMEM.SYS to load.
Without "DOS=HIGH,UMB" HIMEM.SYS would stop with an error message like:

"Another XMS driver is already installed"

because HIRAM has no reason to deactivate its small XMS handler.
Therefore by using HIRAM.EXE you can save 1 KB of low memory in comparison to loading UMBPCI.SYS by itself.

In your case it would be DOS=HIGH,UMB,NOAUTO. Regardless this was entirely optional and wouldn't work on your Pentium system at all, and glad that you got UMB even if it real mode wasn't kept.

i guess i haven't dropped this completely. i got a cf card & pcmcia adapter for the p54c laptop (nec versa p) and the cardsoft drivers chew up a massive amount of ram in real mode. i found this relavent info in the service manual:

The system supports system and video shadowing, both controlled through complementary
metal oxide semiconductor (CMOS). The system supports BIOS as a cacheable area with
write protection.
000000-09FFFF - Reserved for System Base Memory
0C0000-0C7FFF - Mapped to ISA BIOS
0C8000-0CFFFF - Mapped to ISA Bus
0D0000-0DFFFF - Mapped to PCMCIA Bus
0E0000-0FFFFF - Reserved for System BIOS
E8000h-EFFFFFh - Reserved for System BIOS
100000h-On-Board - Reserved for Extended and/or Expanded system memory

there are absolutely no options in the phoenix bios to configure any of this. am i just out of luck since everything kinda looks filled up? a000-bfff is always unuseable right?

stanwebber wrote on 2022-04-23, 21:19:

...there are absolutely no options in the phoenix bios to configure any of this. am i just out of luck since everything kinda looks filled up? a000-bfff is always unuseable right?

If you do not want to use monochrome video modes then B000-B7FF is actually useable. All EGA/VGA graphic video modes use only the segment at A000-AFFF and text modes use only addresses starting at B800.