If you didn't get yours the first time around, the new ones with the resistor fix built-in are on retrousb.com. They went on sale a day or so ago, but are almost all gone! Just wanted to give everyone the head's up!
NC
Yeah, I saw that yesterday, along with the new boot ROM and mapper files. Let's see how good the MMC3 implementation is now.
Bummer there's no list of changes to the new version. So there's no other way to change the boot rom other than CopyNES? I've got a copynes, but it only works on PCs that are in states other than NH it seems, lol.
Can you update the mapper file to 1.10 without updating the boot rom?
-Rob
I don't have a CopyNES either, someone with one should write an updater ROM for the rest of us :) I haven't played with the PowerPak for a month or two, mostly due to many little annoyances; If I could fix them myself that'd be nice.
How important is it to change to the new bootrom? I don't have a CopyNes.
bunnyboy has not been around latley I wonder why he has not commented or mentioned the new files
rbudrick wrote:
Can you update the mapper file to 1.10 without updating the boot rom?
-Rob
I took a peek at the mapper files in a hex editor, and there does appear to be a ROM version check, so the files should work with either boot ROM version.
Based on the change log contents, I don't think it's critical to update the boot ROM unless you're having problems with battery RAM files (the older boot ROM will definitely not work with .sav files larger than 8K, but I don't think any mappers currently have WRAM banking implemented).
Would it be possible to have the powerpak update the bootrom itself? By software on the CF card?
Lloyd Gordon wrote:
Would it be possible to have the powerpak update the bootrom itself? By software on the CF card?
No, there's no way for an unmodded NES to flash the boot ROM, given how the PowerPak is wired. Unless someone makes an adapter, you'll need CopyNES to perform the update. Bunnyboy has stated before that he will offer to perform boot ROM updates for those who don't have CopyNES if there's a critical fix. I don't know if this update counts as critical or not (it's his call and his alone).
How is the wiring preventing a NES from rewriting the flash? By keeping /WE disabled? Perhaps a FPGA pin could be dedicated to /WE allowing updates in software.
But with a fully software-controlled BIOS update mechanism, malware could brick your PowerPak. I'd suggest placing a couple pads for jumpers on the PowerPak PCB, just as the Nintendo DS PCB has the SL1 bridge pads for installing softmods.
It wouldn't be that hard to have a jumper inside to allow for bootrom write enable/disable if it was possible.
Has anyone updating using CopyNES?
I tried to using option 3 (UfROM) flash cart in the RAM Cart menu, but it didn't do anything.
I remember that BunnyBoy said that you shouldn't use a Gamegenie or GameActionReply with the PowerPak as they could write to the bootrom. Doesn't that mean that updating the bootrom is possible without a copynes, maybe by the powerpak itself with software?
Lloyd Gordon wrote:
I remember that BunnyBoy said that you shouldn't use a Gamegenie or GameActionReply with the PowerPak as they could write to the bootrom. Doesn't that mean that updating the bootrom is possible without a copynes, maybe by the powerpak itself with software?
We would all like that (I know I would - I really want to update the boot ROM, but there's no way I'd buy a CopyNES or send the PowerPak back to the US) but I think that what he meant was that the boot ROM could be patched by GG codes, making it behave erratically - not that it actually writes anything to the ROM chip. I don't know.
No Carrier wrote:
If you didn't get yours the first time around, the new ones with the resistor fix built-in are on retrousb.com. They went on sale a day or so ago, but are almost all gone! Just wanted to give everyone the head's up!
NC
dag nab it i MISSED IT AGAIN - you should call me next time you find out they're available o.o
tokumaru wrote:
Lloyd Gordon wrote:
I remember that BunnyBoy said that you shouldn't use a Gamegenie or GameActionReply with the PowerPak as they could write to the bootrom. Doesn't that mean that updating the bootrom is possible without a copynes, maybe by the powerpak itself with software?
We would all like that (I know I would - I really want to update the boot ROM, but there's no way I'd buy a CopyNES or send the PowerPak back to the US) but I think that what he meant was that the boot ROM could be patched by GG codes, making it behave erratically - not that it actually writes anything to the ROM chip. I don't know.
forget the nes it should be possiple to develop a stand alone programmer fairley cheapley or use a pre exsisting programmer
the chip is a M29F0108 was anyboady able to find a datasheet? the closest I could find is a
one time programmable eprom witch is not helpfull sence its not the same
note:sence its the type of eeprom witch is easy to fit in a low profile socket it would not be too difficult to desolder the chip and install a socket (its actually the onley chip on there witch would be easy to remove and put back) maybe replaceing it with a more commen one witch my willen can handle assumeing it cant do this one
if this is a viable option perhaps socketing it standard in future board revisions would be an idea it would at the very least save the shipping costs back and fourth sence you could just mail the chip
I wonder how much the changes for the PowerPak would affect the
PowerPak mapper development kit. I used a hex editor to compare the MAP03 file in the kit to the most recent one, and there were some differences, not including updated dates. Maybe those changes are necessary for disabling WRAM properly or configuring the updated BootROM properly...?
There are two components to a mapper file, generic mapper 6502 loader code and the actual mapper fusemap. Any time you change one little thing in the mapper logic and compile it, the router may drastically change the fusemap from the avalanche effect. My guess would be that the update is in the loader code, not the actual fusemap (unless WRAM disable was added to the boot ROM which would be great!)
kyuusaku wrote:
My guess would be that the update is in the loader code, not the actual fusemap
I didn't find any differences in the loader code, which I believe is around offsets $0-3ff in the .MAP file. They were all in the fusemap.
strangenesfreak wrote:
I wonder how much the changes for the PowerPak would affect the
PowerPak mapper development kit. I used a hex editor to compare the MAP03 file in the kit to the most recent one, and there were some differences, not including updated dates. Maybe those changes are necessary for disabling WRAM properly or configuring the updated BootROM properly...?
Near as I can tell, all changes to the boot ROM and mapper files are documented in the posted change log:
http://www.retrousb.com/downloads/powerpakchanges.txt
The first entry in the mapper section involves reset detection. If my understanding is right, that change would need to be made with the FPGA, which would mean that all mapper files would need recompiling to incorporate the change.
Why not modify the next PowerPak ot have a USB Type-B port and wire it directly up to some free pins on the FPGA. 5V compliant right?
Then have a special 'Mapper' that acts as a USB device, and some software to flash the boot eeprom.
I haven't downloaded the Xilinx software yet. However it seems like it should be possible to have the PowerPak run some code in a .nes file that contains the new bootrom and have it update it.
PDP-13 wrote:
Why not modify the next PowerPak ot have a USB Type-B port and wire it directly up to some free pins on the FPGA. 5V compliant right?
Then have a special 'Mapper' that acts as a USB device, and some software to flash the boot eeprom.
Because a updater ROM image would be so much simpler? Remember beyond modding your PowerPak, you'd also need a synthesizable USB core that fits into a Spartan 2 and PC software and a power source.
Lloyd Gordon wrote:
I haven't downloaded the Xilinx software yet. However it seems like it should be possible to have the PowerPak run some code in a .nes file that contains the new bootrom and have it update it.
Not if the only the CopyNES can unlock the /WE pin (without modifying the PowerPak.)
kyuusaku wrote:
PDP-13 wrote:
Why not modify the next PowerPak ot have a USB Type-B port and wire it directly up to some free pins on the FPGA. 5V compliant right?
Then have a special 'Mapper' that acts as a USB device, and some software to flash the boot eeprom.
Because a updater ROM image would be so much simpler? Remember beyond modding your PowerPak, you'd also need a synthesizable USB core that fits into a Spartan 2 and PC software and a power source.
I could be wrong but cant this type of FPGA program a ROM via j-tag programming cable?
Yes, but then the PowerPak would need to be modified for JTAG and you'd need a $50 USB JTAG and still need PC software. If the PowerPak can be updated in software, at most it'd require a jumper + a resistor + wire.
BTW, for those who have CopyNES, I believe you need to perform the flash mod before you can update the PowerPak's boot ROM:
http://www.tripoint.org/kevtris/Project ... flash.html
This mod connects a pin on the CopyNES board to cart pin 16 (marked EXP0 on the pinout I have). I guess this is where the boot ROM's /WE line goes (although someone should confirm how the ROM is wired before attempting to update it without CopyNES).
Synthesiable USB core,
Like one of those:
http://www.opencores.org/projects.cgi/web/usb/overview
Also it seems a transceiver module is needed(?):
http://www.beyondlogic.org/usb/usbhard2.htm
USB provides 5V power, up to 500mA...
The real question is; would a USB core fit on a Spartan-2...?
PDP-13 wrote:
The real question is; would a USB core fit on a Spartan-2...?
Nope.
Unless you're using higher end FPGAs, a USB softcore is a stupid idea. USB is a pretty complex protocol and you could use something like a Cypress part instead of wasting presious Logic Units ( or so-called "Gates" in Xilinx bullMarketing ) inside the FPGA.
A simple way to put it: You could either fit a whole NES or a full blown USB core in a recent middle-range FPGA.
I hope this makes sense. I'm drunk, and english isn't my mother tongue...
Looks like PowerPaks are
on sale again! The mapper files have been
updated again to fix battery RAM loading and saving (you can see in the
changes file). I wonder when bunnyboy will post up an updated mapper development kit...
strangenesfreak wrote:
I wonder when bunnyboy will post up an updated mapper development kit...
What's there is all you need. What are you looking for? When I get 3GB of free hard drive space to install ISE I'll release my PowerPak mapper "wrapper" design which lets you design as if you were building the cartridge from scratch using original signals.
kyuusaku wrote:
What's there is all you need. What are you looking for?
There might be changes in the schematics for all the mappers for the BootROM or WRAM changes, which may (or may not) be necessary. How could these updated bitstreams be extracted from the new mapper files to check for any important fixes in the schematics, if possible?
Are those changes probably just for things outside the mapper files themselves (MAPxx.map)?
That's true if you want to exactly use Bunnyboy's new reset timing and SRAM logic, but it's not necessary to start developing your mapper. There's a good chance he'll update everything even more which will require another example mapper, but that shouldn't stop you from doing your thing.
AFAIK, there's no way to extract sensible data from bitstreams.
I don't know how the files are changed, just what's listed in the logs. Bunnyboy will have to chime in on that one.
Has anyone else tried checking out with PayPal? Doesn't seem to be working for me.
Well crud...
I tried flashing my PowerPak using the latest boot rom, and it didn't work. Now I have a dead PowerPak.
When I tried to flash it, I used NESDUMP3.NES, I got the following error:
"Invalid function call"
in NESDUMP3.BAS:loadplugin on line 14
(a = ASC(INPUT$(1, 16))
looks like its getting the header.
I thought you were sopose to just run the RAM cart option in copynes and load the suplyed "loader.nes" file, after performing the "flash programming mod"on the copynes
is this not the way to do it?
Nevermind, I figured it out.
For some reason, PP.BIN (in the PLUGDONE dir), would get zeroed (empty file), when trying to load the plugin.
I made it read only and that solved it.
Here is the updated addresses block, which holds the reset detecting circuit. Use this new one if you don't want the reset hijacked (need to hold reset for 2-3 secs). The old version will still work correctly too.
More sample schematics coming...
Here is the block for scanline irq by a12. This is the one that is currently used in MMC3 and RAMBO mappers.
clk => 20MHz on board clock
a12 => chr a12, must be clocked by clk before entering
m2 => m2 clocked by clk before entering
irqd => reload data
prgd0 => used for rambo m2/a12 select
rambo_mmc3 => 0=mmc3 mode, 1=rambo mode
mmc3A_B => 0=mmc3b 1=mmc3a difference is irqs when reloading with 0
irqout => 1=irq, must be inverted before going out to NES
It may take some poking to get it to work, email if you need help!
Excellent, thanks bunnyboy. Is this likely the last mapper update?
Nope I will continue working on those, next up is NSF playing for mappers 1.2. There are more common Japanese mappers that should be easy, and the VRC ones are used by lots of games. Eventually there is MMC5 too...
bunnyboy wrote:
Nope I will continue working on those, next up is NSF playing for mappers 1.2. There are more common Japanese mappers that should be easy, and the VRC ones are used by lots of games. Eventually there is MMC5 too...
I thought NSF's use a custom "mapper" independent of the original game, with bank registers at $5FF8-5FFF.
If 4K switching is an issue (i.e. you can't control PRG A12), you can get around that by loading every 4K of data twice (i.e. $0000-0FFF and $1000-1FFF contain the same data, $2000-2FFF and $3000-3FFF contain the same data, and so on). This would make PRG A12 a "don't care" and you can put the 4K bank selection on A13-A18. This technique will result in a macimum NSF size of 256K instead of 512K, but are there any NSF's larger than 256K?
dvdmth wrote:
bunnyboy wrote:
Nope I will continue working on those, next up is NSF playing for mappers 1.2. There are more common Japanese mappers that should be easy, and the VRC ones are used by lots of games. Eventually there is MMC5 too...
I thought NSF's use a custom "mapper" independent of the original game, with bank registers at $5FF8-5FFF.
Some NSFs use Famicom expansion sound, which depends on the mapper that the original game used.
tepples wrote:
Some NSFs use Famicom expansion sound, which depends on the mapper that the original game used.
Heehee... I forgot all about that....
Is there some way I can buy a PowerPak without a CF card and reader? I already have those and $130+ is a pretty steep price, even for a great product. Hope you'll understand; thanks.