It is currently Mon Oct 23, 2017 1:59 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Aug 08, 2012 5:50 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
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.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 7:13 pm 
Offline
Formerly ~J-@D!~
User avatar

Joined: Sun Mar 12, 2006 12:36 am
Posts: 445
Location: Rive nord de Montréal
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.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 8:01 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 8:39 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6302
Location: Seattle
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:
Code:
 /AudioCartROMSEL = /NESROMSEL OR R/W
 AudioCartM2 = M2 AND NOT R/W

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


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 8:47 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
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?


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 9:22 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 9:37 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6302
Location: Seattle
rainwarrior wrote:
lidnariq: wouldn't "AudioCartM2 = M2 AND NOT R/W" mess up the clocking of the audio hardware?
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.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 9:55 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
lidnariq wrote:
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 10:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
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?


Last edited by rainwarrior on Wed Aug 08, 2012 11:10 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 11:01 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Aug 08, 2012 11:29 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
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.


Top
 Profile  
 
PostPosted: Thu Aug 09, 2012 12:53 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
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.


Top
 Profile  
 
PostPosted: Thu Aug 09, 2012 12:55 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6302
Location: Seattle
infiniteneslives wrote:
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.
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


Last edited by lidnariq on Thu Aug 09, 2012 12:02 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Aug 09, 2012 1:10 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
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.


Top
 Profile  
 
PostPosted: Thu Aug 09, 2012 4:42 am 
Offline
Formerly ~J-@D!~
User avatar

Joined: Sun Mar 12, 2006 12:36 am
Posts: 445
Location: Rive nord de Montréal
Seems my idea get through.

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

How to wire you quad nor gate:
Image

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group