Designing a 16-bit ROM card

[eeguru]

@eeguru One thing I'm still not clear on based on what you said - if a device does assert MEMCS16# early, does NOWS# also have to be asserted to achieve zero-wait? Or does the system assume 0-wait when it samples MEMCS16# the first time? Conversely, if you assert MEMCS16# after the memory strobes are active, what affect does asserting NOWS# have if any?

I'm unclear on that as well. I don't have my full test card built yet to empirically check it. Asserting ZWS# in addition to MEMCS16# would be a safe bet. You could even use the same tri-state or OC/OD driver. It's possible some chip-sets might make different assumptions too.

[maxtherabbit]

That clarifies it a little. But it seems the problem is exactly how I stated it. The AST card is asserting MEMCS16# already for the designated lower memory segments - which disables the bus steering logic for any 8-bit devices in that area. So if you are just trying to solve your issue and not a generic one with a 16-bit option ROM card, you don't have to care about MEMCS16. The AST card is handling that for you. Even it were never asserted, your 16-bit card would still work with broken 8-bit steered accesses. If you are trying to make it generically useful outside of the AST case, then yes, just qualify your card CS with SA19 on down and the 8-bit SMEMR signal (lower 1M only) - optionally feeding it back to MEMCS16#.

Almost, the AST card doesn't assert MEMCS16# for those segments until it has been programmed by the REMM.SYS driver to do so at boot time. So in order for my card to work, it does need to assert MEMCS16# so it can be read (and booted from) before the AST card is initialized in DOS.

[eeguru]

Almost, the AST card doesn't assert MEMCS16# for those segments until it has been programmed by the REMM.SYS driver to do so at boot time. So in order for my card to work, it does need to assert MEMCS16# so it can be read (and booted from) before the AST card is initialized in DOS.

Good point. Unless you wanted to do your own bus steering logic based on SBHE. It's probably not as complicated as it sounds - just a an extra 244/245 to route the high ROM to the lower data path on SBHE# inactive and A0 high.

[maxtherabbit]

I'm not sure what that would do for me other than making the card PC/XT compatible. I guess it might be worth it

[maxtherabbit]

1.jpg

almost ready, just need to route it now

[eeguru]

Looks like you are using something like a 27C1024 in a 40-pin DIP. Any reason on that over dual 8-bit parts? Just curious.

[maxtherabbit]

Looks like you are using something like a 27C1024 in a 40-pin DIP. Any reason on that over dual 8-bit parts? Just curious.

Parts commonality with the Neo-Geo BIOS? lol

I guess I just decided that there was no point in dealing with the (admittedly trivial) task of interleaving the ROM data, and the very minor additional parts cost increase of another EPROM and socket, if I wasn't going to bother with 8-bit bus steering logic at all

[maxtherabbit]

hmmm looking at how much it's going to cost me to get a prototype run of boards with ENIG for the edge connectors I'm back to thinking of using 2 8-bit parts and a buffer to route the high ROM to the lower data bus for backwards compatibility

[eeguru]

ENIG will rub off in just a few insertions. I wouldn't bother. It has about the same endurance for fingers as HASL. Some discount board houses like pcbcart.com offer true hard gold (thicker plating) for not a lot extra.

[maxtherabbit]

ENIG will rub off in just a few insertions. I wouldn't bother. It has about the same endurance for fingers as HASL. Some discount board houses like pcbcart.com offer true hard gold (thicker plating) for not a lot extra.

Thanks, I'll check that out. I had ruled out true hard gold due to cost but obviously that would be ideal.