Goal: A method to play FDS games with perfectly accurate 2C33 audio without using FDS disks (eliminating need for moving parts).
Basically, I'm chasing a perfect solution for playing FDS games that will work for years to come. Using the FDS drive with real disks works currently, but since there are moving parts it will undoubtedly wear out over time. Using original FDS disks also does not provide a way to play fan translations. FDS games can also be run from flashcarts, but the games that utilize the additional audio of the 2C33 chip do not sound correct. There's FDS Loader which is fine in theory, but requires a dedicated older computer with DOS and the correct parallel port capabilities to work which is far from ideal.
I have 3 ideas that I wonder if anyone has looked into or has enough technical knowledge to comment on the feasibility or work towards a solution:
1.) A modern way of loading FDS games straight to he RAM adapter. Basically, think of something like FDS loader but using modern hardware. Even more ideal would be a flash dongle (in place of flashcart) that connects to the FDS RAM adapter to load games to it, thus utilizing the actual 2C33 chip for audio. I doubt anyone is going to whip this up out of nowhere, but I didn't know if someone is already working on a solution like this that I'm unaware of.
2.) Integrate the 2C33 chip in a flash cart. I have no idea how feasible this is, but my thought was basically modding the flashcart to hijack the command to engage the FGPA-ized 2C33 and mod in the real 2C33 to be used. I don't know how much of this is internalized to the FPGA that would make it possible or impossible.
3.) Mod the 2C33 into the console itself. If #2 is not feasible, then I wonder it would be possible to install the 2C33 in the NES/Famicom itself. I'm not sure how it operates and if the signals it needs to engage can be grabbed from the cartridge pins.
I know some people will probably think this is pointless since they consider the audio rendered by flashcarts to be acceptable, but this is for my own persuit of perfection and I'm sure other people would like something similar to what I'm looking for.
The FDS adapter is supported by the TNS-HFC NSF playing cartridges (e.g.
http://www2s.biglobe.ne.jp/~tns/nr26740601.html ).
The bandwidth of the FDS is only serial at about 70kbit/sec, so a microcontroller should be able to keep up. A few people have requested such a device in the past, but most english-speakers seem to prefer more conventional flashcarts to implementing a disk drive emulator.
lidnariq wrote:
The FDS adapter is supported by the TNS-HFC NSF playing cartridges (e.g.
http://www2s.biglobe.ne.jp/~tns/nr26740601.html ).
The bandwidth of the FDS is only serial at about 70kbit/sec, so a microcontroller should be able to keep up. A few people have requested such a device in the past, but most english-speakers seem to prefer more conventional flashcarts to implementing a disk drive emulator.
I'm not familiar with the TNS-HFC, and it's hard to tell a lot about it since the page is in Japanese. Will it actually load FDS games too, or it is it just for playing music and using extra audio chips in cartridges when doing so?
The latter. (NSF files being a format for storing NES/FC soundtracks ... and sometimes more)
lidnariq wrote:
The bandwidth of the FDS is only serial at about 70kbit/sec, so a microcontroller should be able to keep up.
Agreed. Porting FDS Loader to an MCU is the way forward for people uninterested in using an FPGA clone of the FDS synthesizer, such as people verifying whether the FPGA clone is accurate enough. I'm surprised some Arduino fan hasn't done it already.
I have an FDS with a non-functioning disk drive, so I've wanted a way to use it without the drive.
There is a parallel port FDS loader that connects directly to the RAM adapter and can load games that way. I bought one, but then I was never able to get a parallel port working (despite many attempts, and several useless hardware purchases).
http://www.famicomdisksystem.com/tutorials/cables/fdsloader-ram-adapter-cable/I've used a CopyNES to load a game into FDS RAM, but it was a convoluted process and I never made it into something easy to use. It completely bypassed the BIOS, just wrote directly to RAM, so it wouldn't be able to deal with disk loads/swaps.
I'd really love to find an alternative solution using the FDS loader cable. I am wondering if a Papilio or Arduino could handle it? I've never wanted to take the time to reverse engineer the FDS loader software to learn how the disk protocol works, though; that's the main thing stopping me.
FDS protocol is
documented, down to the
low level. The on-disk format is
MFM, just as on Amiga floppies, PC floppies, and high-density Mac floppies, just with variable-length sectors (one as long as each file, instead of a fixed 512 bytes) and one long spiral track like a CD (instead of a surface divided into cylinders).
Okay, that's good stuff to tuck away in case I ever want to do it. (I probably won't, though, for the same reason as stated. Too much time required vs. too little interest.)
There are also these:
http://bakutendo.blog87.fc2.com/blog-category-24.htmlThough I don't think they are for sale.
ccovell wrote:
There are also these:
http://bakutendo.blog87.fc2.com/blog-category-24.html... *snip* ...
Though I don't think they are for sale.
A shame too, I would be very interested in an accurate replacement of the famicom disk system. I love the real thing, but I too am concerned that it will not last forever
rainwarrior what type of computer did you use that had a parallel port still? if the computer used is at least a socket 7 or below it should work no problem. i've went through 2 cables and both bit the dust when i tried to convert the cables to directly connect them. trial and error for me at the time. i just lost interest when the last one broke on me.
It was great to hear what I missed out on coming from the actual system. like the real sword sounds from zelda and noises from the creatures from metroid.
I don't have any computer with a parallel port. I tried two different PCIe parallel port cards, but couldn't get either of them to function outside of Windows (FDS loader need to be run in DOS). I also tried a couple of USB to Parallel thingies for a laugh. Obviously these weren't up to snuff either.
At this point I'd had enough, and gave up on the whole thing forever.
i wouldn't give up all you need is old computer. laptops will not work either. everything is explained in the documentation for FDSLOADR from what i read when i was interested in it.
what do i know anyway. sometime in the future maybe it would become of great interest again?
Ratix wrote:
i wouldn't give up
I wasn't telling you to. Feel free to pursue this however you like. As for me, no I don't need anything.
If I were to attempt it again, I'd rather buy something otherwise-useful and compact like an Ardiuno than an old computer.
The reason I'm not really interested anymore is that I only got the FDS to
reverse engineer its audio hardware, which I managed to do without the parallel port anyway, and at this point I have no open questions about it. There's really nothing I need to know about the disk drive that would help me with the audio, so I can't imagine spending any further time on the loading problem.
cr4zymanz0r wrote:
Goal: A method to play FDS games with perfectly accurate 2C33 audio without using FDS disks (eliminating need for moving parts).
Basically, I'm chasing a perfect solution for playing FDS games that will work for years to come. Using the FDS drive with real disks works currently, but since there are moving parts it will undoubtedly wear out over time. Using original FDS disks also does not provide a way to play fan translations. FDS games can also be run from flashcarts, but the games that utilize the additional audio of the 2C33 chip do not sound correct. There's FDS Loader which is fine in theory, but requires a dedicated older computer with DOS and the correct parallel port capabilities to work which is far from ideal.
I have 3 ideas that I wonder if anyone has looked into or has enough technical knowledge to comment on the feasibility or work towards a solution:
1.) A modern way of loading FDS games straight to he RAM adapter. Basically, think of something like FDS loader but using modern hardware. Even more ideal would be a flash dongle (in place of flashcart) that connects to the FDS RAM adapter to load games to it, thus utilizing the actual 2C33 chip for audio. I doubt anyone is going to whip this up out of nowhere, but I didn't know if someone is already working on a solution like this that I'm unaware of.
Your post inspired me to go ahead and build one. It's a drive replacement that you flash disk images to. There's still some work to do, but you can see game loading works. It also works in the other direction, dumping disks by talking directly with the disk drive.
Holy shit that's awesome. I'm assuming that tact switch is for switching disks?
Yessir. There's enough memory on it to hold 8 disk sides.
Cool! With this I'd even consider using the FDS hardware.
You know, I was never really interested in the FDS because of the crappy technology that floppy disks are... magnectic media is not reliable, mechanical parts in the drive itself degrade, and so on. But this little device actually got me interested.
It can probably also be used for communication between NES software and a PC. Something to explore later...
Very awesome, I want it. Any ETA when and if you'll be offering it to the public?
Side note, my M5A78L-M LX PLUS motherboard works great with FDSLOADER off a USB Flash Drive MS-DOS Boot Disk, formatted with hpflash utility.
Well, the board design is done. I could place an order now and have them in a month or so. Firmware may be finished by then. I'm considering getting a
case made for it, but I'm not sure it's worth it. I'd have to sell a LOT of them to make it worthwhile.
A case would be awesome, but I can see how that could be a problem.
Does this mean I have to buy an FDS?
Sign me up! Case or not, I'd love to buy one of these.
Asaki wrote:
Does this mean I have to buy an FDS?
Just the RAM adapter and loopy's adapter that plugs into said adapter.
...and the adapter to plug the adapter with the adapter into my USA NES.
... and if it's not a top-loading NES, you'll need one of those too.
But at that point, I'd just get a famicom AV.
loopy wrote:
I'd just get a famicom AV.
Easier said than done, depending on where you live. I did get a Famicom AV a few months ago, but it ended up costing me almost US$200 because of shipping and taxes.
Now I'm looking at a RAM adapter, but before I get one: loopy, are you really planning on selling these? How much do you think they're gonna go for?
Yes, I'd like to sell them. I expect somewhere in the $20 range...
loopy wrote:
I expect somewhere in the $20 range...
Sounds very reasonable.
Consider me in, too. And I'd buy a couple of 'em.
...and I just bought a RAM adapter on ebay. Impulsive? Maybe. Guess I'll have to trust loopy and hope this purchase wasn't be in vain!
Since this thing will probably be coming from Japan by ship (which I expect will take 3 months or so), I wouldn't be surprised if loopy was already selling his little device before my RAM adapter even gets here!
This is starting to sound like a literal toolchain.
So...which elements are in it, exactly? Famicom-[FDS?]-FDS RAM adaptor-Loopy's thing?
Myask wrote:
This is starting to sound like a literal toolchain.
So...which elements are in it, exactly? Famicom-[FDS?]-FDS RAM adaptor-Loopy's thing?
Yes, you need your own Famicom or Famicom AV a RAM adapter (FDS system not needed), and loppy's adapter...which I vote be named "RAM Adapter, Adapter"
One other question, does it need special software to preload disk images or is it all drag and drop?
It's not drag and drop, you need software to transfer files.
Will this software be made available for Windows, OS X, and X11/Linux? Or will users of OS X and X11/Linux* have to install VirtualBox and buy a copy of Windows?
* If you dislike this term and have a better term for "Linux with a GUI that is not Android", let me know.
Right now, it's a console app using
HIDAPI that should be easy to port. I'll make a Windows GUI at some point.
loopy wrote:
... and if it's not a top-loading NES, you'll need one of those too.
While I think it would be fun to rig up adapters to plug it into a toaster, I'm sure it would be much easier to just use my top loader.
Looks pretty awesome. I also bought an FDS RAM cartridge in anticipation, they're cheaper than I expected.
About cases, it's not as ideal a solution as your custom one, but one thing I've been considering using with some of my projects are boxes by Bud Industries or Hammond, with end panels. Like
these. It would be really cheap to replace those panels with laser-cut plexiglass of the right thickness.
I'm getting some test cases printed from
Shapeways for about $7 each. Cheaper than I expected. I may go that route for now, make it an optional add-on cost.
Just got another RAM adapter too; to replace the one I sold to rainwarrior. ;P
OK. Now that case, if it only looked like the yellow disksystem dude...
Count me in for a purchase.
B00daW wrote:
Now that case, if it only looked like the yellow disksystem dude...
I think Nintendo might have put the Diskun trophy into
Super Smash Bros. Melee as a token "use in commerce" to keep its trademark alive.
Posting because this is pretty sweet! I definitely want one or two of these
More specs! More details!
*drools*
I'm a lurker here but this thing made me want to post. If you sell it, I'd buy at least one.
This is seriously badass. Can't wait to buy one of these.
-Rob
loopy wrote:
Yessir. There's enough memory on it to hold 8 disk sides.
Woot, IRC discussion paid off! To be honest, your design looks a lot more professional than what I envisioned building (if I had a FDS which I never planned on getting, heh). I was just thinking some flip-chip-style adapter for 8-pin serial EEPROM/Flash ROM SOP/SOIC's and the adapter would be hidden inside but have the socket for 'loading' 'disks'. 8 images is a nice compromise and supports almost all games (as was discussed in IRC). Hell, I think 4 is enough? Cool device either way!
I would like to add to the chorus of people who think that this is a great idea and well worth it. I would buy it.
I have a RAM adapter and disk drive. The adapter can be "hot plugged" into the disk drive after the Famicom is powered on. If you start up the system with the RAM adapter unconnected to the disk drive, you will see Mario and Luigi go at it forever. When you connect the drive, the jingle is heard and the screen flashes. Does this USB device work that way?
Mario and Luigi go at it until a disk is inserted. My thing works the same way, there is a button to "insert" disks.
I see the USB plug and the opposite end for plugging into the RAM adapter, but how does it plug into the drive for dumping disks?
-Rob
That takes a little more work. I made an adapter for myself, but if you don't want to go through the trouble, you could just wire it directly to the drive. There are extra test points on the back of the board.
Ah, I see, OK. I don't think I could bear to destroy two ram adapter's cables to make one of those. To make my FDSLoader cable, I used a SNES AV cable, as the tip was 95% identical to the FDS RAM adapter's. Only problem is finding SNES AV cables with all 12 contacts! Anyone know where I could buy two of those?
-Rob
No, don't destroy ram adapters just for the cables.
I used
this. They have 8 out of 12 contacts, which is enough for doing disk transfers. It's a terrible quality cable for video and deserves its one star rating, but works fine for this purpose. You will have to break it open and move some of the contacts around.
There is one button and it appears to double both as a disk insert and a disk change button. I assume that when the system is first turned on, it acts like a disk insert button, and thereafter as a disk change button.
If the board can support eight disk images, how would you start a game on the second or third or fourth image? Can the board remember the active disk image when the power is off?
It doesn't remember the active disk when the power is off. Push the button N times to select that disk number. It's not the perfect solution, I imagine it would get tedious if you have a lot of disks loaded on it. I'm not sure what's better, maybe forward/back buttons.
Thats one amazing device! Buying two right away, if you will be willing to sell it to me.
I would think the best solution would be to have a forward button, a backward button and a 1-character LED that indicated the number of the selected/inserted disk. Alternatively, a simple LED that pulses as many times as the disk image number currently selected would work. How long of a delay is there between the time you press a button and the disk is inserted? I mean do you have to hold the button down to cycle through the images or keep pressing it fairly rapidly.
I'm still inclined to leave it with one button, one LED. KISS.
Loading it up with a lot of games might not be a common use case anyway, this may be a non-issue. I could put smaller memory on there so the issue doesn't come up. With forward/back buttons, there can be confusion on which disk is selected so now you need a display -- a 7-segment display, or array of LEDs, or just flashing one LED. Counting LED pulses is even more inconvenient than clicking a button a bunch of times, IMO. The other options work, but I dislike the added complexity and cost to solve this one issue. I think a 4-way/8-way switch or thumbwheel would be ideal but I haven't found parts that would fit well. A rocker switch like
this is a little nicer than forward/back buttons.
A new test board is coming in today, it's been through a few revisions. I hope to have the firmware done this week, I'd like to have all the functionality working and tested before doing a larger production run of boards.
I can't tell from the photo what microcontroller you're using, but does it have any on-chip EEPROM? If it does, you could use that to store the current disk selection. Also, if you don't want to put out the money up front for cases, you can just list the model for sale on Shapeways and people can buy it directly from there and then Shapeways just pays you.
That wouldn't be great practice, as the EEPROM likely also is storing the program. A mistake could cause issues there, and writing to it frequently will not be good for its longevity (though the likelihood of it being a problem is slim).
Yes, it has on-chip EEPROM. I can put the 3d model up and let you order it / print it yourself. I'd rather order 10 at a time (or whatever) to make it easier on you and cut out the extra shipping costs.
mikejmoffitt wrote:
That wouldn't be great practice, as the EEPROM likely also is storing the program. A mistake could cause issues there, and writing to it frequently will not be good for its longevity (though the likelihood of it being a problem is slim).
Given the fact that he said it can store up to 8 disk images, I highly doubt that the disk images are on the on-chip EEPROM, and I'm guessing that SOIC-8 chip is an external serial EEPROM and that's where they are. In that case, the on-chip EEPROM isn't being used for code or anything, so there's no harm in using it to store the disk selection. If you're worried about endurance, just store the value once the game is actually loaded, rather than as soon as you hit the button, and that will alleviate a lot of extraneous writes. Beyond that, it has a pretty high endurance anyway (usually 100k+ write/erase cycles), and even if it did eventually die, it's isolated from the program flash memory, so all you'd lose is the remembering part, it wouldn't trash the microcontroller.
loopy wrote:
I'd rather order 10 at a time (or whatever) to make it easier on you and cut out the extra shipping costs.
Whatever works for you, I just thought I'd mention it.
Yeah, I'm not worried about flash endurance. You could use it daily for many years before it wears out. Saving the current disk just didn't seem important to me, it wouldn't be hard to add.
loopy wrote:
Yeah, I'm not worried about flash endurance. You could use it daily for many years before it wears out. Saving the current disk just didn't seem important to me, it wouldn't be hard to add.
Yeah, and EEPROM has even higher endurance than Flash, and since the code is running on Flash, the entire point of on-chip EEPROMs is for saving config data like this. While it's not super important, I could see it being a feature that users might appreciate, especially considering how simple it would be to implement.
And especially with double A-side games like SMB1/SMB2J.
loopy wrote:
No, don't destroy ram adapters just for the cables.
I used
this. They have 8 out of 12 contacts, which is enough for doing disk transfers. It's a terrible quality cable for video and deserves its one star rating, but works fine for this purpose. You will have to break it open and move some of the contacts around.
I'll gladly pay the lazy-ass tax to not have to make that cable if you sell those too.
-Rob
I found a similar project. The guy emulate the ram adapter and drive, and added a LCD display for operation.
https://youtu.be/IGcojFG9-II
Yes, these were noted on the 1st page of this thread.
I'm very much looking forward to this and want to buy 2 or 3. Loopy, please PM me on IRC if you do sell them. (The email notifications for this thread only seem to come through, very sporadically!)
-zombie343/felgar01
What are all of the things you need to be able to dump disks?
Buddybenj wrote:
What are all of the things you need to be able to dump disks?
USB stick and adapter cable.
The design's finally finished. Yes, they are still coming, I don't know when yet. If you can't stand waiting, I have a few hand assembled boards I suppose I could sell.
loopy wrote:
The design's finally finished. Yes, they are still coming, I don't know when yet. If you can't stand waiting, I have a few hand assembled boards I suppose I could sell.
I'd be interested in a board, PM coming your way.
So I got mine today and this little thing is absolutely awesome. It uses a command line program so it's a bit clunky, but it works very well and I'm surprised at how simple the actual board is to use with just that one button.
Wow this is just awesome! Is this going to be open source or will they only sell asembled and ready from you?
Getting one either way
but thought Id ask.
Waiting for mine too, I'm totally stalking the mailman every day! Can't wait to finally test it!!!
Loopy, you really don't have an idea how much I always wanted such thing!
Are they already for sale?
Not quite, just the few handmade.
Anyway is there a possibility to use the stick with Twin famicom? There is the port on the side that fits for it.
jpx72 wrote:
Anyway is there a possibility to use the stick with Twin famicom? There is the port on the side that fits for it.
It won't work on a Twin Famicom, that expansion port on the side is the same as the one on the back of the FDS RAM adapter so it wouldn't fit.
With a little solder work, it should be possible to do it inside.
Yes, I'm waiting for this adaptor too, but I only have a Twin Fami. I dunno if this doc is correct at all, but I made this over a decade ago:
Code:
THIS MIGHT NOT BE CORRECT AT ALL!!!
("C" connector on Twin) (FDS RAM)
1 (Green) 10 (Black) MEDIA SET
2 (Blue) 12 (Purple) STOP MOTOR
3 (Purple) 11 (White) ~READY
4 (Grey) 9 (Yellow) <-DATA
5 (White) 7 (Grey) ~WRITABLE DATA
6 (Black) 5 (Orange) ->DATA
7 (Pink) 3 (Blue) ~SCAN MEDIA
8 (Olive Green) 1 (Green) ~WRITE GATE
9 (Brown1) 4 (Brown) GND
10 (Magenta1) 2 (Lt. Blue) Vcc(+5V)
11 (Brown2) 6 (Pink) MOTOR ON/BATTERY GOOD
12 : This Terminal is not Used.
Inside FDS Disk Drive:
RAM connector -> Drive unit conn.
UUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUU 1 3 5 7 9 B UUU
UUU UUU
UUU 2 4 6 8 A C UUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
A front view of the RAM adaptor's disk drive connector.
pin # signal description 1x12 Drive Pin
----- ------------------ --------------
1 (O) -write 8 Grey *
2 (O) VCC (+5VDC) 10 Black
3 (O) -scan media 7 Purple *
4 (O) VEE (ground) 11 White
5 (O) write data 6 Blue
6 (I) motor on/batt.good (2.5v) 12 Pink (5v)
7 (I) -writable media 5 Green
8 (I) motor power (note 1) 9 Lt.Green
9 (I) read data 4 Yellow
A (I) -media set 1 Brown
B (I) -ready 3 Orange *
C (O) -stop motor 2 Red
Very cool. I'll definitely want to buy one of these when they're ready to be sold.
Mine came today!
Loopy you did an awesome job, command line interface feels appropriate for FDS age, clicking for the right disk is fun, red/green LED shows everything I need to know about what's happening, fits in the socket very well and overall performance is great!
Thank you Loopy! Very very much!
bytestorm wrote:
Is this going to be open source or will they only sell asembled and ready from you?
Getting one either way
but thought Id ask.
Maybe sometime in the future. I've spent a few months and several $Thousand getting them made with some expectation of a return, I'm not going to give it away just yet. The software is open source.
A large batch of boards is being made but it will take a while because of backordered parts. I'll have some more handmade boards next week.
loopy wrote:
bytestorm wrote:
Is this going to be open source or will they only sell asembled and ready from you?
Getting one either way
but thought Id ask.
Maybe sometime in the future. I've spent a few months and several $Thousand getting them made with some expectation of a return, I'm not going to give it away just yet. The software is open source.
A large batch of boards is being made but it will take a while because of backordered parts. I'll have some more handmade boards next week.
Will there be any functional difference between the handmade boards and later boards?
OK, I threw a shitty webpage up with a paypal order-thing. I tried to set it up to allow international shipping, I hope it works.
Limit one per customer. I don't have a lot of these. Once they run out, the price will go up. For now, you get the nesdev special discount
There are a lot more coming, but they won't get here for another month or so.
If you prefer something other than paypal, let me know, maybe I can work something else out.
http://3dscapture.com/fdsstick
loopy wrote:
OK, I threw a shitty webpage up with a paypal order-thing. I tried to set it up to allow international shipping, I hope it works.
Limit one per customer. I don't have a lot of these. Once they run out, the price will go up. For now, you get the nesdev special discount
There are a lot more coming, but they won't get here for another month or so.
If you prefer something other than paypal, let me know, maybe I can work something else out.
http://home.comcast.net/~olimar/NES/FDSStick/Ordering worked okay for me, although I'm within the domestic shipping category. I can't wait for mine to come so I can test it and write a blog post about it.
It had a thing to calculate shipping to Canada, for me, so I guess the international shipping part works. Thanks for making these!
tokumaru wrote:
Since this thing will probably be coming from Japan by ship (which I expect will take 3 months or so), I wouldn't be surprised if loopy was already selling his little device before my RAM adapter even gets here!
A little over 3 months later, here's what arrived in the mail today (the picture looks like crap, but the RAM adapter looks practically new, which kinda surprised me):
Attachment:
fds-ram.jpg [ 108.15 KiB | Viewed 2630 times ]
Just in time for the first batch of loopy's devices too, which may sound like great timing, except for the fact that I'm kinda broke right now...
Guess I'll take a few minutes/hours to think and make a decision!
Of course there's the fact that I have absolutely no use for the RAM adapter without the drive emulator, but sadly that doen't change the fact that I'm broke.
The FDSStick's page appears to indicate that it will write disk images back to real disks in the FDS drive. Do the later FDS drives with a FD3206 drive controller and/or the revised power boards require the modifications described here :
http://famicomworld.com/workshop/tech/f ... write-mod/and here :
http://famicomworld.com/workshop/tech/f ... fications/
Yes, the drive will need to be modified if it's a later model with copy protection.
Hi Great Hierophant,
http://famicomworld.com/workshop/tech/f ... write-mod/If this mod too trouble for you, you can consider this one (they are same function) :
http://www.tototek.com/store/index.php? ... cts_id=143http://www.tototek.com/phpBB2/viewtopic.php?t=2855http://www.tototek.com/phpBB2/viewtopic.php?t=3306Before you start to work on it, you should look inside the drive board.
If it has 7201 chip on it. Then no need to do this mod.
I checked my FDS disk drive, it has a Power Board rev. 05 and an FD7201 chip, so I guess I will only need one mod, assuming the drive works. I never acquired any disks, so I cannot test it out.
another grateful new nesdev'er here. thanks loopy, i've been dying to play Nazo no Murasamejou on the everdrive with real 2c33 audio for awhile now. i didn't think it would ever be possible!
edit: whoops the everdrive isn't even necessary!
Hi loopy,
I want to ask, after I saved game with FDS Stick. Can I read it back to *.fds ? If not, when I flash new game, the save record will gone. This function still in development ?
No, not yet. I'm working on it.
Oh it's already for sale! And sold-out!
Do the command-line program just copy the clean FDS image to the stick's memory as is?
Yes, and its memory has 8 slots. So, you can put 8 games in 1 if games image only one side.
Pokun wrote:
Oh it's already for sale! And sold-out!
Do the command-line program just copy the clean FDS image to the stick's memory as is?
It's not an exact copy, it's converted to a raw format that more closely resembles what's on an actual disk (with file gaps and CRCs added)
I see, thanks!
Anyway the FDS Loader is cumbersome and almost never works, the Japanese variants requires many expensive parts to build and the Everdrive and Powerpak solutions are not very satisfying. But this seems to be the simplest way to run custom FDS code so far. Not mentioning dumping and writing disks. I'm interested in getting one of these when they are back in stock!
Funny enough, I had no idea this was a thing (shame it's sold out, I actually talked to kitahei88 about getting one of the JP FDS writing solutions), but a few days ago, I actually mocked up an FDS flash menu
complete with a cover of the Nintendo Power flash cart music.
Hey loopy, any word on the enclosures?
Will there still be a limit of 1 adapter per person when the new batch arrives? A co-worker of mine wants one, so I was hoping I'd be able to make a combined order and have his and my adapter shipped together.
It shoud be no limit. As I know, he make big quantity this time. I also will order some for sell. At least, I don't limit my customer just buy one.
Shipped today, but I won't receive it until next week. Couldn't the Founders have signed the Declaration of Independence a week later?
Loopy, do you have any plans to sell the adapter cable for the Disk Drive? Or maybe someone else might, like Tototek?
Great Hierophant wrote:
Shipped today, but I won't receive it until next week. Couldn't the Founders have signed the Declaration of Independence a week later?
You're lucky, mine will probably take a month or so to get here...!
mic_ wrote:
Will there still be a limit of 1 adapter per person when the new batch arrives? A co-worker of mine wants one, so I was hoping I'd be able to make a combined order and have his and my adapter shipped together.
There won't be a limit.
MottZilla wrote:
Loopy, do you have any plans to sell the adapter cable for the Disk Drive? Or maybe someone else might, like Tototek?
No. I'll put up some instructions on how to build one. It's too much hassle making them all by hand myself, not worth my time. And I think it's unlikely to sell in high enough volumes to get a custom cable manufactured. I don't know what Tototek (Tomy's) plans are.
Yes, I want to make some adapter cable for the Disk Drive for sell. But I'm not sure if I can buy the parts here in Hong Kong. I think loopy's instructions is easy to learn how to build it for everyone.
I'm sure the housing can be 3D printed, or cheap 3rd party multi-out cable clones can be repurposed with a dremmel.
loopy wrote:
cr4zymanz0r wrote:
Goal: A method to play FDS games with perfectly accurate 2C33 audio without using FDS disks (eliminating need for moving parts).
Basically, I'm chasing a perfect solution for playing FDS games that will work for years to come. Using the FDS drive with real disks works currently, but since there are moving parts it will undoubtedly wear out over time. Using original FDS disks also does not provide a way to play fan translations. FDS games can also be run from flashcarts, but the games that utilize the additional audio of the 2C33 chip do not sound correct. There's FDS Loader which is fine in theory, but requires a dedicated older computer with DOS and the correct parallel port capabilities to work which is far from ideal.
I have 3 ideas that I wonder if anyone has looked into or has enough technical knowledge to comment on the feasibility or work towards a solution:
1.) A modern way of loading FDS games straight to he RAM adapter. Basically, think of something like FDS loader but using modern hardware. Even more ideal would be a flash dongle (in place of flashcart) that connects to the FDS RAM adapter to load games to it, thus utilizing the actual 2C33 chip for audio. I doubt anyone is going to whip this up out of nowhere, but I didn't know if someone is already working on a solution like this that I'm unaware of.
Your post inspired me to go ahead and build one. It's a drive replacement that you flash disk images to. There's still some work to do, but you can see game loading works. It also works in the other direction, dumping disks by talking directly with the disk drive.
Well crap. The thread doesn't get any responses for a few months, I stop paying attention, then awesome happens and sells out
. I look forward to the next batch become available so I can grab one.
One question though, If I've read correctly this doesn't appear to support saving yet. If saving is implemented at a later date is this something that we can do a firmware update ourselves or will it require sending it back in or buying a new model?
cr4zymanz0r wrote:
One question though, If I've read correctly this doesn't appear to support saving yet. If saving is implemented at a later date is this something that we can do a firmware update ourselves or will it require sending it back in or buying a new model?
Saving works. Reading back the .FDS image hasn't been implemented in the software yet. The firmware can be updated over USB.
I just got mine today and I am very pleased with it so far. Some questions :
1. The program allows you to read disks in an FDS or RAW format. Will you eventually be able to write to disks in the RAW format? Is there a program to convert RAW images to FDS images?
2. Do you think it would be possible in a future revision of the command line utility to put in a Delete Slot command? It makes things look more tidy that way.
Here is "delete slot" version fds.exe (modded from V2 fds.exe)
You can delete slot like this :
fds.exe -e 1 (mean delete slot 1)
fds.exe -e 1 3 5 7 (mean delete slots 1,3,5 and 7)
fds.exe -e 1 2 3 4 5 6 7 8 (mean delete all slots)
Tomy wrote:
Here is "delete slot" version fds.exe (modded from V2 fds.exe)
You can delete slot like this :
fds.exe -e 1 (mean delete slot 1)
fds.exe -e 1 3 5 7 (mean delete slots 1,3,5 and 7)
fds.exe -e 1 2 3 4 5 6 7 8 (mean delete all slots)
That was quick, I'll be sure to give it a try.
fds.exe v2.02, just added backup save function.
(it is not original loopy's release)
I think most games save is in side A.
Or you need to remember which side contain game save.
First, you need to backup save with command like this :
fds.exe -s twinbee.sav 1 (mean backup slot 1 save to file twinbee.sav)
Then when you retore save,
fds.exe -S twinbee.sav 1 (mean restore save to slot 1 with save file twinbee.sav)
I make these function because I love my fdsstick, thanks loopy !
Metroid apparently saves to both sides
viewtopic.php?f=10&t=12911.
When it gets possible to write back the disk to the computer the saves should go with it too I guess.
Yes, it should work if you backup both sides. Because at the moment, fds.exe only can backup a side each time. So, you need to backup both sides and keep both save files.
Thanks Tomy, it appears to work. To avoid missing something, you should back up both sides of a two-sided game or all sides of a four-sided game. You will have to write each file back to the FDSStick separately. Also, the save file format does not appear to be easily compatible with emulators. The save files maintain the original file name info, so you don't have to type out long names in the command line program.
Hi Great Hierophant,
fds v2.1 can save whole game's slots. Any problem, please tell me.
(it is not loopy original build)
Hi, Loopy, thanks for making this; it works really well so far!
This is neither here nor there, but I wanted to compare the timing or data differences between your device and the real FDS drive, so here is a pic:
Really, no conclusions can be drawn from this, except that perhaps my drive is running a little faster than the FDSStick. I wondered what that noise was at the start on the real FDS, but of course it's the data playing backwards as the drive head races back to the start.
Thanks Tomy for working on the controll software, delete function is great!
In this thread,
viewtopic.php?f=2&t=3410&hilit=fds+gap, I found this :
Lord Nightmare wrote:
FDS files are by definition flawed. Mitsumi's quick disk format, as used on the fds, literally stores a stream of data (MFM or RLL encoded) on the disk, in a spiral track. All that current fds files contain is the data from all of the disk blocks, concatenated together in a big stream.
This is wrong for a few reasons:
1. The crc16 values at the end of each block are missing. at least one game checks for this as part of its copy protection scheme.
2. The pre-gaps before each block are missing. again, its possible to check this.
3. Data which is not encoded in the standard 'fds format' of nintendo fds disks, which is sometimes present at the end of the disks, is missing. at least one game REQUIRES this data in order to function!
I do not know the games to which Lord Nightmare is referring to, but if someone does, will they work in FDSStick?
Yes. Disk images are stored as a raw stream of bits, so it should be able to handle anything.
I would also like to know what game(s) he's talking about.
Great Hierophant wrote:
1. The program allows you to read disks in an FDS or RAW format. Will you eventually be able to write to disks in the RAW format? Is there a program to convert RAW images to FDS images?
Yes, I suppose so. Raw dumps aren't currently useful for anything except my own analysis, when dumping to .FDS doesn't go right. There aren't any tools to make use of them yet.
Great Hierophant wrote:
2. Do you think it would be possible in a future revision of the command line utility to put in a Delete Slot command? It makes things look more tidy that way.
I released a new version of the software, it can erase and read from flash back to .FDS now.
As for those games... I honestly do not remember, I remember someone mentioning it here or in efnet #nesdev or redump forums or nointro or assembler or somewhere a long (~7-10 years) while ago.
Based on new information and the fds 2c33 decap, I'm not sure it is possible to actually read the crc16 checksums from the famicom/nes cpu side unless there is some way to 'glitch' (maybe a short seek backwards?) the drive to start reading in the middle of a sector, as I *THINK* (but am not sure!) that the crc16 compare happens on the 2c33 die itself and may not be visible to the famicom/nes side except as a status bit for 'checksum is wrong' vs 'checksum is ok' in a 2c33 register.
The gaps, however, are readable, someone made an fds dump (using 2c33?) which has the gaps present, its a few 0x00 bytes before each sector and file header, I think.
LN
Are any of the current FDS images missing anything important? I guess those gaps and CRC could be calculated and inserted automatically in memory by the emulator or other device just like Loopy's FDS.exe does.
Pokun wrote:
Are any of the current FDS images missing anything important? I guess those gaps and CRC could be calculated and inserted automatically in memory by the emulator or other device just like Loopy's FDS.exe does.
No one knows except by playing through the games. I have never had a problem with the existing images, but I do not play the Japanese text adventures that were never ported or the more obscure titles. Considering that there are no games whee this is known to occur outside of games marked in TOSEC as bad, it's not a huge issue.
I would note that No Intro marks any FDS image with any saved information as [b]. This should not be taken to mean that the game is a bad dump, it is just not a pristine dump.
CRCs can be recalculated and gaps added. This is the only thing missing from .FDS files. For the vast majority of games, it's good enough.
Cases where another file format might be necessary:
- Games that rely on a different CRC value (for copy protection maybe?) Until I see one, I'm not concerned about this.
- Games that use some other nonstandard disk format. Again, show me one and I'll care about it.
- Games bigger than the standard 65500 bytes. "Copier" hardware needs this (Game Doctor, etc). I'll be adding support for this in FDSstick soon because Tomy requested it.
There is one advantage to .FDS over a raw disk dump: it's a canonical representation. It's impossible to read out and decode a disk byte-for-byte, from start to finish. Between files there are discontinuities, glitches in the encoding where writing starts and stops. Because of this and the way MFM works, you will always have to use some heuristics or make assumptions about where real data starts so you can decode it. The pre-gap length will vary depending on your drive calibration. You can read the same disk with the same hardware repeatedly and get a slightly different dump each time. It's a minor point and won't affect functionality, but for the purists out there, you will never have a "one true raw dump" that you could compare against. Unless you standardize gap lengths and fix things up by hand...
Lord Nightmare wrote:
Based on new information and the fds 2c33 decap, I'm not sure it is possible to actually read the crc16 checksums from the famicom/nes cpu side unless there is some way to 'glitch' (maybe a short seek backwards?) the drive to start reading in the middle of a sector, as I *THINK* (but am not sure!) that the crc16 compare happens on the 2c33 die itself and may not be visible to the famicom/nes side except as a status bit for 'checksum is wrong' vs 'checksum is ok' in a 2c33 register.
The gaps, however, are readable, someone made an fds dump (using 2c33?) which has the gaps present, its a few 0x00 bytes before each sector and file header, I think.
LN
The 2c33 can verify the CRC16, but you still read it off the disk like normal data. No weird tricks necessary (you can't seek backwards, btw).
When FDS Stick support Copier format (bigger file >64K), many old copier will resurrection. As I remember, it is :
1) Mini Doctor (Max : 64K+8K)
2) Game Doctor (1M/2M/2M plus/4M +8K) version (BUNG)
3) Game Converter (1M+8K) (Venus)
3) Game Doctor 4+ (4M+8K) (Venus)
4) Game Doctor 6+ (2M+2M) (Venus)
5) Game Doctor 6M (4M+2M) (Venus)
6) Magic Card (1M/2M/4M +8K) version (Front Far East)
7) Magic Card latest (4M+2M) + Can connect PC (Front Far East)
8) Game Master (2M+2M, 4M+2M) version + FPGA Mapper (BUNG)
Most copier sold in Asia (Hong Kong, Taiwan, Japan), I think Europe and USA not many people have it.
The powerful one is Game Master, it has FPGA. After you load boot disk, it directly support MMC1/2/3. No need to hack game.
I'll play around it when fdsstick support it.
Boards came in today. Cases should be here soon-ish. I'm removing the bare board option, since almost nobody wanted it last time. I don't really like doing these printed cases, eventually I'm going to get a proper injection molded case made.
loopy wrote:
The 2c33 can verify the CRC16, but you still read it off the disk like normal data. No weird tricks necessary (you can't seek backwards, btw).
So the crc16 is readable from the famicom/nes side? Interesting.
And by 'seek backward' I mean enable the motor right after it gets disabled and the head starts to swings back over the disk to the beginning, so the motor gets turned on and the gear re-engages before the head has fully retracted to the beginning, so you end up starting to read data somewhere random in the middle of the disk (I can't imagine this sort of shenanigans is good for the gears though, nor do I know if it will even work, there may be protections against the head re-engaging the motor unless it has fully retracted)
LN
loopy wrote:
Boards came in today. Cases should be here soon-ish. I'm removing the bare board option, since almost nobody wanted it last time. I don't really like doing these printed cases, eventually I'm going to get a proper injection molded case made.
Probably a silly idea but it would be great to get the cases made in the color of the FDS Drive.
Loopy, can you give some detailed instructions on how to make the gender-changer / adaptor?
Do you just pair the same pins together: 1-1, 2-2...?
I used 2 FDS RAM adaptor cables and just mated the same colour wires, and tried the options -r file.fds and -R file.raw, etc... and it can't read a thing.
The motor spins up, and the light on the FDSStick goes green. Then as soon as the head has moved back to the starting position, the DOS program immediately says "read failed". Meanwhile the light on the FDSStick goes red, and turns off when the head reaches the end of the disk.
Any ideas?
Pair the same pins together EXCEPT Pin #8, leave it unconnected ("motor power" in
Brad Taylor's FDS doc. Careful, his numbering is upside down)
This wire is missing on the ram adapter, so your cable should be good.
It sounds like it's working correctly (well, except for the "read failed" part). The read will abort if data is lost. Try running it a few more times.
Code:
##########################
################################
### C A 8 6 4 2 ###
### ###
### B 9 7 5 3 1 ###
################################
################################
End of RAM adapter cable
UPDATE: It worked better when I switched from my laptop's USB 3.0 ports to its powered port.
I managed to get the FDS disk dumped into a coherent-looking file a few times by switching USB ports. However, sometimes it still gives the Read error.
In my non-powered USB ports, it's nothing but read errors. I tested some of the switch lines with an oscilloscope, and they barely read above 0.3v or so, so I guess the current drain on an underpowered USB port is causing this species of error.
(Old post: About half of the time, the program will say "Read error. Failed" immediately on startup, and the other half of the time, it'll proceed until the drive head hits the switch which triggers "~ready" and then print that message. On these latter occasions, if I trip the ready switch early with my finger, the program prints "Read error. Failed." So obviously the point of failure is when this switch gets triggered. Why should the program have a read error at this point, anyway, since the head has just hit the very beginning of the disk (before any such data can be read anyway)?)
As soon as ~ready is triggered, the FDSstick LED goes red and starts streaming data. It doesn't interpret anything, it's just sending out flux transition timing so it should be reading out the pre-gap area on disk at this point. On the PC side, it will give up if the data sequence is out of order (packet got lost). I'm not sure if that's what happening here. I can make another build of the software that spits out more debugging info so I can try to figure out what's going wrong.
I've had success with reading and writing, so thanks! (See my above post)
ccovell wrote:
UPDATE: It worked better when I switched from my laptop's USB 3.0 ports to its powered port.
I managed to get the FDS disk dumped into a coherent-looking file a few times by switching USB ports. However, sometimes it still gives the Read error.
In my non-powered USB ports, it's nothing but read errors. I tested some of the switch lines with an oscilloscope, and they barely read above 0.3v or so, so I guess the current drain on an underpowered USB port is causing this species of error.
Interesting. The drive's control board is powered by USB (it still needs external power for the motor). The drain should be much lower than what a USB port can provide though.
Hi ccovell,
Congratulation you can read/write disks.
Because of fdsstick release, some people like to write their own disk.
I want to tell something for the people who want to write their own disk.
See my old post here :
http://www.tototek.com/phpBB2/viewtopic.php?t=2855When you buy FDS Drive, take care, you need full modded version of FDS drive.
Or you need to do it by yourself. If you have 7201 drive, then half mod is ok.
If not, fdsstick can not fully rewrite disk.
How to do full mod ?
http://famicomworld.com/workshop/tech/f ... fications/http://famicomworld.com/workshop/tech/f ... write-mod/or
http://www.tototek.com/store/index.php? ... cts_id=143
loopy wrote:
Boards came in today. Cases should be here soon-ish. I'm removing the bare board option, since almost nobody wanted it last time. I don't really like doing these printed cases, eventually I'm going to get a proper injection molded case made.
Would you mind leaving the bare board option? I would like to wire the fdsstick directly to my FDS board and have a simple micro usb port on the back of the console. I don't want to pay an extra $10 or so for something that will be completely useless to me.
If i were you, i would offer a bare boards option, and release the file for a case. I have my own 3d printer and if i wanted to, I could just print my own case in any color I wanted. I could even add a cool little Disk-kun logo or something to it.
Hrm... Guess life made me miss the boat this time around. Another wave happening after this shipment, perhaps? :/
Really looking for a good dev environment for FDS audio.
B00daW wrote:
Hrm... Guess life made me miss the boat this time around. Another wave happening after this shipment, perhaps? :/
Really looking for a good dev environment for FDS audio.
There was suppose to be a new batch for sale yesterday, it never came.
I've got a lot of friends that are pissed. I told them about it and almost all of them were going to order one yesterday. (as was i)
They thought they missed them too.
B00daW wrote:
Hrm... Guess life made me miss the boat this time around. Another wave happening after this shipment, perhaps? :/
Really looking for a good dev environment for FDS audio.
You didn't miss anything, I just haven't put them up yet.
Any chance of offering a caseless option this time around?
Very well. I'll keep it there for now.
It's back up. When
Tototek.com has boards in, I'll let them handle all international (non-U.S.) orders. Tomy is away for a few days so I'll still accept international orders for now.
No more NesDev discount?
I was planning on dumping my paypal account. Everything's all screwy so i want to close it and open a new one. I had exactly $20 left.
Oh well, i'll get everything to work out.
Thanks!
I put up some
instructions on making a cable for disk reading/writing.
Games I have been able to complete from start to finish without issue using loopy's FDSStick :
Akumajou Dracula
Dracula II: Noroi no Fuuin
Hikari Shinwa: Palutena no Kagami
Legend of Zelda 2: Link no Bouken
Metroid
Yume Koujou: Doki Doki Panic
Zelda no Densetsu: The Hyrule Fantasy
I think that is a fair endorsement for this device. Everything else I have tried works without flaw, as long as you avoid corrupted images.
thx loopy.
just recieved ram adapter and test fdsstick.
all working fine.
Video test (Russian)
https://youtu.be/6Zig-WYx9oI
It may be an idea to try Puroresu with your RAM Adapters. I remember there was a discussion of possibly faulty SRAM chips in certain RAM Adapters and this was one of the games where it's clearly visible displaying glitchy sprites.
I don't know if the cause was ever figured out.
Pokun wrote:
It may be an idea to try Puroresu with your RAM Adapters. I remember there was a discussion of possibly faulty SRAM chips in certain RAM Adapters and this was one of the games where it's clearly visible displaying glitchy sprites.
I don't know if the cause was ever figured out.
I do not know of any images of diagnostics disks that would test all the RAM. Some versions of the RAM Adapter use DRAM instead of SRAM, at least for the PRG area.
This doesn't "test" any of the CHR-RAM, but I made a small program (.FDS image) a long time ago that tests the FDS RAM from $6000-$DFFF:
http://www.chrismcovell.com/data/RAM_Ch ... 0-DFFF.zipWhen it starts up, it'll show "CC", meaning "ready".
Press the A button and nothing will appear to happen, but it's testing all addresses with values from $00-$FF to see if the read matches the write. It'll print up RRWWAAAA (AAAA being the address where the error was found) if there is a mismatch.
After a minute or so, the screen will go grey meaning the test is complete.
Maybe someone should make one for CHR. I have looked into making FDS programs and I managed to make an emulator accept my FDS image but, my program doesn't work. I've looked into your FDS homebrew sources but I can't understand them, you compiled it in a strange way that I can't make any sense of.
This is what I got to load at least:
Header:
Code:
;Famicom Disk System program template
;By Pokun
;
;Assembles in ASM6
;FDS Disk Image
;1 side (64 kB)
;===============================================================================
; Constants
;===============================================================================
;Header constants
REVISION = $00 ;revision number used in the header (starts at 0)
SIDE_COUNT = $01 ;number of disk sides (1, 2, 4...)
FILE_COUNT = $02 ;total number of non-hidden files on disk
;(if additional files are added they are hidden)
;FDS defines
FDS_CRAM = $0000 ;where CHR-RAM starts
FDS_PRAM = $6000 ;where PRG-RAM starts
FDS_BIOS = $E000 ;where the BIOS resides
;===============================================================================
; Variables
;===============================================================================
;Zero Page ($0000-$00FF)
.enum $0000
.ende
;Page 1 ($0100-$01FF)
;(Stack)
;Page 2 ($0200-$02FF)
;(Shadow OAM)
;Page 3-7 ($0300-$07FF)
.enum $0300
.ende
;===============================================================================
; fwNES FDS header (optional)
;===============================================================================
;16 byte header for the .FDS Quick Disk format
.org $0000
; .db "FDS", $1A ;identification of the fwNES header
; .db SIDE_COUNT ;number of disk sides
; .pad 16, $00 ;clear the remaining bytes
;HEADEROFFSET = $ ;add this to adjust for the header offset
;Note about blocks
;Each disk side must be structured into blocks as follows:
;First a disk header block and a file amount block then one file header block
;and one file data block for each file on the disk. Finally the disk sides ends
;with an end of disk side indicator (?). Each block has a block code:
;$01 = Disk Header Block
;$02 = File Amount Block
;$03 = File Header Block
;$04 = File Data Block
;$FF = End of Disk Side Indicator
;From the last file, fill the side with zeroes so that the disk side gets
;exactly 65500 bytes.
;On real disks there are also gaps and CRCs not present in
;FDS images. These must also be considered when calculating true
;disk capacity. The actual disc capacity in bytes is:
;65500 - 28300/8 - (2*N + 1)*(16 + 976)/8
;N = number of files
;===============================================================================
; Disk Side 1 (65500 byte)
;===============================================================================
;Disk Header Block
.db $01 ;Block code (1 = disk header block)
.db "*NINTENDO-HVC*" ;Used by BIOS to verify legitimate image.
.db $00 ;Maker code, $00 is unlicensed, $01 is Nintendo $08 is Capcom...
.db "HMB" ;3-letter ASCII code for title (e.g. LNK for Zelda Densetsu)
.db " " ;Game type
;$20 = " " — Normal disk
;$45 = "E" — Event (e.g. Japanese national DiskFax tournaments)
;$52 = "R" — Reduction in price via advertising
.db REVISION ;Revision number (starts at $00, increments per revision)
.db $00 ;Side number
;$00 = Side A, $01 = Side B. Single-sided disks use $00
.db $00 ;Disk number (first disk is $00, second is $01, etc.)
.db $00 ;Disk type
;$00 = FMC ("normal card"), $01 = FSC ("card with shutter")
.db $00 ;Unknown
.db $0F ;Boot read file code (file code/number to load upon boot)
.db $FF,$FF,$FF,$FF,$FF ;Unknown
.db $00,$00,$00 ;Manufacturing date (BCD, Shouwa format)
.db $49 ;Country code ($49 = Japan)
.db $61 ;Unknown
.db $00 ;Unknown
.db $00,$02 ;Unknown
.db $00,$00,$00,$00,$00 ;Unknown
.db $00,$00,$00 ;"Rewritten disk" date (supposedly by the Disk Writer)
.db $00 ;Unknown
.db $80 ;Unknown
.db $00,$00 ;Disk Writer serial number
.db $07 ;Unknown
.db $00 ;Disk rewrite count (value in BCD, $00 = Original (no copies))
.db $00 ;Actual disk side ($00 = Side A, $01 = Side B)
.db $00 ;Unknown
.db $00 ;Price
;.db $00,$00 ;CRC - Not used in the .fds file format.
;Disk sides note
;If the FDS is started with a disk whose side number and disk number
;aren't both $00, it will be prompted to insert the first disk side.
;However, some games make this number $00, even for the second disk
;to make it bootable too.
;File Amount block
.db $02 ;Block code (2 = file amount block)
.db FILE_COUNT ;Total number of files recorded on disk
;If more files exist on disk they will be considered hidden and the
;BIOS will ignore them. A loading routine on disk is required to
;load them.
;File codes note
;All files with IDs smaller or equals to the boot read file code
;will be loaded when the game is booting.
;-------------------------------------------------------------------------------
;File "KYODAKU-"
;The first file on the disk must be the "KYODAKU-" file (approval in Japanese)
;that contains the message that scrolls up on screen ("THIS PRODUCT
;IS MANUFACTERED AND SOLD BY NINTENDO...") at boot, and must match
;the same data in the BIOS at $ED37. It's a nametable type of file that is
loaded into PPU $2800.
;File Header Block
.db $03 ;Block code (3 = file header block)
.db $00 ;File Number, must go in increasing order, first file is 0
.db $00 ;File ID
;ID specified at disk-read function call
;This is the number which will decide which file is
;loaded from the disk (instead of the file number).
;An ID smaller than the boot number means the file is
;a boot file, and will be loaded on first start up.
.db "KYODAKU-" ;File Name (8 uppercase ASCII characters)
.db $00,$28 ;File Destination Address (16-bit little endian)
.db $E0,$00 ;File Size (16-bit little endian)
.db $02 ;File Type
;0:Program (PRAM)
;1:Character (CRAM)
;2:Nametable (VRAM)
;File Data Block
.db $04 ;Block code
.incbin "KYODAKU-.BIN" ;file data
;-------------------------------------------------------------------------------
;File "MAINGAME"
;This file contains the main program and data.
;File Header Block
.db $03 ;Block code
.db $01 ;File Number
.db $01 ;File ID
.db "MAINGAME" ;File Name (8 uppercase ASCII characters)
.dw FDS_PRAM ;Where to load file to (16-bit little endian)
.dw (MainGameEnd - MainGameStart) ;File Size (16-bit little endian)
.db $00 ;File type
;0:Program (PRAM)
;1:Character (CRAM)
;2:Nametable (VRAM)
;File Data Block
.db $04 ;Block code
MainGameStart:
.include "MAINGAME.650" ;file data
MainGameEnd:
;-------------------------------------------------------------------------------
;End of Disk Side 1
.db $FF ;End of disk side indicator
.pad 65500, $00 ;zero out rest of disk
;-------------------------------------------------------------------------------
;Next disk side goes here.
"KYODAKU-" File
Code:
;File "KYODAKU-" data
HEX 24 24 24 24 24 24 24 24 24 24 24 17 12 17 1D 0E
HEX 17 0D 18 24 28 24 24 24 24 24 24 24 24 24 24 24
HEX 24 24 24 24 24 24 24 0F 0A 16 12 15 22 24 0C 18
HEX 16 19 1E 1D 0E 1B 24 1D 16 24 24 24 24 24 24 24
HEX 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
HEX 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
HEX 24 24 1D 11 12 1C 24 19 1B 18 0D 1E 0C 1D 24 12
HEX 1C 24 16 0A 17 1E 0F 0A 0C 1D 1E 1B 0E 0D 24 24
HEX 24 24 0A 17 0D 24 1C 18 15 0D 24 0B 22 24 17 12
HEX 17 1D 0E 17 0D 18 24 0C 18 27 15 1D 0D 26 24 24
HEX 24 24 18 1B 24 0B 22 24 18 1D 11 0E 1B 24 0C 18
HEX 16 19 0A 17 22 24 1E 17 0D 0E 1B 24 24 24 24 24
HEX 24 24 15 12 0C 0E 17 1C 0E 24 18 0F 24 17 12 17
HEX 1D 0E 17 0D 18 24 0C 18 27 15 1D 0D 26 26 24 24
;Translates to this in SMB/Zelda encoding:
;" NINTENDO R "
;" FAMILY COMPUTER TM "
;" "
;" THIS PRODUCT IS MANUFACTERED "
;" AND SOLD BY NINTENDO CO,LTD. "
;" OR BY OTHER COMPANY UNDER "
;" LICENSE OF NINTENDO CO,LTD.. "
And my "MAINGAME" file looks something like this:
Code:
;File "MAINGAME" data
;-------------------------------------------------------------------------------
NMI:
rti
;-------------------------------------------------------------------------------
RESET:
;I think BIOS initalize it so there's not much init code needed.
;I tried to play some sound here but nothing happened.
Main:
jmp Main
;-------------------------------------------------------------------------------
IRQ
rti
;===============================================================================
; Interrupt Vector Table
;===============================================================================
.org $DFF6
.dw NMI
.dw RESET
.dw IRQ
;-------------------------------------------------------------------------------
I suppose with the FDSStick we will finally see some more FDS homebrew again though.
I generally have this code so that my program doesn't suddenly reset to the FDS menu on NMI, IRQ, or reset:
Code:
FDS_HOOK
pha
lda #$C0
sta $0100
lda #$80
sta $0101
lda #$35
sta $0102
lda #$53
sta $0103
pla
rts
And perhaps this will help too?
Code:
.org $DFF6
.dw NMI_SUB
.dw NMI_SUB
.dw NMI_SUB
.dw Reset_SUB
.dw IRQ_SUB
You didn't have enough vectors in the right place.
Don't have the device yet...
Is the dumping ability able to do RAW disk image dumps as well as FDS ripped format?
Would be nice to finally get a RAW redump of as many things as possible and have emulators support the RAW format...
Yes, it can do raw dumps. There are different levels of "raw-ness" here. It can read out the timing of pulses on the data pin, from the flux transitions on the disk. That's as low level as anyone would care to go. With that, you can possibly recover disks that normally fail to read, though it might take some manual intervention or writing your own tools.
From there, it also tries to decode to a binary image (what an emulator would prefer to use). This is trickier than you might think, there is some guesswork in figuring out the clock phase and byte alignment. Between files there are discontinuities in the bitstream so you tend to lose your place a lot. (Alignment's not strictly necessary but it makes things more readable). The software does a pretty good job at this but there is room for improvement.
It can also read directly to .FDS. The process above is simplified, since it can make more assumptions about how the data is formatted.
Just tried this out. Works great!
Took me a moment to realize I have to press twice for side 2.
Later I'm gonna have to figure out how to build FDS files to play some music on it!
Yeah I heard the number of presses is an absolute code as opposed to relative from where you are (in other words you always press twice for side 2 no matter on which side you are). I like that.
ccovell wrote:
I generally have this code so that my program doesn't suddenly reset to the FDS menu on NMI, IRQ, or reset:
Code:
FDS_HOOK
...
And perhaps this will help too?
Code:
.org $DFF6
.dw NMI_SUB
.dw NMI_SUB
.dw NMI_SUB
.dw Reset_SUB
.dw IRQ_SUB
You didn't have enough vectors in the right place.
Oh right there are three NMI vectors. Thanks!
I added them and the FDS_HOOK code (I'm not sure what you mean, would it reset to BIOS just like that?) but it still doesn't work. It seems there aren't anything FDS specific needed in the main program so maybe the problem is in the header.
Lord Nightmare wrote:
loopy wrote:
The 2c33 can verify the CRC16, but you still read it off the disk like normal data. No weird tricks necessary (you can't seek backwards, btw).
So the crc16 is readable from the famicom/nes side? Interesting.
And by 'seek backward' I mean enable the motor right after it gets disabled and the head starts to swings back over the disk to the beginning, so the motor gets turned on and the gear re-engages before the head has fully retracted to the beginning, so you end up starting to read data somewhere random in the middle of the disk (I can't imagine this sort of shenanigans is good for the gears though, nor do I know if it will even work, there may be protections against the head re-engaging the motor unless it has fully retracted)
LN
The CRC check is simple
Each bit read is passed into the CRC calculator of the 2C33.
When the 2C33 is instructed to seek the start of a new block, the CRC is reset to zero (0).
Once the CRC becomes non-zero the 2C33 will begin collecting data.
Normally the 2C33 is instructed to seek the next block within a gap between blocks.
While in the gap each bit read will be zero (0) and while the CRC is zero (0) it will have no effect on it.
The first non-zero bit in the stream will determine the start of a block.
A status flag ($4030.4) will also be set if the CRC is non-zero.
Data is read until the end of the block.
The block length in all cases is determined either by the block ID or by the previous block and two data bytes will follow.
The purpose of these two bytes are to bring the CRC back to zero.
If the status flag ($4030.4) is set after these two bytes are read, the CRC is non-zero and the read has failed (error 27)
Code:
PROCEDURE update_crc(bit: Byte);
ASM
AND AX, 01H
XOR crc16, AX
SHR crc16, 1
SBB DX, DX
AND DX, 8408H
XOR crc16, DX
END;
This is the
correct CRC calculator.
Since there is no standard block size, it is up to the software to determine if there has been a read error.
Overload wrote:
Code:
PROCEDURE update_crc(bit: Byte);
ASM
AND AX, 01H
XOR crc16, AX
SHR crc16, 1
SBB DX, DX
AND DX, 8408H
XOR crc16, DX
END;
This is the
correct CRC calculator.
Since there is no standard block size, it is up to the software to determine if there has been a read error.
Ok so in C, that would be:
Code:
int crc16 = 0; // global counter
void updatecrc(int shifterContents) // shifterContents is the most recent 8 bits shifted in by the read head, lowest bit is the 'new bit'
{
int newbit = shifterContents&1;
crc16 ^= newbit;
crc16 >>= 1;
crc16 ^= 0x8408;
}
I'm not quite sure I 'get' what you're doing with SBB and DX, it looks like subtracting something from itself with borrow, I'm assuming that is a clever way to load DX with the constant 0xFFFF? wouldn't it be simpler to just MOV the constant 0x8408 to DX?
Edit: oh wait, NOW I see what you're doing! SBB DX,DX borrows if the prior opcode carried (i.e. if the shift off to the right had a 1 bit in it), so you get 0x0000 if the carry flag is 0, or 0xFFFF if it is 1. cute!
Code:
int crc16 = 0; // global counter
void updatecrc(int shifterContents) // shifterContents is the most recent 8 bits shifted in by the read head, lowest bit is the 'new bit'
{
int newbit = shifterContents&1;
crc16 ^= newbit;
if (crc16&1) {
crc16 >>= 1;
crc16 ^= 0x8408;
}
else
{
crc16 >>= 1;
}
}
LN
Lord Nightmare wrote:
I'm not quite sure I 'get' what you're doing with SBB and DX, it looks like subtracting something from itself with borrow, I'm assuming that is a clever way to load DX with the constant 0xFFFF?
SBB reg,self will set reg to 0xFFFF or 0 depending on the value of the carry/borrow flag. The whole thing is a way to avoid a branch prediction failure, which ... since this is an LFSR/CRC, the branch will be taken about 50% of the time.
lidnariq wrote:
Lord Nightmare wrote:
I'm not quite sure I 'get' what you're doing with SBB and DX, it looks like subtracting something from itself with borrow, I'm assuming that is a clever way to load DX with the constant 0xFFFF?
SBB reg,self will set reg to 0xFFFF or 0 depending on the value of the carry/borrow flag. The whole thing is a way to avoid a branch prediction failure, which ... since this is an LFSR/CRC, the branch will be taken about 50% of the time.
Yeah, I see, I had an edit dialog up while you did your post. I've updated mine above with correct info.
LN
I went ahead and just purchased one of these. Thanks for your hard work Loopy!
I mainly purchased it to dump games. With this I should be able to dump sealed games perfectly with the CRC and gap data correct? I've got a few sealed games already and may work on getting more picked up so we can have these FDS games preserved even better than before.
Hubz wrote:
I mainly purchased it to dump games. With this I should be able to dump sealed games perfectly with the CRC and gap data correct? I've got a few sealed games already and may work on getting more picked up so we can have these FDS games preserved even better than before.
Yes, you can get a raw dump with CRCs and all.
Copy Master software original from BUNG cracked by Me. (Keep original, no any modify). This fds image is doctor format (copier format). So, you need fds copier to run it. Download from fdsstick.com
Because I'm the FDSSTICK reseller, I made a website
http://www.fdsstick.comIt is unofficial fdsstick website. Loopy haven't join it yet. I'll keep release something.
At the moment, fdsstick not support file bigger than 64K per side. But if docter format image smaller than 64K. It is supported.
Waitting Loopy update firmware or fdsstick 8M version.
If you only need normal fds game support, fdsstick 4M version already perfect.
Can anybody make a cable for me and I'll buy it? I had some AV cables but none have enough pins. I'm guessing the SCART is the only one that has them.
Managed to get one whipped up and I think once I'm done dumping i'll be able to salvage it for my FDS RAM Adapter.
Works great! I have gotten dumps of various brand new games in both raw and FDS. The only thing I wondered about was I keep getting wrong block types with FDS dumps a majority of the time. However loading the game up in an emulator and it seems to play fine. Is that anything I should be concerned with?
Hubz wrote:
The only thing I wondered about was I keep getting wrong block types with FDS dumps a majority of the time. However loading the game up in an emulator and it seems to play fine. Is that anything I should be concerned with?
Nah, don't worry about it. I should get rid of that warning. It's telling you there's extra garbage at the end of the disk (which is pretty much ALWAYS the case).
USA customer please use this website to order.
http://3dscapture.com/fdsstick/
help me troubleshoot this. I can't read disks. I get this error, I may have to change the src to get some more debug info.
"Read error."
"Failed."
sounds like chris' problem from page 10, I tried different PCs and ports. I can hear the head moving.
Here's the pinout for my cinpel cable. all mine are joined except black. my cable is about 4 inch.
= equals no pin
(this is looking at the connector)
__#############__
################
### O = Blk = Y W ###
### G Bl = = Br R ###
#################
#################
Hmm, I'm not sure. The pinout is right. Re-check the wiring?
This is in Windows? Occasionally it does fail and the USB end needs to be reinserted. It should only take a few tries though. How does it fail? Does it exit immediately or time out?
Hi Hubz,
How do you make the cable ? I make my own, but it is not work. At first, I think cable too long. Then I cut it short, it still not work.
If I connect two fdsstick on both end of cable, then put one fdsstick connect to PC. I can read other fdsstick(with game inside) with the one connected to PC. So, I beleive the cable is good. Only don't know why can not read disk.
Thank you
I traced the connector with a multimeter and soldered the wires. It's ghetto but works. I'll take a pic and post it later.
Wow, you directly connected it. When I back home, I will try it. Thank you.
let us know the results.
my problem is still unresolved, I suspect my drive. I checked my cable it seems to be good, continuity through the cable and connector, I checked from the pins to stick. I don't want to solder wires to it either
so I changed the src code to print out the values returned from the function calls but they didn't mean much to me. maybe someone can add some more logic as to why "read failed" so we can debug our problems a little easier.
fdsstick works great other than that though.
Hi DrDementia,
Sorry for the late. I can't get it work. My case is same as yours.
The error is from fdsstick as I understand. So, it is no easy to know what is the problem from the source I think.
I've 4 PCs, only one have better result. All others will fail when the magnet head return to the beginning of disk.
It will show error immediately. I saw Chris post, said his good PC have USB 3.0 powered. I try my PC which have USB 3.0, it can read
FDSSTICK, but not fds drive.
Then I try to add some buffer between fds drive and fdsstick. The problem still the same. No idea what is the problem at the moment.
I already rquest loopy to try more PC, I waiting for his test now. If some PC not compatible with fdsstick. I think loopy can update
firmware to fix it.
I doing Twin Famicom to fdsstick cable at the moment. It should be working well I think.
Can someone tell me how to physically write to disks with this?
On read errors - I've found that a series resistor (10k or so) on the READ DATA pin ("pin 9" in my pinout diagrams) helps.
http://3dscapture.com/fdsstick/fds_res.jpgI built a GUI, it's not quite finished but you can try it out.
http://3dscapture.com/fdsstick/FDSStick.exeI made a small change to the firmware to make using the button easier. Instead of slot numbers, you push the game number (1, 2, 3, etc..). After the game loads, the button changes disk sides (1=A, 2=B, ...)
I tried the 10k resistor, didn't seem to work, not one successful read yet. I tried two PCs, different ports. I don't have a usb3.0(blue) port so I can't test that. Most of the time reading fails at the beginning of the disc (right before or after click?). I reinserted the stick each time.
I'll try to test and debug some more when I have some time.
Tomy wrote:
I've 4 PCs, only one have better result. All others will fail when the magnet head return to the beginning of disk.
It will show error immediately. I saw Chris post, said his good PC have USB 3.0 powered. I try my PC which have USB 3.0, it can read FDSSTICK, but not fds drive.
So does that rule out the fds drive? does the pc that works(have better results) always work?
I attached my modified fds.exe. it prints out more info, maybe loopy can get some debug info from this. maybe someone can show me what a successful read looks like. I should have probably gave some more meaningful labels.
here's one of my better reads. (we need a spoiler to hide this text)
fds -r read1.fds
FDSStick console app (Aug 31 2015)
Opened FDSStick (xxxx.xxxx)
dev-readstart
readbuf
result D3118E
bytesin 0
readbuf 9F0020
dev rd result 100
buff
result FE
bytesin FE
readbuf 9F0020
dev rd result 100
buff
result FE
bytesin 1FC
readbuf 9F0020
dev rd result 100
buff
result FE
bytesin 2FA
readbuf 9F0020
dev rd result 100
buff
result FFFFFFFF
Read error.
Failed.
Hi DrDementia,
My problem solved. I can read FDS disk now. Not yet for write.
What I do is :
1) Add 10k resistor on pin 9.
2) Update fdsstick firmware to v1.03
3) FDS Drive don't mod, let it original
4) Modded Power Board v5
I've 4 PC here. Now, two PC very stable. One PC sometimes error, re-insert fdsstick, it is ok again. Only 1 PC with AMD CPU not work (never work)
The cable I make is very long (2 feet). So, "long" is not the problem.
Because I don't have 7201 drive here, I can't test write. I'm finding a way now, if I can write, I'll tell you.
I tried your fds.exe, it is not work for me. It error everytime, never success. I use loopy fds.exe v2 at the moment.
Hi DrDementia,
I can write FDS disk now.
What I do is :
1) Add 10k resistor on cable pin 9.
2) Update fdsstick firmware to v1.03
3) FDS Drive with 7201 chip (no need to mod)
4) Modded Power Board v5
All my 3 PCs ok, only the one with AMD CPU not ok.
I can Read and Write FDS disk.
Where can I download the firmware with edited button function? Thanks
Download this :
http://3dscapture.com/fdsstick/FDSStick.exePlug in fdsstick to your PC and run FDSStick.exe
It will auto update your fdsstick firmware.
(It will show updating on screen, don't remove your fdsstick at that time. If not, I afraid it may die.)
I updated the windows GUI (fdsstick.exe) to allow disk reading/writing.
Tomy wrote:
The cable I make is very long (2 feet). So, "long" is not the problem.
I tried your fds.exe, it is not work for me. It error everytime, never success. I use loopy fds.exe v2 at the moment.
thanks for clarifying the cable length, mine is a little too short.
Thanks for testing. does loopy' fds.exe v3 work for you? why use v2?
My further testing. I tried the new gui (fdsstick.exe) I could only get it to read the first 0x33 bytes or so of the disks- sometimes less. I tried most of my discs around 20, some multiple times. I got part of the header the "NINTENDO HVC". I could never get a whole block. I always get - crc failure and 508 bytes lost.
My setup was similar to Tomy's. I tried with and without the resistor, same results.
1) 10k resistor on pin 9.
2) 3206 FDS Drive unmodded
3) Modded Power Board v5
I got another FDS
with a 7201. I tried reading with it and get the same thing only part of the header. Any clue to what I'm missing?
finally success, reading and writing with the gui.
tomy was right try different PCs.
It seemed to work perfectly with one pc I have. It is a AMD winxp 32 bit laptop.
non working PC(s). I tried different ports in all these.
notebook win7 32bit intel (read always resulted in 0x00 filled file)
desktop winxp 32bit intel (read got part of disk header then 0x00)
desktop winxp 32bit (same)
no usb3.0 ports in any of those.
Thanks for the help and the great product.
and I hope this helps someone else in the future.
hello all I am so glad to have found other people with the same struggles as me
(well, not so many now ; see EDIT)
I have a 3206 drive with tototek write chip installed, v5 power board modded
I am using a cable I made using 2 x N64 scart cables
-previously I was able to dump 1 disk when my cable was setup to 'read only'. (with power board mod only, no tototek chip at this time)
-after modifying my cable (link black wires + move pin 8 to pin 5)(I am using a switch to link the black, so I can switch it off to just read disks ; not sure if this is correct), I now cannot read or write any of my disks and it appears I have somehow wiped all my disks (only 3)...
I have just updated firmware using the new GUI (very cool thx) and will try to use the 10k resistor on pin 9. Can anyone inform me of something wrong I did to wipe my disks and stop my setup from being able to read or write ? I have bought some new disks but am a little scared to read them, incase I somehow wipe them too!
* I have 4 FDS drives here, only one has been powerboard + tototek chip modded so can try lots of stuff *
thanks guys I would really like to get disk writing going - i love my fds stick but nothing beats the read/write mechanism of the old 2.8" drives!!
EDIT: OK i realized my newest FDS unit actually has a 7201 (
) so I have been able to re-write all of my previously blanked disks. I do still have the same problem with the tototek chip modded 3206 drive, it will play disks which I have written on the 7201 drive, but it cannot dump or write using the fds stick... When I try to dump, I get an empty .fds file (correct size in KB, but a completely empty file, same for writing, fdsstick.exe software says its writing, the drive mechanism moves correctly, but I end up with a totally blank disk)... Can anyone help me to fix this ?
p.s. the cable I made using the two N64 scart leads works, reads and writes with the black cable moved to pin 8.
p.p.s i did all my reading/writing in Windows 8.1 Pro x64 on my Lenovo W530 laptop using a USB2.0 port
Hi evilsim,
I'm sorry. And I tested it like you say.
And it is same as you. So, I confirm 3206 modchip is not compatible with fdsstick read/write.
When it is develop, fdsstick haven't appear. So, I can't know that.
It is working good except fdsstick. Like Copy Master 1.1, Disk Hacker else.
Also, it can work with any fds game with save function like Zelda.
I'm finding a way to make it compatible with fdsstick. But need some times.
I will check what different with Copy Master and fdsstick read/write.
Hope will fix soon. Thanks.
Tomy wrote:
Hi evilsim,
Thanks for the reply Tomy, I understand that fdsstick and this chip don't work yet. I am happy to wait and see if a new firmware on the fdsstick will resolve this problem. Like I said I have 4 FDS drives, one of them is in a TwinFC and 3 loose FDS units, one being a 7201. If there is any further testing I can do to help, or if you need someone to test some new firmware I am happy to help.
I don't have a 3206 drive to test with. Would the modchip have the same effect with a 7201?
loopy wrote:
I don't have a 3206 drive to test with. Would the modchip have the same effect with a 7201?
cut the traces to the write gates on a 7201 !? blasphemy
i'll send u a 3206 if you send me a 7201
---
I tested out using diskhacker and such apps with my chipped 3206, it appears to write to the disks, but due to it not writing the correct header (or something) the disk gives me an error 20 when I try and load it on my TwinFC or regular FDS
---
Correction from above : Disk Keeper (I was able to write the diskkeeper disk using the fdsstick + 7201 drive) actually lets me write disks using my 3206 with tototek mod chip. hooray two of my drives can write full disks now.
New software update
is available (Windows GUI). Supports larger flash, and boots to a menu (credit to deadbody for inspiration
). I'll throw the source up on github, it may take a few days to get it organized.
Also, I got proper injection-molded cases done, so no more 3D printing. (They've been shipping for a while, I just haven't announced it til now).
loopy wrote:
New software update
is available (Windows GUI). Supports larger flash, and boots to a menu (credit to deadbody for inspiration
). I'll throw the source up on github, it may take a few days to get it organized.
Also, I got proper injection-molded cases done, so no more 3D printing. (They've been shipping for a while, I just haven't announced it til now).
Just tried the update- I really like the menu! Thanks.
loopy wrote:
New software update
is available (Windows GUI). Supports larger flash, and boots to a menu (credit to deadbody for inspiration
). I'll throw the source up on github, it may take a few days to get it organized.
Awesome job the menu is really handy. I noticed the following ;
-menu lists games you have loaded in upside down order eg game in slot1 is at bottom of list
-after loading new firmware, using older fds.exe to load games does not work properly (no menu and cannot open any games with button)
-i was being stupid and not pressing the "write" button after loading a few games, via fdsstick.exe. until now i had been using fds.exe hehe
love your work Loopy - and loving my new rgbnes mod too - Tim Worthington has tons of stock, i was at his house y/day and he had just received a shipment of boards
rgbnes mod makes the fds games even better!!
I had to try the new firmware with the loading menu and I love it! No more need to memorize the list of games on the FDSStick, which will undoubtedly be appreciated by other people who have a device that can hold more than eight disk sides.
I found that when I added disk images to fdsstick.exe, it put them in alphabetical order and the FDSStick menu also showed them in alphabetical order. I also note you can now remove an image without having to rewrite the whole flash using fdsstick.exe. I really do not know how FDSStick can be improved at this point for playing FDS images.
Yeah, you shouldn't use the older fds.exe right now, it isn't compatible with the updated firmware. I'm working on a few more things in the GUI (should be ready in a day or two) then I will roll all the recent changes back into the console app.
I would hope that an FDSStick 2.0 design might use a microSD card that would allow dragging and dropping of files from any computer and be entirely FDS menu driven (for reading and writing real disks). One concern I have is that FDSStick.exe is a Windows application which may one day become obsolete (whenever Microsoft wants to find a new way to disable unusual devices in the name of security.) Getting the EMS 64M GB Smart Card to work in Windows 7 or 8.1 is always something of a trial because it connects directly via a USB cable and Microsoft's OSes refuse to load unsigned drivers without doing things like entering test mode. Getting the EverDrive GB to work in anything is a pure pleasure by comparison. I note that FDSStick does not have a driver file to load, but there is always the concern.
As you noted, it doesn't require drivers so your point is somewhat lost on me. It identifies itself as a HID device, I did this specifically to avoid dealing with drivers.
loopy wrote:
As you noted, it doesn't require drivers so your point is somewhat lost on me. It identifies itself as a HID device, I did this specifically to avoid dealing with drivers.
Thank you for that explanation and for choosing the HID device instead of relying on device drivers. I don't think support for the HID specification is likely to disappear anytime soon.
Still loving the built-in menu by the way. I'm amazed it could be done with the original hardware.
Another
update. Some minor bugfixes, and more flash types supported. Standard flash size has been changed to 128Mbit.
Hey, are any of you guys members of "Japanese Retro Video Game Discount Market" group on Facebook? I just noticed the following post an hour ago:
"just a quick warning to anyone using an fds stick flashcard on their famicom, don't upgrade the firmware, the latest pc software (20/dec/2015) included the latest firmware update but if you have one of the older versions i'm afraid it can kill your card (see photo) the update is so large including its new menu system that it fills the whole card (the blue bar at the bottom) and there isn't a way to roll it back so you'll need to pay for an upgrade ($10 + shipping) to get it working again."
followed by:
"in case you didn't know this new firmware is also incompatible with the disc dumping software (used to dump your discs to the card / pc) but a new version is being worked on. and you'll still need an additional ram copier (like the venus) to run / copy your blue discs (with hacked or patched files on that load as one big disc from several sides)."
I wasn't aware there were different FDSStick versions.
leonk wrote:
Hey, are any of you guys members of "Japanese Retro Video Game Discount Market" group on Facebook? I just noticed the following post an hour ago:
"just a quick warning to anyone using an fds stick flashcard on their famicom, don't upgrade the firmware, the latest pc software (20/dec/2015) included the latest firmware update but if you have one of the older versions i'm afraid it can kill your card (see photo) the update is so large including its new menu system that it fills the whole card (the blue bar at the bottom) and there isn't a way to roll it back so you'll need to pay for an upgrade ($10 + shipping) to get it working again."
Err, no. The firmware isn't "so large that it fills the whole card". It isn't stored on the main flash, and it's compatible with all boards. The only difference between different FDSStick boards is the size of flash, newer ones hold more games.
It looks like a bug in the software, maybe not initializing the flash fully during the update. I'll look into it. Also, the console app should only be used on the old firmware, I should probably just take it down for now. Maybe they are using that, and that's what's causing problems.
If you clear the flash (use the console app, run "fds.exe -e all"), that will probably fix the problem.
leonk wrote:
followed by:
"in case you didn't know this new firmware is also incompatible with the disc dumping software (used to dump your discs to the card / pc) but a new version is being worked on. and you'll still need an additional ram copier (like the venus) to run / copy your blue discs (with hacked or patched files on that load as one big disc from several sides)."
I wasn't aware there were different FDSStick versions.
Games made for those Bung copiers are larger than the standard .FDS format can hold. They're not supported YET but I'm working on it.
I'll check out that facebook group and try to answer questions.
Thanks for loopy quick respond and support. Mike fixed his problem with "fds.exe -e all" command.
I tried to update the flash, but it failed. Is there a way to reupdate the flash. I am unable to use the FDSStick on the RAM adapter. I can still write to disks, but most of the time it fails to fully write the image to disk.
Hi stevep31,
You can use old software to downgrade fdsstick's firmware.
When you run old software, it will ask you upgrade.
Then just click ok, it will downgrade fdsstick's firmware to older version.
After that, you can upgrade again by using newer software.
Hope that help.
-Tomy
Thanks! I was able to downgrade then upgrade to the latest firmware
I fixed a bug that was causing games to be written out incorrectly, it's available to download now. This was probably the source of your problem.
A bad update is highly unlikely since the firmware is verified before & after. The process of downgrading and upgrading probably "fixed" your issue by clearing the flash contents.
Hi
I haev a question
Now I have 2pcs 4M FDSStick.
Can I upgrade to 128M version simply replacing flashrom ?
Yes, you can upgrade by replacing the flash and using the newest software.
Micron or Winbond flash should work (like W25Q128FVSIG). It's larger than the 4M chips I used, but it can fit by bending the pins under the chip.
Thank you loopy !!
I will try.
loopy wrote:
Yes, you can upgrade by replacing the flash and using the newest software.
Micron or Winbond flash should work (like W25Q128FVSIG). It's larger than the 4M chips I used, but it can fit by bending the pins under the chip.
Has anyone tried this? I also have a 4M FDSStick I'd like to upgrade.
I upgraded 4M->128M successfully using winbond 25Q128FVSG.
Thanks loopy.
I am waiting for a new pair of flush-cuts to arrive before I attempt this. Kazmat, can you tell me the process you undertook to swap it over, I have not had to swap out such a small chip before - I really don't want to wreck it. I do a lot of soldering work and pcb modifications etc but just a bit cautious on this one.
kazmat wrote:
I upgraded 4M->128M successfully using winbond 25Q128FVSG.
Thanks loopy.
kazmat wrote:
I upgraded 4M->128M successfully using winbond 25Q128FVSG.
Thanks loopy.
Awesome!, gonna order the part.
Another
software update. PC emulation mode is added - games can be loaded directly from a PC. Handy for trying out games without having to disconnect and reflash. It's also convenient for NES development. With FDSStick software running in the background, just recompile and hit reset on the NES to reload your game.
Hi loopy,
Thanks for new update. Few days later here is Chinese Happy New Year.
Good gift for it.
I saw you add Twin Famicom to fdsstick connection pinout.
I want to ask, is it still connect 8 pins are enough ?
Tomy wrote:
I saw you add Twin Famicom to fdsstick connection pinout.
indeed, good work Loopy !!
loopy wrote:
Another
software update. PC emulation mode is added - games can be loaded directly from a PC. Handy for trying out games without having to disconnect and reflash. It's also convenient for NES development. With FDSStick software running in the background, just recompile and hit reset on the NES to reload your game.
The software just keeps getting better and better. I never imagined back in late July that it would become so advanced. Using the PC instead of the FDSStick's flash to load games also makes being an early adopter with the small flash size much more bearable. I tested it with Metroid v1.02 and I was able to start, save, load and play a game. Amazing work!
One possible bug or suggestion, if you switch to a different tab in the FDSStick.exe program and switch back, you have to reload the disk image. This can be a bit nerve wracking if you are in the middle of a game and need to save and you are on the wrong disk side. I know and you know the games are supposed to check for the proper side before reading or writing to the disk, but the next guy may not.
evilsim wrote:
I do still have the same problem with the tototek chip modded 3206 drive, it will play disks which I have written on the 7201 drive, but it cannot dump or write using the fds stick... When I try to dump, I get an empty .fds file (correct size in KB, but a completely empty file, same for writing, fdsstick.exe software says its writing, the drive mechanism moves correctly, but I end up with a totally blank disk)... Can anyone help me to fix this ?
New update is up. I fixed the problem with Tototek 3206 write mod chips and made some other changes that should make disk reading and writing more reliable.
loopy wrote:
New update is up. I fixed the problem with Tototek 3206 write mod chips and made some other changes that should make disk reading and writing more reliable.
Wow nice stuff loopy, I did however accidentally rip up a trace on my FDSStick while upgrading to 128MB so I have ordered another from tototek and will have to wait for its arrival before I can test this out. I would like to repair the existing one, but its friggin tiny. I obviously thought the chip was hot enough from the solder tip when i went to move it and it ripped a trace very close to the main chip on there..
Just want to let you guy know, if you want to mod your 3206 drive for use on fdsstick. Then you *MUST* use V2 3206 Mod Chip.
http://www.tototek.com/store/index.php?main_page=product_info&cPath=1_35&products_id=143Also, you *MUST* use latest software from fdsstick site.
If you use V1 chip on fdsstick, then you can not read or write. Also, when you read disk, it will format your disk. I'm sorry about that. But V1 chip had been released before fdsstick. I don't know it is not compatible with fdsstick.
Tomy wrote:
I saw you add Twin Famicom to fdsstick connection pinout.
I want to ask, is it still connect 8 pins are enough ?
No, connect them all. The 8-pin cable is only for disk dumping.
I made a small adapter board to make it easy to hook up a ram adapter cable, it's a purchase option for fdsstick now.
Loopy, are those pin headers / cables for the back of the Twin Fami standard parts? I tried looking around Akihabara / junk shops in my area to find some identical pin types with no luck.
Any chance of a single purchase of just some adaptor cables for the Twin?
I don't think it's standard, you probably won't find the right connector for it. Try searching for a 2.50mm pitch header instead.
I'm not selling cables, it's just a board that lets you connect the cable pulled from a ram adapter.
It would certainly be nice to get some custom cables manufactured but I don't think that's feasible for this small project.
I actually tried a 2.5 mm pin header and it fit just fine in the Twin Fami. Not sure about the connector that plugs into the RAM adapter cable though.
Loopy, I soldered together an adaptor board for my Twin Famicom, and it worked!
BUMP:
I tried out the Twin Famicom adaptor and saving/kill mode in Zelda II always gives me an "error 24". It works fine when I run the FDSStick through an FDS RAM Adaptor in the cartridge slot. Any ideas why?
Older FDSsticks (before I started making the Twin Fami adapters) will need an extra resistor from pin 6-10 on Port C. I use 27k, but somewhere around 10-50k should do...
loopy wrote:
Older FDSsticks (before I started making the Twin Fami adapters) will need an extra resistor from pin 6-10 on Port C. I use 27k, but somewhere around 10-50k should do...
Just to confirm, this is bridging "-> DATA" with "VCC" by a resistor?
Yes, it's a pullup on the write data line.
OK, I added pullups to all the outputs noted in deadbody's post (
viewtopic.php?f=9&t=13520&start=45#p165112 ) and now both devices appear to work great in my Twin Famicom.
... maybe next I'll add a piezo buzzer to the data line to get some sound out of the thing. ;-D
I finally got around to adding support for Game Doctor (a.k.a. "famicom copier") disk format. So, have fun with that... all 3 of you
Also, the flash code has gone through a major rewrite and sped up significantly (about 10X faster than before) so it's worth updating just for that.
Download from
the usual place.
loopy wrote:
I finally got around to adding support for Game Doctor (a.k.a. "famicom copier") disk format. So, have fun with that... all 3 of you
loopy, big thanks to you. I'm sure *NOT* only 3 people interest in it. I'm in holiday now. I want to try out 10x flash operation speed.
Looking forward to trying the Game Doctor stuff on it. Great work!
Is there a way to fully reset the device/firmware? When I was using the windows program to read a bunch of disks, the Windows USB unplugged notification sound triggered. Now every time I try to do something other than read disks through the program the red LED just stays lit and the Famicom just stays on "Now Loading..." I can still read disks fine, and if I plug the Famicom and FDS normally, without the FDSStick everything still works as it should.
Hi KittyFae,
Are you using latest version of the software ? If yes, you can downgrade your fdsstick with this version.
http://3dscapture.com/fdsstick/FDSStick_20160220.exeAfter downgraded your fdsstick, you can upgrade again with latest software.
It should fix your problem if upgrade failed before.
Tomy:
I tried that and it didn't work, not sure if it was the whole firmware being updated/re-written or just a part of it. I've also gone to the one just older than the one you posted then back up to the most recent to no avail.
I've read this thread and saw there was some debugging things in a previous (CLI) version and a way to clear the contents of the flash. Is there anything similar to these options in the GUI version?
Looks like it is my FDSStick that is messed up, the ground and write gate are shorted together on the stick itself with nothing else connected. Sent a PM to Loopy about it. Thanks for the help, Tomy.
Hey Loopy,
Do you still have the old firmware available somewhere? I recently updated my stick and am running into issues dumping a few disks. But they work fine in the FDS drive itself. I had the old console version that could do RAW/BIN dumps. That seems to be missing from the new version unless I'm missing something.
Thanks for your help!
- Hubz
I've updated the
software to read+write raw dumps (change the file type when choosing a file).
I made a minor board change a while ago that makes disk reading more reliable on certain drives. If you have an older board, you can do it yourself (if you have the right tools). It's an improvement over the resistor fix/hack
mentioned here. (If you can already read other disks ok, this probably isn't necessary.)
Bridge pins 11 and 12 on the mcu:
loopy wrote:
I finally got around to adding support for Game Doctor (a.k.a. "famicom copier") disk format. So, have fun with that... all 3 of you
Also, the flash code has gone through a major rewrite and sped up significantly (about 10X faster than before) so it's worth updating just for that.
Download from
the usual place.What exactly is the Game Doctor format and where do you even find information or example dumps of it? I've been curious to see any examples but never could find any. I know of the devices like the TGD6, "Game Converter", etc. I've heard most support NROM, CNROM, UNROM, and some support hacked MMC1 or MMC3 games. I think I read somewhere that one actually can run unhacked MMC3 games.
Can anyone point out any information on the subject?
Yeah. It's an enigma to me too.
What tools use these files? How were the dumps made? I guess it would be more aptly named
MGD1 format. I was given some sample files, I deduced the format on my own. It's similar to .FDS. Only a 3-byte header. 2 extra CRC bytes with file blocks. No fixed file size. One file for each disk side, named *.A, *.B, *.C, etc. I would post a dropbox link with roms but I don't think that's kosher here.
Figuring out how Game Doctor (& friends) works would be an interesting subject deserving its own thread, there's very little information about it. I think Tomy knows more.
---
Incidentally, this thread should have been split a long time ago.
I didn't announce it here yet, fdsstick price was dropped and flash size increased a few weeks ago.
I ... I'm not touching this one. Even thinking about it is exhausting.
You be you, man. Go you.
loopy wrote:
Figuring out how Game Doctor (& friends) works would be an interesting subject deserving its own thread, there's very little information about it. I think Tomy knows more.
I'm certainly curious about the Game Doctor and friends since there were several different units with somewhat different capabilities that aren't entirely clear. No emulator support or technical documents seemed to pop up. No disk image dumps easily found.
But I guess the devices aren't very common and certainly not outside Asia. I just am curious since it's the start of what went on to bring us the SNES copier era. Those things seemed to be everywhere.
So I finally figured out how to write to disks using the FDSStick and a Twin Famicom.
1) Make or get the normal FDSStick to Twin Famicom pin connector (the add on option when ordering)
2) Get a proto board and wire up 2 female 12 pin header connectors and wire them both together pin-to-pin
3) On a blank space for the proto board solder in a male 12 pin connector (the one that goes into port D)
4) Connect the ground and power pins from the 12 pin male into the two 12 pin female adapters (Pins 9 and 10 on Port D, pins 2 and 4 on the RAM adapter cable)
5) Plug in the cable from step one into one of the 2 female 12 pin connectors, connect the stock plug you unplugged and plug that into the other connector
6) Turn on the famicom and you are good to go using the FDSStick GUI, and not having to open the console.
This is at least how I was able to successfully dump and write to disks using the build in FDS drive on the Twin Famicom
http://www.tototek.com/store/index.php? ... cts_id=207It is new and not like other modchip, it don't need to cut any wires on the drive board. And of course support fdsstick.
FDSStick Transfer Cable
http://www.tototek.com/store/index.php? ... cts_id=206If you know how to use solder iron, I sugguest you make it by yourself. This product is for people who can not make by themself. All info can find on loopy site.
Has anyone connected a ram adapter to the cart port on a Twin Famicom and got the FDSSTICK or a FDS drive to work with it that way? I always assumed it would work but never tried it until now.
*Edit*
Tried another Famicom Twin and it worked fine, turns out my other Famicom Twin has a fault.
Update:
Scratch that I managed to get it working. Most versions online appear to be improperly patched so you have to do it yourself.
Original Post:
Has anyone tested the Kalin no Tsurugi (Sword of Kalin) English patch?
Every time I try to load it I am getting Disk Trouble ERR. 25
If you run the game unpatched it works fine so I am not sure why the english patch breaks the game. :\