It is currently Tue Dec 12, 2017 3:02 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 259 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11, 12 ... 18  Next
Author Message
PostPosted: Fri Jul 10, 2015 1:34 pm 
Offline

Joined: Fri Sep 14, 2012 12:17 pm
Posts: 76
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.


Top
 Profile  
 
PostPosted: Fri Jul 10, 2015 11:32 pm 
Online

Joined: Sat May 06, 2006 9:19 am
Posts: 42
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 !


Attachments:
File comment: Added backup save function
fds_v2.02.7z [24.37 KiB]
Downloaded 55 times
Top
 Profile  
 
PostPosted: Sat Jul 11, 2015 3:16 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 919
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Sat Jul 11, 2015 3:50 am 
Online

Joined: Sat May 06, 2006 9:19 am
Posts: 42
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.


Top
 Profile  
 
PostPosted: Sat Jul 11, 2015 7:03 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 631
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.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Sat Jul 11, 2015 9:01 pm 
Online

Joined: Sat May 06, 2006 9:19 am
Posts: 42
Hi Great Hierophant,

fds v2.1 can save whole game's slots. Any problem, please tell me.

(it is not loopy original build)


Attachments:
File comment: Game save change to whole game save instead of single slot save.
fds_v2.1.7z [24.62 KiB]
Downloaded 55 times
Top
 Profile  
 
PostPosted: Sun Jul 12, 2015 11:08 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 923
Location: Japan
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:

Image

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.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Mon Jul 13, 2015 2:35 am 
Offline
User avatar

Joined: Tue Sep 28, 2010 3:27 am
Posts: 178
Location: Slovakia
Thanks Tomy for working on the controll software, delete function is great!


Top
 Profile  
 
PostPosted: Mon Jul 13, 2015 10:04 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 631
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?

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Mon Jul 13, 2015 10:18 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
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.


Top
 Profile  
 
PostPosted: Tue Jul 14, 2015 7:31 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
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.


Top
 Profile  
 
PostPosted: Tue Jul 14, 2015 9:56 pm 
Offline

Joined: Wed Apr 05, 2006 10:12 am
Posts: 126
Location: PA, USA
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

_________________
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"


Top
 Profile  
 
PostPosted: Wed Jul 15, 2015 7:35 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 919
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Wed Jul 15, 2015 8:57 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 631
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.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Wed Jul 15, 2015 12:31 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
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).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 259 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11, 12 ... 18  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group