Image Map Image Map
Page 4 of 4 FirstFirst 1234
Results 31 to 35 of 35

Thread: Designing a 16-bit ROM card

  1. #31

    Default

    1.jpg2.jpg

    in production now!

  2. #32

    Default

    isa1.jpgisa2.jpg

    PCB came out pretty nice, just need to assemble and test

  3. #33

    Default

    Big problems with the logic. I assembled the circuit as designed and then went through several bodges which reveled the ISA signals work quite differently than I was expecting.

    #1) Qualifying the byte shift on A0 and SBHE# did not work. With the unmodified circuit, I was simply getting the low bytes repeated when the system accessed the ROM using 8 bit transfers. Forcing the system into 16 bit transfer mode produced sane reads with proper data and byte order.

    Solution: instead of inverting A0 and SBHE# then NORing them, I just drove the next downstream gate with A0 directly. This allowed the card to function properly with 8 bit transfers, but only when inserted in a 8-bit slot (more on that later)

    #2) My motherboard/chipset on the machine I've been using to test does NOT respect my MEMCS16# assertion. In the original design, I was qualifying this assertion based on SMEMR# and decoding a matching address. I considered that maybe waiting for the command strobe to go active was too late, so I tested asserting MEMCS16# whenever the 688 matched a valid address. Still did not work, system performed only 8 bit transfers from the card unless forced by the AST driver switch.

    Solution: none, card must support 8 bit transfers correctly in order to boot on this system

    Incidentally, asserting 0WS (on this card, for ROM reads) made ROM reads fail when they would otherwise work, not sure why since everything should be fast enough, but that's not a priority now.

    #3) Here's the real pisser, using the 541 to shift the high byte down to the lower data bus only works when the card is in an 8 bit physical slot. It would appear from looking at the nonsense reads of high bytes when the card is installed in a 16 bit slot, that there is bus contention. From this fact I can only assume that something else is driving the high byte of the system data bus when the system is doing 8 bit split transfers. WTF over?

  4. #34

    Default

    Digging a little deeper into my test results to analyze what's going on here:

    The problems with SBHE# and the high byte of the system data bus only occur on the second half of split transfers (high byte in 8-bit mode.)

    SBHE# is high on the first (low) byte of the split transfer, so my original design is handling that transfer properly. However, it seems on my chipset/motherboard that SBHE# is getting pulled low again when it goes to transfer the high byte of the split transfer. I presume this is related to address piplining.

    With respect to the bus contention: I've verified that if I force the 541 to drive the low byte of the system data bus with the high ROM, that it will transfer "correctly" for the first byte of the split transfers. I.e. the ROM data is not correct but the high bytes are getting read as low bytes without corruption. So what's happening is that when the chipset goes to transfer the second byte of the split transfers, it is either driving or allowing another device to drive the high byte of the system data bus. Presumably because it assumes the active device on the system bus is 8-bit only and won't be affected.

    I figure I can solve both of these issues by qualifying the byte shift only on A0 and using an addition 541 or 244 to buffer the high byte of the system data bus from the card. I will just set it up to drive both upper and lower bytes of the data bus on odd addresses as it is currently, but the buffer will prevent the high byte contention from corrupting the data on the lower half of the bus. This will maintain compatibility with "odd address" transfers in 16-bit mode - where SBHE# is asserted low and A0 is high and the system expects the odd addressed byte to appear on the upper byte of the bus. My main concern with this approach is potentially adversely affecting whatever other device on the system is driving the high byte of the system bus during the split transfers.
    Last edited by maxtherabbit; November 11th, 2019 at 05:43 AM.

  5. #35

    Default

    Quote Originally Posted by maxtherabbit View Post
    This will maintain compatibility with "odd address" transfers in 16-bit mode - where SBHE# is asserted low and A0 is high and the system expects the odd addressed byte to appear on the upper byte of the bus.
    The more I think this over, I wonder if this edge case even exists. There are various documentary sources on the internet that describe a case where the system board pulls SBHE# low and A0 high, and expects a single byte on the upper 8 bits of the system data bus. But I wonder more and more if this would ever occur in practice? Why bother with such a transfer when you know the bus target supports 16-bit transfers? Why not then just transfer a full word on the even address located immediately prior to the desired byte??

    The observed behavior of my specific system board, seems to contradict the very possibility of performing these "odd address 16-bit transfers" since it appears to be pulling SBHE# low at some point in the second cycle (A0 = high) of split 8-bit transfers, yet still expects the data to appear on the lower byte of the system data bus.

    I'm thinking for maximum compatibility I should buffer my high ROM with two different 244s or 541s - with each one connected to the lower and upper half of the system data bus, and enabling only one of them at a time, which one being qualified by A0.

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
  •