VOGONS


Why does EMS suck on my 286?

Topic actions

Reply 40 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:

I would suggest one last try with Intel Above Board and setting the EMS Page Frame to CC00 instead of D000.

I can but what's the reasoning behind this?

Reply 41 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Frankly speaking, all logical options have already been exhausted, so I would start suspecting potential hardware decoding issues or system BIOS bugs around the borders.
Another option can be moving the SCSI BIOS to D800 or DC00, and setting the EMS Page Frame at C800. These were just my typical EMS debugging back in my 286 days.

A more exotic suggestion would be to reduce the memory on the 286 baseboard from 4MB to 1MB to see if reducing memory load would help the ISA EMS memory board. I believe you have a more recent version of Intel Above Board that can be configured to back-fill memory from 128KB-640KB. This gives you a better LIM EMS 4.0 in addition to the 64KB EMS Page Frame. Advanced EMS application such as DeskQview can take advantage of mapped memory pages outside of EMS Page Frame.

Reply 42 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
bakemono wrote:

how about using smartdrv with the /double_buffer switch

OK we're on to something here!

Just running SMARTDRV.EXE from the command prompt fixes the issues with Keen, BioMenace and Spear of Destiny. So I think it's safe to say the problem is in fact disk I/O related. Unfortunately the garbled cockpit problem in Wing Commander remains.

I tried putting DEVICE=C:\DOS\SMARTDRV.EXE /DOUBLE_BUFFER in my config.sys but it didn't seem to do anything. It executes without error, but memory usage didn't change upon loading it. My understanding is it's meant to consume ~3kB of conventional memory, but I see no evidence of it being loaded.

EDIT: Grabbed a copy of smartdrv from MS-DOS and EVERYTHING WORKS! I didn't even have to execute the caching element from the command prompt, simply adding the DEVICE statement to the config.sys got it sorted, however it's only effective if you add the + to the end of the statement. I'm guessing the PC-DOS version of SMARTDRV doesn't respect the + (force) option.

You can force the double buffer driver to load even if SMARTDRV.EXE decides that it is unnecessary. Adding a PLUS SIGN (+), as i […]
Show full quote

You can force the double buffer driver to load even if SMARTDRV.EXE decides that
it is unnecessary. Adding a PLUS SIGN (+), as in the following example, forces
the double buffer to load:

DEVICE=C:\WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER+

Reply 44 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
maxtherabbit wrote:

Only one problem - using double buffering is destroying my disk I/O performance, anything I can do about that?

That is the side-effect because instead of doing 1 big chunk DMA transfer the card is forced to do small chunk into the transfer buffer and the CPU will move the data from transfer buffer to the final destination buffer.
I think you may have a faulty SCSI card or faulty ISA slot that has issues doing DMA transfer in higher range of memory address. Enable double buffering hides the issue because the card is forced to only transfer into a small memory in lower memory address. Perhaps you can take out the card to clean the metal contacts and try other available ISA slot.

286 system should not require double buffering at all to deal with the virtual address in V86 mode as in 386 or higher with the presence of 386 memory manager. There is no V86 mode in 286, so the linear memory address is the same as physical address anyway.

Reply 45 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

Is it even possible for ISA DMA to go from one ISA card (SCSI HBA) to another (EMS Board)?

I thoroughly cleaned all edge connectors before building this system. I can try moving the SCSI card I guess, but I don't think it's a contact problem.

Reply 46 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
maxtherabbit wrote:

Is it even possible for ISA DMA to go from one ISA card (SCSI HBA) to another (EMS Board)?

I think so, why not? 8-bit ISA has 20-bit address lines and the 16-bit ISA (AT-BUS) has 24-bit address line. For simple EMS board such as the lo-tech EMS board, the 64KB EMS Page Frame is just a normally decoded memory and can be the target for DMA. For more advanced EMS board such as the Intel Above Board, the EMS Page Frame, the back-filled memory at below 640KB can all be DMA targets.

Reply 47 of 167, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie

I think so, why not?

For a 16-bit card to transfer to an 8-bit card it would have to test the MEMCS16 line and then split a word transfer into two bytes. That's assuming that the motherboard itself asserts MEMCS16 for system memory addresses, which is not clear. Even if this is possible the SCSI card designers may have assumed that system memory would always be at least 16 bits wide and omitted this logic.

The MS-DOS help says that double buffering uses only a 2KB buffer for I/O so that will limit the speed somewhat but it also says this:

If you are using SMARTDrive's double-buffering feature and your system appears to be running slowly, try adding the /L switch to […]
Show full quote

If you are using
SMARTDrive's double-buffering feature and your system appears to be
running slowly, try adding the /L switch to the SMARTDrive command in
your AUTOEXEC.BAT file.

Maybe if it was running from HMA there is also the overhead of changing the A20 line???

Reply 48 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

Remember the Above Board is a 16-bit card, and it was doing the exact same thing. Unless EMS itself is limited to 8-bit transfers by design?

Every time I've tried loading SMARTDRV from the command prompt, it has loaded itself into conventional memory anyway, so I'm not sure the /L switch would do anything

Reply 49 of 167, by Matth79

User metadata
Rank Oldbie
Rank
Oldbie

One crazy idea, try waitstating the SCSI BIOS... http://download.adaptec.com/pdfs/user_guides/aha1540b_um.pdf

Also, instead of the smartdrv double buffer, maybe try ASPI4DOS.SYS /W - not sure if that only works on 386 systems though, or if it's applicable to 286
If the /W doesn't help (uses extended memory), try /WM (uses main memory, though that will eat a 64k chunk of low memory

Reply 50 of 167, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie
maxtherabbit wrote:

Remember the Above Board is a 16-bit card, and it was doing the exact same thing.

Ah. Didn't know there was a 16-bit version.

According to the 1542 manual it uses the 8237 for DMA. I haven't seen anything that says you can't do DMA from one ISA card to another. Although it's hard to find any info, search engines seem to be getting worse all the time...

Interestingly, it does say that you can use DMA channel 0, which is an 8-bit one instead of 16-bit. I wonder if that would make any difference.

Reply 51 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

I've been trying in vain to successfully get ASPI4DOS.SYS to actually allocate a buffer. Regardless of whether I use the /W or /WM switch it simply loads normally, using the exact same amount of conventional memory it does with no switches, and 0 XMS. I suspect it may be a similar situation to the SMARTDRV buffer, and the reason I had to "force" with the plus sign - it probably sees a 286 and decided "there's no V86 mode here this shit is stupid" and refuses to buffer.

I may be onto something else though... if this PCCONFIG program is to be believed, even the 16-bit Above Board still only allows 8-bit access to its page frame. I've tried moving the page frame to D000, CC00, and C800 (while also relocating the SCSI ROM, when appropriate, with jumpers) but regardless of where the page frame is, it still shows up as only having 8-bit access.

bakemono could be 100% on target about DMA writes from the SCSI card only supporting 16-bit width and failing to write to a page frame with 8-bit access.

(BTW I did try waitstating the SCSI BIOS just now, no effect. Also tried the /L switch with smartdrv and it had no effect, it was already loading low)
(Also tried DMA 0 just now, no change - I think on a 16-bit system selecting DMA 0 is just the same as selecting DMA 4)

Had the Above Board installed and configured with the page frame at C800 in this screenshot (SCSI ROM @DC00)

20190810_203820.jpg
Filename
20190810_203820.jpg
File size
1.43 MiB
Views
924 views
File license
Fair use/fair dealing exception

Reply 52 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
maxtherabbit wrote:

Had the Above Board installed and configured with the page frame at C800 in this screenshot (SCSI ROM @DC00)

20190810_203820.jpg

Your last picture looks strange. The SCSI BIOS didn't show up as ROM but the EMS Page Frame of 96KB????
Somehow, the Intel Above Board mapped memory overlapped with your SCSI BIOS. This is very bad. Any diag software scanners should easily detect the ROM.

Reply 53 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

No it didn't overlap. That particular informational display only distinguishes regions by timing factor. The description field is unreliable. Any other diag (MSD, Checkit, etc.) showed a distinct 64kB page frame between C800-D7FF and the SCSI ROM from DC00-DFFF

Reply 54 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

16-bit DMA from 8237 is just 2 back-to-back 8-bit data cycle. The 8237 only has 8 data lines.
In fact, according to some of the x86 legacy literature, as long as the ISA card does not assert MEMCS16# when its address was decoded, the bus decoding logics should split the master 16-bit data cycle into 2 back-to-back 8-bit data for the target. At least, it says this happens when 80286 is the master during 16-bit data cycles. Since the AHA-1542 is performing DMA through 8237 (3rd-party DMA), 8-bit or 16-bit ISA target does not matter. 16-bit ISA introduces ISA Bus Mastering (1st-party DMA) but I guess it still needs to follow the MEMCS16# protocols and play nice with other 8-bit targets.

Reply 55 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

I was under the impression that the AHA-1542B actually does bus mastering and does not perform DMA through the 8237.

I don't recall seeing anything in the manual that described it using the 8237 either.

https://www.tuhs.org/Usenet/comp.unix.sysv386 … ary/003525.html
This site has some pretty interesting information on the subject, I've tried adjusting the DMA transfer rate to no avail but have not attempted anything with the bus on/off times

Reply 56 of 167, by bakemono

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote:

16-bit DMA from 8237 is just 2 back-to-back 8-bit data cycle. The 8237 only has 8 data lines.

The data lines on the 8237 are only used for accessing its internal registers. It doesn't actually read or write data during DMA. It only puts an address on the bus and sets the control/command lines, the other relevant devices are expected to drive the data bus or read the data. The second 8237 that handles channels 5,6,7 effectively puts even addresses on the bus so that words can be transferred, because they shifted the address lines over by one. A0 is not connected to it. That's why its registers are spaced 2 apart from $C0-$DF whereas the first 8237 only occupies $00-$0F

I was under the impression that the AHA-1542B actually does bus mastering and does not perform DMA through the 8237.

You could be right, this part is confusing because bus mastering needs a DMA channel just to request the bus even without using the 8237 for anything else. But the docs say that a card is also bus master during a block transfer where the 8237 is used for addressing.
http://www.hardwarebook.info/ISA

I may be onto something else though... if this PCCONFIG program is to be believed, even the 16-bit Above Board still only allows 8-bit access to its page frame.

That is curious, but would explain why it has the same problem as the Lo-tech card.

Whatever the reason that DMA to the EMS fails, the ideal solution would be an option in the SCSI BIOS to exclude the page frame area, or a TSR that hooks disk I/O and does buffering only for addresses in the page frame. You would think that someone already had this problem and solved it thirty years ago...

Reply 57 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

A logic analyzer with an ISA card edge would really come in handy right about now. Be so easy to just look for any addresses in the page frame and just peep the high byte of the data bus...

Reply 58 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

My bad, the AHA-1542 does indeed capable of 1st party DMA. The ISA quirks are rusty in my memory that ISA bus master simply requires DRQ/DACK to handshake with 8237 for HOLD/HLDA protocols for CPU to tri-state the bus without actually using the 8237 for DMA.

Well, you can also write small test program to fill the EMS Page Frame with patterns, issue INT13h write command to write to the disk or vice versa (read sectors, fill EMS Page Frame). Allocating EMS memory and mapping the memory into EMS Page Frame are quite simple even without library support with just a bunch of calls to INT67h.

Reply 59 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

That would be quite an undertaking for me, I wouldn't even know where to start with an assembler (MASM?)

What about another utility program that could corroborate what PCCONFIG is saying regarding the memory access bit-width of the page frame? If I could confirm completely that the Above Board only allows 8-bit access to its page frame, I'd at least feel like the mystery was "solved" even if it means no resolution with my current hardware.