Re: [Freedos-user] [SOLVED] XMS on a 386SX
Rugxulo, Ralph,
Thank you both for your inputs! Here's the endgame :)
I already tried to test the RAM on this machine using both "AleGr
MEMTEST 2.00" and "MEMTEST86+ 4.20" (from a boot floppy), but both fail
miserably - AleGr MEMTEST imemdiately freezes, while MEMTEST86+
immediately reboots the PC.
The BIOS test passes though, so even if RAM chips are bad, they are at
least seemingly behaving correctly.
Now, I tested two things:
MS HIMEM v2.06 (from the XMS developer disk, with sources and all) -
works fine, mem detects all XMS memory, Wolf3D is happy, no wild
reboots, no freezes, everything works (yaay!). This is not a 'free'
solution, so it can't be considered viable, but still - WORKS (meaning
my 386 is not totally wasted). Also, MS HIMEM consumes 30K of
conventional memory, which is not cool.
HIMEMX v3.34 (as per Rugxulo's suggestion) - miracle, this one works
perfectly - mem sees all the RAM, Wolf3D is happy (as well as all other
applications I tested), no crash, no reboots, no freezes, no nothing.
Solution found!
I didn't test XMGR, since I don't really see the point, XMGR being a
dead end anyway.
About HIMEMX:
1. The 'TESTMEM:ON' switch is not working - with my limited ASM
understanding, I think it checks for "TESTMEM:OFF" only, while the
default is OFF anyway.
2. What makes the v3.34 "unofficial"? Maybe might it be a good time to
advertise it as "official", so other people would avoid going through
hoops like I had to?
cheers,
Mateusz
On 25/08/2015 07:28, Rugxulo wrote:
> Hi again,
>
> On Mon, Aug 24, 2015 at 11:19 PM, Mateusz Viste wrote:
>>
>> Yes, I have considered the possibility that it might be a hardware
>> problem. Wouldn't be that surprising given that's a 25 years old
>> machine. I also resoldered lots of stuff fixing PCB traces and replacing
>> a few passive components because the mainboard was in a very poor state
>> when I got it, due to an evil battery leak.
>> But the problem I have is happening only with XMS, and it does work
>> almost perfectly with FDXMS (with the exception of Wolf3D not detecting
>> XMS), so I'd rather think there is something non-standard about this
>> 386SX, and that it does something differently than expected by most XMS
>> managers. That's one of the first 32bit machines after all - plenty of
>> space for non-standard solutions. Plus, the BIOS memory test passes all
>> right, and other XMS-relying programs work fine, too.
>
> It could actually be a cpu bug. Didn't early 386s have bugs with some
> instructions?
>
> "Early in production, Intel discovered a marginal circuit that could
> cause a system to return incorrect results from 32-bit multiply
> operations." (Wikipedia)
>
> Also see here ("80386 Bugs"):
>
> http://www.informit.com/articles/article.aspx?p=130978&seqNum=27
>
>> I will follow your suggestion and test newer versions of HIMEMX
>
> IIRC, HIMEMX had a quirk/bug where a 386 [sic] needed to do "jmp $+2"
> after enabling pmode. I don't think this was officially ever fixed
> (only in unofficial later releases), so if you're still using 3.32,
> it's probably still there.
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/himem/himemx/old/himemx-3.33-unofficial-old-386-patch.zip
>
> Ah, here's the old discussion we had on BTTR (circa 2009):
>
> http://www.bttr-software.de/forum/board_entry.php?id=6445#p6445
>
> (Rod P.'s unofficial 3.34 is mostly for workaround "modern" memory
> holes, probably irrelevant for your 386, but IIRC it does include the
> above fix too.)
>
>> and XMSGR, even if unofficial/closedsource,
>
> No, I meant the one still on iBiblio, circa this year (2015), not old
> from 2012 (not sure why you're using that one). Though honestly I
> don't know if anything significant changed since then anyways.
>
> http://freedos.sourceforge.net/software/?prog=xmgr
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/xms/xmgr/drivers-2015-03-05.zip
>
>> just for the sake of knowing whether it changes anything. Then indeed,
>> my next plan was to install MSDOS and see if it works fine, but I
>> thought it might be a good idea to ask around here first for some
>> first-hand experience.
>
> I'm surprised I even remembered any of this. Maybe I'm not completely
> useless after all (just close enough!). :-P
>
--
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] [SOLVED] XMS on a 386SX
Hi, On Tue, Aug 25, 2015 at 1:04 AM, Mateusz Viste wrote: > Rugxulo, Ralph, > > Thank you both for your inputs! Here's the endgame :) > > I already tried to test the RAM on this machine using both "AleGr > MEMTEST 2.00" and "MEMTEST86+ 4.20" (from a boot floppy), but both fail > miserably - AleGr MEMTEST imemdiately freezes, while MEMTEST86+ > immediately reboots the PC. I vaguely remember an older version (circa 2003) hacked by Eric, which I think is this one, so if super curious, you could try it: http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/memteste.zip > The BIOS test passes though, so even if RAM chips are bad, they are at > least seemingly behaving correctly. Well, it's probably not your RAM then. > Now, I tested two things: > > MS HIMEM v2.06 (from the XMS developer disk, with sources and all) - > works fine, mem detects all XMS memory, Wolf3D is happy, no wild > reboots, no freezes, everything works (yaay!). This is not a 'free' > solution, so it can't be considered viable, but still - WORKS (meaning > my 386 is not totally wasted). Also, MS HIMEM consumes 30K of > conventional memory, which is not cool. Yes, at least it works, so that's good. > HIMEMX v3.34 (as per Rugxulo's suggestion) - miracle, this one works > perfectly - mem sees all the RAM, Wolf3D is happy (as well as all other > applications I tested), no crash, no reboots, no freezes, no nothing. > Solution found! Again, it's probably the 386 "jmp $+2" cache flushing (or whatever, I'm no systems programmer). > I didn't test XMGR, since I don't really see the point, XMGR being a > dead end anyway. Well, slightly older is still on iBiblio with sources, for comparison. > About HIMEMX: > 1. The 'TESTMEM:ON' switch is not working - with my limited ASM > understanding, I think it checks for "TESTMEM:OFF" only, while the > default is OFF anyway. Dunno. > 2. What makes the v3.34 "unofficial"? Maybe might it be a good time to > advertise it as "official", so other people would avoid going through > hoops like I had to? There are no maintainers. I don't even know who (if anybody) would even have the interest to decide to even release a "new" version. Literally, the previous two versions were hacks done by random people, and even those are from years ago. So it just doesn't seem to show much activity. I actively use 3.34 with no problems, but that's far from exhaustive proof that no bugs or regressions remain. I agree that the 3.32 "bug" is bad for 386 owners, but it's unlikely that anybody cares (well, besides you and me and a very few others). In short, I don't know what to tell you. What do you want to do? Clean up the sources? Repackage it? Edit the Software List? Become maintainer yourself?? (Can't be any worse than /dev/null.) -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] [SOLVED] XMS on a 386SX
On 8/26/2015 12:59 AM, Rugxulo wrote: > Hi, > > On Tue, Aug 25, 2015 at 1:04 AM, Mateusz Viste wrote: >> Rugxulo, Ralph, >> >> Thank you both for your inputs! Here's the endgame :) >> >> I already tried to test the RAM on this machine using both "AleGr >> MEMTEST 2.00" and "MEMTEST86+ 4.20" (from a boot floppy), but both fail >> miserably - AleGr MEMTEST imemdiately freezes, while MEMTEST86+ >> immediately reboots the PC. > I vaguely remember an older version (circa 2003) hacked by Eric, which > I think is this one, so if super curious, you could try it: > > http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/memteste.zip If MemTest86+ (exactly THAT and none else ever mentioned by me, and of course the latest version) is not properly running on a PC, there is something fishy with that host, either something not "standard" or there is a problem with the memory/CPU... > >> The BIOS test passes though, so even if RAM chips are bad, they are at >> least seemingly behaving correctly. The RAM "test" in most BIOS'es isn't a test for properly working RAM, it is merely a test if RAM is accessible/available at a certain memory location, and hence means absolutely nothing for the proper operation of a PC... > > Well, it's probably not your RAM then. Wrong conclusion... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
