Behold, I give you:
FDS on PowerPak
Consider it a proof of concept at this point. Few games work, I'm still trying to figure out why. I just wanted to show that it's doable. It uses an unmodified bios; the low level disk stuff is emulated, I didn't need to write new loading routines. I'll need to do it eventually though, to handle disk switching.
Very cool, I hope this can be integrated into the BIOS sometime.
Impressive. Please see this all of the way through. There have to be some FDS features that are impossible to make work on the PowerPak, right?
Can't do FDS audio. Saving is not going to be easy.
Can't wait to try this out - thanks!
Very cool loopy. I never expected anyone to take on the FDS for the PowerPAK.
This is a very cool hack. I didn't see why it couldn't be possible -- the PowerPak mapper is configurable enough to give you the RAM and the timer IRQs of the FDS.
On my Famicom+PowerPak setup, several of the games (Super Mario Bros., etc.) have glitchy CHR graphics, or just general PPU screw-ups. SMB2's jumping is all screwy too. I'm not asking you to fix that, but I wonder what could be causing such strange bugs...
At least many FDS games' intro scenes can be run on the PowerPak now.
Whoa. [/keanu] Here's something I didn't think was possible. Could FDS audio be achieved even via mods?
-Rob
Well bunny DID say that the leftover pins on the fpga were routed to the exp pins on the cart......so I guess it's possible?
If someone still has the file(s) I'd love to check it out. Unfortunately it no longer seems to be available from the original location
I have voluntarily removed said files to comply with forum policy.
FDS BIOS is copyright Nintendo.
Will you be able to put it back up later by requiring the user to inject the FDS bios themselves?
Since when the FDS bios is a commercial game ?
The FDS bios is a copyrighted work by Nintendo.
Copyrights apply to software.
How long does a software copyright last? wiki said 70 years....
the system is over 20 years old. 50 more to go
Wikipedia wrote:
Copyright does not cover ideas and information themselves, only the form or manner in which they are expressed. For example, the copyright to a Mickey Mouse cartoon restricts others from making copies of the cartoon or creating derivative works based on Disney's particular anthropomorphic mouse, but doesn't prohibit the creation of other works about anthropomorphic mice in general, so long as they're different enough to not be judged copies of Disney's.
Does this prevent people to use anything inside the FDS bios ? It's not very clear. I admit that I am using some routines I got from the FDS bios that does clever $2007 writes I found really clever and usefull. Should I modify my code so that I use my own version of them, making "my own work with about an anthropomorphic mice" ?
And how many lines of code have to change so that it's not considered the same ? This is really ambigious, especially about programming.
Also I don't see how can anyone own intellectual propriety on the FDS bios as there is no characters, story or gameplay element. Only really basic graphics and music, and the Mario character, that I'm not going to steal.
An interesting question. I wonder what the legality of NSF and SPC rips is. Are they banninated too?
Derivitive works, since they incorporate machine code from the game ROM. Plus of course the music itself is copyrighted.
I wonder when this graph will reach its limit and copyright length will go off into infinity... Someone should do a logarithmic regression.
How does it comes the name of a private company comes on a copiright act ? Since when private companies make the law ?
Bregalad wrote:
Since when private companies make the law ?
Since they started buying politicians off (bribing).
I put the file back, you'll have to find it yourself. I tweaked the bios to let you watch mario+luigi being silly before you "insert" a disk
(No, I haven't yet debugged the other problems with it)
loopy wrote:
I tweaked the bios to let you watch mario+luigi being silly before you "insert" a disk
Thanks!
I can spend upwards of 20-30 min when I'm bored watching those two go at it. Too bad it's not a screensaver.
Bregalad wrote:
How does it comes the name of a private company comes on a copiright act ? Since when private companies make the law ?
That's Sonny Bono the person. He was a House representative who died in a skiing accident just before the law was passed.
wikipedia
I'm reeeeeally upset this was discontinued. I wanna play Doki Doki Panic and SMB2 Japan on my Powerpak for God's sake!
Updated.
There's still a lot left to do, but I fixed a major loading bug so I think most single sided games will work now.
Enjoy.
P.S.
It's not discontinued
Glad to hear work on it continues. =)
Another update. Automatic disk switching is implemented, more games should work now. Writing isn't done yet. If a game tries to save, it will probably fail.
Awesome! Super Mario 2 (Lost levels) on the NES! Thanks a lot loopy
Ok, saving is fixed (it won't save back to CompactFlash though). Most games should be playable now.
Bug reports welcomed.
That's awesome, loopy!
When you say saving is fixed but it won't save to the Compact flash, it sounds contradictory. Could you explain what you mean?
Thanks!
-Rob
When a game saves, it's only writing to a disk image in RAM, not to the card.
I have an idea...maybe the existing SRAM-saving code in the boot ROM could be modified to save changes to the FDS image? All it would need to do is copy from PRG-RAM to .NES, instead of SRAM to .SAV.
It would likely require bunnyboy's involvement/source code, though, and most people don't have a means of updating the boot ROM...
I imagine games that require you to switch sides to continue (such as Zelda) don't work right? Since Zelda runs the attract mode until you insert a disk opposed to waiting for you to push Start and then requesting a disk side change.
Zelda works just fine. I have the "disk inserted" status bit always toggling, so any game waiting for a disk change should get triggered.
Do you plan on releasing the source files? I'm curious how much logic it takes up and whether it would fit on a CPLD project.
2600 wrote:
Do you plan on releasing the source files? I'm curious how much logic it takes up and whether it would fit on a CPLD project.
I would be interested about the "logic" emulating the $4xxx registers. What about the BIOS?
I am really interested in trying this out when I get back home. Has anyone tried out V.S. ExciteBike?
what does vs exitebike have to do with fds?
VS ExciteBike is on the FDS system. He didn't mean the arcade NES thing.
I got this working and it's pretty awesome to play FDS on NES (especially now that my NES is RGB modded with audio adjustment knobs). I do wish the FDS sound channels were implemented (a good example is Doki Doki panic where the sound effect when lifting things is missing).
I am curious on why saving doesn't seem to work for me. I played a couple of levels of Castlevania, and as a test, I died on purpose giving me the save option which it did. Chose my save file after the title screen and it worked. But turning off the game seems to not save it to the FDS image.
loopy wrote:
Ok, saving is fixed (it won't save back to CompactFlash though). Most games should be playable now.
Bug reports welcomed.
LN
Fx3 wrote:
I would be interested about the "logic" emulating the $4xxx registers. What about the BIOS?
I added a register at $4027 for choosing the disk side. Reading and writing was a little tricky. PowerPak's FPGA does not control A0-A12 of its PRG RAM, so it's not possible to map any arbitrary byte to the disk read port ($4031). A proper address needs to be requested by the NES. I handle this by patching a load instruction in the BIOS, replacing the address with the current disk pointer. Thus,
$F4EF: LDA $4031 ;read byte from disk
PowerPak changes this to LDA $XXXX (E000-FFFF), maps part of the disk to the BIOS area on the next read, and increments the disk pointer. Writing works similarly. Of course, this isn't the only way to do it, maybe I made it too complex
You could simplify the FPGA logic and write more BIOS code instead.
The BIOS was not modified much. I added the disk switching, and removed disk interrupts and some delay code, which aren't needed anymore. Real saving to CF will need to be done as BMF54123 wrote above.
So, the new PowerPak mapper update includes FDS and NSF files, but I seem to be having far more trouble making games load than with your older FDS->NES file converter. For example, Konami games keep resetting to the FDS BIOS screen rather than loading up as before, and Zelda gives Errors 5 and 21 repeatedly.
Granted, I'm using a Boot Rom v.1.0 PowerPak; is the reason for this incompatibility solely from the different boot ROM version? In other words, exactly what does the new FDS mapper require in the newer Boot ROM?
I think it's better if you not remove older FDS converters from your site, as we can't all get the ROM in our PowerPaks updated in as timely a manner as we'd like.
(Oh, the NSF player looks and works great, but still doesn't recognize the buttons on Famicom expansion joypads...)
Hmm, I don't have any of those problems. I also have boot rom v.1.00. There weren't any big changes between mappers. Disks were moved to the upper half of ram, could it be a ram fault?
I put the old converter back, and fixed FDS and NSFs to read expansion joypads.
One thing that I noticed from the early versions of your FDS converter was that in some games, graphics loaded up glitchy, alongside the games that would reset randomly or have checksum errors, etc. One thing I suspected was a dirty/unreliable data connection, since data is being copied from the cart to the PPU/CPU, and back to RAM on the cart. So adaptors, and noise on the data lines can screw up the process in many points along the way. But should it be this bad? Just to check, during "BIOS" loading, are all interrupts masked and the PPU turned off? That's the only thing I could imagine screwing up all these data transfers. Or else perhaps other errors when loading the FDS image into RAM/moving it around on the PowerPak.
Any ideas why I would be getting a constant loop of "Set side B / Error 21"s? And had you considered a different way of changing disk sides, such as getting the user to press buttons in combination on controller 2, or something like that?
I'll try to clean the contacts on my cartridge and adaptor in the meantime.
Now with audio!
I tried to match the output level with VRC6. Let me know if anything sounds "off".
ccovell wrote:
Any ideas why I would be getting a constant loop of "Set side B / Error 21"s?
I changed the ram access timing to get it working better on my PowerPak. Maybe this fixes your problem as well.
Well I'll give it a try but I don't know if I'll be able to tell unless it's waaay off. I'm also wondering what games would be best at using the sound channel extensively.
I am pleased to say that the FDS mapper works with boot rom 1.00 and most games I tried. I tried Zelda 1 & 2, Super Mario 1 & 2, Castlevania, Galaga, Kid Icarus, Jackal, and Zanac. I got partial success with Mario Bros and Metroid would not load a game or would be unplayable.
Yay! Finally I get to play FDS games with sound on my Powerpak! :P
But as awesome as this feels, I can't help feeling sad that the automatic disk switching just won't allow me to watch the intro to games like Zelda and Doki Doki Panic, which only show the intro until you change the disk side. Would it be possible to workaround this in some practical way, or is hacking the FDS file itself the only viable option?
If the console polls the controller continuously, toggle "hot keys" could work. With a watchdog after a "disk set" read, it shouldn't interrupt game play.
Hm.. it might be doable. Assuming NMI is enabled while games wait on the disk, you could stick some button checking code inside the BIOS NMI handler.
The automatic switching is convenient most of the time though. Maybe hold down a button to suppress automatic switching while you watch intros?
I meant reading the pad in hardware, so a shift register -> comparator -> toggle-FF. No CPU time stolen, but pad reading a necessity.
Heh... that was easy. Hold down select to keep the disk ejected. Tested on Zelda and DokiDoki.
I would like to hear the expansion sound, but I have a problem in that I am using a PowerPak with a Famicom AV and a 72 to 60 in converter. I know that on Famicoms, the sound is sent from the console to the cartridge on pin 45. If the cartridge does not have expansion sound hardware , it connects pin 45 to 46 and the sound is sent back to the console for output. If the cartridge has expansion sound hardware, the NES sound on pin 45 is mixed with the cartridge audio inside the cartridge and the result is output on pin 46. (All pins in this paragraph are Famicom pins)
The PowerPak outputs sound on NES Cartridge Pin 54, but does not mix the sound from the cartridge because the NES, unlike the Famicom, cannot send the sound out on the cartridge connector. Cartridge Pin 54 is connected to Expansion Pin 9, which is connected to Expansion Pin 3 on the mod through a 47K resistor.
Can I do the same thing with my 72 to 60 pin converter? Famicom Pins 45 and 46 are connected together on the converter as they would be on a Famicom cartridge that does not have extra sound hardware. If I soldered a 47K resistor between NES pin 54 and Famicom pins 45 & 46, would I get the proper sound? Does it matter that the Famicom would use an output and the NES uses an input?
The select feature works nicely to stop the disks from loading on Zelda. Castlevania II also seems to work with the FDS mapper.
Loopy, the FDS audio sounds pretty good. I tried it on Palutena no Kagami, Zelda, Zelda II, and Yuushi no Monshou.
However, on my setup (Famicom Titler, 72-60-pin adaptor) the same problems exist with many FDS games. Some get to the title screen, but then display a repeated "Error 21", most Konami games simply reset to the FDS BIOS after the Nintendo copyright message, and some games show garbled CHR or NAM table graphics. Obviously the PPU and/or CPU is getting some kind of interference while loading games.
My wild theories: 1) The expansion pins on the PowerPak need to be grounded or something because their being connected to audio lines causes interference with PPU/CPU data lines. This could be true in some sense because of the glitches in your early VRC6 mapper whenever a sound plays, and because I see interference on-screen whenever the pitch changes in the FDS channel (only when the PowerPak expansion pin is connected directly to my TV's audio with no resistor attached.)
2) Games or the BIOS are somehow overwriting the FDS disk image currently loaded, causing the first *HVC-NINTENDO* identifier to be unrecognized. I don't know how true this might be because I don't know if your mapper stores them as "RAM" or "ROM" in the PowerPak's eyes.
Next, I tried out the NSF player for the FDS & VRC6, and both still have very poor sound, with garbled audio (sounds like the volume is being repeatedly muted and reenabled at some frequency (30Hz?), or with audio note pitch sounding completely off, or with the NSF simply crashing. My only guess with this one is that the NTSC/PAL timer may be just wrong. How about an NTSC-only mapper, with no timers interfering with playback? Since the FDS and VRC6 game mappers sound so good, it's a mystery why the NSF players would act all weirdly and sound garbled.
Anyway, on a positive note, the PowerPak used in my Twin Famicom loads FDS games just fine...
I can't play NSF's on my PowerPak without it freezing (screen says File not found). I am using the Kevin Horton collection.
any luck with getting FDS saves to write to the PowerPak? I wouldn't mind playing Metroid on FDS
I am running my power pak (modded with graphics fix) on my RGB modded NES
I had the same problem earlier, and it seems I had to rename nsf.nes to NSF.NES (that is, capitalize it) to make it work.
eastbayarb wrote:
I can't play NSF's on my PowerPak without it freezing (screen says File not found). I am using the Kevin Horton collection.
any luck with getting FDS saves to write to the PowerPak? I wouldn't mind playing Metroid on FDS
I am running my power pak (modded with graphics fix) on my RGB modded NES
The PowerPAK FDS already supports saving to disk. To save, after saving in game you need to hold RESET for 4 seconds or so and it'll ask you which disk file you need to write back to.
[/quote]
The PowerPAK FDS already supports saving to disk. To save, after saving in game you need to hold RESET for 4 seconds or so and it'll ask you which disk file you need to write back to.[/quote]
do you have to create a .SAV file first just like with regular NES games?
Bananmos wrote:
I had the same problem earlier, and it seems I had to rename nsf.nes to NSF.NES (that is, capitalize it) to make it work.
I did that initially and it didn't work. Do I have to convert .NSF to .NES first or can I just have a bunch of NSF's in a directory?
eastbayarb wrote:
do you have to create a .SAV file first just like with regular NES games?
No, you save to the .fds file.
eastbayarb wrote:
Bananmos wrote:
I had the same problem earlier, and it seems I had to rename nsf.nes to NSF.NES (that is, capitalize it) to make it work.
I did that initially and it didn't work. Do I have to convert .NSF to .NES first or can I just have a bunch of NSF's in a directory?
Just a bunch of NSF's. You don't need to convert.
I have the NSF file named NSF.NES but still getting the problem with the screen freezing with garbled graphics/text and saying "file not found"
As far as saving for FDS games, for instance, Castlevania, as a test, I played through level one, and died till it gave me the option to save and chose to save. Then it kept on resetting, telling me to change the disk side (it did this automatically). I held down the reset for 4 seconds (tried it for longer as well), but there was no option to save the game to the FDS file.
Incidentally, anyone get the FDS version of Metroid to work? I loaded it up and just freezes when you first start from the beggining of the game
Metroid works great here. Maybe you have a bad dump or a corrupt file.
MottZilla wrote:
Metroid works great here. Maybe you have a bad dump or a corrupt file.
What's the name of the dump you are using? Also as I stated, I tried to save in Castlevania, as well as Kid Icarus, and after I saved and held Reset on the system for about 4 seconds, it didn't give me the option to save the game to the FDS file (just went to the PowerPak start up screen).
Metroid v1.01 (1986)(Nintendo).fds
CRC32: 8F10CDD1
Are you sure you are using the most recent FDS driver file and have a patched FDS bios? Other than those I don't know what to tell you other than it will ask you to save the FDS if the game trys to write to it and you hold down reset to return to the main menu of teh powerpak. It might not ask you first thing but maybe it's after you push A once or something.
I have the latest powerpak 1.20 mapper files, FDS driver and patched FDS bios in my /powerpak directory. Metroid FDS version still just freezes right before you start the game, and the option to save to FDS after holding reset for 2-3 seconds just doesn't come up. I also reformatted my CF card (FAT and FAT32) as well as tried another CF card.
I have an RGB modded NES, and PowerPak (2nd revision)
has anyone else gotten the FDS version of Metroid to work and/or FDS saving to work?
eastbayarb wrote:
I have the latest powerpak 1.20 mapper files, FDS driver and patched FDS bios in my /powerpak directory. Metroid FDS version still just freezes right before you start the game, and the option to save to FDS after holding reset for 2-3 seconds just doesn't come up. I also reformatted my CF card (FAT and FAT32) as well as tried another CF card.
I have an RGB modded NES, and PowerPak (2nd revision)
has anyone else gotten the FDS version of Metroid to work and/or FDS saving to work?
I had the same freezing problem, until I changed some memory timing (as mentioned
here). Maybe with some adjustments I can get it working for you.
Actually, my whole problem all along was that I was using the old FDS to NES converter, and putting the resulting converted file onto my CF card. AFter finally just putting the .FDS images on my CF card, now Metroid, and FDS saving actually works.
Oh jeez... yeah, that explains a lot
I'm glad it's finally working.
loopy wrote:
Oh jeez... yeah, that explains a lot
I'm glad it's finally working.
Yea so am I. For those interested, I performed the extra sound mod with a 47k ohm resistor and it works great - Castelvania III (J), Doki Doki Panic, and others really take advantage of it
The above mentioned dump of the FDS version of Metroid doesn't (playably) work for me, using the latest FDS mapper (the one with FDS sound). It gets all the way to the name entry screen, but when you try to start a game it says "omachi kudasai" in hiragana (light blue text), followed by a grey screen with white text saying something about BCRS ("BCRS yuyotsu" (yuyo is lowercase katakana, is it garbage?) or something) and some katakana ("set B side" or something), then the BCRS/katakana text glitches/turns light blue(black background) for a second before jumping to a black screen. Resetting at this point gives a glitched FDS BIOS followed by a glitched "Family Computer" screen (halfway down the screen, doesn't scroll up) (glitched BIOS screen remains visible), but the game seems to start as before after that.
(with some dumps of Metroid I can get all the way to the first screen with some finagling, but the level is horribly glitched and Samus and the enemies can't move)
As a side note, I've noticed Puzzle Boys freezes during saving whenever I try to save, has anyone else had that problem? (happened once to me...and boy is it a long way to that first save point to try again, unless there's something I don't know... I didn't try just saving to the FDS file anyway to see if it worked...)
EDIT: Tried it this morning, no BCRS screen, just a frozen black screen... one time the BCRS screen appeared with a black background... and now it's behaving as above again...weird.
Had the same problems as the person above. I talked to Loopy got him to add some more delays. Metroid works flawless now.
edit: loopy said he updated his website to.
Thanks! It seems to run a *bit* better for me...sorta. When I first tried it, it got (on the "real" dump or whatever) to the frozen gameplay screen I mentioned happening with some dumps earlier. This happened the first two times I tried it, but lately it's just been doing the same thing it did before. I tried to capture the frozen gameplay screen, but I haven't been able to get it to reappear so far. It still has saving issues with Lutter and Puzzle Boys.
Just for the hell of it, I've posted some videos of various issues I've had with my Powerpak I haven't seen reported elsewhere, in case it's somehow related. Aside from these, the only issues mine has (that I'm aware of) are "jumpy" statusbars (or whatever) in SMB3/Megaman 3/TMNT2 (these randomly appear, and usually go away if I restart the game after having the Powerpak on for a while).
Metroid FDS:
http://www.youtube.com/watch?v=jO8m75qxLok
Lutter (JPN):
http://www.youtube.com/watch?v=mY2EOXOoq9c
-Weird blue noise on the screen just before it freezes while saving. Same dump works fine in Nestopia.
Kirby's Adventure:
http://www.youtube.com/watch?v=p-ROE36jCUI
-Various palette issues (seems to replace certain colors with white sometimes). Took me forever to make it happen ingame.
Noah's Ark (PAL):
http://www.youtube.com/watch?v=M0KzyIgVvss
-Ingame horizontal lines similar to what happened for me in early versions of the VRC6 mapper. (Running on NTSC NES)
I'm not complaining about these, just posting in case it helps
EDIT: Also, in the Earthbound prototype, 16x32 pixel (horizontal) artifacts appear on screen when you bring up the Talk/Goods/etc menu. They seem to appear in fixed locations, like once per screen or something. These artifacts do affect scenery, and they can make previously passable areas unpassable (and the other way around). I dunno if it makes the game unbeatable or anything though, it's actually not very annoying.
you suree you downloaded the latest version of the fds mapper? That should fix metroid fds (or maybe loopy needs to add even MORE delays)
Jeroen wrote:
you suree you downloaded the latest version of the fds mapper? That should fix metroid fds (or maybe loopy needs to add even MORE delays)
Yep, I checked the checksum of F.MAP on my Powerpak and the one currently on loopy's site, they're identical. Guess I'll reformat my CF card just to make sure that's not the prob, I'll post back here in the unlikely event that it is.
Well, RetroUsb has their own mappers for FDS now. Haven't tried them yet though. It'll be interesting to see which has less bugs... or maybe they just ripped loopy's work off?
Bunnyboy runs RetroUSB. I'm sure loopy gave him permission to use his FDS mapper. I don't think anyone was "ripped off".
Oh man that just made me LOL
little off topic but speaking of rip-offs did neoflash ever come out with theres?
peppers wrote:
little off topic but speaking of rip-offs did neoflash ever come out with theres?
hell no. just like thier Mega Drive flash cart (which hasn't seen the light of day after litterally years since it's anouncement), the Neo Flash NES flash cart has had no real updates beyond some pics. Dr Neo hasn't released an ETA on this thing or any of the other supposed projects in development. All they care about is their MANY Nintendo DS flash carts, it seems.
I would just try to score a Power Pak if I were you and not hold your breath for a Neo Flash NES/Famicom product. Too bad, because I have their PC Engine flash cart and I love it.
Sorry for ressurecting an old post, but of all the games I have tried, Metroid refuses to work for me. I have used mappers from 1.20 to 1.35b2, including loopy's latest mappers, every .fds of Metroid I can find, a front loading NES and Famicom AV. My PowerPak was truly a first run cartridge but has bootrom 1.11 and bunnyboy implemented the resistor fix. Neither console was modified except to enable external audio.
The result is pretty much as MrPlacard describes :
Quote:
The above mentioned dump of the FDS version of Metroid doesn't (playably) work for me, using the latest FDS mapper (the one with FDS sound). It gets all the way to the name entry screen, but when you try to start a game it says "omachi kudasai" in hiragana (light blue text), followed by a grey screen with white text saying something about BCRS ("BCRS yuyotsu" (yuyo is lowercase katakana, is it garbage?) or something) and some katakana ("set B side" or something), then the BCRS/katakana text glitches/turns light blue(black background) for a second before jumping to a black screen. Resetting at this point gives a glitched FDS BIOS followed by a glitched "Family Computer" screen (halfway down the screen, doesn't scroll up) (glitched BIOS screen remains visible), but the game seems to start as before after that.
(with some dumps of Metroid I can get all the way to the first screen with some finagling, but the level is horribly glitched and Samus and the enemies can't move)
I have attached a photo of the screen showing what happens at absolute best, the first Brinstar screen is shown but Samus cannot move due to the overlayed blocks. Can anyone offer a solution?
Just to add some spice to this convo:
I had some of the metroid .FDS files that are floating around of the net tested with my real FDS RAM adapter + a FDSLDR cable and the result was quite disappointing. Out of 5 images only two worked properly.
I hope you find that informative.
Because FDS media is writable, there needs to be some defined way to hash .fds files to make sure the read-only portion is correct. Fortunately, as I understand it, all read-only files precede writable files. With ROMs, it's easier because the entire PRG and CHR can have CRC, MD5, SHA-1, or SHA-256 applied to it. So has the emulation community settled on a way to "normalize" FDS dumps to something hashable?
The only way to do that is to take verified clean disk dumps, directly from sealed fds boxes and hash once the file header is added. In my opinion, the fds file header is useless, a check of the file size should tell you how many shoes the disk has. Since there was no standard way to write save data to disk, the best way to reflect disk writes is to use something like an ips file that keeps track of the bytes changed. Nintendulator does that. The fds files I tried were not clean, but they worked in that emulator.
Some games like The Legend of Zelda write to the disk once you delete a character file. They can look clean. Other games like Metroid do not write to the disk until you start a game, and therefore cannot look clean by playing the game itself. One solution would be to delete all three characters, then do file comparisons after you begin a new game in slot one, then two and three.
Keep in mind that the FDS can (should, actually) only write a very specific area of the disk. If Nintendo put hardware on some of the units to make sure they could write only at the end of the discs, you could use that information as reference and hash only the pertinent part of the disk.
I HONESTLY believe that EMULATOR or GAME COPIER HEADERS should NOT be into the hashes for ROM files as they're NOT part of the games in question. Maybe it would be PERFECT if ROM management utilities would INTERPRET the actual EMULATOR/COPIER HEADERS and hash the real contents of the files then correct any wrong HEADERS as needed.
All my fds roms play just fine on my powerpak. And i have almost all of them.
I wonder somehow if my PowerPak is less reliable in this area, as it was in the first batch sold.
do not use lexar compact flash cards. sandisk and the ones given from retrousb are the best cards to use.
formatted fat32 allocation units 4096. highest i've gone is 4GB in size
It my sound ridiculous but i have major problems with using compact flash cards under windows vista and 7. I feel like a broken record on the board because thats all i talk about. from what i had learned about the powerpak is that they are very picky about ROMs when it comes to loading the game. its either bad headers or wrong mapper assigned to the rom. it took me a few weeks to figure it out slowly chipping away at it trying different ROMs checking the card for errors ect.