nesdev.org

Another update:

So lacking anything else to try, I soldered my last chip to an adapter board. This one id's! So somehow I fried or otherwise screwed my other boards. I have no idea how that could have happened. The only thing that came to mind was not cleaning the flux off well enough. Switched flux brands for the new board.

Anyway, the board id's but the data on the chip once written has errors. Even with double write at -2 (which takes forever).

So the chips write but verify fails each time? I have the exact same problem using the official GQ-4X TSOP-40 adapter. I emailed someone at MCumall and they told me that it is a known issue with the newer software (I believe they said Ver 5.1 worked fine, but dont quote me). Something about the algorithm got messed up for the verify process and they dont seem to keen to fix it. What you need to do is step down the voltage for the verify to 3V and it will work. I have that option on my adapter with just a jumper, and it verifies correctly. But if i leave it on the 5V jumper it fails to verify 90% of the time.

I'm not sure if you have a way to do that with your adapter setup, but thats the only way I can get them to verify on mine. And seeing as they dont have the older software version available anymore I'm not sure what else you can try...

Thanks for the reply!

Lacking more options, I actually ended up soldering a new board with my last chip. That one works! So it would seem I ruined the other boards. I also had a microscopic bridge between two pins that caused some frustration on the new board, but once I cleared that I'm able to write without hassel using the newest (6.17) or the old one (5.03B). The game loads again on the system.

However, I'm still getting verify errors. My test so far was to write at various speeds with double write. I'm still failing on verification. I dumped the read data from one session and diff'd it with the source data and there are exactly 64 mistakes (63 are reading other values instead of FF except for one instance of an FB).

I have a hard time believing the remaining errors are a soldering issue. But I'd like to verify this is just a glitch in verification/reading rather than an actual issue with the data on the chip before gifting this away. I might try writing the erroring data back to the chip and reading that back and seeing if the errors correspond to the same addresses? It's usually a little wishy-washy about where the errors occur, so that probably wouldn't be fruitful.

I don't have any sort of voltage adjustment like the official TSOP adapter does, I'm just using the Willem adapter mentioned earlier in the thread.

I have read several posts now about the many difficulties of the Willem programmer. I use the one made by Andromedia Labs. ARLabs.com You have to buy the adapter for the tsop. The one thing I don't like about the ARLabs programmer is that it's DOS based but once you get used to the programming instructions, it's really not an issue. Anyways....I made for them an adapter that uses both the tsop40 zif socket as well as a socket for the 36 pin mask rom (for reading) and programming the tsop already on the tsop adapter pcb. They were considering making and selling to the Snes community but I don think they got around to it. No matter, I have some spare pcb's I could sell or give the gerbers to whoever wants them. Just so I am clear before anyone considers buying an ARLabs programmer, you would need the programmer (obviously), and the tsop BASE adapter that they sell, THEN, you would need the adapter that I made (and use) that has provisions for a tsop zif socket and also provisions for a DIP socket that has the same footprint/pinout as the snes mask roms and the tsop40 to dip36 adapter that BuyIC.com sells. The adapter I made has to be mated with the base adapter that ARLabs sells. I'll have to take a pic of my set up to give you a visual or what I am talking about. Anyways, this is the setup I use and it works perfectly. Plus, they are still in business and their support is excellent.

Mark

Hi,

I´m trying to make me an Zelda Parallel Worlds using an BA3M but it´s not working;

The game runs, but I can´t go past the save game screen;

I´ve tried to recable it like an BJ0N but with no success;

Any help?

I´ve tried some solutions that I found on Google, here a picture of the actual board;

http://i.imgur.com/v3AaGsX.jpg

Best regards

PS.: sorry for my bad english

A BJxx cart is Hi rom mapping and Zelda PW is Lo mapped. The BA3M would be the appropriate host cart to use. The "A" indicates its a Lo mapped cart, the "J" = Hi mapped.

Since the lower rom slot of the BA3M cart is capable of 16mbits natively, the A20 line (pin 1) is location that the game is trying to access. I've never tried the type of conversion you are attempting so this is guess work on my end.... Maybe take the A20 pin hole and tie it to the rom 1 (upper) OE pin and remove that wire from the mad1 pin 1. Then take the mad1 pin4 and tie it to the lower rom OE. Reinsert the mad1 pins back into their solder holes. This is purely guess work on my end though.

But....... if you did the bin swap, you shouldn't need to run wires from the mad1, pins 1&16. Just swap the roms pins 24&31 with each other. Then the mad1 pins will line up as needed.

What are you doing with mad1 pin4?? That's the OE output to the roms. The mad1 sends the OE signal to the 2 roms through pins 1 and 16.

The reason it doesnt work is you wired it all messed up.

You only need to jumper 2 wires from each chip. Pin 31 goes to hole 26, and pin 24 goes to hole 33. You do this for each chip.

The MAD-1 is left completely alone.