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