VOGONS


386 Memory question

Topic actions

First post, by PLB-389

User metadata
Rank Newbie
Rank
Newbie

Hi all,
In addition to my 486 dell that I've almost finished rebuilding, I've also got a Mitac 3062e, which is a 386sx-16 based system. The processor is soldered onto the motherboard so not much opportunity to upgrade except I did put a coprocessor in. It's got 4 banks of 30pin memory slots (8 slots in total). I was wondering if anyone might be able to help me understand the way it works.

I have 8x 4mb simms. When I fill up banks 0 and 1 with 4x4mb=16mb it recognises 640kb base and 15232kb extended memory. Seems weird to me because 15232kb is a smidge more than 15mb - is there maybe some physical limitation with these systems? What seems stranger is when I fill up the rest with 8x4mb simms = 32mb, it only recognises 640kb base and 5120kb extended memory.

Can anyone help me understand this?

Reply 1 of 27, by pentiumspeed

User metadata
Rank l33t
Rank
l33t

386SX is 16bit data path with 24bit addressable range for memory allocation.

So this is same limitations as 286. 16MB max except 386SX gives you a way to run 32bits enabled software. Slowly.

Cheers, pentiumspeed

Great Northern aka Canada.

Reply 4 of 27, by Anonymous Coward

User metadata
Rank l33t
Rank
l33t

Mabye 15232 is only an extended memory count? What kind of BIOS does your machine use?

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 5 of 27, by pentiumspeed

User metadata
Rank l33t
Rank
l33t

Actually look back to the XT and AT that begun that oddball less than actual memory reported when 1MB or more memory is used:

8088/8086 is 1MB addressable range, the missing bit is upper 384K is reserved for mapped i/o ranges for expansion cards. That why 640K max. Same with 286 if using 1MB total memory too. Still there even with greater than 1MB memory total.

Again on 286 and later processors started out 640K minus the upper 384K and rest beyond that like more than 1MB like 2, 3, 4, 16MB or more capacity usable to 386 and later aware software/OS. Legacy still there if you are playing with DOS and Win 3.x computer with athlon, P4, C2D etc.

Hence 15,xxxMB on yours. If you calculate from there using diagnostic software, should add up to 16,5535. 24 addressable lines power of two.

Cheers, pentiumspeed

Great Northern aka Canada.

Reply 6 of 27, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie

386sx has a 16 MB memory limit due to the mentioned 24 address line architecture.

However, there is a chance to enable the rest of the memory as EMS by a motherboard/chipset specific driver.
I do not know if your board has this path since 386sx with that amount of memory were uncommon at the time when they were in use.

Reply 7 of 27, by root42

User metadata
Rank l33t
Rank
l33t

No need for a specific EMS driver. EMM386 will work just fine on a 386SX, since it emulates EMS via v8086 mode, which is available on every 386.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 8 of 27, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie
root42 wrote:

No need for a specific EMS driver. EMM386 will work just fine on a 386SX, since it emulates EMS via v8086 mode, which is available on every 386.

But EMM386 cannot see the memory between 16 and 32 MB. There is a chance that a chipset specific driver can do this although I never have seen one in real.

Reply 9 of 27, by canthearu

User metadata
Rank Oldbie
Rank
Oldbie

The maximum physical address range on the 386SX is 16meg (or 24bit)

https://en.wikipedia.org/wiki/Intel_80386#The … 80386SX_variant

The extended memory count will be all addressable memory above 1 megabyte. So that gives a maximum of 15megabytes of memory on the extended memory counter.

Then you have other ISA devices that can take up address space for memory mapped I/O, so that further reduces the memory space available for actual memory. Hence why you are just a little bit below 15meg memory on your BIOS counter.

I've never seen or even heard of a motherboard with built in EMS emulation .... do they even exist?

Reply 11 of 27, by Jo22

User metadata
Rank l33t++
Rank
l33t++
canthearu wrote:

I've never seen or even heard of a motherboard with built in EMS emulation .... do they even exist?

Surely. 😀 286 chipsets often did (see NEAT). Some 486 or laptop chipsets also supported it. (See some of my vids)
386SX PCs were often based on exisiting, very advanced 286 chipsets, by the time when plain/pure 286 PCs went out of favor.
That's why in some odd situation, some 386SX PCs can be more funtional than an avaerage 386DX system based on a modern 386 chipset.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 12 of 27, by Scali

User metadata
Rank l33t
Rank
l33t

Yes, I had a Commodore 386SX-16 with NEAT chipset. The BIOS allowed me to allocate memory between EMS and XMS. The EMS memory could only be used via the specific NEAT driver (EMM386 emulates EMS via XMS memory, which is very slow).

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 13 of 27, by root42

User metadata
Rank l33t
Rank
l33t

I think EMM386 acquires memory via HIMEM.SYS in the XMS area, but actual EMS emulation is done via the MMU and not quite that slow. But my memory might be a bit fuzzy.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 14 of 27, by Scali

User metadata
Rank l33t
Rank
l33t
root42 wrote:

I think EMM386 acquires memory via HIMEM.SYS in the XMS area, but actual EMS emulation is done via the MMU and not quite that slow. But my memory might be a bit fuzzy.

Well, on my 386SX-16, using EMM386 was considerably slower than using the chipset. So much so that the advantage of using EMS was nullified.
For example, Falcon 3.0 could use EMS to accelerate the video sequences it played.
With the NEAT chipset, this made the videos play very smoothly. With EMM386, they were just as choppy as when you only had XMS.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 15 of 27, by root42

User metadata
Rank l33t
Rank
l33t

I do believe that the chipset can do this faster! Probably had wider or faster access to the memory than the SX with its meager 16 bits...

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 16 of 27, by canthearu

User metadata
Rank Oldbie
Rank
Oldbie

It is not because the chipset is faster than the CPU at accessing memory.

It is because in switching the CPU from real mode to protected mode and then running everything in v86 mode to emulate EMS and map UMBs imposes a small overhead.

On a 386SX-16, that overhead is going to be quite high, as the 386 was really quite slow at virtual 86 mode, and the 16bit data bus and low clock speed of 16mhz just amplifies that slowness.

Reply 17 of 27, by root42

User metadata
Rank l33t
Rank
l33t
canthearu wrote:

It is not because the chipset is faster than the CPU at accessing memory.

It is because in switching the CPU from real mode to protected mode and then running everything in v86 mode to emulate EMS and map UMBs imposes a small overhead.

On a 386SX-16, that overhead is going to be quite high, as the 386 was really quite slow at virtual 86 mode, and the 16bit data bus and low clock speed of 16mhz just amplifies that slowness.

The latter part sounds interesting. Do you have any references for this fact? I assumed that the SX core was more or less the same as the DX, except for the data bus and the limited address lines.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 18 of 27, by Scali

User metadata
Rank l33t
Rank
l33t
root42 wrote:

The latter part sounds interesting. Do you have any references for this fact? I assumed that the SX core was more or less the same as the DX, except for the data bus and the limited address lines.

True, the SX core is the same as the DX core, only the bus is different.
But, firstly, the 386 wasn't particularly fast to begin with, with v86 mode, and adjusting page frames etc.
Secondly, setting up v86 mode and using paging to emulate EMS requires various tables in memory. Access to these tables will be slower over the 16-bit bus.

There is probably a 'break even' point somewhere:
EMS memory was originally developed for 808x machines, so even the fastest EMS cards probably use relatively slow memory, and they always use the ISA bus, so there is some practical 'upper bound' to EMS performance.
As CPUs get faster, the overhead of v86 mode and EMS emulation became less of an issue. The advantage is that you could use the regular system memory, which would always run at full speed. So on a given machine, probably a 486DX-33 or so, EMM386 will probably be faster than the fastest hardware solution.

The NEAT chipset is an interesting special case, because like EMM386 it uses the fast system memory. However, it eliminates the overhead of EMM386 (and the need to run in v86 mode at all). So its EMS performance may be faster than the fastest EMS card as well.

Anyway, as for v86 overhead, you see similar things with the TSR solution for SoftMPU and the OPL2LPT and related interfaces. They actually use some EMM386 features for virtualization. And the overhead of this is quite high. A 386SX-16 is generally too slow to run games this way, even though it would run the games just with the actual hardware.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 19 of 27, by root42

User metadata
Rank l33t
Rank
l33t

Thanks for the info! I never noticed a speed issue back in the day. First v86 capable machine I had was a 486SX with 25MHz, which was probably fast enough so the difference wasn't hugely noticeable.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC