jakethompson1 wrote on 2023-08-29, 23:46:

Question: This means a 16-bit VGA BIOS at C000 and an 8-bit SCSI BIOS or XT-IDE Universal BIOS at C800 should not work. As the 286 CPU prefetches instructions from the 8-bit BIOS at C800, the VGA card should assert MEMCS16# causing the CPU to read garbage on the upper data lines. In practice, I don't think this has been a problem or at least I don't see discussion about it. Why not?

Because most VGA cards do not assert MEMCS16# for BIOS access, just for RAM access (A000-BFFF).

mkarcher wrote on 2023-08-30, 05:50:

jakethompson1 wrote on 2023-08-29, 23:46:

Question: This means a 16-bit VGA BIOS at C000 and an 8-bit SCSI BIOS or XT-IDE Universal BIOS at C800 should not work. As the 286 CPU prefetches instructions from the 8-bit BIOS at C800, the VGA card should assert MEMCS16# causing the CPU to read garbage on the upper data lines. In practice, I don't think this has been a problem or at least I don't see discussion about it. Why not?

Because most VGA cards do not assert MEMCS16# for BIOS access, just for RAM access (A000-BFFF).

Why odd/even BIOS chips on many AT clone era cards then? Just because of the size?

Reason for 16 bit bios firmware is improved performance on ISA boards that does not support firmware shadowing.

Cheers,

mkarcher wrote on 2023-08-30, 05:50:

jakethompson1 wrote on 2023-08-29, 23:46:

Question: This means a 16-bit VGA BIOS at C000 and an 8-bit SCSI BIOS or XT-IDE Universal BIOS at C800 should not work. As the 286 CPU prefetches instructions from the 8-bit BIOS at C800, the VGA card should assert MEMCS16# causing the CPU to read garbage on the upper data lines. In practice, I don't think this has been a problem or at least I don't see discussion about it. Why not?

Because most VGA cards do not assert MEMCS16# for BIOS access, just for RAM access (A000-BFFF).

Idk about the validity of this statement. Any VGA with odd/even ROMs either is by default or can be configured for 16 bit ROM accesses.

maxtherabbit wrote on 2023-08-30, 14:49:

mkarcher wrote on 2023-08-30, 05:50:

jakethompson1 wrote on 2023-08-29, 23:46:

Question: This means a 16-bit VGA BIOS at C000 and an 8-bit SCSI BIOS or XT-IDE Universal BIOS at C800 should not work. As the 286 CPU prefetches instructions from the 8-bit BIOS at C800, the VGA card should assert MEMCS16# causing the CPU to read garbage on the upper data lines. In practice, I don't think this has been a problem or at least I don't see discussion about it. Why not?

Because most VGA cards do not assert MEMCS16# for BIOS access, just for RAM access (A000-BFFF).

Idk about the validity of this statement. Any VGA with odd/even ROMs either is by default or can be configured for 16 bit ROM accesses.

Not all VGA ISA cards. Some have 1 rom IC. Can convert some to 16 bit ROM by adding 244 TTL buffer and second ROM IC if the card has the pads. This is documented in most datasheets for VGA chipset.
Good examples is WD vga chipsets documentations.

Cheers,

jakethompson1 wrote on 2023-08-30, 05:52:

mkarcher wrote on 2023-08-30, 05:50:

jakethompson1 wrote on 2023-08-29, 23:46:

Question: This means a 16-bit VGA BIOS at C000 and an 8-bit SCSI BIOS or XT-IDE Universal BIOS at C800 should not work. As the 286 CPU prefetches instructions from the 8-bit BIOS at C800, the VGA card should assert MEMCS16# causing the CPU to read garbage on the upper data lines. In practice, I don't think this has been a problem or at least I don't see discussion about it. Why not?

Because most VGA cards do not assert MEMCS16# for BIOS access, just for RAM access (A000-BFFF).

Why odd/even BIOS chips on many AT clone era cards then? Just because of the size?

I'm sorry, I was mostly thinking of later VGA cards that relied on BIOS shadowing, like most ET4000 cards. If those cards have two ROM chips, one is the BIOS and the other one most likely a register translation map for CGA/MDA emulation. Those old cards either have a jumper to disable 16-bit BIOS access, or later ones (IIRC the TVGA8900) can be programmed to disable 16-bit BIOS access. The VGA BIOS is initialized first, so it can scan the C000..DFFF area for concurring ROMs and disable the MEMCS16# support only if an 8-bit SCSI BIOS is present.

mkarcher wrote on 2023-08-30, 18:06:

The VGA BIOS is initialized first, so it can scan the C000..DFFF area for concurring ROMs and disable the MEMCS16# support only if an 8-bit SCSI BIOS is present.

This is the part I've always been curious about. I have long suspected they may use this method, but has anyone ever reversed any VBIOS code to prove any of them actually do it?

mkarcher wrote on 2023-08-30, 18:06:

I'm sorry, I was mostly thinking of later VGA cards that relied on BIOS shadowing, like most ET4000 cards. If those cards have two ROM chips, one is the BIOS and the other one most likely a register translation map for CGA/MDA emulation. Those old cards either have a jumper to disable 16-bit BIOS access, or later ones (IIRC the TVGA8900) can be programmed to disable 16-bit BIOS access. The VGA BIOS is initialized first, so it can scan the C000..DFFF area for concurring ROMs and disable the MEMCS16# support only if an 8-bit SCSI BIOS is present.

Background: We've talked about this before, but I was thinking of what an "AT-IDE" card would involve as I have never designed a board before. Between our past discussion and your IDE stackoverflow post and some discussion with maxtherabbit I get the basic idea. An "AT-IDE" would be for those situations where there is no built in BIOS support for IDE (more correctly WD1003-compatible) like the PS/2 30-286 and also no support for shadowing (or support for system/video BIOS shadowing but not arbitrary option ROMs). In those cases you would want the 16-bit wide option ROM.

The description of the VGA BIOS degrading to 8-bit access if an 8-bit card is in the system makes sense, but I wonder why that didn't crop up enough to hit period FAQs and so forth as something to watch out for.

The IDE side seems like it can be boiled down to: 74F521 comparators to derive CS1FX# and CS3FX#, a 74LS244 for the 3F7 case, two 74LS245s for all other cases, and one 74LS10 NAND and one 74LS32 OR to compute the output enables for the 244/245 chips.

Low244_1G# = Low244_2G# = CS3FX# OR IOR# OR (A0 NAND A1 NAND A2)
Low245_OE# = Low244_1G NAND (CS1FX# NAND CS3FX#) = (NOT Low244_1G#) OR (CS1FX# AND CS3FX#)
High245_OE# = IOCS16# OR CS1FX#

jakethompson1 wrote on 2023-09-01, 21:25:

An "AT-IDE" would be for those situations where there is no built in BIOS support for IDE (more correctly WD1003-compatible) like the PS/2 30-286 and also no support for shadowing (or support for system/video BIOS shadowing but not arbitrary option ROMs). In those cases you would want the 16-bit wide option ROM.

OK, I understand that. There is another possibility with its own drawbacks: You could copy the Int 13 handler for the AT-IDE card to the top of the base memory and decrement 40:13 (number of KB of base memory). That's how the Tekram Caching IDE controllers implemented the BIOS choice "Tekram Int13 copied to RAM". This will drop the conventional memory available, but will allow execution at full speed.

jakethompson1 wrote on 2023-09-01, 21:25:

The description of the VGA BIOS degrading to 8-bit access if an 8-bit card is in the system makes sense, but I wonder why that didn't crop up enough to hit period FAQs and so forth as something to watch out for.

Looking at the EISA specification you already cited, I see that MEMCS16# (they call it M16#) is sampled twice. Once at a time where the SA lines are not yet guaranteed to be valid for a minimal amount of time "at the end of the address phase", and a second time half a clock (~60ns) later. As I read the specification, if you assert MEMCS16# at the later time, your forfeit getting the MEMR# and MEMW# signals (just getting SMEMR# and SMEMW# half a clock later), and you likely forfeit the opportunity of getting 0WS honored. But the cycle should still be performed as 16-bit 1WS cycle. While it is specified this way in the EISA specification book, I have no idea how this works on actual 286-class machines, so your AT-IDE shouldn't rely on this method.

You can try decoding MEMCS16# from LA and SA, gated with BALE (so you do not decode SA before it is ready), but you need to find a method to make sure to stop driving MEMCS16# before the next pipelined cycle starts (e.g. by using a flip-flop that ensures MEMCS16# is only driven for one bus clock). This method should be optional, though, for example by a jumper interrupting MEMCS16#. If this way of disabling data steering on the board doesn't work, you need to provide the high byte on D0-D7 yourself, so I can't estimate whether the idea is worth the trouble.

jakethompson1 wrote on 2023-09-01, 21:25:

The IDE side seems like it can be boiled down to: 74F521 comparators to derive CS1FX# and CS3FX#, a 74LS244 for the 3F7 case, two 74LS245s for all other cases, and one 74LS10 NAND and one 74LS32 OR to compute the output enables for the 244/245 chips.

Do you have any practical use for 3F7? As I understand it, that's a legacy status port that's supported by old IDE drives only for WD1003 compatiblility. If you provide your own IDE BIOS on the AT-IDE card, you can write it as everyone else does it today, and never access 3F7. Omitting this port might simplify your logic design. Furthermore, the split 3F7 only works if the floppy controller does not drive the low 7 bits of 3F7h. Are you sure this is the case on the PS/2 Model 30-286?

jakethompson1 wrote on 2023-09-01, 21:25:

Low244_1G# = Low244_2G# = CS3FX# OR IOR# OR (A0 NAND A1 NAND A2)
Low245_OE# = Low244_1G NAND (CS1FX# NAND CS3FX#) = (NOT Low244_1G#) OR (CS1FX# AND CS3FX#)
High245_OE# = IOCS16# OR CS1FX#

Looks good. The whole address decoding logic (both 521s, the NAND and the OR) could also be implemented in a single PAL/GAL. You would need 11 inputs (A0-A9, IOCS16#) and provide 3 outputs. This will fit even in the most basic PAL16L8. Using discrete logic on the other hand makes building that card as a hobby project easier, as not everyone owns a PAL/GAL programmer.

Do there is a single and dual IDE decoding logic using discrete logic schematics for me to use? I preferred doing this on new design using 4 or 6 layer PCB as nearly 98% of time out there is done on 2 layer which is proven noisy when you have a sound card in same machine.

Some super I/O chipsets provides the decoding logic so you don't need to. Far more reliable than PAL/GAL.

For example SMC FDC37C932, FDC37C666GT and FDC37C665GT. These three can be put directly on the ISA bus and also these decodes the bus for IDE ports but use few discrete logic for buffering the ISA data bus between this and IDE ports. I like doing this correctly.
And yes you can get datasheet for these SMC chipsets.

No, I have not found the discrete logic decoding for the IDE yet. Also didn't have a chance to design a new board using this or SMC chipsets.

Cheers,

mkarcher wrote on 2023-09-02, 10:46:

Looking at the EISA specification you already cited, I see that MEMCS16# (they call it M16#) is sampled twice. Once at a time where the SA lines are not yet guaranteed to be valid for a minimal amount of time "at the end of the address phase", and a second time half a clock (~60ns) later. As I read the specification, if you assert MEMCS16# at the later time, your forfeit getting the MEMR# and MEMW# signals (just getting SMEMR# and SMEMW# half a clock later), and you likely forfeit the opportunity of getting 0WS honored. But the cycle should still be performed as 16-bit 1WS cycle. While it is specified this way in the EISA specification book, I have no idea how this works on actual 286-class machines, so your AT-IDE shouldn't rely on this method.

You can try decoding MEMCS16# from LA and SA, gated with BALE (so you do not decode SA before it is ready), but you need to find a method to make sure to stop driving MEMCS16# before the next pipelined cycle starts (e.g. by using a flip-flop that ensures MEMCS16# is only driven for one bus clock). This method should be optional, though, for example by a jumper interrupting MEMCS16#. If this way of disabling data steering on the board doesn't work, you need to provide the high byte on D0-D7 yourself, so I can't estimate whether the idea is worth the trouble.

The original 5170 AT and true clones latch MEMCS16# on the falling edge of BALE and do not sample it again, making the approach described in the second paragraph above impractical. You can of course assert it late, and accept the fact that you will only get 16bit transfer on much later systems, but that seems to defeat the purpose of this build.

mkarcher wrote on 2023-09-02, 10:46:

Do you have any practical use for 3F7? As I understand it, that's a legacy status port that's supported by old IDE drives only for WD1003 compatiblility. If you provide your own IDE BIOS on the AT-IDE card, you can write it as everyone else does it today, and never access 3F7. Omitting this port might simplify your logic design. Furthermore, the split 3F7 only works if the floppy controller does not drive the low 7 bits of 3F7h. Are you sure this is the case on the PS/2 Model 30-286?

This is a good point. I think it would come down to whether the XUB reads 3F7 or not, since I don't believe writing a brand new option ROM was in scope.

mkarcher wrote on 2023-09-02, 10:46:

OK, I understand that. There is another possibility with its own drawbacks: You could copy the Int 13 handler for the AT-IDE card to the top of the base memory and decrement 40:13 (number of KB of base memory). That's how the Tekram Caching IDE controllers implemented the BIOS choice "Tekram Int13 copied to RAM". This will drop the conventional memory available, but will allow execution at full speed.

There is also the issue, as old AMIBIOS offers, of where to store the Type 47 FDPT without BIOS shadowing, in the BIOS Stack Area (30:0) or to steal a KB of conventional memory like this. If there is some reason to have to do the latter then perhaps the Int 13h handler is free if it--or at least the common cases of read/write--fits.

mkarcher wrote on 2023-09-02, 10:46:

Looking at the EISA specification you already cited, I see that MEMCS16# (they call it M16#) is sampled twice. Once at a time where the SA lines are not yet guaranteed to be valid for a minimal amount of time "at the end of the address phase", and a second time half a clock (~60ns) later. As I read the specification, if you assert MEMCS16# at the later time, your forfeit getting the MEMR# and MEMW# signals (just getting SMEMR# and SMEMW# half a clock later), and you likely forfeit the opportunity of getting 0WS honored. But the cycle should still be performed as 16-bit 1WS cycle. While it is specified this way in the EISA specification book, I have no idea how this works on actual 286-class machines, so your AT-IDE shouldn't rely on this method.

You can try decoding MEMCS16# from LA and SA, gated with BALE (so you do not decode SA before it is ready), but you need to find a method to make sure to stop driving MEMCS16# before the next pipelined cycle starts (e.g. by using a flip-flop that ensures MEMCS16# is only driven for one bus clock). This method should be optional, though, for example by a jumper interrupting MEMCS16#. If this way of disabling data steering on the board doesn't work, you need to provide the high byte on D0-D7 yourself, so I can't estimate whether the idea is worth the trouble.

I only saw one M16# sample point in the diagrams on pages 36-38 of the pdf.
In the simple case of decoding M16# directly from LA<23:17> only, would you need this flip-flop?
I think the jumper on MEMCS16# is needed anyway if the user needs to force 8-bit operation. By disconnecting MEMCS16# from the card's memory address logic, the chipset never sees it and never asserts SBHE#.

mkarcher wrote on 2023-09-02, 10:46:

Do you have any practical use for 3F7? As I understand it, that's a legacy status port that's supported by old IDE drives only for WD1003 compatiblility. If you provide your own IDE BIOS on the AT-IDE card, you can write it as everyone else does it today, and never access 3F7. Omitting this port might simplify your logic design. Furthermore, the split 3F7 only works if the floppy controller does not drive the low 7 bits of 3F7h. Are you sure this is the case on the PS/2 Model 30-286?

I looked at Minix, as it bypasses the BIOS for disk access on an AT, and it does not read that port. I wonder about Xenix?
I should look at Win3.x WDCTRL as well, in case the board would make it into a 386.

jakethompson1 wrote on 2023-09-02, 18:05:

mkarcher wrote on 2023-09-02, 10:46:

Looking at the EISA specification you already cited, I see that MEMCS16# (they call it M16#) is sampled twice.

I only saw one M16# sample point in the diagrams on pages 36-38 of the pdf.

I gave the wrong source for the quote. I am looking at "EISA system architecture" by Tom Shanley and Don Anderson, pages 55-60 (as printed on the pages), not the official EISA specification.

jakethompson1 wrote on 2023-09-02, 18:05:

In the simple case of decoding M16# directly from LA<23:17> only, would you need this flip-flop?

No. If you just decode from LA23:17, as intended in the AT architecture, no additional circuitry is required.

jakethompson1 wrote on 2023-09-02, 18:05:

I think the jumper on MEMCS16# is needed anyway if the user needs to force 8-bit operation. By disconnecting MEMCS16# from the card's memory address logic, the chipset never sees it and never asserts SBHE#.

Are you going to add a '244 to forward the odd byte to D0..D7 if both A0 and SBHE# are high?

jakethompson1 wrote on 2023-09-02, 18:05:

mkarcher wrote on 2023-09-02, 10:46:

Do you have any practical use for 3F7?

I looked at Minix, as it bypasses the BIOS for disk access on an AT, and it does not read that port. I wonder about Xenix?
I should look at Win3.x WDCTRL as well, in case the board would make it into a 386.

As I understand it, reading 3F7 is only used used for diagnostic purposes to read back some internal control signals of the WD1003 hard disk controller. I suspect except for a rigorous WD1003-targeted POST (as is common in IBM hardware of that day) or lowest-level diagnostic software, no driver is ever going to read that port.