• Please review our updated Terms and Rules here

ISA 8 Bit 8MB Extended Memory Card

Looking at the LIM spec, a board (and driver) providing only the basic functions and 4x 16KB pages in a single 64KB window looks doable with a bunch of SOIC sRAMs, some latches, buffers and a bit of glue logic. In this simple form, it would have 4MB address space (16KB x 256) but that would be expensive to make.
 
I had a thought: why don't we have a crack at this in software using a swap partition? We'd have to write the driver anyway and this would open up the full 32MB allowed in the spec, and with an XTIDEr2 or XTCF board, we have IO way faster than would have been possible at the time. 16KB pages could be swapped to a partition in about 125ms I reckon - clearly much slower than updating page frame registers, but worth a shot?

The only hardware needed would be a 64KB RAM segment available in upper memory, which could either be via a dedicated (and potentially entirely through-hole) SRAM board, or using the board design I posted already. This approach would also open up EMS apps to machines line Tandy 1400 series laptops, which do have upper memory available but no chance of ever having an EMS board.
 
If I understand you right, you'd want to write an EMS driver that uses a 32MB file on disk as a virtual memory/swap area. Well, no need to reinvent the wheel, that's been around for quite a while. Searching a Simtel mirror will surely find one or two implementations of that. I don't recall if the software emulation drivers claim EEMS/EMS 3.2 or whatnot, but I know they do allocate the 64K page frame in regular DOS memory so there's no need to have real RAM above 640k.

Obviously, any hardware functions (remapping, etc.) silently fail. And also obviously, you can't use emulated EMS for things like Desqview. It's really only useful if you come across a program that supports EMS but somehow does NOT support swapping of its own.
 
Yes, though I was thinking of a swap partition instead of a swap file, as FAT-16 is way too computationally expensive. Why would it be no use for DesqView though, I wonder if anyone has ever profiled the frequency of page changes (locality of reference and all that)?
 
Last edited:
pearce_jj said:
Yes, though I was thinking of a swap partition instead of a swap file, as FAT-16 is way too computationally expensive. Why would it be no use for DesqView though, I wonder if anyone has ever profiled the frequency of page changes (locality of reference and all that)?
Click to expand...

If DesqView sees multiple mapping registers, or the ability to hardware map to the 0-640K area, it will try to use these so that it can swap entire programs in and out of memory realtime to multitask between them. If a disk swap driver advertises that and/or attempts to emulate it, DesqView will likely grind to a complete halt.

I would much rather see a modern LIM EMS 4.0 board project. It would have 100% compatibility with all apps that use EMS (including DesqView) without trickery or speed penalties or changes to existing software. For extra speed and transparency, it could include a small BIOS that implemented the LIM EMS standard (INT 67h) so that no driver need be loaded. (I understand this is a pie-in-the-sky project, however, since it would be of limited audience.)

If you'd like to write your own driver for a swap partition, I certainly won't stop you, but the driver should advertise itself as only 3.2 and only support the EMS 3.2 specification. You will find a lot of software (disk caches, desqview, Windows) won't work with 3.2. Less demanding applications (ramdisks, Lotus 1-2-3, Turbo Pascal) will work ok, although the sanity of using a swap partition as a "ramdisk" is questionable :)
 
It seems to me most the clever stuff is in the Int.67 code - the hardware itself only needs to provide a 64KB access segment split into four 16KB windows? That should be doable - but the Int67h code (or BIOS extension) is beyond my skill.
 
Got your back pearce, you design a board and I'll have a crack at the BIOS Extension stuff...

Is it split into 4x16K? Haven't read the LIM spec fully yet, I'll get around to it soon...Been a bit busy...

I have to admit that I don't have more then Photoshop for designing Layers for PCBs...

While I do have some freebies off the net that I'm evaluating, because AutoCAD Electrical 2014 is about $6500 beyond my budget at the moment, I need to investigate which product I want to spend my money on.

It has been about 18 years since I have designed a circuit board, on good old 2 bit monochrome paper, and back then 5V TTL was all the rage, not this new fangled 1.2V stuff that's appearing...

Anyway, I am a software engineer, have been for the last 18 years...Systems Analysis and Design is my hobby too, I apply that to the Electronics Tech stuff I learned at college, before the bachelors degree stuff started.
 
I've been using CadSoft Eagle 6 - see here.

The EMS board I'm working on currently has 8-bit registers at 260h, 261h, 262h and 263h. It would work by loading these registers with the 16KB page number required, or more specifically the high 8-bits of the 22-bit physical address space on the card itself, providing 4MB total address space (being 256 pages of 16KB).

The RAM is then presented though a 64KB page frame at either D000h or E000h (the base address) in four 16KB windows. Accessing base+0h uses the contents of register at 260h as the high 8-bits and the ISA address bus low 14-bits to form a 22-bit physical address, base+400h the second register, base+800h the 3rd, and base+C00h the 4th. Hopefully my understanding of this is correct.

The board itself I'm currently implementing with 4x 512KB SRAMs giving 2MB total. The free version of Eagle is restricted to 100x100 PCB size, but this is no bad thing since PCBs of this size are very cost effective from SeeedStudio. I'm struggling with the trace routing but hopefully it can all fit on, though a full 4MB implementation I think is out (at least, with my limited skills).

Schematic here.
 
I haven't been following this thread, but I do have a question: Why a BIOS extension for INT 67H? None of my EMS boards use that--they all use loadable drivers.
 
I guess it's just convenience and maximising lower memory (given we're on the subject) - appeals to me, since my systems typically have 24KB ROM space, but I guess it wouldn't make much difference to run with a driver - especially in the development phase.
 
I suggested a BIOS extension for Int 67h because it would mean no drivers to load/lose. The idea isn't mine; I learned it from my Dell 386sx, which has EMS emulation in ROM, selectable from the BIOS setup screen. You can either turn it off completely for a "normal" 386, or you can turn it on and select how much RAM you want to dedicate as EMS. It's convenient.
 
I guess--I prefer the loadable driver because that allows me to have several menu-driven DOS startup choices (e.g. plain, EMS, networking, special device drivers, etc.), but whatever tickles your fancy. EMS drivers aren't difficult, but you do have to be careful when you perform memory-to-memory moves to treat overlapping moves correctly.
 
Trixter explained later - DesqView extensively used the mapping functions to achieve multitasking, so it would be very slow if instead of a register update to change tasks - taking microseconds - it took something like 200ms to perform a page to & from disk.
 
Chuck(G) said:
EMS drivers aren't difficult, but you do have to be careful when you perform memory-to-memory moves to treat overlapping moves correctly.
Click to expand...

I would hope there would be very little moving of memory at all, except to/from the pages themselves.

One thing that bugs me is the perception that EMS is slower or worse than XMS, as if it is conveniently forgotten that XMS is a block copying protocol. To use XMS you must copy a block in or out of the lower 640k. EMS however is a hardware memory page/window scheme -- if you need data from a page, issue a command and POOF it is there, in the frame, waiting for you to read it. No copying required.

I suppose on 386s and higher there is probably a way to accelerate XMS copying in 4K chunks/boundaries by simply remapping memory, but I never saw XMS drivers do this (when you load HIMEM.SYS, system stays in real mode). Maybe QEMM or others did, but I never benchmarked them.
 
LIM 4.0 function 24 is the memory move/exchange function. It's possible to use LIM 4.0 EMS without a page frame, like XMS.

Code: 
     FUNCTION 24   MOVE/EXCHANGE MEMORY REGION

          MOVE MEMORY REGION SUBFUNCTION

          PURPOSE

          This subfunction copies a region of memory in the following memory
          source/destination combinations.

          o   conventional memory to conventional memory

          o   conventional memory to expanded memory

          o   expanded memory to conventional memory

          o   expanded memory to expanded memory

          You do not have to save and restore the expanded memory mapping
          context to perform these move operations.  The current mapping context
          is maintained throughout this operation.

          The length of the region is limited by the amount of expanded memory
          allocated to the handles specified.

          However, in most practical applications, the region length will be
          considerably smaller.  A region length of zero is not an error, and no
          move will be performed.

          A region length which exceeds 16K bytes is not an error.  In this case
          the function assumes that a group of logical pages is the target for
          the move.  The logical page specified represents the first logical
          page in which the move will take place.  If the region length exceeds
          16K bytes, or if the region is less than 16K bytes but spans logical
          pages, there must be sufficient logical pages remaining after the
          first logical page for the entire region to fit.

          If your application needs to save a region of conventional memory in
          expanded memory, you can move it without having to perform a save or
          restore of the current mapping context.

          The memory manager maintains the context.  A move of up to 1M byte may
          be performed, although practical lengths are substantially less than
          this value.

          If the source and destination handles are identical, the source and
          destination regions are tested for overlap before the move.  If they
          overlap, the move direction is chosen so that the destination region
          receives an intact copy of the source region.  A status will be
          returned indicating that this overlap has occurred.
 
You must log in or register to reply here.
Back
Top