PDA

View Full Version : ISA 8 Bit 8MB Extended Memory Card



RubberTelly
September 23rd, 2013, 08:34 AM
Here's a chip;
http://www.cypress.com/?mpn=CY62187EV30LL-55BAXI

Let's fry it up and see how it tastes.:-)

4Mb x 16 SRAM Memory Module...plus a few logic circuits and you have an 8bit ISA Memory Card, yay...

Al Kossow
September 23rd, 2013, 08:37 AM
Let's fry it up

That's exactly what you'll do if you ignore the 3.3V VMax rating.

pearce_jj
September 23rd, 2013, 08:55 AM
16-bit ISA do you mean? Or an 8-bit EMS board?

RubberTelly
September 23rd, 2013, 09:10 AM
8 bit ISA can address that much memory, if you select either high or low 8bits of the 16bit output...

NobodyIsHere
September 23rd, 2013, 09:20 AM
Really? BGA-48?

Let me know how that works out for you.

Andrew Lynch

RubberTelly
September 23rd, 2013, 09:24 AM
Yeah, some sort of holder would be nice...

RubberTelly
September 23rd, 2013, 11:22 AM
TI make not only BGA to pin converter but this;

http://www.ti.com/product/sn74avc24t245

A Bidirectional 3.3V to 5V address bus converter...

pearce_jj
September 23rd, 2013, 01:12 PM
8 bit ISA can address that much memory, if you select either high or low 8bits of the 16bit output...

What exactly are we suggesting here - an EMS board presumably? Does anyone have the LIM specifications?

nestor
September 23rd, 2013, 01:58 PM
The LIM 4.0 specification is here: http://www.phatcode.net/res/218/files/limems40.txt

RubberTelly
September 24th, 2013, 07:40 AM
I was thinking more of a Protected Mode Extended Memory Card...EMS would require a Micro Controller or PSOC subsystem...Doable though...

NobodyIsHere
September 24th, 2013, 08:05 AM
Hi

You realize the 8 bit ISA slot has only 20 address lines (A0-A19). That means a maximum of 1MB of directly accessible memory on an 8 bit ISA board -- less depending what is on the motherboard typically 256K to 1MB.

LIM might be able to have more memory but requires some sort of bank switching scheme and/or controller. A 16 bit ISA board could have as much as 16MB directly addressable memory but those are common boards.

Andrew Lynch

RubberTelly
September 24th, 2013, 08:22 AM
Oh crud...LIM EMS it is...I'll need to investigate PSOCs further....64K window mapped to main memory...386 does this inherently while the 286 needs a driver written...

Looks like I'm in for a fun time...Yay...

pearce_jj
September 24th, 2013, 01:06 PM
I put together a 1MB 8-bit RAM board based on AS6C4008 SRAM chips (http://www.alliancememory.com/pdf/AS6C4008.pdf). Board features:


Full 1MB RAM on an 8-bit ISA card
Each physical 64KB page is separately switched
Jumper to disable first 16KB, enabling maximum RAM expansion on a 5150 with 16KB onboard.


Schematic here (http://www.lo-tech.co.uk/downloads/temp/lo-tech-1mb-ram-board.zip).

RubberTelly
September 25th, 2013, 01:38 AM
Nice one pearce...What Design program do you use?

pearce_jj
September 25th, 2013, 03:51 AM
Thanks, it's CADsoft Eagle PCB Designer.

Trixter
September 25th, 2013, 06:43 AM
I put together a 1MB 8-bit RAM board based on AS6C4008 SRAM chips (http://www.alliancememory.com/pdf/AS6C4008.pdf). Board features:


Full 1MB RAM on an 8-bit ISA card
Each physical 64KB page is separately switched
Jumper to disable first 16KB, enabling maximum RAM expansion on a 5150 with 16KB onboard.


Schematic here (http://www.lo-tech.co.uk/downloads/temp/lo-tech-1mb-ram-board.zip).

Did you ever make a page on your wiki for this board?

If the RAM is SRAM, I wonder if there is a way to dramatically shorten the DMA dram refresh routine for just the first 16k -- would result in a slight speedup. (just thinking out loud, not actually going to try it)

pearce_jj
September 25th, 2013, 10:02 AM
Did you ever make a page on your wiki for this board?

Not yet - only started this a couple of days ago :) If there is interest I'll take it forward.


If the RAM is SRAM, I wonder if there is a way to dramatically shorten the DMA dram refresh routine for just the first 16k

I wondered this too but is seems it's not possible - the DMA controller needs to visit 128 consecutive rows in 2ms, which the 66kHz refresh clock provides nearly exactly. You could though pull all the RAM logic from the system board, then re-gain DMA channel 0 too I guess.

RubberTelly
September 25th, 2013, 10:14 AM
BGA to Anything
http://www.advanced.com/

RubberTelly
September 25th, 2013, 10:31 AM
Not yet - only started this a couple of days ago :) If there is interest I'll take it forward.

SRAM is always interesting...DRAM sucks...

RubberTelly
September 25th, 2013, 10:37 AM
Anyway, I'm going to make a parts list;
5V to 3.3V Bi-Directional Logic Converter (Maybe 2) - TI

4Mb x 8 Memory SRAM - Cypress
or
4Mb x 16 Memory SRAM - Cypress

PSoC for Advanced Page Selection Algorithms (Maybe)

and a few other ICs

pearce_jj
September 25th, 2013, 12:47 PM
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.

pearce_jj
September 25th, 2013, 10:06 PM
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.

Trixter
September 25th, 2013, 10:20 PM
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.

pearce_jj
September 25th, 2013, 10:32 PM
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)?

RubberTelly
September 26th, 2013, 01:39 AM
Ok...after much Coffees

The MAX3002 looks like a good candidate for Bi-Directional 3.3V to 5V Logics...
http://www.maximintegrated.com/datasheet/index.mvp/id/3672

It has a 20ns prop time...

RubberTelly
September 26th, 2013, 01:42 AM
I also thought of High Speed Drive swapping...but then I do go to some strange parties...;-)

Trixter
September 26th, 2013, 08:00 AM
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)?

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 :-)

pearce_jj
September 26th, 2013, 09:32 AM
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.

RubberTelly
September 27th, 2013, 07:35 AM
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.

pearce_jj
September 27th, 2013, 10:45 AM
I've been using CadSoft Eagle 6 - see here (http://www.cadsoftusa.com/eagle-pcb-design-software/product-overview/?language=en).

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 (http://www.lo-tech.co.uk/downloads/temp/xt-ems-r1-schematic-001.png).

Chuck(G)
September 27th, 2013, 10:57 AM
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.

pearce_jj
September 27th, 2013, 12:04 PM
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.

Trixter
September 27th, 2013, 12:06 PM
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.

Chuck(G)
September 27th, 2013, 12:58 PM
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.

cr1901
September 27th, 2013, 01:12 PM
And also obviously, you can't use emulated EMS for things like Desqview.

I must be having a bad day, because this isn't obvious to me :(...

pearce_jj
September 28th, 2013, 02:32 AM
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.

RubberTelly
September 28th, 2013, 07:55 AM
Ok, I'll work on a TSR to handle the Basic LIM stuff...

My Friendly TSR C++ code as an Open Watcom project zipped.
FTSR.zip (http://www.rtmedia.net.au/zips/FTSR.zip) - 858B

RubberTelly
September 29th, 2013, 01:25 PM
Are we sure the LIM specs are 4x16K and not 1x64K window addressed as 32bit memory, 16bit segment(Emulated) and 16bit lower address?

Trixter
September 29th, 2013, 10:22 PM
EMS drivers aren't difficult, but you do have to be careful when you perform memory-to-memory moves to treat overlapping moves correctly.

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.

Plasma
September 30th, 2013, 09:36 AM
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.


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.

Chuck(G)
September 30th, 2013, 09:42 AM
Thanks, Plasma--that's what I was talking about. Regardless of mapping functions, there are times (quite often) when you need to move from EMS to conventional memory and vice-versa.

Comparing this to XMS isn't qute the same thing--we're talking about an 8-bit LIM card here. You'd need your head examined if you opted for an 8-bit ISA card on a 286 or better system. I suspect this 8-bit card is intended for 808x systems.

pearce_jj
September 30th, 2013, 01:33 PM
Progress report on my PCB - just 30 wires left to route :)

RubberTelly
September 30th, 2013, 11:46 PM
Ok, according to Wiki...it's Multiples of 16KB mapped to lower memory above 640K, e.g. 1 x 64KB as a window is possible, I believe...

RubberTelly
October 1st, 2013, 12:29 AM
Is this chip any help;
http://www.maximintegrated.com/datasheet/index.mvp/id/3672

It's a bi directional voltage level translator that has a 20ns propagation time, I posted it to another thread, to convert between 1.2-3.6V CMOS and 5V TTL.

pearce_jj
October 1st, 2013, 02:11 AM
Thanks, level shifting isn't the problem, rather the packages. I've gone with SOIC as these are pretty easy to handle - quicker that DIP, once you've done a few :-)

The layout is nearly finished. I'll post an image in the next day or too.

4x 16KB registers can be used by the ISR as 1x 64KB if desired ;-)

pearce_jj
October 1st, 2013, 12:38 PM
PCB layout is done. To recap, this board uses up to 4 of 512KB SRAM chips to provide up to 2MB of EMS. It has four page registers providing four 16KB windows within a 64KB page frame.

http://www.lo-tech.co.uk/downloads/temp/xt-ems-r1-pcb-001.png

evildragon
October 1st, 2013, 01:42 PM
Something like this would slow down my model 25 though, wouldn't it? Since my model 25 addresses it's conventional RAM as 16-bit, not 8-bit.

pearce_jj
October 1st, 2013, 09:54 PM
8-bit cards always run at ~5MHz too, unless they assert B8 and the machine supports ZWS. This board is designed for XT class hardware.

Trixter
October 2nd, 2013, 07:04 AM
PCB layout is done. To recap, this board uses up to 4 of 512KB SRAM chips to provide up to 2MB of EMS. It has four page registers providing four 16KB windows within a 64KB page frame.

While I'm happy to see this, is there any chance it can be designed with something larger, like 8MB or the full 32MB? 2MB is only useful for applications; with 16 or more, a large disk cache could make a real dent in hard disk access times.

pearce_jj
October 2nd, 2013, 07:46 AM
I went with the biggest RAM chips in SOIC I could find that were sensible money (about 2 each). SRAM helps keep things simple, too as obviously no need to worry about refresh. I guess you're thinking about old MFM drives - with CompactFlash, very much the limiting factor is the REP MOVSW throughput of the 8088 anyway.

So really the answer is maybe, if someone can find some bigger SRAMs :-)

To add - retrieving data from CompactFlash with my V3 adapter via DMA, on an 8088, will be *faster* than retrieving from EMS via REP MOVSW, and we save the cache lookup. I've been pondering on the idea of implementing the same logic - and hence CPLD implementation - for an EMS board, but I wonder whether many (any?) apps use function 24h and how much difference it would make (locality of reference and all that). Plus that also ties us to a very non-existent supply of 5V CPLDs.

There are some 8Mb SRAMs available, but they all seem to be TSOP packages, which are very small and likely to put off many assemblers (even the SOIC stuff I think is pushing things).

pearce_jj
October 2nd, 2013, 12:49 PM
Just a thought - the design is actually 4MB already, but there's only space for 4x 512KB SRAMs on the board. The 100x100 size limit is imposed by the free Eagle software, and also provides very significant cost advantage for manufacturing.

But, I could split the board into two parts: the address decode and latches, and the a daughter board for the SRAMs. This will enable the full 4MB, but obviously then requires assemblers to make two PCBs even if they only wanted 512KB EMS. Going beyond 4MB means moving to 16-bit latches which makes everything much more complicated, unless we go the CPLD route (or some uController).

Trixter
October 2nd, 2013, 12:55 PM
If it significantly increases the complexity or cost of the board, by all means, feel free to ignore me :-) I just threw it out there in case it was easy to do. I have since been corrected.

pearce_jj
October 2nd, 2013, 01:23 PM
I'll do the layout, then see what we think :)

xprt
October 2nd, 2013, 02:56 PM
So piggy-back the RAM chips. :)

Interesting Micron and IBM among others are trying to stack up RAM chips at the die level:

http://www.theverge.com/2011/12/7/2616348/3d-dram-ibm-micron-128-gbps

http://hybridmemorycube.org/

eeguru
October 2nd, 2013, 03:50 PM
I've kicked around a larger design. I just don't have anytime to work on vintage projects atm - sorry. My day job keeps me pretty busy - which is now turning into a night job and weekend job it seems as well.

https://upverter.com/eeguru/1461fe95496bdc02/ISA-RAMROM-Expansion-Board/

I've used the same memory routing and footprint before with a modified Lattice SDRAM controller design. It works up to about 60 MHz but performs a full burst transfer for every WB access - no caching. All the ISA lines for both 8 and 16 bit operation are present so even though it's a 16-bit card, it could would work in an 8-bit slot assuming there's clearance for the overhang. The intent would be to configure the 8/16 bit mode flag, conventional fill areas, XMS starting (fill) address, and EMS window size and location through an IO port discovered through PnP. The dip switch would to just active the PnP config mode only incase the configured settings were not compatible with the machine it was in. There also plenty of capacity in the PLD for a small MCU to perform shadow loads of option ROMs into mapped RAM on boot and to facilitate fast page to page copies per the LIM spec. 64MB RAM and 64MB flash offer some interesting possibilities like a flash backed RAM disk auto-loaded on start-up. There wasn't enough pins for DMA signals so fast transfers to the host would need to be memory window mapped and rep movsw'd. I had planned to hold the first ISA bus access hostage with a arbitrarily long wait cycle until the startup load from flash was complete - so there would be plenty of time for option ROM loading. The PLD is loaded from internal flash but it also supports keeping a golden image on the external flash for guarantee'd fail-safe updates.

I suppose an 8-bit version could be made with maybe an RTC to go with it. However everyone I've talked to about it always points out the limited demand for ISA memory cards. So I'm surprised to see this thread. The design is on upverter so anyone can run with it. I might get back to it during Christmas time frame assuming work settles down like I expect.

I would recommend changing the design proposed above to through hole if you are just using SRAMs. Would make it hobby friendly.

Chuck(G)
October 2nd, 2013, 03:58 PM
How about an Alliance AS6C8008 (1Mx8 SRAM)? Looks to be TSOP-44 (still easy to solder) and in stock at Mouser.

Just thinking...

pearce_jj
October 3rd, 2013, 09:17 AM
0.8mm pitch I think many will find daunting. But, by moving to a daughter-board arrangement, that option would be easy to provide.

That said, Alan's board is so very far ahead, seems things have moved on :)

eeguru
October 3rd, 2013, 09:23 AM
No, I have no time to work on it. Any solution that can be here soon is better than mine. At some point, I'll get to it. When and if I do, great. But your hard work is still the most valuable to everyone else.

pearce_jj
October 5th, 2013, 12:22 PM
Well, this is the idea. The ISA board itself has the address decode logic and the four window registers, but no memory of any kind. Instead, a 40-pin header:

http://www.lo-tech.co.uk/downloads/temp/4MB-EMS-Board.png

Then, a memory module can be connected to that header - meaning that each time the SRAMs go end of life, we only need spin up a new memory module. The ISA slot board itself is just plain old 7400 series ICs so should be pretty easy to source (SOIC) components for. For now, I've laid out a board that can be populated with 1-8 512KB modules, so providing up to 4MB:

http://www.lo-tech.co.uk/downloads/temp/4MB-EMS-RAM-Module.png

The driver (/BIOS) will be able to determine the memory installed by simply testing a write-then-read from the first byte of each 512KB physical region within the EMS memory space, the pull-up network ensuring FFh will be returned if no memory chip is present.

These PCB layouts are essentially complete so just need a bit of peer review, and to confirm Seeed can actually do 0.3mm vias, and we'd be good-to-go.

pearce_jj
October 14th, 2013, 10:16 PM
I guess the enthusiasm for this board has fizzled out, with the capacity limitations inherent in my design. But for the sake of clarity, is anyone actually working on EMS driver code for it?