Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 32

Thread: Roast my design: 16-bit ISA memory board

  1. #1
    Join Date
    Mar 2015
    Location
    Colorado, USA
    Posts
    104

    Default Roast my design: 16-bit ISA memory board

    Inspired by the Lo-Tech 1MB RAM board which is great for adding UMBs to XT class systems, I set out to design a 16 bit version for AT class systems. It can selectively fill 0-512K in 64KB chunks (which is probably already maxed out on most ATs) and 512-1024K in 32K chunks, though obviously some of those areas won't ever be available for memory anyway.

    Attached are the schematics and design I came up with. After they're tested and debugged, I intend to make PCBs and maybe built boards available to the community. Anyone feel like taking a look to tell me what mistakes I've made?

    Schematic: https://drive.google.com/file/d/17V2...ew?usp=sharing
    Board Layout: https://drive.google.com/file/d/1T_t...ew?usp=sharing
    GAL code: https://drive.google.com/file/d/1dv9...ew?usp=sharing

  2. #2
    Join Date
    Mar 2015
    Location
    Colorado, USA
    Posts
    104

    Default

    Oops, meant to upload a PDF of the schematic: https://drive.google.com/file/d/1vt1...ew?usp=sharing

  3. #3

    Default

    Two things:

    1) In order to get true 0-wait, I think you are going to need to assert MEMCS16# before the lower 20 bits of address are on the bus. I.e. before the rising edge of BALE

    2) CEH = MEMSEL & BHE;
    I don't think this is going to work. The system board holds SBHE# low when doing a word transfer.

    If I were you, I would just ignore the SBHE# signal. Your card is not intended to be backwards compatible with 8-bit buses nor does it have any steering logic to put the high byte on the lower data bus, so I don't see why you'd need it as long as you assert MEMCS16# appropriately.
    Last edited by maxtherabbit; November 23rd, 2019 at 07:23 AM.

  4. #4
    Join Date
    Mar 2015
    Location
    Colorado, USA
    Posts
    104

    Default

    Quote Originally Posted by maxtherabbit View Post
    Two things:

    1) In order to get true 0-wait, I think you are going to need to assert MEMCS16# before the lower 20 bits of address are on the bus. I.e. before the rising edge of BALE

    2) CEH = MEMSEL & BHE;
    I don't think this is going to work. The system board holds SBHE# low when doing a word transfer.

    If I were you, I would just ignore the SBHE# signal. Your card is not intended to be backwards compatible with 8-bit buses nor does it have any steering logic to put the high byte on the lower data bus, so I don't see why you'd need it as long as you assert MEMCS16# appropriately.
    Thanks for the input! You bring up some good points...

    1) Well that's unfortunate... So it seems zero wait states might not be possible for this board then. Asserting MEMCS16# based on a decode of LA17-LA23 like the 5170 technical manual suggests wouldn't work as that only gives us 256k "chunks" of memory and in the UMB area that might clash with things like VGA BIOS ROMs that could be 8-bit. I was hoping some of the references I can find online that seem to suggest MEMCS16# is samples after BALE goes high were correct (here for example)

    2) I'm getting conflicting info on the polarity of BHE. The technical manual and HwB agree that it is active high, but other sites like here say it is SBHE#... I'll take your word for it and fix that in the GAL code

    As for ignoring it entirely, that makes sense for reads, but are all writes guaranteed to be 16 bit?

  5. #5

    Default

    Quote Originally Posted by ab0tj View Post
    Thanks for the input! You bring up some good points...

    1) Well that's unfortunate... So it seems zero wait states might not be possible for this board then. Asserting MEMCS16# based on a decode of LA17-LA23 like the 5170 technical manual suggests wouldn't work as that only gives us 256k "chunks" of memory and in the UMB area that might clash with things like VGA BIOS ROMs that could be 8-bit. I was hoping some of the references I can find online that seem to suggest MEMCS16# is samples after BALE goes high were correct (here for example)

    2) I'm getting conflicting info on the polarity of BHE. The technical manual and HwB agree that it is active high, but other sites like here say it is SBHE#... I'll take your word for it and fix that in the GAL code

    As for ignoring it entirely, that makes sense for reads, but are all writes guaranteed to be 16 bit?
    First let me say I'm no expert, I've just only designed my first ISA card recently (documented here: http://www.vcfed.org/forum/showthrea...-bit-ROM-card/

    I think different chipsets sample MEMCS16# differently. I'm still trying to figure that out myself.

    As for SBHE#, it is definitely active low. I believe that all writes will in fact be 16-bit if MEMCS16# is properly asserted. We had better hope so, because if the system does a split transfer to an odd address, it's going to write to D[7:0] so you're screwed anyway
    Last edited by maxtherabbit; November 23rd, 2019 at 09:13 AM.

  6. #6
    Join Date
    Mar 2015
    Location
    Colorado, USA
    Posts
    104

    Default

    Quote Originally Posted by maxtherabbit View Post
    First let me say I'm no expert, I've just only designed my first ISA card recently (documented here: http://www.vcfed.org/forum/showthrea...-bit-ROM-card/

    I think different chipsets sample MEMCS16# differently. I'm still trying to figure that out myself.

    As for SBHE#, it is definitely active low. I believe that all writes will in fact be 16-bit if MEMCS16# is properly asserted. We had better hope so, because if the system does a split transfer to an odd address, it's going to write to D[7:0] so you're screwed anyway
    Thanks. I'll definitely be reading the whole thread about your ROM card, that's some good info. It sounds like I *might* be OK asserting MEMCS16# as soon as the address lines match, since BALE goes high (making the address latches transparent) before any of the memory strobes go active. Of course none of this logic stuff happens with zero delay, but I think it might even get asserted before BALE goes back low. I'll keep researching this topic because I see no other way of making 0WS happen in this memory area

    On the 8-bit writes I wasn't thinking of a split 16-bit transfer, but specifically an 8 bit write to an odd address. MOV m8,AL for example. I'm not sure if that is a thing in x86 land but it seems conceivable.

  7. #7
    Join Date
    Mar 2015
    Location
    Colorado, USA
    Posts
    104

    Default

    Just a third confirmation, the 5170 schematic shows SBHE# is just latched and buffered from the CPU's BHE# signal. Yes, definitely active low.

  8. #8
    Join Date
    Mar 2015
    Location
    Colorado, USA
    Posts
    104

    Default

    http://www.minuszerodegrees.net/oa/O...n%20Option.pdf
    This is interesting. Looks like IBM's "official" memory expansion board controls the data buffers in the same way - low bits controlled by A0 low and high bits controlled by BHE# low. They also derive MEMCS16# from a direct decode of the LA23-LA17 lines, so that doesn't really help me on if it's possible to add SA19-SA15 into that equation and still meet timing to get 16-bit transfers. And at that rate, it's not yet clear to me if I'm making things better or worse by latching the LA lines as part of that equation.

    Research shows that 0WS might not be worth pursuing as the timing requirements might be impossible to meet on an 8MHz AT no matter how fast the logic is. I'll leave the jumper in there anyway and see how things go.
    Last edited by ab0tj; November 23rd, 2019 at 07:33 PM.

  9. #9
    Join Date
    Mar 2015
    Location
    Colorado, USA
    Posts
    104

    Default

    Looks like maybe even 1WS 16-bit transfers aren't possible on the AT/5170 unless using 128k blocks: https://en.wikipedia.org/wiki/Talk%3...ompatibilities

  10. #10
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,504

    Default

    Quote Originally Posted by ab0tj View Post
    Looks like maybe even 1WS 16-bit transfers aren't possible on the AT/5170 unless using 128k blocks: https://en.wikipedia.org/wiki/Talk%3...ompatibilities
    You can achieve 1 wait but not zero unless you decode LA and assert combinatorially within 1 CLK in combination with asserting ZWS# within 1 cycle of the strobe assertions.

    BTW, your .oe logic is messed up in the CUPL file. For a single-side drive (high or low + Z), you should be setting the value of the FF to a 1 or 0 and assigning the non-Z logic to the .oe expression; not both.
    "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

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
  •