Image Map Image Map
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 35

Thread: Designing a 16-bit ROM card

  1. #11
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,497

    Default

    Quote Originally Posted by maxtherabbit View Post
    @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.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  2. #12

    Default

    Quote Originally Posted by eeguru View Post
    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.

  3. #13
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,497

    Default

    Quote Originally Posted by maxtherabbit View Post
    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.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  4. #14

    Default

    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

  5. #15

    Default

    1.jpg

    almost ready, just need to route it now

  6. #16
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,497

    Default

    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.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  7. #17

    Default

    Quote Originally Posted by eeguru View Post
    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

  8. #18

    Default

    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

  9. #19
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,497

    Default

    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.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  10. #20

    Default

    Quote Originally Posted by eeguru View Post
    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.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •