VOGONS


Why does EMS suck on my 286?

Topic actions

Reply 60 of 167, by Scali

User metadata
Rank l33t
Rank
l33t

Well, at least we have a working theory of why the EMS doesn't work...
Apparently the SCSI controller is somehow interfering. Which might explain why the test tools don't catch the problem: there is no disk I/O during the test.
It also explains why some games will and others will not work... It depends on whether or not there is any disk I/O after the EMS memory is filled.

I suppose the simplest 'solution' is to replace the SCSI controller with a simple IDE controller or such. Chances are it solves the problem.
Then the next question is whether this combination of SCSI controller and EMS cards has the same problem on all machines, or if it is specific to this motherboard.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 61 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

MS-DOS DEBUG.COM provides {XA, XD, XM, XS} command to manipulate EMS memory and it also has {L, W} to load memory from named file and write named file to memory. Use "?" at the DEBUG command prompt to get more details.

A rough idea looks like:

-{XA, XM} to allocate and map EMS memory 64KB
-N FILE1.BIN
-R DS
:C800
-L DS:0
-D DS:0

That is read from FILE1.BIN into EMS Page Frame at C800 and dump it. You can create and fill FILE1.BIN with the patterns. When you load the named file, BX:CX will contain to size of the file.

To write from EMS Page Frame to FILE2.BIN, BX:CX is the write size, and the example use 0x10000 for 64KB EMS Page Frame.

-N FILE2.BIN
-R BX
:1
-R CX
:0
-R DS
:C800
-W DS:0

DEBUG {L,W} can also work with drive and sector, but this is more risky for write and may corrupt the disk if you are not careful. You can google for more DEBUG examples.

Reply 62 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

Well, at least we have a working theory of why the EMS doesn't work...

I actually don't believe that ISA bus master cannot do 16-bit access to 8-bit memory target on ISA, if this is the theory. The CPU is already a bus master that can do 16-bit access to 8-bit ISA memory target. The chipsets will just split the data as 8-bit ISA targets do not have MEMCS16#. The same rule would have been there for ISA bus masters.

Reply 63 of 167, by Scali

User metadata
Rank l33t
Rank
l33t
kjliew wrote:

I actually don't believe that ISA bus master cannot do 16-bit access to 8-bit memory target on ISA, if this is the theory.

I wouldn't go that far no.
The 'theory' as far as I was concerned, is that the SCSI card does 'something' that corrupts the EMS frame (which explains why EMS tests and certain games succeed, because there's no disk I/O... and certain games fail, because there is disk I/O).
Whatever that 'something' is, I don't know exactly.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 64 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:
Scali wrote:

Well, at least we have a working theory of why the EMS doesn't work...

I actually don't believe that ISA bus master cannot do 16-bit access to 8-bit memory target on ISA, if this is the theory. The CPU is already a bus master that can do 16-bit access to 8-bit ISA memory target. The chipsets will just split the data as 8-bit ISA targets do not have MEMCS16#. The same rule would have been there for ISA bus masters.

bakemono's theory was not that all 16-bit ISA bus masters can't do DMA to 8-bit targets, it was that the AHA-1542B specifically can't do them

which would make perfect sense if the card designers simply neglected to account for the possibility of an 8-bit hardware memory card on a 16-bit system and didn't code a test of MEMCS16# - the motherboard chipset can't do anything to split data when the card is bus mastering

later today I'm going to try to experiment with manipulating the bus on/off times on the SCSI card, I'll also try the debug commands provided

between those two tests that should give a definitive answer as to whether it is really the bit width that's the problem or some other aspect of the first party DMA process

Reply 65 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

I set bus on/off times to their "most compatible" values as well as reducing DMA transfer speed to the minimum (3.3MB/sec) and it still does the same thing.

A VALUE OF FF (E.G., /XFF) WILL SET THE HOST ADAPTER TO THE SLOWEST AND MOST COMPATIBLE TRANSFER SPEED OF 3.3 MBYTES/SECOND.

Use the following command line switches on Adaptec ASPI device drivers to make the host adapter as compatible as possible: For t […]
Show full quote

Use the following command line switches on Adaptec ASPI device drivers
to make the host adapter as compatible as possible:
For the Novell NetWare 386 operating system:
:load AHA1640 bus_on=4 bus_off=12
NOTE: ASPITRAN.DSK must be in the same path.
This sets the bus on time to 4 microseconds,
and the bus off time to 12 microseconds.

Note I didn't actually use the Novell driver switches, but that's where I sourced the values of on 4 off 12 for testing.

Reply 66 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

***IT'S THE BITS BOIS***

Here's the first sector of my boot partition:

20190812_112546.jpg
Filename
20190812_112546.jpg
File size
1.53 MiB
Views
894 views
File license
Fair use/fair dealing exception

Now here's me filling the beginning of the first EMS page with a pattern, then loading that same sector from disk on top:

20190812_112200.jpg
Filename
20190812_112200.jpg
File size
1.78 MiB
Views
894 views
File license
Fair use/fair dealing exception

Notice how only the even columns got updated??

thanks to kjliew for the tips on using DEBUG - I had no idea it was so easy to work with EMS handles in DEBUG!
thanks to bakemono for the theory which proved true!

NOTE: this test was performed with the Lo-Tech, I will retest with the Above Board, but I suspect that it does in fact only allow 8-bit access to its page frame and the results will be the same
EDIT: confirmed same result with the Above Board

Reply 67 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Very interesting discovery!
I would think that this is an early 286 chipset bug since ISA bus master was new in 16-bit ISA and perhaps not very common in the beginning. It would be really helpful if you can tell us the details of the chipset used in your 286 motherboard, or post a good shot of the motherboard and we can look for the chipset.

maxtherabbit wrote:

which would make perfect sense if the card designers simply neglected to account for the possibility of an 8-bit hardware memory card on a 16-bit system and didn't code a test of MEMCS16# - the motherboard chipset can't do anything to split data when the card is bus mastering

AFAIK, MEMCS16# is driven by ISA memory target to tell the bus decoding logics that it can accept 16-bit access. ISA bus master does not have to know if the target is 8-bit or 16-bit. There is only one bus, ISA bus master does not have side-bands to ISA target, the address/data/strobe has to go through the same bus decoding logic that CPU would go through to reach the target. Otherwise, CPU MOV rd/mem16, CMPSW/LODSW/MOVSW and other 16-bit data movement instruction would have failed on 8-bit ISA memory target. If CPU 16-bit data movement instruction works on the 8-bit ISA memory target, then this is most likely a chipset bug. And, it is very common for software to do REP MOVSW to and from EMS Page Frame.

Reply 68 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:
Very interesting discovery! I would think that this is an early 286 chipset bug since ISA bus master was new in 16-bit ISA and p […]
Show full quote

Very interesting discovery!
I would think that this is an early 286 chipset bug since ISA bus master was new in 16-bit ISA and perhaps not very common in the beginning. It would be really helpful if you can tell us the details of the chipset used in your 286 motherboard, or post a good shot of the motherboard and we can look for the chipset.

maxtherabbit wrote:

which would make perfect sense if the card designers simply neglected to account for the possibility of an 8-bit hardware memory card on a 16-bit system and didn't code a test of MEMCS16# - the motherboard chipset can't do anything to split data when the card is bus mastering

AFAIK, MEMCS16# is driven by ISA memory target to tell the bus decoding logics that it can accept 16-bit access. ISA bus master does not have to know if the target is 8-bit or 16-bit. There is only one bus, ISA bus master does not have side-bands to ISA target, the address/data/strobe has to go through the same bus decoding logic that CPU would go through to reach the target. Otherwise, CPU MOV rd/mem16, CMPSW/LODSW/MOVSW and other 16-bit data movement instruction would have failed on 8-bit ISA memory target. If CPU 16-bit data movement instruction works on the 8-bit ISA memory target, then this is most likely a chipset bug. And, it is very common for software to do REP MOVSW to and from EMS Page Frame.

I wonder if it is indeed a chipset problem, could the chipset be what's forcing the EMS page frame to 8-bit on the Above Board? Or is that just a limitation of the card itself, since it is designed for backwards compatibility with 8-bit busses. I'm pretty murky on how address decoding works with ISA so that might not even be feasible... I'm torn on whether to attempt purchasing another 16-bit EMS board or just to pull the plug on EMS all together for this build. I'd hate to get another 16-bit board and find out it is also limited to 8-bit page frame access.

Chipset is the VLSI VL82PCAT-QC

ICs are:
VL82C100
VL82C101B
VL82C102A
VL82C103A
VL82C104

Reply 69 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I may have found a solution for you. I hex-viewed the ASPI4DOS.SYS and I didn't find any occurrence of /W or /WM which enables double-buffering. However, I found the README.TXT in the DOS driver package that ASPIBUF.SYS must be loaded right after ASPI4DOS.SYS for system with over 16MB of memory. This exactly means double-buffering because ISA bus master maximum address space is 16MB. I hex-viewed ASPIBUF.SYS and it can take /size= switch to allocate from 2-64KB of buffer. So if this works, then you can keep the EMS board and SCSI working happily.

DEVICE=C:\SCSI\ASPI4DOS.SYS
DEVICE=C:\SCSI\ASPIBUF.SYS /size=n
DEVICE=C:\DOS\HIMEM.SYS

I am not sure if it is able to allocate the buffer from Extended Memory since you have lots of that. Otherwise, taking out 64KB from 640KB seems too much and you may as well use 286 EMS emulator that has EMS Page Frame below 640KB. It will be perfect if the buffer can be allocated from Extended Memory, then you just max it out at 64KB to get the best performance.

Extended Memory != XMS memory. You should load ASPI4DOS and ASPIBUF before HIMEM.SYS. Otherwise, all Extended Memory will be used by HIMEM.SYS into XMS memory and the ASPI duos will fail to find any available Extended Memory.

Reply 70 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:
I may have found a solution for you. I hex-viewed the ASPI4DOS.SYS and I didn't find any occurrence of /W or /WM which enables d […]
Show full quote

I may have found a solution for you. I hex-viewed the ASPI4DOS.SYS and I didn't find any occurrence of /W or /WM which enables double-buffering. However, I found the README.TXT in the DOS driver package that ASPIBUF.SYS must be loaded right after ASPI4DOS.SYS for system with over 16MB of memory. This exactly means double-buffering because ISA bus master maximum address space is 16MB. I hex-viewed ASPIBUF.SYS and it can take /size= switch to allocate from 2-64KB of buffer. So if this works, then you can keep the EMS board and SCSI working happily.

DEVICE=C:\SCSI\ASPI4DOS.SYS
DEVICE=C:\SCSI\ASPIBUF.SYS /size=n
DEVICE=C:\DOS\HIMEM.SYS

I am not sure if it is able to allocate the buffer from Extended Memory since you have lots of that. Otherwise, taking out 64KB from 640KB seems too much and you may as well use 286 EMS emulator that has EMS Page Frame below 640KB. It will be perfect if the buffer can be allocated from Extended Memory, then you just max it out at 64KB to get the best performance.

Extended Memory != XMS memory. You should load ASPI4DOS and ASPIBUF before HIMEM.SYS. Otherwise, all Extended Memory will be used by HIMEM.SYS into XMS memory and the ASPI duos will fail to find any available Extended Memory.

Interesting I'll give that a try. Even if it's able to allocate the buffer from extended memory I suspect it will still incur a hefty performance hit.

(I always forget there is some software that uses extended memory directly without the aid of HIMEM.)

ASPIBUF.SYS is an ASPI double-buffering driver that you load immediately after ASPI4DOS.SYS (e.g. before ASPICD.SYS, ASPIDISK.S […]
Show full quote

ASPIBUF.SYS is an ASPI double-buffering driver that
you load immediately after ASPI4DOS.SYS (e.g. before ASPICD.SYS, ASPIDISK.SYS,
etc.). It, along with ASPI4DOS.SYS, must both be loaded low before EMM386
(or QEMM, 386MAX, etc.). It intercepts ASPI and INT 13h commands and double-
buffers both so that these data transfers occur within the first 16 MBytes
of RAM. ASPIBUF.SYS is intelligent enough to not double-buffer if the
ASPI or INT 13h buffer is already within the first 16 MBytes of RAM.
It is
only designed to work with ASPIDISK.SYS, ASPICD.SYS, and INT 13h commands.

That might be a problem

Reply 71 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
2.1.3 8 Bit Memory […]
Show full quote

2.1.3 8 Bit Memory

During normal DMA operations, nearly all transfers to and from memory are 16
bit transfers. At the very end, or the very beginning of an odd address
boundary, an 8 bit transfer on the upper data bits (D8-D15) will occur
according to the AT bus architecture. Some memory in the I/O space, such as
video RAM, is 8 bits only and always transfers data only on the lower data bits
(D0-D7). The AHA-1540A/1542A will transfer 16 bit or 8 bit memory in the
address space between 0A0000 hex and 0BFFFF hex depending on the signal line
MEM16 on the AT bus. If this signal is active, 16 bit memory is assumed, and if
inactive 8 bit memory is assumed. Outside of this address space 16 bit memory
is always assumed.

Found this interesting piece from the user manual, so that's about it. Look like the chipset only takes care of the CPU master, ISA bus master is on its own. I am surprised that Intel Above Board does not have such a test case of ISA bus master, or perhaps there is a configuration for Intel Above Board to accept 16-bit data transfer.
Perhaps, if the SCSI BIOS actually controls the range 0A0000 and 0BFFFF where MEMCS16# is respected, then someone may be able to hack the SCSI BIOS to expand the memory range.

Reply 72 of 167, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie

A definitive answer! Nice work.

I was looking at ASPIBUF.SYS just now, and I saw that its INT 13h handler tests for the presence of Virtual DMA services and if there are none then it just falls through to the old INT 13h handler. So unfortunately it looks like this driver is only meant for protected mode environments and won't help with real mode.

Reply 73 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I managed to find an old version 3.0 of ASPI4DOS.SYS. I hex-viewed it and it does support /W, /WM, /V and /VM switch. Give it a shot!
http://ftp.mpoli.fi/unpacked/hardware/hdd/ada … ip/aspi4dos.sys
Update: Version 3.0 does not support extended translation for SCSI HDD over 1GB. You need to track down version 3.0a that first support extended translation, but I don't know if the switches have been removed in 3.0a. Adaptec EZ-SCSI 1.0 comes with ASPI4DOS.SYS version 3.1, and the switches have been removed.

Or, use SCSIHA.SYS for double buffering. Some of the usenet archives say it does not incur poor performance as SMARTDRV does.
http://www.nic.funet.fi/index/doc/hardware/pc … ptec/SCSIHA.SYS

Reply 74 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:
2.1.3 8 Bit Memory […]
Show full quote

2.1.3 8 Bit Memory

During normal DMA operations, nearly all transfers to and from memory are 16
bit transfers. At the very end, or the very beginning of an odd address
boundary, an 8 bit transfer on the upper data bits (D8-D15) will occur
according to the AT bus architecture. Some memory in the I/O space, such as
video RAM, is 8 bits only and always transfers data only on the lower data bits
(D0-D7). The AHA-1540A/1542A will transfer 16 bit or 8 bit memory in the
address space between 0A0000 hex and 0BFFFF hex depending on the signal line
MEM16 on the AT bus. If this signal is active, 16 bit memory is assumed, and if
inactive 8 bit memory is assumed. Outside of this address space 16 bit memory
is always assumed.

Found this interesting piece from the user manual, so that's about it. Look like the chipset only takes care of the CPU master, ISA bus master is on its own. I am surprised that Intel Above Board does not have such a test case of ISA bus master, or perhaps there is a configuration for Intel Above Board to accept 16-bit data transfer.
Perhaps, if the SCSI BIOS actually controls the range 0A0000 and 0BFFFF where MEMCS16# is respected, then someone may be able to hack the SCSI BIOS to expand the memory range.

Great find, I guess that settles it

Regarding the Above Board - it is also designed to provide conventional backfill and extended memory for ATs, and has a setting for backwards compatibility with XTs/PCs. It wouldn't surprise me if EMS support was somewhat of an afterthought and not the primary design consideration, so they just made access to the page frame 8-bit only to make switching into backwards compatibility with 8-bit buses easier.

Last edited by maxtherabbit on 2019-08-13, 15:03. Edited 1 time in total.

Reply 75 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:
I managed to find an old version 3.0 of ASPI4DOS.SYS. I hex-viewed it and it does support /W, /WM, /V and /VM switch. Give it a […]
Show full quote

I managed to find an old version 3.0 of ASPI4DOS.SYS. I hex-viewed it and it does support /W, /WM, /V and /VM switch. Give it a shot!
http://ftp.mpoli.fi/unpacked/hardware/hdd/ada … ip/aspi4dos.sys
Update: Version 3.0 does not support extended translation for SCSI HDD over 1GB. You need to track down version 3.0a that first support extended translation, but I don't know if the switches have been removed in 3.0a. Adaptec EZ-SCSI 1.0 comes with ASPI4DOS.SYS version 3.1, and the switches have been removed.

Or, use SCSIHA.SYS for double buffering. Some of the usenet archives say it does not incur poor performance as SMARTDRV does.
http://www.nic.funet.fi/index/doc/hardware/pc … ptec/SCSIHA.SYS

I have attempted to load that 3.0 version from that exact zip file before and it just hangs up after displaying its splash text. I do have a 2GB HDD using extended translation so that might be the reason - I can't remember for certain if I also tried it with a smaller drive, but I think I did.

I'll give SCSIHA.SYS a try. I have my doubts as to whether any double buffering solution is going to be performant, but it's definitely worth a shot. Think it's safe to assume the performance of SCSIHA.SYS would be commensurate with finding that magic version of ASPI4DOS that has the /W switch and still supports extended translation?

Reply 76 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

From wikipedia:

8/16-bit incompatibilities
Memory address decoding for the selection of 8 or 16-bit transfer mode was limited to 128 KiB sections, leading to problems when mixing 8- and 16-bit cards as they could not co-exist in the same 128 KiB area. This is because the MEMCS16 line is required to be set based on the value of LA17-23 only.

I wonder if this could be relevant? The SCSI BIOS itself is an 8 bit ROM, and no matter which memory location you choose via jumper it's going to end up in the C or D segment - so regardless it would be in the same 128kB segment as any page frame on this system.

Is it possible the ROM could be "dragging down" the entire C and D segments to 8-bit access?? Evidence that contradicts this would be the fact the VGA BIOS at C000 still appears to have 16-bit access as per PCCONFIG.

(Also makes me question whether having a mono adapter installed as secondary is dragging down my VGA RAM in the A segment...)

Reply 77 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
maxtherabbit wrote:

Regarding the Above Board - it is also designed to provide conventional backfill and extended memory for ATs, and has a setting for backwards compatibility with XTs/PCs. It wouldn't surprise me if EMS support was somewhat of an afterthought and not the primary design consideration, so they just made access to the page frame 8-bit only to make switching into backwards compatibility with 8-bit buses easier.

I am not sure which Intel AboveBoard SKU/revision yours is, I found some version of Intel AboveBoard has a SW/Jumper for AT/XT compatible. Not sure if this would mean the board can support 16-bit data transfer. Other RAM expansion board such at the one below has explicitly called the support for 16-bit transfer mode.
http://www.minuszerodegrees.net/manuals/Evere … 00%20Deluxe.txt

SW4:1 EMS transfer mode. Not applicable for XMS.
OFF = 8 bits (default), ON = 16 bits.
16 bits may not be useable if the computer's bus speed is 8 MHz or faster.
maxtherabbit wrote:

I have my doubts as to whether any double buffering solution is going to be performant

You're absolutely right. Double-buffering basically introduces the overhead of CPU data move. There is no way performance will be the same with or without it. It sorts of void the benefits of a bus mastering DMA controller. Larger transfer buffer simply soften the performance impact in hope of being less annoying. Unfortunately, SCSIHA.SYS won't allocate buffer from Extended Memory, so that is a kill for taking out a large chunk of memory from DOS 640KB memory.

Reply 78 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

OK final report on the SCSI buffering drivers:

ASPI4DOS 3.0a: can't find it, seems lost in time

ASPIBUF.SYS: allocates buffer in conventional, even when it and ASPI4DOS are loaded before HIMEM. Doesn't matter anyway, as it doesn't do anything. Doesn't buffer whatsoever unless it detects VDMA.

SCSIHA.SYS: here's where thing get interesting - it allocated a 16kB buffer in low memory, and did NOT affect the results of DISKTEST, BUT it did pass the DEBUG test and work with Keen, Biomenace, and Spear of Destiny
This driver appears to be buffering discretionarily, and leaving transfers to system memory alone. It is obviously buffering writes to EMS at least some of the time, but it still fails the Wing Commander test and gives garbled cockpit. All and all seems to have more or less equivalent results to using SMARTDRV WITHOUT double buffering.

I have been unable to locate any documentation on SCSIHA.SYS to see if there are any switches or such that might help correct it.

Reply 79 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.