1
\$\begingroup\$

I have a microcontroller "A" and 8-bit game console "B" that I'd like to be able to share a 2Kx8 SRAM address space. "A" will only write to RAM, and "B" will only read. A dual-port SRAM would handle this. However, the DIP dual-port SRAM I can find all seems to be obsolete (or out of stock and prohibitively expensive). I realize with DIP that obsolete is just a matter of time, and it seems like that time may have already come for DIP dual-port RAM. So, I'm looking for an alternative, if there is one.

Is there a way to accomplish this using as few 5V non-obsolete DIP IC's as possible? I'm hoping that the fact that there's no need to support R/W for both "A" and "B" provides an opportunity.

Some other limitations:

  • I only have around 12 square inches (3"x4") of board space on one side. I suppose I could use the back too, but I'd have to be able to access the pins on the other side to solder them. So basically I'd only be able to overlap a smaller and larger IC. I also have limited vertical space, so I won't be able to stack boards or such, plus that sounds like an assembly nightmare.
  • I have control over how "A" is wired and behaves, but "B"'s wiring and operation is fixed and is limited to reading from addresses spanning A0-A13 (so there are 3 spare address lines A11-A13 to work with, although they can only be set for around 300ns while reading a byte, they aren't GPIOs), and D0-D7 for data. I don't have access to "B"'s clock.
  • I'm dead-set on using DIP, for aesthetic reasons (so I don't want to use SOIC adapter boards or such).

I considered hooking "B" directly to "A" with no SRAM in the middle, and serving up "A"'s internal SRAM to "B". By the numbers, I believe "A" is just barely fast enough to accomplish that. However, "B" will be reading pretty much constantly. Processor "A" wouldn't really have any clock cycles left over to be useful, so I scrapped that idea.

Another idea I had was to use two 2Kx8 SRAMs. Processor "A" could write to one of them while "B" read from the other. Then, when "A" was done writing to RAM, it could toggle an input to switch the roles of the two SRAMs. I based this on the concept of double-buffered graphics (and, indeed, Wikipedia even mentions it as an alternative to dual-port RAM: https://en.wikipedia.org/wiki/Multiple_buffering), so I feel like I'm on the right track. I think I could accomplish this with a bunch of quad bilateral switches (74x4066 or similar, 74x245 also seemed possibly useful), but for my application they waste pins and I'm not sure that I'd have enough space. I found an octal FET bus switch (74x3245) that seemed perfect, but it was obsolete.

When Googling, I saw someone mention using an SRAM twice as large so the writer would be in a different part of the RAM than the reader, but I feel like I'd still have address and data line contention with that approach, unless I'm missing something obvious.

\$\endgroup\$
8
  • \$\begingroup\$ These days maybe an FRAM and an MCU? Something like FM25V10-PG. Yes, it's serial. Yes, it's a lot more memory. But yes, it's also currently available and in-stock in various places. Add an MCU and you can set up the ports as you like. (Given the 8-bit system, I suspect low MHz, at best.) Could you consider that? (I have lots of old 1970's and 1980's SRAM chips. But I'm not selling them.) Or you could just get an MCU with at least 2kx8 to begin with, I suppose, and forget about the FRAM. They do come in DIP. \$\endgroup\$
    – jonk
    Sep 4, 2021 at 5:00
  • \$\begingroup\$ It seems that the DIP version of the IDT 7130 is still available though not for much longer. mouser.co.uk/ProductDetail/Renesas-IDT/… \$\endgroup\$ Sep 4, 2021 at 5:12
  • \$\begingroup\$ @calamari I understand you can control "A", and that is good. I'd like to see all the pins for "B" and the details for its operation. I don't see anything close to sufficient detail in your question, yet. So I'm not sure I can say much towards the part where you say that you "don't know how to pull it off yet.". I'm also stuck -- short on info. \$\endgroup\$
    – jonk
    Sep 4, 2021 at 8:19
  • \$\begingroup\$ @calamari What's their bus clock rate and how many clocks are involved in a read cycle? Do you have an actual read-ROM timing diagram for the "B" system? (I don't want to assume that just because you can find a datasheet on the ROM that they are operating it at a presumed maximum speed for the part.) Have you scoped all this out, yet? Or going on assumption? \$\endgroup\$
    – jonk
    Sep 4, 2021 at 8:28
  • \$\begingroup\$ @calamari Also, I gather that "B" has its own behavior you cannot modify. (Which I think we need to know a lot more about than we do.) And I gather that "A" is under your control. But there's also little info on the transactions that must be supported for "A". Do you have to burst data from "A" into the memory, quickly? Or can you drag it out in some fashion? You know a lot, but I'm feeling mostly ignorant about what's needed right now. \$\endgroup\$
    – jonk
    Sep 4, 2021 at 8:38

1 Answer 1

1
\$\begingroup\$

The old trick is to get a very fast ram chip. The old 32kx8 cache rams should be plenty quick as they were better than 35ns usually. They’re also skinny dip. For the address mux you could use 74x157, 74x244 or 74x245. For the data bus mux, two 74x245. That’s the easy part, the tricky part is the logic that determines the start of cpu B’s bus cycle. From that point you know you have X time to sneak in, perform cpu A’s read or write then switch back with plenty of time to satisfy cpu B. If cpu B takes 300ns for a read, you’ve got plenty of time. Cpu A needs to be told to wait or implement a bit-bashed bus cycle that can be held off.

Thinking a little more, if you bit bash cpu A bus cycle, use 74x574 for the address latches. Cpu A can load the address it wants into the latches, set a request and the logic waits for a cpu B cycle then does its magic and flags when it is done. For the logic I’d use a GAL, but that might be counter to your retro leanings.

For a recent retro project, i just used a 600MHz microcontroller to sniff the bus and do the magic. Much simpler. Took about 60% of the cpu time though.

Best if I expand on the 'old method'- For point of reference, let's say cpu A is an AVR mega328. That micro is rather limited on port pins, so we need to be a little creative. Using 74x574 tristate D registers means we can create an 8 bit bus from the AVR and connect this to the two 74x574 and use them as an address latch - the AVR writes the low address to one, then the high address to the other. Then the AVR could present the write data to the 74x245 then set a flag to the magic logic to say we want to write. The logic would wait for the beginning of a bus cycle on cpu B, disable the 3state address buffers and data buffer from cpu B to the ram, then enable the address registers (these have the address already), then enable the data bus buffer for cpu A then perform a write cycle to the ram, say in less than 150ns. Once done, it disables the cpu B registers and buffer and enables the cpu A buffers. cpu A knows no difference.

Draw up a block diagram to get a clearer picture.

Then work on a timing diagram and incorporate the enable/disable times of the buffers etc, the setup and hold times of the ram.

From that you can formulate the logic and the timing required. How you ensure the timing be it through using a finite state machine or clocked logic or using gate and r/c delays is up to you.

The Apple II and many other computers of the day performed similar techniques to interleave the video accesses to memory with cpu access.

\$\endgroup\$
8
  • \$\begingroup\$ Hmm. Was that 600 MHz MCU in a DIP? I think the OP wants that. ("I'm dead-set on using DIP, for aesthetic reasons...") \$\endgroup\$
    – jonk
    Sep 4, 2021 at 8:31
  • \$\begingroup\$ @jonk. DIP, yes it was, albeit a teensy4.1. Note, the 600MHz cpu was how I solved a similar problem for a point of reference. \$\endgroup\$
    – Kartman
    Sep 4, 2021 at 8:35
  • \$\begingroup\$ I suspect that does NOT qualify. ("I don't want to use SOIC adapter boards or such.") \$\endgroup\$
    – jonk
    Sep 4, 2021 at 8:39
  • \$\begingroup\$ @jonk, I wrote - ‘for a recent project I used....’ I know it would not satisfy the OP’s requirements and it is 3V logic as well. [Edited by a moderator.] \$\endgroup\$
    – Kartman
    Sep 4, 2021 at 8:45
  • 1
    \$\begingroup\$ @Kartman Thank you for your answer! I bet it's telling me exactly what I need to know, but I don't understand it yet, sorry! How do I accomplish the "easy part"? Could you explain a little more about how that works? Also, could you please explain "load the address it wants into the latches, set a request and the logic waits"? Thanks! \$\endgroup\$
    – calamari
    Sep 4, 2021 at 8:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.