2

I'm looking to create something to multiplex N 64 bit signals together. The goal of the project is to provide digital switching between a library of old cartridge based video games.

Essentially I want to have a number of cartridges always 'hooked up', but only one set of lines connected to the console. I could do it with 64 single output multiplexers but its seems like I'm going about it the wrong way. Any suggestions on ways to simplify the design?

P.S. - I've been thinking about this a little more, and I have an idea for an alternative approach but I'm not quite sure how to execute it. I don't really need to quickly switch between the 64 bit inputs with any sort of speed, which is what a multiplexer would support. All I really need to do is to tie a given cartridge to the console, while electrically isolating all of the other cartridges. For that, I would essentially need 64 relays for each cartridge. I'd like to avoid that, so I wonder if there are any sort of on/off pass-through chips or circuits I could construct. All I would need is something with 64 ins/outs, +1 to open or close the 64 switches. Ever heard of anything like that?

Chetan Bhargava
  • 4,632
  • 5
  • 27
  • 40
Kallin Nagelberg
  • 121
  • 1
  • 4
  • so you want to select 1 of 64 1-bit inputs with a 6-bit control input? or do you want to select 1 of N, 64-bit bus inputs to a 64-bit bus output? I think you're asking for the latter but I want to make sure... if so can you quantify (or at least bound) N? – vicatcu Feb 19 '13 at 04:08
  • 1 of N 64 bit inputs to a 64 bit output. For now the bound can be low, like 4 or 8, but eventually I would like to be able to do upwards of 1000. – Kallin Nagelberg Feb 19 '13 at 04:41
  • ... right so you want to have the scalability to multiplex 64000 lines to 64 lines ... I think you had better put a lot of thought into a solution that has some kind of modular routing – vicatcu Feb 19 '13 at 05:18
  • 2
    If this just for your personal use I suspect the easiest solution would be to copy all the cartridges to a large memory device and build a form of ROM copier / emulator. I'm pretty sure in the past I've seen similar projects to do that on several consoles. – PeterJ Feb 19 '13 at 05:25
  • That would be more practical probably, but I'm interested in making something that utilizes all the original hardware at run-time. – Kallin Nagelberg Feb 19 '13 at 05:27
  • 2
    Since you say it's partly driven by nostalgia, could your solution include a mechanical aspect? I'm thinking that a CD changer/jukebox sort of mechanism might actually be simpler/cheaper at the scale you're talking about. – HikeOnPast Feb 19 '13 at 06:09
  • Remember that whatever scheme you come up with you are going to need several stages of buffering. Say for example that all the address lines could be sent to all 1000 cartridge in parallel. You will have practical limits of how many buffers that the address out of the console can drive. Let us say that maybe 10 buffers are the limit. Those each of those would need to drive a second stage of 10 buffers. Each of those total of 100 buffers could the drive to 10 cartridges to support your 1000 total. – Michael Karas Feb 19 '13 at 06:50
  • The data path coming back from the cartridges can most likely be buffered with a tri-state buffer at each module connection. There would be a practical limit of maybe tri-stating 10 of these buffers together onto one set of wires. So a second rank these tristate buffers can be used to gate 10 of the first busses to a second 10 way tri-state bus. There would be a total of 100 of these second stage buffers driving into ten more second level tri-state buses. These 10 second level buses can feed into a third and final set of the tri-state buffers onto the final bus back to the game console. – Michael Karas Feb 19 '13 at 07:02
  • As above I say it is possible to buffer out to 1000 cartridges with 3 stages of buffering going out and another 3 coming back. The buffering is necessary due to distributed capacitance of all the wiring. You will have to very carefully consider the reading access time available in the design of the game console logic. It is likely that the speed of the cartridges themselves is not a whole lot faster than the read cycle coming out of the console. For this reason the analysis has to be done to ensure that 6 stages of buffering still permit the console to fetch valid data from the cartridges. – Michael Karas Feb 19 '13 at 07:10

3 Answers3

3

Do these cartridges have any kind of "cartridge select" pin? If so, you could conceivably connect all the lines except for the select in parallel and just drive the appropriate select line.

If they don't have a select line, do the cartridges have any address(es) which cause the data lines to be released/"driven" to high impedance? If so, do the cartridges have a common address for all of the cartridges which do this? If they do, there's your cartridge select -- connect the data lines in parallel and connect as many address lines in parallel as you can; that gives you fewer lines you have to multiplex.

Failing all of that, you're stuck with a high pin count FPGA to do it, which is probably your best solution. I think that no matter what you'll want to go through the above exercises to minimize the number of uniquely driven lines. It sounds like an interesting project. Good luck!

akohlsmith
  • 11,307
  • 1
  • 36
  • 62
  • Even with an FPGA, the biggest pincount at the moment is ~2k pins or 30 cartriges. – stanri Feb 19 '13 at 05:07
  • That is why I said you want to go through and find out what you can get away with; even if there is no way to isolate them you need to only isolate the data signals; there's no need to isolate the address/control lines, barring some kind of goofy (not just ROM) cartridge. In fact, if it is just ROM, there'll very likely be an OE# signal which is the only one you really need to have unique for every cartridge. There have been some really goofy game systems though, so without more detail it's just guessing. – akohlsmith Feb 19 '13 at 05:10
  • yeah. good point on the OE lines - that would be ideal. – stanri Feb 19 '13 at 05:15
  • Thanks, I'll definitely see if I can simplify by taking advantage of the cartridge architecture. I wonder what would happen if I just kept everything except 5v and gnd all connected in parallel.. Probably burn something :P http://www.gamesx.com/cartouts/gennycart.htm – Kallin Nagelberg Feb 19 '13 at 05:19
  • FYI someone suggesting something similar here, http://www.atariage.com/forums/topic/131959-building-a-sega-genesis-jukebox-game-switcher/ . "It seems like just masking the chip selects should be enough for most purposes (C_OE, C_CS)" – Kallin Nagelberg Feb 19 '13 at 05:34
  • @StaceyAnne I see OE# CE# and more interestingly, #RST. I would take two cartidges to start with, wire up everything but those in parallel, and connect 100 ohm resistors from the cartridge data pin to the "shared" data pin. then step through a few addresses with the right OE/CE lines asserted and measure across the 100 ohm resistors. if you have more than a few millivolts across the resistor, the data line is being pulled in two different directions. – akohlsmith Feb 19 '13 at 12:04
2

What you could use is a SP64T switch (single pole, 64 throw), which would basically open or close 64 connections with one switch. Naturally, you'd need one per cartridge.

Or, you could use a bidirectional buffer IC and use the OE to enable and disable.

stanri
  • 5,382
  • 2
  • 29
  • 56
  • Yes that sounds exactly like what I need. One per cartridge would be fine. I've tried searching a little bit and will continue to do so, but would you be able to point me to any suggested ICs? – Kallin Nagelberg Feb 19 '13 at 05:13
  • That would be a 64pole n throw switch. In the good old days you could build them using Yaxley wafers http://antiqueradios.com/forums/viewtopic.php?f=15&t=174009 but a 64-pole one would make a heroic "clunk" when you turned it! –  Feb 19 '13 at 09:24
  • I once opened up an analogue monitor switch box and found the smaller version of that, it's what gave me the idea :) – stanri Feb 19 '13 at 09:46
  • Open up an old oscilloscope to see the highest form of that art! –  Feb 19 '13 at 09:51
0

It sounds like you're going to design a big back-plane. Even for a few cartridges, the number of lines is going to grow too rapidly to do this job with discrete components. The solution, I think, is to put an FPGA on your backplane, and implement the multiplexing function in Verilog. That should be a super easy FPGA to code up too.

vicatcu
  • 22,695
  • 14
  • 81
  • 156
  • Thanks, but I'm hoping to find a solution more cost effective and scalable than an FPGA, both in terms of number of cartridges, and overall cost of the design. – Kallin Nagelberg Feb 19 '13 at 04:50