VOGONS


Why does EMS suck on my 286?

Topic actions

Reply 100 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

decided to bang my head against this again today - not a resolution but I did come back with some more information

The AST card's EMM driver, REMM.SYS, has an option that's only documented in the addendum to the manual.

remm.jpg
Filename
remm.jpg
File size
117.19 KiB
Views
532 views
File license
Fair use/fair dealing exception

This option allows me to force the page frame to allow 16-bit access! But, doing so also killed INT13H since the SCSI ROM only has 8-bit access and they coexist in the same 128kB area (details on that limitation described elsewhere.) So, to get the system to boot I had to load ASPI4DOS.SYS prior to REMM.SYS, no big deal. Turns out that using the option /M=7F (forcing A,B,C, and D segments to 16-bit access mode) makes the EMS work perfectly in Wing Commander and Spear of Destiny. However it breaks text display in Keen and Biomenace (every other character is garbage.) I'm assuming the galaxy engine relies on 8-bit writes for character data somehow.

Changing the option to /M=5F (forcing C and D segments to 16-bit) made the EMS work in Keen and BioMenace. Wing Commander seems to work properly about half the time.

In any case, this is probably not a viable solution, because although the use of ASPI4DOS allows me to bypass SCSI ROM accesses for INT13H, any software that attempts to directly access the ROM in memory will crash the system when the EMS card is asserting MEMCS16# on accesses to C and D.

Last edited by maxtherabbit on 2019-09-01, 00:55. Edited 1 time in total.

Reply 101 of 167, by Scali

User metadata
Rank l33t
Rank
l33t
maxtherabbit wrote:

However it breaks text display in Keen and Biomenace (every other character is garbage.) I'm assuming the galaxy engine relies on 8-bit writes for character data somehow.

EGA and VGA use an ALU to read/write pixels. This is only specified to work with 8-bit reads/writes, because the ALU and its latched registers are only specified to be 8-bit wide.
So it could be that you actually do need to force it to 8-bit for segments A and B (where the VRAM normally is).

Which would explain why the /M=5F switch fixes things... except for Wing Commander, which as you say is probably doing something else that breaks.

maxtherabbit wrote:

In any case, this is probably not a viable solution, because although the use of ASPI4DOS allows me to bypass SCSI ROM accesses for INT13H, any software that attempts to directly access the ROM in memory will crash the system when the EMS card is asserting MEMCS16# on accesses to C and D.

But would that ever occur in practice?
Any regular application would only access the HDD via int 13h (or actually, they'd probably use int 21h only, which uses int 13h internally).
So the only normal way to call any code of the SCSI BIOS is by calling int 13h.
Basically all that ASPI4DOS does is to load its version of the SCSI BIOS in RAM somewhere, and redirect int 13h to there.
I suppose the original ROM is not used at all anymore at that point, and since the int 13h vector is overwritten, there's nothing that even points to the original ROM location.

I suppose only software that would specifically scan for extension ROMs, and would actually know enough about the SCSI ROM to know where its entry points would be, would be able to meaningfully call any ROM code directly. I think that's an extremely unlikely scenario.

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

Reply 102 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

Both Checkit and PCCONFIG lock the system up at their loading screens... So maybe if I refrained from using any diagnostic/information software it would be sustainable?

The real pisser here is the god damned AMI diagnostic ROM that resides in the E segment. If I could just be rid of that bastard and put my EMS page frame in E000-EFFF I think I would be able to have 16-bit access to it with zero hassle.

I guess 286 motherboards that don't have shadow ram support really are the anti-sweet spot for EMS use.

Reply 103 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

Just a bit of clarification - when I say "character" with respect to the galaxy engine games, I specifically mean text character. The sprites are all rendered properly

Reply 104 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

Update on Wing Commander - regardless of whether I set /M:5F or 7F it only works partially. Whereas without the switch it gives garbled cockpit 100% of the time, with the switch it gives garbled cockpit maybe 25% of the time and does other strange things like missing audio tracks etc. I think WC may just be incompatible with this EMS implementation.

So at this point, disregarding Wing Commander, it seems like the only thing holding me up from EMS being usable is this SCSI ROM thing. MS Scandisk won't execute either with the /M:5 or 7 either btw.

Is it possible to write a TSR that can disable DOS access to a specific memory region? I.e. C800-CBFF

Reply 106 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
georgel wrote:

It is well about time to rename your topic to " Why does Adaptec SCSI suck on my 286?" !!!

🤣 fair point but performance-wise the bus master DMA of the SCSI card is really carrying the team here

plus, I'm not really annoyed by the card's insistence on 16-bit DMA transfers anymore, honestly I would not be satisfied with being limited to 8-bit access to a 16-bit memory card

the only thing I can really lay on the SCSI adapter right now is its ROM being 8-bit instead of 16-bit, that's the real problem

(that and that stupid useless diagnostic ROM on the motherboard preventing me from using the E segment)

Reply 107 of 167, by Scali

User metadata
Rank l33t
Rank
l33t
maxtherabbit wrote:

(that and that stupid useless diagnostic ROM on the motherboard preventing me from using the E segment)

I take it that's an option ROM?
Is it socketed? Perhaps you can just pull it out and be done with it?

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

Reply 108 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

I take it that's an option ROM?
Is it socketed? Perhaps you can just pull it out and be done with it?

Sorry, read it wrong. The System BIOS taking E000 segment is a common problem for early AMI-286 missing hardware ShadowRAM/EMS support. There is no way to throw away excessive BIOS codes used for diagnostics.

That will prevent SCSI-HD to be used as boot drive and require loading of ASPI4DOS to access the drive after boot.

Another solution is to write a TSR to shadow the SCSI ROM below 640KB after boot. If memory serves me right, then ISA option ROM POST entry point is ROMSEG:0003. That requires some minimum x86/ASM programming skill to write a TSR.

Reply 109 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:

Another solution is to write a TSR to shadow the SCSI ROM below 640KB after boot. If memory serves me right, then ISA option ROM POST entry point is ROMSEG:0003. That requires some minimum x86/ASM programming skill to write a TSR.

isn't that basically what ASPI4DOS is doing? sorry I know you struck that out but I just want to make sure I'm understanding everything

since ASPI4DOS is handling the functions of the ROM after boot, could I just write a TSR to simply block accesses to the C800-CBFF region, is that even possible?

Reply 110 of 167, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
maxtherabbit wrote:

isn't that basically what ASPI4DOS is doing? sorry I know you struck that out but I just want to make sure I'm understanding everything

It depends, but I doubt ASPI4DOS is actually doing a full shadow of the SCSI BIOS. Most likely, it provides additional software layer to handle non-boot SCSI device, such as 2nd/3rd SCSI-HD, and may reuse ROM primitive SCSI functions to save resident code space when ROM presence is true. The best way to check this out is to disable the SCSI ROM if the card support that option. But then, you can't use SCSI-HD as boot drive.

maxtherabbit wrote:

since ASPI4DOS is handling the functions of the ROM after boot, could I just write a TSR to simply block accesses to the C800-CBFF region, is that even possible?

There is no way to do that in real-mode. BTW, if 8-bit ROM is the problem, then INT10h from VGA BIOS may be in trouble, too, which starts at C000 segment and typically 32KB.

Reply 111 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:
It depends, but I doubt ASPI4DOS is actually doing a full shadow of the SCSI BIOS. Most likely, it provides additional software […]
Show full quote
maxtherabbit wrote:

isn't that basically what ASPI4DOS is doing? sorry I know you struck that out but I just want to make sure I'm understanding everything

It depends, but I doubt ASPI4DOS is actually doing a full shadow of the SCSI BIOS. Most likely, it provides additional software layer to handle non-boot SCSI device, such as 2nd/3rd SCSI-HD, and may reuse ROM primitive SCSI functions to save resident code space when ROM presence is true. The best way to check this out is to disable the SCSI ROM if the card support that option. But then, you can't use SCSI-HD as boot drive.

maxtherabbit wrote:

since ASPI4DOS is handling the functions of the ROM after boot, could I just write a TSR to simply block accesses to the C800-CBFF region, is that even possible?

There is no way to do that in real-mode. BTW, if 8-bit ROM is the problem, then INT10h from VGA BIOS may be in trouble, too, which starts at C000 segment and typically 32KB.

ASPI4DOS requires ASPIDISK.SYS to support HDDs when the BIOS is disabled

I'm fairly certain my VGA has 16-bit access to its ROM, I think there was actually a DIP switch to set it

Reply 112 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
kjliew wrote:

It depends, but I doubt ASPI4DOS is actually doing a full shadow of the SCSI BIOS. Most likely, it provides additional software layer to handle non-boot SCSI device, such as 2nd/3rd SCSI-HD, and may reuse ROM primitive SCSI functions to save resident code space when ROM presence is true.

the more I think about what's going on the more I believe this is exactly what's happening - Maybe ASPI4DOS is NOT handling some of the more exotic INT13H functions and passing them back to the ROM, which would explain the lockups when launching SCANDISK, checkit, et al.

ASPI4DOS actually has a bug with HDD larger than a certain size (even the version that supports extended translation) so I would prefer to not use it anyway

Seems like shadowing the entire SCSI BIOS in low-RAM would fix everything, I would just have to learn how to write it. But it seems like the concept is sound - just copy the entire block to RAM and then change the INT13H entry points to the new spot right?

Reply 113 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

or here's an even more ridiculous/awesome idea:

what if I just disable the ROM on the card by jumper and then flash the code to a DIP-40 EPROM and tie that bad boy in to the ISA bus?

I'm really more of a hardware guy than software, it would probably take me far less time to design an 16-bit ISA ROM card than write a TSR - and I'd be saving 16k conventional memory

Reply 114 of 167, by georgel

User metadata
Rank Member
Rank
Member

Had you been a hardware guy you would have known that apart from the EPROM itself there could have been some glue logic and for example some 245 buffer(s) responding together with the EPROM to the SCSI BIOS address space. Disabling the EPROM alone does not guarantee you freeing the address space it occupies. Use IDE natural PC/AT HDD interface and stop bothering with this stupid adaptec SCSI card.

Reply 115 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
georgel wrote:

Had you been a hardware guy you would have known that apart from the EPROM itself there could have been some glue logic and for example some 245 buffer(s) responding together with the EPROM to the SCSI BIOS address space. Disabling the EPROM alone does not guarantee you freeing the address space it occupies.

Had YOU been a hardware guy you would know that 245 buffers tristate their outputs when their output is disabled

georgel wrote:

Use IDE natural PC/AT HDD interface and stop bothering with this stupid adaptec SCSI card.

No.

Reply 116 of 167, by Tiido

User metadata
Rank l33t
Rank
l33t

One thought is to use a 128KB BIOS chip and put the SCSI ROM in the lower 64KB, and any other BIOSes you have, freeing up the remaining space. You might need to introduce one extra address line if there's no spot for a 1Mbit EPROM.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 117 of 167, by georgel

User metadata
Rank Member
Rank
Member
maxtherabbit wrote:
Had YOU been a hardware guy you would know that 245 buffers tristate their outputs when their output is disabled […]
Show full quote
georgel wrote:

Had you been a hardware guy you would have known that apart from the EPROM itself there could have been some glue logic and for example some 245 buffer(s) responding together with the EPROM to the SCSI BIOS address space. Disabling the EPROM alone does not guarantee you freeing the address space it occupies.

Had YOU been a hardware guy you would know that 245 buffers tristate their outputs when their output is disabled

georgel wrote:

Use IDE natural PC/AT HDD interface and stop bothering with this stupid adaptec SCSI card.

No.

Stubborn guys who are explaining me what I have just explained them deserve nothing.

Reply 118 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
georgel wrote:

Stubborn guys who are explaining me what I have just explained them deserve nothing.

look I don't know if you don't speak good English or what your problem is, but you've contributed absolutely nothing to my thread

all you've done is shitpost about how my SCSI card sucks, couldn't even be bothered to read the thread before posting, and then finally took a totally unjustified shot at my hardware ability with some nonsense about 74 series logic

so, kindly, piss off

Reply 119 of 167, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

Just moved the 27c128 EPROM containing the SCSI BIOS from the SCSI card over to my 3c509b. Left the ROM address jumpers on the SCSI card set to C800, but removed the BIOS enable jumper. Software configured the 3C509B for a 16k PROM at C800, everything is working exactly the same as when the BIOS was physically on the SCSI card.

But how could this be??? Muh GLUE LOGIC