• Please review our updated Terms and Rules here

8086/V20/V30, Win 3.0 and 'virtual memory'?

lameboyadvance

lameboyadvance

Member
Joined
Aug 25, 2016
Messages
36
Location
Australia
I recently came across a couple of Amstrad XTs (a PC1512 and a PC1640). While they'll need a bit of work before they're functional again I decided to look into what addons I could put in them. I was surprised to find this place, and all the amazing advances in hdd/ram/etc expansions people have made since their heyday.

I know that Windows claimed it needed a 286/'protected mode' to allow virtual memory/pagefiles, but with the XTIDE allowing gigabytes of storage, and EMS cards that seem to allow up to 2MB RAM, I was wondering if there was in fact a way to combine the two under Windows (or even DOS) to allow the extra hdd space to be seen/used as memory?


...Also, I was under the impression the maximum RAM limit for XT/EMS was 1MB, yet lo-tech sells a 2MB RAM board. Do these actually work? If so, what is the actual limit for XTs?
 
Last edited:
Its a pity then that the XT ISA bus is only 8-bit, otherwise we may have seen a 32MB RAM card for it. (I'm guessing lack of address lines is the reason there isn't one?)
Everything I read still says that XT can only go to a maximum of 1MB (well, 64kb over that AFAIK). So I'm wondering if thats either wrong, or another method has been used to overcome that.


I'm still curious though as to whether or not there is some sort of driver that works on 8086 and allows virtual memory/pagefiles to let Windows think it has more RAM than it actually does. While not really necessary, having even 4MB under Windows would be a big improvement over 1MB or even 2MB.
 
lameboyadvance said:
Its a pity then that the XT ISA bus is only 8-bit, otherwise we may have seen a 32MB RAM card for it. (I'm guessing lack of address lines is the reason there isn't one?)
Everything I read still says that XT can only go to a maximum of 1MB (well, 64kb over that AFAIK). So I'm wondering if thats either wrong, or another method has been used to overcome that.


I'm still curious though as to whether or not there is some sort of driver that works on 8086 and allows virtual memory/pagefiles to let Windows think it has more RAM than it actually does. While not really necessary, having even 4MB under Windows would be a big improvement over 1MB or even 2MB.
Click to expand...

Well the address space is 1Meg so you can only ever see one 1Meg at any point in time. When Lotus-123 appeared and people wanted bigger spread sheets the PC started to run out of RAM. So folks created cards which allowed "banks" of memory to be switched into the area above the 640K line but below the 1MB. Its a bit like one of those car CD players that hold eight or ten CD's but only one can be played at once. There is a reasonably complete Wiki article here:-

https://en.wikipedia.org/wiki/Expanded_memory
 
lameboyadvance said:
...Also, I was under the impression the maximum RAM limit for XT/EMS was 1MB, yet lo-tech sells a 2MB RAM board. Do these actually work?
Click to expand...

I don't see why not. AST back in the day released the AST Rampage/2 which is an 8-bit ISA card for both the XT/AT with up to 2MB of EMS memory. I actually have one of these cards in my Atari PC3 8088 and it works no problem.

The lo-tech card isn't anything new it's just simply a more modern design.
 
Thanks for that info, but I already knew what memory banking was, I was just under the impression that even then back in the day the memory expansion cards were only just 1MB. As I've just found information of at least one 8MB version existing (the Dakota RAM/XT), I was obviously wrong...
...In regards to such information, I just found this snippet as I was searching eBay for XT addon cards (from a 2MB EMS board listing no less, sadly WAY out of my price range though):
EMS memory is a little bit of a kludge from the XT days. The original PC only had 20 address lines, which gave it a max of 1mb of addressable RAM. This is where the 640k dos limit comes from, 640k for apps, and 384k reserved for BIOS, etc. In order to add more RAM, EMS was invented. It will load a driver to create a table of multiple 64k segments, out of whatever RAM is available. The application MUST BE AWARE OF HOW TO USE EMS for this to add RAM. The downside was access speed, and if you read up on it, you'll find that Bill Gates totally hated EMS and thought it was awful. :) 286 machines had 24 address lines, and 386's had 32 giving them 16mb & 4GB of addressability, so EMS was really not needed. This is what XMS is, and why you load himem.sys in the config.sys for DOS.
Click to expand...


....And I guess no one ever made an 8086 capable virtual memory driver?
 
lameboyadvance said:
Thanks for that info, but I already knew what memory banking was, I was just under the impression that even then back in the day the memory expansion cards were only just 1MB. As I've just found information of at least one 8MB version existing (the Dakota RAM/XT), I was obviously wrong...
...In regards to such information, I just found this snippet as I was searching eBay for XT addon cards (from a 2MB EMS board listing no less, sadly WAY out of my price range though):



....And I guess no one ever made an 8086 capable virtual memory driver?
Click to expand...

Virtual memory requires the support of the CPU to be transparent to the application program that is being swapped out to disk. The 286 is the first CPU to support it.
 
Also note that swapping is hypothetically possible without virtual memory, but there's two main ways to do it (and none of these can be done on Windows without a rewrite of its memory management routines):

1. You can have the OS swap the entire program out to swap another program in, with a huge performance impact, and a single program still cannot exceed the available memory. Some very low-end *nix implementations (Mini-UNIX and LSX) did this. This can be transparent to the program, though.
2. You can write a program to handle its own swapping - it keeps track of the memory it's been allocated, and it swaps itself out. But, that's not transparent to the program, it must be aware of all of this.

Also, EEMS and "true" EMS 4.0 cards (not the Lo-Tech card) can handle swapping pages in and out of the entire address space (you actually remove all but 64-256k from the motherboard when using one of those, to let them do the most they can), opening up another possibility for semi-transparent swapping, that was actually used for DOS programs by Desqview - you assign EMS pages to a program, and then map those pages into the address space when you want to run the program. But, Windows never really supported this - "large page mode" (which uses EEMS or true EMS 4.0 cards over the entire address space) was a thing that Microsoft developed support for, but it was never stable.

With EMS 3.2-style memory (how Windows normally handles EMS), programs that are EMS-aware can put some things (typically data) into EMS instead of main memory, though, which reduces the amount of conventional memory they use... but they're still gonna use a lot of it.
 
Oddly enough, there were a very few x80 CPU programs that could implement a type of virtual memory. The basic scheme was to compile to a sort of P-code, then, on interpretation, use disk storage to supplement available memory. JRT Pascal is one such setup.

But then, that should be no surprise. You could emulate an 80386 on a Z80, given sufficient memory, albeit slowly, as the Z80 is Turing-complete.
 
Windows will load code and data segments into EMS 4 if you have extra EMS windows. Unfortunately, this does not work for programs that have more than 64k of data because the whole data block is locked together and stuck in the lower 640k. Note that real mode Windows development guidelines strongly recommend that no program use more than 64k of data.

DOS sessions could be swapped to disk but it is an all or nothing proposition and takes a long time.

Windows on a 808x/80286 does not implement virtual memory but settles for discarding code segments. These code segments can then be reloaded from the original file on disk. Functionally, this is equivalent to swapping code segments except there isn't an extra copy of the code segment stored on disk. Saves disk space but is a little slower. If you have enough EMS, you could move the entire Windows directory to a ramdisk and get quick reloading of discarded code.
 
Long time ago I saw some program to emulate EMS using HDD.
Who knows, maybe even 8088-compatible?
Of course, it was too slow to be useful, but maybe replacing the HDD with some modern Flash/SSD would alleviate this?
 
Xacalite said:
Long time ago I saw some program to emulate EMS using HDD.
Who knows, maybe even 8088-compatible?
Of course, it was too slow to be useful, but maybe replacing the HDD with some modern Flash/SSD would alleviate this?
Click to expand...

TurboEMS is 8088 compatible. The problem is it only supports a limited subset of EMS 3.2, enough to trick Lotus into using its fake EMS but not enough to handle the EMS functionality needed by real mode Windows.
 
I wrote and marketed an EMS emulator back in the day, so I can recall some of the issues. The first is that you don't have the usual RAM page at D0000 available, so you have to appropriate some of the 640K base RAM space. The second is that EMS 4.0 has a lot of added functionality that's impossible to accommodate in an emulator that runs on an 8088, so a limited 3.2 is about the best that one can do--and it eats available RAM to create an EMS page space. Not the greatest situation in the world, but useful if you've got to have something. For example, you could get Lotus 1-2-3 or SuperCalc to use emulated EMS for large spreadsheets (which is really what the idea of EMS was originally all about). But it's not fast, just barely functional.

An 80386 on the other hand, has the functionality needed to emulate EMS 4.0.
 
alecv said:
LTEMM driver (opensource!) emulates EMS 4.0 except two functions on a very simply hardware
Click to expand...
It doesn't emulate EMS.
It supports EMS using actual memory-paging hardware.
BTW, I'm wondering why did Lo-Tech choose to make a 2 MB-only board? Nowadays it shouldn't be any more expensive to make a 32 MB one.
 
Xacalite It emulates EMS 4.0 functions on the 3.2-like hardware (single fixed frame address, 64K window = 16Kb x 4 pages )
2Mb size fits very well for simplifying hardware design: 2^7 = 128 * 16Kb = 2048Kb.
7bit is used for internal frame address stored in 4x74LS573 latches. Memory size may be expanded upto 4096Mb using full 8 bit in this registers but it requires modifying driver and hardware. Otherwise, 512Mbit SRAMs are rather expensive.
 
Last edited:
But now you're talking about added hardware. In a "naked" 5160 with HD and floppy, 3.2 is about the best you can do. Some of the early VLSI support chipset for 8088 and 80286 did have some added hardware facilities for EMS.

But if you want real EMS on an XT, get an AboveBoard or the like with appropriate drivers.
 
2 MB is plenty of EMS for period software. Most applications topped out at using 512kB EMS leaving a good amount for a disk cache. Desqview or large page frame Windows running a lot of big DOS apps might use more but it is an unpleasant experience.
 
Thanks for the replies everyone.
I thought maybe since memory programs like LTEMM and HIMEM.SYS were needed to use higher memory that maybe these programs were called by programs requiring them, and that maybe an alternate version could be made that returns data from 'memory' that is in fact from the HDD instead.
The fact I was wrong about that, and also that the 8086 is not powerful enough to do EMS v4 in software, let alone fake it using hdd accesses, probably means that such a thing would not be possible on XT hardware.

I guess I'll just have to wait for the 2MB memory boards to come back in stock.
 
Actually, hang on, why couldn't you do EMS 4.0 emulation on a naked XT?

So, emulating EMS 4.0 on an EMS 3.2 card basically involves, whenever you change register sets, or change page mappings, swapping contents of RAM to and from EMS pages, this all being handled by the INT 67h handler.

An EMS 3.2 emulation on an XT simply puts the page frame in conventional memory, and blocks that memory off so nothing else gets allocated there. Changing page mappings to the page frame gets swapped to disk.

With an EMS 4.0 emulation doing that - again, this could all be done in the INT 67h handler - why couldn't it just swap directly to disk? It'd be incredibly slow, but I can't see why it wouldn't work.

Mind you, this doesn't give you the benefits of a true EEMS/EMS 4.0 implementation, but then, neither does EMS 4.0 emulation on an EMS 3.2 card, and you'd end up with 64k less usable conventional RAM than EMS 4.0 on a 3.2 card.
 
You must log in or register to reply here.
Back
Top