So I had some old photos from March sitting around, and people happened to find them just a few days before it is all public
Basic specs is 128Mbit of SDRAM to handle (bigger than) the biggest games ever. Load games off a CF card, loading times in a few seconds. Optional DSP1 chip for Mario Kart. Works on NTSC, PAL, clones, Super Famicom, basically anything I have tested.
Available now at
www.retrousb.com
Please tell me this will play the translate Star Ocean non S-DD1 hack.
You mean the 96Mbit version? ~25 secs to load but boots fine.
http://www.youtube.com/watch?v=Uy4SFfoT5LY
128 Mbit of SDRAM... That's amazing! Did you have to use donors for the lockout and DSP1 chips? It must be expensive to keep supply of DSP1 donors, so I can definitely understand the extra charge.
See, See, I'm not insane!!
Can't wait to try this out.
interesting, are any additional enhancement chips like the super fx chip for example planned and are they possible to implement?
Since there is no mention of it and the real DSP1 is installed manually I assume not, but I thought i would ask.
btw u thinkin about any N64 carts by chance?
I would like one and I would rather not buy from neoflash
bunnyboy wrote:
You mean the 96Mbit version? ~25 secs to load but boots fine.
http://www.youtube.com/watch?v=Uy4SFfoT5LYThe destruction of them will slow down greatly.
Enhancement chips are simply not happening. DSP/C4 can probably be quickly done with a PIC, but by the time you make the Super FX you are a significant way to doing the entire system. For the small number of games and the big increase in hardware it was a design decision early on not to do them.
bunnyboy wrote:
You mean the 96Mbit version? ~25 secs to load but boots fine.
Especially when you compare it to the loading time of a PlayStation 1 game.
This is good news. What I like this time is that I don't need any adapter to use on a super famicom. This could be an interesting option for snes programming in a near future since this is what I would have the most interest in such a device. For now, I will concentrate on my nes project.
Is it a coincidence that it just came out before the Christmas season?
Yes its coincidence, I was expecting to have them done much earlier than this. Chinese customs had a different idea...
Nice work. I guess my 96mbit repro board can wait a little longer. How big is the onboard sram? As far as the mappers as concerned, would I be able to write one that uses bankswitching so that I could take advantage of the full 128mbit if necessary?
bunnyboy wrote:
Enhancement chips are simply not happening.
By you or anyone? XC2S30 again?
This is amazing I didn't exept it to come so early !! Too bad I have only a crappy 16MB CF cart that don't work with the NES power pak, can't wait until I find a better one.
I am curious what is the CIC inside it ? Not that i really care as I have a CIC re-rooter I always use to play non-PAL SNES games, but I guess it wasn't reverse-engineered, was it ?
shadowkn55 wrote:
Nice work. I guess my 96mbit repro board can wait a little longer. How big is the onboard sram? As far as the mappers as concerned, would I be able to write one that uses bankswitching so that I could take advantage of the full 128mbit if necessary?
The SDRAM is 128Mbit, bankswitching should be possible to use the entire thing. There is no other SRAM chip on there.
Right now the mapper chops up the address range into 4Mbit sections which can be nothing/rom/ram. Block RAM is used for that so granularity could be much smaller. DSP and the 6000-7FFF SRAM are handled separately.
kyuusaku wrote:
bunnyboy wrote:
Enhancement chips are simply not happening.
By you or anyone? XC2S30 again?
I would bet by anyone with limited space and hardware multiplier. That is why some chips would be better in a PIC, and things like the FX are just out. Someone will eventually put them on a huge chip but not something affordable for general products.
Bregalad wrote:
I am curious what is the CIC inside it ? Not that i really care as I have a CIC re-rooter I always use to play non-PAL SNES games, but I guess it wasn't reverse-engineered, was it ?
Uses real CIC chip, no Super Ciclone yet
The CIC only matters for the console, not for the games, so you can play across regions (with the usual 50/60Hz problems).
Quote:
The CIC only matters for the console, not for the games, so you can play across regions
There are a few games that does a SW region check. I've never understood why since Nintendo themselves didn't do this, so it can't have been imposed by them.
Anyway, this is really cool. I'm getting a bit tired of my 64 Mbit SuperFlash cart with its LPT interface so I've placed an order for a SNES PowerPak.
Cool once I get money i'll surely buy this. Hopefully we wont have a resistor fix incident this time
Looks nice, and costs less than what my SF7 setup cost (main unit, extra ram, parts for building CD-ROM, replacement floppy drive, etc).
I'm a little disappointed at no prospect of SFX or SDD1 support (the SFX was developed on a FPGA btw according to Wikipedia) but I suppose we cant have everything...
There is one thing that confuses me a little, why the need to supply pre create BRAM files for saves? I can understand that the NES has little resources to deal with this sort of thing but the SNES, even after loading the largest game out there there should be enough RAM left over on the cart to hold some slightly more advanced filesystem code. Perhaps once you release the relevant sourcecode somebody else could do it? If simple microcontrollers can do it (RAM is tight there) then it should be possible for the SNES.
One last thing, good to see that the bootrom is socketed
Looks like the only carts I'l need now are Yoshi's Island, my Frankensteined StarFoxCompetition2 cart... and this one.
Expect to receive my order soon... once I figure out how rich I currently am. ^_^
PS. About DSP1 support, I have a donor cart but there arent any instructions on how to install it. I'm guessing that theres a socket on the pcb it'l solder straight into and does it get completely disabled for non DSP games?
Ah fuck it, now I have no desire to work on my own >: (
bunnyboy wrote:
I would bet by anyone with limited space and hardware multiplier. That is why some chips would be better in a PIC, and things like the FX are just out. Someone will eventually put them on a huge chip but not something affordable for general products.
Well what is the FPGA? XC2S15? Even that should be able to fit the PicoBlaze core (~40 MIPS).
cybertron wrote:
Ah fuck it, now I have no desire to work on my own >: (
Well I suppose not if it does everything you were aiming to do yourself. It certainly raises the bar from doing it at all to doing something superior. Sorry that bunnyboy beat you to it.
This was really a surprise so quickly after those pictures had been discovered. Can't wait to get one. I have a GDSF7 which I use with a laptop now but a single cartridge with massive CF card would be a much nicer setup.
cybertron wrote:
Ah fuck it, now I have no desire to work on my own >: (
Hey, don't sweat it. It seems that neither flash cart could have every little feature, and there could certainly be a place for yours, even with the SNES PowerPak available. Didn't the code for loading files off of the SD card also have code for live patching of ROMs? (Or am I thinking of a different project?) Anyway, that's currently something the PowerPak couldn't do.
Your cartridge could have its own focus within the SNES clique. After all, one who wants a development cartridge will be looking for different features than one who just wants to play games. There's still plenty of ground to cover.
kyuusaku wrote:
bunnyboy wrote:
I would bet by anyone with limited space and hardware multiplier. That is why some chips would be better in a PIC, and things like the FX are just out. Someone will eventually put them on a huge chip but not something affordable for general products.
Well what is the FPGA? XC2S15? Even that should be able to fit the PicoBlaze core (~40 MIPS).
Yup xc2s15. I don't know if software multiplier would be good enough for the 16x16+ needed, but certainly something to look into in the future. Chip is around 60% full depending what you look at so space may be an issue. FPGA config is on the CF card so it can be added later.
Hojo_Norem wrote:
There is one thing that confuses me a little, why the need to supply pre create BRAM files for saves? I can understand that the NES has little resources to deal with this sort of thing but the SNES, even after loading the largest game out there there should be enough RAM left over on the cart to hold some slightly more advanced filesystem code. Perhaps once you release the relevant sourcecode somebody else could do it? If simple microcontrollers can do it (RAM is tight there) then it should be possible for the SNES.
That is probably something I should add, but file name entry is also annoying. RAM and other resources aren't really an issue here, its just more of the FAT file system to deal with.
Hojo_Norem wrote:
PS. About DSP1 support, I have a donor cart but there arent any instructions on how to install it. I'm guessing that theres a socket on the pcb it'l solder straight into and does it get completely disabled for non DSP games?
Desolder from game board, solder onto SNES PowerPak board, done
naI wrote:
Your cartridge could have its own focus within the SNES clique. After all, one who wants a development cartridge will be looking for different features than one who just wants to play games. There's still plenty of ground to cover.
Just like I am still looking at the Quickdev16. Except for the curiously sloooow file loading it looks very good for developers. When it loads at SRAM speeds instead of flash speeds it will be very nice for homebrews.
MottZilla wrote:
This was really a surprise so quickly after those pictures had been discovered.
Those pictures were from the first proto board and had been posted since March
A few other people claimed to have seen them but didn't post. Was fun to swap out the picts, but damn Google was too slow to update cache or read the take down request!
bunnyboy wrote:
naI wrote:
Your cartridge could have its own focus within the SNES clique. After all, one who wants a development cartridge will be looking for different features than one who just wants to play games. There's still plenty of ground to cover.
Just like I am still looking at the Quickdev16. Except for the curiously sloooow file loading it looks very good for developers. When it loads at SRAM speeds instead of flash speeds it will be very nice for homebrews.
Did you try the new bootloader? It's supposed to be faster.
bunnyboy wrote:
So I had some old photos from March sitting around, and people happened to find them just a few days before it is all public
Hey Bunnyboy! Congrats on this new product!!! I can't wait to read some reviews on it.
Is there a limit on how big of a CF you can support? Also, about the FX1 chip, any hopes of getting support for it in the future?
Nah this one is way better then mine. Sexy red!
Leon,
bunnyboy wrote:
That is why some chips would be better in a PIC, and things like the FX are just out. Someone will eventually put them on a huge chip but not something affordable for general products.
So it sounds like no for Super FX, SA-1, but a "maybe" for simpler things like maybe Cx4. Having had a copier for such a long time, the lack of support for chip games other than DSP1 is really not a very big drawback.
bunny, as someone who has bought multiple flash carts and used lots of emulators, I recommend testing sram save/load behavior on large lorom games like "Ys III" and "Umihara Kawase". Most beginner SNES mapper detection schemes fail to accommodate their mapper types.
FitzRoy wrote:
bunny, as someone who has bought multiple flash carts and used lots of emulators, I recommend testing sram save/load behavior on large lorom games like "Ys III" and "Umihara Kawase". Most beginner SNES mapper detection schemes fail to accommodate their mapper types.
This man knows his games, and speaks the truth.
I just bought one SNES PowerPak with all of the upgrades (because I'm lazy). I have one question though. What version of the DSP1 chip are you using? Aren't there multiple versions? DSP1, DSP1a, and DSP1b?
Is the SNES power pak without CIC confirmed to work when using a CIC re-reouter, where you put a cart with the corect CIC for the CIC lines, and another cart for the game ? I remember having some trouble with the super gameboy using that adaptator, as well as some other games such as Donkey Kong Country (all of them works fine without the adapter - and thanks all my US and Jap carts works fine with it).
Looks like a great product. Must have been tough with having to redo all those prototypes, but I'm glad to see it worked out in the end, congrats.
While it's true that the Quickdev16 should be better for development (it's designed for it primarily), the SNES PowerPak will do decently in that department. When I was developing my SNES NSF Player, I was using a floppy disc for small tests and a CD-RW for the full 32Mbit test (yeah, that was easier than having 4 reliable floppies). It kind of sucked to swap media all the time, but I got through it by testing with ZSNES most of the time.
bunnyboy wrote:
Yup xc2s15. I don't know if software multiplier would be good enough for the 16x16+ needed, but certainly something to look into in the future. Chip is around 60% full depending what you look at so space may be an issue. FPGA config is on the CF card so it can be added later.
Shame on you for not choosing the XC2S100! ;) By my calculation it would have been able to pull off all chips! A pipelined 16x16 multiplier (fast enough for DSP) might still fit in the 2S15, but definitely not with a CPU core.
I think you should start on the first update right now and give another case color option :) (really dig the flashy pink Xmas cart!) I think the 2S100 might even be pin compatible... Call it SNES PowerPak XL or something, I'd totally be willing to pay for the larger FPGA so I can tinker with expansion hardware.
Looks like it would have to go up to the 208 pin XC2S200 because the 100 isn't really available. The XC2S50 is likely a drop in replacement.
Bregalad wrote:
Is the SNES power pak without CIC confirmed to work when using a CIC re-reouter, where you put a cart with the corect CIC for the CIC lines, and another cart for the game ?
If you mean a T-slot, none of the currently available ones have all the pins connected so it will not work. The 2 wings on the connector are needed for DMA. I haven't tried making a full connector so someone else will have to test it.
bunnyboy wrote:
:) Looks like it would have to go up to the 208 pin XC2S200 because the 100 isn't really available. The XC2S50 is likely a drop in replacement.
AVNet has a big supply in TQ144
Don't think the XC2S50 would fit SA-1 anyway.
Does the SNES PowerPak's FPGA have enough room left for the PicoBlaze core?
The xc2s15 has 192 slices (unless the info I found is incorrect). If those are what bunnyboy referred to when he said the chip is about 60% full, then you've got about 75 slices left. I don't know if PicoBlaze would fit in that - maybe it would.
This is pretty nice and I am glad this kind of thing is finally a reality. What is the largest CF card that can be used? I suppose I will just take the 2gb CF card out of my SWC DX2/Disk Dual
I ordered the SNES powerpak because I am slowly migrating towards flash carts (Neoflash PCE, Neoflash MD Myth Cart, Power Pak for NES), rather than console copiers (those will either be sold, or put on display). This totally makes the Tototek SNES carts obsolete.
Like another guy here said, as a guy who has used console copiers, I knew that special chips (FX, FX2, C3, C4, etc) weren't going to supported from launch, and all the special chip games I want, I already have the cartridges for.
I suppose N64 is next. Z64's are kind of hard to come by and are expensive.
bunnyboy wrote:
If you mean a T-slot, none of the currently available ones have all the pins connected so it will not work. The 2 wings on the connector are needed for DMA. I haven't tried making a full connector so someone else will have to test it.
My "universal" AD-29 adapter has all pins for slot A. In fact even SGB works trough it, but with ocasional graphical issues (may be due to dirty pins ?).
RGB_Gamer wrote:
This is pretty nice and I am glad this kind of thing is finally a reality. What is the largest CF card that can be used?
The largest card would be 2^28 sectors * 512 bytes, or 128GB, which doesn't exist yet
That is a limit of the CF spec I used at the time which may be old now. I have used 16GB regularly with both NES and SNES PowerPaks with no problems. That is ~11000 games.
mic_ wrote:
The xc2s15 has 192 slices (unless the info I found is incorrect). If those are what bunnyboy referred to when he said the chip is about 60% full, then you've got about 75 slices left. I don't know if PicoBlaze would fit in that - maybe it would.
It wouldn't, but then again, you don't need all the memory mapping stuff, just a simple address decoder and SDRAM controller.
kyuusaku wrote:
mic_ wrote:
The xc2s15 has 192 slices (unless the info I found is incorrect). If those are what bunnyboy referred to when he said the chip is about 60% full, then you've got about 75 slices left. I don't know if PicoBlaze would fit in that - maybe it would.
It wouldn't, but then again, you don't need all the memory mapping stuff, just a simple address decoder and SDRAM controller.
Even if support was added via the FPGA for only one additional DSP chip, it would be a first for SNES backup devices. Once support is added for a single DSP chip, the rest of the DSP chips would quickly follow.
Or maybe due to the addition distance of travel effecting the quality of the signal or something like that. I've noticed with my Action Replay MK3 trying to play my US Mega Man X2 and X3 carts on my Super Famicom has slight glitches every now and then (being every few seconds) but the game still runs. I first assumed it was dirty connectors but everything was very clean and further cleaning didn't help at all.
Just got mine in the mail, thanks.
I just caught that you can now load Game Genie codes from a txt file. That's so hot.
peppers wrote:
Yeah I'm in the US and had no issues with RetroZone.
Personally I plan on skipping this one as I can't justify the expense since work is slowing down but I would get a N64 version if it where to mysteriously appear some time in the future.....[/hint hint]
I wouldn't skip this version, as there are many better SNES games than N64 and I think just about anyone would agree with that. N64 really only had a small handful of games and for me, I can count all the N64 games that I like on one hand.
A quick question. Do you need the DSP1 chip to play Star Ocean 96mbit version? would be thankfull for answer.
acedo2 wrote:
A quick question. Do you need the DSP1 chip to play Star Ocean 96mbit version? would be thankfull for answer.
No
Ok thanks for quick reply.
Another thing. I have a NTSC Snes modded to be region free. Will a power pak with a NTSC Lockout chip work on it or do I have to order a power pak with no lockout chip?
^it will work with the lockout chip installed but you do not require the lockout if the internal lockout has been disabled.
RGB_Gamer wrote:
peppers wrote:
Yeah I'm in the US and had no issues with RetroZone.
Personally I plan on skipping this one as I can't justify the expense since work is slowing down but I would get a N64 version if it where to mysteriously appear some time in the future.....[/hint hint]
I wouldn't skip this version, as there are many better SNES games than N64 and I think just about anyone would agree with that. N64 really only had a small handful of games and for me, I can count all the N64 games that I like on one hand.
It would require more than one hand for me to count the n64 games I like, also n64 emulation is terrible where SNES is pretty dam near perfect also I'm growing accustomed to using higher quality filters with SNES so I'm starting to prefer the emulators .
cd_vision wrote:
I just caught that you can now load Game Genie codes from a txt file. That's so hot.
That was also added to the NES PowerPak, I got tired of entering in codes while testing
My only concern is that the only thing people seems excited about it is to try all their bootlegged game even though where on a dev forum.
A sad day indeed.
I want to try various SNES games but I also appreciate it as a method to test homebrew on a real console without resorting to EPROMs or another Copier. Obviously for many people the appeal is bootlegged games but it also will enable them to play any free homebrew that comes out or is already out.
Banshaku wrote:
My only concern is that the only thing people seems excited about it is to try all their bootlegged game even though where on a dev forum.
A sad day indeed.
Where? Here!
Without those horrible people whose only goal in life is to steal from Nintendo, this system wouldn't be available for homebrewers or reverse engineers. The sad day would be if any development hardware was cancelled because it could be used with illegal ROMs.
Banshaku wrote:
My only concern is that the only thing people seems excited about it is to try all their bootlegged game even though where on a dev forum.
A sad day indeed.
Why would you want this for dev at all?
Compiling, hooking up a CF card reader, copying it over, putting it in, and booting it, oh shit typo, start all over.
vs.
Compiling it, USB upload to QuickDev16 already plugged in, oh shit typo, just reset and resend the changed portion
PowerPaks (NES and SNES) can be good development tools, you just can't use them exclusively. It's perfectly fine to do most of the testing in emulators, but try on real hardware from time to time to make sure everything works and looks OK.
Maybe you can use it to play the extra difficult game in Earthbound that won't let you finish.
http://starmen.net/mother2/gameinfo/antipiracy/
Tokumaru is right on. While it certainly is nice if you can just quickly change, rebuild, and upload to test again with real hardware nowdays there are extremely accurate NES and SNES emulators available so you don't need to do real hardware tests that often that loading the file on a CF card will be such a problem. I have a GDSF7 which would allow uploading ROMs but it's still limited by parallel transfer speeds and more importantly the parallel port itself which my current PC lacks entirely. The QuickDev16 seems nice but face it, if I can get one device that lets me test and play homebrew as well as play all my other games I'll go for that and take the added hassle for quick cycle time testing.
I guess I'm quite tired these days because of work so this unusual comment from me came out. I need some rest I guess.
And yes, I would use it for dev, that would be my first reason for buying it. I'm no saint either so I'm sure I would try a game or two but this would not be my main reason of buying that device.
It just felt that people got more excited about the fact of playing their games on it than the dev aspect on the dev forum. This was my point I was trying to put emphasis on: where in the dev forum, not the general one.
Honestly, I do wish it would allow me to play Starfox 2 on real hardware. With that being said, this is pretty awesome. I'm glad to see this has finally be made.
I'm sure at least 90% of the PowerPaks bought are used for piracy, not dev'ing, sadly. But it seems that if it weren't for pirates these devices wouldn't exist, because there aren't many of us dev'ers out there and we're broken all the time.
I don't use my PowerPak for playing that often, I basically do that when friends want to play something I don't have in cart format, so I quickly put it in the PP. I have a few games in it, but I can't seem to play any of them longer than 10 minutes. Then again, I don't play my regular carts that much either, I guess I do most of my playing on emulators. I'm a sucky player, so I kinda rely on save states too much I guess.
I really want to do SNES-dev.
The problem is that I wanted to have already a couple of NES games out by now when I start SNES-dev, but making a full game is hard.
Maybe I'll start developping for the SNES soon I don't know.
I'll be ordering soon but bunnyboy could you answer this, is the SNES Powerpak hardware final? There's talk of 'PicoCore' this and 'if you used this pin-compatible version' that.
Also, what version of the DPS1 is best to install for best compatibility?
Hojo_Norem wrote:
I'll be ordering soon but bunnyboy could you answer this, is the SNES Powerpak hardware final? There's talk of 'PicoCore' this and 'if you used this pin-compatible version' that.
I currently have no plans to change any of the hardware, unless a major unknown bug is found. Of course that could change quickly but prototyping boards is expensive! The Pico stuff is all configurable in the FPGA. Anyone who wants a bigger FPGA can swap it themselves
Hojo_Norem wrote:
Also, what version of the DPS1 is best to install for best compatibility?
From what I have seen, nobody knows. Only seen brief mentions of bug fixes in the 1A/1B without details. Hopefully someone will use this product to check out any differences.
Bregalad wrote:
I really want to do SNES-dev.
I don't have any desire to do any SNES dev'ing. If I do eventually get this PP it would be for gaming only. For dev'ing I'm much more interested in the 2600 and the SMS... I guess I like to work with 8-bit systems better.
I'm the opposite Tokumaru. While I enjoy gaming on the 8bit NES, I can't really see myself developing much of anything for it when SNES seems like a much better option. Ofcourse that's because I think it's an easier system to work with than NES or atleast easier because of extra capability.
Yeah extra processing power, many BG layers and almost limitless sprites, mode 7 and automatic HDMA so that you don't need raster code are all exiting features. The fact to have a separate, VERY powerfull (for year 1990) SPU is an overkill.
Since it was off-topic and getting quite extensive, I moved the customer complaint portion of the thread to here:
http://nesdev.com/bbs/viewtopic.php?t=5734
So I got an email from RetroZone that the SNES PowerPak orders are being put on hold due to a compatibility issue that was found before shipping out most of the PowerPaks. Does anybody know what the issue is?
Jagasian wrote:
So I got an email from RetroZone that the SNES PowerPak orders are being put on hold due to a compatibility issue that was found before shipping out most of the PowerPaks. Does anybody know what the issue is?
I saw a mention about there being problems with certain revisions of the SNES PPU. In that case, it's likely to be fixable in software. If it's the bootrom, it might not be a "user serviceable" part. But you can consider this a rumor and speculation, because I don't know for sure.
I got mine yesterday and it basically doesn't work at all. All I get is a blank screen for any ROM I try. LOROM/HIROM or header properties do not matter. It's a cpu ver2 / ppu1 ver1 / ppu2 ver3 PAL unit.
I mailed bunnyboy about it but he doesn't react. Unless there is a software
fix soon I want to return the powerpak and get my money back. I understand hardware differences might be difficult, but since I paid quite some cash on this one I quite honestly don't care.
I saw over on the DP website that one user had a problem with the CF card that was sent with the PP. Have you tried a different card?
Any news of how soon the SNES PowerPak will become available again? I would definitely like to see about purchasing one when it is available again. No rush on getting the hardware/software issue resolved, but I would like to know when they're on the market again.
I tested mine on 3 systems:
SNES v1 (CPU v2, PPU1 v1, PPU2 v3): Word Great!
SNES v2 (CPU v2, PPU1 v1, PPU2 v3): Boots, Claims SDRAM Error, DSP1 Not Installed (but it is)
SFC v1 (CPU v1, PPU1 v1, PPU1 v1): Black Screen
Hopefully the issue can be resolved. Think maybe its power related and different SNES revisions just draw slightly different amounts of power or something? Just a thought since most copiers have a separate PSU.
I have two Snes (one very first 1990 SFC, and one 1992 pal Snes ).
I'm wondering if the snes powerpak (I have choosed a NTSC cic version) can work on my pal snes with my AD29 adapter? (this adapter have the extra expansion pins) or will the powerpak draw too much current?
For now my order is on hold like certainly many others, no problem, I can wait.
MatthewCallis wrote:
SNES v1 (CPU v2, PPU1 v1, PPU2 v3): Word Great!
Of course this is the system I tested with, and emulators pretend to be. If only everyone had it
MatthewCallis wrote:
SNES v2 (CPU v2, PPU1 v1, PPU2 v3): Boots, Claims SDRAM Error, DSP1 Not Installed (but it is)
This is next on the list to be checked out. There is some hardware diff that is either stopping FPGA config or messing up the clock signal. For now it will likely be put on the incompatible list with hopes of a software fix in the future.
MatthewCallis wrote:
SFC v1 (CPU v1, PPU1 v1, PPU1 v1): Black Screen
This is what I was working on full time all week. There is some unknown difference in DMA behavior which causes the system to reset. I can very easily write code that runs on all emulators, all clones, and all systems with PPU2 v3, but fails horribly on PPU2 v1. HDMA is off (420c=0), NMI is off (4200=0), but a 1 byte or 1 cycle difference in a constantly running DMA loop will make it crash. For now the fix is to not use DMA through the boot process, then switch it on if PPU2=v3 from the CF files so that part can be changed later.
Phew... Scary!
Is there a way to check which category my SNES (PAL) fits into without opening it?
Press select + start in the menu of Final Fantasy Mystic Quest.
Is there any place that lists the differences and variants for the snes models? I want to try to get them (at least the more available ones) for development and testing purposes.
As far as I can tell, nobody knows any of the differences. There is only a mention of DMA and HDMA colliding on some versions of some chips. However I have HDMA off and there is still something weird happening.
There are also no case markings to tell which chips are inside. A lower serial number (8 numbers instead of 9) may be a way to tell if it is early revs, but still not exactly which ones. Either need to open it up, or have a game that reports the versions.
Bregalad wrote:
Press select + start in the menu of Final Fantasy Mystic Quest.
I seem to remember a CPU and PPU revision number display in The Lion King: press B A R R Y in one of the menus.
You are correct, in the options menu on Lion King pressing B A R R Y reveals a secret menu which lists CPU, PPU1, PPU2 versions. So that's two games that can tell you your chip revision, but didn't someone say that the overall SNES revisions can have the same chip revisions? Or was that a typo as no one ever answered that.
Never mind the games, I have neither of those.
I opened up my SNES and would like to know if the following information means that my control deck is what has been called "SNES v1 (CPU v2, PPU1 v1, PPU2 v3)" here - it seems to me it is, if I am to judge from the 02, 01, 03 in each of the middle lines. This is written on three chips on the board:
S-CPU A
5A22-02
2JF 72
S-PPU1
5C77-01
2JU 7P
S-PPU2 B
5C78-03
2JA 91
I'm guessing it's v1 from the fact it has an 8-digit serial number (apart from the first two letters, US).
Hot or cold?
Please excuse my n00bness.
Yeah, you have a 2/1/3 model. It is immune to the HDMA crashing bug.
I really can't say what causes your error, but I'd bet it has more to do with the CPU revision than the PPU2 revision. I've spotted a lot of timing differences (mostly to fix the HDMA bug) between the two CPU revisions, but I've never seen any PPU changes. They're there, of course. I just can't spot them yet.
The problem is it fails on 1/1/1 (SFC) and 2/1/1 (SNES), but works on 2/1/3 (SNES). I see that as something with the PPU2 being a problem, but honestly have absolutely no idea.
Could you de-solderer the ppu and swap it with the differint version, that might help identify where the issue is?? whether its in the cpu or ppu
Bunnyboy,
I tried using an 8gb compact flash card, formatted to FAT32, but the PowerPak gives me a format error, asking me to format to FAT16 or FAT32. Any ideas?
Also, as far as save files, can you somehow convert save files from emulators to work on the SNES PowerPak? Or perhaps game copier saves (Game doctor uses .B01, Super Wild Card uses .BBD)?
thanks!
You should be able to convert the saves from Game Doctor or Super Wild Card to work the the SNES PowerPak using ucon64. Also, if I remember correctly, I think that emulator saves will work without modification with the SNES PowerPak. I just ordered a SNES PowerPak yesterday so I will confirm my suggestions once it arrives. I have a GDSF7 that I can try converting saves to work with the SNES PowerPak as well.
pcmantinker wrote:
You should be able to convert the saves from Game Doctor or Super Wild Card to work the the SNES PowerPak using ucon64. Also, if I remember correctly, I think that emulator saves will work without modification with the SNES PowerPak. I just ordered a SNES PowerPak yesterday so I will confirm my suggestions once it arrives. I have a GDSF7 that I can try converting saves to work with the SNES PowerPak as well.
Sweet. Ucon64 doesn't seem to have an option to convert saves from a game copier to something else - only from something else to a game copier type save.
As far as emulator saves (like .srm), could I just rename it to .sav and it should work on the PowerPak?
They should. All the save files should be is the actual save data on the chip. Same thing with copiers except that the save file usually is of the whole SRAM chip and not just what the game was using. So you may need to trim it down to the game's proper size. The only thing to remember is you can't use "Save States". But regular game save files you can use.
MottZilla wrote:
They should. All the save files should be is the actual save data on the chip. Same thing with copiers except that the save file usually is of the whole SRAM chip and not just what the game was using. So you may need to trim it down to the game's proper size. The only thing to remember is you can't use "Save States". But regular game save files you can use.
How would I convert my game copier (Game Doctor SF7/ Super Wild Card DX2) saves to work on the PowerPak?
sorry, I am not very savvy with such things.
kyuusaku wrote:
Rename.
Super Wildcard DX2 is another animal. For some reason, when I try to copy the save files (.BBD), it errors every time.
What errors? How large are these BBD files? typical SRAM sizes for SNES games are 2 Kbytes and 8 Kbytes. Some games do have larger but it's fairly uncommon.
MottZilla wrote:
What errors? How large are these BBD files? typical SRAM sizes for SNES games are 2 Kbytes and 8 Kbytes. Some games do have larger but it's fairly uncommon.
The BBD files are 33kb each. Weird because I usually get errors when I try to copy them to my PC, but today I actually got to copy them to my PC. I just wanna convert them to .sav for use on my PowerPak
It might just be a matter of chopping off the first and last n bytes. But to help us determine n, can you make a save for, say, Mario Paint in both bbd and srm formats?
tepples wrote:
It might just be a matter of chopping off the first and last n bytes. But to help us determine n, can you make a save for, say, Mario Paint in both bbd and srm formats?
i will do it for Equinox, which is one of the games that need the saves converted
ucon64 -stp whatever.whatever
[quote="kyuusaku"]ucon64 -stp whatever.whatever[/quote
so for equinox.bbd the command would be:
ucon64 -stp equinox.bbd equinox.sav
Any other ideas on how to get copier SRAM saves to work on the PowerPak?
I have several games that I am deep into (Equinox, Secret of Evermore, Seiken Densetsu 3, Zelda 3, Terranigma), that I don't want to have to replay.
There isn't another idea, either the copier save has a header or it doesn't.
You could upload the copier save and link it. By looking at the file we can probably tell you what needs to be done.
MottZilla wrote:
You could upload the copier save and link it. By looking at the file we can probably tell you what needs to be done.
http://rapidshare.com/files/312660946/EQUINOX.BBD.html
thanks!
I got your save working in bsnes by ignoring the first 512 bytes, copying the following 8KB (8192 bytes) to another file and ignoring the rest. You can use an hex editor for this.
Download it and see if it works.
tokumaru wrote:
I got your save working in bsnes by ignoring the first 512 bytes, copying the following 8KB (8192 bytes) to another file and ignoring the rest. You can use an hex editor for this.
Download it and see if it works.
thank you!
how about this one:
http://rapidshare.com/files/312669576/TERANIG.BBD.html
this is for Terranigma, which is the one I am most concerned about. I will test later tonight .
If what I did really worked, and if the format is the same, just do what I said above. Open it in an hex editor, delete the fist 512 bytes. Keep the next 8192 bytes and delete anything after that, then save to a new file and you should be done.
Here it says at retroUSB
The Lockout option specifies which regional lockout chip is included. Clones do not have a lockout chip, so none is needed in the cart. Systems with the lockout disabled also do not need it. All other authentic Nintendo systems will either need the NTSC or the PAL chip. The lockout must match your console, not your games.
I have a Pal console that has a 60hz switch & a lockout switch.
( Also an awesome SNES/SFC collection
)
I want to play only USA & JAP games on the Snes powerpak.
Hacked SNES games are also NTSC 60hz optimized.
Shall I choose PAL, NTSC, or NONE lockout chip.
The compability seems to suck at the moment, & seems to need more HARDWARE chip´s added.
Here they say:
Lifetime boot rom updates - mail the cart here, we update then mail back free.
We need more chip´s & not just bootrom updates?
Am I right?
Maybe smarter to wait for an updated version to be able to play more games??
Cheers
tokumaru wrote:
If what I did really worked, and if the format is the same, just do what I said above. Open it in an hex editor, delete the fist 512 bytes. Keep the next 8192 bytes and delete anything after that, then save to a new file and you should be done.
What hex editor did you use and how do you delete/keep bytes?
RGB_Gamer wrote:
What hex editor did you use
This is a good free one.
Quote:
and how do you delete/keep bytes?
Open your file. Resize the window so that the number of visible columns is a power of 2 (16 or 32, for example), this will make finding the offsets easier, since they are also powers of 2 (512, 8192).
Then click on the first byte, go to Edit -> Block <n> chars. This will select as many bytes as you specify, starting from the one you clicked. Ask for 512 decimal or 200 hex, they are the same. Then go to Edit -> Block delete. OK, the first 512 bytes are gone.
Now scroll down until the end of the data you want to keep, 8192 bytes later. Since 8192 in hex is 2000, scroll down until you see 2000 on the left (gray) column. Click on the byte to the right of the 2000 and go to Edit -> Block mark to start the block. Scroll down to the end, click on the last byte of the file and go to Edit -> Block mark again to mark the end of the block. Delete this block and all that's left is the data you want. Save it with a new name.
Make sure that the final file is exactly 8192 bytes in size, if it's not you have done something wrong.
Maybe its best to get one with lockout disabled because my console has a lockout switch.
If I buy one with NTSC, would it affect some games to not boot when my console has a disabled region chip?
tokumaru,
thanks for the tip. Works great!
Taxititan wrote:
Here it says at retroUSB
The Lockout option specifies which regional lockout chip is included. Clones do not have a lockout chip, so none is needed in the cart. Systems with the lockout disabled also do not need it. All other authentic Nintendo systems will either need the NTSC or the PAL chip. The lockout must match your console, not your games.
I have a Pal console that has a 60hz switch & a lockout switch.
( Also an awesome SNES/SFC collection
)
I want to play only USA & JAP games on the Snes powerpak.
Hacked SNES games are also NTSC 60hz optimized.
Shall I choose PAL, NTSC, or NONE lockout chip.
Does your switch just disable the lockout or switch it with a NTSC lockout chip? I assume it just disables the PAL lockout and lets any cartridge run. In this case you do not need a NTSC or PAL lockout chip in your PowerPAK. So if this is true choose NONE. To make it simple, if when you put the switch in the position to play NTSC cartridges you can still play PAL carts without changing that switch, then that means pick NONE for the PowerPAK.
To Convert SWC Saves to SRM:
http://www.romhacking.net/utils/368/
What adapter do I want to use to flash the BIOS? I haven't take the cart apart and won't be back to it for a while but I want to go ahead and order it. I have a True-USB Willem programmer,
http://www.mcumall.com/comersus/store/c ... oduct=4219
My SNES PowerPak just arrived today in the mail and I am waiting until I return to school to test it. I was getting stuff ready to copy over to my compact flash card and it appears as though the latest SNES PowerPak bootrom isn't available for download. The link exists, but it just redirects to the main page.
http://www.retrousb.com/downloads/snesp ... oot102.zip
I could get version 1.01, but I am unsure of whether that was the revision of the bootrom that had problems with compatibility. I'm not sure what version my SNES PowerPak shipped with however. It could be the newest one since it was shipped out on the 24th. I will report more information tomorrow after doing some initial testing. Also, will I need to flash the bootrom with an eprom programmer? Or is there a flashing utility built into the cart?
Mine shipped with 1.01 already on there. I waited extra long to receive mine after I ordered it. I am assuming the latest version is on mine because of the bugs in earlier versions
Good to hear about yours shipping with 1.01. Depending on when 1.02 was released, my cart may have that flashed into the BIOS already. I will post the version number tomorrow.
All carts ship with whatever the latest boot rom is that day. If you are using it fine then you shouldn't need any of the boot changes that are being implemented. Right now it is only to try to get more CF cards working. All the files on website should be up to date now.
bunnyboy wrote:
All carts ship with whatever the latest boot rom is that day. If you are using it fine then you shouldn't need any of the boot changes that are being implemented. Right now it is only to try to get more CF cards working. All the files on website should be up to date now.
I was really disapointed when my CF to SD card adapter didn't fit in the Power Pak. Oh well, can't have everything. Still a great product, especially now that I converted my old game copier saves to work on the Power Pak.
Bunnyboy,
I really hope you are going to continue the line of Power Paks. Please consider one for the Gameboy/Gameboy color. I have a Bung Xchanger but 64mb for a cart is too small.
When I boot the card, it says I have 1.02. However, I get a DSP1 not installed message and an SDRAM error message. I read that this could be caused by my system configuration, but it could also be from an incompatible compact flash card. I have a Sandisk Ultra II 2.0GB compact flash card, but I'd be willing to test one more card if that will help fix it. Also, I am using Windows 7 format utility to format the card. What is the best format to go with? FAT16 or FAT32? And what cluster size? Or should I get another tool?
If you have an SNES mini, then that is the problem. Still not sure what is wrong with that system, may just not like the lower voltage inputs.
Next thing to try is setting DMA=0 in the CONFIG.TXT file in the POWERPAK directory. Some cards can't handle the faster access time of the DMA mode, so it will get errors.
And finally try another card. The formatting is not likely to be the problem if you are getting that far in the boot process.
I would just make things easier and just get a full sized SNES. Problem solved
I have a full size SNES that was bundled with Super Mario World when brand new. I'm pretty sure that it's not my SNES, but rather my compact flash card. What compact flash card would you recommend getting? I probably should have just ordered a compact flash card with the PowerPak, but oh well.
I've had the SNES Powerpak for a few days now, and most things so far are pretty good. One thing that is odd, is that the 2GB DANE-ELEC card that I got with the Powerpak doesn't work correctly with it.
When using the 2GB card, I get sporadic rom load failures, and when scrolling the rom lists there is visible corruption that begins to happen in the text of the rom names. When using a Sandisk UltraII 8GB card, neither of these things happen.
Also for some reason, Test Drive II refuses to load, though the rom seems to be correct. The Powerpak says 'ExLoROM 8Mbit unsupported' at the end of the message dump.
Boot and Card ROM v1.02, DSP1 installed / Original large SNES
nsrt scan of Test Drive II
Internal ROM Info
File
Test Drive II - The Duel (U) (24291).smc
Revision
1.0
Checksum
Good 0x5EE3
Game Code
Hashes
CRC32
BA093E24
MD5
EF76F860CD8709DAF99A60E9DAC8D2BE
Ok, so I got a new Sandisk Extreme III 4GB 30MB/s card but I get a different error when trying to boot. It says
Error CF sectors left = 01
Error $01 - CF card error
remowilliams wrote:
Also for some reason, Test Drive II refuses to load, though the rom seems to be correct. The Powerpak says 'ExLoROM 8Mbit unsupported' at the end of the message dump.
Boot and Card ROM v1.02, DSP1 installed / Original large SNES
nsrt scan of Test Drive II
Internal ROM Info
File
Test Drive II - The Duel (U) (24291).smc
Revision
1.0
Checksum
Good 0x5EE3
Game Code
Hashes
CRC32
BA093E24
MD5
EF76F860CD8709DAF99A60E9DAC8D2BE
I get the same problem in either of my SNESes with either this ROM or Test Drive II - The Duel (U) (20429).smc. Also, Pilotwings (U) [!].smc refuses to get past the loading screen, even though I have a DSP1 installed.
I think that Pilot Wings is a known problem game for DSP1 games. You might want to look for alternate versions of it.
i have 2 questions THANKS FOR ANSWER
i read on another forum that Star Ocean save dont work with the Snes powerpak . Can someone confirm that ? i really want to play this game.
2. my snes version is v2 - v1 - v1 . Will it work with the snes powerpak. its a NTSC system. i found my version with help of final fantasy mystic quest
I don't know about Star Ocean but I believe the recent fix to the PowerPAK solved it not working on older systems. You could always email RetroZone asking if your specific version works.
Bunnyboy
I have the Star Ocean rom that is compatible with the powerpak. i can play it and all, but when i go to save and hold hte reset button 5 seconds it doesn't give me the save ram option, it just resets the game.
Any idea if it is a compatability issue or a rom issue?
hey bunnyboy, thanks for the great product and quickly responding to my emails.
I've got an interesting issue. I've got two SNES consoles (neither is a SNES mini). One of them will detect the DSP1 chip and the other will not.
1) DSP1 installed console
- 2-1-3 console
- printed text eject button
- mode 7 games work fine
- Sticker below power button is English and says "USA"
2) DSP1 not installed console
- 2-1-3 console
- molded text eject button
- mode 7 games do not work, displays error screen
- Sticker below power button is English and French and says "CANADA"
Weird eh?
Here's my rudimentary way of tell revisions 2/1/2 and 2/1/3 from the outside, from observing ones I have.
2/1/2 - Printed Eject on button, cartridge locks in place when switching power on, base has 4 rubber "feet," console is noticeably heavier, FCC ID on base is silver sticker, probably yellowed by now!
2/1/3 - Molded eject button, cartridge doesn't lock in, bases has 2 rubber feet, lighter weight, FCC ID on base molded in, probably still grey.
The SNES I've been using so far is v1 (CPU v2, PPU1 v1, PPU2 v3)
It's got printed Eject on the lever, cartridge doesn't lock in, base has 2 rubber feet, FCC ID on base molded in.
my snes is 2/1/1 (tested with FFMQ) printed Eject. FCC ID IS silver and theres a silver sticker with this:
Super Nes control Deck
Model No. SNS-001
Rating: DCv10 850ma
use with adapter no. SNS-002 ONLY
Made in Japan
SNS - USA
Im from Canada. But i think this snes has been bought in USA some years ago. but im not 100% sure.
I will have my SNES powerpak soon to test it
anybody know if this version is working ?
retrozone answered me about my star ocean saving question. this is the answer:
The battery information is pulled from the internal game header of the ROM, so if the save question does not appear it is a problem with the ROM. The header info can be seen in the LOG.TXT file after the game loads.
so what do you think?
anyway i will test my rom as soon as i get my snes powerpak
I figured out the save issue with the 96mbit version of star ocean. It seems like the powerpak reads the rom's internal header instead of the gd3 header for sram mapping. If you open up the file in a hex editor and change the following values, saving will work properly. I have a patch made up for it but I don't know how to attach it. If someone is willing to host it, I can send it to them.
0081D5: 32->31h
0081D6: 45->02h
A081D5: 32->31h
A081D6: 45->02h
The GD3 header is not used for battery info because it does not contain any battery info
In general none of the added headers are used and the internal game info is trusted. Of course that will be incorrect for some games...
It only seems to be a problem for this game in particular so it's not a big deal. I have a deinterleaved version of the game when I was doing some work on a 96mbit repro cart. How would I go about adding support for it? I don't mind doing the coding myself so long as I have the tools to do so.
Many translated games that were expanded do not change the internal game information which the Game Doctor SF series can be affected by too. For example Final Fantasy IV was expanded from 8 Mbits to 12 Mbits but the internal info was not changed to reflect this and my GDSF made the game unable to read beyond the 8MB mark causing problems. Sounds like PowerPAK will have that issue too. The only people not effected are emulator and EPROM players.
can you send me the star ocean patch to
renejr902@hotmail.com
thanks
Dont tell me that final fantasy IV translated in english will not work.
ITS THE FIRST GAME i want to play with my snes powerpak. i always want to play the ffiv in hard difficulty mode. FFII us was the easy version.
Can someone make some code changing for it ?? THANKS
renejr902 wrote:
FFII us was the easy version.
Well, not exactly; there's more to it than that. It was easier, however.
http://finalfantasy.wikia.com/wiki/Fina ... ifferences
EDIT:
Take a look at this:
http://www.romhacking.net/hacks/419/
i played it with the emulator. and FFIV ( HARD TYPE) IS MUCH DIFFICULT than FFII US.
i finished the game with the emulator but i want to play it again with the real hardware.
You CANT compare these 2 games. FFii is a lot too easy. believe me the difference in difficulty is really big.
( your link is about ffiv easy type vs ffiiUS. not FFIV Hard type vs FFIIus)
Quote:
i read that on a forum: Many translated games that were expanded do not change the internal game information which the Game Doctor SF series can be affected by too. For example Final Fantasy IV was expanded from 8 Mbits to 12 Mbits but the internal info was not changed to reflect this and my GDSF made the game unable to read beyond the 8MB mark causing problems. Sounds like PowerPAK will have that issue too. The only people not effected are emulator and EPROM players.
Can i modify the final fantasy iv rom with ucon64 or other program to change the rom information to 12mbit ? anybody know ? its the first game i want to play with my snes powerpak. i always want to play the ffiv HARD type in english thanks for help
In a headered rom open it with a hex editor and goto file offset $81D7. It should have the value 0A. Change it to 0B. That's all.
thanks A LOT for answer. i think i will love you !!!
i will do it. how can i be 100% sure my rom have a header. with which program i can verify that.
But i just donwloaded this: Checksum Recalculator Bongo` Tool to recalculate and update checksums in SNES ROMs. Useful if you want your translation or hack to show a “good” checksum after the ROM has been successfully patched.
Is this tool will do the job ? because he found a checksum error in ffiv translated rom and it fixed it ?
thanks for the 2 answers
maybe i do it right but with hex editor i got 5a value and not 0a
i tried to patch star ocean with this:
0081D5: 32->31h
0081D6: 45->02h
A081D5: 32->31h
A081D6: 45->02h
but how can i change 32 for 31h. i cant put more than 31. theres only 2 spaces. what i do with the '' h ''
thanks again
The lower case h notes that the value preceeding it was Hexidecimal. You don't need to type in the h.
my ff4 rom version was not good. i succeed to patch ffiv with 0b with another rom. i even verify the rom to be sure. now rom size is 12/16mbit instead of 8mbit
thanks a lot, i love you LOL
the ff4 rom detect 12/16mbit correctly now, but is it necessary to correct the checksum automatically with a utility to get it working on Snes powerpak, because the checksum fail when i load it in zsnes, but the rom work properly.
thanks for answer
MottZilla wrote:
The lower case h notes that the value preceeding it was Hexidecimal. You don't need to type in the h.
so i change 32 for 31 without the h ? right ? so i ignore the h right ?
i made the 4 correction.
do you know any other Snes Rpg that need patching the rom size in header ?
MottZilla wrote:
Many translated games that were expanded do not change the internal game information which the Game Doctor SF series can be affected by too. For example Final Fantasy IV was expanded from 8 Mbits to 12 Mbits but the internal info was not changed to reflect this and my GDSF made the game unable to read beyond the 8MB mark causing problems. Sounds like PowerPAK will have that issue too. The only people not effected are emulator and EPROM players.
No headers are trusted for game size, that is calculated from the file size during loading. Internal headers and most (all?) copier headers specify the size in powers of 2 Mbits which fails for sizes like 20/24/28Mbits. By segmenting the address space into 4Mbit blocks the mirroring should be correct for all those. Of course the file could always be the wrong size from over/bad dump...
Well then my problem was more likely related to the conversion software generating the GD3 header. Perhaps it was using the imbedded info to generate the header which contains a memory map.
so bunnyboy, its not necessary to change rom size in header for the snes powerpak ? im confuse
Well, I received my powerpak yesterday, I'll try it tomorow.
But I'm actually wondering something:
-Does the powerpak is compatible with microdrive? (I have two 2.5GB one).
WOW WOW !!!
i receive my Snes Powerpak today. ALL IS WORKING PERFECT. my snes console is a NTSC (USA/CANADA) v2, v1, v1 , with printed eject. my snes powerpak has dsp1 installed correctly. version 1.02. my TV is a CRT Proscan 27''
The compact Dane-elec 2gb that is include with the snes powerpak work at full speed. no problem at all. buy your CF card from Retrozone if you dont want to find a compatible one.
Some facts:
- ALL my roms are working until now except for one game (asterix see below)
- Star Ocean save is working after i patched the rom with this:
0081D5: 32->31h
0081D6: 45->02h
A081D5: 32->31h
A081D6: 45->02h
- Final fantasy IV Hard type with english translation Work perfect.
- Seiken detstsu 3 in english work perfect.
- EUROPEAN ROMS WORK AT NORMAL SPEED !!! people that said that (E) roms on a ntsc system will run faster than normal ARE WRONG. at least for the games i tried. Jellyboy (E) and a few others european games run at Normal speed.
Problems so far. ( only one LOL):
- i convert Asterix & Obelix (E) to NTSC system with ucon64 with parameter -f, because when the game is started, it said in the tv screen that i need a pal system to play it. even after patching the rom it said the same thing. so its seem ucon64 is unable to remove the Asterix & obelix pal protection.
If your rom has no pal checking , your rom will work perfectly at NORMAL speed. but if its asking for pal system, you have to remove the pal checking with ucon64. but it doesnt work for me.
Any ideas for Asterix & Obelix ?? THANKS FOR ANSWER
I HIGHLY RECOMMEND THE SNES POWERPAK TO ANYONE THAT LOVE SNES GAMES. CONGRATULATION BUNNYBOY and RETROZONE , this thing is a DREAM COME TRUE FOR ME. It will help me to change my mind and forget my life problems. ITS REALLY FUN TO PLAY WITH IT. ALL games runs exactly like the original game. i cant play emualtors anymore. LOL
The BUILD QUALITY IS AWESOME. GREAT QUALITY PRODUCT. BUY IT SOON, you cant live with it LOL
(E) roms will run faster on a NTSC system than a PAL system. However since many PAL (E) releases are nothing but the NTSC version slightly changed for release in another region when played on a NTSC system it plays at "normal speed". However if you found a PAL (E) game that was adjusted for speed to run about the same speed of action as it did in the NTSC release, when you play that PAL (E) rom on a NTSC version it will run faster than normal. So it depends on the game. Not every (E) game will work properly on your NTSC system. Many will, but not all.
For Asterix & Obelix:
Goto $E70A. Change values to EA EA. The game will now run on a NTSC console.
i tested several others roms.
ALL my (E) roms have been patched with ucon64 -f, But unfortunately, only a few of them will remove the PAL protection.
THIS is my favorite pal roms list in order of importance of games that dont work on a NTSC system even after trying to remove the PAl protection: IF YOU CAN GIVE ME THE HEX CODE TO CHANGE FOR SOME OF THEM I WOULD BE VERY HAPPY , only if you have time, THANKS:
1. Lucky Luke
2. Tintin au Tibet
3. Adventure of Tintin
4. Spirou
OTHERS PROBLEMS:
- BS ZELDA DONT WORK, and i have 4 different versions. and i have one version made for the real hardware.
- BS F-ZERO 2 DONT WORK
- Final Fantasy II ( translated in French) only show 2 lines in each paragraph, so its not possible to understand the text. Its bad because my wife dont speak english and she want to play it. Dont worry the english translation of final fantasy IV work perfectly.
- Mystick ARK (7th saga 2) i have 2 roms with a different english patch. anyway the 2 patchs are 100% translated in english. But one of them will SHOW NO TEXT. the other work perfectly.
- Pilot Wings dont work correctly
- all A&S nes hack dont work. ex: mappy, pinball, pooyan
- I TRIED TO TEST ALL SNES RPG : USA AND JAPAN AND EURO AND ALL ENGLISH TRANSLATED, ALL OF THEM WORK PERFECTLY, except for what i wrote before.
- star ocean need a patch for saving. works perfect with the patch
- terranigma need a patch for working. works perfect with the patch
- all others rpg work without a patch.
THANKS FOR HELP, if you can help me with one of my problem i will appreciate it. But at least, all my favaorites games are working. im happy.
i tried more than 300-400 roms. no more problems so far.
i cant get Super adventure island to work.
The Japanese and EURO version are working correctly.
the (U) version doesnt start. i tried several (U) roms.
It's likely those translations are from people not testing their hacked code properly. I haven't tried those ones you mentioned, but I do remember occasionally running into fan translation glitches on my Game Doctor SF7. Mostly on hacked-in intro screens and such.
Those A&S NES hacks should work though, they played just fine on the GDSF7. Maybe PPak doesn't like the small ROM size.
If someone could find a way to get any one of the versions of BS ZELDA working that would be AMAZING!
I can't be the only one wanting a fix for this...
Quote:
YS IV ( english translation) YOU CANT SEE ANY TEXT
i patch it myself, and it works now
i have a old final fantasy iv rom with a OLD j2e english translation patch without modified battle menu format. so i want to play with this old patched rom. but the snes powerpak dont work with it.
but my rom work in zsnes, snes9x, my snes psp emulator...
So What can i do to get my rom working on the Snes powerpak.
i tried to repair the header. i tried to remove the header and add another one. i tried repair the checksum. i dont have any more idea. thanks for help.
(note: i cant find old j2e english patchs versions for final fantasy iv. my patch is older than v 3.03 because even the 3.03 version has modified battle menu)
Finally i tried all snes games that i have played since my 10 years old
( i have 30 years old )
and i didnt find any other games that do not work. ( more than 300-400 roms tested, you can ask me if a particular game is working correclty)
So i can enjoy All my favorites games on real hardware. Finally i like the final fantasy iv large battle menu and the last translation patch.
So all my problems have been resolved
THANKS ALL.
The snes powerpak really worth it.
i have to go because i have to play final fantasy iv, star ocean, seiken 3 and final fantasy V. and all my favorites platform and racing games games: megaman x, castlevania series, mario series, asterix and obelix, Tintin, jellyboy, smurfs, mariokart, f-zero...
i have 116 nes and snes original games. But i never have been able to play most of my favorite games on real hardware ( euro and japan snes games ). That awesome.
I will be very BUSY. LOL !!!
(note: only F-zero 2, bs zelda and all versions of pilot wings dont work, if someone find a way to get one of these games working correctly dont hesitate to tell me)
Have a nice week !!! AND THANKS A MILLION TIME FOR YOUR HELP MottZilla. Without this guy a lot of my favorites games wont be working.
THANKS TO MOTTZILLA AGAIN and THANKS to SHADOWKN55 for the star ocean save hex code.
F-Zero 2 and BS Zelda are probably related problems to loading BS-X roms. They might be fixable with some hex editing or if the PowerPAK loader recognized them in an update I guess. If I ever get a PowerPAK I'd try getting them working.
Pilot Wings I remember being a game that even on Copiers needed a patched/hacked version to play or something like that. I can't be sure but I think it is because Pilot Wings is a LoROM DSP-1 where as virtually everything else I'm guessing is HiROM. I know Super Mario Kart, Lock-On (Super Air Diver), and Super Air Diver 2 are all HiROM DSP1 games. I didn't go through the list of every DSP1 game though to see if it is the only one.
One of my favorites games is on the incompatibility list. But i think someone can get it to work.
The game is street fighter Alpha 2. It use the SDD-1 chip.
If someone decompress Street fighter alpha 2 like someone did for Star OCean, i think street fighter alpha 2 will work with the Snes Powerpak ?
right ?
Is it a hard job to do ?
Another question:
i played with a game title: Sonic the hedgehog (UNL) ??
Is Sega have done a Sonic game for the super nes ?? im very surprised ??
or its a hack ?
the game have several stages and several worlds and it work on the snes powerpak
thanks for answer
(NOTE: I cant pad any hack nes rom. see error : [inSNESt Error] File is smaller than 1 Mbit! ) i tried mappy, anyway i dont miss these games much )
The only sonic I know on Snes is an hack of "Speedy Gonzales":
http://www.youtube.com/watch?v=ysHk1D9RFuk&feature=related
Yes Street Fighter Alpha 2 could have a similar hack done to Star Ocean. But it's not something simple to do.
Could anyone with the Star Ocean save patch please send it to me on this email adress:
henke.999@hotmail.com
Would be very appreciated!
i sent him the patch, enjoy
if it can help people: sorry for my bad english:
1. Download Cygnus Hex Editor FREE EDITION
2. Open the rom file ( you need the star ocean rom of 96mbit edition translated in english, made by neviksti)
3. go to edit choose GO TO and write : 0081D5 , choose ok
4. now change the 32 value to 31. FORGET the h
5. change the others too the same way:
0081D6: 45->02h
A081D5: 32->31h
A081D6: 45->02h
6. go to file and choose save
i hope it can help a few people.
note: i sent you the patch anyway)
renejr902:
could you send me the patch, too ?
Email:
zoigln@googlemail.com
thanks
why not just host it somewhere and post a link to it? Or is that not allowed?
artaxia wrote:
why not just host it somewhere and post a link to it? Or is that not allowed?
OR just follow my instructions before and hex edit the rom yourself. its not so difficult
Oh, don't worry, I didn't have any trouble doing it myself. It was just a suggestion in the event that you get a few dozen pm's from other users asking you to email them the patch.
With all the bashing Retrozone has suffered so far, let me chime in with my experience.
The SNES PowerPak came in the mail today, and I can't believe how amazing a device it is. It works perfectly on my 2/1/3 SNES (PAL). Of course, I have no idea how long it will operate as well as it does now, but for as long as it does I'm going to be a fully satisfied customer.
Everything works, the PowerPak, the card reader, the card itself, the DSP-1...
Way to go, bunnyboy!
Ah, by the way... I got a 2GB card instead of the 1GB one I paid for! If you're reading this, bunnyboy, please tell me if you want me to reimburse you for the difference in price.
P.S. In case you haven't had the chance to use a CF card yet (like me), be careful when putting the card in the reader, so as not to pull out/push in any pins in the reader's slot - push the card in as straight as possible.
pcmantinker wrote:
Ok, so I got a new Sandisk Extreme III 4GB 30MB/s card but I get a different error when trying to boot. It says
Error CF sectors left = 01
Error $01 - CF card error
I am getting the exact same error. I formatted the card to FAT32 with winxp and loaded the POWERPAK dir to the root directory of the CF Card. I am using a Sandisk Ultra 8gb CF card. What does this error mean exactly?
Also, I tried 3 different snes model 1's. All had the same error.
Hey guys, I'm a member over at Digital Press and thought I'd bring up a "bug" I'm encountering with my PowerPak
With over 20 different games good (U)! dumps I have not been able to reach the SNES PowerPak Saving battery RAM screen. Holding RESET for 5 seconds keeps the game playing until I let go in which that time the game resets like it would normally do with a real cartridge. Thus, I am unable to update Battery RAM onto the CF card. This problem is repeatable over and over for me on PowerPak(NTSC CIC DSP1 Installed) 1.02/1.02 on an NTSC US v1 SNES rev 1/1/1.
I am using a properly setup(with DMA=1 working fine) FAT32 PNY Optima Pro 4 GB 133x CompactFlash Memory Card P-CF4GB-133W-DVDC with premade 8kb .srm files from the Retrousb site.
This problem however does not exhibit itself on my US NTSC v1 SNES rev 2/1/2. During holding of RESET the screen immediately switches to black with my proper video 2 channel indication(as I'm assuming from change of resolution) instead of the game continuously playing. Upon release of RESET I'm greeted with the Save Battery RAM to CF Card screen as I should be.
So... bug for rev 1/1/1 systems for the time being? Anyone else here have a 1/1/1 system to test this on? I believe pre 1.02 there were DMA/HDMA problems with 1/1/1 systems?
Greatly appreciated,
jupitersj
i find a way to get the Nightmare Busters rom to work on the SNES POWERPAK
when you load the rom , all the screen become black and freeze. BUT IF YOU RESET THE SNES WITH THE RESET BUTTON NIGHTMWARE BUSTERS WILL LOAD AND WORK.
i played with it it work correclty
note : it doesnt work when the snes powerpak load it the first time, but the game load after you reset the snes, dont power off and power on it wont work. just reset it.
I got my PowerPak a couple weeks ago, and I feel like I've used it enough to report on some things.
My Super Famicom Jr. doesn't work with it (big surprise). So I went back to my dad's to get my regular Super Famicom, and while there, I tested it in my US SNES (NOT an SNES2, though I don't know what model/revision it is). Strangely enough, the menus tended to lock up on the SNES, and even when they didn't, I couldn't get anything to run.
It runs like a charm on my Super Famicom though, and everything I've thrown at it works. All in all, I'd say I'm 95% satisfied - the only things I could have asked for would be better hardware compatibility (but again, I have it working, so no biggie, and I'm sure this will improve with time) and maybe a USB-in port (to further encourage homebrew development).
Personally, I got this for RPGs (to avoid the loss of battery saves) and the potential for homebrew (though I haven't seen much yet), and I can read Japanese, so I haven't messed with any hacks. As such, I'm obviously not going to have as many problems with weird ROMs as many of the other non-devs who bought this. But I can at least add that the Star Ocean fix posted by renejr902 and others works fine on the Japanese Neviksti version as well, though I doubt that's a big surprise to anyone. I agree that it would be neat if someone converted Street Fighter Zero/Alpha 2 in the same way as Star Ocean (if only to improve compatibility by one game), but I have the original cart, and there is no save data (or at least I don't think there is), so personally I'm not that concerned.
renejr902 wrote:
i played it with the emulator. and FFIV ( HARD TYPE) IS MUCH DIFFICULT than FFII US.
i finished the game with the emulator but i want to play it again with the real hardware.
It's already basically been said, but there is no such thing as FFIV Hardtype (outside of maybe some hacks); there is FFIV, FFIV Easytype, and FFIIUS. FFIIUS is actually harder in some respects than regular FFIV - for example, Dark Wave is convenient for taking out large groups of enemies at the very beginning. And just try getting a Pink Tail in FFIIUS!
You may think FFIV is hard
er than FFIIUS, but that doesn't make it
hard - it's still a pretty middle-of-the-road RPG for its time, I'd say, especially compared to FFIII (ugh, the final dungeon!).
renejr902 wrote:
You CANT compare these 2 games. FFii is a lot too easy. believe me the difference in difficulty is really big.
Sounds like you're comparing these two games.
Eyedunno wrote:
It's already basically been said, but there is no such thing as FFIV Hardtype (outside of maybe some hacks); there is FFIV, FFIV Easytype, and FFIIUS.
"FFIV Hardtype" is a
retronym for vanilla FFIV, just as "SMB1" is a retronym for the original Super Mario Bros.
Quote:
renejr902 wrote:
You CANT compare these 2 games. FFii is a lot too easy. believe me the difference in difficulty is really big.
Sounds like you're comparing these two games.
Sounds like you realized the hyperbole.
go to read the wiki for the difference between ffiv ( standard japanese version) and ff2 ( US version)
the differrence in difficulty is big. YOU HAVE TO DO A LOT MORE of experiecne point to gain level in FFIV. when you fight the dark knight while youre the paladin this battle is a lot more difficult.
the queen ashura in land of monsters have a lot more HP in ffiv than ff2.
a lot of difference exist , go read the wiki
I only played FFIII on DS for a couple weeks and beat Dark Cloud easily. I've been stuck at Zeromus on the same FFIV (PS1 Chronicles) file since 2004. Go figure.
Hi guys, I'm just a visitor here, sharing a problem I've got with my SNES PowerPak which arrived last week. I get some errors and have not been able to get any games running on it, but it works fine on my friends SNES, which I found unusual, since his is the exact same model as mine. Both our systems are european (PAL) and were sold in AustraLia. They are both in good working order.
Here's my SNES system details...
Serial Number: UP18110013
Model No.: SNSP-001A(AUS)
Rating: AC9V 1.3A
Errors at power on... "DSP1 not installed" (it is installed)... "SDRAM error"
Cannot get any games running but attempting to load, I get the following... "Copying game... Game copied... Checking BRAM....(some text)... "No Internal Header Found... Check game list......"
And my friends system, which it seems to work ok, though possibly a bit picky with the games and locked up a couple of times on loading a game.
Serial Number: UP16517792
Model No.: SNSP-001A(AUS)
Rating: AC9V 1.3A
Anyway, hope that info is of use to someone. I've just ordered myself a retro duo v2 system so I'm counting on that to fix my problem for the time being, though I will be checking for software updates as I would rather be using it with my SNES.
When you say it works on your friend's console, do you mean YOUR PowerPAK and YOUR Compact Flash card work when put in his console? Just curious if a different console is the only variable.
Moonster wrote:
I've just ordered myself a retro duo v2 system so I'm counting on that to fix my problem for the time being, though I will be checking for software updates as I would rather be using it with my SNES.
I hate to be a pedant, but the RetroDuo
is an emulator. There's really no advantage to ruling out all special chip games, losing all the standard emulator features (auto SRAM save, save states, rewind, filters, etc), getting lower compatibility and, most importantly, spending all that extra money when you could just use a PC emulator in its place.
I'd strongly recommend you get a different model SNES off of eBay instead. Would probably even be cheaper given the used condition. No emulator can match the real SNES with a flash cart.
MottZilla wrote:
When you say it works on your friend's console, do you mean YOUR PowerPAK and YOUR Compact Flash card work when put in his console? Just curious if a different console is the only variable.
Yes, the same PowerPak and compact flash. After I couldn't get it working on my system, I took it over. Wasn't expecting it to work on his either because I knew he had the exact same model, so I was surprised when it did. When I got back, I put it straight into my SNES again and no-luck.
I remember I got my system new, and it was one of the last available around here. I sold my first in '96 then soon after, wished I didn't! Then there was one last batch of 'control decks' that were being sold brand new around here in 2000 for $40 each. I grabbed one off the shelf without a second thought. I'm guessing that since mine was one of the last, there was probably cost-cutting revisions in the hardware. If this is the case, there doesn't seem to be anything external on the system to indicate it.
Quote:
I'd strongly recommend you get a different model SNES off of eBay instead. Would probably even be cheaper given the used condition. No emulator can match the real SNES with a flash cart.
Yes, I will probably do that down the track if I don't have any luck with future software updates. I'm really after a 60 Hz NTSC system, but it is difficult and expensive to get one around here. I can find them easily on ebay but then I'm looking at twice the price of the system to get it shipped over here. I've heard the retro duo has quite accurate emulation, plus it is 60hz and has the option to run NES games, so thought it was definitely worth a look at.
I've just received my SNES powerpak and i only have 1 complaint about this....IT DOEST WORK! It seems there is a SDRAM error and when i try to load a game, i get all kinds of errors about headers and stuff. I tried alot of games and they dont boot. So what's the problem here? my snes? the CF card they sent me? the powerpak itself?
Hi, got the Powerpak 1.02 for Christmas, but I cannot make it work. I have a PAL SNES, 2/1/3, SNSP-001A(UKV) and a 2 GB Kingston CF (that works perfect with the NES Powerpak).
First of all, the CF only "works" if it's formatted to FAT32, because if I format the card to FAT then the Powerpak gives me a "CONFIG file not found" error. With FAT32, I can see the games list, but when I execute any of them, it just shows a black screen or it executes the game with a lot of graphic glitches and then it hangs, even with DMA=0.
I think it can be a CF compatibility problem, but before spending 30+ € in a Dane-elec one, I prefer to make sure this is the problem. Any ideas?
byuu wrote:
There's really no advantage to ruling out all special chip games, losing all the standard emulator features (auto SRAM save, save states, rewind, filters, etc), getting lower compatibility and, most importantly, spending all that extra money when you could just use a PC emulator in its place.
One is SDTV output. PCs with Intel graphics usually don't have it without a $40 VGA-to-composite adapter. Another is the ability to use it and your TV in separate rooms at the same time. So unless it's cheaper than an Acer Aspire Revo nettop and a scan converter...
When I learned of the PowerPak, I was very enthusiastic about the possibilities it seemed to offer.
With some experience of developing games and bootmenus as well as reverse-engineering on the SNES, I even looked into developing my own PowerPak bootmenu while I was waiting for my PowerPak to arrive.
I was a bit disappointed when I received mine and have since not worked on the former anymore.
I started to get worried when people reported problems with different SNES revisions.
As for Compact Flash compatibility, most people report problems here. Personally, I went through 4 CF cards before finding one the PowerPak eventually decided to work with.
It also fails to work with some SanDisk cards (inventors of the CF standard and usually among the best in spec conformity).
When you finally find a compatible CF card and SNES, the PowerPak works quite well. ROM compatibility is good, Star Ocean 96M support is great!
Summarizing my experience, I'd say that the PowerPak does not quite live up to the expectations and is a bit too expensive. It's great when it works, but the remaining issues should be adressed before I can recommend it to others without feeling bad about it.
I really hope that these issues can be resolved in the future.
okay but is the sdram error problem a problem with the kind of snes that you have or the cf card?
I have to agree to d4s on this one. First of all if you want to do any kind
of development the Powerpak is largely uninteresting - it is clearly aimed
at gamers. If you want to do any kind of programming on the SNES get a
quickdev16. At the moment that's by far the best option. Old HK backup
units of course also work but they usually operate over parallel port and
I hate that ;)
The next thing is the price. I paid the $135 plus shipping. That is quite a
lot of money. When I got the powerpak I found out it doesn't work....
What do you do when something you ordered doesn't work ? Right, you
mail to support. Unfortunately I didn't get any answers there. I ended up
finding answers here in the nesdev forum. Surely the store website would
be updated soon I thought. Strangely enough that never happened. After
some time I realized that apparently I belong the unlucky percentage of
people owning the "wrong" SNES version which isn't supported - I
wonder if it is supported now, the website didn't say last time I checked.
I sent several emails asking if the problem is going to be fixed soon, if I
can expect it to be fixed at all etc. I never got any answer. I then mailed
that I wanted to return my powerpack. I had to email several times
before I got a reply to that.
so .. sorry, but : long story short ...
powerpak is expensive, doesn't work and retrousb service sucks.
Well the "problem" with RetroUSB's service is it's 1 person. Also being the holiday season, he probably is on a vacation and not dealing with RetroUSB issues. I think that people have not read part of RetroUSB's site where he makes it pretty clear that it's a small operation and he isn't a retail chain and thus doesn't have 24/7 support.
I do think you are right that the SNES PowerPAK is more aimed at gaming than development. But it's hard to really market a development only device. Right now I use an old Game Doctor SF7 for my SNES needs with the good ol' parallel transfer. It's not the most ideal setup because it requires me to keep an old laptop around for transfers. And since if I were to develop anything for SNES it would still require a jump from my current PC with no parallel port transfer capability, to the laptop to be uploaded.
I think that given more time the compatibility issues with PowerPAK will be worked out. It just seems it went to market a bit too soon. Although perhaps this will have a positive effect on those that were working on their own similar SNES carts using SD cards to encourage them not to abandon their projects.
Not that I hate bunny or anything. But he does seem to have a tendancy of undertesting his products.....I mean a similair issue happend with the nes powerpak. Like you said he might've gone to market too soon.
I have just ordered an American NTSC SNES since there seems to be a lot of problems running the PowerPak on PAL systems (which mine is). Just a couple of questions, if anyone knows... The PowerPak I ordered has the PAL lockout chip in it. I opened it up, and it looks like the chip is a clip-in that can be easily removed/replaced. What would I need to do in order to run it on my North American NTSC system? As far as I know, I will need to remove the PAL chip in the cartrige and the clips in the SNES, so the cartridge will fit in. Is this correct? Or will I need to buy an NTSC lockout chip for the PowerPak?
Also, Could someone tell me how I check what 'SNES hardware revision' I am using, and what they mean? Sorry for my ignorance, SNES technology is not something I have really looked at in the past, but I'd really like to get the best experience out of my PowerPak.
I know this is completely obvious, but:
For all the people who can't get this to work,
PLEASE, PLEASE clean your console connector before complaining. It isn't good enough to say that "my other games work fine".
I doubt there is a good way to check for marginal physical contact in software. Stuff will fail in strange ways. Welcome to my day-job nightmare. Dirty connectors on communication cables causing just bizarre symptoms. Anyways.
And d4s, I disagree with your assertion that the product is overpriced. For being quite a niche item, I doubt he's even going to make a profit for quite a while. Price out low-volume PCB pricing and assembly if any of you are skeptical. Nintendo could do this stuff because they contracted out to have made millions upon millions of these things. Maybe Europe could have been made to wait a bit longer (like they normally do)
as things got sorted out, because of the ridiculously high shipping costs.
Not pointing at anyone, but if I was ever to offer for sale a product like this, there would not be the option of purchase without the media card. Those "people on a budget" are going to drain the most time, energy and resources. Plus, it's doing everyone a favor in the long run.
Moonster wrote:
I have just ordered an American NTSC SNES since there seems to be a lot of problems running the PowerPak on PAL systems (which mine is). Just a couple of questions, if anyone knows... The PowerPak I ordered has the PAL lockout chip in it. I opened it up, and it looks like the chip is a clip-in that can be easily removed/replaced. What would I need to do in order to run it on my North American NTSC system? As far as I know, I will need to remove the PAL chip in the cartrige and the clips in the SNES, so the cartridge will fit in. Is this correct? Or will I need to buy an NTSC lockout chip for the PowerPak?
Also, Could someone tell me how I check what 'SNES hardware revision' I am using, and what they mean? Sorry for my ignorance, SNES technology is not something I have really looked at in the past, but I'd really like to get the best experience out of my PowerPak.
To use your PowerPAK on a NTSC SNES you will need to remove the PAL CIC/Lockout chip and replace it with one you would find in a NTSC game cartridge. You don't need to remove any tabs, the cartridge is molded to fit any SNES slot.
You can get chip revision numbers from some SNES games like the Lion King or Final Fantasy Mystic Quest with hidden cheat codes.
Thanks for the response. I'll try to get the hardware details and post them here for other PAL users. Might even be an idea to start up some hardware safelist for the PowerPak?
As for the NTSC chip.. I'd like to avoid tamering with the PowerPak (if possible). Would disabling the SNES's lockout have the same effect?
okay...please...please answer my question: what the hell does sdram error mean? is it a problem with my snes revision OR the cf card they sent me? please answer
Yes it would. Basically it would be just like trying to get any NTSC cartridge to play on your PAL system.
BeaKManiak wrote:
Hi, got the Powerpak 1.02 for Christmas, but I cannot make it work. I have a PAL SNES, 2/1/3, SNSP-001A(UKV) and a 2 GB Kingston CF (that works perfect with the NES Powerpak).
First of all, the CF only "works" if it's formatted to FAT32, because if I format the card to FAT then the Powerpak gives me a "CONFIG file not found" error. With FAT32, I can see the games list, but when I execute any of them, it just shows a black screen or it executes the game with a lot of graphic glitches and then it hangs, even with DMA=0.
I think it can be a CF compatibility problem, but before spending 30+ € in a Dane-elec one, I prefer to make sure this is the problem. Any ideas?
Finally I bought a Sandisk Ultra II 2 GB and works like a charm with my PAL SNES, even with DMA=1. I had to format the CF to FAT32, because with FAT format the Powerpak still gave me the "CONFIG file not found", but in FAT32 it works perfect.
So, if anyone of you are having problems with a PAL SNES (at least with 2/1/3 hw), check if you can get a Sandisk Ultra II 2 GB, because in my case it worked.
MottZilla wrote:
Yes it would. Basically it would be just like trying to get any NTSC cartridge to play on your PAL system.
Thanks again. Don't think I will need to do that now, though. My retro duo v2 just arrived. It works flawlessly with the PowerPak and as far as I can see it emulates the SNES 100% accurate, with a consistent 60 fps. Also, all the games that had problems (on the other PAL SNES I mentioned) are all working without an issue now. Very impressed so far, yet to come across a problem...
That thing doesn't emulate SNES. It's a hardware clone. The quality of which I'm unaware of but if it's anything like the NES hardware clones it's probably passable but certainly not perfect.
whicker wrote:
And d4s, I disagree with your assertion that the product is overpriced. For being quite a niche item, I doubt he's even going to make a profit for quite a while. Price out low-volume PCB pricing and assembly if any of you are skeptical.
This is a speculative matter, of course.
However, given the fact that I've had pcbs produced and assembled in Shenzhen, China myself, I'd say that I can roughly estimate the production costs of the PowerPak.
whicker wrote:
Not pointing at anyone, but if I was ever to offer for sale a product like this, there would not be the option of purchase without the media card. Those "people on a budget" are going to drain the most time, energy and resources. Plus, it's doing everyone a favor in the long run.
True, but what if a user wants to use a different card, maybe one with more capacity or higher access speed? Retrousb offers 2gb and 4gb cards. IIRC, you need more than that to hold the complete GoodSNES-set uncompressed.
Also, when selling something with a CF-slot, this implicitly gives the impression that this device supports any CF-card you throw at it.
At least, that's what most users seem to assume and I don't think that's an unjustified assumption.
Moonster wrote:
Might even be an idea to start up some hardware safelist for the PowerPak?
Not a first-hand experience, but on a german message board, one user recommended a CF-card that worked fine for him. Another user bought the same card based on that recommendation and it caused problems on his PowerPak. Card in question was: SanDisk Compact Flash Ultra II 8 GB
Moonster wrote:
http://www.youtube.com/watch?v=xR0Msnp5oNU&hd=1
Anyone else having this problem?
I've had a similar issue with Battletoads in Battlemaniacs crashing to a black screen right in front of the ending once. Didn't happen again, though...
d4s wrote:
Moonster wrote:
http://www.youtube.com/watch?v=xR0Msnp5oNU&hd=1
Anyone else having this problem?
I've had a similar issue with Battletoads in Battlemaniacs crashing to a black screen right in front of the ending once. Didn't happen again, though...
There you have another video. Is the Powerpak defective? Never any problem to copy the games from CF card.
d4s wrote:
the complete GoodSNES-set
But who actually plays all those games?
Yeah. I don't really understand these people that want to put all ROMs in their CF cards, specially considering that a bunch of them doesn't even work with the PowerPak. The exact same think happens with the NES PowerPak.
Aren't people already satisfied with the fact that pirating a game and saving it in the card is already 100 times easier than going to the store and buying cartridges at retail price like it was back in the 90's? Nowadays the internet is your 24h free game "store", and your CF card can be your game shelf. You don't need to have everything, just what you actually like and play.
If someone was committed to finishing all SNES games in existence they wouldn't do anything else for the rest of their lifetime.
tepples wrote:
d4s wrote:
the complete GoodSNES-set
But who actually plays all those games?
A year ago or so, I tried every ROM in the goodset in the hope of finding some overlooked gems. Eventually dug up some cool japanese games I didn't know yet and even bought a couple of these afterwards.
There are also a couple of interesting unlicensed/pd ROMs that you'd hardly know about if you didn't try each of them.
Whether someone actually needs a complete set on one card is debatable, but it does have advantages.
d4s wrote:
A year ago or so, I tried every ROM in the goodset in the hope of finding some overlooked gems.
I wish more people would do that, and keep track of any bugs they find :D
I have come back with a few (probably) minor suggestions for possible software revisions for the PowerPak.
1) ".smc" sometimes comes up (for me at least) as ".|mc". It might be nice to fix that, though it's hardly a huge deal.
2) The PowerPak doesn't seem to recognize read-only files, which I can save over just fine. I wish I could flag some saves as permanent. Conversely, making files hidden works to the point where making the POWERPAK directory hidden (to clear up a wasted line on screen) makes it stop working. These again are no big deal, but it would be nice if they got changed.
3) This may be a pipe dream, but it would be sweeet to have an option in CONFIG.TXT to allow automatic loading of sram files (i.e. savefiles are automatically loaded where "[game title].srm" exists).
4) PAR instead of less-useful GG codes would also be great. If I want GG codes, I'll just convert them to PAR.
BTW, my working SFC is 2/1/3, in case that helps in any way. I'll try and figure out what my nonworking Super Nintendo is when I next visit my dad's house (but he lives several hours away)...
renejr902 wrote:
when you fight the dark knight while youre the paladin this battle is a lot more difficult.
Ever try just defending? He goes down in three or four rounds for me, though they're three edge-of-the-seat rounds of sweaty palms and right-followed-by-A. *whew!*
renejr902 wrote:
the queen ashura in land of monsters have a lot more HP in ffiv than ff2.
Try the DS version then. She's more brutal in that version IIRC, so maybe that's the "hardtype".
d4s wrote:
Retrousb offers 2gb and 4gb cards. IIRC, you need more than that to hold the complete GoodSNES-set uncompressed.
Even if you just include one version of every game? I wouldn't think that would be more than 4GB. Most of the complete GoodSNES "content" is superfluous crap, remember that, and when I say that, I'm not even including games that just suck.
d4s wrote:
some overlooked gems
I can tell you now that Pit-Fighter and Super Noah's Ark 3D aren't among them though, so you can safely leave them (and a lot of other stuff) off.
For people wondering:
I just got a Yobo FC16GO today.
And the powerpak works perfectly with it, it's seems to be even better than in my 1/1/1 super famicom (but that's certainly because my sfc slot contacts are worn...).
EDIT: Now I'm sure: It IS better:
-Chrono trigger with french patch: super famicom: HANG (CF ERROR), Yobo: Works.
Only problem... yobo's reset is not really a reset (more an automatic on/off)... so I can't save.
alright, i swapped my snes with my friend's and now it's working... i can't get my expanded star ocean rom to save though.... i tried modifying it with a hex editor but somehow it's not working, can anyone upload a working star ocean rom on megaupload or something like that? i would be very grateful.
gilgamesh21 wrote:
alright, i swapped my snes with my friend's and now it's working... i can't get my expanded star ocean rom to save though.... i tried modifying it with a hex editor but somehow it's not working, can anyone upload a working star ocean rom on megaupload or something like that? i would be very grateful.
Never make ROM requests of any kind.
gilgamesh21 wrote:
can anyone upload a working star ocean rom on megaupload or something like that? i would be very grateful.
It's clear that most people buy PowerPaks for playing pirate games, but this is a development forum and it's not OK to ask for pirated stuff here. I'm sure you can find other ways of obtaining the ROM.
oh right... sorry i forgot about forum rules
bunnyboy wrote:
Yup xc2s15. I don't know if software multiplier would be good enough for the 16x16+ needed, but certainly something to look into in the future. Chip is around 60% full depending what you look at so space may be an issue. FPGA config is on the CF card so it can be added later.
kyuusaku wrote:
Shame on you for not choosing the XC2S100!
By my calculation it would have been able to pull off all chips! A pipelined 16x16 multiplier (fast enough for DSP) might still fit in the 2S15, but definitely not with a CPU core.
I think you should start on the first update right now and give another case color option
(really dig the flashy pink Xmas cart!) I think the 2S100 might even be pin compatible... Call it SNES PowerPak XL or something, I'd totally be willing to pay for the larger FPGA so I can tinker with expansion hardware.
bunnyboy wrote:
:) Looks like it would have to go up to the 208 pin XC2S200 because the 100 isn't really available. The XC2S50 is likely a drop in replacement.
Im just curious here, but how much extra would it have actually cost to use the XC2S50? and could that chip emulate all SNES enhancement chips? If so, is there any possibility that there could be an 'enhanced' SNES PowerPak at some point in the foreseeable future?
It just seems like such a good idea to have a cart that could support all enhancement chips (Like the NES PowerPak does with different mappers) Even if it would add some extra to the cost.
The 50 doesn't have enough logic for the SA-1. It MIGHT be able to fit the rest LOGICALLY, but the lack of block RAM would definitely be an issue! The only hope would be to multiplex the SDRAM between the SNES and enhancement chip and I don't know if that's even a possibility with the hardware implementation much less at the necessary speed. Even with the 100, this would still be the case. Could it be done however, the SA-1 would have a slight chance at being implemented/fitting.
Anyone know whats wrong if I get this message :
Error CF sectors left = 01
Error $01 - CF card error
?
I have a SanDisk Ultra II CF 4 GB card..
This is almost certainly a problem with the SanDisk card compatibility, you should try a different brand.
PowerPak says "I want 1 sector starting from #x". Card says "ok its ready". PowerPak reads 1 sector (512 bytes). Then it checks how many sectors the card thinks are left to be read. The correct answer is 0, but many SanDisk cards say 1. Likely a timing problem where they are too slow and miss some read signals so they still think there are some bytes left to be read. I don't know if its the authentic or fake SanDisk cards that act this way because not all of them do.
bunnyboy wrote:
This is almost certainly a problem with the SanDisk card compatibility, you should try a different brand..
Odd. The 2GB Dane-Elec I
bought with the Powerpak doesn't work at all, yet the Sandisk Ultra II 8GB I had here works fine.
Some homebrew demos currently don't work with the PowerPak (mappers 1.03b). One example is Censor's "Sidmania".
It works with the tototek flash cart, so it's not a faulty ROM.
It's related to how the PowerPAK loads roms. It's more strict than copiers or the tototek flash cart. Could be related to the internal header or if the ROM is less than 512kb it may help to pad it until it is and change the header to reflect that size.
Weird file sizes are not yet supported correctly. For example Sidmania is not a power of 2 (512KB+256KB) so the internal header will be wrong. Games under 512KB will also not be loaded right. It can all be fixed in the mapper software, just low priority right now.
Contra 3 The Alien Wars does not load on the PowerPAK. It complains about the header.
MottZilla wrote:
Contra 3 The Alien Wars does not load on the PowerPAK. It complains about the header.
Yeah, same problem for me with Contra 3.
Also, Family Feud and Jeopardy both need a reset after game load to work properly as well.
Mitch
Contra 3 looks like another one that doesn't have a good internal header. The name extends into the mapper field. Other than ROM editing not sure how to handle that one correctly.
Will have to investigate the others when I am near a PowerPak
So for the record, just change byte $7FD5 (on a headerless ROM) from $53 to $30, which trims the ROM name and thus fixes the mapper.
I changed it to $20 to fix it as I knew Super Castlevania was the same cartridge type (LoROM, 8M) and checked out if it loaded, it did. It also had a title that seemed to go too far, but the final byte of the title was $20 which just luckily agreed with the PowerPAK loader.
Bunnyboy, is there any chance you might make the loader support actually using a Game Doctor SF header for mapping? Or does it already? Seems that could help the problem.
All file headers are completely ignored. From what I saw a random downloaded swc set had far more errors than are showing up here. Of course you could always say "download a verified set" but most people simply won't. The issues will still appear if people use headerless ROMs so that isn't a full fix either. GD3 header also doesn't include info like the battery.
MottZilla wrote:
I changed it to $20 to fix it as I knew Super Castlevania was the same cartridge type (LoROM, 8M) and checked out if it loaded, it did.
Yes, $20 is indeed better. I just checked on Super Probotector (European title of Contra 3), which goes with that value as well.
BTW, I found another game where the same issue arises: Super Adventure Island (US version only). All you PowerPak users, change the byte at $7fd5 (on a headerless ROM) to $20, and you'll be fine.
The European version of the game is not affected.
bunnyboy wrote:
All file headers are completely ignored.
Are you sure about this? I encounter an error message "Bad header or filesize, copying again" once in a while. It doesn't affect gameplay (after "copying again", the game loads fine), but deleting the copier header from the ROM or overwriting it with valid Super WildCard header info makes the error vanish. Strange indeed.
More correct would be all mapping info in file headers is completely ignored. The presence of a header still needs to be detected so the game ROM data is loaded to the correct spot in SDRAM.
I HAVE A GREAT NEWS !!! I GOT BS F-ZERO 2 to work
i think its the first bs game to work on powerpak. but i cant get bs zelda to work
how to get BS F-Zero 2 working
1. You need this rom title: BS F-ZERO Grand Prix 2 (J) [f1].smc
2. you need to remove header ( i use snesROMUtil.exe )
3. change the byte at $7fd5 to $20
ENJOY
Tell me if you get it working thanks
note: i have Mapper v1.03
note: i TRIED Several fzero2 rom and different way to patch it. only the way i explain before work.
Does anyone know why "Chibi Maruko Chan - Mezase Minami no Island" won't run on a PAL SNES? It's not a PowerPak-specific problem, because it won't run from my ToToTek cart either. So my guess is that it either uses some extra chip, or does a software region check.
Since I really like that game I'd consider buying an original copy, but it seems to be pretty rare because I can't find it on eBay (and if it showed up I've got a feeling it'd cost a f*ckload).
mic_ wrote:
Since I really like that game I'd consider buying an original copy, but it seems to be pretty rare because I can't find it on eBay (and if it showed up I've got a feeling it'd cost a f*ckload).
The average price in japan is 10$ or less (loose cart usually):
http://www.superpotato.com/detail/167001205001/
Edit:
Another link, similar price and show the one with box:
http://www.famicom.biz/all/htmls/6800000017145.html
Thanks for the links, both of them have a lot of cool stuff. Neither seem too keen on shipping abroad though (from what I could make of the registration forms by running them through google translate).
mic_ wrote:
Does anyone know why "Chibi Maruko Chan - Mezase Minami no Island" won't run on a PAL SNES? It's not a PowerPak-specific problem, because it won't run from my ToToTek cart either. So my guess is that it either uses some extra chip, or does a software region check.
This game appears to be 50/60 Hz protected in such a way that it doesn't present you with an error message when run in 50 Hz mode (as most other protected NTSC games do), but instead only shows a black screen. Thus, you'd have to remove the protections from the ROM using SNESTool, killem or something similar.
mic_ wrote:
Thanks for the links, both of them have a lot of cool stuff. Neither seem too keen on shipping abroad though (from what I could make of the registration forms by running them through google translate).
Yeah, that's one common problem with those store. The first one as a store in Tokyo (but mostly in Osaka) and I go once in a while. But since there seems to be a protection, you wouldn't be able to run the original unfortunately.
Ah, cool. SNESTool seems to fix the problem (at least in BSNES, I'll have to wait a few hours until I can test it on my SNES).
Sure enough, with the help of SNESTool I can now play "Chibi Maruko Chan - Mezase Minami no Island" on my PAL SNES. It also fixed "Ninja Gaiden Trilogy".
My experience with SNES Powerpak is ver acceptable, I've noticed some layering glitches on next games:
Super Mario World: At final castle , whe you hit Bowser, he starts to turning around, but he disappears while he's being stunned, after that, he appears normaly, this happens too with some on his children's castles.
On F-Zero, roadmap is distorted, unplayable, also son Super Mario Kart.
Jurassic Park 1 at intro the Island doesn't show correctly and Dr Grant gets stuck on a corner.
Capcom's Soccer Shootout, goalkeeper's area is awfully distorted.
Art of Fighting - before it says Fight when Ryo/Robert hop screen got black then normalizes itself.
Donkey Kong Country - Intro, Logo Layering problem, At Misty Mine too.
What's your layering/gaming experience guys?
So i just bought one of these last week. i start it up trying to use it and i hit select at the start menu and i get this error:
SDRAM check
Read bank: FF
ERROR: read=40 wanted=00
at addr=000000
trying again: 40 40 40 40
it won't load up any game at all. most times, i get this screen:
SWC Header Copying Game... Game Copied 1808sectors 24Mbit Checking BRAM... Copying BRAM... BRAM Copied 0010sectors 8KB MAP00 TYP01 ROM7D SRM7F RST007F00 No $40FFC0 Header MAP00 TYP02 ROMEF SRMFF RSTFFFF No $FFC0 Header MAP00 TYP00 ROM00 SRME8 RST0000 No $7FC0 header No Internal Header Found Check the unsupported games listor verify your game file is good
sometimes, i get this screen, which looks like its gonna load, then doesn't go any further than a blank screen:
SWC Header Copying Game... Game Copied 0808sectors 8Mbit Checking BRAM... No Save File MAP00 TYP79 ROM7D SRM7D RST317D00 No $40FFC0 Header MAP00 TYP82 ROMCB SRMCB RST02CB No $FFC0 Header MAP20 TYP02 ROM0A SRM03 RST8000 Header at $7FC0 Battery Added 8KB SRAM Added LoROM 8Mbit SRAM in 7x/Fx 0 1 2 3 4 5 6 7 8 9 A B C D E F 20212021202120212021202120212021 2021207F 2021207FGG-> $000000 = $00 code unused GG-> $000000 = $00 code unused GG-> $000000 = $00 code unused GG-> $000000 = $00 code unused GG-> $000000 = $00 code unused
anyone have any clue whats going on here? i bought it with the CF card to insure compatibility, but after reading here i thought that it might be bad. so i went and bought another one, and its giving tme the same errors. it does this regardless of if i use DMA=1 or DMA=0, on either card.
edit: i've tried this on the 1.02, 1.03, and 1.03b mappers with both cards and both DMA's with no luck
Have you formatted the cards and removed the copier header from the games?
tairan, we need specifics. Please verify your files are actually rom images, not savegames / .zst's / etc. The most helpful would be to use NSRT
http://www.romhacking.net/utils/400
I'm tending to believe the " No Internal Header Found Check the unsupported games list or verify your game file is good " message at this point.
abarberena_gil: same thing. are these "good" dumps? That, or your SNES itself is crapping out, or you're swapping PAL<->NTSC games. Do you have the real cartridge of any of those games that are causing problems? Do those work without issue?
whicker wrote:
tairan, we need specifics. Please verify your files are actually rom images, not savegames / .zst's / etc. The most helpful would be to use NSRT
http://www.romhacking.net/utils/400I'm tending to believe the " No Internal Header Found Check the unsupported games list or verify your game file is good " message at this point.
yes they are valid roms, i have used the NSRT utility on the ones that i have tried using. i've added nsrt headers, removed headers, add empty headers, all that i could, and haven't had anything go yet.
i have formatted both CF cards using FAT32, since FAT16 has a read error right off the bat. i've tried it on both a FC twin and an original SNES. not sure how to tell the difference in versions, but it just says SNS-001 on the bottom. doesn't work on either
the most promise i've seen so far is that it gets to the screen that says "copying game..." then sits there til i reset it.
If Fat16 errors right off the bat, perhaps it's a problem with your memory card. If you can try another CF card you should, it could be that the one you are using has something wrong with it or the powerpak just doesn't like it.
MottZilla wrote:
If Fat16 errors right off the bat, perhaps it's a problem with your memory card. If you can try another CF card you should, it could be that the one you are using has something wrong with it or the powerpak just doesn't like it.
i've tried 2 CF cards, one of them that came with it. both give a "config file not found" error if its not in FAT32
whicker wrote:
abarberena_gil: same thing. are these "good" dumps? That, or your SNES itself is crapping out, or you're swapping PAL<->NTSC games. Do you have the real cartridge of any of those games that are causing problems? Do those work without issue?
Hi whicker, actually they're good dumps, a friend of mine tested them on his powerpak, and they go OK, i was thinking about you said of CLEAN console before to assume something.
Posted my rom layering experience in case someone else have same glitches.
So, the question is My SNES PPak is defective or my console is crapping it out? as you suggested.
this weekend i'll get a gamebit to perform an intensive cleaning and discard some doubts.
alrighty so i thought it might be i had bad roms, so i downloaded the snes goodset with the verified dumps. but, those still arent working. where did you guys download your roms that work, or do i have to edit the roms and add internal headers myself or what?
sorry, i just can't get the guy to email me back after more than a week ><
tairan wrote:
MottZilla wrote:
If Fat16 errors right off the bat, perhaps it's a problem with your memory card. If you can try another CF card you should, it could be that the one you are using has something wrong with it or the powerpak just doesn't like it.
i've tried 2 CF cards, one of them that came with it. both give a "config file not found" error if its not in FAT32
hi I have exactly the same problem the message config file not found" appears. any solutions yet?
Maybe u should try to update the mappers because the Config.txt is included in the new mappers package
Zoigl wrote:
Maybe u should try to update the mappers because the Config.txt is included in the new mappers package
???
ive downloaded the zip file and unpacked it to directory POWERPAK
Quote:
Error CF sectors left = 01
Error $01 - CF card error
?
I have a SanDisk Ultra II CF 4 GB card..
gettings same error with miy 8 GB card SanDisk Ultra II
Quote:
I don't know if its the authentic or fake SanDisk cards that act this way because not all of them do.
got mine directly from amazon in a retail package
thought sandisk is a good brand
Quote:
Odd. The 2GB Dane-Elec I bought with the Powerpak doesn't work at all, yet the Sandisk Ultra II 8GB I had here works fine.
could you write down code and "made in..." at small side of CF Card?
btw. will there be a N64 Powerpak soon since neoflash offers a flash system?
Quote:
could you write down code and "made in..." at small side of CF Card?
BI090312757B made in China
As an update - the 2GB Dane Elec I bought with the PP works now after the latest 1.03 PP update.
If you format these cards first to FAT32 it will probably work?
they are mostly formated only in FAT if you buy a new one
I've tried many SMW-hacks on the PowerPak (and the most works perfectly in bsnes or zsnes) but only a few of them works without crashes etc.. Is this related to the orginal hardware or to the PowerPak?
Also the PowerPak always says "bad checksum or filesize" but the checksum is ok. How can i check the filesize?
Zoigl wrote:
I've tried many SMW-hacks on the PowerPak (and the most works perfectly in bsnes or zsnes) but only a few of them works without crashes etc.. Is this related to the orginal hardware or to the PowerPak?
A lot of hacks have never been tested on a Super NES. Emulator results might not be fully reliable; even the author of bsnes admits that its PPU is closer to Nesticle than to Nintendulator in accuracy. Have you tried burning it on an EPROM?
Fab wrote:
If you format these cards first to FAT32 it will probably work?
Tried both on the Dane Elec. It refused to work until the new PP update.
tepples wrote:
Zoigl wrote:
I've tried many SMW-hacks on the PowerPak (and the most works perfectly in bsnes or zsnes) but only a few of them works without crashes etc.. Is this related to the orginal hardware or to the PowerPak?
A lot of hacks have never been tested on a Super NES. Emulator results might not be fully reliable; even the author of bsnes admits that its PPU is closer to Nesticle than to Nintendulator in accuracy. Have you tried burning it on an EPROM?
not yet but i will try it at weekend.
Could u also explain me why when the PowerPak loads the rom, the first time appears "bad filesize or checksum" and on the second try it works?
I want to confirm that my SanDisk Ultra II 2.0GB (formatted to FAT) and Lexar 4GB Platinum II 80X (formatted to FAT32 and DMA=0) work with the 1.03 update. I also have a SanDisk Extreme III 4GB 30MB/s card, but it doesn't work with FAT or FAT32 formatting. That's not a huge issue though.
Prior to the 1.03 update, however, none of my cards worked. I assumed that I had a faulty PowerPak, but apparently it had something to do with my SNES. My SNES is not a mini so I thought that it was strange it wasn't working. It's an NTSC American SNES with 2/1/3. In any case though, it's fixed now.
On a side note, would it be possible to add Pro Action Replay cheat support in a later firmware? I understand that more ROM addresses can be modified with the Pro Action Replay than the Game Genie. If not, it's not a problem. Game Genie codes definitely beat Gold Finger codes. Thanks for your hard work!
Action Replay doesn't modify ROM. Instead, it hijacks NMI to modify RAM.
tepples wrote:
Action Replay doesn't modify ROM. Instead, it hijacks NMI to modify RAM.
Ah, my mistake. That makes sense. It was late and I didn't pay attention to my statement. ROM is read only so it can't be changed. Thanks for the clarification.
Hey, I just ordered a PowerPak. Planning to pick it up from my brother's house when I'm in the US in May.
Given all the SD/CF cards are made here in China, I think I can get several to try cheaper than I could in the US. Hope one in three will work OK assuming they were not ghost-run.
I had a question about the SNES mini/Jr.
As of last night (Feb 26) the
RetroZone page said:
Quote:
System Compatibility List:
- Works on full size Super Nintendo and Super Famicom systems from
- NTSC and PAL regions with correct lockout.
- Works on the Nintendo SNES mini, aka SNES Jr.
- Works on the RetroDuo and FC Twin clones, no lockout needed.
- Other clones untested, likely to work.
Is this a new update or has it always been there? Given how many problems were reported in this thread with the SNES mini/Jr failing to work, should I assume compatibility is fixed in the latest BIOS?
Or has bunny just never updated the page to say that console doesn't work?
Asking because I was planning to take an SNES mini back with me. If it's still known not to work, I'll try to pick up a Japanese Super Famicom on the local second-hand market.
D wrote:
Is this a new update or has it always been there? Given how many problems were reported in this thread with the SNES mini/Jr failing to work, should I assume compatibility is fixed in the latest BIOS?
It is indeed fairly new (a month or so ago, I guess); I actually bought mine never expecting to be able to play it on my SFC Jr. There were issues, but they were fixed starting with the 1.03b mapper pack (nothing to do with the BIOS/firmware). Others have confirmed that it works with the SNES 2, and I have personally confirmed that it works with the Super Famicom Jr. (the Japanese equivalent of the SNES 2). CF card compatibility is also apparently improving. So shop with confidence.
does anyone know for sure if it'd work on the portable Yobo FC-16 Go?
Yobo gameware snes handheld.
thanks for answer
someone said in a forum that compatible
but i read its not compatible with Revision 1 for saving ?? because reset button work bad. how bad exactly ?
because i was about to buy the revision 1 for a low price.
thanks for answer
or do you think it can be easily modded for get the reset working correclty on revision 1 for saving. my father is a electronic tech
thanks for answer
i got BS-Zelda working with last 1.04 mapper on retrousb.
But i have to download several bs zelda roms before getting one that work really . a lot of them freeze in main menu of the game , you cant choose your name and create your carater.
but i got one rom that work perfect. i play 10 minutes the game. no problem so far.
renejr902 wrote:
but i read its not compatible with Revision 1 for saving ?? because reset button work bad. how bad exactly ?
because i was about to buy the revision 1 for a low price.
thanks for answer
or do you think it can be easily modded for get the reset working correclty on revision 1 for saving. my father is a electronic tech
thanks for answer
Indeed,
On my FC 16 GO, the reset button shut down the console.
But I found a way to be able to save:
-Press and Hold the ON button
-Now, press and hold the reset button for 4 seconds...
-Release the reset button, the powerpak message prompt for the save appear.
-Navigate where you want to save, validate...
-Then release the ON button, the fc 16 go shuts down, but your save is saved.
thanks a lot for answer , i will buy revision 1. i will take the risk
Heya,
I bought the SNES powerpak a few weeks ago with the 2gb Dane-Elec CF card that comes with it.
Sadly, I cant get any of the games to work for more than a few minutes. The cartridge boots fine, seems to copy the selected game without too much trouble. But depending on the game, it either just freezes at some point (black screen) or the graphics glitch out badly.
I have tried with DMA on/off, tried formatting FAT16/32, tried using old mapper versions (though I went back to 1.04 afterwards) and nothing has fixed it.
Lastly, It doesn't seem like the games always glitch at the same point. I can't tell if its time-related (heat?) or if the rom file has been miscopied. My SNES is a SNES Mini (aka Snes Jr.)
Any ideas how to fix the problem? Thanks.
Edit: Also tried using a Transcend 1gb and a Sandisk Extreme III CF card. The former wouldn't boot (FAT16/32 error even though it was in that format) and the latter gave me some weird error (Sectors Left = 1).
I want to buy my FC 16 GO at
www.DASCHEAP.com to play with my snes powerpak.
did someone has bought anything from there and receive it. they dont accept paypal, i have to pay with my credit card and give all my personal information.
thanks for answer.
or how can i be sure this web site online shop is legit ??
Lodis wrote:
Heya,
I bought the SNES powerpak a few weeks ago with the 2gb Dane-Elec CF card that comes with it.
Sadly, I cant get any of the games to work for more than a few minutes. The cartridge boots fine, seems to copy the selected game without too much trouble. But depending on the game, it either just freezes at some point (black screen) or the graphics glitch out badly.
I have tried with DMA on/off, tried formatting FAT16/32, tried using old mapper versions (though I went back to 1.04 afterwards) and nothing has fixed it.
Lastly, It doesn't seem like the games always glitch at the same point. I can't tell if its time-related (heat?) or if the rom file has been miscopied. My SNES is a SNES Mini (aka Snes Jr.)
Any ideas how to fix the problem? Thanks.
Edit: Also tried using a Transcend 1gb and a Sandisk Extreme III CF card. The former wouldn't boot (FAT16/32 error even though it was in that format) and the latter gave me some weird error (Sectors Left = 1).
Which mappers are you using? Try the latest 1.04 mappers and see if that works. I know that some Sandisk cards have errors with the PowerPak. I've not been able to get my Sandisk Extreme III working. When I first got the PowerPak, none of my three CF cards worked, but after I upgraded to the 1.03 mappers, two out of my three cards have worked.
pcmantinker wrote:
Lodis wrote:
Heya,
I bought the SNES powerpak a few weeks ago with the 2gb Dane-Elec CF card that comes with it.
Sadly, I cant get any of the games to work for more than a few minutes. The cartridge boots fine, seems to copy the selected game without too much trouble. But depending on the game, it either just freezes at some point (black screen) or the graphics glitch out badly.
I have tried with DMA on/off, tried formatting FAT16/32, tried using old mapper versions (though I went back to 1.04 afterwards) and nothing has fixed it.
Lastly, It doesn't seem like the games always glitch at the same point. I can't tell if its time-related (heat?) or if the rom file has been miscopied. My SNES is a SNES Mini (aka Snes Jr.)
Any ideas how to fix the problem? Thanks.
Edit: Also tried using a Transcend 1gb and a Sandisk Extreme III CF card. The former wouldn't boot (FAT16/32 error even though it was in that format) and the latter gave me some weird error (Sectors Left = 1).
Which mappers are you using? Try the latest 1.04 mappers and see if that works. I know that some Sandisk cards have errors with the PowerPak. I've not been able to get my Sandisk Extreme III working. When I first got the PowerPak, none of my three CF cards worked, but after I upgraded to the 1.03 mappers, two out of my three cards have worked.
I upgraded to the 1.04 mappers before I plugged the snes powerpak in my nintendo for the first time. I tried the CF cards mentionned in my first post as well as a Sandisk Ultra II 4GB and a Lexar Platinum II 4GB and none worked. I went back to the 1.03 mappers, which made the Lexar card boot properly, but then the games would glitch really, really bad.
Edit: I realise these are the 2 cards you got to work with mappers 1.03. Gotta wonder if my Snes console or powerpak are faulty.
If you're able to test your PowerPak with the various different compact flash cards you have on another SNES, I would recommend that for ruling out the PowerPak as being faulty. I thought that my PowerPak didn't work when I first got it. I just had to be patient and wait for a fix in the firmware. Supposedly SNES mini support was added in 1.03 so it should work fine with those mappers. I don't have a SNES mini to test that though. If your PowerPak works on a full sized SNES, I would recommend getting one from eBay as they are relatively cheap.
pcmantinker wrote:
If you're able to test your PowerPak with the various different compact flash cards you have on another SNES, I would recommend that for ruling out the PowerPak as being faulty. I thought that my PowerPak didn't work when I first got it. I just had to be patient and wait for a fix in the firmware. Supposedly SNES mini support was added in 1.03 so it should work fine with those mappers. I don't have a SNES mini to test that though. If your PowerPak works on a full sized SNES, I would recommend getting one from eBay as they are relatively cheap.
Right, I'll do that. One of my friends have to have a regular Snes around collecting dust that I could borrow.
I'll let you know how that goes.
Update:
My powerpak with its Dane-Elec 2GB card works perfectly on a regular SNES I borrowed (I believe its the SNS1001 board model).
Here's something I ommited to say:
I did a modding project on my snes mini (basically its a case-mod) meaning I had to relocate the 62pin cartridge socket. So there are a bunch of wires that are about 4 or 5 inches long between the board and the cartridge. This is the only thing that differentiates my own snes mini with non-modded ones.
As far as I know, there are some few games that require very precise timing (such as Yoshi's Island) and wouldnt work on my modded snes. So could that be the reason my powerpak fails to work properly on my console? What's weird is that it plays really fine until about 5 to 10 minutes where graphics start to glitch..
I had the same problem with a first-gen NES PowerPak when I used floppy cable wires for the resistor fix; a lot of games would either fail to load outright or crash after a few minutes. Soldering the resistors directly to the board completely fixed it.
I would say that's definitely your problem as well. PowerPaks just seem to ride the bleeding edge of stability, to the point where even different revisions of the same console can affect compatibility. :\
BMF54123 wrote:
I had the same problem with a first-gen NES PowerPak when I used floppy cable wires for the resistor fix; a lot of games would either fail to load outright or crash after a few minutes. Soldering the resistors directly to the board completely fixed it.
I would say that's definitely your problem as well. PowerPaks just seem to ride the bleeding edge of stability, to the point where even different revisions of the same console can affect compatibility. :\
Thank you for the input.
I am also using floppy cable wires. I guess I'll have to grab my soldering tools and figure out the maximal length of the wires and build my mod around that
renejr902 wrote:
I want to buy my FC 16 GO at
www.DASCHEAP.com to play with my snes powerpak.
did someone has bought anything from there and receive it. they dont accept paypal, i have to pay with my credit card and give all my personal information.
thanks for answer.
or how can i be sure this web site online shop is legit ??
Read online that that guy who runs dascheap.com has a lot of checkered past stuff tying him to fraud. I purchased mine from Videogamecentral.com. They've been around for years.
I noticed Snes powerpak now uses "Super Ciclone".
Is it Ikari's CIC Pic version? As it has been released under GPL v2, I think Bunnyboy is violating GPL by not releasing any source.
Zonomi wrote:
I noticed Snes powerpak now uses "Super Ciclone".
Is it Ikari's CIC Pic version? As it has been released under GPL v2, I think Bunnyboy is violating GPL by not releasing any source.
if i didn't read this
bunnyboy wrote:
If anyone knows someone who is awesome at PIC programming, I will offer a significant pile o cash for a Super Ciclone. Please PM/email to not derail the thread.
i would think most likely the Ciclone code with the added delays, triple mangle and the new seeds..
Hi @all.
this is my first post on this forum. I read it since several month. Now i have a question relation the snes powerpak.
Did i missed something, or is rregio patching not possible with the snes powerpak?
Here is a link what i'm talking about:
http://www.emulatronia.com/doctec/conso ... protection
It's just because i can't play some games, esp. Secret of Mana (PAL) on my FC16 Go, just because i have an snes powerpak with PAL lockout.
Is it possible in later mappers to add the ability to make an on the fly regio patch?
In the myth forum someone already did this:
http://www.neoflash.com/forum/index.php ... 042.0.html
b.regards!
Actually it's not part of the Myth menu (yet). The code I posted was intended to be used with the Neo2 Ultra Menu (the PC software used for putting ROMs on the cart). I may add on-the-fly patching to the menu at some point, although this will slow down ROM loading a bit.
Your current option is to download SNESTool or some similar program and patch the ROM before you put it on your cart.
I understand.
But it would be a really great addition for myth ot powerpak. Just because we don't need a lockout chip or ciclone anymore.
Offline patching is an option, but not that easy to use.
You still need a CIC(lone). The patching we're talking about here only solves the software region check that a few games do.
With software region check, you don't mean the CIC check? CIC check is on the hardware modul and not coded into the rom?
So i can't patch my PAL - Secret of Mana rom and then run it on my fc-16 go using the powerpak?
You need the CIClone to keep the console from holding the CPU in reset.
A clone (which I'm guessing that the FC-16 is) might not have a CIC on the console side, and therefore might not care about whether or not a CIC is present in the cartridge.
If you want the cart to also work on an official SNES/SFC you will need a CIC(lone) for the reason that tepples gave.
Ok.
. Thats why i wrote FC16 go. Of couse you need an CIClone if you use a SNES with CIC.
Thanks for explanation. So it would be really great to have rom patching to remove region check in powerpak.
Maybe it's doable with the current GameGenie patchsystem?
With a Game Genie you can patch up to 5 bytes of ROM. This is plenty to fool a game with NTSC/PAL protection into running on the opposite video system. But if the game for some reason doesn't function properly on the opposite then you'd need more than just a few byte changes.
MottZilla wrote:
With a Game Genie you can patch up to 5 bytes of ROM. This is plenty to fool a game with NTSC/PAL protection into running on the opposite video system. But if the game for some reason doesn't function properly on the opposite then you'd need more than just a few byte changes.
Of couse. But using Game Genie and on-the-fly patching is far more better than a hard patch. In Snes-Powerpak i can place a Game Genie file, this should do the job.
Update: As long as i understand GG patching, I can patch "Secret of Mana PAL" to work on my FC16 Go (NTSC without cic) using this GameGenie code with Snes-Powerpak "CB83-DF92".
Correct?
Hi Heinz2001,
Patching based on a generic seek and replace method is not always reliable. Indeed I've already come across games where the code pattern of the protection is not listed on the web page you gave earlier. This half broken "feature" would be hard to support for the powerpack designer imho.
The gg code is not too hard to find with a debugger. Of course a more extreme but easier solution would be to use the US version.
Now about the gg code you've found, there have been several revisions of SoM PAL, in different languages.
Could you please provide the crc of the rom you're using ?
--
I used SnesTool to patch this rom and then i compared the patched one with the unpatched one. Then i used ggconvc to convert the hex adress and the byte value into GG code.
md5: 976edc10fbb8825d9d2e31117055f1f9 *Secret of Mana (G).smc
sha1: e54e6b8c41b14b1ef579ac73c16cc39dec4d9b35 *Secret of Mana (G).smc
Of couse i can use the US version, but i want to play Secret of Mana in German on my FC16 Go
. I have several Pal Games with german language that don't work on the FC16-Go. Thants why i wanna use my powerpak to play them.
I searched the web for GG codes to patch roms for region. But i can't find one. I don't think i'm the first one who want todo this
?
Well I don't know from where you got the rom (and I don't want to know) but the goodsnes and no-intro db all agree on the
same hash for SoM German which is not the same as yours.
Anyway I'll show you how to get the gg code by yourself. This is using the german version with the following hash :
(md5)B57303407986C0D28F2D78F931EFC59C
(sha1)AB8A31BFB4CF0CE19B96893A31442FFBFD8D0BEB
- Open the rom in an emulator which include a debugger like bsnes.
- Open the debugger and put a breakpoint on 213f when read. $213f is a register where the region type is stored (PAL/NTSC). The games always read this register to detect the region.
- Reset the game. It should stop with the following:
Code:
7ed45a lda $00213f [00213f] A:0204 X:0620 Y:0610 S:02e9 D:02ee DB:7f nvMxdizC V: 70 H: 10
This is where the game tries to read the region code. Step a bit through the code until you reach a condition:
Code:
7ed45e and #$10 A:0263 X:0620 Y:0610 S:02e9 D:02ee DB:7f nvMxdizC V: 70 H: 10
7ed460 cmp #$10 A:0200 X:0620 Y:0610 S:02e9 D:02ee DB:7f nvMxdiZC V: 70 H: 26
7ed462 beq $d47f [7ed47f] A:0200 X:0620 Y:0610 S:02e9 D:02ee DB:7f NvMxdizc V: 70 H: 42
This last line is a conditional jump. If on NTSC, display the bad boy message else jump over the bad boy code and continue. Of course, this portion of code change from game to game, so you'll have to understand a little bit of assembler but this should be ok with the proper documentation. - One way to always jump over the bad boy message is to change the conditionnal jump to an unconditional one. Refering to the doc, we can use the BRA instruction which translate to opcode $80 in hexadecimal (while BEQ translate to F0).
So we want to have $80 at address $7ed462, give that to ggconvc 7ed462:80 and it returns 6D21-FA8B. (I'm using "Game Geni Code Converter by the way)
Now there is catch: while this code should work with emulator like bsnes or zsnes, it won't on the original gg hardware and by extension on the powerpak (I guess because I don't own a ppak but then it would allow PAR code as well). This is because the target of the patch is in the system RAM (begins with 7e/7f) which the gg can't access. But all is not lost, the code must have been copied from the ROM to the RAM from somewhere else.
5. Disable the breakpoint on 213f and put a breakpoint at 7ed462 on write. Reset the game:
Code:
0001f0 mvn $c7,$7e A:0001 X:b2e9 Y:d462 S:01c0 D:01c5 DB:7e NvMxdIZc V:245 H: 584
This copy byte from @c7b2e9 to @7ed462. So we want to overwrite byte @c7b2e9 with 80 => ggconvc: c7b2e9:80
=>
6D83-849A
This should do it.
Yes, the Game Genie cannot override RAM, as the system itself responds to those addresses instead of the cart bus.
The Pro Action Replay "cheats" by hooking the NMI routine and manually overwriting RAM each frame.
Unfortunately there are thousands of RAM-based codes out there, so we can't very well ignore RAM-based GG codes.
Thanks for this good Tutorial.
Anyway. I tried my GG code and it don't work. I tried the snestool patched rom (for ntsc) and it worked.
I have to get hands on the rom version you mentioned.
So GG codes patch the rom not the ram right?
Heinz2001 wrote:
So GG codes patch the rom not the ram right?
byuu in the post immediately before that one wrote:
Yes, the Game Genie cannot override RAM
I read this
, but it does not say explicitly that it overwrites the rom. And i asked, just because my calculated code don't work.
@Marcel: Ok. I found the rom version you mentioned and used your GG code. It also does not work.
Maybe i calculate the GG code wrong.
ok, snestool change byte $29 to $a9 @7b2e5 in the rom file, ie "and #$10" becomes "lda #$10" in the code listing I gave earlier.
The gg code to mimic this would be:
$c7b2e5:a9 ($c7b2e5=$7b2e5+$c00000 : hirom, no header)
=> CB83-8F9A
To calculate the right address - without using a debugger -, you need to know the map mode of the rom (lorom,hirom,...) and check the presence of an header to add 512 ($200) accordingly. Please note that while the goodtools rename this rom with an smc extension, there is actually no smc header.
I just checked those two codes (CB83-8F9A and 6D83-849A) in both bsnes and zsnes by forcing the rom to load in ntsc mode and it works ok. So if this don't work for you, I don't see why and can't help any further i'am afraid as I don't own the fc16, the gg nor the ppack
Ok. I tried both codes yesterday. No code works. This is strange indeed.
I also tested both codes on bsnes and they work. Mh. Would be cool to know something about the GG implementation in Snes powerpak.
Bunnyboy?
Strange questions
The same CF card
My SFC:game perfect work
My friend's (A) : no one can the SFC and submitted to the different work as freely though they are wrong, including $51 CF CARD: they $10 CF CARD as freely though they as freely though they
I another friend (B) the SFC: the game, most occasionally work does not work, and friends (A) the same mistake
I another friend (B) the SFC JR: game perfect work
Don't have internal voltages and host?
Excuse me, where the problem??????
Heinz2001 wrote:
Ok. I tried both codes yesterday. No code works. This is strange indeed.
I also tested both codes on bsnes and they work. Mh. Would be cool to know something about the GG implementation in Snes powerpak.
Bunnyboy?
I can confirm that Game Genie codes have never worked for me on the PowerPak, even when they work on emulators or with an actual Game Genie.
lifeixie wrote:
My SFC:game perfect work
My friend's (A) : no one can the SFC and submitted to the different work as freely though they are wrong, including $51 CF CARD: they $10 CF CARD as freely though they as freely though they
I another friend (B) the SFC: the game, most occasionally work does not work, and friends (A) the same mistake
I another friend (B) the SFC JR: game perfect work
If you are using an automatic translation site, please know that what you have said is almost completely impossible to understand. All I gather is that some Super Famicoms work and some don't.
It might help to press select at the first screen and tell us the CPU, PPU1, and PPU2 numbers.
to Eyedunno
*8
-----------------------------------NO----------------------
SFC1(japan)------CPU = 02 PPU1= 01 PPU2 = 03 (not 90 weight loss
)
SFC2(japan)------CPU = 02 PPU1= 01 PPU2 = 03 (not 90 weight loss
)
SUPER nintendo------CPU = 02 PPU1= 01 PPU2 = 03 (UNV PAL,Hong Kong??Europe not run,,,have pal 50/60)
-------------------------------------------------------------
------------------------------------OK--------------------
SFC3(japan)------CPU = 02 PPU1= 01 PPU2 = 01 (90)
SFC4(japan)------CPU = 01 PPU1= 01 PPU2 = 01 (90)
SNES1(USA)-------CPU = 02 PPU1= 01 PPU2 = 03
SNES2(USA)-------CPU = 02 PPU1= 01 PPU2 = 03
JR-----------------------------------------------
------------------------------------------------------------
locking NTSC.
@bunnboy
Is it possible to add a auto-load function, too?
it would be nice if the powerpak would look in the same directory (where the game is stored) for an "romname".srm. Also It should be possible to change the selected srm file if the the auto-load function is enabled.
And
what about making the powerpak-software open-source? Some poeple could build other cool stuff for the powerpak, too
Hi this is my first time posting on this forum. I have a classic snes bought in America during the mid 90s. I decided to buy a snes powerpak because I thought it looked fun and would be easy to get working. It has been two weeks now of me trying unsuccessfully to get this useless $160 paper weight to work. I have tried no-intro roms, using NSRT, .sfc files, everything but I always get this same black screen whenever I try to load a game. I'm sure it is some little thing that is stopping me so if you have any advice pleeeaase give it to me. In fact I'm not even asking I'm begging for a slight bit of help anything would be appreciated.
Thanks
All my games turned up garbled with my new Kingston 8 GB 133x...
But I got my other Kingston card to work!
I had another Kingston 4 GB standard that once worked for my powerpak NES lying around but both powerpak turned it down as bad format. New format didn't help.
This is what I did to bring the bad format back to life:
Deleted the partition on the CF-card
Made a new primary partition on 4 GB
(Quick) format in FAT32 default cluster size
Copy POWERPAK folder as the first thing to avoid card busy
To delete the partition i used windows enabler 1.1 in disk management on my xp machine
Now to experiment with partition and cluster sizes. It think its wierd that the manual states powerpak uses the first logical partition... I think you need linux to do such tricks with the cf card.
I haven't touched the games with any tool (verified roms)
ps. don't go buying kingston 4 GB standard just because my works, kingston probably uses random chips on each batch
UPDATE: Using the same procedure I got my Kingston 8 GB 133x working as well - first try it started garbling up again because I partitioned to 8 GB... It seem to work best with 2 GB. Maybe its the cluster size as I just chose default - now to see if it will continue to work. UPDATE: According to MS clustersize is always 4 KB up to 8 GB. Bah it started acting funny again trying different stuff... The CF is just generally unstable - guess the format only helped a little. I tried a 8 GB 133x from kingston last fall and I remember that it worked ok in my nes powerpak, they must have changed chips ok I remember wrong...
Snespowerpak wrote:
Hi this is my first time posting on this forum. I have a classic snes bought in America during the mid 90s. I decided to buy a snes powerpak because I thought it looked fun and would be easy to get working. It has been two weeks now of me trying unsuccessfully to get this useless $160 paper weight to work. I have tried no-intro roms, using NSRT, .sfc files, everything but I always get this same black screen whenever I try to load a game. I'm sure it is some little thing that is stopping me so if you have any advice pleeeaase give it to me. In fact I'm not even asking I'm begging for a slight bit of help anything would be appreciated.
Thanks
Best advice if you are having problems is to try a different SNES console (be sure it works) and/or try a different CF card.
It may be a little bit off-topic but related to the snes powerpak. I may have missed the reason in all the messages that was posted but want to know: what make it so hard to make the powerpak work on many snes revisions compared to the game doctor that seemed to work on any machine? I'm just curious.
Banshaku wrote:
It may be a little bit off-topic but related to the snes powerpak. I may have missed the reason in all the messages that was posted but want to know: what make it so hard to make the powerpak work on many snes revisions compared to the game doctor that seemed to work on any machine? I'm just curious.
Improper 3.3V to 5V CMOS logic level translation.
Lack of testing.
One-man design.
A focus on minimum component count versus a robust circuit.
Chinese CF Card chicanery.
Everyone's old decaying hardware.
I see. So there are many cause in this. But is the others ones like the myth (?) one have the same issue? Did the game doctor, super wild card (?) etc had those issue in the past too?
I'm not aware of the Game Doctor or other copiers having these issues. Ofcourse those devices were much more expensive and likely developed by more than 1 person and probably tested pretty extensively. No clue about the Myth cartridge.
Banshaku wrote:
I see. So there are many cause in this. But is the others ones like the myth (?) one have the same issue? Did the game doctor, super wild card (?) etc had those issue in the past too?
I don't know about the Neoflash myth.
Floppy drives are mediocre in terms of reliability and speed. And yes, copiers have their own unique quirks (DRAM expansion, power adapters, incompatible floppy formatting) AND went through a back and forth battle with copy protection. Depending on the copier model, one must even patch certain game images so they'll even run instead of displaying a scary warning screen.
I still firmly believe the flash-based or memory card based carts are the way to go now... I mean, unless you absolutely love parallel ports and floppies.
whicker wrote:
I still firmly believe the flash-based or memory card based carts are the way to go now... I mean, unless you absolutely love parallel ports and floppies.
Nah. I had one in the past for snes and megadrive. I'm not touching those floppy thingy anymore. I may invest in one of those flash based one someday when I feel like developing for it. It just would suck to buy one and it doesn't work because of X hardware. I don't know if there is many issue with the Japanese models yet.
whicker wrote:
Depending on the copier model, one must even patch certain game images so they'll even run instead of displaying a scary warning screen.
I don't think it was so much a back and forth. There are only 3 different copy protections atleast for SNES that I'm aware of. ROM Mirroring used in Mega Man X, and I think another or some other Capcom games. Some Copiers didn't mirror the ROM image or didn't do it properly which could be detected. SRAM size detection, some copiers mapped the full 64kbytes of SRAM reguardless of what the game actually contained. The GDSF7 has neither of these two problems.
The third is additional hardware in the cartridge like SA-1, Cx4, SuperFX, DSP1. ROM mirroring protection was used on few games, SRAM on more including very notable titles. I suppose this sucked for those backing up their own games or ones they rented or borrowed but for those that downloaded from BBS places they could easily get a patched/cracked one as the pirates from the Far East would surely do that, or someone else out there.
I totally agree, Flash memory cards for storage of ROMs and Saves are the way to go today.
I never had any of the copy protection screens come up on the GDSF7. I did have just a couple that froze at a black screen, but I patched them myself. It was a little challenging to combine a CD-ROM with their bizarre 2 or 3-letter filename convention (SF999xxx.078 or SF999xxA.078). And why the files need still need to be split to load all-at-once off a CD-ROM is something I don't even want to wonder about, heh. It's a pretty nice system though, other than that.
Flash is so much nicer, my only use for a floppy drives is because I was putting my .SRM/.BRM files there, and because I have an Atari ST with a floppy drive. The disks all fail miserably on everything.
That Quickdev16 would be a great alternative for any of these, if you're inclined to do development. Stuff like that, or an EPROM emulator, is more convenient for instant testing than anything else out there.
Memblers wrote:
I never had any of the copy protection screens come up on the GDSF7. I did have just a couple that froze at a black screen, but I patched them myself.
The SF7 shouldn't trip any copy protections unless you have a bad ROM image. You could purposely trip them by doing something like altering the internal rom information to change SRAM size or something.
The CD-ROM for the SF7 is something I really wanted but was always too expensive and then the SNES PowerPAK came out and it became irrelevant. Before it was expensive but useful with advantages over a laptop + parallel link. After SNES PowerPAK it couldn't compete.
These days the SF7 is still a great device but can be cumbersome to use.
whicker wrote:
Banshaku wrote:
It may be a little bit off-topic but related to the snes powerpak. I may have missed the reason in all the messages that was posted but want to know: what make it so hard to make the powerpak work on many snes revisions compared to the game doctor that seemed to work on any machine? I'm just curious.
Improper 3.3V to 5V CMOS logic level translation.
Lack of testing.
One-man design.
A focus on minimum component count versus a robust circuit.
Chinese CF Card chicanery.
Everyone's old decaying hardware.
I thought the problem was due to different SNES revisions using different brands/models of static RAM chips, causing timing issues?
Also, i'm curious to know if the issues mentioned above have been completely resolved now?
Link83 wrote:
whicker wrote:
Banshaku wrote:
It may be a little bit off-topic but related to the snes powerpak. I may have missed the reason in all the messages that was posted but want to know: what make it so hard to make the powerpak work on many snes revisions compared to the game doctor that seemed to work on any machine? I'm just curious.
Improper 3.3V to 5V CMOS logic level translation.
Lack of testing.
One-man design.
A focus on minimum component count versus a robust circuit.
Chinese CF Card chicanery.
Everyone's old decaying hardware.
I thought the problem was due to different SNES revisions using different brands/models of static RAM chips, causing timing issues?
Also, i'm curious to know if the issues mentioned above have been completely resolved now?
this is a reminder to myself to be more literal...
Some people got their PowerPak working after bunnyboy posted updated firmware for them to put onto it.
Some people got their PowerPak working by using a different CF card.
Some people got their PowerPak working by using a different SNES.
Some people still can't get it working no matter how hard they try.
As of the latest firmware, the SNES PowerPak should be working even with SNES jr / SNES mini's.
Did anyone ever get Pilotwings working on their PowerPAK? All other DSP1 games I tried (all those released outside Japan) seem to work fine with the PowerPAK with DSP1 upgrade.
Great Hierophant wrote:
Did anyone ever get Pilotwings working on their PowerPAK? All other DSP1 games I tried (all those released outside Japan) seem to work fine with the PowerPAK with DSP1 upgrade.
I'm wondering if figure 2-21-2 on page 2-21-3 of the you-know-what book wasn't taken into account.
There's a note stating that for mode 20 mapping when the program rom size is less than 8 megabits (probably meaning 4 megabits and under), the DSP is located at address $8000-$FFFF of banks $30-$3F
And I can see why that is... it's cheaper to use a 74139 than a MAD.
Hmm... Pilotwings worked just fine on my PowerPak (both with old and new mappers).
Strange question!
The same CF card,
The same SFC,
Work yesterday, but today doesn't work
lifeixie wrote:
Strange question!
The same CF card,
The same SFC,
Work yesterday, but today doesn't work
does the snes work with another cartridge?
does the CF-card work if you put it in your computer?
hyarion wrote:
lifeixie wrote:
Strange question!
The same CF card,
The same SFC,
Work yesterday, but today doesn't work
does the snes work with another cartridge?
does the CF-card work if you put it in your computer?
does the snes work with another cartridge?
NO，Also the SNES(PAL AUS)，Also the CF card
A few days ago can run
does the CF-card work if you put it in your computer?
PC--Access to the PC
Work well (CF card),
Cf card no fault
[/img][/url]
Have not gone mine to work either. I will see if my new Kingston 4GB CF card will do the trick. I tried turning DMA on and off and reformatting my card and tried it on 2 consoles. I can try another one but I will have to go toa mates place. The weird thing is my DSE 1GB CF card(rebranded A-DATA) worked fine on my PowerPak (NES) when I reformatted it as FAT32.
danntor wrote:
Have not gone mine to work either. I will see if my new Kingston 4GB CF card will do the trick. I tried turning DMA on and off and reformatting my card and tried it on 2 consoles. I can try another one but I will have to go toa mates place. The weird thing is my DSE 1GB CF card(rebranded A-DATA) worked fine on my PowerPak (NES) when I reformatted it as FAT32.
The Kingston fixed it by the way. Only tested the one game but it loaded and I could play it(U.N Squadron).
bunnyboy posted a mapper update on the nintendoage forums today. SRM auto loading is now supported.
Ah great news
.
Yeah, geat news ! I hated to have to load it manually.
The compatibility of host need to be updated
I got Pilotwings to work in my SNES by using a different CF card. The usual card is a SanDisk Ultra II 2.0GB. I tried it with a SanDisk 256MB and it worked perfect!
Does the SNES Powerpak work with the Pro Action Replay? I mean can I plug the Powerpak into an actual Pro Action Replay and use cheat codes with it?
I don't see why it wouldn't. All the PAR does it to overwrite parts of the SNES's RAM at a regular interval. It shouldn't matter if the game you're playing is on the PowerPak or on an original cartridge.
The AR might interfere with the PowerPAK. I know the NES one doesn't work through Game Genie or atleast I recall hearing that. The SNES PowerPAK may not work with AR or may only work with the MK3 model which connects the extra edge connectors used by chip enhanced games. But until someone trys there is no definitive answer I guess.
Anything electrical that sits between two devices changes the electrical properties of the connection, such as the setup and hold times, the capacitance, etc. For instance, look at
NES games that have to be patched on PowerPak because they rely on unofficial PRG data bus capacitance. Even if Game Genie or PAR can work with mask ROM chips without throwing the response time too far out of spec, that doesn't necessarily mean they can work with the RAM in a PowerPak.
Hi,
I want to play Star Ocean on my Power Pack, but I´m really out of luck. I´m really big beginner, when it comes to PC stuff, so I tried patch the rom and It still writes me error, when i tried to rewrite the code, that I could save the game, i really cant find those A081D5 numbers atc
Can´t you anybody send me working file, that i will copy on my ower pack and could play?
(My email
Tuuurek@centrum.cz)
Thank you very much for respond
Hello,
I have an SNES Powerpak, and I'm really happy with it so far, but I'm having the issue where Star Ocean won't save (it plays beautifully otherwise). I have the DeJap translated version 1.0, with the Neviksti patch applied, and I have patched the following locations:
0081D5: 32->31h
0081D6: 45->02h
A081D5: 32->31h
A081D6: 45->02h
But I still can't save!!!
When I go to save the game and say OK, the files still say No Data. The first three hours of the game were pretty awesome, so I really want to play the rest over the holiday break.
Can anyone help?
Greetings, fellow SNES PowerPak owners!
You might be interested to hear that I recently decided to work on a GUI overhaul. I started by using pseudo-hires mode and altering the font and text loading routines, which can now display up to 64 characters per line (useful for long filenames). This was achieved thanks to a programming trick first conceived by ikari_01, maker of the sd2snes. While I opted for a simpler way of doing it, a special second font was still needed as well as reassigning characters to two BG layers in order to compensate for Mode 5's 16x8 tile size limitation.
The current result, which of course works beautifully on real hardware too, looks like this:
Even though there's still a lot more to do (such as reworking the character-to-BG allocation algorithm in order to avoid flaws like the space in the CF error code), this gives you an idea what the new PowerPak user interface will look like. It might even be fully themeable later on!
Additionally, I'm planning to add more features and improve existing ones like the SPC player by hacking the mapper files, too. This of course will require hours and hours of work because disassembling and rewriting even mere chunks of code is a tedious and time-consuming process. However, as a huge fan of the SNES PowerPak since very early on, I really want to pull off a major software update, no matter how big the challenges.
@bunnyboy, in case you're reading this, please get in touch if possible.
Thanks for reading, and long live this awesome flashcart with the spot-on name, the
SNES PowerPak!
Ramsis
Very nice, keep up the good work.
I wonder how hard it'd be to make a variable-width font engine with a canvas made out of these 16x8 pixel tiles.
Well, cool, I'll definitely try this out when it's released.
Thanks, guys!
A few moments ago, I flashed the hacked firmware to my PowerPak in order to get on with testing and debugging. While things tend to look messy at first glance, the process greatly helped me understand how parts of the boot ROM seem to work:
Hmm ... no idea yet why the title and version string, and them only, get messed up with a CF card inserted, though. Maybe I'm still using a "forbidden" WRAM location for the second tilemap (i.e., one that gets overwritten somewhere else) ...
The file loading dialog. Apart from how one of Simba's paws was made cursor (:P), notice the two "%s" strings. They appear because unlike the backslash, stuff with a preceding percent sign isn't implemented in the new font routine yet. Anyway, it's a major breakthrough for me to have a better understanding about the way filenames are handled!
Until next time!
Hello! I recently purchased the SNES Powerpak and I really like it, but I'm having a few problems that I can't seem to find much information on.
1) Super Mario All-Stars. None of the rom versions I have tried seem to work with the PP. I can get past the main screen and select a Mario title, but after that the screen goes black. Sometimes I hear a sound effect or a theme from one of the levels during the blackness.
2) Zelda: A Link to the Past. No matter which version I try, the character name entry gets glitchy and when Link awakens in his bed there is a constant beeping sound like when you are low on hearts. When he gets out of bed, none of the buttons do anything except for the D-Pad and Pause. He cannon interact with anything. Weird.
3) Mega Man X. I've read that the sequels will not work with PP, but I cannot get the original to load very well. It's very glitchy and at times Mega Man simply slides across the screen rather than running/walking.
I'm having issues with several other titles that are not on the incompatible list, but those are the ones I'd like to get working first.
Any suggestions? I've gotten my NES Powerpak to work without any problems so it's strange that I am having trouble with the SNES counterpart. I am using an SNES mini, but according to the retrousb site that's a-okay.
Thank you so much for taking the time to read my post. In the meantime, I will reformat the memory card again and see what happens.
My thanks,
Error
@I_Am_Error, I would strongly recommend using another CF card (of a different brand, if possible). From my experience, the SNES PowerPak is especially picky about the type of CF card being used!
Regarding the new firmware I've announced, there's good news ahead!
I also finally got the filebrowser working:
As you can see, the only critical issue that remains to be fixed is BG1 tilemap clearing/rebuilding. Which is actually not
that much of an "issue."
On top of that, the routine that interacts with the CF filesystem doesn't seem to load more than ~26 characters of a filename at a time. Gotta fix that, too.
On a side note, the direction of fast scrolling (with the L and R shoulder buttons) is reversed when loading SRAM files, as many of you might have noticed already. Here's a quick-and-dirty fix for this:
- Open SB.MAP from the POWERPAK directory on your CF card with the hex editor of your choice
- Replace the byte at offset $97 [should be $10] with $20
- Replace the byte at offset $D3 [should be $20] with $10
That's it! With this mere two-byte-change, the SRAM L/R button behavior should match that of loading ROMs or GameGenie code TXT files (R = down, L = up).
Until next time!
Thanks, Ramsis! What is a good brand you would recommend? I've been using the one retrousb.com shipped with it (Dane). Would a faulty cf card still load some games great and some games... not so great?
I've looked at several different 1gb compactflash carts but do not know which brand works best with the SNES PowerPak. Thanks!
I_Am_Error wrote:
What is a good brand you would recommend?
SanDisk! Works great even with modded PowerPaks.
Thank you so much! I'll order one tonight! The local stores carried SD only.
Thanks, man! You've been very helpful! I placed an order from one just the other day and it should arrive in the mail sometime tomorrow.
Quick question. Would a buggy CF card allow some games to run perfectly and others to, well... barely run at all? Thank you again!
I_Am_Error wrote:
Quick question. Would a buggy CF card allow some games to run perfectly and others to, well... barely run at all?
As I said before, the SNES PowerPak can tend to be picky about the CF card type. My 4GB SanDisk card works fine most of the time. Small ROMs (<4 Mbit) often fail to load, while they do load and play just fine when using a 512 MB card. Strange, but that's how it is.
In your case though, I'd contact RetroZone support about why the card your PowerPak shipped with doesn't work (provided you're using verified good ROMs and the filesystem isn't corrupted, of course).
Good luck!
Thanks, Ramsis! I really appreciate you taking the time to help.
My SanDisk cf card arrived today. Its the same one you pictured, actually. I was very hopeful, but it simply didn't work. I couldn't get past the boot screen. The error message claimed there was on odd amount of space on the card. I reformatted it several times in two different computers and still had the same result. I followed the troubleshooting guidelines in the PP manual as well. It's a shame, but I may have a bad PowerPak. I have contacted retrousb and they have agreed to allow me to return the item. Right now I'm just waiting for them to send me their return mailing address. It's a shame, I really wanted to get this cart working.
I_Am_Error wrote:
It's a shame, but I may have a bad PowerPak. I have contacted retrousb and they have agreed to allow me to return the item. Right now I'm just waiting for them to send me their return mailing address. It's a shame, I really wanted to get this cart working.
Sorry to hear your PowerPak is faulty. At least you've got a reply from the support staff. I hope they'll sort things out for you!
Concerning the SIMBA firmware: Today I managed to fix the scrolling routine for BG1 and BG2. With this, my hack has reached early alpha state, and long-term testing/tweaking has begun. An official release doesn't seem too far from now!
Ramsis, do you have an ETA on a release? What will be the easiest way to update the firmware?
Thanks, Ramsis! I think the gentleman who sells the carts is a pretty cool dude. He was very polite to me when I explained my problem.
I_Am_Error wrote:
Thanks, Ramsis! I think the gentleman who sells the carts is a pretty cool dude. He was very polite to me when I explained my problem.
At least you got a reply. After about 6 months of trying to contact him via his website email, and several other sites, I was never able to get a reply. I finally just threw it in the trash as it was nothing more than a paperweight. Dudes a prick.
Can it support NES-style banks from 16k, 8k, or 4k depending on your created mapper instead of just 32k?
It also must be used in order for the bankswitch mapper for a certain pirate multicart to work, ''20-in-1 Super 20 Collection'' is availible at D4S's website:
http://dforce3000.de/
Hamtaro126 wrote:
Can it support NES-style banks from 16k, 8k, or 4k depending on your created mapper instead of just 32k?
It also must be used in order for the bankswitch mapper for a certain pirate multicart to work, ''20-in-1 Super 20 Collection'' is availible at D4S's website:
http://dforce3000.de/IIRC I did try that 20in1 collection, it did not work
Jagasian wrote:
Ramsis, do you have an ETA on a release? What will be the easiest way to update the firmware?
Thanks for asking!
At this time, I can't give you a definite release date yet. I'm currently working my way through bunnyboy's code (and heaps of FAT16/32 documentation) in order to have the new filebrowser load and display 52 characters per entry. Didn't think there was a challenge like this lying ahead when I began, whew! But I do think I'm getting there, albeit slowly.
Concerning the actual firmware update, two steps will be required, the first (and easy) of which will be to replace the mapper files on your CF card. The second will involve one of two possible actions:
1) You screw open your PowerPak and reflash the boot ROM chip (if it is socketed) with a PLCC32 programmer. This is how I'm doing all my testing, btw.
-- or --
2) You put the new loader ROM file on your CF card and invoke a self-flashing process. This will likely be the only way to update your PowerPak at all if you have a newer board revision (look inside the CF card slot and check the printing on the PCB, mine says "8/9/09 revD"). According to bunnyboy, self-flashing was never tested (and thus, maybe not even fully implemented). I'll investigate.
In the meantime, here's a shot of the boot screen cleanup I did today:
The new filebrowser now loads up to 128 LFN characters per entry, 52 of which it can actually put on screen. Additionally, the text routine automatically adds indentions at the top and left:
This wasn't by far as trivial as it might look (and it doesn't work completely bug-free yet, either). But as long as it doesn't break ROM loading -- which it did until very recently -- there's no reason to be worried.
wow, that's amazing work Ramsis! Can't wait to test your finished work!
Thanks, keropi!
Big update today:
The filebrowser now works completely bug-free. As suppressing garbage text at the top and bottom of the screen turned out to be a pain in the neck, I taught myself how to use HDMA and created a "window", which simply masks anything unwanted out. Works like a charm!
While I was at it, I also added a nice gradient HDMA background color table. Those few lines with the wrong color will hopefully yet be fixed. Meanwhile, have another look at the boot screen:
Until next time!
Thanks!
With some minor adjustments to the HDMA table I did yesterday, it looks still better (and even more so in reality, dunno why all my camera shots suffer from overexposure):
Today, I fixed entering of GG codes (which had been broken by the automatic indentions) and added a nice mosaic effect to the boot sequence.
More to come!
Ramsis wrote:
Thanks!
With some minor adjustments to the HDMA table I did yesterday, it looks still better (and even more so in reality, dunno why all my camera shots suffer from overexposure):
Today, I fixed entering of GG codes (which had been broken by the automatic indentions) and added a nice mosaic effect to the boot sequence.
More to come!
Million-dollar question: When do you plan to release this?
It looks much better with the HDMA effects.
I also hope the cursor will move incrementally and not SLOWLY move pixel by pixel like it does right now. And I know you can make it faster with the left and right buttons but it's still way to SLOW.
Also, enabling the use L/R to skip pages would be very useful.
Eyedunno wrote:
Million-dollar question: When do you plan to release this?
Soon!
As of now, v2.00-alpha3 appears to work great. There are still a few things I'd like to fix, though. For example, (...)
EDIT: HDMA seems to be fixed for good in alpha4, but! (Read on further below ...)Bregalad wrote:
It looks much better with the HDMA effects.
I also hope the cursor will move incrementally and not SLOWLY move pixel by pixel like it does right now. And I know you can make it faster with the left and right buttons but it's still way to SLOW.
Also, enabling the use L/R to skip pages would be very useful.
Thanks for the input! I've thought about that before, too. Unfortunately, this would mean to totally rewrite the whole scrolling routine. I haven't actually decided about that yet but as I know myself, I might definitely be struck by sudden ambition and - just do it!
EDIT August 4th:Dammit! The more I delve into this, the more critical bugs pop up that already plagued the official release. Here's a list of crashes I've found so far. All of these can be reproduced with boot ROM v1.02 and card mappers v1.05 (beware of potential CF data loss
):
- Browse to a ROM file and press Select --> immediate crash!
- From the intro screen, press A and then Start again to return there. Repeat this another ~44 times --> crash!
- With LASTSNES.TXT filled (i.e., at least one game has been loaded previously with success), press Start on the intro screen and then Start again to return there. Repeat this another ~36 times --> crash!
Fortunately, I have an idea about how to fix all of these for v2.00. Still a long way to go, though!
But let's not get carried away and instead just continue to try and improve things that deserve it.
Until next time!
Don't worry, I feel like it'll be worth the wait for the fully fonctional version.
I understand you're hesitant to rewrite the whole scrolling routine, but really it would be better to have the cursor move an entire line at a time. Pretty much all games do it this way.
Also by the way it would be great to scroll the whole thing a few pixels to the right, because you know, on PAL TV screens the leftmost ~4 pixels are hidden, and this makes the cursor looks cropped and it looks weird.
So, your updates would require a firmware update? Have you looked into how the firmware update could be done in-system? I remember bunnyboy mentioning it should be possible.
Bregalad wrote:
Also by the way it would be great to scroll the whole thing a few pixels to the right, because you know, on PAL TV screens the leftmost ~4 pixels are hidden, and this makes the cursor looks cropped and it looks weird.
True, and already done.
Here, this should make keeping track of my progress easier:
http://www.manuloewe.de/snestuff/powerpak/firmware-v2.00-changes.txtthefox wrote:
So, your updates would require a firmware update? Have you looked into how the firmware update could be done in-system? I remember bunnyboy mentioning it should be possible.
Apart from replacing the CF modules, my custom firmware will definitely require a boot ROM update.
Since later versions of the SNES PowerPak seem to have a non-replaceable flash chip installed (which I don't know for sure but could only deduce from the scarce information bunny gave me in his one, and only ever, e-mail reply), I will certainly investigate whether reflashing from CF card is possible. The easier the upgrade can be performed, the better, I guess.
By the way, should anyone here have a PowerPak revision other than "D", please let me know - pictures appreciated (no need to open up your PowerPak, just remove the CF card and have a look at the printing on the PCB).
Mine's a revD, with socketed boot ROM. The picture was taken before I replaced the CIC chip with a SNES CIClone:
I have a RevE. 2/23/10,
Quote:
Apart from replacing the CF modules, my custom firmware will definitely require a boot ROM update.
Does this mean that the upgrade isn't available to us mere mortals?
I don't have an SNES PowerPak, but the flash chip should be hooked like the same as a RAM chip would be (with a /write signal connected). I've uploaded some code that works with an AMD flash chip, I'm sure it would work on SNES with the Atmel flash chip with little (if any) modification.
http://membler-industries.com/nes/flash.asm
Thanks, guys!
shawnleblanc wrote:
I have a RevE. 2/23/10
Very interesting. When looking through the transparent casing at the back of your PowerPak, are you able to tell how the ROM chip is most likely mounted (e.g., with a socket or without)?
@tepples, you too might want to check this since there might even be different sub-revisions around. Thanks in advance!
Memblers wrote:
Wow, thanks for sharing, Memblers!
I must admit though that I have no clue how to actually approach and implement a self-flashing update (especially as a newbie programmer and without any proper PowerPak hardware documentation), but this might definitely help me getting started.
Ideally, a revised firmware would just chain-load the new firmware version from CF if present. Or what makes that hard?
Quote:
Very interesting. When looking through the transparent casing at the back of your PowerPak, are you able to tell how the ROM chip is most likely mounted (e.g., with a socket or without)?
Here's what I have (click for larger image):
tepples wrote:
Ideally, a revised firmware would just chain-load the new firmware version from CF if present. Or what makes that hard?
I'm not the kind of guy to ever present "ideal" solutions. Just better ones (hopefully).
shawnleblanc wrote:
Here's what I have (click for larger image):
Thanks a bunch for the picture, shawnleblanc! As far as I can see, there shouldn't be any major problem with updating your PowerPak (but that's no promise, of course).
Ramsis wrote:
Memblers wrote:
Wow, thanks for sharing, Memblers!
I must admit though that I have no clue how to actually approach and implement a self-flashing update (especially as a newbie programmer and without any proper PowerPak hardware documentation), but this might definitely help me getting started.
The main thing to consider is that you won't be able to use the ROM for anything during the detect (auto-select) and write commands, and (obviously) immediately after it's erased. So don't forget to disable NMI and IRQ. Any needed code that would normally be in the ROM, you would assemble an alternate version of it with the origin at a location in RAM. Then copy it into RAM before running it.
Ramsis wrote:
tepples wrote:
Ideally, a revised firmware would just chain-load the new firmware version from CF if present. Or what makes that hard?
I'm not the kind of guy to ever present "ideal" solutions. Just better ones (hopefully).
And a chain-loader would make it easier to test and install better and better solutions as time progresses.
I have just bought a SNES PowerPak this week for use on my Super Famicom. I have spent all day trying to get it to work, but nothing loads. I just get the black screen of death every time. I read in lots of places that it works with the Super Famicom, but now I am wondering if (U) Roms do not work at all? I also couldn't get any (J) Roms to work either though.
I have the latest firmware as of August 2012 and have copied over a selection of Roms. Whereas on the YouTube videos when they pick a game it boots up, on my one everything just goes black, and it stays that way for 15 minutes before I turn it off.
I am pretty sure the PowerPak is ok because the first screens load. The Super Famicom works with normal cartridge games. I thought the Roms might be regionally locked, but: a) I thought this wouldn't be an issue; and b) as I said, even (J) Roms do not work. The CF card (2GB) came with the PowerPak.
I think I really need some help off someone who has a Super Famicom and a SNES PowerPak. If you could please share your experiences of it, that would be most welcome. Thank you in advance.
Did you put the CF card in your computer to load your own files before trying it or did you try it with any preloaded files? I've heard some problems are related to the CF Card reader doing something that the PowerPAK doesn't like. You could try using a different CF card interface, different PC, etc to put the roms on the CF card and you may have better luck. The Super Famicom can play (U) and (J) roms just fine.
MottZilla wrote:
Did you put the CF card in your computer to load your own files before trying it or did you try it with any preloaded files? I've heard some problems are related to the CF Card reader doing something that the PowerPAK doesn't like. You could try using a different CF card interface, different PC, etc to put the roms on the CF card and you may have better luck. The Super Famicom can play (U) and (J) roms just fine.
Hi, thanks for the prompt advice. I have tried preparing the files from XP and 7, but it did not make a difference. The error message I get is:
No internal Header found
Trying again with fixed header
MAP20 TYP20 ROM31 SRM00 RSTFF86D9
No $FFC0 Header
MAP40 TYP00 ROM00 SRM00 RSTFF80
0KB SRAM Added
LoROM 24Mbit
0 1 2 3 4 5 6 7 8 9 A B C D E F
2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7
2 4 2 5 2 6 2 7
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
This was for Mortal Kombat 2.
Hi!
ferretingaround wrote:
Hi, thanks for the prompt advice. I have tried preparing the files from XP and 7, but it did not make a difference.
In addition to MottZilla's advice, I'd recommend trying a different brand of CF card and/or reformatting your CF card (with FAT32) and/or reorganizing your files in such a way that the "POWERPAK" system directory is at the beginning of the file system (i. e., copy the system directory to your empty card first, and only then start adding ROM directories). Also, you could try setting DMA=0 in CONFIG.TXT. Though I doubt it'll actually make much of a difference, it's still worth a try.
Meanwhile, I'm proud to announce that the SPC player has been redesigned - apart from the cool fact that it now actually
works, too!
(Thanks, blargg!)
Another fact worth mentioning is that v2.00 works flawlessly on 1/1/1 systems (no HDMA <> DMA crashing!). Here's a shot of my beloved 1990 Super Famicom passing the SDRAM test:
Until ... soon!
ferretingaround wrote:
No internal Header found
Trying again with fixed header
MAP20 TYP20 ROM31 SRM00 RSTFF86D9
No $FFC0 Header
MAP40 TYP00 ROM00 SRM00 RSTFF80
0KB SRAM Added
LoROM 24Mbit
0 1 2 3 4 5 6 7 8 9 A B C D E F
2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7
2 4 2 5 2 6 2 7
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
GG-> $00000 = $00 code unused
This was for Mortal Kombat 2.
This shows the game was detected wrong because while it is 24mbit, it is HiROM not LoROM. Try formatting the CF card to Fat 32, try using a different CF Card Reader. It does appear like it is having CF card problems and the PowerPAK itself should be ok.
Big thanks to Mottzilla and Ramsis!
I tried an Integral 1GB CF card, formatted in FAT32, and then systematically added the Roms.
It worked, so I am well pleased now.
Cheers!
I'm glad you got the issue worked out. It must be a relief to have it working now.
Yes, the powerpak is excellent, thanks!
My next question, and I'm sorry if this is already covered, is about loading saves.
With Mario Kart it works fine. With some other games, not so. Is it the case that any given game needs to support battery back-up in order for the save to work? Can the powerpak save states like on an emulator?
I've spent an hour reading online but haven't found anything definitive. Seems states can now be saved on NES version, but not yet SNES. Thank you
SNES PowerPAK doesn't support "save states". Only normal game saving is supported.
Not to worry, it's still an amazing piece of kit.
The problem with implementing realtime save states on the SNES is that getting the internal state of the entire system is quite difficult, if not impossible. For example, the S-CPU doesn't have direct access to the SPC's RAM (or the S-SMP state for that matter). And the situation is even worse with the PPU and DMA controller as some of their registers are write-only AFAIK.
I began looking into implementing this feature on a different flash cart a year or two ago, and quickly came to the conclusion that it just wouldn't work. It would've been cool if it was possible though - it's a feature I appreciate a lot when playing GBA games with the Supercard.
mic_ that explains it well, thank you. Otherwise, I am very impressed with the PowerPAK so far.
I spent last weekend playing Mottzilla's cut of BS Zelda through the PowerPAK, which worked very well. Having never played the original Zelda, the 16-bit make-over was the pleasure to play through, a true work of art.
Got me thinking that a 16-bit version of the original Metroid, in the style of Super Metroid, would also be amazing (if unlikely to ever happen).
ferretingaround wrote:
Got me thinking that a 16-bit version of the original Metroid, in the style of Super Metroid, would also be amazing (if unlikely to ever happen).
Would it look like Metroid Zero Mission?
Agreed. Play Metroid Zero Mission. It's awesome.
I've completed Metroid 2 and 3 and the Prime Trilogy, which were all awesome. (I tried Other: M but was horrified, it just felt wrong in every respect).
I think I'll hunt down the two GBA games (and a GBA) since they were both highly rated.
tepples wrote:
ferretingaround wrote:
Got me thinking that a 16-bit version of the original Metroid, in the style of Super Metroid, would also be amazing (if unlikely to ever happen).
Would it look like Metroid Zero Mission?
Cool, now if we only could find out how the in-system flashing of the firmware works (if it does at all).
awesome news!!!but I am unsure of how to proceed , this is my powerpak:
do I still need to get the SST chip out and program it?
I pray for hot flashing to work - cause I don't have tools to reprogram this PLCC flash-ROM, and adapter would be required.
thefox wrote:
Cool, now if we only could find out how the in-system flashing of the firmware works (if it does at all).
True, I too would love to see an easy-to-use flash updater.
Actually, I've been looking into this for quite some time now. The good news is that I have a plan on how to proceed, and that my routine to upload code to WRAM and execute it from there works fine so far. With Memblers' flash routines around, in theory the whole issue shouldn't involve more than compiling a ROM ... and some (or heaps of) trial and error.
However. (What follows should answer your question too, keropi.)
I haven't gotten the flash chip to "respond", even after modifying the routine to fulfill the 29C010's datasheet specs, and with neither of the following two different approaches:
1) Compile a standalone ROM and load it from CF like a normal game --> no success (any writes to the specified addresses [whether they be converted to SNES LoROM addresses or not] just reach SDRAM, which the PowerPak maps to the A bus on game start, and reads simply return SDRAM content/open bus)
2) Compile a special mapper file and load it while the flash boot ROM is active (and thusly mapped to the A bus) --> no success (any writes to the specified addresses [whether they be converted to SNES LoROM addresses or not] are seemingly ignored, and reads simply return boot ROM content)
So, either the flash ROM doesn't have its write signal line connected on revision D PowerPaks (very likely since the chip is socketed anyway), or ... I did something wrong. But without newbie-friendly documentation, hardware schematics, or even previous experience in flash programming, there's not much I can do, I'm afraid.
For everyone without a PLCC32 programmer, there's still the option of asking RetroZone staff to reflash your PowerPak, and - provided they agree - sending it back their way:
RetroZone wrote:
The boot ROM is socketed for easy reflashing but this will hopefully never be needed. If it is needed and you do not have a programmer, you just pay the shipping to get your SNES PowerPak here and I will reflash then mail it back free.
sourceSo yeah: I'm sorry and really hate to admit it, but if you don't have a programmer (and a revD/revE PowerPak with socketed boot ROM), you're pretty much stuck with v1.0X as of now.
Otherwise, you (carefully!) remove the ROM chip from its socket, reflash it with the BIN file from my release, reinsert it, and have fun.
Sorry again! And rest assured that I still haven't given up completely on getting a flash updater done.
Oh it sounds like I should really look to borrow a PLCC32 adapter form someone. If only I know someone who has one...
thanks for the answer Ramsis
I seem to remember somewhere that one can use a tool called uniflash in DOS , put the flash chip in a NIC card or something and flash the code... can't remember the details or maybe the whole thing is a fragment of my imagination
I also remember reading somewhere that retrousb did put an easy way to update the flash... but can't find it...
I was sent this link by keropi as he asked about me flashing his chip (as I do this type of thing on another forum).
I have a high end programmer and the required adapter.
If anyone wants their chip reflashing, they can send it to me and for a £0.50p fee + return shipping I will do it for you.
If Ramsis were to give me permission - I could offer preflashed chips for a (semi?) decent price. Quotes I have been given would suggest probably £3 per chip + shipping and would be preflashed.
awesome, Bad_Ad84 and his great services are here
welcome!
I got rid of my SNES PowerPak recently for an SD2SNES, however I would love to see this new version of the screen in action. Could someone post a video on Youtube of going through the titles screens and game lists.
thank you
^ I kept the PowerPak and got the sd2snes too
, I would love to see more shots/video too!
Bad_Ad84 wrote:
If Ramsis were to give me permission - I could offer preflashed chips for a (semi?) decent price. Quotes I have been given would suggest probably £3 per chip + shipping and would be preflashed.
Sure, I don't mind people selling pre-flashed chips.
At the same time however, I would generally advise against paying money for this, folks. Remember that this is still beta software (i. e., updates are bound to follow), plus there's still the chance of a user-friendly flash updater to show up.
Oh, and don't forget that installing custom/unofficial software on your PowerPak might void your Retrozone warranty. Just thought I'd mention this, too.
The vibe I got from keropi was - keep the original chip, so you can always revert. Mess about with a replacement (preflashed), if it needs updates, they could send it back to me or wait for a flasher from you and wouldnt be without a working powerpak.
Either way, it means you have the original to fall back on.
I dont intend to sell a lot, I also do not intend to profit from your work (hence asking for permission). Its pretty much cost (+ a very small profit for fronting the money I may never get back) + flashing fee.
yep, play with a 2nd chip and have the original as a fail-safe... TBH 3GBP for a preflashed chip is not that big of a deal, I couldn't even find an empty chip for that money
but ofcourse to each their own
I can vouch for bad_ad84, he's a stapple of racketboy's Assemblergame's forum and supply user with modified Saturn or Dreamcast bios chip along with plenty of other similar thing for barely the price of a chip and shipping. I highly doubt he's making much at all and give a very valuable service to peoples. I got a modified Saturn and dc bios chip from him and I paid less than the price of blank chip on ebay.
assemblegames, not racketboy
I do have an account at racketboy, but dont really post there much.
and thanks for the kind words
Oh sorry, I ment assembler game! For some reasons I always mix those 2 website:)
Anyway, the new firmware look very nice, if only there was something similar for the NES Powerpak, wink, wink!
The new 2.00-beta1 firmware is awesome! Thanks Ramsis! But I have a question about the .spc player. Is there some trick to make it play a full directory of .spc files? Seems like it just plays the file that is first and repeats until forever. And the only way to get the next spc is to reboot the system and select another file. Am I doing it wrong?
Thanks, Marvin!
Marvin wrote:
But I have a question about the .spc player. Is there some trick to make it play a full directory of .spc files? Seems like it just plays the file that is first and repeats until forever. And the only way to get the next spc is to reboot the system and select another file. Am I doing it wrong?
Unfortunately, there is no easy, generic way to "reset" the SNES' sound processor and have it play a new song. AFAIK it isn't even possible e.g. to fade-out a playing SPC file without deeper knowledge about how its specific sound engine works (plus, you'd basically need some kind of custom "hack" for it).
Thus, it is inevitable to reset the SNES in order to stop the current song and be able to load a new SPC file.
On a side note, I'm still working to improve the filebrowser - now it's possible to hold up or down for fast "digital" scrolling after a short delay. Also, the SDRAM check can now be aborted. Stay tuned for beta 2!
nice!!
I assume beta2 is a software update on the CF card right?
keropi wrote:
nice!!
I assume beta2 is a software update on the CF card right?
Yes, and a bootloader flash ROM update, too.
I have moded my 1CHIP snes with ikari01's goodies: IGR + SuperCIC + 50/60hz switch... Everything seems to work fine but the powerpak in NTSC mode does not work, it does not load roms, it always complains they are missing the header... switch to PAL mode and everything works perfect - switch to NTSC mode and you get card initialization errors and/or the no-header error.
Is this a known problem or I have something wrong?
Quote:
Thus, it is inevitable to reset the SNES in order to stop the current song and be able to load a new SPC file.
Didn't the original SNES PowerPak menu stop the currently playing SPC and jump back to the startup screen when you pressed some key on the gamepad (START or SELECT or something)? I guess it was just triggering a reset of the entire system somehow, but it was still convenient because you didn't have to walk over to the SNES and press the RESET button.
keropi wrote:
I have moded my 1CHIP snes with ikari01's goodies: IGR + SuperCIC + 50/60hz switch... Everything seems to work fine but the powerpak in NTSC mode does not work, it does not load roms, it always complains they are missing the header... switch to PAL mode and everything works perfect - switch to NTSC mode and you get card initialization errors and/or the no-header error.
Very strange indeed. Does/Did this happen with firmware v1.0X as well?
mic_ wrote:
Didn't the original SNES PowerPak menu stop the currently playing SPC and jump back to the startup screen when you pressed some key on the gamepad (START or SELECT or something)?
Yeah, press Start while an SPC is playing and you'll be taken back to the intro screen via soft reset. (This was not changed at all.)
@Ramsis:
I forgot to mention I am using the original 1.05 firmware, I don't have yet a flash chip with your rom....
It's coming ... and it's gonna be ... grand! (
No kidding!)
Sweet, I wish I still had my PowerPak just so I could play around with this.
Ramsis do we have a rough ETA on the new menu? I am still holding back receiving my updated bios chip since I want it to have the latest version on it
keropi wrote:
Ramsis do we have a rough ETA on the new menu? I am still holding back receiving my updated bios chip since I want it to have the latest version on it
Depends on how many critical bugs I may yet encounter. Despite ~110 downloads of beta 1 so far, I'm pretty much on my own with all the testing. And my testing is thorough! So, just a few more days until the release of beta 2, I guess. It will happen before December, that's for sure!
I have eventually be able to reflash my BIOS, and I must thank you VERY VERY much Ramsis !!
This is makes the thing, way, way better than the original Super PowerPak. Now the only shame is that this can't be done with the NES power pak as well
Also, I can recognize Kirby's Dream Land in your music, but I haven't recognized anything else. You probably didn't took music of TRUE classics
very nice Ramsis!
awesome work!
is the BIOS revision stabilized now or we need to flash every time? I am kinda holding back on this because I need someone else to flash my BIOS, it would be great to only having to flash one time
Hi!
Bregalad wrote:
I have eventually be able to reflash my BIOS, and I must thank you VERY VERY much Ramsis !!
This is makes the thing, way, way better than the original Super PowerPak.
Thanks a lot for the positive feedback! Glad to see other people happy about how this project has turned out so far.
Bregalad wrote:
Also, I can recognize Kirby's Dream Land in your music, but I haven't recognized anything else. You probably didn't took music of TRUE classics
Hehe, I agree one could argue about that.
keropi wrote:
very nice Ramsis!
awesome work!
is the BIOS revision stabilized now or we need to flash every time? I am kinda holding back on this because I need someone else to flash my BIOS, it would be great to only having to flash one time
Thanks! Well, beta2 is pretty stable already, so I can only encourage any PowerPak user to give it a try. Apart from that, development will continue as long as there is room for improvement.
I have a revD (8/9/09) with what appears to be a socketed firmware chip. Will I have to buy my own programmer to upgrade, or will pre-programmed chips be available once this is done?
Either way, is there a chance for some sort of "autoexec" feature in the firmware so that future upgrades can be stored on CF?
I have rev D as well. So just grab a 29C010 PLC32 chip and program it and swap them out? Might have to try it. It certainly looks appealing.
tepples wrote:
I have a revD (8/9/09) with what appears to be a socketed firmware chip. Will I have to buy my own programmer to upgrade, or will pre-programmed chips be available once this is done?
Thanks for reporting!
At the current time, I'm afraid you'll have to either buy a programmer or find someone to re-flash the chip for you. Unfortunately, I don't think I'll ever be able to provide pre-programmed chips. Maybe you should consider sending your PowerPak bunnyboy's way asking him to re-flash it for you? (Granted, he probably won't as he can't easily provide any kind of warranty on unofficial software.)
tepples wrote:
Either way, is there a chance for some sort of "autoexec" feature in the firmware so that future upgrades can be stored on CF?
Sorry, no news on self-flashing so far.
As
mentioned earlier, I didn't get far with preliminary tests. I'd love to try with a newer revision (where a write line may be connected) but can't afford buying yet another PowerPak just to have a stab at it, especially considering the likely situation that it won't work either.
MottZilla wrote:
I have rev D as well. So just grab a 29C010 PLC32 chip and program it and swap them out? Might have to try it. It certainly looks appealing.
Thank you!
Ramsis wrote:
tepples wrote:
Either way, is there a chance for some sort of "autoexec" feature in the firmware so that future upgrades can be stored on CF?
Sorry, no news on self-flashing so far.
As
mentioned earlier, I didn't get far with preliminary tests. I'd love to try with a newer revision (where a write line may be connected) but can't afford buying yet another PowerPak just to have a stab at it, especially considering the likely situation that it won't work either.
Forget all that.
Just today, I got my revD's flash chip to respond on the very first try!
Code:
sei ; disable NMI & IRQ
stz $4200
lda #$AA ; software product identification entry (AT29C010A)
sta $00D555 ; $5555 + $8000
lda #$55
sta $00AAAA ; $2AAA + $8000
lda #$90
sta $00D555
jsr Wait10ms
lda $008000 ; manufacturer code (should be $1F)
sta v1UpdTemp
lda $008001 ; device code (should be $D5)
sta v1UpdTemp+1
lda #$AA ; software product identification exit
sta $00D555
lda #$55
sta $00AAAA
lda #$F0
sta $00D555
jsr Wait10ms
; -- v1UpdTemp printing stuff removed for a clearer view --
lda #$81 ; VBlank NMI + Auto Joypad Read
sta $4200 ; re-enable VBlank NMI
cli
Now there are just a few more hurdles to overcome - like writing routine code that's backwards compatible with v1.0X, loading and buffering the update file somewhere, and, most importantly, fully understanding and correctly implementing the flash routines Memblers was kind enough to share. If all works out as planned folks, upgrading your v1.0X PowerPaks in the future might be as easy as copying some files to your card, waiting for the automatic flasher to complete, and play.
I'll keep you posted!
This is too good! I'm stuck on beta1 I flashed on a friends flasher, but don't want to bother him again. And I'm on rev D too
Is it possible to arrange the firmware update so that there's a recovery method if the system happens to lose power during flashing, such as automatically loading autoexec.sfc if A+B+Select+Start is held at power on? Compare what FlashMe on DS does.
Thanks, guys.
I'm happy to announce that the automatic v1.0X updater for PowerPaks with the AT29C010A chip is practically finished. I successfully completed and tested the code this evening, first using v1.02 and then v1.03b1 (which my unofficial release is based upon) as a base. Takes hardly three seconds to update, and what's best is that my implementation is as user-friendly as possibly imaginable. Just load the new mapper folder onto your card, expect yourself prompted to update, and presto: The SNES reboots running the new firmware. No need even to reload another set of CF mappers!
What's now left to do is to write an alternative programming routine suitable for the SST39SF010 chip, which most revE PowerPaks seem to have installed. Since I don't have this chip available to test, it doesn't make much sense to start on this yet. (The AT29C010 is programmed on a 128-byte sector basis, while a quick glance at the SST39SF010's datasheet reveals that it is programmed on a byte-by-byte basis.) What I also feel compelled to do is support "early adopters" (i.e., beta1 and beta2 users) by further enhancing the new update module (SU.MAP).
Another thing worth mentioning is that I've currently no knowledge whatsoever about what kind of flash chip(s) PowerPaks newer (?) than revE ship(ped) with. To even hope for eventually supporting those, I can only rely on people willing to share PCB photos of their carts. (Is there anyone out there at all who possesses a PowerPak with a non-AT29C010, non-SST39SF010, and/or non-socketed boot ROM?)
tepples wrote:
Is it possible to arrange the firmware update so that there's a recovery method if the system happens to lose power during flashing, such as automatically loading autoexec.sfc if A+B+Select+Start is held at power on? Compare what FlashMe on DS does.
Definitely not, due to the way the PowerPak hardware is designed. Very different from a Nintendo DS.
But whoever requires an all-or-nothing flash gaming solution (like myself) is heartily invited and encouraged to buy an
sd2snes. Those are
really great! I use mine for casual gaming, and MSU1-related projects. Like!
Ramsis wrote:
What's now left to do is to write an alternative programming routine suitable for the SST39SF010 chip, which most revE PowerPaks seem to have installed. Since I don't have this chip available to test, it doesn't make much sense to start on this yet. (The AT29C010 is programmed on a 128-byte sector basis, while a quick glance at the SST39SF010's datasheet reveals that it is programmed on a byte-by-byte basis.) What I also feel compelled to do is support "early adopters" (i.e., beta1 and beta2 users) by further enhancing the new update module (SU.MAP).
Cool stuff! My revE has SST39SF010, so I hope that will be eventually supported as well.
For the brave amongst you, here's my preliminary, tested working but nevertheless TOTALLY BLEEDING-EDGE, SNES PowerPak Flash Updater to try out!
WARNING !!!
ONLY use this ...
- ... if your SNES PowerPak has a SOCKETED (i.e., externally reprogrammable) AT29C010A type of flash ROM chip!
- ... with your SNES PowerPak connected DIRECTLY to your UNMODIFIED SNES (i.e., NOT using additional hardware like e.g. a "T-adaptor", GameGenie, Action Replay, and/or Ultra16)!
- ... if the CF card you're using has proven to work FLAWLESSLY, without glitches or errors, with your SNES PowerPak!
- ... if you aren't afraid of (in the worst case) turning your SNES PowerPak into a very expensive paperweight!
- ... AT YOUR OWN RISK !!!
That said (please excuse the rudely formatted warning above), I might add that I've tested the updater countless times on my revD PowerPak, with previous boot ROM versions of v1.02, v1.03B1, v2.00-beta1, and v2.00-beta2, and using various SNES console revisions (2/1/3 US unmodified, 2/1/3 1CHIP PAL, 1/1/1 SFC unmodified), each time with success.
To initiate the updater, just copy the POWERPAK directory contained within the archive to your CF card, overwriting all (!) existing files in the process (while preserving the contents of your SAVES directory of course, if applicable). Once you power up your SNES PowerPak, you will be prompted to update (given that your setup meets the requirements). If you receive an error message, you'll have to revert back to your previous mapper set for now. If successful, your SNES will restart within seconds, showing the new PowerPak boot screen.
Don't forget to let me/us know if it worked!
So without further ado, here it is:
http://www.manuloewe.de/snestuff/powerpak/preliminary_flash_updater.7zGOOD LUCK!
(AND DON'T BLAME ME IF YOU BRICK YOUR VALUABLE POWERPAK !!!)
It would be a possibly good idea to have the earliest code be some sort of primitive recovery mode, comparable to FlashMe from the old NDS days, should anything go wrong later in the writing process.
tepples wrote:
FlashMe on DS
Definitely not, due to the way the PowerPak hardware is designed. Very different from a Nintendo DS.
Video of the upgrade procedure, made by a cool guy who helped testing beta 1 (thanks again, pal!
):
http://www.youtube.com/watch?v=LB7CZOA-0Hk(ROM loading issues toward the end are likely card-related, BTW.)
How do you switch SPC music playing? Manual reset by human? PowerPak controls the /RESET line so it can do it? It would be interesting if it remembered that you were playing an SPC so when you press reset/it asserts reset, it restored where you were browsing music, which would also allow it to do an SPC playlist.
blargg wrote:
How do you switch SPC music playing? Manual reset by human? PowerPak controls the /RESET line so it can do it?
The latter.
blargg wrote:
It would be interesting if it remembered that you were playing an SPC so when you press reset/it asserts reset, it restored where you were browsing music, which would also allow it to do an SPC playlist.
Yeah, that'd be nice. Actually, that's the way e.g. sd2snes does it: Press A to play an SPC, and B to "stop" playing and return to the folder you were just browsing. Only a very brief screen flicker indicates at all that a cartridge-triggered console reset is involved.
For similar convenience on the PowerPak, I'd probably have to change the software design completely (sigh) for maximum performance. The good thing is that I have an in-system flasher working now. So in theory, anything might be possible in the future.
As for detecting a software-initiated reset, you need some flag that reliably is one value at power or after a normal reset, and some different value after a software-initiated reset. This could be some register on the cartridge, or RAM in the SNES matching some value that it's extremely unlikely to have normally. Then the boot code just needs to check this flag and restore where it was in the SPC playback. Main question is whether anyone wants to use their SNES as an SPC jukebox (with abrupt endings to songs, rather than fades).
Ramsis wrote:
What's now left to do is to write an alternative programming routine suitable for the SST39SF010 chip, which most revE PowerPaks seem to have installed. Since I don't have this chip available to test, it doesn't make much sense to start on this yet. (The AT29C010 is programmed on a 128-byte sector basis, while a quick glance at the SST39SF010's datasheet reveals that it is programmed on a byte-by-byte basis.)
I hope you'll consider buying SST39SF010 at some point, it's only a couple of bucks:
http://www.digikey.com/product-detail/e ... ND/2297825. Or maybe you can get bunnyboy to send you one.
I'm a little confused. Do we just need the 7z file to do the update and have the right firmware, or do we need the file you have linked in your signature too?
blargg wrote:
As for detecting a software-initiated reset, you need some flag that reliably is one value at power or after a normal reset, and some different value after a software-initiated reset.
Yeah, I know. Unfortunately, the current software design is completely incompatible with this approach.
thefox wrote:
I hope you'll consider buying SST39SF010 at some point, it's only a couple of bucks:
http://www.digikey.com/product-detail/e ... ND/2297825. Or maybe you can get bunnyboy to send you one.
I'll definitely add support for the SST39SF010 chip some time in the future. Product identification is actually already implemented (should return an error message).
MottZilla wrote:
I'm a little confused. Do we just need the 7z file to do the update and have the right firmware, or do we need the file you have linked in your signature too?
Just the 7-zip file. (Beta 2 is older!)
I'll probably try it out then and see how it goes. I do recall you saying that your version should be pretty stable and free of bugs.
The new menu looks fantastic, I haven't had any issues using it. I had to manually flash the firmware onto my SST39SF010 with a programmer though.
Hello, first post cuz my snes powerpak is on the way and i would like to put this on.
Now i understand the copying the powerpak folder but what about that src folder?
Thanks
Scott
@muckyfingers: Glad to hear that, thanks!
snstay wrote:
Hello, first post cuz my snes powerpak is on the way and i would like to put this on.
Now i understand the copying the powerpak folder but what about that src folder?
Hi snstay, thanks for your interest. "src" =
source, which means in that folder you'll find the unassembled hardware instructions (i.e., the sourcecode) for reference. This is not needed at all for casual PowerPak gaming, as explained in the readme file.
In How To Use.txt, Ramsis wrote:
To install this unofficial SNES PowerPak firmware v2.00, you are required to perform two steps:
1) Update your PowerPak's boot FlashROM chip with snes_powerpak_loader_v2.00.bin,
2) Replace the CF module files in the "POWERPAK" directory on your CF card with those from this release (whilst keeping your "SAVES" directory intact, of course).
Now however, since the beta version you likely downloaded is out of date, I would
NOT recommend using it at all.
Your brand-new PowerPak's hardware revision might not even be compatible with the latest flash updater I've come up with either.
So for now, I'd strongly advise you to use the
officially available firmware instead, and wait until a user-friendly solution becomes available -- if at all, that is (please don't forget that I'm doing all programming, and PowerPak research, in my free time while being reliant solely on my very own, first-run rev. D PowerPak to test everything).
BTW, should you be able to handle a screwdriver, it would be very helpful for me if you could post PCB pictures of your cart, or otherwise at least a picture of the closed shell (from both sides).
In any case, have fun using your SNES PowerPak!
PS @SST39SF010 users: Chips are ordered, waiting for them to arrive. Wish me luck!
Very cool stuff ramsis, and thanks for the advise. Ill wait for a more stable version to come out. And when it finally arives ill post pic of it for you.
Thanks alot
Scott
Ramsis wrote:
BTW, should you be able to handle a screwdriver, it would be very helpful for me if you could post PCB pictures of your cart, or otherwise at least a picture of the closed shell (from both sides).
Hey, I have a Rev H cart and would like to be able to use the updated firmware. It looks like my chip is soldered in so I don't know if it's possible, though. Let me know if you need any more pics of the cart / close ups. The picture of the back is kind of blurry but it's just traces.
http://i50.tinypic.com/10ek5ue.jpghttp://i46.tinypic.com/qrnjt0.jpg
effowe wrote:
Hey, I have a Rev H cart and would like to be able to use the updated firmware. It looks like my chip is soldered in so I don't know if it's possible, though.
Thank you so much!
Looks like your revH has the same type of flash chip installed as most (or all?) revE carts. That's good news because the 39SF010A chips I've ordered arrived just today. So once I manage to add reliable support for this chip to my flashing routines (which shouldn't be too much of a hassle), you'll all be able to update. Let's just hope revD's and revE/H's hardware design isn't so different as to ruin my efforts.
I'll definitely look into it this weekend. Stay tuned!
Edit: Took me long enough, but I succeeded! Flashing the SST39SF010A works totally different than flashing the AT29C010A, though. Before being able to reliably rewrite so much as a single byte, you have to erase the 4KB sector that contains that byte. (With the AT29C010A, you don't have to erase anything first but instead make sure that 128 bytes are written at a time, i.e. before data polling or checking the toggle bit.) So for the record, I have two completely independent flashing routines implemented by now. The updater automatically determines which one to use depending on the respective type of flash ROM chip the PowerPak has installed. Yay! What's left to do is code optimization as well as some more testing. Seems like a final release is drawing near!
This is too awesome! Looks like I don't have to bother my friend again whom I used to program my SST39SF010A with 2.0-beta1.
Awesome news, my snes powerpak arives in 2 days. Sounds like there should be good news by the time i get it.
Scott
I have a socketed SST39SF010A rev E as well. Today I discovered the spc player with the retrousb files doesn't really work (I don't hear anything from it). Am I doing something wrong or does the powerpak built in spc player stink and I should update to this?
Hey Drakon,
no idea what's actually wrong with the "stock" SPC player. It never really worked for me either, although I was able to get a few tunes playing (though sometimes only until a song started looping). My release incorporates blargg's SPC player (ported over from sd2snes), which does the job like a charm.
You'll have to update in order to benefit from it, though. I don't really feel like backporting any new CF module features to v1.0X. My in-system flash updater is basically finished, someone else apart from myself should put it to the test before release, though.
Any socketed SST39SF010A users who happen to have a PLCC32 programmer available and would like to try out the flasher, please PM me.
Thanks!
Ramsis
Hey ramsis if you need a guinea pig to test you update i will give it a try.
I just got my powerpak its a rev H.
Thanks
Scott
Ramsis wrote:
Any socketed SST39SF010A users who happen to have a PLCC32 programmer available and would like to try out the flasher, please PM me.
As the feedback hasn't exactly been overwhelming, I just decided to put the new flash updater up here for everybody to try out.
SNES PowerPak flash updater v03This supports both the AT29C010A and the SST39SF010A type of flash ROM chip, with any known previous SNES PowerPak loader software (i.e., the "stock" v1.02 or any of my beta ROMs) installed. It has been very well tested on all kinds of different setups -- on consoles with 2/1/3 and 1/1/1 chipset, respectively.
Usage: Just copy the POWERPAK directory from the 7z archive onto your CF card, overwriting ALL (!) existing files in the process -- yes, including the TXT files (but preserving the contents of your SAVES folder, if applicable). Ignore the "other" directory (it contains the flash module source code and a full bootloader ROM file for manual programming). On powering up your PowerPak, you should be prompted to update. Don't worry about glitchy graphics, especially if your previous ROM is v2.00-betaX.
Some warnings:
- This is unofficial software. Use it at your own risk!
- If you turn your expensive PowerPak into a brick by using my software, I will neither be blamed nor held liable or responsible for it.
- I do NOT recommend using this software with any PowerPak whose boot ROM chip isn't socketed (e.g., revH) at the current time.
- Please be aware that you will likely forfeit your 5-year replacement warranty by using any unofficial software with your PowerPak.
- Don't use this software if you don't agree with these terms!
That said, have fun updating!
Wow, the programming went really fast. My experience @
http://youtu.be/nqoYknU3VK8Thanks man!
cool ramsis cant wait to try it out. I cant belive there arnt more people interested in this.
Scott
Whoa are you saying this wont work on rev H?
I'll try it out probably tonight. One thing that would make more people interested or aware would be if it wasn't burried in a thread with so many pages of replies and if a list of features/improvements even comparison pictures were presented. Ofcourse the popularity of the Super EverDrive and SD2SNES mean there are probably less PowerPAK owners than there otherwise would be.
I know the improvements include wider resolution for filenames to fit nicer, different backgrounds and logos. But a complete list that's right where people will see it is a good idea. I didn't check the archive yet, maybe it is in there.
Well I flipped back a few pages to find a
changes list but I think this whole thing deserves its own thread don't you?
I think you are right this wonderful project dose deserve its own post so more people can see it.
Scott
Marvin wrote:
Wow, the programming went really fast. My experience @
http://youtu.be/nqoYknU3VK8Thanks man!
Thank you too! Now I know my flasher works perfectly fine on revE, too. No hardware compatibility issues, apparently.
snstay wrote:
cool ramsis cant wait to try it out. I cant belive there arnt more people interested in this.
Scott
Whoa are you saying this wont work on rev H?
Thanks for the kind words, Scott.
Well, I won't say the flasher won't work on revH; in fact, it will very likely work. There's just a much, much higher risk involved in trying. Should anything go wrong -- say, a power failure occurs during the ~3 seconds it takes to rewrite the chip --, a revH PowerPak couldn't be repaired as easily as e.g. a revE, where you'd just have to take out the ROM chip and reflash it using an external programming device.
So - the decision is yours, as is the risk.
MottZilla wrote:
One thing that would make more people interested or aware would be if it wasn't burried in a thread with so many pages of replies and if a list of features/improvements even comparison pictures were presented.
The first two betas were announced/released on my
personal blog. For the final release, I plan to set up a dedicated subpage with a list of features, images, and downloads.
Thanks again!
Well alright the new ramsis firmware update works perfectly on a rev H snes powerpak. The setup was fast, easy, and flawless.
Thank you ramsis for this great update and i cant wait to see what the final revision will bring.
Take it from me if you own a snes powerpak you should put this update on.
scott
The update ran smoothly on my Rev H cart as well. Very well done, thanks again!
Amazing, guys!
Both of you are true SNES PowerPak pioneers.
No kidding, you've proven yourselves exceedingly lion-hearted. So glad to hear that flashing your revH carts worked without any trouble (whew)!
snstay wrote:
Thank you ramsis for this great update and i cant wait to see what the final revision will bring.
Don't expect too much -- the bootloader itself hasn't changed since mid-December and is pretty much final. Regarding the CF modules, there's still room for improvement, though.
... And of course there's always room for v3.00, hehe.
Oh damn, so this came out just as I borrowed my SNES PowerPak to my brother. I guess I'll have to wait a couple of more days before trying it, but thanks in advance for the SST flashing option!
I updated my PowerPAK last night. It looks very nice. One thing I noticed though that was slightly annoying was that less files fit into a directory now. I used to have all my games in one folder. But now, I guess since it stores more characters, it cut off around letter S I think. So I had to split into two folders but other than that, it's more colorful with a much nicer font and seems to be an all around improvement. =)
My PowerPAK is I think the earliest revision so it was expected to update with no problems.
Hey, thefox, you're welcome. Good luck, let's hope it'll work for you, too!
MottZilla wrote:
I updated my PowerPAK last night. It looks very nice. One thing I noticed though that was slightly annoying was that less files fit into a directory now. I used to have all my games in one folder. But now, I guess since it stores more characters, it cut off around letter S I think. So I had to split into two folders but other than that, it's more colorful with a much nicer font and seems to be an all around improvement. =)
Thanks!
About the supported ~508 files per folder limitation: I'm fed up with that myself, by now.
The way the buffer was implemented in v1.0X (using WRAM $7F0000-$7FFFFF) simply isn't up to the task anymore, is it?
BTW, you guessed correctly: In order for more characters per filename to load, the buffer had to be expanded from 32 to 128 bytes per entry, so the max amount of entries supported got effectively cut down by 75%. Which is a lot.
So I've been thinking for quite some time about relocating the buffer from WRAM to SDRAM, of which the PowerPak has a whopping 16 MB (128 Mbit) to offer. What a blast!
Now theoretically, half -- and only, ever, half -- of all this monstrous space could be used for storing directory content: $FFFF entries * 128 bytes each = 8 MB. That would be 65,535 entries per directory. (Compare that to the current design, where we are limited to 512 entries!)
So I sat down this very evening and tried to implement new "CardLoadDir"/"DirPrintDir"/"DirGetEntry"/"DirFetchEntry" routines using SDRAM as a buffer, just to prove to myself it was possible at all. To my own surprise, with success.
(Note how I had to fall back to using multiplication registers instead of the slightly faster M7X PPU registers, as the latter seem to expect signed values only.)
Code:
; *********************** Fetch entry from SDRAM ***********************
; This function calculates the current entry's SDRAM buffer address.
; 65536 ($FFFF * $80) entries are supported at the max. For more ugly
; hardcoded buffer-related stuff, see routines
; "CardLoadDirSaveEntryLoop" and "CardLoadDirShortFileName".
;
; DMA_port_address[24bit] = selectedEntry[16bit] * 128
DirFetchEntry:
lda selectedEntry ; lower byte
sta $4202 ; multiplicand
lda #$80
sta $4203 ; multiplier
nop ; wait a few cycles (plus 3 to read the product register) ...
nop
nop
lda $4216
sta DMAWRITELO ; ... for the multiplication to complete, store the interim result
lda $4217
sta temp+6
lda selectedEntry+1 ; upper byte
sta $4202 ; multiplicand
lda #$80
sta $4203 ; multiplier
nop ; wait a few cycles ...
nop
nop
lda $4216 ; ... for the multiplication to complete, add the interim result
ora temp+6
sta DMAWRITEHI
lda $4217
sta DMAWRITEBANK ; store the final result
rts
As a side note, it's fast! I can only make an educated guess, but actually using the filebrowser feels at least 1/4 faster than before. And no trouble loading Syvalion (j) from a directory with ~800 ROMs starting with the letter S.
There are drawbacks, though. First of all, I'll have to readjust a couple of routines I'd thought to be finished once and for all (e.g. page-by-page navigation, SRAM auto-matching) due to the PowerPak's SDRAM DMA port hardware implementation (featuring auto-increment). Second, I was hoping to get away with a CF module-only upgrade. No way though! The goddamn scrolling routine makes use of ye olde DirPrintEntry during Vblank.
Worst of all, I'll have to keep the original directory loading / WRAM buffering code anyway. This is because one of the key software design features of the PowerPak is being able to access the CF card file system
before even programming the FPGA and/or unlocking SDRAM.
To summarize, this will be more than enough work for a 2.10 release. Which is not going to happen soon. But you bet that it will happen. Because the SNES PowerPak is awesome. Because the SNES PowerPak deserves one blast of a firmware.
Long live the SNES PowerPak!
Idly curious: why an array of fixed-length strings for holding filenames, rather than a heap and a linked list?
Faster random access? I dunno.
Glad to hear you'll work on improving it. =)
Faster random access can be done with a collection of concatenated NUL-terminated UTF-8 strings (which are generally more compact in memory than the UTF-16 in which directories are stored in FAT) and an array of pointers into this collection, one pointer per filename. Sort the array and you've sorted all the filenames.
Ramsis wrote:
Code:
; *********************** Fetch entry from SDRAM ***********************
; This function calculates the current entry's SDRAM buffer address.
; 65536 ($FFFF * $80) entries are supported at the max. For more ugly
; hardcoded buffer-related stuff, see routines
; "CardLoadDirSaveEntryLoop" and "CardLoadDirShortFileName".
;
; DMA_port_address[24bit] = selectedEntry[16bit] * 128
DirFetchEntry:
...
You can make this even faster without using the multiplier. Multiplying by 128 is the same as shifting left 7 times. However, it's more efficient to "shift" left 8 times (you don't actually need to shift because it's on byte boundary), then shift the 24-bit value right once.
Something like this (not tested):
Code:
; *********************** Fetch entry from SDRAM ***********************
; This function calculates the current entry's SDRAM buffer address.
; 65536 ($FFFF * $80) entries are supported at the max. For more ugly
; hardcoded buffer-related stuff, see routines
; "CardLoadDirSaveEntryLoop" and "CardLoadDirShortFileName".
;
; DMA_port_address[24bit] = selectedEntry[16bit] * 128
DirFetchEntry:
lda selectedEntry + 1
lsr
sta DMAWRITEBANK
lda selectedEntry
ror
sta DMAWRITEHI
lda #0
ror
sta DMAWRITELO
rts
Thanks for the input, guys!
Concerning directory buffering, I've actually considered a database approach similar to e.g. sd2snes before. Problem is, I have very much close to zero experience when it comes to efficient data structure implementation. (And I don't have the FPGA file's sourcecode either, so everything would have to be done on the SNES CPU). Apart from that, the PowerPak's rudimentary FAT implementation would have to be redone from scratch in order to allow reliable saving of larger files (of any given size, and even if the existing target file is of a different size) onto the CF card.
Implementing dynamic filename buffer allocation
without a CF database wouldn't make much sense in my opinion. Imagine having to wait for the buffer to be rebuilt every single time you launch the filebrowser, or navigate to another directory, or choose a ROM with SRAM, especially when your ROM collection is huge. Most of the time, you'd be staring at "Loading ..." messages. No fun at all.
Of course, the prospect of maxing out the number of supported files per directory, seeing filenames sorted alphabetically, doing fully dynamic filename comparisons (for SRAM auto-matching), and/or even adding gimmicks like auto-scrolling of longer filenames, sounds exciting. To be honest, even attempting to tackle the database thing, though not impossible per se, seems well beyond what time and effort I'm willing to further invest in this project.
Thus, right now I feel that concentrating on improving and optimizing the way things are currently implemented is the best approach.
thefox wrote:
Multiplying by 128 is the same as shifting left 7 times. However, it's more efficient to "shift" left 8 times (you don't actually need to shift because it's on byte boundary), then shift the 24-bit value right once.
Ack!
Shame on me! *facepalm* This is indeed way, way more efficient, and elegant, than my clunky multiplication routine. Thank you so much! You'll be mentioned as a contributor.
Does this fix the game genie code problems the original powerpak has? Bunnyboy released an unofficial fix that never really fixed the problem. If the game genie codes work in Contra 3 or Pockey and Rocky then it is fixed, if not it still suffers the same issue
.
Oh man, just realized this requires some sort of programmer to the firmware which I currently do not own =/.
Retrogamer wrote:
Does this fix the game genie code problems the original powerpak has? Bunnyboy released an unofficial fix that never really fixed the problem. If the game genie codes work in Contra 3 or Pockey and Rocky then it is fixed, if not it still suffers the same issue
.
Oh man, just realized this requires some sort of programmer to the firmware which I currently do not own =/.
There's a fix somewhere out there.
And you do not need a programmer AFAIK, unless there's some revisions that don't offer upgrading.
Hi, Retrogamer.
Retrogamer wrote:
Does this fix the game genie code problems the original powerpak has? Bunnyboy released an unofficial fix that never really fixed the problem. If the game genie codes work in Contra 3 or Pockey and Rocky then it is fixed, if not it still suffers the same issue
.
Please have a look at
this thread. Is the file linked by jupitersj on the first page the unofficial "fix" you mentioned? Also, can you provide a GameGenie Code for Contra 3 that works on real hardware, but not on the PowerPak?
Retrogamer wrote:
Oh man, just realized this requires some sort of programmer to the firmware which I currently do not own =/.
As a matter of fact, no such mysterious device is required to update at all.
Ramsis wrote:
SNES PowerPak flash updater v03(...)
Usage: Just copy the POWERPAK directory from the 7z archive onto your CF card, overwriting ALL (!) existing files in the process -- yes, including the TXT files (but preserving the contents of your SAVES folder, if applicable). Ignore the "other" directory (it contains the flash module source code and a full bootloader ROM file for manual programming). On powering up your PowerPak, you should be prompted to update. Don't worry about glitchy graphics, especially if your previous ROM is v2.00-betaX.
Some warnings:
- This is unofficial software. Use it at your own risk!
- If you turn your expensive PowerPak into a brick by using my software, I will neither be blamed nor held liable or responsible for it.
- I do NOT recommend using this software with any PowerPak whose boot ROM chip isn't socketed (e.g., revH) at the current time.
- Please be aware that you will likely forfeit your 5-year replacement warranty by using any unofficial software with your PowerPak.
- Don't use this software if you don't agree with these terms!
That said, have fun updating!
Interesting, that was the SM.BIN I had downloaded before (and renamed to SM.MAP). It never worked for me, deleting all the files in the POWERPAK directory and then replacing it has some how made it work. I just tested contra III and pocky and they both accepted the codes fine now.
I guess false alarm after all, thanks.
EDIT:
Wow that flash updater is awesome.
EDIT:
So I flashed the powerpak with that flasher v0.3 and it works fine. However, if I try to update to your beta 1 on your website, I get black screen when I turn the powerpak on. Is there a beta 2 flash.bin floating around?
Retrogamer wrote:
I just tested contra III and pocky and they both accepted the codes fine now.
Great to hear that!
Retrogamer wrote:
So I flashed the powerpak with that flasher v0.3 and it works fine. However, if I try to update to your beta 1 on your website, I get black screen when I turn the powerpak on. Is there a beta 2 flash.bin floating around?
The betas are older than the version you have in the flash updater. A downgrade is NOT recommended. There's not even a flash updater included in the beta releases either, hence the blackscreen. Just stick to the POWERPAK files that came with the flash updater.
Excellent, thank you sir and keep up the great work!
I also tested game genie in that flasher version and it works great, outstanding job!
Retrogamer wrote:
Excellent, thank you sir and keep up the great work!
Sure will, thanks!
I won't take the credit for the GameGenie support in my unofficial firmware though -- that one goes to bunnyboy, whose sourcecode my release is based upon.
just checking in to say that everything is working great for me on this firmware!
simple process: first i took out the two screws in the back of the powerpak just to check what version i had and it looked the same as
effowe's here, rev H. followed the instructions
in this post and when i turned it on and got a bit of a scare as it just sat at the powerpak screen. turned it off and back on again and it loaded into the updater fine, so i'm not sure why it needed 2 tries.
but yeah now there's this really good looking menu on my powerpak and all the long filenames display better (couldn't distinguish
Teenage Mutant Ninja Turtles - Tournament Fighters from
Teenage Mutant Ninja Turtles IV - Turtles in Time when they used to get truncated). thanks a lot Ramsis
definite upgrade and i look forward to it having its own thread
Great to hear it worked for you, too!
(Not sure either about why it needed a second try though -- sorry.)
Here's a v2.01 WIP screenshot. Notice the beautiful SDRAM error message cleanup (and just pray you'll never, ever, see it yourself!
), and the fact that the whole thing is now logged for easy review and analysis later on:
Apart from that, v2.01 is coming along nicely overall.
The big new feature is support for 65536 files per directory thanks to using an SDRAM buffer. What's also cool is the fact that it's going to be the first version that was tested solely using my new flash updater, without even removing the chip from the PowerPak even once so far. Yay!
hooray cant wait for the new version!!!!
Ramsis rocks!!!!
Would it be possible to add more lines to the game genie codes? (I.e. put in 10 codes instead of 5)
Pasky wrote:
Would it be possible to add more lines to the game genie codes? (I.e. put in 10 codes instead of 5)
Theoretically, that should be possible. There are, however, other good things planned and/or currently in the works, which deserve highest priority.
Finally got a chance to try the Flash updater — everything worked great! So thanks once more for all the work you've put into this.
Is there a way to restore the original firmware? The only reason is because my Supaboy wont load a game with the update. Although I must say it runs like silk on my actual SNES.
thefox wrote:
Finally got a chance to try the Flash updater — everything worked great! So thanks once more for all the work you've put into this.
Glad to hear that, thank you too -- especially for the cool bitwise operation code snippet!
darkoutsider wrote:
Is there a way to restore the original firmware? The only reason is because my Supaboy wont load a game with the update. Although I must say it runs like silk on my actual SNES.
The Supaboy is a clone console, isn't it? If the PowerPak worked on it before the upgrade, then I see no reason it shouldn't work with my firmware, too
(unless you used another CF card and/or didn't replace
all the files in the POWERPAK directory).
Anyway, a downgrade is of course possible.
I'll send you a PM with instructions.
Yes I replaced all of the files on the CF. Not sure why it wont work. It loads up the main menu, just wont load the actual games. I tried about a dozen or so. Got one of them to load once (Mario Kart I believe) but it wouldnt load again. Checked it again on my SNES and it worked beautifully.
I'll try the downgrade and see if it acts any differently.
Okay I found out what the problem is. It is releated to the power of the Supaboy on Battery power. If I start up the Powerpak while plugged in it works just fine. AN external battery pak also helps from what i've read.
v2.01 is finally here.
Changes in v2.01:
- pulled my North American 2/1/1 chipset SNES out of the closet to simulate an SDRAM error, and thus be able to clean up the error message. Also, the latter is now written to LOG.TXT for easy reporting if required
- added feature: With a semi-intelligent buffer selection system, it's finally possible to use half of the available SDRAM (64 Mbit) for directory buffering. This extends the former limit of ~500 supported files per directory to a whopping 65,536 (theoretically, i.e. with FAT32 limitations in mind), which is especially useful if you have a large ROM collection, and/or store massive amounts of SRM files within a single directory. Best of all: It's faaaast!
- improved button mapping: You can now back out of the SRAM browser as well (press B) and return to where you previously were (i.e., options screen before starting a game / questions screen after long reset)
- changed the way ROM/SRAM filename printing on the options screen is implemented: Full filenames are preserved now, and written to LASTSNES.TXT, instead of NUL-terminated strings
- tweaked the flash updater for reliability, and removed v1.0X/v2.00-betaX support from it. (Caveat: To be able to update to v2.01 without an external programming device, you MUST have v2.00 already installed!)
- added SRAM auto-loading support for .FIG ROMs, this was forgotten in v2.00 for some reason (sorry). Also, maxed out the filename matching character limit (122 with the current implementation), though for the sake of efficiency, it never compares any more characters than the ROM name actually consists of. Finally, optimized the module (SA.MAP) code-wise after realizing that my FindFile macro introduced in v2.00 supports finding directories, too! X-)
- optimized filebrowser and questions modules (SB/SG/SN/SQ.MAP) even more, getting rid of clone instructions and anti-stack overflow hacks
- countless other optimizations (especially code-wise, but also speed-related)
- other minor bugfixes and cleanups (e.g., error messages when system files/folders are missing, logo visibility after long reset)
awsome work as always ramsis!!!!
Is there any possibility to add support for Boot ROM 1.01? I was a very early adopter of the PowerPak but have not seen the need to update to the official RetroZone 1.02 Boot ROM when the only change was " - Starts with DMA off for better CF card compatibility" However, the 2.00 upgrade program will refuse to run on my PowerPak.
Thanks, guys! Your feedback is much appreciated!
Great Hierophant wrote:
Is there any possibility to add support for Boot ROM 1.01? I was a very early adopter of the PowerPak but have not seen the need to update to the official RetroZone 1.02 Boot ROM when the only change was " - Starts with DMA off for better CF card compatibility" However, the 2.00 upgrade program will refuse to run on my PowerPak.
Whoa, I didn't even know that v1.01 was a retail boot ROM version until just now!
Thanks for reporting, Great Hierophant!
Actually, the updater itself should support all v1 boot ROMs. Since I assumed v1.02 was the first retail version, however, I only added a check for v1.02 and v1.03-beta1 to my v2.00 release. Sorry for that!
The good news is that I can easily recompile another v2.00 update version for you and all v1.01 users, you'd just have to wait a bit as I'm busy with regular work right now. Or, if you know how to use a hex editor, you can add compatibility with your version yourself (it's a one-byte change).
To do that, open
SI.MAP (not SU.MAP!) from my v2.00 release with the hex editor of your choice, navigate to offset
0x873 and verify that the byte value is $33. Then, change it to
$31. Save and close the file, and then try updating again. What this change does is basically change an instruction like
if ver string starts with v1.02 or v1.03, then ... to
if ver string starts with v1.02 or v1.01, then ... So, nothing special, really (assuming that the version string remained at the exact same offset in the later ROMs, which is likely).
BTW, no need to do anything like that again when subsequently updating from v2.00 to v2.01 -- this should work out of the box.
Good luck, and let me know if it worked as I expect it will!
According to my email archive, I bought mine on November 5, 2009. I think I can easily manage a one-byte change to the file indicated
I will be happy to let you know how it works out.
EDIT - Updated to 2.00 like a charm!
EDIT2 - Updated to 2.01 without a problem. Thanks Simba
Hey Ramsis,
Just wanted to say that I installed 2.01 and it all went well. Thanks for the update, and the shout out in the txt file in the release
effowe
First post, new member here. I've been having problems with my Powerpak since I got it this morning. I've formatted my Kingston 4GB countless times and still, nothing.
Symptoms are as follows: I'll format the card to FAT32 and first put it in the Powerpak to see whether or not it senses the CF card. It does, then tells me I need to put the Powerpak file on the card. I put it on correctly and start up my NTSC SNES and the start up screen will flicker and the load screen will not work at all. It'll happen for a few seconds and then it will just turn black.
Enter CF card #2. A Sandisk 1GB that while slow, seems to work--at least it lets me navigate menus and store some games on it. I open a rom file and then the screen will change to a "Copying Game..." text, which fades in and out--indefinitely. The screen continues way past two minutes and nothing happens. I've tried changing the DMA to 0 and still, nothing.
CF #3, just a modern 8GB Sandisk Ultra. I get the sectors left error, which I pretty much expected. Seriously, what is going on here?
haochao:
describe the power supply you are using to power your snes.
I've been thinking about hiding the POWERPAK folder in the filebrowser entirely. Having to look at that folder has been annoying since the very beginning, anyway. I already came up with a fast and reliable implementation that works great.
This change, however, would involve altering the way SRAM saving is handled because you'd no longer be able to access the SAVES subfolder. Personally, I like the idea of storing the SRM file along with the ROM file -- just as you might be used to in case you're organizing your ROMs in game folders, like myself. At a later stage (i.e., once I fully understand how FAT32 works), I might even implement an option to create new savefiles residing in the current ROM folder.
So, PowerPak users, please let me know what you think about that. Do you cling to a SAVES subfolder? Or are you fed up with copying your emulator saves to a different location than your ROMs, and like the idea to be able to copy two files (ROM & SRAM) to one and the same folder in the future?
I'm looking forward to your feedback!
Ramsis wrote:
I've been thinking about hiding the POWERPAK folder in the filebrowser entirely. Having to look at that folder has been annoying since the very beginning, anyway. I already came up with a fast and reliable implementation that works great.
This change, however, would involve altering the way SRAM saving is handled because you'd no longer be able to access the SAVES subfolder. Personally, I like the idea of storing the SRM file along with the ROM file -- just as you might be used to in case you're organizing your ROMs in game folders, like myself. At a later stage (i.e., once I fully understand how FAT32 works), I might even implement an option to create new savefiles residing in the current ROM folder.
So, PowerPak users, please let me know what you think about that. Do you cling to a SAVES subfolder? Or are you fed up with copying your emulator saves to a different location than your ROMs, and like the idea to be able to copy two files (ROM & SRAM) to one and the same folder in the future?
I'm looking forward to your feedback!
I don't have a problem with the SAVES folder, but also wouldn't mind the saves residing in my ROMS directory. Maybe you could just implement a "Starting Directory" option that would open the file browser in the folder of my choice. I would set mine to ROMS so I wouldn't see the POWERPAK directory anyways. Just a thought.
Can't you make a switch, so that when browsing for a ROM file to load it hides the folder, but when browsing for SRAM files it does not? And make that an option?
Thanks, effowe!
MottZilla wrote:
Can't you make a switch, so that when browsing for a ROM file to load it hides the folder, but when browsing for SRAM files it does not? And make that an option?
I easily could, but I don't think an implementation like that would be in favor of usability (and logic, for that matter).
But hiding it isn't that much better. I mean I guess the goal is to hide the Powerpak folder and keep the save and roms in their folders together which isn't a bad idea really. I'm just not bothered enough by seeing the PP folder to want it hidden. If you hide it and have saves moved to where the roms are then you need to make sure the auto-save locating still works right?
MottZilla wrote:
If you hide it and have saves moved to where the roms are then you need to make sure the auto-save locating still works right?
It would actually require much less code, and thus be faster than now, if locating the SAVES folder and navigating into it weren't necessary any more.
Well, anything that ends up making it easier to use, sounds like a good idea.
Hide it Ramsis. I also think its an eyesore on the main menu.
By the way awesome job!!
Scott
I'd prefer it to be hidden as well, I never browse to it.
PowerPaks support FAT/FAT32, so here's my question:
Does the filesystem and directory printing code actually honour the
hidden file attribute (0x02)?
I could pull out my PowerPak and check, but I'd rather just ask.
If not, I would recommend simply adding code honouring that bit, since all that attribute does is hide the file/directory from directory listing visibility; in other words, make use of the filesystem capabilities that exist, rather than create "special naming one-offs".
This honestly seems like best approach for both the POWERPAK folder and the SAVES folder -- the user marking them hidden is easy to do on every OS and makes the most sense. It's then up to the user to decide for themselves what
they want.
Thanks for the feedback, guys!
koitsu wrote:
Does the filesystem and directory printing code actually honour the
hidden file attribute (0x02)?
Yes, of course. If that bit is set, the FAT entry is skipped entirely, which makes sense. Problem is: We don't want to skip the entry as we need to read the folder's contents.
Now, I could change this implementation and add a variable that is modified when a hidden FAT entry is detected, and checked when all relevant entries are saved to the buffer. The way I've been doing it in the current WIP is much like that, just that instead of a variable, I compare the entry's cluster to that of the PowerPak folder. Let me know if you have a better suggestion.
koitsu wrote:
If not, I would recommend simply adding code honouring that bit, since all that attribute does is hide the file/directory from directory listing visibility; in other words, make use of the filesystem capabilities that exist, rather than create "special naming one-offs".
Yeah, that's been my approach all along.
koitsu wrote:
It's then up to the user to decide for themselves what they want.
Yeah. To learn what PowerPak users want has been the purpose of me asking, you know.
Ramsis wrote:
koitsu wrote:
Does the filesystem and directory printing code actually honour the
hidden file attribute (0x02)?
Yes, of course. If that bit is set, the FAT entry is skipped entirely, which makes sense. Problem is: We don't want to skip the entry as we need to read the folder's contents. :)
Now, I could change this implementation and add a variable that is modified when a hidden FAT entry is detected, and checked when all relevant entries are saved to the buffer. The way I've been doing it in the current WIP is much like that, just that instead of a variable, I compare the entry's cluster to that of the PowerPak folder. Let me know if you have a better suggestion. :)
I'm not sure how to interpret what you've said here, so if I'm misunderstanding the fault is mine.
Your description, re: "if hidden attribute is set, the FAT entry is skipped entirely", indicates completely/absolutely incorrect behaviour (meaning whoever/whatever wrote that code behaviour did so wrongly). The code needs to be changed to simply remove the visual presentation (i.e. printing of the directory) and that's all.
So if your proposition is to make it do exactly that, then yep, fully agree that's the right solution. :-)
koitsu wrote:
Your description, re: "if hidden attribute is set, the FAT entry is skipped entirely", indicates completely/absolutely incorrect behaviour (meaning whoever/whatever wrote that code behaviour did so wrongly).
Thinking about it, I have to agree. Each and every OS I know can and does access hidden files. No idea what the original developer was thinking ... nor myself up until now.
koitsu wrote:
The code needs to be changed to simply remove the visual presentation (i.e. printing of the directory) and that's all.
So if your proposition is to make it do exactly that, then yep, fully agree that's the right solution.
Cool! I'll try to come up with a fast and easy implementation. Thanks for the helpful input, koitsu!
Popular file managers for Gtk+, such as Nautilus and Thunar, have a shortcut Ctrl+H to show and hide "hidden" files. (Under Linux, "hidden" files are those whose names start with '.' or end with '~'.) When I'm on Windows, I miss having this shortcut. I wonder what sort of button combination on the Super NES controller would make sense for "reload the current working directory and toggle whether hidden files are included in the list".
tepples wrote:
Popular file managers for Gtk+, such as Nautilus and Thunar, have a shortcut Ctrl+H to show and hide "hidden" files. (Under Linux, "hidden" files are those whose names start with '.' or end with '~'.) When I'm on Windows, I miss having this shortcut.
On Windows 8, the keyboard shortcut to toggle the displaying of hidden files/folders is Alt+A, H, H (or maybe Alt+V, H, H, depending on your OS language).
The next version of my firmware is nearly ready, with some more testing pending. Not only will v2.02 incorporate the proper acknowledgement of hidden files/folders, but it'll also be faster than previous versions.
Awesome! Now for my slightly-off-Subject question: can this same PowerPak adjustment be made for the NES PowerPak? I do not own a SNES PowerPak and have no intention of getting one, but the NES PowerPak I do have and would benefit from said fixes.
A new version with the hidden files....Awesome ramsis, totally awesome.
to kind of quote jeff spicoli.
koitsu wrote:
can this same PowerPak adjustment be made for the NES PowerPak?
As I understand it, it's slightly harder to reflash an NES PowerPak in-system because of how boot ROM write enabling is handled.
snstay wrote:
A new version with the hidden files....Awesome ramsis, totally awesome.
to kind of quote jeff spicoli.
Hehe, thanks, Scott!
koitsu wrote:
can this same PowerPak adjustment be made for the NES PowerPak?
Yes. The relevant code sections in the
NES boot ROM source are
CardLoadDirCheckHidden: and
CardLoadDirSaveEntry:. Just add a "hidden" flag to variable
tempEntry+$1B, bit 0 of which is the directory flag. Then, check this new flag in
CardLoadDirSaveEntry:, skipping the entry if it's set. Don't forget to adjust the handling of said variable in all the mapper code (not just loader.asm) as well, since any
cmp #$01 will result in incorrect status bits if your new "hidden" flag is set at the same time.
BTW, you would also want to add some means to detect whether
CardLoadDir: was called for printing directory content to the screen, or merely for loading a system file, and disable skipping of "hidden" files in the latter case.
Let me know if you need further assistance regarding the PowerPak boot loader's code structure/functions.
tepples wrote:
As I understand it, it's slightly harder to reflash an NES PowerPak in-system because of how boot ROM write enabling is handled.
Hmm ... don't at least older versions of the cart have a socketed boot ROM, just like early SNES PowerPaks? Unfortunately, the only PCB shot I could find doesn't look like it:
Well, whatever. I don't own a NES PowerPak, so I can't really tell. In fact, I don't even own a NES.
Hello Ramsis, great work. I love reading this thread.
So you have been asked about updating another flashcart, I have always wanted to ask you a similar question but haven't so here goes. Have you considered working on the SD2SNES as well, maybe helping to implement some of the remaining chips?
marvelus10 wrote:
Hello Ramsis, great work. I love reading this thread.
So you have been asked about updating another flashcart, I have always wanted to ask you a similar question but haven't so here goes. Have you considered working on the SD2SNES as well, maybe helping to implement some of the remaining chips?
Thanks, marvelus10.
I'll head over to the
SD2SNES thread to answer your question.
hey ramsis any update info? I got my snes all hooked up and ready to go.
snstay wrote:
hey ramsis any update info? I got my snes all hooked up and ready to go.
Hey, Scott, v2.02 is basically ready for release.
The only thing I still haven't decided yet is what to do about the SAVES folder. I've added a compiler switch to easily enable/disable its usage, and would really like to disable it for the release. However, I fear this might cause many false "bug reports" about save files not loading, which you'd either have to load manually, or move from SAVES to your ROM directories.
Any comments on this matter -- preferably from active PowerPak users like yourself -- are appreciated.
Hello Ramsis - thank you for your work on this firmware! The menu is much easier to navigate and has saved me a lot of time having to go in and rename a lot of my file names that were too long for the original screen width.
I have one question because it wasn't straightforward to me when downloading.
I copied the contents of your POWERPAK folder into mine for version 2.0 then upgraded to 2.1. Was this necessary if I was starting from scratch or could I have started with version 2.1? (Using revH powerpak). I know a few people who own a powerpak and would like to pass this along.
Looking forward to V2.02
Hi-res is awesome on S-Video but sort of blurry on composite. Still an improvement over stock though.
dram55 wrote:
Hello Ramsis - thank you for your work on this firmware! The menu is much easier to navigate and has saved me a lot of time having to go in and rename a lot of my file names that were too long for the original screen width.
Thanks a lot!
dram55 wrote:
I copied the contents of your POWERPAK folder into mine for version 2.0 then upgraded to 2.1. Was this necessary if I was starting from scratch or could I have started with version 2.1? (Using revH powerpak). I know a few people who own a powerpak and would like to pass this along.
You did it exactly right.
Up to v2.00 (non-beta), I had to relocate several variables related to printing and directory loading. Starting from v2.00, all variables were kept at their memory location to ensure a certain level of backward compatibility (which is why v2.01's flasher is much more lightweight, with the drawback that an installed v2.00 is a prerequisite). This also means that you can upgrade from v2.00 to v2.02 directly, thus skipping v2.01 if you want to.
dram55 wrote:
Looking forward to V2.02
And here it is:
Download v2.02 ("Happy Halloween" release)The most important changes include the proper acknowledgement of FAT32 entries marked as hidden, an all-new GG code handler (both on the frontend and "under the hood"), hardcoded developer's note music that can be stopped/restarted at will, and last but not least an overall speed-boosted CF card software interface thanks to using 16-bit math wherever possible. For an exhaustive list of changes and fixes, check the link in my signature.
Note that the in-system flashing procedure takes a bit longer than previously due to one more bank being written. (BTW, you can safely delete SD.SPC from your CF card, as this file is no longer used.)
tepples wrote:
Hi-res is awesome on S-Video but sort of blurry on composite. Still an improvement over stock though.
Thanks, tepples!
Now that you mentioned it, I tested my firmware with an RF hookup last night and thought the new hi-res font was still more than legible, even though I'm used to using a crystal-clear RGB connection.
Edit:Ramsis wrote:
The only thing I still haven't decided yet is what to do about the SAVES folder. I've added a compiler switch to easily enable/disable its usage, and would really like to disable it for the release.
FYI, I completely scrapped that idea because implementing it would have been too much of a hassle.
Anyway, have fun with v2.02, and happy Halloween, everybody!
Ramsis wrote:
Hey Ramsis,
Thanks for the new firmware, I loaded it up onto my card and upgraded successfully. I am getting an error when I try to load a game, however. For the 5 games I just tested (which were working before) I get..
"Error: SA.MAP file not found!"
I thought that was peculiar, so I double checked my POWERPAK directory and it was there. I also copied SA.MAP from the 2.02 release directory and overwrote the file again, and I still get the same error.
Any ideas?
Sounds like a CF card issue to me. Are you using FAT16 or FAT32? The first thing you might want to try is check the card filesystem for errors with Scandisk (or a similar tool). Even if no errors are found, re-format your card using FAT32 and copy the POWERPAK folder onto it first. If the problem persits, try using a different CF card.
Did you power-cycle your SNES after the upgrade was successfully completed (and before trying to load the games)?
Thanks!
Ramsis wrote:
Sounds like a CF card issue to me. Are you using FAT16 or FAT32? The first thing you might want to try is check the card filesystem for errors with Scandisk (or a similar tool). Even if no errors are found, re-format your card using FAT32 and copy the POWERPAK folder onto it first. If the problem persits, try using a different CF card.
Did you power-cycle your SNES after the upgrade was successfully completed (and before trying to load the games)?
Thanks!
After formatting the card and trying another one a couple times, it finally started working. I don't know what the issue was, but it's fixed now.
The menu definitely feels snappier, thanks for the update!
Glad to hear that!
Ramsis, the new menu looks amazing! Thank you for your hard work!
A spooktacular halloween release.
Thanks ramsis wonderful job as always!!!!!
Thanks, guys.
So, what about the future of the SNES PowerPak software?
Well ... Once again, I recently wrote to bunnyboy concerning a few important things (e.g., I wonder what more could be done with an only "60% full" FPGA?), but haven't gotten a reply yet. In the meantime, I've reviewed my progress so far, gotten better by reading more tracelogs (of FF6j, mainly), and contemplated the possibilites for maxing out the PowerPak's potential.
First and foremost, I've come to the conclusion that my PowerPak firmware as of now is nice to look at, and works well. And that it needs heavy improvement, at the same time. The reasons why I feel compelled to do it are manifold. If I don't do it, who will?
Joking apart, I've been a fan of the PowerPak ever since it was announced in late 2009, and even though there are other flash carts for the SNES available, I feel I love my PowerPak more each day.
To cut a long story short: Yes, there will be an unofficial firmware v3.00. It's been in the works for two weeks now, and it's coming along nicely.
Emulator shot:
TV shot:
Major new (i.e., WIP) features are:
- Full theme support, replacing the restricted logo/BG selection (at least one theme will be distributed along with the first "MUFASA" release).
- No more CF module accumulation, the concept of which has been obsolete ever since the appearance of my in-system flasher anyway. Been working on this very hard lately, it's actually much more of a pain in the neck than it may seem.
- A sprite-based, palette-switchable 8x8 VWF font for errors, special messages, etc.
- Auto-SRM creation (planned); this will only happen once I fully understand how FAT cluster chains work.
Are you still with me? ... That's great. Long live the SNES PowerPak!
From what I understand, FAT cluster chains are not that hard. When a FAT-using system loads a file, it does the following:
1. Get first cluster number from directory entry.
2. Read cluster.
3. End of file? Yes, stop. No, continue.
4. Read entry of FAT that corresponds to current cluster number (i.e. cluster 0x02 uses entry 0x02).
5. Entry set to end-of-chain (0x0FFFFFF8-0x0FFFFFFF for FAT 32)? Yes, stop. No, continue.
6. Entry set to free cluster (0)? Yes, assume end-of-chain and stop. No, continue.
7. Use value found at entry as next cluster number. Return to step 2.
Because you're only talking about creating SRMs, you should already know how long the memory snapshot you need is, and so creating a file in the FAT is basically something like
* Find series of 0s (free) in FAT long enough to hold desired file (because you're trying to avoid fragmentation. Aren't you? Otherwise just take any random set of 0s in the FAT you want)
* Rewrite them as a linked list
* The last element of the linked list should contain one of the end-of-chain IDs.
* The directory entry points at the head of the linked list
The cluster values/FAT locations 0, 1, and …FF0 through …FFF have predefined meanings, so don't allocate them.
Thanks for the input! In fact, the boot ROM already has all the code that's necessary to follow a cluster chain (otherwise, game loading wouldn't be possible on the PowerPak at all, unlike e.g. the sd2snes). What I'm not confident about doing yet is adding a routine that actually
creates a file.
lidnariq wrote:
Because you're only talking about creating SRMs, you should already know how long the memory snapshot you need is
Once a ROM is loaded, I know how big its SRAM is, so roger that.
lidnariq wrote:
Find series of 0s (free) in FAT long enough to hold desired file (because you're trying to avoid fragmentation. Aren't you? Otherwise just take any random set of 0s in the FAT you want)
So does the FAT contain entries for all possible FAT entries on the drive? Or do I have to read it in order to find out how many free sectors/clusters there are? Also, fragmentation shouldn't be an issue on flash drives AFAIK. Or is it?
lidnariq wrote:
Rewrite them as a linked list
I have honestly no idea how to do that, but I'll accept a challenge.
lidnariq wrote:
* The last element of the linked list should contain one of the end-of-chain IDs.
* The directory entry points at the head of the linked list
Hmm ... sounds plausible.
I take it there's a difference between FAT16 and FAT32 in creating files, isn't there? As of now, the PowerPak supports both file systems, and I don't want to have to scrap support e.g. for FAT16, of course.
lidnariq wrote:
The cluster values/FAT locations 0, 1, and …FF0 through …FFF have predefined meanings, so don't allocate them.
From what I've read (and revised) of bunnyboy's code up to now, that sounds familiar to me.
Hmmm ... gonna read some more FAT documentation as well to shed some light on this.
Thanks!
Ramsis wrote:
What I'm not confident about doing yet is adding a routine that actually creates a file.
You could prototype it using FAT file system images in C first. But after that is the hard (and probably patented) part: creating entries for the file in the directory and its long name and possibly allocating another cluster for the directory entry.
Quote:
So does the FAT contain entries for all possible FAT entries on the drive? Or do I have to read it in order to find out how many free sectors/clusters there are?
Yes, you have to read the whole FAT to see how many clusters are free. That's why some versions of DOS took a long time to print the last line of
dir output for the first time on a drive, and that's why Windows refuses to format FAT32 larger than 32 GB.
Quote:
Also, fragmentation shouldn't be an issue on flash drives AFAIK. Or is it?
I don't know much about ATA, but if it has a command to read multiple consecutive sectors, assigning consecutive sectors to a file is still useful. If anything, it means fewer clusters of the FAT need to be read to follow a given file's cluster chain.
Quote:
I take it there's a difference between FAT16 and FAT32 in creating files, isn't there? As of now, the PowerPak supports both file systems, and I don't want to have to scrap support e.g. for FAT16, of course.
FAT16 uses 16-bit entries, and FAT32 uses 32-bit entries. There are a few other differences, but that's the big one.
I'm late to the game here... Ramsis, are you looking into automatic saves now (vs. holding reset function)?
That would make the powerpak very awesome. My last contact with bunny boy -- I asked him about this and he said that he has someone working on it..... Would that be you or someone else?
Edit-- the sharper text.... Is this something that could be added to the stuff you did for me?
Ramsis wrote:
So does the FAT contain entries for all possible FAT entries on the drive? Or do I have to read it in order to find out how many free sectors/clusters there are? Also, fragmentation shouldn't be an issue on flash drives AFAIK. Or is it?
The FAT has 1.5, 2, or 4 bytes for each cluster on disk. It's basically an array of (12/16/28-in-32 bit) entries where each element specifies for any given cluster what the next cluster to look at is.
tepples wrote:
I don't know much about ATA, but if it has a command to read multiple consecutive sectors, assigning consecutive sectors to a file is still useful. If anything, it means fewer clusters of the FAT need to be read to follow a given file's cluster chain.
The CF1.4 specification has the commands "Read Sectors (20h)" and "Read Multiple (C4h)" both of which read up to 256 sectors at a time.
Ramsis wrote:
lidnariq wrote:
Rewrite them as a linked list
I have honestly no idea how to do that, but I'll accept a challenge.
A linked list is a memory structure that contains a pointer to the next element of the list. In C, that would usually be measured in bytes, but in the FAT it's measured in clusters. (Often, linked lists also contain a data element in addition to a pointer to next element, but in the case of FAT, the address is the data)
So, if the 40th-60th 32-bit words in your FAT32 volume (or 16-bit words in your FAT16 volume, or 12-bit words in a FAT12 volume) were all 0, and your cluster size was 4 KiB, and you wanted to make a 32KiB uncleared file, you'd write something like
41, 42, 43, 44, 45, 46, 47, …FFF
to the 40th through 47th words of both copies of the FAT. Then, in the directory you were inserting the file, you'd insert a directory entry with FirstCluster = 40.
The sectors haven't been cleared yet, though, so you might want to write 32768 bytes of all 0 to flash first. (Or maybe not, maybe that'll be handled transparently when you write out the SRM from the game)
tepples wrote:
But after that is the hard (and probably patented) part: creating entries for the file in the directory and its long name and possibly allocating another cluster for the directory entry.
You
might be able to claim non-infringing use by copy-pasting the original name verbatim, and updating the last 3 bytes/ucs2 of the shortname and LFN.
IIRC, the patent was only on making available a linked shortname-longname pair, so
workarounds exist. (Although one does need to ask whether non-VFAT compatibility is needed)
Also, you should seriously ask if you need to care; Microsoft doesn't seem interested in suing people unless they can get meaningful licensing fees.
Thanks for elaborating, lidnariq and tepples, and especially for alerting me to the patenting issue.
Now we know why bunnyboy obviously never bothered to add auto-SRAM creation himself, despite all that FAT32 code that he'd already come up with. I wonder whether patent licensing only applies to commercial products incorporating FAT32, and whether unofficial, non-commercial software such as mine would be affected at all ...?
Markfrizb wrote:
That would make the powerpak very awesome. My last contact with bunny boy -- I asked him about this and he said that he has someone working on it..... Would that be you or someone else?
It can't be me. The only ever reply I got from him dates from July 2012, when he said he'd put the firmware source code up on his server. Whatever I've done messing around with the PowerPak since then, I've been doing completely on my own and without bunnyboy ever showing evidence that he's even aware of it.
Anyway, here's a current WIP screenshot of the new SPC player:
Took me quite some time to get it done properly, as I had to both expand the tilemaps for a text buffer backup and implement some more HDMA tricks so the vertical scrolling offset doesn't get messed up. As you might guess from the picture, pressing B will take you back to the filebrowser instantly. While I was at it, I added some HDMA color math to fill the player "window", and spent time drawing the frame, and joypad button sprites.
More to come!
Ramsis wrote:
I wonder whether patent licensing only applies to commercial products incorporating FAT32, and whether unofficial, non-commercial software such as mine would be affected at all ...?
Specifically in this case, Microsoft has insinuated that they have no interest in suing the direct vendors and users of linux (with its compatible VFAT layer), but only mostly-closed end-user devices such as GPS units and Android phones. An optimist would hope that this is because they're afraid of having the patent invalidated if they did sue the Linux Foundation; a cynic would say that Microsoft is more interested in extracting money than in keeping people from using the patented techniques.
An obvious workaround for the powerpak is to create the SRM from the shortname. The ugliness is even mostly hidden now that you have a separate SAVES directory.
Additionally, maybe store the longnames in a non-VFAT manner, such as in a separate file like the umsdos overlay filesystem. If you wanted to be
really silly, you could store this database as a
.bat file that would rename the shortnames to the longname when the CF card was back in a windows machine.
There isn't usually a 'commercial' vs 'not' criterion with patent law.
@ Ramsis: I just wanted to say, THANKS!
The stock menus are pretty harsh, and can be a pain in the ass to read. Yours look fantastic. Thank you so much for your work!
Ramsis wrote:
Anyway, here's a current WIP screenshot of the new SPC player:
nice, i actually have around 30k SPC files copying to my CF card right now, and they're all rather cryptically named so this player will make it less of a nightmare to find certain songs
Is there a way to downgrade? I updated to 2.02 and now my CF card cannot be read. It worked fine with v2.00. I formatted the CF card using Fat32, tried again and it just gives garbage characters when trying to read the CF card. The actual boot menu is fine but cannot read the directories or files correctly. Verified its the powerpak by using another CF and get the exact issue, both used to work fine.
EDIT:
It just gave me 2 errors
Error $51 - CF Card status
Error $10 - CF Card error
Thanks, Ziggy587!
Pasky wrote:
Is there a way to downgrade? I updated to 2.02 and now my CF card cannot be read. It worked fine with v2.00. I formatted the CF card using Fat32, tried again and it just gives garbage characters when trying to read the CF card. The actual boot menu is fine but cannot read the directories or files correctly. Verified its the powerpak by using another CF and get the exact issue, both used to work fine.
Weird.
If it boots up fine, then that means it succeeds in reading files on the CF card (specifically, CONFIG.TXT, SI.MAP, and TOPLEVEL.BIT). Whatever the cause of your issue might be, I suspect that a firmware downgrade (if possible at all) likely won't fix it. Regardless, I got your PM and will send you a reply with instructions.
Downgrading worked. Fixed the problem. upgraded back to 2.02 and all is fine now.
i just realized that i can play the Alcahest fan translation on my PowerPak now thanks to the SIMBA firmware! (doesn't work on official firmware)
any updates on the next version?
hows the work coming along for the mufasa update?
First of all thanks for your work.
I have been using it for months , and the firmware works perfectly and looks much better than the original one.
When I use the info option(Select button) on the init screen I get this:
Quote:
Firmware v2.02 "SIMBA"
CF modules v2.02 "SIMBA"
DMA: on
DSP1: installed
CPU: 02
PPU1: 01
PPU2: 03
Video: 50hz
SDRAM: ERROR!
Reading bank: D5, read byte value: FF
Expected byte value: BF at offset $D5BC31
Trying again 4 times: 4D 4D 4D
CRITICAL HARDWARE ERROR! PLEASE CHECK LOG.TXT
According to SNES Memory Mapping by Duncanthrax of ShadowCraftIt,
that address correspond to the ROM in both Hi and Lo ROM modes:
Quote:
LoROM:
C0-FC 0000-7FFF 32k ROM Chunk
HiROM:
C0-FE 0000-FFFF 64k ROM Chunk
So is something wrong with the SDRAM of my Powerpack or my SNES?
Hi!
Ratix wrote:
hows the work coming along for the mufasa update?
It's almost ready for release, with the drawback that auto-creation of SRAM files isn't implemented. The FAT32 stuff required for that is just totally over my head, I'm afraid.
Pity that in spite of my many inquiries, bunnyboy never bothered to put the FPGA sources up on his
webspace, which might have simplified the task.
kp64 wrote:
First of all thanks for your work.
I have been using it for months , and the firmware works perfectly and looks much better than the original one.
Thanks!
kp64 wrote:
So is something wrong with the SDRAM of my Powerpack or my SNES?
The SDRAM test data is routed through the SNES, so you might want to check if there are any cart connector issues (e.g. dirt/dust). Next thing you should try is switch to another SNES console. If the issue still persists after that, I'd contact bunnyboy and ask for a hardware replacement.
Quote:
The SDRAM test data is routed through the SNES, so you might want to check if there are any cart connector issues (e.g. dirt/dust). Next thing you should try is switch to another SNES console. If the issue still persists after that, I'd contact bunnyboy and ask for a hardware replacement.
Thank you very much for the fast reply.
I pluged in the console 5 minutes ago and the error is gone( yeah!
)
As you said , maybe the error was caused by a bit of dirt/dust.
How do I create a Game Genie code file? I couldn't find this info anywhere, but maybe I'm not looking hard enough.
I put a .txt file on my CF card. I put "C28A-AD61" in the text file (I tried it with and without the hyphen). When I load the text file on the SNES PowerPak, it comes up "2861----" so obviously I'm doing something wrong. But from these results, I can't extrapolate the correct way to format the text file.
Hey, Ziggy587,
the GG code file format is briefly explained in the
manual (printed page 9). I just tested your code on v2.99, where it loads just fine.
Please try this:
Code:
C28AAD61 code description
Use notepad or a similar (non-unix style) text editor to save the file.
Good luck!
Ramsis
Thanks for the reply, Ramsis.
I still can't seem to get it to work. I'm using Notepad on Windows 7. I have your v2.02 "Simba" firmware installed (everything else works fine). I made a .txt file with simply "C28AAD61 code description" and nothing else. I left it on ANSI encoding. I still get "2861----" entered as a code. I tried switching the encoding to Unicode, Unicode big endian, and UTF-8 but got the same results with each one.
And by the way, thanks again for your awesome SNES PowerPak firmware! It makes using the PowerPak so much more enjoyable!
Hmm ... weird. The GG code handler in my latest WIP build is still the same as in v2.02, so I can't really see why it doesn't work for you – except maybe a corrupted file system on the card. Have you tried checking it for errors and/or reformatting it, or temporarily using another card?
Anyway, glad you like the firmware. Stay tuned for v3.00 "MUFASA"!
Ramsis wrote:
Have you tried checking it for errors and/or reformatting it, or temporarily using another card?
No, I have not. I'll try that when I get a chance and see if it fixes the problem.
Ramsis wrote:
Stay tuned for v3.00 "MUFASA"!
Right on!
edit: Well I re-downloaded your v2.02 FW and copied it over my CF card. I'm still getting the same results. It might be worth mentioning that I can manual input GG codes and they work fine as far as I can tell. I do have two other CF cards that I could test out with, in case that's the problem.
So, I got it to work.
I never loaded GG codes from .txt files on the PowerPak before, so when I was testing it out I just used any random code and put the .txt file in the route of the CF card. This loaded the code wrong, as I previously described. So I decided to organize some GG codes like I do on other carts: Game Genie folder in route of card, sub folders for each game, .txt files in sub folders. Storing a .txt this way, I was able to successfully load a GG code. I guess you can't store the .txt files in the route of the card?
Ziggy587 wrote:
So, I got it to work.
I never loaded GG codes from .txt files on the PowerPak before, so when I was testing it out I just used any random code and put the .txt file in the route of the CF card. This loaded the code wrong, as I previously described. So I decided to organize some GG codes like I do on other carts: Game Genie folder in route of card, sub folders for each game, .txt files in sub folders. Storing a .txt this way, I was able to successfully load a GG code. I guess you can't store the .txt files in the route of the card?
Hmmm ... unfortunately, I don't see any reason why loading of GG codes shouldn't work, regardless of where exactly your TXT file is stored. As a matter of fact, I tried it with a TXT file in the root directory of my CF card yesterday, without issue.
The PowerPak hardware really
is picky about what type of CF card is used, I guess.
"Pentecost" ...
For me (and you), it's more likely going to be a PowerPak festivity.
Voilà!
SNES PowerPak Firmware v3.00 "MUFASA"Installation instructions (copied from the Readme):
- Determine the current version of your firmware. You'll see the version number once you power up your SNES PowerPak. If it says, "Boot ROM v1.0X" (where X can be any number), then you have a version 1 firmware. If you spot the word "SIMBA" anywhere on the screen, then you have a version 2 firmware.
- Copy the contents of <this release's archive root>/POWERPAK (sans the SAVES subfolder) to the POWERPAK directory on your CF card, replacing any existing file(s) (i.e., TOPLEVEL.BIT).
- Browse to <your CF card root>/POWERPAK. Delete SI.MAP. Then, rename the SIvX.MAP file that matches your installed firmware number from step 1 (i.e., SIv1.MAP for a version 1 firmware, and SIv2.MAP for a version 2 firmware) to SI.MAP.
- Power on your SNES PowerPak, and follow the on-screen instructions.
- After the upgrade procedure has completed successfully, you can safely delete all *.TXT and *.MAP files from <your CF card root>/POWERPAK.
Have fun!
Once the PowerPak has successfully flashed its update, do we need to keep the TOPLEVEL.BIT, UPDATE.BIN or UPDATE.ROM files? Also, how is the PowerPak to know whether it has the latest firmware without an Internet connection?
Great Hierophant wrote:
Once the PowerPak has successfully flashed its update, do we need to keep the TOPLEVEL.BIT, UPDATE.BIN or UPDATE.ROM files?
You can delete UPDATE.BIN, but you have to keep the other two.
Here's the list of files/subfolders in the POWERPAK folder that are required for v3.00 to operate correctly:
Code:
SAVES
THEMES
ERROR.LOG
LASTGAME.LOG
POWERPAK.CFG
TOPLEVEL.BIT
UPDATE.ROM
Great Hierophant wrote:
Also, how is the PowerPak to know whether it has the latest firmware without an Internet connection?
When you check for an update via the settings menu, the PowerPak compares the version/build it's running on with that in UPDATE.ROM. If the latter is newer, it launches the update flasher. Of course, you still need an internet-capable device to get the update in the first place.
Thanks Ramsis for the new FW! Playing SPC and instantly returning to file selection is AWESOME!
Thanks for the update. Going to have to check this out later.
Hey Ramsis,
Thanks again for the great firmware update. As a user from the alpha stages I look forward to all of your updates as it gives my PowerPak new life every time. I do have one suggestion, however. I was going through the options and the menu selection keys are colored, namely to the Famicom colors that are on the controllers. These are on Pal and NTSJ controllers, but for those of us in the NTSC (America) regions, we get two different shades of blue. Here's an example..
As a result, I didn't really know what button I was pressing to navigate the menus, as I only have those two shades of blue, and if there were letters underneath the colors I couldn't see them.
My recommendation would be to throw a solid black letter on top of the color so that all users could tell which button press did what. Other than that, speed seems to have increased and you keep bringing new features to this "old" cart. Keep up the good work and thanks again!
effowe
Hey guys, glad to hear my work of long years is still appreciated.
effowe wrote:
I was going through the options and the menu selection keys are colored, namely to the Famicom colors that are on the controllers. These are on Pal and NTSJ controllers, but for those of us in the NTSC (America) regions, we get two different shades of blue. Here's an example..
(...)
As a result, I didn't really know what button I was pressing to navigate the menus, as I only have those two shades of blue, and if there were letters underneath the colors I couldn't see them.
Indeed, the standard theme (MUFASA.THM) uses SFC/PAL SNES joypad button colors only. If you have any trouble, please try using another theme with North American-style button graphics (like FOURDOTS.THM, MARIO.THM or RETROUSB.THM).
Thanks!
Ramsis
Hey Ramsis. I just updated to the latest FW and it looks/works great! I just wanted to give you a big THANK YOU again for your work. Your menus are a million times better than the stock menus!
Just curious... Any chance of working on the NES PowerPak?
Ziggy587 wrote:
Hey Ramsis. I just updated to the latest FW and it looks/works great! I just wanted to give you a big THANK YOU again for your work. Your menus are a million times better than the stock menus!
Thanks, I'm glad to hear you enjoy the new firmware!
Ziggy587 wrote:
Just curious... Any chance of working on the NES PowerPak?
Unfortunately, I don't own one of those, so I don't even know about its drawbacks. The main enhancement of my SNES PowerPak firmware, however (i.e., horizontal hi-res), can never be achieved on the NES anyway, so there really isn't much point in working on it at all IMHO.
Ramsis wrote:
The main enhancement of my SNES PowerPak firmware, however (i.e., horizontal hi-res), can never be achieved on the NES anyway, so there really isn't much point in working on it at all IMHO.
The corresponding upgrade for the NES would be using a proportional font.
Last time I looked at this, it looked like that wouldn't even require a full firmware upgrade, just replacing a few of the individual modules (?.MAP) ... although reflashing the actual bootloader would be an obvious way to polish it up.
lidnariq wrote:
Ramsis wrote:
The main enhancement of my SNES PowerPak firmware, however (i.e., horizontal hi-res), can never be achieved on the NES anyway, so there really isn't much point in working on it at all IMHO.
The corresponding upgrade for the NES would be using a proportional font.
Last time I looked at this, it looked like that wouldn't even require a full firmware upgrade, just replacing a few of the individual modules (?.MAP) ... although reflashing the actual bootloader would be an obvious way to polish it up.
The modules are fairly small though (1 KB), so can't do a whole lot within them. Could also put the replacement menu in part of the 512 KB PRG SRAM (and optionally upload a new FPGA config as well). Some juggling would have to be done to actually load the games though (unless the new menu hands over control to the old system just before the game is to be loaded, which would be a good idea for compatibility reasons as well).
While reflashing the bootloader would make things easier, I think it would be a major barrier for people to update.
thefox wrote:
The modules are fairly small though (1 KB), so can't do a whole lot within them.
Aw, man, why does CardLoadModule have to only use the 1KiB from $0400 through $07FF?
Ramsis wrote:
The main enhancement of my SNES PowerPak firmware, however (i.e., horizontal hi-res), can never be achieved on the NES anyway
Antialiased 4x8 pixel text can though, provided you're on a mapper that supports 16K of CHR RAM like mapper 96 (Oeka Kids).
If the NES had a power-on self-test
Code is now on
GitHub.
Feel free to download the
latest build #11314. If you're already running v3.00 build #11310, simply copy UPDATE.ROM to your /POWERPAK folder (overwriting the existing file), go to the settings menu, and select "Check for firmware update". Otherwise, i.e. if you're still running v1.0X or v2.0X (non-beta), proceed as described in How To Use.txt.
The file browser is getting a major overhaul: All file browsing routines (there had been 4 of them by now) have been merged into a single subroutine. The stack is now used to keep track of directories visited, which will eventually allow me to implement convenient stuff like placing the cursor on the subdir that was visited last as soon as the user returns to the parent directory.
Please check out the latest build, available here:
https://github.com/Ramsis-SNES/snes-powerpak-firmware-v3/blob/master/src/out/POWERPAK/UPDATE.ROM (just click on the "Raw" button to download the update ROM, put it in the /POWERPAK folder on your CF card (overwriting the existing file), then go to the PowerPak's settings menu, and select "Check for firmware update").
It would be great if as many people as possible could thoroughly test this build. Let me know if you encounter any irregularities (apart from a hidden /POWERPAK dir and an otherwise empty root directory -- this might cause problems in the theme and SRAM browser at the moment).
Thanks!
I'm already on some version of the "Simba" firmware. (I can't check the exact version number for several hours.) Would I need to first install intermediate updates in order to test UPDATE.ROM?
Ramsis wrote:
if you're still running v1.0X or v2.0X (non-beta), proceed as described in How To Use.txt.
How To Use.txt wrote:
Steps necessary:
1. Determine the current version of your firmware. You'll see the version number once you power up your SNES PowerPak. If it says, "Boot ROM v1.0X" (where X can be any number), then you have a version 1 firmware. If you spot the word "SIMBA" anywhere on the screen, then you have a version 2 firmware.
2. Copy the contents of <
this release's archive root>/src/out/POWERPAK (sans the SAVES subfolder) to the POWERPAK directory on your CF card, replacing any existing file(s) (i.e., TOPLEVEL.BIT).
3. Browse to <your CF card root>/POWERPAK. Delete SI.MAP. Then, rename the SIvX.MAP file that matches your installed firmware number from step 1 (i.e., SIv1.MAP for a version 1 firmware, and SIv2.MAP for a version 2 firmware) to SI.MAP.
4. Power on your SNES PowerPak, and follow the on-screen instructions.
5. After the upgrade procedure has completed successfully, you can safely delete all *.TXT and *.MAP files from <your CF card root>/POWERPAK.
Thanks.
I copied SIv2.map to SI.MAP, ran the update, and now I'm on
MUFASA! (Ooh, do it again) build 11310.
The use of red and blue buttons on the title screen of 11310 is kind of confusing, seeing as my controller is a U.S. one with purple A and B and lavender X and Y.
...and now I'm on 11325.
tepples wrote:
The use of red and blue buttons on the title screen of 11310 is kind of confusing, seeing as my controller is a U.S. one with purple A and B and lavender X and Y.
Don't forget that you can switch to a different theme with US-colored buttons at any time.
tepples wrote:
...and now I'm on 11325.
Great! Feel free to report any oddities you might encounter (especially in the file browser).
News: When you return to a directory's parent directory, the cursor will automatically be placed on the subdirectory you left for convenience.
Also, you can now flip through the "pages" of a directory indefinitely (i.e., no more forced "stop" at the beginning/end of the file listing).
Download:https://github.com/Ramsis-SNES/snes-powerpak-firmware-v3/blob/master/src/out/POWERPAK/UPDATE.ROMAs always, just click on the "Raw" button to download the update ROM, put it in the /POWERPAK folder on your CF card (overwriting the existing file), then go to the PowerPak's settings menu and select "Check for firmware update". After reflashing is complete, please check out the new file browser, and don't hesitate to let me know if you encounter any issues.
Hi, I've installed your MUFASA firmware and it's awesome. But I've formatted the CF card and now always I get the error "Powerpak: File not found"
I backed up the CF to my hard drive, I copied the files back to the CF and keep getting the error.
Do you have any clue? Which files are necessary to copy to the CF?
Thanks in advance.
Hi, solbad03!
Hm, that's odd. To start afresh (assuming you're already running v3.00), format your CF card with FAT32, create a folder named POWERPAK, then copy all of
this stuff (except for the two SIvX.MAP files, which are only needed for the initial upgrade to v3.00) into it.
This is what your POWERPAK folder should contain for v3.00:
Code:
/SAVES
/THEMES
ERROR.LOG
LASTGAME.LOG
POWERPAK.CFG
TOPLEVEL.BIT
UPDATE.ROM
Hope that helps!
I made a video that shows the upgrade procedure from v1.0X to the latest »MUFASA« build, and some of the new firmware's features.
Link:
https://youtu.be/4lJ6yjhI7zQEdit: And here's another video featuring not one but TWO SNES PowerPaks, and some hardware stuff. :3
Link:
https://youtu.be/l7hEmTKA1Cc
Ramsis wrote:
It would be great if as many people as possible could thoroughly test this build. Let me know if you encounter any irregularities
Hey, Ramsis. I just wanted to let you know that I've been using your current firmware for a while not and haven't had any issues yet. It's been working perfectly for me. Thanks again for this!
Glad to hear that, Ziggy587. Thanks for the feedback!
I often get a black screen when powering up, which clears up after a one or two resets. (1/1/1 console, firmware build #11331) Does a newer build fix this?
tepples wrote:
I often get a black screen when powering up, which clears up after a one or two resets.
Hmmm, strange. How often is "often?" Does it also happen without a CF card inserted? Have you tried using a different size/brand of CF card?
I haven't been able to reproduce it on demand. I guess it happens only on some days. If I can reliably reproduce it, I'll let you know.
As of the latest build, you can jump to the next/previous SPC file with R/L (among other stuff). It's been tested thoroughly and is confirmed working well, so don't hesitate to
download and install the update.
Attachment:
spcplayer-rl2.png [ 766.35 KiB | Viewed 1678 times ]
tepples wrote:
I often get a black screen when powering up, which clears up after a one or two resets. (1/1/1 console, firmware build #11331) Does a newer build fix this?
i rarely get mine to give me the menu on the first power on. although for my cart i always had issues doing anything on it. there are no errors either. even before i updated with ramsis firmware i had that issue with a black screen. I was able to update normally to the mufasa firmware and it works great. i had no issues except for 1st power on that you mention here. I am thinking its probably due to the CF card im using or a dirty cart connector. I am VERY certain its a CF initialization issue.
Edit: snes is a 2/1/1
I just happened to remove the card from the cart and powered on and it worked on 1st boot. removed the cart and reinserted acting like I switched games and it still booted on 1st boot. didn't remove the cart. turned off the console and inserted CF card powered on and black screen hit reset and everything came up.
Hey ramsis, great stuff! love the latest update. Im confused on how to get back to the main menu when playing a game. What a great and useful feature.
