AOROM to UxROM conversion

Is it possible? I attached some dip switches and an HC32 to my AOROM cart for and AOROM-UNROM (and the other way around) conversion. It worked, excepting for not figuring out how to solve the mirroring problem, witche caused some glitches and chaotic map stuff. Then I modified the whole circuit to AOROM-UOROM conversion, hoping that it will work fine. But now it doesn't work at all for UNROM/UOROM. It only works for AOROM but when I set the switches for UNROM no answer...
Has someone done this type of conversion?

The RetroUSB ReproPak basically does this, except the "switches" are solder jumpers or different traces/sockets. But you can certainly rig a board to play both UxROM or AxROM games.

It's certainly possible I implemented the conversion using several solder jumpers. Post up your schematic and I can probably help you figure out where you're going wrong assuming your schematic matches your circuit. Keep in mind the UNROM has 16KB banks and AxROM has 32KB banks so you need to make and break PRG A14 when going back and forth.

http://www.mediafire.com/?2qlib92i086umrz .pdf
http://www.mediafire.com/?b11qr1ebo48kv4c .sch

Here is my schematic.

Where are the outputs of the first 4 UOROM switches going? Based on your labels is sounds like you're connecting them to the PRG-ROM. They shouldn't be, they should only be connected to the '32 inputs, and the outputs of the '32 should drive the PRG-ROM A14+

I'm also making a lot of assumptions based on the labeling since I don't have the pin number definitions commited to memory. I suggest giving them more useful names like PRG-ROM A15 vice pin #-32. Oh nvm, I think I just figured out where the actual connection are, you're feeding those to the '32 and then back through the other dip switches. It looks like it should work, the only condition to that is I'm assuming you're pin numbering is correct I'll leave that for you're verification and/or labeling.

Check your connections from NES connector to the expected in on the mapper and roms etc with a multimeter. Check every single last one until you figure out what minor mistake you make in the connections. You can also check for shorts in likely locations. There are 100s of possibilities that could keep it from booting. Your design looks fine pending my assumptions, so it's up to you to find the connection issue where your schematic doesn't actually match your design

EDIT: One suggestion would be to simplify your design significantly, you don't need to switch the inputs to the '32, you can tie them directly to the '161's outputs because you don't care when it's in AxROM mode. You only need to switch the outputs of the '32. If you make that simplification you might rid yourself of your bug in the mean time, less complex means less room for mistakes.

Thanx for the hint, it helped a lot! I switched only the outputs and now it works. I forgot to mention that i used a breadboard. That's why i thought that it would be fine to switch the inputs too, because i thought that there would be less chances for the board to work in AOROM mode when the hc32 is "totally floating". Anyway, i'm getting the same mirroring problem i got when i first tried the UNROM conversion. I tested it running Castlevania burned on a 512k AMD flash chip. When i connect CIRAM/A10 to A10 and A11 i'm getting a lot of graphic glitches and the the mirroring is so bad that the sectors of the stage overlap each other. But when i connect CIRAM/A10 to the pin 11 of the 161 (witch is switched on with the PRG D3 line), the graphic glitches disappear, it runs perfectly except for the overlapping thing that is definitely caused by bad mirroring. Any ideas what it could be?

You need a switch to pick one of 3 options for CIRAM /A10: what the 74161 outputs (AOROM single-screen mirroring), CHR A10 (UxROM vertical mirroring) or CHR A11 (UxROM horizontal mirroring). Depending on the UxROM game you'll have to select between vertical or horizontal mirroring.

...Yes. And this is when the glitches kick in. No matter which of these 3 options i pick...

Sounds like you have a bad connection on CIRAM A10 to the '161 somewhere and the line is floating based on the fact that you're saying things 'glitches dissapear, but still has wrong mirroring' when you connect it to the D3 output of the '161.

Are you saying that when you bypass your switch (but still schematically the same) things clean up? If so you just proved your switch bad, but you still have a different issue (probably the D4 input to the '161 since it sounds like it's not switching and sounds like you've got one NT mirroring, aka CIRAM A10 to GND/Vcc.)

In any event bread boards are notorious for causing issues with poor connections. If you really must use it, check all the connections related to mirroring with a multimeter to try and verify good contact.

I'm pretty sure it's not the breadboard because i got the same results with the 1st unrom conversion witch was not on breadboard. The glitches disappear when i disconnect ciram/a10 from a10&11 lines and i connect it to the pin 11 of 161 (witch is connected to the prg d3). But even the glitches disappear i still have a bad mirroring.

It's supposed to be PRG D4... See the M 'mirror bit' in the wiki. I thought you had a switch to go back and forth between D3 and D4 on that input to the '161.

Yes there is a switch for each one of them. But switching on D4 doesn't seem to solve the problem. Now i try to run some test with 1943 the battle of midway rom. I works like hell! Full of glitches and all that, freezes at certain areas, sometime doesn't start at all... I can attach some photos if you want.

Well if you went back to UNROM with 1943 and things are all glitched up it sounds like things are now getting worse. Didn't UNROM work properly after you took my suggestion on the '32 inputs?

In any event really 'dirty' graphics glitches are usually indicative of a bad connection somewhere probably a floating line. If the tiles are 'clean' but just the wrong tile or you can see the NES updating tiles on screen while you scroll you've probably got the wrong mirroring. Sprites don't rely on mirroring, so those should be clean. If they aren't you've certainly got a connection issue. Since I'm guessing all those CHR-RAM connections are already made for you by the original board and there aren't bad traces then you might just have a dirty 72pin...

Yes, the tiles are clean and they update as i'm scrolling. But only when CIRAM/A10 is connected to the pin 11 of the 161. When i connect it to A10 or A11 the tiles are glitched.

did you ever check all your connections with a multimeter? Trust me, it's your freind. Sounds like you're leaving CIRAM A10 floating. You just have to keep searching till you find your bad connection. Could be anywhere with a breadboard especially. Another method would be to just bypass ALL switches and get AxROM to work, then take one step at a time to add in the switches back in.

I redone the whole circuit 2 times today, and each time verifying each connection with the multimeter. It works perfectly for AOROM but i still getting the same glitches for UxROM as before. I kinda tried everything. This is the schematic of the whole thing: http://www.mediafire.com/?v5n29sj8ih2uyi9 Should it work?

I'm unable to veiw your recent file, but will take a look later on.

Sorry if this is a stupid question but you are connecting CIRAM A10 it to CHR A10/11 and NOT PRG A10/11 right? I noticed your last diagram only labeled it as A10/A11 leaving the fact your using CHR and not PRG up to assumption so I thought I'd check.

Since it's working flawlessly for AxROM, and glitched for UxROM there is really only ONE signal that can be causing this issue. Since the PRG side is working you know most of your inputs to the '161 are correct. None of the signals change on the CHR side going between UxROM and AxROM except CIRAM A10. The ONLY change on the CHR side going from AxROM to UxROM is disconnecting CIRAM A10 from the '161 (PRG D4 latched output) and connect it to CHR A10 or A11 depending on mirroring. That's the ONLY thing.

I actually tested this conversion out on my boards last night because I had yet to fully verify everything for myself. Coincidentally I got my jumpers mixed up and left CIRAM A10 floating. The graphics were all glitched in a 'dirty' manner as you're discribing. I corrected the issue proper connecting CIRAM A10 as discussed above and it works flawlessly.

How are you verifing the connection with your multimeter? For UxROM you can literally connect your meter between the CHR A10/A11 pin and CIRAM A10 pin on the cart connector. If you have continiuty the only way you could have glitches is if you are shorting that line to some other signal which would then be interfering with it causing the glitches.

Took a look at your diagram, based on the fact you labeled A11 'pad 2' I'm guessing you've been connecting it to PRG A11 which would definetly generate the glitching you're seeing Connect it to CHR A10/A11

I was going to link you to the wiki's mirroring description. And noticed that even the wiki is wrong and basically tells you to do what you did...



That should DEFINETLY say CHR A10/A11 and not PA10/11 which is just plain wrong. To take it even further not only is it wrong saying PRG instead of CHR, but the address bit is wrong too. Vertical is CHR A10-> CIRAM A10, Horizontal is CHR A11-> CIRAM A10. Oh nvm it just says 'configure for horizontal' in both.. Those sentences confuse even myself. I'll just go fix them If you read what it says now it should make a little more sense

I've always read "CHR Axx" to mean the address going to the CHR ROM. PPU A10/A11 (or PA10/PA11 for short) is the address on the cart edge coming from the PPU. CHR A10/A11 is the same as PPU A10/A11 on AOROM, UNROM, and MMC1, but it will be modified by any mapper more complex than an MMC1. I guess ultimately the problem is that "picture" and "program" start with the same first letter and that "central" and "character" start with the same first letter.

A rough block diagram, not to scale, of where the C's and the P's are:

Yeah I guess the difference between your short hand convention and mine is what threw me off.

The fact that your P's turn to C's and C's turns to P's seems prone to confusion though if the convention isn't thoroughly explained.

As for naming conventions on the wiki I think it's best to not use any short hand. Maybe it's just me but it seems the convention used by most people on the forum is to say CHR Axx and CHR ROM Axx and similarly PRG Axx, and PRG ROM Axx when there is a mapper in the middle. I agree that does leave it a little ambiguous though when you don't know if there is a mapper in the middle or not. Now that I think about it I do like how your convention has PPU, CPU, PRG, CHR all different it doesn't leave much to question. The problem really only arises for short hand. Places like the wiki we're probably best to just do without them all together.

Sometimes shorthand is pretty much required though, namely for things like silkscreen on PCBs. For my boards I use C strictly for CHR and P strictly for PRG. So I literally write P11 for PRG A11. When I need to denote something as strictly coming from the NES I write 'N' and assume you'll know it's PPU/CPU based on the nearby label for C11. So for a jumper that ties PPU A10 to CHR ROM A10 I'll write C10/N



The other time I use a lot of shorthand is code, but honestly my naming convention there (which I won't even bother to share) has even confused myself. I might migrate to PPU_A[10], CHR_A[10], CPU_A[10], PRG_A[10], PRG_D[7] and such which aligns more with your method Tepples. Fairly short to type but still lacks ambiguity.

The PA11/PA10 convention is believed to arise from Nintendo documents, or that's the impression I get from this page and various schematics that are floating around. This in particular appears to have been scanned from a Famicom repair manual or something.

Kevtris' pinouts on that page are more along the lines of what I'm used to using with PRG/CHR. I don't see any use of PA11/10 there.

In any event if you're unable to tell what the acronym stands for based on the context I don't think it's useful nor helpful to use them. I'm not sure if acronyms are the source of where Asphyx got mixed up connecting PRG A10/11 to CIRAM A10 or not. But whatever we use on something like the wiki should avoid any ambitiousness if possible.

I figured it out in the end. Thank everyone for help! I used the PRG A10 and 11 for the mirroring indeed. I checked with some schematics later and found out that that was wrong. Can't believe i haven't noticed at the time because i already knew that the CHR lines are the ones used for mirroring. Dumb me! But anyway this was the least problem, because again my Castlevania was a NTSC version (my machine is a PAL one ) and my connections were defective despite the fact that i double checked them multiple times and they were clean and correct. I used some common internet/network wire. Maybe the (old scavenged) dip switches were causing problems, not to mention that i used ic sockets for them. Anyway i gave up any of these and i attached the hc32 directly to my AOROM cart, using some other (and thinner) wire. I tested it using Castlevania and 1943 and they both work perfectly. So the conversion is possible. Thanks to everyone! :* Cheers!

please tell me what program to open. sch - file ?

I'm guessing Eagle pcb cad

thank you!