a few questions

Alright I have made probably 10 reproductions for myself and have had no issues what so ever. Recently my friend wanted me to make him a copy of Zelda Parallel Worlds. I had the ROM saved from when I made a copy for myself. I am using tsop chips/adapters on type III boards (probably explained that part really bad.) I am using a GQ-3X to program the chips. I checked the ROM before programming in bsnes and it worked fine. The chips ID correctly and programmed. After the chip was programmed I test them before soldering them into the cartridges. I have a test board with a socket attached where the mask rom use to be. I place the chip I programmed into the socket and then this happens(sorry crappy phone quality). Any help would be appreciated.

What does the message say? Yeah, that video is pretty crappy....

If you watch this video. You see how it loads up as "~Euclid~ presents" then goes to the loading screen/music. Mine loads to the "~Euclid~ presents" then makes a weird sound and the screen stays black.

Did you do a file comparison after programming? Did you program the rom on the tsop adapter or mount after programming? I'm betting that you either have a bad mounting of the tsop40 or is not programmed right. Is parallel worlds 32 mbit? If its smaller, maybe you need to not have the unused address lines float......

That's all I can think of....

I did not do a file comparison, what would be the best way to do this or is there a program that does it automatically? I bought the tsop chips pre installed to the adapter boards. I don't think its an issue with the chips because I have tried a few chips and they all do the same thing. From what I learned before since these are flash chips the entire chip does not need to be filled for them to work.

I think it is either something with my programmer or the programming software. Is there a universal software that can be used by any programmer? Or am I stuck with the software that mine came with?

This will compare files: http://www.cjmweb.net/vbindiff/

So I guess the best way to do this would be to program the chip, read what was programmed onto the chip and then save what was written as the same file type?

No, the first step is to verify that you've even created a valid binary ROM file to be put on the chip in the first place. Don't program the chip until you know the data going in is correct.

I can't even get the program to open.

Again can anyone help?

are you on linux or windows?

as summed up by previous posts. The two main important things:

1) That the actual file you are flashing is perfect in itself.
2) That the actual ROM data on the flash chip, matches your perfect file.

Do those steps in order.

If you are Linux, I use a program called hexdiff for this purpose.

p.s. Can you link us to the exact board you purchased? (Type I Type II Type III)

I am using windows (windows 7 but have a VM of XP and 98), and I could not get the program vbindiff to open/run on my computer. I bought the flash chips preinstalled onto Type III adapter boards.

I don't think its the ROM file since I have used the ROM file before to program the same game but at this point I am willing to try anything.

"Bare in mind that VBinDiff is a CLI program, so if you just try to run it on Windows, it will either appear not to start, or will very briefly show a command prompt window, which quickly disappears. Open up a command prompt and run the program from there to see what arguments it accepts, and then use it from the command prompt accordingly"

If that doesn't like you, then try this binary diff program: http://en.wikipedia.org/wiki/WinDiff

Let us know how that goes

In the case that he/she has a correctly diffed binary, maybe he needs to ground his address lines? Here's s reference pic of the Type III adapter in that case. The next step would be to trace the board to see which jumpers go where and what to solder together. iirc the OP said this was maybe not the problem. Still, i post..

Alright I used the WinDiff program and this is what it says This

Also the adapter boards I have look more like thisthen the one you posted. I purchased a decent amount of these at the same time and the other ones worked perfectly fine when I used them.

HxD will do binary file comparison (Analysis->File Compare->Compare). Read back the contents of the chip to a file, then open it in HxD and compare it to the original ROM file you burned to the chip.

Won't your programmer do a compare function?
Compare what's inside the chip to what the original is?

I compared the files and the programs say they are identical except that the one I saved from the chip is bigger.

Try grounding any unused address lines?

I have no idea why this is not working anymore. Would anyone be willing to try this (with my rom) on their programmer and let me know the results?

I always cringe when I see these (cheap?) PCBs without any ground fill, even though it seems there's plenty of space, especially on the bottom.

Double post but anyways, I tried another game I already made and was not able to get this one working either so this leads me to think its one of a few things,

1.) The Super Nintendo System- I don't think it's this because it still play games just fine. I am going to try another system in the next day or two.

2.) My test cartridges/boards- I don't think it's this because I can put the original Mask ROMS into the sockets attached to the board and those play fine.

3.) The ROMS I am trying- I don't think it's this because I have used these same exact ROMs before.

4.) My programmer- I have no way to test it with another programmer but I think it might be this.

5.) The programmer software- Is there a universal programming software? Or do I have to use what my programmer came with.

I'm inclined to thing it's your programmer or the tsop adapter.

You can pm me if you want and I'll test it on my set up.

Mark

Using this type of boards over the eprom-ratsnest we usually see is, according to me at least, an huge improvement.

Pouring copper on the back side of this board wouldn't improve much anyway, you would need to re-route it to have a grid like ground plane, or even better, a 4-layer PCB with dedicated power and ground planes. But then again, if it works for everyone, why bother?

Just thought I would give an update, I tried it on my friends GQ-4X and it worked fine. I guess there is something wrong with my set up.