kjliew wrote:

Have you tried using just SMARTDRV but having it load to both functional as double buffering and disk cache?
The DEVICE=SMARTDRV.EXE /DOUBLE_BUFFER+ in CONFIG.SYS for double buffering and either in AUTOEXEC.BAT or at the prompt just load SMARTDRV. The default should use 2MB XMS memory for disk cache, and it can cache both read and write. Use SMARTDRV /S to show the status and you should have all 3 (read cache/write cache/buffering) "Yes" for drive C: The disk cache in theory should somehow restore the disk performance caused by double buffering.

I have and it doesn't perform well. In fact, just running SMARTDRV from the command prompt without even using double buffering actually hurts my I/O performance. Guess the SCSI bus is faster than the CPU 🤣

I think I'm going to pull the plug on trying to make the Adaptec card work with 8-bit DMA targets. It's really starting to feel like square plug/round hole. I sold the Above Board to a buddy of mine and I'm gonna repurpose the Lo-Tech in an IBM 5150 I have.

I may revisit EMS on this 286 system in the form of another 16-bit memory card if a deal on one presents itself. Thanks again to you guys for helping me solve the mystery!

So I did revisit EMS on this system - got a deal on an AST Rampage Plus 286 that has 8 30-pin SIMM slots on it. And what do you know - when I set up EMS with the included driver I once again can only perform 8-bit writes to the page frame. There's got to be something about either my chipset or hardware configuration that is limiting the C and/or D segments to 8-bit access. Or perhaps EMS only allows 8-bit access by design?

I'm officially giving up on EMS with this AT, but the Rampage Plus still worked out - it allowed me to assign all 8MB of RAM on the card to extended and set 0 wait states, so I have a 12MB 286 now 🤣

AST Rampage Plus 286 that has 8 30-pin SIMM slots on it. And what do you know - when I set up EMS with the included driver I once again can only perform 8-bit writes to the page frame.

I don't know for sure, but at least my AST Rampage came with an outdated device driver (more precisely, it came without anything. I used the driver that's included with Windows 2.x).
Using a more recent driver from the net provided LIM 4 and better compatibility with games and stuff. 😀

maxtherabbit wrote:

Or perhaps EMS only allows 8-bit access by design?

I don't think it does.
I had a 386SX-16 with NEAT chipset, that had EMS onboard, and that worked fine with 16-bit access afaik.
Would make sense anyway, since EMS is a very lowlevel interface... You just get a base segment, and you address that. All the EMS controller has to do is translate the address from the address bus to the currently active window. I see no reason why that couldn't work in both 8-bit and 16-bit mode.

The EMS should work with arbitrary RAM access (8,16,32,64,80 bit, etc.). It is just a RAM that is mapped to desired regions. I would recommend QEMMs Manifest (MFT) as a tool for troubleshooting OP's issue.

Scali wrote:

I don't think it does. I had a 386SX-16 with NEAT chipset, that had EMS onboard, and that worked fine with 16-bit access afaik. […]
Show full quote

maxtherabbit wrote:

Or perhaps EMS only allows 8-bit access by design?

I don't think it does.
I had a 386SX-16 with NEAT chipset, that had EMS onboard, and that worked fine with 16-bit access afaik.
Would make sense anyway, since EMS is a very lowlevel interface... You just get a base segment, and you address that. All the EMS controller has to do is translate the address from the address bus to the currently active window. I see no reason why that couldn't work in both 8-bit and 16-bit mode.

Yeah, I'm struggling to conceive of a scenario where it makes sense. But the fact remains I have 2 different 16-bit hardware EMS cards which are only updating the low byte when the Adaptec card tries to write words into the page frame. I'd love to figure out why, it seems unlikely that two different designs from two different manufacturers would both arbitrarily limit access to expanded memory on their cards to 8-bit.

It was more believable with the Above Board since it is backwards compatible with 8-bit buses, but the Rampage Plus 286 is not AFAIK

Jo22 wrote:

AST Rampage Plus 286 that has 8 30-pin SIMM slots on it. And what do you know - when I set up EMS with the included driver I once again can only perform 8-bit writes to the page frame.

I don't know for sure, but at least my AST Rampage came with an outdated device driver (more precisely, it came without anything. I used the driver that's included with Windows 2.x).
Using a more recent driver from the net provided LIM 4 and better compatibility with games and stuff. 😀

I'm using the driver package from minuszerodegrees.net (FASTDISK.ZIP)

Do you mean CPU writes or DMA writes to the EMS frame? How do you debug this Adaptec card of yours (sorry ,I haven't read the whole topic)?

DMA writes. I've been using the DEBUG utility to load a sector from disk into memory as a test. It would really be more clear if you read the thread

It is the problem of Adaptec SCSI. It only cares about MEMCS16# at address range 0A0000-0BFFFF and explicitly calls this out in the manual. Don't know why back then they could have reached such a design decision that clearly violated ISA protocols and shipped the products in volume. Perhaps it was the time that ISA memory expansion cards could have been obsoleted for 286-AT. People would just add more memory on-board instead of buying ISA memory expansion cards and most late 286-AT chipsets support EMS, too.

Or, there could be other issues with MEMCS16# as ISA bus master was an after-thought and a nightmare for PC chipsets designers. Someone more familiar with the original IBM PC-AT circuitry would probably know about them, or trace out the logics on MEM16CS# from IBM PC-AT technical reference.

Perhaps, someone can file the issue for the lo-tech EMS design and if they could come up with an improved revision using 16-bit ISA supporting 16-bit transfer and MEMCS16# signaling.

Finally, it is highly probable that 8-bit vs 16-bit transfer is done within the SCSI BIOS because Adaptec manual also says the controller will intelligently decide the 8-bit transfer in the beginning or at the end or both (even size payload at odd address) while performing the rest of the payload in 16-bit transfer. If someone can disassemble and hack the SCSI BIOS to always do 8-bit transfer (at the expense of slight performance hit), then it will be compatible with ISA memory expansion cards that only support 8-bit transfer.

When the Adaptec tries to do word writes to the (8-bit) Lo-tech card it fails. We can attribute that to the Adaptec not handling 8-bit targets correctly.

However the other EMS boards should be able to accept word writes, but somehow the data transfer still fails the same way. This part makes no sense.

Here's an excerpt from the manual of "The Last Byte" memory manager. I can't help but think this is somehow related, even though it still doesn't explain why both 16-bit EMS boards shit the bed with word writes.

Address lines A15 and A16 are not latched in hardware design of the AT bus. As a consequence, some 16-bit adapter c […]
Show full quote

Address lines A15 and A16 are not latched in hardware design of
the AT bus. As a consequence, some 16-bit adapter cards do not
properly decode these address lines within the narrow time
constraints imposed by the Address Latch Enable (ALE) signal,
and will occassionally respond to a memory access that is
directed at some other portion of the address space. Thinking
that it is for them, they force the transfer into 16-bit mode
even though the intended recipient requires 8-bit mode, and thus
cause erroneous data to be transferred to the bytes in the
odd-numbered addresses.

The most common (and damaging) occurence occurs during the 8-bit
DMA transfers between a floppy disk drive and upper memory near
the address space occupied by an offending 16-bit adapter card.

Due to organization of the address signals on the AT bus, this
phenomena only occurs when the two address areas are within the
same 128k region. There are three such regions in the upper
area: A0000-BFFFF, C0000-DFFFF, and E0000-FFFFF. LASTBYTE.SYS
automatically senses the presence of 16-bit adapter cards in
each of these three regions and records this information within
its resident image for use by its utilities. LASTBYTE.SYS skips
this test if it detects a PC with a Micro Channel bus (like the
PS/2) since problem was corrected in its design.

The RESTRICT option is provided to override this automatic
detection of 16-bit adapters. Each of the three arguments (one
per 128k region) should be replaced by either "0" (indicating no
16-bit adapters), or "1" (indicating the presense of a 16-bit
adapter) and separated by commas.

For example, the option RESTRICT=1,1,0 would imply that one or
more 16-bit adapters are located in the first two 128k regions
of upper memory (A000-DFFF), so that when the companion
/RESTRICT option of HIGHDRVR, HIGHTSR, HIGHDUBL or HIGHUMM is
used, only High-DOS memory in the region E000-FFFF will be
allocated.

maxtherabbit, could you clone your hard drive and use an IDE drive instead?

georgel wrote:

maxtherabbit, could you clone your hard drive and use an IDE drive instead?

I don't know what the point of such an exercise would be. IDE isn't going to perform bus master DMA transfers and will almost certainly work just fine. I know I can write arbitrary data to the page frame manually in DEBUG without any issue.

The point is that the real mode software you want to run would run on a 286 AT machine flawlessly with the EMS attached. The drive is just a mere disk storage - INT13h 😉 The SCSI drives were exotic back then. Hence the bugs. MFM/IDE was de facto the standard for the PC hard drives natively suppoprted by AT BIOS. Leave the SCSI to other non-PC platforms.

georgel wrote:

The point is that the real mode software you want to run would run on a 286 AT machine flawlessly with the EMS attached. The drive is just a mere disk storage - INT13h 😉 The SCSI drives were exotic back then. Hence the bugs. MFM/IDE was de facto the standard for the PC hard drives natively suppoprted by AT BIOS. Leave the SCSI to other non-PC platforms.

no thanks, I care about my SCSI setup way more than EMS

EMS was just a lark, at this point I'm totally happy living without it but the curiosity factor is the only thing keeping me involved

maxtherabbit wrote:

no thanks, I care about my SCSI setup way more than EMS

I wouldn't.
A HDD is just a HDD. If you want real performance, a CF-IDE setup will beat a SCSI HDD any day of the week.
Besides, I agree, a HDD is just a HDD for an old DOS machine. You only use it to load up your application. Once the application is in-memory, most software barely uses the disk, so performance is not relevant.
EMS on the other hand... There are applications out there that NEED EMS to even work, or to unlock certain features. Other applications will work with XMS instead, but have better performance with EMS.
So I would definitely prefer IDE+EMS over SCSI without EMS.

I believe I have come up with a theory that fits the facts - and it is deceptively simple

What if the Adaptec card is simply not asserting SBHE# when is does DMA transfers to the C or D segments? We already know that it assumes all DMA accesses outside of the A and B segment to be 16 bits wide, but what if it doesn't assert SBHE# at all since asserting MASTER is enough to make the chipset assume 16 bit access to system memory?

This would be consistent with the 16-bit EMS cards only updating the low byte, because even though the entire word is available on the data bus, they are assuming 8-bit transfer mode since SBHE# is not being asserted at the time of address decoding.

Scali wrote:

If you want real performance, a CF-IDE setup will beat a SCSI HDD any day of the week.

that's demonstrably false, at least on this system

I did an entire thread over at VCFED documenting the performance of various disk systems. SCSI crushed CF-IDE, most likely due to the bus mastering DMA.
http://www.vcfed.org/forum/showthread.php?697 … r-a-286-Machine

I don't use any applications that require EMS, other than Monster Bash which requires it for sound, which i can live without.

maxtherabbit wrote:

that's demonstrably false, at least on this system

I did an entire thread over at VCFED documenting the performance of various disk systems. SCSI crushed CF-IDE, most likely due to the bus mastering DMA.
http://www.vcfed.org/forum/showthread.php?697 … r-a-286-Machine

Can't be bothered to read, but I was talking about the fact that a HDD has seek times, where CF or SD do not. Which generally leads to better performance in practice, even if theoretical maximum throughput is lower.