Now that the PowerPak is in people's hands, I think it would be a good idea to list the games with confirmed problems in a separate thread, so I will start with my observations about buggy games.
Mike Tyson's Punch-Out!! (U) (PRG1) [!].nes/Punch-Out!! (U) [!].nes
Playable, but graphical errors abound
Low G Man - The Low Gravity Man (U) [!].nes
Playable, but graphical garbage appears when you use the boomerang weapon and the boss level music gets garbled.
Crystalis (U) [!].nes
Graphics flickering when wandering around.
Teenage Mutant Ninja Turtles II - The Arcade Game (U) [!].nes
Graphic garbage usually flickers when new enemies come onto the screen.
Little Nemo - The Dream Master (U) [!].nes
Graphical garbage when conversing.
Micro Machines has crazy raster offset issues (title screen, character select). But i'm using a really cheap tube TV set, so that might be the issue.
baisoku wrote:
Micro Machines has crazy raster offset issues (title screen, character select). But i'm using a really cheap tube TV set, so that might be the issue.
Ugh... Not THAT game again...
It would also be helpful to figure out the mapper number of the specific rom file you are using. There will be bad headers that could create problems. Also then it will be easier to look up on the mapper table to see ones that are known buggy like MMC2 (iNES #9). MMC4 most likely has the same chr bank switching problem. Photos might be useful later if I can't get the problem to happen, but don't flood the thread with them yet.
Micro Machines (Unl) [!].nes/Micro Machines (Unl) (Aladdin) [!].nes
Has graphical glitches in both the menu and the racing screens
Fire Hawk (Unl) [!].nes
Graphical glitches during play, eventually crashed.
Karnov (U) [!].nes
Severe graphical errors
Fantastic Adventures of Dizzy, The (Unl) [!].nes
Non-Aladdin version crashes on begining play.
Pin Bot (U) [!].nes
Severe graphical errors
High Speed (U) [!].nes
Severe graphical errors
OK I have now found a real bug witch did not tern out to be the ROM's fault
Wario's Woods (U) [!].nes
Mapper 4
After the title screen the graphics thern into large blocks
Isn't SMB/Duck Hunt GNROM (66)?
no mapper 66 was never even put into US carts and those are both dumps of offical US games
btw I had some problems with Kirby but resetting the system fixed that so I removed it from my list
Gumshoe, Thunder & Lightning and Dragon Power were all released in the US.
SMB/DH is logically the same as GNROM.
SMB/DH/TM is not and probably will require it's own config file just as a 4M MMC1 game would.
I now see you are correct about mapper 66 used in the US I was under the impression that onley 0-7 were used but after looking through my collection I see that is wrong I suffer from bouts of being a jackass yuo will have to forgive that
but nestopia said those two 2 are mapper 1 so that is what I type I dont know it its correct or not
this is something odd woth noteing
"kirby's adventure (PRG0)" get a scrambled screen before the game genie screen but "kirby's adventure (PRG1)" works fine
the PRG0 one has Ni0330 included in its headder and PRG1 dose not
edit: made a small discovery if screen scrambles before GG/s-ram screen check the header for garbage data
Hi, I got mine today but I seem to be having problems with ALL of my games.
Many games don't load at all, and the ones that do are doing something REALLY weird. Any moving sprites (like Mario in SMB) are all messed up like only half is rendering properly. Regular carts still work fine. I also tried loading everything onto a different CF card with no change.
One thing of note, all of my NES roms are from about 10 years ago in most cases. I wonder if that could make a difference? I guess I'll have to see if I can find some more recent copies if that's the case.
Any ideas?
Thanks
When reporting a non-working game, you need to post some kind of checksum so others can reproduce your results more easily.
srgilbert wrote:
Many games don't load at all, and the ones that do are doing something REALLY weird. Any moving sprites (like Mario in SMB) are all messed up like only half is rendering properly.
I'm getting the same thing, and the ones that don't load, I get a screen that says "File not found," and the background is very messed up.
I'd get some pics, but my main computer is down so I don't have a capture card.
atarimike wrote:
I get a screen that says "File not found," and the background is very messed up.
I'd get some pics, but my main computer is down so I don't have a capture card.
^from my experence that means the mapper is not supported or the header is screwed up and needs correcting
blargg wrote:
When reporting a non-working game, you need to post some kind of checksum so others can reproduce your results more easily.
thats a good idea but there are various types of checksums
what program would you recamend?
atarimike wrote:
srgilbert wrote:
Many games don't load at all, and the ones that do are doing something REALLY weird. Any moving sprites (like Mario in SMB) are all messed up like only half is rendering properly.
I'm getting the same thing, and the ones that don't load, I get a screen that says "File not found," and the background is very messed up.
I'd get some pics, but my main computer is down so I don't have a capture card.
Yep, that's exactly what happening to me too.
Quote:
When reporting a non-working game, you need to post some kind of checksum so others can reproduce your results more easily.
Instead of posting a checksum, I redid my posts to include new games, all using their GoodNES 3.10 name. I suggest everyone else do the same, using the latest version of GoodNES
I'll bet 90% of the problems that will eventually be reported will be related to bad headers, and 90% of those that remain will be because of bad dumps, neither of which is bunnyboy's fault.
dvdmth wrote:
I'll bet 90% of the problems that will eventually be reported will be related to bad headers, and 90% of those that remain will be because of bad dumps, neither of which is bunnyboy's fault.
Maybe, but that doesn't explain the problem I'm having seeing that it's EVERY game I've tried. This will really suck if my Powerpak is defective since I doubt it will be possible to do an exchange any time soon.
srgilbert wrote:
dvdmth wrote:
I'll bet 90% of the problems that will eventually be reported will be related to bad headers, and 90% of those that remain will be because of bad dumps, neither of which is bunnyboy's fault.
Maybe, but that doesn't explain the problem I'm having seeing that it's EVERY game I've tried.
Has anyone got
Tetramino (NROM-128) to work?
tepples wrote:
Has anyone got
Tetramino (NROM-128) to work?
Works just fine.
dvdmth wrote:
I'll bet 90% of the problems that will eventually be reported will be related to bad headers, and 90% of those that remain will be because of bad dumps, neither of which is bunnyboy's fault.
this is probubley true this diskman appaerintley was quite a busy guy sence I have run across quite a few of his dumps in my collection
allowing the power pack to ignore garbage in the headers would be a posiple fix for this if possiple,
anouther possiple fix for this is a PC side tool witch can remove junk along with telling you about unsuported mappers this would make it easyer for the general public to use and cut down on this problem
personally after getting into it my error reports will be less stupid in the future
my tip's to people: if you get small black or white lines flutering over the screen reset the system and it should be ok, and if the game freezes before the game genie/battery screen check the header
edit: duh goodnes can fix the headers with the fixnes command (proubley)
edit2: after runing my ROM's though goodnes's fixnes command it has dramaticlay increased the amount of working ROM's those with problems should do the same
peppers wrote:
duh goodnes can fix the headers with the fixnes command (proubley)
I haven't used that feature myself (I'm on a Mac, so I can't use GoodNES unless there's a version I never heard of). When the feature first appeared in v3.0, I heard a lot of bad things about it (not fixing some headers, breaking others). I don't know how good v3.1 is, though.
I still maintain that Nestopia's database is the best source for finding out what the header should be set to. A utility based on that database would be really great in my opinion. Anyone here willing to write it? Nestopia is GPL.
dvdmth wrote:
peppers wrote:
duh goodnes can fix the headers with the fixnes command (proubley)
I haven't used that feature myself (I'm on a Mac, so I can't use GoodNES unless there's a version I never heard of).
PowerPC or Intel?
I could make a simple C program that takes the filename of an iNES file, checks if there is garbage in bytes 12-15, and if so, zero out bytes 7-15. That might solve at least a few problems, at least for [ACEFPSTU]?[A-Z]ROM games.
Why not just try all roms on ANY EMULATOR BUT NESTOPIA before trying them with PowerPak to know if the rom is bad or if it's the header ? Some emulators, like Nesticle, LoopyNES or REW are so innacurate that they could break games working fine, but the average emulator such as VirtuaNES, Nester, RockNes should't be much worse than Nestopia.
Quote:
Why not just try all roms on ANY EMULATOR BUT NESTOPIA before trying them with PowerPak to know if the rom is bad or if it's the header ? Some emulators, like Nesticle, LoopyNES or REW are so innacurate that they could break games working fine, but the average emulator such as VirtuaNES, Nester, RockNes should't be much worse than Nestopia.
A good suggestion, in this case you should use Nintendulator, which is as accurate as Nestopia. Sometimes I feel that they are the same emulator, only one is geared for testing, the other for playing.
loopy wrote:
I tried my hand at writing a mapper. Here's a better mapper 9 (Punchout).
link
Much better, the only glitchy part of either ROM is the training sequences between Circuits. Those still show flickering and corrupt graphics on the lower portion of the screen.
tepples wrote:
PowerPC or Intel?
PowerPC (yes, I am behind the times).
tepples wrote:
I could make a simple C program that takes the filename of an iNES file, checks if there is garbage in bytes 12-15, and if so, zero out bytes 7-15. That might solve at least a few problems, at least for [ACEFPSTU]?[A-Z]ROM games.
If you do that, make sure to check for NES 2.0 first. This solution will guard against header garbage like DiskDude and what not, but it won't correct headers that are simply set wrong (and there are numerous ROM images floating around that fall in that category).
parhaps just a simple tool with all the ines options layed out that displays the verious setting and can apply new setting manually to a ROM so people will not have to understand the header file just match it to what nestopia said, although this still leaves the problem of haveing to go through them manually
Great Hierophant wrote:
Much better, the only glitchy part of either ROM is the training sequences between Circuits. Those still show flickering and corrupt graphics on the lower portion of the screen.
Good job loopy. But given that the training sequence between circuits is a
major fad on YTMND, you can expect the YTMNDers to be scrutinizing this screen rawther closely.
dvdmth wrote:
If you do that, make sure to check for NES 2.0 first.
Thanks for the heads up. Implemented in my Anti-DiskDude tool. But it appears that a header "signature" that starts with H, I, J, K, X, Y, or Z will falsely trigger NES 2.0 mode.
loopy wrote:
Great Hierophant wrote:
loopy wrote:
I tried my hand at writing a mapper. Here's a better mapper 9 (Punchout).
linkMuch better, the only glitchy part of either ROM is the training sequences between Circuits. Those still show flickering and corrupt graphics on the lower portion of the screen.
I'm not seeing it. looked perfectly fine to me. ...?
This is strange, the corruption does
not appear with Mike Tyson's Punch-Out!! (U) (PRG1) [!].nes, but
does appear with Punch-Out!! (U) [!].nes. [/u]
peppers wrote:
parhaps just a simple tool with all the ines options layed out that displays the verious setting and can apply new setting manually to a ROM so people will not have to understand the header file just match it to what nestopia said, although this still leaves the problem of haveing to go through them manually
Yes, please, simple is good! I guess I'm having a hard time understanding why this is even necessary. Why do the roms that some people have work fine, while others like myself are having nothing but problems? As I said in a previous post, all of my roms were downloaded at least 5 years ago, and according to the file, created as long as 10 years ago. A quick search online seems to indicate that most of the roms floating around are also that old. I've tried downloading different versions of the the same games (for instance, Super Mario Bros by itself, +Duck Hunt, or +Duck Hunt and Track&Field.) and the exact same thing happens to Mario. Again this isn't just on Mario games, this is on EVERY game.
I realize that this forum is meant for NES developers with the background to go with it, but this product wasn't only marketed to that crowd. If there is nothing wrong with my PowerPak, then I need to know either how to fix the roms I have, or where I can find "good" ones. I'm sorry to sound like a whiner, but I feel like I've paid a good amount of money to be a beta tester. I'm sure this will be resolved, but I just needed to blow off some steam.
Thanks
for now just run them though
goodnes useing the fixnes command that will get you going till/if there are better options
the ones created in this proses will be marked with the extension .nes.new.nes
the outher current option is manually editing them useing a hex editor witch is slow going when doing a lot
but if its every game maybe there are outher problems causeing the trouble like card format parhaps or the powerpack files are not all loaded in?
personally I am quite impressed with its abiltys and injoys it quite a bit the mapper I paticlarley miss is mapper 19 but 64 differint ones is still plenty for now
Great Hierophant wrote:
This is strange, the corruption does not appear with Mike Tyson's Punch-Out!! (U) (PRG1) [!].nes, but does appear with Punch-Out!! (U) [!].nes. [/u]
Even stranger. For me, Mike Tyson's Punch-Out!! (U) (PRG1) [!].nes works almost flawlessly on my front-loader (minor opponent tile corruption during fight), but has constant graphics corruption on my top-loader. Very confused.
peppers wrote:
for now just run them though
goodnes useing the fixnes command that will get you going till/if there are better options
the ones created in this proses will be marked with the extension .nes.new.nes
the outher current option is manually editing them useing a hex editor witch is slow going when doing a lot
but if its every game maybe there are outher problems causeing the trouble like card format parhaps or the powerpack files are not all loaded in?
personally I am quite impressed with its abiltys and injoys it quite a bit the mapper I paticlarley miss is mapper 19 but 64 differint ones is still plenty for now
how do you use goodnes? i opened the exe file and got the command. then i opened a command line and typed fixnes when i was in the folder where the .exe file is. i know this is probably wrong, just wondering how to use it.
Extract to a directory. Put the roms in the same directory. Go to start, run, browse to goodnes.exe, then add fixnes after the goodnes.exe and run.
ok, i did that and got an error message "unable to open goodnes.db. I tried the scan function and got the same thing. i looked in the zipfile and i didnt get a goodnes.db.
tepples wrote:
Thanks for the heads up. Implemented in my Anti-DiskDude tool. But it appears that a header "signature" that starts with H, I, J, K, X, Y, or Z will falsely trigger NES 2.0 mode.
Kevtris chose the signature pattern for NES 2.0 after doing a ROM scan to see what bit patterns exist in the wild. He didn't find any with D2 clear and D3 set in byte 7, so he chose that configuration for NES 2.0. This doesn't mean ROMs won't exist that can be falsely detected as NES 2.0, but hopefully such incidents will be fairly rare.
To help avoid false positives, you could also read byte 9 of the header, which in NES 2.0 contains additional bits for PRG and CHR sizes. If this byte is non-zero, and if the resulting PRG/CHR sizes are too large when compared with the actual file size, you can conclude that the ROM is probably not NES 2.0.
coinheaven wrote:
ok, i did that and got an error message "unable to open goodnes.db. I tried the scan function and got the same thing. i looked in the zipfile and i didnt get a goodnes.db.
that is just a database of ROMs you have already scaned it is not nessasery and is generated after you run a scan
its just to help you keep track of ROM's you already have to make it easyer to collect them all
peppers wrote:
for now just run them though
goodnes useing the fixnes command that will get you going till/if there are better options
the ones created in this proses will be marked with the extension .nes.new.nes
the outher current option is manually editing them useing a hex editor witch is slow going when doing a lot
but if its every game maybe there are outher problems causeing the trouble like card format parhaps or the powerpack files are not all loaded in?
personally I am quite impressed with its abiltys and injoys it quite a bit the mapper I paticlarley miss is mapper 19 but 64 differint ones is still plenty for now
Well, I ran some through GoodNes like you said following the instructions below. I does seem to fix the problem of the games that wouldn't load at all, but it had no effect on the corrupted graphics.
just to make sure you are aware that that is dose not replace you ROM'S it creates new one's mixed in with with your old ones adding ".new.nes" to the ends of the new ones
I'm experiencing minor graphical corruption in lots of titles, but a quick scan through GoodNES tells me my roms are in much poorer condition than I would have thought.
When I get them sorted out properly, I'll post differences if I see them.
remowilliams wrote:
I'm experiencing minor graphical corruption in lots of titles, but a quick scan through GoodNES tells me my roms are in much poorer condition than I would have thought.
When I get them sorted out properly, I'll post differences if I see them.
ditto that
peppers wrote:
just to make sure you are aware that that is dose not replace you ROM'S it creates new one's mixed in with with your old ones adding ".new.nes" to the ends of the new ones
Yeah, I figured that out, but no difference.
You should always be using the GoodNES v3.10 roms that have a [!] or a [!p] in the filename. If you are not, to quote from one of my favorite movies, "I have no sympathy for you gents."
Great Hierophant wrote:
You should always be using the GoodNES v3.10 roms that have a [!] or a [!p] in the filename. If you are not, to quote from one of my favorite movies, "I have no sympathy for you gents."
BTW, what does that [!p] tag mean? I've seen it before, but I never could find anything that explained its meaning.
dvdmth wrote:
BTW, what does that [!p] tag mean? I've seen it before, but I never could find anything that explained its meaning.
From GoodCodes.txt:
Code:
: [!p] Pending Dump [!] Verified Good Dump :
I have tested this on several consoles, and each one exhibits a different variety of glitches, ranging from very minor to very severe:
Toaster NES 1 (serial # N12597170): severely corrupted graphics and screen layouts in both BIOS and games. Completely unplayable. However, I did get it to boot once, and aside from intermittent scanline corruption, it worked fine. (NOTE: this particular system has been pretty badly abused by its owner and his young relatives, which might have something to do with it.)
Toaster NES 2 (serial # N3271679, CPU "G", PPU "G", MB "NES-CPU-08"): about half the sprites in all games show incorrect tiles (in SMB3, half of Mario looks like his map screen sprite). Otherwise playable.
Toaster NES 3 (serial # N23193854, CPU "G", PPU "G", MB "NES-CPU-10"): the newest console of all those tested. Almost flawless. Only common bug noticed so far is background glitching in TMNT2, which has already been reported. This is the least-glitched PowerPak/NES combo.
Toaster NES 4 (serial # N7962083, CPU "G", PPU "G", MB "NES-CPU-07"): same as toaster 3, except "Squashed (U) (Prototype).nes" exhibits sprite corruption (all sprites except player show some incorrect tiles). Probably affects other games as well, though I haven't tested that many yet.
Toaster NES 5 (serial # N0948916, CPU "E", PPU "E", MB "NES-CPU-04"): a true relic! Works identically to toaster 3, except for a small flickering line right above the status bar on SMB3's map screen. (For those that are curious, PPU "E" shows a brown or purple screen at power-up instead of the usual white/grey. No other noticeable differences.)
AV Famicom (serial # HN10735029): same as toaster 4, except with worse sprite corruption in Squashed (more corrupt sprites, several garbage sprites floating about the screen). I also have to power-cycle this one somewhat frequently to get rid of flickering horizontal lines in the graphics.
Interestingly, all the glitches are completely graphics-related; none of the games ever crashed.
[EDIT]
Added some more consoles, as well as serial numbers and chip/board revisions.
BMF54123 wrote:
Interestingly, all the glitches are completely graphics-related; none of the games ever crashed.
Not even
Milon's Secret Castle,
Super Mario Bros.,
Big Bird's Hide and Speak, and other games that stash plenty of data in CHR ROM?
tepples wrote:
BMF54123 wrote:
Interestingly, all the glitches are completely graphics-related; none of the games ever crashed.
Not even
Milon's Secret Castle,
Super Mario Bros.,
Big Bird's Hide and Speak, and other games that stash plenty of data in CHR ROM?
Or games that rely on sprite 0 hit?
Bunnyboy, you posted in another thread that you have to connect the two ground pins in order to get a cartridge to work in a Famiclone. Does the PowerPak PCB have the two grounds connected? If not, I'm wondering if that may be the root cause of these graphical issues.
Great Hierophant wrote:
You should always be using the GoodNES v3.10 roms that have a [!] or a [!p] in the filename. If you are not, to quote from one of my favorite movies, "I have no sympathy for you gents."
Thanks for the tip, I found a BT of Goodnes 3.10 roms just like you describe, again, no difference. I also redownloaded the mapper files again, same thing.
Unfortunatly, I only have one NES, my toaster, to test it on.
I should say, none of the games I
tested ever crashed. I guess I missed the ones with data in CHR-ROM.
Speaking of which, how exactly is data pulled from CHR-ROM? My NES hardware knowledge is still somewhat limited...
BMF54123 wrote:
Speaking of which, how exactly is data pulled from CHR-ROM? My NES hardware knowledge is still somewhat limited...
CHR-ROM (or CHR-RAM, whichever is present on a cartridge) is connected to the PPU directly, so it has direct access to data in the CHR-ROM. If the CPU (i.e. the program code) needs to read data from CHR-ROM, it has to go through the PPU registers ($2006 and $2007) to get the desired data.
Okay, roms are all sorted out and as GoodNES as they get.
Only one problem game that I remember stopped having problems (F-117) the rest are still experiencing the same exact minor graphical corruption.
Random list off the top of my head:
Code:
Excitebike (JU) [!] Player, starting gates, temperature gauge
Donkey Kong 3 (U) [!] DKs fists, feet (title) / 2nd level vines
Family Feud (U) [!] Hosts feet corrupt while walking in beginning
Shinobi (Unl) [!] Enemy sprites
R.C. Pro-Am (U) (PRG0) [!] Player race position indicator (right half)
High Speed (U) [!].nes Severe corruption
Klax (Unl) [!].nes Massive graphical corruption / playfield jitter
Skull & Crossbones (Unl) [!].nes Corruption / Massive playfield jitter
Punch-Out!! (U) [!] Severe opponent corruption
Ms. Pac-Man (Unl) [!].nes playfield graphical corruption
Rolling Thunder (Unl) [!].nes massive score area jitter/corruption
There's more I'll note them as I go through them.
Do you have a way to tell which mapper #s go to what games? Castlevania III won't run on mine, but I dunno what the # is.
I have also noticed that (E) games run better than (U) games on mine. Maybe my cyclone chip isn't set in the proper region?
cd_vision wrote:
Castlevania III won't run on mine
Castlevania III uses the MMC5 mapper, which the PowerPak does not support (yet).
Quote:
Maybe my cyclone chip isn't set in the proper region?
If that was the case, you'd be getting resets every second. The CIC(lone) only keeps your system from resetting, and has no impact on the game that's running.
Anyone else having CF issues? I have to power-on, power-off, power-on again for the PowerPak to recognize the card. The first time it completely bugs out, after that it works like a charm on an old model FC. It could be the card though.
One mapper bug I've come across is the IRQ ctr for Skull & Crossbones's mapper. I'm not sure if Shinobi is the same mapper, but that works fine though I don't think it uses IRQs.
i just tested the power pak on a NES-CPU-11 and had great results. mario 3 worked flawlessly as did both versions of punchout. i did have severe graphical errors with pinbot, karnov and high speed, but when compared to the other systems i tested on, most games looked good.
Yay!
I haven't got mine yet but I guess it's in the mail now. I don't mind doing a simple resistor fix. We all knew that this sort of thing could happen. I'm waiting for the instructions. Hopefully mine should be here this week, I'm getting my CF card ready.
Quote:
Excitebike (JU) [!] Player, starting gates, temperature gauge
Donkey Kong 3 (U) [!] DKs fists, feet (title) / 2nd level vines
Family Feud (U) [!] Hosts feet corrupt while walking in beginning
Shinobi (Unl) [!] Enemy sprites
R.C. Pro-Am (U) (PRG0) [!] Player race position indicator (right half)
High Speed (U) [!].nes Severe corruption
Klax (Unl) [!].nes Massive graphical corruption / playfield jitter
Skull & Crossbones (Unl) [!].nes Corruption / Massive playfield jitter
Punch-Out!! (U) [!] Severe opponent corruption
Ms. Pac-Man (Unl) [!].nes playfield graphical corruption
Rolling Thunder (Unl) [!].nes massive score area jitter/corruption
I have already pointed out the problem with High Speed and can confirm in part the problems with Skull & Crossbones (jittery screens) and Klax (jittery screens and moderate graphical glitches.) The rest of these games work perfectly for me (Punch-Out works almost perfectly with loopy's Map09.)
bunnyboy wrote:
Quote:
I have seen some background white lines but not often enough to tell if this fix makes those right too. If half of heads are missing in SMB3, this is the problem!
Oddly enough SMB3 is nearly glitch free here, except for some faint partial line corruption in the title and overview map. And that doesn't even happen all the time.
Did the hardware fix, haven't had any sprite issues since, but haven't been able to do a wide test.
Really should get a set of roms for a more standardized cross nes/user testing.
Please disregard what I have said about all the Camerica/Codemasters games for now, some of them display the same glitches using real cartridges.
I have compleated the mod and I am now unable to get the raphics problems with the strange lines although wario's woods has not changed
note: use the smallest resistors you can get if you attempt the mod with large ones it proved difficult to fit them all in place, I managed though
I have not tryed serface mounts but it may be the best bet perhaps with a little 30awg wire if nessasery
I'll go in for a bag of 100 ohm 1/8 watt resistors:
http://www.jameco.com/webapp/wcs/stores ... tId=107916
$5 to ship, argh.
Unless someone has some, they could send for $1 ?
I have ~100 120 Ohm resistors if anyone needs them
drk421 wrote:
I'll go in for a bag of 100 ohm 1/8 watt resistors:
http://www.jameco.com/webapp/wcs/stores ... tId=107916$5 to ship, argh.
Unless someone has some, they could send for $1 ?
Starting Monday, Jameco will be on my way to work. I can probably pick up stuff on my commute and then discreetly send stuff via USPS using regular envelopes and postage.
I have started a section on the wiki (
nesdevwiki.org) for the problem games. It will be updated with any more info and should be easier to follow than a thread format. Looks like most of the problems (besides the resistor fix) are on the mmc3 irq and camerica games.
Just came this morning. I've only tried a few games but it seems to be glitch free so far. I will probably do the resistor mod. Is it easier to do with the resistor chip than with individual resistors?
Lloyd Gordon wrote:
Just came this morning. I've only tried a few games but it seems to be glitch free so far. I will probably do the resistor mod. Is it easier to do with the resistor chip than with individual resistors?
I would imagine so. I used the relatively large 100ohm resistors from radioshack and had quite the time getting them all to fit and stay properly.
Just tried about 6 more games and everything looks great so far on my front loader. I did use the Nintendo certified cleaning device
. I'm going to keep looking for bad games before I add the resistors.
check super mario 3 load it up a few times and some should show up one of the times
The link to buggy mappers on the main page of the Wiki appears to be broken.
I needed a 'play' unit anyhow, so I picked up another toaster (much lower serial 2009744) and it exhibits none of the common sprite glitches. Just the mapper related and known stuff.
Still going to get the resistor fix done though
Woo first post
Anyway about Micro Machines ROM floating around, I think the ROM is bad... why? Well I've dumped Micro Machines myself and the game runs perfectly on the PowerPak.
- Martin
My copy of Micromachines works fine on my PowerPak too.
Could you check the other games that use that mapper like Fire Hawk and Fantastic Adventures of Dizzy? I think the bad ones are actually dumped as mapper 2 (unrom).
Both Goodnes v3.10 dumps of Micro Machines are right, their CRCs correspond with bootgod's. However, as I can attest, Camerica/Codemaster's games are really finicky when it comes to NTSC. In Quatro Sports, the Baseball game flickers wildly on one of my TVs and not at all on another TV! (This is using a true Aladdin Deck Enhancer, either with a NES or Famicom AV.)
Quote:
Could you check the other games that use that mapper like Fire Hawk and Fantastic Adventures of Dizzy? I think the bad ones are actually dumped as mapper 2 (unrom).
All Codemasters games, except for the Quattro 4-in-1s use mapper 71. According to kevtris, the only difference between UNROM and BF9093 games is the address range that operate the lockout defeater.
Firehawk is assigned mapper 71, but like Karnov and Low-G-Man, I think it needs its own mapper. Mapper 71 is has hardwired mirroring. Firehawk uses one-screen mirroring, like the A*ROM series. A*ROM would not work with it because one of its 16KB banks is fixed.
Karnov has a similar problem. Its mirroring is hardwired, but the standard mapper 4 designates mirroring as mapper controlled. I think by emulating the register that switches the mirroring, Karnov gets broken.
As for Low-G-Man, it suffers from needing an open bus on addresses where quite a few other games expect RAM. iNES is too limited to deal with this in mapper 4, so a new mapper is needed.
Firehawk and Dizzy both work great too. Maybe it's because I use a PAL NES that I don't get the same flickering as on NTSC consoles?
However I tested the Micro Machines rom from the GoodSet and it goes crazy on my PowerPak while my own dump works... which led me to believe that the rom in the goodset is bad.
Maybe the resistor mod fixes all the Camerica games, I haven't had it performed yet.
Micro Machines from GoodNES 3.10 had flickering during the race on my PAL NES, as well as messed up graphics at the player selection menu iirc.
Fire Hawk also had some flickering in-game. Linus Spacehead was ok I think.
If the 8K WRAM were initialized to the open-bus values (i.e. set $6000-60FF to $60, $6100-61FF to $61, and so on), would that fix Low G-Man? I remember Nestopia doing this, at least in earlier versions of the emulator (the latest version allows for the possibility of no WRAM, with the addition of NES 2.0 support).
dvdmth wrote:
If the 8K WRAM were initialized to the open-bus values (i.e. set $6000-60FF to $60, $6100-61FF to $61, and so on), would that fix Low G-Man?
It depends. Does the game write to WRAM? If you have it, run it in FCE Ultra and set a write breakpoint on $6000-$7FFF.
Atlantis no Nazo (J) pukes invalid characters into the Game Genie code list when I hit Reset, and they don't go away until I cycle the power. I think they're even being interpreted as codes, because half the time I try to start the game again, it just locks up. Attempting to change the characters usually crashes the BIOS and gives a card failure error upon reset.
I'm assuming that proper register/RAM initialization in the BIOS would solve these problems?
BMF54123 wrote:
Atlantis no Nazo (J) pukes invalid characters into the Game Genie code list when I hit Reset, and they don't go away until I cycle the power. I think they're even being interpreted as codes, because half the time I try to start the game again, it just locks up. Attempting to change the characters usually crashes the BIOS and gives a card failure error upon reset.
I'm assuming that proper register/RAM initialization in the BIOS would solve these problems?
I also have experienced this once. ever since I always push the power button instead of reset when changing game as to make sure that no strange data is left in memory
BMF54123 wrote:
Atlantis no Nazo (J) pukes invalid characters into the Game Genie code list when I hit Reset, and they don't go away until I cycle the power. I think they're even being interpreted as codes, because half the time I try to start the game again, it just locks up. Attempting to change the characters usually crashes the BIOS and gives a card failure error upon reset.
I'm assuming that proper register/RAM initialization in the BIOS would solve these problems?
I know the cause of this problem. The BIOS is not setting the stack pointer on reset. Certain games can have the stack pointer set to point to a lower portion of the stack page ($0100-01FF), which will mess up the boot ROM. GameGenie codes, for example, start at RAM address $0110 and run through $0137. If the stack pointer were in this range, the GG codes will be corrupted and trying to change them will crash the boot ROM (due to the stack collision).
Yup its my old bad init code, probably also causing the rare files not displayed too. Correcting the stack pointer in the modules code will fix many problems but there still could be stack collisions in the early boot code.
Argh! I don't want anymore PowerPak fixes now that cannot be fixed with a software update!
Revisiting the Karnov issue...
Some emulators, including Nestopia, have assigned Karnov (and presumably other MIMIC-1 / Namco-109 games) to mapper 206. The "official" name of mapper 206 is DE1ROM (which is the name of the board on which Karnov was released). Mapper 206 is not currently supported by the PowerPak. Once it is, Karnov should be playable after the mapper number is changed in the INES header (you'll have to make the change manually because GoodNES does not appear to be aware of this mapper).
Bunnyboy, here's now mapper 206 should be implemented (from what I can tell):
1. Registers $8000 and $8001 should be identical to the MMC3, except that the upper 2 bits of $8000 should be ignored. As is the case with the MMC3, these registers should be mirrored throughout the $8000-9FFF space.
2. Writes to $A000-FFFF should either (a) be ignored or (b) mirror $8000-9FFF. Nestopia does (a), but (b) is more likely what the hardware does. (Kev's description of the mapper doesn't cover this issue.)
3. Mirroring is hard-wired. There is no WRAM or IRQ support. The only thing the mapper supports is PRG/CHR bankswitching.
Anyone else having problems with Batman: Return of the Joker (FME-7) randomly locking up on a glitched screen? The first time, it happened shortly after I started the game, and the second time, I got through several stages before it happened. Both connectors are clean, and I haven't had the same issue with any other games, aside from those already reported.
BMF54123 wrote:
Anyone else having problems with Batman: Return of the Joker (FME-7) randomly locking up on a glitched screen? The first time, it happened shortly after I started the game, and the second time, I got through several stages before it happened. Both connectors are clean, and I haven't had the same issue with any other games, aside from those already reported.
Haven't had a problem like this... do you have another NES/Famicom to try it on?
i cant get spy hunter to work at all (after goodnes as well)
coinheaven wrote:
i cant get spy hunter to work at all (after goodnes as well)
I seem to remember this game often having the mirroring set wrong (should be horizontal IIRC). I don't know if GoodNES fixes improper mirroring flags or not. The game is CNROM, so it's very unlikely to be a PowerPak bug.
so does that mean it is a bad dump?
it means the headder may be set wrong
Is this the one with the circus gang? It works Ok on my powerpak (I ran goodnes fixnes first).
I'm curious what it is about Abadox that prevents it from working with the PowerPak. It just loads up a black screen. The copy I'm using is good, according to GoodNES 3.10, and it's just a MMC1 game.
Have you tried Abadox (J)? I know I've played it on my PowerPak, don't remember which region though.
Yeah, I've tried both the US and Fami versions, neither one will work for me. I just now tried both again to be certain, and I'm still getting nothing.
Check the ines header of the file
I tried Abadox. It didn't load the first time but the second time it worked perfectly.
Abadox executes CLI instead of SEI at the start of the reset code (most likely a programming bug). The PowerPak boot ROM does not touch any APU registers AFAIK, so frame IRQ's are probably active, which would prevent this game from loading (since its IRQ code is simply an RTI instruction).
If you load any game other than Abadox first, then press Reset and select Abadox afterwards, it should boot fine.
Ah, that did the trick. Thanks much.
I can't seem to save in FF3E...
Using 1.10 BIOS, 1.11 Mappers.
Save, hold reset, save to a file, come back, no data is there.
drk421 wrote:
I can't seem to save in FF3E...
Using 1.10 BIOS, 1.11 Mappers.
Save, hold reset, save to a file, come back, no data is there.
Can you save in other games, or is this the only one giving you problems?
If this is the only game with problems, try saving to a different 8K .sav file on the card. Also, make sure you're saving properly within the game (I think FF3 doesn't let you save until you finished the first area of the game).
You may also try reading the .sav file back to your computer and seeing if the saved data shows up in an emulator.
Could someone please load Dirty Harry (U) on their PowerPAK? It loads for me... but strangely it won't let me start the game. It just loops the intro forever. On the emulator I just press start and it begins, but on the NES it doesn't recognize it or something.
Quote:
Can you save in other games, or is this the only one giving you problems?
Other games save just fine, this is the only one I'm having problems with.
Quote:
If this is the only game with problems, try saving to a different 8K .sav file on the card. Also, make sure you're saving properly within the game (I think FF3 doesn't let you save until you finished the first area of the game).
Tried saving to a different file, and no luck. I'm saving after the first area, works fine in an emulator.
Quote:
You may also try reading the .sav file back to your computer and seeing if the saved data shows up in an emulator.
The save file has data in it (when I open it in a hex editor), but it doesn't work in an emulator, and vice versa (emulator save file doesn't work for the powerpak).
Has anyone else tried saving with FF3E?
I'm using "Final Fantasy III (J) [T+EngR2_AWJ+NCorlett+SoM2Freak].nes" (GoodNES).
Can you post a link to the .sav file generated by the PowerPak? Also, can anyone else reproduce the bug?
Other things to try:
1. Save to each of the three save slots and see if the problem is only affecting one of them.
2. Save, then press (don't hold) Reset and see if the data is still there.
Another game that doesn't work right that seems odd as it's marked as a good mapper. Fire Emblem Gaiden (MMC4). The game runs, but it's not doing it's MMC2 like bankswitching for graphics. This is most noticable whenever you character attacks his animation is all screwwed up tiles. Is MMC4 support incomplete? I know MMC2 seems to work fine which makes it odd that what I believe is a shared feature isn't in MMC4's mapper file.
Quote:
1. Save to each of the three save slots and see if the problem is only affecting one of them.
All of the slots are effected, which means none of them retain their data when trying to save/load.
Quote:
2. Save, then press (don't hold) Reset and see if the data is still there.
All the data is still there (three slots), after a reset (not holding).
I tried creating a new save file and saved in the menu, but it remained all zeros when I looked at it in a hex editor.
I will try it again, and see if it modifies the save file.
drk421 wrote:
I tried creating a new save file and saved in the menu, but it remained all zeros when I looked at it in a hex editor.
Try this:
1. Load any 8KB file as your battery data for FF3. It's best if you don't use a typical FF3 save file (e.g. use a battery file for another game).
2. Start the game and get to the first battle (you don't need to save - just get to the first battle).
3. Reset to the boot ROM and write the data out to another (preferably blank) 8K file.
4. Compare the two files and see if the data matches or not.
Quote:
1. Load any 8KB file as your battery data for FF3. It's best if you don't use a typical FF3 save file (e.g. use a battery file for another game).
2. Start the game and get to the first battle (you don't need to save - just get to the first battle).
3. Reset to the boot ROM and write the data out to another (preferably blank) 8K file.
4. Compare the two files and see if the data matches or not.
The data is exactly the same.
I even tried going through the first part and saving, and the file is still exactly the same.
If the data's exactly the same, then it means FF3 isn't modifying it in any way, which can only mean it's accessing a different portion of the 32K WRAM chip. For MMC3, only the first 8K should be accessible - maybe bunnyboy made a mistake and a different 8K bank is being swapped in.
If that's the case, then using a 32K file should fix the problem, since it will capture everything in the WRAM (assuming bunnyboy's fix for larger .sav files works). Try giving FF3 an enpty 32K .sav file. Play until the first battle, then reset to boot ROM and save. Then check to see if there's any non-zero data in the file. (FF3 uses WRAM for more than just saved data - its sound system, level map decompression, menu system, and battle system all use different portions of WRAM, so by the time the first battle starts, plenty of opportunities will have passed for WRAM data to be modified.)
Tried a 32K save file, and the last 8K of the save file (starting from 6000h), has valid FF3 save data. I was also able to load/save my game now
I tried the data in an emulator and it worked.
Thanks for the help!
Glad to hear it. I guess bunnyboy has WRAM A13 and A14 high instead of low, causing the last 8K bank to be swapped in. This is an error, and he should fix it in a mapper update. If/when that fix is applied, you will need to extract the good 8K and throw out the bad 24K before using the .sav file with the updated mapper files. (At least this isn't a boot ROM issue this time...)
I suspect all MMC3 games (mappers 4, 118, and 119) are likely affected by the bug (possibly other mappers as well, depending on what gets reused from one mapper implementation to the next).
I just loaded up Armadillo for the first time, and found the background flickers to the point of making the game essentially unplayable. Just thought I'd mention it since bunnyboy has mapper 118 listed as good.
I tried to play armadillo. The beginning of the first level is fine. As soon as you go to the right the background turns to blank blue sky so you can't see what you are doing. Looks like the wrong CHR bank is being used. There was no flickering though.
I seem to remember that mapper 118 game being cause for problems with emulators back when it was assumed to be a single-screen mapper (which it isn't).
Proper m118 implementation:
If $8000.D7 is clear:
command 0 affects $0000-07FF (D1-D6) and $2000-27FF (D7)
command 1 affects $0800-0FFF (D1-D6) and $2800-2FFF (D7)
command 2 affects $1000-13FF (D0-D6) and $3000-33FF (D7)
command 3 affects $1400-17FF (D0-D6) and $3400-37FF (D7)
command 4 affects $1800-1BFF (D0-D6) and $3800-3BFF (D7)
command 5 affects $1C00-1FFF (D0-D6) and $3C00-3FFF (D7)
If $8000.D7 is set:
command 0 affects $1000-17FF (D1-D6) and $3000-37FF (D7)
command 1 affects $1800-1FFF (D1-D6) and $3800-3FFF (D7)
command 2 affects $0000-03FF (D0-D6) and $2000-23FF (D7)
command 3 affects $0400-07FF (D0-D6) and $2400-27FF (D7)
command 4 affects $0800-0BFF (D0-D6) and $2800-2BFF (D7)
command 5 affects $0C00-0FFF (D0-D6) and $2C00-2FFF (D7)
In theory, a 256K CHR game using m118 would have bit 7 of each register control both CHR and CIRAM bankswitching. I don't know if any m118 games use 256K CHR or not.
Lloyd Gordon wrote:
As soon as you go to the right the background turns to blank blue sky so you can't see what you are doing. Looks like the wrong CHR bank is being used. There was no flickering though.
Yeah, that's exactly what happens. Sorry, dunno where I came up with the flickering thing.
I haven't had time to check these so it isn't official, but the (hopefully) fixed mmc3 (and possibly 118) is up at
http://www.retrousb.com/downloads/POWERPAK112.zip I also poked at MMC4 but I dont think that is fully working yet. Fixed a typo but I think there is another problem too.
Sorry BunnyBoy, Armadillo still has the same problem with .112
MMC4, Fire Emblem Gaiden has improved. The only problem I've noticed so far is the right side of some windows (outside of battle) are missing the right side. But the game is more enjoyable now that you can see your characters battling. =)
Dirty Harry (U) still suffers the problem where input is not recognized at all.
Does anyone know what hardware Armadillo actually has? Mapper 118 is supposed to be TLSROM/TKSROM, which is standard MMC3 except CHR A17 is connected to CIRAM A10 to get single screen mirroring control. I checked that on a real TLSROM game (Pro Sport Hockey) and all the other 118 games seem to be working fine.
bunnyboy wrote:
Does anyone know what hardware Armadillo actually has? Mapper 118 is supposed to be TLSROM/TKSROM, which is standard MMC3 except CHR A17 is connected to CIRAM A10 to get single screen mirroring control. I checked that on a real TLSROM game (Pro Sport Hockey) and all the other 118 games seem to be working fine.
It should be mapper 118. Here's my code analysis of the game:
The game sets all CHR bank registers to the range $00-7F at V-Blank, then sets them to the range $80-FF when the (second) IRQ fires during the frame. During VRAM updates, the CHR banks for commands 2 and 5 get set to either $00 or $80 (depending on what needs to be updated). Since the game uses inverted CHR banking (bit 7 of $8000 is set), this corresponds to $2000-23FF and $2C00-2FFF. When the VRAM updating is done, all CHR bank registers are refreshed with values in the $00-7F range.