Board for testing famicom expansion audio

I'd like to build something similar to a TNS-HFC3 which lets me run code from one cartridge (i.e. a PowerPak) while connecting a second cartridge that will use its expansion audio. My knowledge of electronics is somewhat basic, so I could use some advice about how to accomplish it.

Possible plan:

The device will have two cartridge connectors. The host connector will have all pins connected except Audio in / Audio out.

The expansion connector will connect only: GND, +5V, M2, PRG *, and Audio in/out. The PRG D* lines will need to be write only for the expansion; would a diode on each of them accomplish this?


So, my question is would this work, or would connecting two cartridges like this have problems? Do I need to buffer some or all of the lines somehow to keep the two cartridges from interfering with each other? Feel free to laugh at me if I'm way off base here.

I know for sure that you'll have to make sure the "expansion connector" isn't accessed during reads; it'll cause bus conflicts between the two cartridges as you mentioned. Something like {PRG /CE} OR {PRG R/W} going to the expansion {PRG /CE} should do this trick for all mappers except MMC5 and N163, which would need also !{PRG R/W} AND {PRG A14} going to expansion {PRG A14}. And then, it would be mostly fine. I'm afraid diodes on D* lines won't do the trick, though: it will interfere with reads, no matter how you place your diodes.

So as long as you properly ADDRESS the cart properly during reads you'll be okay without anything special. It depends on what kind of address map you're interested in. If you're really only doing sound features it might not be too hard. Do you need to actually READ from your cartridge? If so as long as your writes to the powerpak and sound cart don't interfere with each other it'll be simple. If you do need to read and know exactly what addresses you need to read from it might not be that big of deal either. Perhaps you could realign the sound cart's read registers to $6000-7FFF. Making the special cart like you're saying would allow you to easily perform tricks like that by redirecting addresses (no buffers etc). Additionally if you manage to design the mapper you're running on the powerpak you could resolve any conflicts.

It's hard to answer you're question well since you haven't given any specifics on what mappers you want to work together. But generally your choice of mapper on the powerpak and addressing scheme with your device would give you the power to do quite a bit. We'd need more specifics to give more detail or a better answer.

It's probably fair to assume he'll want all of the 5 non-FDS sound generators: MMC5, VRC7, VRC6, SS5, N163. Writes should be all that's necessary.

To rephrase from the wiki:
MMC5: Writes to $5000-$5015; maybe reads from $5010, $5015.
VRC7: Writes where (address & $F000) = $9000 and ($address & $0018) != 0
VRC6: Writes where address >= $9000 and <= $BFFF
N163: Writes where (address & $F800) = $4800 or $f800; maybe reads from $4800
SS5: Writes >= $C000

If you are only interested in writing, like infiniteneslives suggested, you could probably do this with failing to connect anything on the PPU side and just two gates:

I think you can get all of that with a single 74'02 quad NOR gate.

Thanks for the replies.

Are there a general case hard rule for when the PRG read is or is not enabled, or is that something that's going to be specific to a mapper? Does the FDS do it the same way as MMC5 and N163? (I've got an FDS but getting the disks to read is proving very difficult, so a way to bypass it like this would be very useful to me.) Why don't all mappers that need to be written to without bus conflicts just disable the PRG read when PRG R/W is low? Does a PowerPak do this, or are the rules more complicated than that?

Jahrmander: If you don't mind me asking, what makes diodes on PRG D0-7 inadequate? I'm not insisting they should, I'd just like learn whatever it is I don't know that would cause a problem.

infiniteneslives: no, reading should not be necessary. The intent is to use the powerpak as the host, and some expansion audio cart or FDS in the secondary slot. I don't think I need any reading from the secondary slot for audio purposes.

lidnariq: wouldn't "AudioCartM2 = M2 AND NOT R/W" mess up the clocking of the audio hardware?

Generally diodes don't work because current flows both directions on a data bus. The diodes would only work if there was ONLY ever a '0' or '1' on the bus, but infact it's always different. If the cathode was towards the sound cart that output a '0' and the powerpak output '1' you'd have trouble, and vice versa. But luckly since you don't need to read from the sound cart you don't need and bus transceiver/diodes etc since you won't have read conflicts.

Since you don't need to read from the sound cart you'll only have to ensure that your writes to the audio chip don't have bad side effects on the mapper. There are a couple ways to do this assuming you don't want to write your own powerpak mapper. The bad side effect would be something like if you try to write to the sound chip but when you write there, you'd also write to the mapper swapping banks. Additionally you have to be concerned about bus conflicts which is mapper dependent (answering you're question I believe) This is fairly simple to solve if you don't need more than 32KB. You just choose a mapper that doesn't suffer from bus conflicts like ANROM and then program your ROM into ALL banks of the PRG ROM. That way if you swap banks you don't really care because the ROM is in all banks.

If you did all that all you would need to do it make your sound cart never think it was being read from. Something like only let the sound cart's PRG /CE signal go low when PRG R/W is also low (one simple OR gate). Then you'd only allow writes to the cart and block all reads from $8000-FFF. That would relieve any issues in the sound chip needing unmasked M2 signal like you pointed out.

Ooooops. You're right (at least, for everything but the VRC7). Uh, let's try this:
AudioCartA14 = NESA14 AND NOT R/W

... edit: which is exactly what Jahrmander said. sigh.


infiniteneslives: Blocking just /ROMSEL is insufficient, because many of the games that contain audio hardware also map readable stuff below $7fff, like the N163's waveform memory (in $4800-$4FFF) would appear as a bus conflict when the master cartridge is trying to read from $C800-$CFFF, or any game with RAM mapped into $6000-$7fff would conflict with $e000-$ffff.

Yes, but I was implying that it wouldn't matter by suggesting the use of something simple like ANROM only downside is the 32KB limit with his ROM. Additionally my method would allow you to make use of WRAM or anything mapped below $8000 on that sound cart.

Your AudioCartA14 = NESA14 AND NOT R/W solution should work. But you're only moving the possibility of WRAM from the sound cart to the powerpak. Most mappers with WRAM aren't tolerant to any random write in $8000-FFFF though (ie MMC1 and MMC3 with their states) So you're still limited to 32KB and stuck with ANROM. There may very well be mappers supported that would allow it, I'm just not certain of the powerpak's precise mapper definitions.

EDIT: If you wanted to create some more complex circuitry you could do something like move the powerpak's mapper registers to unused address space and open the possibility of large ROM space and unmoved sound registers. It just gets a little messy... The other option would be to write your own powerpak mapper that moved those registers without extra hardware.

infiniteneslives: I don't think there are any side effects on the second cart that I would care about. Bankswitching is not a problem (don't want to read from the cart), and even IRQs shouldn't matter since that pin wouldn't be connected. I don't need bankswitching on the host cart side; I can easily do what I want to do within 32kb.


So, I think I understand the suggestion, but let me think out loud and tell me if I've got this correct:

PRG R/W - high on any read.
M2 - high when the bus is ready for read or write.
PRG /CE - low when $8000-FFFF is needed for read or write.
PRG A14 - mappers never use $0000-3FFF, so this bit is always high when writing/reading $4000-7FFF.

On a mapper that does not require reading or writing outside of $8000-FFFF, PRG /CE is high when the bus should be clear so the CPU can write to its internal registers. On a mapper that does use $4000-7FFF, even when PRG /CE is high some mappers may still want to put a read on the bus if in the $4000-7FFF range.

So:

1. "PRG /CE = PRG /CE | PRG R/W" tells the mapper to clear the bus whenever read is enabled (i.e. fool it to think we're always outside $8000-FFFF on read).
2. "A14 = PRG A14 & ! PRG R/W" disables A14 on read to prevent reading from the mapper $4000-7FFF.

This makes sense to me. Thanks.


The last thing I'm trying to understand is what the problem case is with diodes. I'm assuming the PRG D0 line would be attached to both carts, and the CPU. Calling the two carts A and B, I only want to read from A, and I want to write to both A and B identically.

Reading: A=1, B=1 - no conflict?
Reading: A=0, B=0 - no conflict?
Reading: A=0, B=1 - will the diode prevent conflicting flow from B, allowing CPU to correctly read 0 from A?
Reading: A=1, B=0 - will the CPU still read 1 from A, or does flow from A to B cause a problem?
Writing: presumably both A and B will have PRG disabled when write is enabled to avoid their own bus conflicts, should there be a conflict here between the two of them?

Does writing to both carts simultaneously cause a conflict?

Sorry I'm probably not explaining myself well. The bankswitching problems I was referring to was on the power pak. Not the sound cart. Which is also the answer to your question about write conflicts. Its okay to write to two different places at once. But writing to the power pak will also presumably swap your banks that hold your code. That would be problematic. You'd either need to take my suggestion about anrom that way the bank doesn't matter, or block writes to the cart with more hardware.

With the diodes: Current flowing from A to B would cause problems. You don't know if you'll get a 1 or 0 read by the cpu. My guess the bus would be around 0.7 volts and the CPU would incorrectly read that as a 0. Not to mention you'd have high current draw/sinking which is bad for those parts. And like we've mentioned its easier to just block all reads.

Ah, suddenly I understand why you suggested ANROM instead of NROM. I don't know if the PowerPak disables PRG when PRG R/W is low for all mappers, or just ones that need to, but it would have to for ANROM, yes.

Actually, after thinking about it, the NSF mapper is probably compatible with all of the expansions. The only NSF mapper registers are $5FF8-$5FFF, and none of the expansions have any sound control registers in that range.

I must either be being dense or terrible at explaining myself. The problem I was trying to prevent with modifying A14 was keeping the accidental mirror of internal readable registers from causing bus conflicts against the cartridge we're trying to execute from. Now, admittedly, this won't pose a problem for the SS5, but at least some layouts of all four other mappers do have cartridge WRAM (or have the N163's internal sound ram), causing bus conflicts when we're e.g. trying to fetch the vectors.

Now, we could say AudioCartA14 = NESA14 AND (NES /ROMSEL OR NOT R/W), which would have the advantage? of being able to read from the audio cart's control registers. But we have to do something once we've permanently removed what's tantamount to the Audio Cart's A15 line.

edit: fixed new eqn

Well, on the N163, for the most part the registers are just going to contain whatever I write to them anyway. No real point to reading them. There are 3 registers in each channel that are still unknown but it has been presumed that they contain a 24-bit phase value, and this can actually be verified by other means (their value can be "played" as a waveform, or I could just write a hotswap diagnostic). I don't think it's something I'd want to go out of my way to support for this project.

Anyhow, thanks for your help, everyone. I'll be giving this a go once my parts arrive in the mail.

Seems my idea get through.

I don't know if it's too much but anyway:

How to wire you quad nor gate:


Connect Famicom's {PRG R/W} to A1, Famicom's {PRG /CE} to B1, Q1 to both A2 and B2 and then Q2 to the "expansion" cart {PRG /CE}. This makes an OR gate. Then connect {PRG R/W} to A3, {PRG A14} to both A4 and B4, Q4 to B3 and then Q3 to the "expansion" cart {PRG A14}. This is equivalent of a AND gate with the {PRG R/W} inverted.

Yeah, I can handle wiring up a 7402. That part's not problem.

The main thing I was unsure of is what happens when you connect 2 devices to the same bus, which is something I've never done before. I'm still a bit unclear on how that works, actually. infiniteneslives' guess that a read conflict would put "about 0.7 volts" on the bus is something I'd like to know more about. How do you make that guess? What about trying to write to two mappers at once; is there a limit to how many devices you could write to simultaneously via the same bus? My knowledge of how TTL circuits work in this kind of case is very deficient. If there's a standard textbook that I should read, or you know a good online resource that teaches this stuff, please let me know.

Controlling the read state of the mapper via PRG /CE and PRG A14 was an interesting lesson too. I had been under the assumption that there was no way to directly do this, but after thinking it through I can see how it works. I was interested in the solution, but I am much more interested in knowing why the solution would work, so that I could figure it out and be capable of changing the plan if I needed to.

Yeah, it was a bit late here and didn't take the time to explain much my solution. But with the help of everyone, now that's all explained, plus potential pitfalls to avoid.

Concerning the 0.7V, it's just the diode drop you'll encounter if you put diodes in the data bus. I'll explain it (but please don't mind the crappy ascii art). For the sake of simplicity, only D0 is shown here:



Suppose that cart A is the one you want to prevent bus conflicts with reads. Well, that doesn't entirely work: imagine your program does a read at $8000 for example, cart A PRG has $00 at that address and cart B has $FF at the same address. That means D0 from cart A will be driven low (~0V) and D0 from cart B will be driven high (~5V) when that read occur. Current will flow from cart B D0 to cart A D0: with NMOS technology the 0V will "win" and the 2A03 will see about a diode drop (~.7V) and that will be interpreted as a logical 0. That's a bus conflict! Put the diode the other way and it will work with this particular situation, but then if cart A D0 is driven low it will still do a bus conflict.

That's why it's better to somehow manipulate the {PRG /CE} and {PRG /A14} that goes to the expansion cartridge, that's so simple it works : you only have to change those signals so when read occurs, the "expansion" cartridge will never see a good address nor {PRG /CE} going low, so it will never drive the data bus for whatever reason, because it is never 'activated' on reads. Of course, that prevent you to make any read from the "expansion" cart, but when messing with external audio why would you want to read out some registers? Namco163 support this, but it's just plain RAM; reading $5015 with the MMC5 will give you access to the status bits, but for what use? I can only see interest in reading FDS registers. But then, you'll have to remove the extra logic required for {PRG A14} and make sure you choose a mapper that the PowerPak won't decode addresses in the range $4000-$7FFF internally, if that's possible.

So...

If there's no diode in this case, current would flow from B D0 to A D0, and nothing would get to the CPU input, but if there is a diode in the way, the voltage drop across the diode allows an equivalent voltage to apply to the CPU?

However, if /OE on PRG ROM A is high, its D0 is effectively disconnnected and does not interfere with the CPU?

If these things are true, then I guess my next question is what is different about the CPU input and the A D0 low output that means A will "win" the conflict instead of the CPU?

Is it generally safe to connect one TTL output to multiple inputs? Is it also generally unsafe to connect two TTL outputs together, causing unwanted flow if one is high and one is low?

You get it. The last thing is precisely a bus conflict.

When a device in a bus IS selected AND it's a read request THEN it drives the bus, otherwise it doesn't drive it (let the bus in its state, possibly floating). Of course when a device is accessed for a write, it doesn't drive the bus because the CPU is driving it and it's supposed to take what the CPU drives. It's like that to allow multiple devices on the same bus.

edit:
When doing a read the CPU doesn't drive the data bus, so it won't "fight" with other devices possibly driving the data bus. So the CPU isn't part of the conflict, it's between the devices trying to drive the bus together. Only one device is supposed to drive the data bus, either the CPU or one peripheral.

With most discrete mappers, you get bus conflicts precisely because a ROM doesn't have a R/W pin, it is supposed to be read, period. When doing writes to the ROM, the ROM chip will effectively drive the data bus as it were a read, so both the CPU and the ROM chip drive the data bus, which does a bus conflict. The ANROM and AN1ROM adds extra logic to the ROM /CE to disable it if it's a write, a bit like we're going to do with your special cartridge.

Sounds like you're looking for some basic fundamentals of a birectional data bus system (might find something with that on google.) One quick read that may help is simple a SRAM datasheet. Read through it a time or two and make sure you understand exactly how each pin behaves and the timing diagrams of reading and writing, tristate inputs and such. Sounds like you've got most of this down now, but it's a quick read that might solidify some of this stuff for you. Another decent source would be the 6502 datasheet. I've only read though the first couple sections but it try to teach these basics and such of R/W addressing, chip enable, bidirectional bus etc.

FYI The way this is avoided with things like UNROM is by making sure the address 'written' to on the ROM has the same value that the CPU is writting to the mapper, so the ROM and CPU both agree on the value. They are BOTH outputing to the bus (because the ROM doesn't know it's a write) But since they output the same value conflicts are avoided.

If you put 100 some memories on a single bus and tried to write to them all at once you might have issues due to the large loading, but this isn't really of concern for your discussion.

Wikipedia's article on three-state logic seems helpful. Yeah, I've dealt with bankswitching code for discrete logic mappers; I know how that's done. I'm generally okay with stuff on the programming or logic side. It's the electronics that I sometimes feel inadequate with, but I'm learning more all the time, so this is good. Thanks for your help.

Yeah I can relate with that. I thought it was interesting when I first stared deving here. I'm more of a hardware guy, so trying to learn about the mappers was kind of challenging for me at first because all the documents are written from the perspective of the programmer. It wasn't until I started tracing some of the PCB circuits and stuff myself and RE'd the mappers that I actually understood how they worked on a hardware level. So I can imagine the challenge of coming from software to hardware without the hardware back ground.

For me it was kind of neat to finally get around to creating my own version of pong a few months back. In a lot of ways, creating a game it was greatly eased by the fact I had such a good grasp of the hardware. But when programming I quickly found the knowledge holes I had, and enjoyed patching them up and finally tying the whole NES hardware/software together.

Recently I was trying to learn how to wire a cartridge for horizontal or vertical mirroring. I had been expecting there to be a pin that was high/low vertical/horizontal, or something like that. When I first started looking at it it made no sense to me; why were CHR address lines going to the pin that controls nametable mirroring? It was quite eye-opening to realize how that worked. I guess this kind of use of address lines is a pretty normal idea if you work with hardware a lot, but I never expected it.

Actually, I wonder what kind of interesting things could be done with it. Memblers mentioned building a cart with no onboard CHR and just uses one of the nametables as CHR-RAM. I wonder what other useful possibilities there might be. (Has anyone tried to use diagonal mirroring?)

Yeah mirroring is kind of one of those mystifying things that really turns out to be simpler than you imagined when you actually figure it all out.

Diagonal mirroring huh? Interesting thought. Wouldn't seem too hard to wire up, but I'm not sure how to make use of in a game...

Diagonal mirroring (CIRAM A10 = PA10 xor PA11) in a 4-way scrolling game has wraparound glitches not at the left and right, not at the top and bottom, but only at the corners, which are even harder to see. It's already possible on TxSROM and MMC5 and possibly a few obscure Japanese mappers.

I'd make a tech demo of it, but I lack a big picture to pan over.

I've actually been working—although not very earnestly—on reworking Galaxian to that layout (which in my head I've taken to calling micro7).