it's happening

That C1 should be somewhere in bottom instead where it would actually be useful, rest seems to be quite nice ~

Tiido wrote:

That C1 should be somewhere in bottom instead where it would actually be useful, rest seems to be quite nice ~

probably best I could do with it would be to shove it in that island between the address comparator and the 02/05 gates

I kinda figured that being tied to both the power and ground planes anywhere on the card would have a short enough electrical distance to be effective, but I can move it if you really think it would help

Hi maxtherabbit,

Can you completely explain how this special card solution can solve this issues to fix the EMS and adaptec scsi card conflict?

Cheers,

pentiumspeed wrote:

Hi maxtherabbit,

Can you completely explain how this special card solution can solve this issues to fix the EMS and adaptec scsi card conflict?

Cheers,

Ok sure let's start with the basic facts:

1) 154x Adaptec cards do bus mastered DMA transfers
2) it is documented that when doing so, they assume all memory space to be 16-bit, EXCEPT for the A and B segments of UMA used for video RAM
3) the SCSI card's BIOS can be mapped into the C or D segments of UMA with jumpers on the card, and is physically 8-bits wide
4) ISA cards that assert MEMCS16# based on the early address information available on the latchable address lines LA[17:23] can only qualify 16-bit access on 128kB boundaries because of the limited address precision of the LA lines

Now let's look at the facts that are specific to my individual setup:

1) the Lo-Tech card is physically 8-bit
2) the Intel Above board appears to only offer 8-bit access to its EMS page frame despite being a 16-bit card. Exact reason for this is unknown, but I theorize it was a design shortcut to make backwards compatibility with 8-bit PC/XT buses easier to implement
3) the AST Rampage+ 286 Card offers 8-bit access to its EMS page frame by default, but through a driver switch, can be forced to provide 16-bit access - with the limitation of only being able to quality this access assertion on 128kB boundaries due to its logic being based on early address information of LA[17-23] (this is due in part or in whole to it offering a zero-wait memory option, which needs the extra time afforded by early address decoding)
4) because my motherboard maps ROM BIOS to both the E and F segments of UMA, I have only the C and D segments available to work with option ROMs and my EMS page frame

All three EMS cards could be made to work with the Adaptec 154x SCSI cards by employing a double-buffering driver like SCSIHA.SYS or SMARTDRV with double buffering enabled. These solutions did not satisfy me as they are not performant and/or consume excessive conventional memory. Therefore, the only configuration that would allow me to retain the performance of bus mastered SCSI DMA, and have true 16-bit EMS access was to use the AST card with the driver switch set to force the C and D segments to 16-bit.

This is where the ROM card I've designed comes into play. Because of the previously described limitations of the AST card, when I activate the driver switch to allow 16-bit access to my EMS page frame, it will assert MEMCS16# for ALL accesses to memory in the C or D segments of UMA. Since this is also where my SCSI BIOS resides, and the SCSI BIOS is physically 8-bit, it breaks my disk access. The only way out of that mess is to relocate the SCSI ROM off of the adapter itself, onto another device which can give it a 16-bit bus.

Since this was such a terribly specific application, I decided to design a general purpose ISA ROM card that could work in both 8 and 16-bit modes, and also be backwards compatible with a PC/XT 8-bit bus. So I can use my design to solve this specific problem, as well as have other ROM cards for a variety of different uses. Adding support for zero-wait using modern high speed EPROMS was another feature I threw in to distinguish this design from previously available ROM cards on the market.

PS: The Lo-tech got rehomed and is doing quite well in my 5150 PC now, and the Above board got sold to a buddy who is running it in a PS/2 286

Very good project thinking, I almost understood you regarding these till now all in one post, was missing or scattered across posts. Thank you.

Have you occurred to you that you could shadow the scsi bios firmware onto this memory range with a software shadowing utility, does not consume any once finished instead? Like mother board does. Some cards has advanced firmware that does that too during POST initialization.

I knew about DMA busmaster very well as it made my scanner and I had a ESDI with busmaster feature work really nice on old computers. I really like scsi setup as well as this simplify resources on the computer's instead of many resources that IDE ports (especially more than 2 ports).

int13 is dumb dumb for sure and slow until decent hard drive controller come on it's own especially DMA busmastering and shadowing the firmware of any cards it's finds. A better motherboard bios even has a settings to copy any cards's bios into memory (shadowing).

I even went straight to 386DX board long ago, for this reason due to 286's bug that needs keyboard controller to bring 286 out of protected mode and performance reasons. Also better bios are available too. Late 386DX motherboard would be better option.

Cheers, pentiumspeed

My chipset does not offer any shadow RAM support whatsoever. Loading the ASPI4DOS.SYS Adaptec driver does hook INT13 and provide most basic disk services, but it does not shadow the entire ROM - just about any "system information" or diagnostic software will still crash the system. Additionally, ASPI4DOS seems to have issues with disks larger than 8GB and it consumes a good bit of conventional memory.

I could in theory write my own TSR that shadows the entire ROM, but that's well outside my skillset and again would be a memory hog

To verify your theory you can take a 386/486 ISA PC/AT motherboard with at least of 2M of RAM on board (enough for this task), plug your "precious only to you" SCSI card, plug an ISA EMS card and run QEMM386 with its EMS subsystem disabled and with activated shadowing of your SCSI card BIOS. After QEMM is loaded in config.sys load/run your hardware EMS card's driver and other drivers/utilities for the SCSI. Second approach -- if your motherboard's BIOS (I remember colorful AMI to be able to do this) and chipset support "native" shadowing of BIOS extensions use that feature and do the test without the help of QEMM.

Personally don't understand what the big deal with EMS on a 286 really is about.Most 286s are quite cable of using XMS which is better in the first place.

georgel wrote:

To verify your theory you can take a 386/486 ISA PC/AT motherboard with at least of 2M of RAM on board (enough for this task), plug your "precious only to you" SCSI card, plug an ISA EMS card and run QEMM386 with its EMS subsystem disabled and with activated shadowing of your SCSI card BIOS. After QEMM is loaded in config.sys load/run your hardware EMS card's driver and other drivers/utilities for the SCSI. Second approach -- if your motherboard's BIOS (I remember colorful AMI to be able to do this) and chipset support "native" shadowing of BIOS extensions use that feature and do the test without the help of QEMM.

I have ample enough confidence based on my existing testing. The board is already designed, so it's off to the races.

Caluser2000 wrote:

Personally don't understand what the big deal with EMS on a 286 really is about.Most 286s are quite cable of using XMS which is better in the first place.

I can and do use XMS on this machine, in fact I have the AST card configured to provide both.

I disagree with XMS being "better" however. In real mode DOS, in order to use XMS it must first be copied to/from conventional on every single access. EMS is directly written/read from the page frame with nothing more than a concomitant I/O port write

she's in production now!

I also don't understand the need for EMS on a 286 or later machine.

If you *really* want to use EMS, why not just use some memory manager to emulate EMS with XMS?

Boards with XMS support and expansion cards to add XMS are considerably easier to find nowadays than EMS. EMS was designed for PCs and XTs with a 20 bit address space in mind.

I can allocate EMS from my 286s bios.

FAMICOMASTER wrote:

I also don't understand the need for EMS on a 286 or later machine.

If you *really* want to use EMS, why not just use some memory manager to emulate EMS with XMS?

Boards with XMS support and expansion cards to add XMS are considerably easier to find nowadays than EMS. EMS was designed for PCs and XTs with a 20 bit address space in mind.

The EMS memory cannot be emulated only in software without the help of an external chipset logic on 286 because this CPU lacks the paging unit available on 386 and later CPUs. The EMS was a huge benefit for real mode software widely spread before the 386 era. The problem here is the topic starter is in love with his buggy and meaningless for PC world early adaptec SCSI controller card that he insists of using. He could have verified his doubtful theory before producing untested and "complicated" ROM shadowing card on some of the widespread motherboards that have such ROM shadowing support built-in into their chipsets and controlled via their CMOS Setups.

FAMICOMASTER wrote:

I also don't understand the need for EMS on a 286 or later machine.

If you *really* want to use EMS, why not just use some memory manager to emulate EMS with XMS?

Boards with XMS support and expansion cards to add XMS are considerably easier to find nowadays than EMS. EMS was designed for PCs and XTs with a 20 bit address space in mind.

Okay, since you basically asked for it..:
Because this is about getting support for "real" EMS, the way as it was intended originally. 😀
Despite popular believe, EMS is not a 386+ thing. It never has been.
EMS was a bank-switching design (a 70s tech ?) made for the original IBM PC line.

It wasn't until the late 80s/early 90s that EMS became associated with EMM386,
which emulated it's functionality by using the paging-capable MMU that's internal to the 386 processor.

Real EMS usually is located on a separate piece of hardware, even on 286es it's semi-external as a part of the chipset.
One of the biggest benefits is that EMS boards do not require the help of EMM386, or more prececisely, V86.
The latter causes compatibility issues, as well as a performance hit on 386es and early 486es not having the VME extension.
(Fun fact: EMM386 is a form of mini-OS on by itself, a bit like a hypervisor/supervisor program, which intercepts and monitors many things.)

Another ability that EMS boards have/had over things like EMM286 and other LIMulators:
They often support "Alternate/DMA Register Sets (Function 28)", "Data aliasing to multiple physical pages", backfilling, EEMS, Large-Frame EMS
and last, but not least, don't require Himem.sys. 😉

Edit: Seems georgel was quicker. 😊
Anyway, there's something I should probably mention. There are references to external MMUs for 286 PCs in PC-MOS/386 documentation.
Perhaps, long, long time ago (in a galaxy far, far away ?) there was auxilary circuitry that allowed the 286 processor to do paging.

Edit: Another thing. EMS boards are apparently compatible with extender games, too.
- I once tested my AST Rampage 286 with Lollypop (32-Bit or Flat-Mode ?) and the game ran smooth as silk.

Jo22 wrote:

Real EMS usually is located on a separate piece of hardware, even on 286es it's semi-external as a part of the chipset. One of t […]
Show full quote

Real EMS usually is located on a separate piece of hardware, even on 286es it's semi-external as a part of the chipset.
One of the biggest benefits is that EMS boards do not require the help of EMM386, or more prececisely, V86.
The latter causes compatibility issues, as well as a performance hit on 386es and early 486es not having the VME extension.
.....

Another ability that EMS boards have/had over things like EMM286 and other LIMulators:
They often support "Alternate/DMA Register Sets (Function 28)", "Data aliasing to multiple physical pages", backfilling, EEMS, Large-Frame EMS
and last, but not least, don't require Himem.sys. 😉

...
Anyway, there's something I should probably mention. There are references to external MMUs for 286 PCs in PC-MOS/386 documentation.
Perhaps, long, long time ago (in a galaxy far, far away ?) there was auxilary circuitry that allowed the 286 processor to do paging.

Edit: Another thing. EMS boards are apparently compatible with extender games, too.
- I once tested my AST Rampage 286 with Lollypop (32-Bit or Flat-Mode ?) and the game ran smooth as silk.

There is no such thing as "Real EMS". Its a software API and that's all. It is called LIM EMS standard. The software that uses EMS does not care how it is realized in hardware. Either is is fully provided or not (like with disk emulated EMS memory).

The 386 expanded memory managers cause compatibility issues only if they have more bugs, and performance penalty is practically near 0. But advantages were significant. The ability to run DOS multitasking with DESQView was great. The ability to run older software with increased amount of RAM and speed was great. There was no longer need to spend money for old 16-bit EMS boards that were priced as a 386 motherboard itself! Use QEMM or 386MAX to have better performance and compatibility. As far as I remember EMM386 appeared later than QEMM & 386MAX. Actually QEMM improves performance on most occasions and its EMS handler is faster that most of the 286 "real EMS" drivers. I know of no application software that is slowed down by a 386 DOS memory manager!

The EMS hardware is the same as or form of an "external MMU".

It is up to the DOS extenders (which to your surprise had been used long before it appeared as royalty free stub in games with serious CAD/CAM/CAE software) to utilize all PC resources. EMS is one of them. This is not related to the "real" EMS boards at all and with the same success they would have used the EMS memory provided by a 386 memory manager had it been the only way to allocate the same physical memory.

georgel wrote:

There is no such thing as "Real EMS".

Pffft, semantics.
Clearly Jo22 meant hardware EMS solutions, as opposed to software emulation with EMM386 or similar solutions.

georgel wrote:

The software that uses EMS does not care how it is realized in hardware.

The user of that software might. On 286 and low-end 386 machines, hardware EMS solutions tend to perform considerably better than software emulation.

georgel wrote:

and performance penalty is practically near 0.

Incorrect. Performance penalty is considerable.
I had a 386SX-16 machine with NEAT chipset, which had EMS support.
The difference between using the NEAT chipset and using EMM386 was night and day.
I especially recall a huge difference with Falcon 3.0.

No way. How did you measure that EMS performance on your 386? Which application was slowed down like "night and day"? On 286 there is no such thing as software EMS emulation unless it is partial and crippled!

georgel wrote:

No way. How did you measure that EMS performance?

I explained how: by running Falcon 3.0.
It was especially obvious with the animations it played.
With real EMS, it would just store each frame in a separate EMS frame, and copy the data to VRAM.
When using EMM386, it would have to copy the memory from XMS into the EMS frame first, and then the additional copy to VRAM.
That overhead completely messed up the animation playback, turning it into a slideshow.

Sure, throw enough horsepower at it, and even with EMM386 it works again... but a 386SX-16 was not enough horsepower, ergo performance penalty was far from 0.