I tried a quick search on Google Groups (usenet posts), nothing there except people already back in 1990 looking for it.

https://groups.google.com/search?q=EXTMEMS.SYS

"LIMulators
Some programs, known as LIMulators, emulate expanded memory on 8088- and 80286-based machines using hard disk space and/or extended memory. These programs are not much of an advantage, because although they supply expanded memory, they are not hardware. They must locate a 64K EMS page frame in conventional memory and also take up space for the driver itself. LIMulators generally take close to 80K of conventional memory to run. Because conventional memory is the most precious memory on your machine, we do not recommend these types of programs. They are also typically extremely slow."

Possibly you want to talk to this guy... https://www.linkedin.com/in/roboachiever

Since Softbyte computing seems to be the only softbyte in the right era.

I knew it!

I always wondered why it wouldn't be possible to emulate XMS on an 8086/8088, since the whole point of XMS was to make memory beyond the 1MB addressable range available in real mode, by providing an API that would copy the accessed memory to the conventional memory space.

As I understand it, the main difference with EMS is that EMS maps bank-switched extra memory to a fixed window in the Upper Memory Area, whereas the XMS API allows for the copying of data between the extra memory and arbitrary locations within conventional memory.

Although it would be slower than EMS, since XMS emulation would require byte-for-byte memory copying, there's no technical reason why at least that part of the XMS API couldn't be emulated on an 8086/8088 CPU.

The only part of the XMS spec that couldn't be emulated on such CPUs would be the High Memory Area.

Someone please correct me if my understandings of this are wrong. Always eager to learn!

I hope this piece of obscure software turns up somewhere. On-line searches are indeed coming up dry here.

It isn't in the jheronimus "big bundle"
http://www.vogonsdrivers.com/getfile.php?fileid=2163

I'm just not sure how the NEC V30 could access extended memory though. Does it have enough pins for that?

douglar wrote on 2024-06-04, 17:20:

It isn't in the jheronimus "big bundle"
http://www.vogonsdrivers.com/getfile.php?fileid=2163

I'm just not sure how the NEC V30 could access extended memory though. Does it have enough pins for that?

It doesn't. Looks like there is BIOS support for Int 15h ah==87 to move a block of memory to or from the ST into conventional memory.

https://www.atarimania.com/pgesoft.awp?version=23201

GloriousCow wrote on 2024-06-04, 18:34:

douglar wrote on 2024-06-04, 17:20:

It isn't in the jheronimus "big bundle"
http://www.vogonsdrivers.com/getfile.php?fileid=2163

I'm just not sure how the NEC V30 could access extended memory though. Does it have enough pins for that?

It doesn't. Looks like there is BIOS support for Int 15h ah==87 to move a block of memory to or from the ST into conventional memory.

https://www.atarimania.com/pgesoft.awp?version=23201

Expanded memory sure. That was uses on 8086 / 8088 processors. That makes sense.
Emulating EMS from XMS was common on 386 computers. That makes sense to me too.
This driver? "there are some special drivers which may exchange Extended to Expanded Memory, like EXTMEMS.SYS from SOFTBYTE."

That driver must exist on the Atari ST side, because the NEC V30 doesn't know anything about Extended (XMS) memory. Doesn't have the pins or the circuitry for it.

douglar wrote on 2024-06-04, 18:41:

Expanded memory sure. That was uses on 8086 / 8088 processors. That makes sense. Emulating EMS from XMS was common on 386 comp […]
Show full quote

Expanded memory sure. That was uses on 8086 / 8088 processors. That makes sense.
Emulating EMS from XMS was common on 386 computers. That makes sense to me too.
This driver? "there are some special drivers which may exchange Extended to Expanded Memory, like EXTMEMS.SYS from SOFTBYTE."

That driver must exist on the Atari ST side, because the NEC V30 doesn't know anything about Extended (XMS) memory. Doesn't have the pins or the circuitry for it.

That's my impression. The only support was through the emulator's BIOS calls. They even warn you direct XMS access will explode:

By using XMA difficulties may occur if Programms use the special Funktions of the 80286 Prozessor which are not su […]
Show full quote

By using XMA difficulties may occur if Programms use the
special Funktions of the 80286 Prozessor which are not
supported by the NEC V30.
Precisely: The V30 does not have a protected-mode.

GloriousCow wrote on 2024-06-04, 18:54:

douglar wrote on 2024-06-04, 18:41:

Expanded memory sure. That was uses on 8086 / 8088 processors. That makes sense. Emulating EMS from XMS was common on 386 comp […]
Show full quote

Expanded memory sure. That was uses on 8086 / 8088 processors. That makes sense.
Emulating EMS from XMS was common on 386 computers. That makes sense to me too.
This driver? "there are some special drivers which may exchange Extended to Expanded Memory, like EXTMEMS.SYS from SOFTBYTE."

That driver must exist on the Atari ST side, because the NEC V30 doesn't know anything about Extended (XMS) memory. Doesn't have the pins or the circuitry for it.

That's my impression. The only support was through the emulator's BIOS calls. They even warn you direct XMS access will explode:

By using XMA difficulties may occur if Programms use the special Funktions of the 80286 Prozessor which are not su […]
Show full quote

By using XMA difficulties may occur if Programms use the
special Funktions of the 80286 Prozessor which are not
supported by the NEC V30.
Precisely: The V30 does not have a protected-mode.

Those int calls are pretty limited. I’m not sure what you could actually achieve, since you can’t actually access the data.

http://www.phatcode.net/res/219/files/xms30.txt

OK, so I briefly studied how the INT 15h, ah=87h call works. So apparently you need to pass a pointer to a global descriptor table through ES:SI. This is an address in the 1MB addressable memory area in real mode, and could therefore be emulated in an 8086 or 8088.

This GDT should then contain 6 descriptors, only the 3rd and 4th of which (the source block and target block respectively) are required. [url=http://vitaly_filatov.tripod.com/ng/asm/asm_026.14.html]The source and target block contain 24-bit (286 protected mode) addresses[/url].

So this could indeed be emulated completely in real mode (and thus on an 8086 or 8088), with the XMM (HIMEM replacement) having to do translation from 24-bit addresses to 20-bit real mode addresses for the first 1MB of memory and mapping anything higher to EMS memory or a disk cache. This mapping, translation, emulation and memory copying would all have to be done by the emulator on each such INT 15h call. This would be fairly complex (and possibly slow) to emulate completely in real mode without any actual extended memory, but not impossible.

And indeed like GloriousCow clarified, it would only work for applications and games that access extended memory from real mode through the INT 15h. It will obviously not work for software that would try actually switching to 16-bit protected mode.

There's actually some C source examples of that kind of thing I think that turn up if you search extmems against cd.textfiles.org with filenames like extmem.zip and extmem.arc

BitWrangler wrote on 2024-06-05, 03:19:

There's actually some C source examples of that kind of thing I think that turn up if you search extmems against cd.textfiles.org with filenames like extmem.zip and extmem.arc

As soon as you get an XMS driver running, there are ready-made solutions to emulate EMS using the XMS copy API function (which would call INT 15/87h in that XMS driver). Re-Implementing an XMS driver is way easier than writing a full LIMulator. You might want to use EMM286 to convert XMS into EMS.

digger wrote on 2024-06-04, 23:39:

So this could indeed be emulated completely in real mode (and thus on an 8086 or 8088), with the XMM (HIMEM replacement) having to do translation from 24-bit addresses to 20-bit real mode addresses for the first 1MB of memory and mapping anything higher to EMS memory or a disk cache. This mapping, translation, emulation and memory copying would all have to be done by the emulator on each such INT 15h call. This would be fairly complex (and possibly slow) to emulate completely in real mode without any actual extended memory, but not impossible.

I'm going to check the RAM disk option first and run some benchmarks. Emulator would allow similar access...
Well the beauty of it is that there are two more emulators reversed:
- AT-Speed - which is using 80286 @ 8MHz
- AT-Once - which is using 386SX @ 25MHz plus it has it's own 512kB "FAST RAM" and Xillinx FPGA for chipset

Just waiting for the PCBs to arrive!

Thanks for all the input - I'll investigate it a bit further, trying to get to the Sack ppl on German Atari forum as well...

Hi, I'm not sure if this is helpful, but..

Older versions of PCE (8088/8086 PC emulator) had XMS support via supplied driver.

Re: need info: detailed comparision of ways accessing above 1mb ram in dos

The AST Rampage had a a driver that converted EMS memory (aka XMA memory, IBM term) into Extended Memory (rex.sys).
And that meant memory via BIOS service routines (int15h), rather than XMS (what himem.sys provides).

Re: Is it possible to go over the 640KB barrier on an 8088 using some software ?

Strictly speaking, though, this shouldn't be called Extended Memory support.
It's rather some sort of "AT BIOS memory request call" support (made up term).

That's what ancient utilities like VDISK.SYS had used before XMS had existed.
Himem.sys has a switch to set aside int15 memory (/INT15=) for those dinosaur.

Edit: It could be worded way better perhaps, but the AT BIOS with int15h was meant to made things easier.
Back in the day, the LOADALL trick and Himem.sys weren't known.

So the 80286 was being put into Protected-Mode to get a bit of memory beyond first megabyte and then switch back to Real-Mode and give it to the application.

The AT BIOS essentially automated this procedure and standardized it.

And since it's a BIOS call, there's no physical dependency.

An PC/XT with special hardware, a simplified MMU so to say, can do have its own memory via INT15h just as well.

That's essentially what the PC emulator kit for the Atari ST was implementing in hard and software, I believe.

Thanks @jo22 this build the fullk picture along with @digger and @GloriousCow feedback!

One potential use case for this: the game Dune II, which supports PCM sound effects only when extended memory is available, even though the game itself runs in real mode, as far as I know.

You could at least in theory get the game to run with digitized sound effects on an 8086 or 8088 system with an emulator like this.

Don't ask me how well that game would run in such a configuration, though. 😅 It would probably be slow on such CPUs, even without the XMS emulation. 🐌

Would be fun to try, though! For science.

digger wrote on 2024-06-05, 18:29:

One potential use case for this: the game Dune II, which supports PCM sound effects only when extended memory is available, even […]
Show full quote

One potential use case for this: the game Dune II, which supports PCM sound effects only when extended memory is available, even though the game itself runs in real mode, as far as I know.

You could at least in theory get the game to run with digitized sound effects on an 8086 or 8088 system with an emulator like this.

Don't ask me how well that game would run in such a configuration, though. 😅 It would probably be slow on such CPUs, even without the XMS emulation. 🐌

Would be fun to try, though! For science.

But it seems like a logical thing to do there would be to Lock Extended Memory Block and then use it for DMA to the sound card, but I don't see how that API would be supported here.

jakethompson1 wrote on 2024-06-05, 18:56:

digger wrote on 2024-06-05, 18:29:

One potential use case for this: the game Dune II, which supports PCM sound effects only when extended memory is available, even […]
Show full quote

One potential use case for this: the game Dune II, which supports PCM sound effects only when extended memory is available, even though the game itself runs in real mode, as far as I know.

You could at least in theory get the game to run with digitized sound effects on an 8086 or 8088 system with an emulator like this.

Don't ask me how well that game would run in such a configuration, though. 😅 It would probably be slow on such CPUs, even without the XMS emulation. 🐌

Would be fun to try, though! For science.

But it seems like a logical thing to do there would be to Lock Extended Memory Block and then use it for DMA to the sound card, but I don't see how that API would be supported here.

I remember that Dune II only supported 8-bit sound cards, which would only allow DMA to conventional memory (the first 1MB, even on 286+ systems). And also it didn't use a 32-bit DOS extender, because it also ran on 286 systems.

So I guess the programmers of that game would call INT 15h to copy digital samples and other game asserts to conventional memory whenever needed, and then access it there.

But thinking more about that, that would be a slow operation for on-the-fly stuff such as sound effects, especially on 286 systems, which were slow to switch to protected mode and back to real mode each time such INT 15h calls would be made.

I wonder why the game didn't use EMS instead. Probably because it was targeting 286 systems, which were more likely to have XMS than EMS?