The first batch of PowerPaks is now available at
www.retrousb.com!
This is the first production version so there are bugs, will be bugs, and hopefully all bugs can be fixed. If you are expecting a perfect product, do not buy this cart.
Pleeease release the constraints file so I can start working before it arrives. Which Foundation/WebPACK is suitable? Thanks
bunnyboy wrote:
This is the first production version
Will there be subsequent production versions, or is this a once in a lifetime offer?
Woo hoo! Ordered!
Quote:
Will there be subsequent production versions, or is this a once in a lifetime offer?
I expect I will have more boards made, but it will be at least 2 months until they will be available. Could be longer than that if any problems that need fixing appear. Future hardware versions will not have any advancements like more RAM or bigger FPGA.
Quote:
Pleeease release the constraints file
Sorry will have to wait a bit! I will be putting out a package with one complete mapper like cnrom to show how all the config works. Everything is built on Xilinx WebPack ISE 9.1i, which I believe is the most recent free downloadable version. The files should also be convertable to 8.1 and possibly earlier versions. Everything I have done is straight schematics, no HDL
Will there ever be an ability to play NSF files straight from the cart?
Also, what about N106 and other sound chips? Can these be emulated through the cart?
Quote:
Will there ever be an ability to play NSF files straight from the cart?
NSF is scheduled for the next mapper upgrade, which is just an update of the files on the CF card. Bankswitching will be no problem, but expansion audio chips will not be supported. There is no (simple) way to get the audio from those chips mixed into the NES audio. Will have to wait for PowerPak FDS for that!
so.........
have any been shipped out yet?
Haha! It seems we're all very impatient! =D
I know I can't wait to put my hands on mine! =)
Don't worry, most of the orders will ship out today! First people should get theirs around Friday, international will be sometime next week. This batch is almost sold out on the website. I have ~20 more unflashed boards, ~10 failed boards (likely bad soldering), then it will be many weeks until any more are available.
I'm surprised theres any left to be honest.
I missed the NWC batch again.
Oh well, gives me a chance to finish some coding
Al
albailey wrote:
I'm surprised theres any left to be honest.
I can think of several reasons why:
1. It hasn't been dugg...yet. (Of course, neither has the NWC cart AFAIK.)
2. There's that limit of 2 per person. (There is no limit AFAIK on the NWC cart.)
3. High price point.
4. Bugs. I for one am waiting for the product to become more reliable. I don't have to have this thing "right now" - I can wait, and I'll wait a year (or longer) if need be.
dvdmth wrote:
1. It hasn't been dugg...yet. (Of course, neither has the NWC cart AFAIK.)
...
4. Bugs. I for one am waiting for the product to become more reliable. I don't have to have this thing "right now" - I can wait, and I'll wait a year (or longer) if need be.
These are very good points. In an ideal word, this would stay off of Digg for a little while - and then hit it with an independent review detailing how incredibly cool this thing is. If this hit dig right around the time Bunnyboy had his second batch ready to go (with any bugfixes), I imagine the digg crowd would clean him out.
A quick note on the "high price point" comment. I agree it's a little pricey for a lot of hobbyists - but it is really a steal for what it is. I can't imagine bunnyboy's margin on these things is very much at all - and I know the development costs had to be in the $1K to $3K range, even if you count labor as free. Milling machines don't grow on trees, and he had to do multiple passes of the PCB's, including going through a board stuffer since the parts are so small. I spent well over $500 developing prototypes of my own multi-cart board, and it never came anywhere near completion, much less production. Don't tell bunny, but I would gladly pay twice the price for for this item.
You won't get any argument from me about the price being too high - in fact, I'm surprised it's as LOW as it is, given all the effort bunnyboy had to put into it. But it's still a lot of money to spend on a cartridge for such an old system, and that will keep some people away from the product.
I wonder how large his first batch was
I just saw that you haven't been able to test the PowerPack on a Famicom.
I can test my powerpack on an original Famicom and an A/V Famicom with a 72-pin converter when it comes in. I don't see why it wouldn't work.
Please do. If it doesn't work, we'll have to make it work somehow since all I have around me are Famicoms.
(Yeah, I know: water, water everywhere...)
peppers wrote:
I wonder how large his first batch was
I think there were supposed to be 100, though the number may have changed.
I wonder what name Cowering will give the boot ROM when it's added to GoodNES's database....
The NES PowerPak just got
Kotakuieted and most think it's an absurd and expensive idea.
I do not think so.
Zuerihb wrote:
The NES PowerPak just got
Kotakuieted and most think it's an absurd and expensive idea.
I do not think so.
Some of the people replying to the Kotaku post think that the cart only has 512k of storage... even though it says it runs on CF cards. Hello? Bueller?
Only 512 KiB of PRG RAM is a drawback if you want to run 100-in-1 Contra Function 16 or anything else with a 1024 KiB PRG.
A good alternative would be to put all games featured in 100 in 1 individually on your Compact Flash cart, and then put it in PowerPak.
Bregalad wrote:
A good alternative would be to put all games featured in 100 in 1 individually on your Compact Flash cart
But were there any single games using a 1024 KiB or larger PRG? Can
Action 52 be split into its components?
I don't know, but I think the only 1MB official game is Metal Slader Glory, wich is 512 KB PRG and 512 KB CHR.
Bregalad wrote:
I don't know, but I think the only 1MB official game is Metal Slader Glory, wich is 512 KB PRG and 512 KB CHR.
Which fits in the PowerPak, right?
Guido Anchovy wrote:
Zuerihb wrote:
The NES PowerPak just got
Kotakuieted and most think it's an absurd and expensive idea.
I do not think so.
Some of the people replying to the Kotaku post think that the cart only has 512k of storage... even though it says it runs on CF cards. Hello? Bueller?
I had never seen that message board before... don't think I'll go back. Did anyone read the comments? What a bunch of idiots. My favorite quote was this one:
realyst2k wrote:
135$ is far far far too much.
No way in hell there's that much tech in that cart. Nor would it cost that bloody much to manufacture. Hell, there are(less elegant) DIY projects for far cheaper fer cryin' out loud.
Lower the price, blokes, and you got a deal. Until you wake up, however, I'll stick with my NESten.
No way there's "that much tech in that cart"? What does that even mean? Nobody on that board put together that the fact it took 25 years for a universal cartridge to be made was because: it's really difficult!
There's so much bad information in that thread, and unfounded accusations of overpricing the powerpak, that I'm really disappointed. Maybe the masses just aren't ready for this product.
Sure it's expensive for a casual player, who's happy to play emulated games on their newer consoles. But that's not who it's for.
Yes a few dumbshits but there are positive comments also
obviously a "DIY" project with 64 memory mappers would cost more than $135 I have never been to that site before ether but it seems to be a community witch are not paticularley into this kind of stuff there are other forums witch there would be less jackassery
Btw when someone gets there’s in let us know
Since I started placing my order during the first second it was out refreshing as soon as it appeared to do so I should be one of the first to get mine I will do so also
I wish I was up to this level of DIY. I guess whoever wrote that has never held a screwdriver let alone a soldering iron. I'm gladly waiting for mine.
Kotaku.com is good for News, but most commenters don't know Jack.
I will order mine in a later batch, and I'm waiting for the reviews.
I'm still waiting for mine to ship...
I got mine. I'm very impressed with the build quality! I also dig the seal seal.
It starts up on my Famicom, I haven't had time to get it up and playing yet though and I probably won't until bunnyboy gets the mapper examples out :P
kyuusaku wrote:
I got mine. I'm very impressed with the build quality! I also dig the seal seal.
It starts up on my Famicom, I haven't had time to get it up and playing yet though and I probably won't until bunnyboy gets the mapper examples out
Can't wait to have mine to try it on my PAL NES. By the way, did you get any confirmation e-mail that it was shipped?
kyuusaku wrote:
I got mine. I'm very impressed with the build quality! I also dig the seal seal.
It starts up on my Famicom, I haven't had time to get it up and playing yet though and I probably won't until bunnyboy gets the mapper examples out
Got mine, too. It only had to ship about 15 miles, though.
Having some issues with my toaster NES with random gfx corruption (Punch-Out!, Zelda, et. al), so i'll need to find my top-loader to compare. Dollars to doughnuts it's my crappy toaster.
Just got mine! I don't even know why I'm posting.. I should be trying it out!
I did want to mention though, that the USPS notifier never got beyond the "electronic shipping info received" status. This has happened countless times before as well - their notifier only seems to work when packages are actually scanned and sent from an actual office, not printed and sent from home.
NC
Got mine too! So far, I've tested:
Duck Tales (US)
Rockman 4 (J)
Bugs Bunny's Crazy Castle (US)
Super Dodge Ball (US)
All work fine on my front loader!
I just started testing on my original Famicom and so far have gotten a little bit of random graphics corruption on all four of those games. It may be due to either a worn out connector on my old famicom or the crappy 72-pin converter. I will dig out my brand new A/V famicom in a little while and test that and let you know what happens.
UPDATE:
Tested the Powerpack in my A/V famicom and it works just fine on those four games above! I guess my old famicom needs a new connector.
I'm waiting for a review.
got myne today also probubley wont have time to extencive testing though
For those wanting to design their own FPGA config files, a sample mapper is avail at
www.nespowerpak.com/powerpakdev1.zip. It has pretty much zero documentation right now, so only bother with it if you can read schematics well!
That's everything we need
I'll work on getting some FC mappers going.
The first 1KB of the MAP03.MAP file is the plugin code. It handles the game loading and should work for any game that doesnt need special settings:
1 displays the Loading Game text
2 calls boot rom to load wram, writes whole .sav file into wram so 8/16/32KB files will work
3 calls boot rom to load prg, number of banks used from ines header
4 turns screen off
5 calls boot rom to load chr, number of banks used from ines header
6 calls boot rom to reprogram fpga config
7 calls boot rom to set mirroring, ignored if mapper controlled
8 calls boot rom to set prg/chr size
9 calls boot rom to load all game genie stuff
10 disables boot rom
11 jumps to ($FFFC)
All the mapper plugins are named MAPxx.MAP where xx is the hex num of mapper.
No cpu/ppu/apu registers are reset before jumping to game code, could this be where some graphics problems come from? I never touch the sprite dma or apu regs.
So, would the NES-scene be flooded with new high-tech mappers now?
And bunnyboy, are you a very busy guy or are you simply ignoring my pm's/e-mails?
tepples wrote:
Can Action 52 be split into its components?
Yes it can. You can extract each 32k from inside, add the VROM, and call it a mapper 0 game. Nesticle will even play them. Only problem is that some games bankswitch half way through (Billy Bob after level 2, Cheetahmen each 2 levels).
Oddly, the VROM bankswitching is almost identical to CNROM. (set cheetahmen 2 to mapper 3 and you can still watch the intro)
Dwedit wrote:
tepples wrote:
Can Action 52 be split into its components?
Yes it can. You can extract each 32k from inside, add the VROM, and call it a mapper 0 game. Nesticle will even play them. Only problem is that some games bankswitch half way through (Billy Bob after level 2, Cheetahmen each 2 levels).
Oddly, the VROM bankswitching is almost identical to CNROM. (set cheetahmen 2 to mapper 3 and you can still watch the intro)
It would be possible to split the cartridge into three ROMs, the first containing games 1-18, the second 19-36 and the third 39-52 or whatever combinations would fit into each 512KB chunk.
The more important question is "why would you want to?"
Great Hierophant wrote:
Dwedit wrote:
tepples wrote:
Can Action 52 be split into its components?
Yes it can. You can extract each 32k from inside [etc]
It would be possible to split the cartridge into three ROMs [etc]
The more important question is "why would you want to?"
Others would ask this question about the PowerPak itself.
I hope the postman comes with mine today
Got mine in the mail today (@ Sweden). I'm currently waiting for my GoodNES 3.10 download to finish so the only ROMs I've tried running so far are my own demos which are all NROM.. works great on my PAL NES. I'll try something like W&W or SMB3 later.
Picked up mine and mine friends from the post office today =)
and I can't belive it! my old code actually runs on hardware
Some MMC3 titles that I noted problems with:
* Contra Force (U) [!]
Corrupted graphics. Hangs after a while on the first level.
* McDonaldLand (E) [!]
Corrupted graphics.
* Super C (U) [!]
The first time it hanged at the title screen. The second time it stopped scrolling properly a bit into the first level.
It could be that these are bad dumps.. I haven't looked at the headers or tried them in an emulator yet.
[quote="dXtr"]and I can't belive it! my old code actually runs on hardware
quote]
But then, the PowerPak OS does some of the hardware setup for you, especially the waiting for 2 vblanks part and setting up a predictable mapper state (especially on mappers capable of 32 KiB PRG switching).
tepples wrote:
dXtr wrote:
and I can't belive it! my old code actually runs on hardware
But then, the PowerPak OS does some of the hardware setup for you, especially the waiting for 2 vblanks part and setting up a predictable mapper state (especially on mappers capable of 32 KiB PRG switching).
true. but I'. guessing that it still would work without the PowerPak setting up the PowerPak as I've also tested it on both Nintendulator and Nestopia.. thought you never know
I am curious as to how meny people (if any) are working on new mapper configuretion's for the project
peppers wrote:
I am curious as to how meny people (if any) are working on new mapper configuretion's for the project
I haven't started yet, but I'm qualified and interested. The Xilinx webpack is pretty easy to use, and bunny has provided everything that is needed. I was really hoping someone would organize a list of "these mappers have bugs, here's who's working on replacements". Also, any that I do I will release the schematics for, and bunny is more than welcome to use them in any way he wants.
I think we should all use a set of roms that use different mappers/etc to do base tests with just them on any NESes we have, then at least we'd have a better compatibility/bug list for them
(cross posted everywhere)
I think I have found the root problem for the sprite glitches. It is possible there is a software fix but it may have to be a hardware one. In that case I will be doing a recall and instructions for those that do not want to wait for shipping. I am still doing some testing but hope to have everything figured out this week. 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!
Even if you are not seeing problems it is probably a good idea to do the fix. Slight manufacturing variations in the NES systems means the board may work perfect on one system, but have major sprite problems on another system of the same kind. My test system is one that happens to work well so I did not know the problem was so big.
For those technical people, the problem appears to be a bus conflict during sprite DMA. The PowerPak responds too quickly which corrupts the data headed from the internal RAM to the PPU. By adding the resistors the cart will always lose the bus conflict and display correctly. The PRG and CHR rom/ram data are unaffected, which is why none of the supported games would crash.
Bus conflicts during sprite DMA... Are you saying that the address lines are not quite set correctly at the start of each DMA fetch/store? That's weird indeed....
I guess the PowerPak is just too good for the NES.
Sometimes I see the same (or similar) sprite-DMA glitches when I use my EPROM emulator. Resistors in series fixes that too. It's been kinda bad at times (severity seems to vary with the cart/system combo I hook it up to), but with all my setups I've never seen anything like those white lines in that video.
Instructions with bad blurry picts are now avail at
http://www.nespowerpak.com/powerpakmod.html. If you have done any electronics soldering or repro making then this should be pretty easy.
Memblers: Bananmos suggested it might be one problem and noted your experiences with the EPROM emulator too. Kevtris said some Sachen carts can crash his CopyNES bios if they don't have the resistors. Game Genie also uses them internally.
Hey that looks exactly like what I had to do to a Famicom adapter to get Namco 106 carts to boot:
My resistors may have been a little on the big side though
bunnyboy wrote:
Instructions with bad blurry picts are now avail at
http://www.nespowerpak.com/powerpakmod.html. If you have done any electronics soldering or repro making then this should be pretty easy.
Before i start cutting traces, i'm interested in hearing how folks make out with this mod. I'll take another look at my 'problem' images, but i feel like some of the issues would be beyond OAM DMA-related.
Works good for me. I tried 470 Ohm resistors, but that gave me a red screen, so I used 120 Ohm ones.
Grah, I HATE soldering. Either the stuff doesn't melt, or it balls up and doesn't stick. >_<
Maybe I'll just wait for a recall or software fix...
Will a mod like this make it into the second production batch?
Will this mod work if a game were to perform sprite DMA from external memory, such as WRAM (lda #$60 / sta $4014)? Don't know if any games do this (never saw a commercial title that didn't have sprites in $0200-02FF), but theoretically it is possible.
I tried removing sprite DMA from the game Mario Bros (=no sprites visible at all), but the game still glitches alot. I am no hardware-guru, but shouldn't it be glitch free if sprite DMA was the problem and I disable it?
oRBIT2002 wrote:
I tried removing sprite DMA from the game Mario Bros (=no sprites visible at all)
Doesn't the game freeze/crash when there are no sprites, because the sprite 0 hit at the top of the screen never happens?
Anyway, I'm still waiting for my PowerPak... I wish I didn't have to mod it, because it will sure look very ugly. But if I do get the problems some of you guys are reporting, I guess I'll have no choice.
oRBIT2002 wrote:
I tried removing sprite DMA from the game Mario Bros (=no sprites visible at all), but the game still glitches alot. I am no hardware-guru, but shouldn't it be glitch free if sprite DMA was the problem and I disable it?
Super Mario Brothers REQUIRES sprites to work, because it needs sprite 0 hit. You can try other games, though, such as Metroid, SMB2, SMB3, and others that don't rely on sprite 0 hit.
I'm happy to report that I got my PowerPak today, and it works on my Famicom Titler!
Of course, many games had nasty graphics glitches (I tried a few; Hebereke was pretty bad.)
I put 120 Ohm resistors in my 72->60 pin adaptor, and almost all the glitches are gone.
So, thanks a lot, bunnyboy! This is a marvel of engineering!
tokumaru wrote:
oRBIT2002 wrote:
I tried removing sprite DMA from the game Mario Bros (=no sprites visible at all)
Doesn't the game freeze/crash when there are no sprites, because the sprite 0 hit at the top of the screen never happens?
Anyway, I'm still waiting for my PowerPak... I wish I didn't have to mod it, because it will sure look very ugly. But if I do get the problems some of you guys are reporting, I guess I'll have no choice.
MarioBros works without sprites, however it gets quite difficult.
Oh, I thought you said "Super"...! =) I see you didn't. SMB expects a sprite 0 hit at the top of the screen, so I bet it would freeze without sprites.
dvdmth wrote:
(never saw a commercial title that didn't have sprites in $0200-02FF), but theoretically it is possible.
At least I remember Hanjuku Hero used $300-$3ff, and some other games used $700-$7ff but I don't remember wich ones.
Just for curiousity why does resistors in series fixes the problem ? Does it remove noise or something ?
Bregalad wrote:
Just for curiousity why does resistors in series fixes the problem ? Does it remove noise or something ?
Well, bunnyboy said the PowerPak was responding too fast or something, so maybe those resistors delay the signal?
Based on what bunnyboy said, the resistors are preventing the bus conflict from affecting the NES (the bus conflict still occurs, but the NES doesn't see the results of it). This is why I'm wondering if sprite DMA will work from WRAM with this mod.
I can by the way, confirm that PowerPak works on a Famicom A/V by using a 72-60 pin adapter. If anyone's interested.
If bunnyboy makes a new printed circuit board that fixes this problem, then doesn't that make all of the current carts ultra rare prototypes?
Jagasian wrote:
If bunnyboy makes a new printed circuit board that fixes this problem, then doesn't that make all of the current carts ultra rare prototypes?
I prefer having a later power pack that works than a ultra rare prototype that doesn't work.
Quote:
Well, bunnyboy said the PowerPak was responding too fast or something, so maybe those resistors delay the signal?
Resistors doesn't delay anything, they just increase the impedance.
Quote:
Based on what bunnyboy said, the resistors are preventing the bus conflict from affecting the NES (the bus conflict still occurs, but the NES doesn't see the results of it).
What bus conflict ? Sorry, but it's hard to follow when something is going on in 4 different threads at the same times (it's actually much worse than when more than one thigns goes at the same time in the same thread).
Quote:
Will a mod like this make it into the second production batch?
Yes the next boards will have this fix. I have not ordered the second batch exactly to find problems like this. Pretty sure it fixes the background fuzzyness (garbage sprites?) but I will still wait for more people to check it out. If you do see any problems AFTER the mod you should note the game with mapper of your rom, and type of system (front loader, top loader, famicom, av, etc). You can find out the mapper num and other header info by running the game through Nintendulator. It will display (but not fix) all the header info. The (hopefully) correct mapper/mirroring can be checked at bootgod's site:
bootgod.dyndns.org:7777
Bregalad wrote:
I prefer having a later power pack that works than a ultra rare prototype that doesn't work.
Same here.
Quote:
Resistors doesn't delay anything, they just increase the impedance.
OK, I admit... I don't know anything about electronics...
Quote:
Sorry, but it's hard to follow when something is going on in 4 different threads at the same times (it's actually much worse than when more than one thigns goes at the same time in the same thread).
I agree with you. Even if you follow them all, you never know what was said where.
Bregalad wrote:
What bus conflict ? Sorry, but it's hard to follow when something is going on in 4 different threads at the same times (it's actually much worse than when more than one thigns goes at the same time in the same thread).
bunnyboy wrote:
(For those technical people, the problem appears to be a bus conflict during sprite DMA. The PowerPak responds too quickly which corrupts the data headed from the internal RAM to the PPU. By adding the resistors the cart will always lose the bus conflict and display correctly. The PRG and CHR rom/ram data are unaffected, which is why none of the supported games would crash.
So bunnyboy, what are the chances that the artifacts can be fixed by a software upgrade?
The PowerPak needs its own forum (or its own section here at nesdev), as it's becoming really awkward even for me (and I have a lot of spare time right now).
If you read bunnyboy's description of the problem (which he posted in all of the threads), he describes the problem as a bus conflict during sprite DMA. I suppose the sprite DMA engine isn't quite running in sync with the Phi-2 clock, causing the address lines to be unstable at either the very start or the very end (don't know which) of each memory access cycle. It appears Nintendo's cartridges had a slow enough reaction time not to notice the out-of-sync nature of the sprite DMA engine. However, newer and better hardware is sensitive to the problem and will attempt a bogus memory read during sprite DMA operations, causing a bus conflict. This is my understanding of what the problem is (bunnyboy can correct me if I'm wrong).
what is a game witch these probelms are paticularley apperint so I can tell if my console is affected soldering 8 resistrs is no real problem for me but a bit of a nusance
peppers wrote:
what is a game witch these probelms are paticularley apperint so I can tell if my console is affected soldering 8 resistrs is no real problem for me but a bit of a nusance
If you haven't noticed it in any game yet, you probably have got a "good console". This is the way SMB3 (PAL) looks with my machine for example:
http://www.anes.se/powerpak.mpg
bunnyboy, did the mod, and it seems you fixed it! My tetris peices don't change when they fall anymore! (just the graphics, not the actual pieces.) Free PowerPak for you!... oh wait...
I do see the problem about 1/3 of the time when loading SMB3 so I guess Ill have to do it
Quote:
If you haven't noticed it in any game yet, you probably have got a "good console". This is the way SMB3 (PAL) looks with my machine for example:
http://www.anes.se/powerpak.mpg
I don't get those lines in SMB3 (I have a NES-PAL-001 model), but I get a similar effect in Mike Tyson's Punch-Out!! (E) (PRG0) [!] (using loopy's MMC2 mapper file)
dvdmth wrote:
The PowerPak needs its own forum (or its own section here at nesdev)
It appears that PowerPak already has one: it's called "NES Hardware / CopyNES".
Quote:
If you read bunnyboy's description of the problem (which he posted in all of the threads), he describes the problem as a bus conflict during sprite DMA. I suppose the sprite DMA engine isn't quite running in sync with the Phi-2 clock, causing the address lines to be unstable at either the very start or the very end (don't know which) of each memory access cycle. It appears Nintendo's cartridges had a slow enough reaction time not to notice the out-of-sync nature of the sprite DMA engine. However, newer and better hardware is sensitive to the problem and will attempt a bogus memory read during sprite DMA operations, causing a bus conflict. This is my understanding of what the problem is (bunnyboy can correct me if I'm wrong).
If I undestand things, during sprite DMA, the adress changes after the low-to-high edge of the phi-2 clock, and if the RAM or ROM present on the cartridges are too fast, they may resond to this quick state, wich correspond to reading the last adress, wich is where the "$40" of "sta $4014" was stored.
Then the on-board PRG-ROM or PRG-RAM is conflicting with the NES internal RAM used for actual sprite DMA. Because the NES internal WRAM is old and slow enough, it doesn't have problem so does the cartridges. Now this would only conflict with the very first DMA fetch, since the adress keeps in the RAM range for the whole DMA. This means that only the sprite #0 X coordinate is conflicted, wich can of course crash or add serious glitches all games relying on sprite #0 hit. For all other games, that'd just be a sprite glitched. Is this what happens ?
Adding 470 ohms resistors in series on the data bus higer the impedance of the cartridge, making the NES internal RAM winning the bus conflict. A lot of current may drawn in those resistors, tough (about 10mA per bus line) for a short while. Does this mean that adding resistor on the data bus is needed for all new cartridges with fast-responding EPROMs, Flash ROMs or SRAMs ? Or is it better to just pick slow ones ? Or is there a more proper way to fix thigs ?
dvdmth wrote:
The PowerPak needs its own forum (or its own section here at nesdev), as it's becoming really awkward even for me (and I have a lot of spare time right now).
Great idea. It should have it's own forum and the three topics about the powerpak should be move into the new forum.
Bregalad wrote:
If I undestand things, during sprite DMA, the adress changes after the low-to-high edge of the phi-2 clock, and if the RAM or ROM present on the cartridges are too fast, they may resond to this quick state, wich correspond to reading the last adress, wich is where the "$40" of "sta $4014" was stored.
Then the on-board PRG-ROM or PRG-RAM is conflicting with the NES internal RAM used for actual sprite DMA. Because the NES internal WRAM is old and slow enough, it doesn't have problem so does the cartridges. Now this would only conflict with the very first DMA fetch, since the adress keeps in the RAM range for the whole DMA. This means that only the sprite #0 X coordinate is conflicted, wich can of course crash or add serious glitches all games relying on sprite #0 hit. For all other games, that'd just be a sprite glitched. Is this what happens ?
Adding 470 ohms resistors in series on the data bus higer the impedance of the cartridge, making the NES internal RAM winning the bus conflict. A lot of current may drawn in those resistors, tough (about 10mA per bus line) for a short while. Does this mean that adding resistor on the data bus is needed for all new cartridges with fast-responding EPROMs, Flash ROMs or SRAMs ? Or is it better to just pick slow ones ? Or is there a more proper way to fix thigs ?
That explanation makes some sense, though it does appear that the conflict is affecting more than just sprite 0's Y coordinate (given the more corrupt nature of the reported symptoms). Perhaps the DMA is really 256 small DMA's that occur one after another, with the 6502's program counter appearing on the address lines between the transfers (since that would be the next byte needed by the 6502).
I know I said this before, but what happens when sprite DMA occurs from WRAM? Will it cause a bus conflict between the WRAM chip and the PRG chip (both of which are on the other side of the resistors in this fix)?
Then it would make sense to put reistors between the data bus and the PRGROM, but not between data bus and PRGRAM.
This is supposed to work exept :
1 - If the programm does "STA $4014" from the PRGRAM
2 - If the programm attemp to do sprite DMA from PRGROM.
Also, I don't see why this problem would not be occuring when placing fast EPROMs on a normal Nintendo-made cartridge board.
Bregalad wrote:
Also, I don't see why this problem would not be occuring when placing fast EPROMs on a normal Nintendo-made cartridge board.
I don't know. Perhaps it's an issue of whether or not the address lines are latched on M2 rising edge (don't know how ROM/RAM chips work, so I don't know if they see changes to the address lines in the middle of an access or not).
EDIT - I guess the /CE line is the most important. During a sprite DMA access, the PRG-ROM would be active for a brief moment at the start of a memory read, but when the address changes to point to internal RAM, the PRG /CE line would go high and thus halt the PRG-ROM from further activity. If the FPGA in the PowerPak controls the PRG directly and doesn't allow PRG /CE to "pass through," this change may not be visible to the PRG chip and cause it to continue a memory access when it shouldn't be.
Quote:
If the FPGA in the PowerPak controls the PRG directly and doesn't allow PRG /CE to "pass through," this change may not be visible to the PRG chip and cause it to continue a memory access when it shouldn't be.
PRG /CE is needed to known the state of A15 (without adding a wire to the bottom NES connector at least), so Powerpak definitely must watch PRG /CE to enable it's PRG SRAMs.
I decided for the heck of it to take a peek at the boot ROM code in a hex editor to see how much I could figure out. Three things stood out right away:
1. You don't seem to ever initialize the stack pointer. This wouldn't be important, except that you do appear to write something to $010D early on. On power-up, the stack pointer is $FD, but on reset it is set to three less than what it was prior to reset (which could be anywhere in the stack page, which in turn may corrupt whatever variables you have in that memory range).
2. I did not see any zero-age addressing modes in the code snippet I looked at. (Not important, but you might want to check your assembler.)
3. You didn't disable frame IRQ's in the boot ROM. Frame IRQ's are enabled on power-up, so if you don't take care to shut them off, an IRQ will fire every 1/60th of a second or so. You can disable frame IRQ's by writing $40 or $C0 to register $4017. (There is at least one game out there that won't work if a frame IRQ is pending at the time it begins execution.)
Sorry for being a snoop, bunnyboy.
Just a thanks to Bunnyboy. The PowerPak is amazing. I already have a 100 of so games on it so far and I'm working on the "rest". So far I haven't noticed any but the most minor glitches which look like normal NES stuff.
Well, mine finally arrived today. Nice piece of kit. The manual makes for a nice touch. It works 99% fine with my 512MB Maxell branded CF card. (There was one time so far when the browser was showing directories but no files, a reset fixed that).
As expected there were the reported gfx glitches so I proceeded to do the resistor fix. I have 3 PAL frontloaders and two of them still exhibit the same glitches, but at a much reduced rate and more confined to the top of the screen but one works near perfectly, if it wernt for it's loose fitting cart slot.