FDS header date fields

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: FDS header date fields

Post by Pokun »

Oh yeah I forgot Tomy (Tototek) is selling the read/write cable. Since oRBIT2002 is Swedish that's also were he will have to buy the FDSStick, so he can combine shipping.


Yeah I know Copy Master has speed measuring function. I'm not convinced that you can get disks to work universally on all drives though. Not that I've tried, it's just my impression from people that are writing disks. It's best to only overwrite broken disks for this reason and clearly mark the disk that it has been home-rewritten, or there will be harder and harder to know what's wrong with disks in the future.

I have actually been disassembling Copy Master with the hope to figure out how it measures the speed and make my own speed measuring program so that the Game Doctor isn't needed. I've been unable to follow the code very far though, and the fact that the disk doesn't work on most emulators doesn't help.
ZReport
Posts: 21
Joined: Thu May 31, 2018 11:57 pm

Re: FDS header date fields

Post by ZReport »

Pokun wrote: Thu Mar 18, 2021 4:33 am Oh yeah I forgot Tomy (Tototek) is selling the read/write cable. Since oRBIT2002 is Swedish that's also were he will have to buy the FDSStick, so he can combine shipping.


Yeah I know Copy Master has speed measuring function. I'm not convinced that you can get disks to work universally on all drives though. Not that I've tried, it's just my impression from people that are writing disks. It's best to only overwrite broken disks for this reason and clearly mark the disk that it has been home-rewritten, or there will be harder and harder to know what's wrong with disks in the future.

I have actually been disassembling Copy Master with the hope to figure out how it measures the speed and make my own speed measuring program so that the Game Doctor isn't needed. I've been unable to follow the code very far though, and the fact that the disk doesn't work on most emulators doesn't help.
I've also never been fully convinced myself but TBH I don't think such a process has been measured thoroughly either for good or bad. Now that I think about it, I have a number of (busted) FDS drives, along with 3 working ones (one cannot copy properly to the other two) and I think what I might do is measure them all while I repair all of the busted ones, then send out a few test disk copies to other people to see if they will work on certain speed tunings.

It would be awesome to have an FDS Speed Tuning program, seeing as it's extremely difficult to find a Game Doctor now, and it's just not feasible any more. Ironically, I also think we are well into the future that someone might be able to reverse engineer a GD and build a new one perhaps. There are a number of Copy Master programs that have been reversed, but I don't think the speed tuning feature is on any of them, or perhaps hidden from the respective software UI.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: FDS header date fields

Post by Pokun »

You mean the speed measuring is done on the Game Doctor itself? That is unfortunate. Still, the disk drive is connected to the RAM Adapter as normal, so the measuring must be done entirely from the information you can get from communicating with the drive. I might not really know what I'm talking about, but I feel like it should be possible to do it entirely in software? It would be nice to have a tool that can just be loaded up with the FDSStick then connect the disk drive.

I've noticed that the Copy Master does some strange things like writing from $00F9 to $4026 although the RAM Adapter expansion port isn't used by the Game Doctor. I guess it might just be part of some standard initialization though.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: FDS header date fields

Post by NewRisingSun »

You mean the speed measuring is done on the Game Doctor itself?
No, but the program in general uses disk I/O routines from the Game Doctor BIOS, and uses the Game Doctor's additional memory to store the program code along with the full content of an entire disk.
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: FDS header date fields

Post by ccovell »

OK, I've made a newer version of the Disk Lister that lets you read the disk the old way, or you can press START to put it into a deeper scanning mode, which will display more of the disk's header, as well as try to read and display all file headers on the disk.

http://chrismcovell.com/data/FDListNAM2021.zip

If the number of files in the header doesn't match the actual number of files found (more or less) then it'll print the two numbers beside each other. This can be an indicator that 1) there is a hidden file, 2) the physical surface of the disk has some errors or dying data, 3) your drive belt is wearing out, or... 4) maybe my program has some bugs in it. (My prog should be safe, but caveat emptor.)

Hidden files will also be indicated by a red square in the file list.
Image
User avatar
loopy
Posts: 405
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Re: FDS header date fields

Post by loopy »

Pokun wrote: Sat Mar 20, 2021 11:44 am You mean the speed measuring is done on the Game Doctor itself? That is unfortunate. Still, the disk drive is connected to the RAM Adapter as normal, so the measuring must be done entirely from the information you can get from communicating with the drive. I might not really know what I'm talking about, but I feel like it should be possible to do it entirely in software? It would be nice to have a tool that can just be loaded up with the FDSStick then connect the disk drive.

I've noticed that the Copy Master does some strange things like writing from $00F9 to $4026 although the RAM Adapter expansion port isn't used by the Game Doctor. I guess it might just be part of some standard initialization though.
Old thread about using fdsstick for drive tuning - http://forums.nesdev.com/viewtopic.php?p=213714#p213714
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: FDS header date fields

Post by Pokun »

Thank you Loopy. I seem to have missed that thread.
ZReport
Posts: 21
Joined: Thu May 31, 2018 11:57 pm

Re: FDS header date fields

Post by ZReport »

ccovell wrote: Fri Apr 02, 2021 4:17 pm OK, I've made a newer version of the Disk Lister that lets you read the disk the old way, or you can press START to put it into a deeper scanning mode, which will display more of the disk's header, as well as try to read and display all file headers on the disk.

http://chrismcovell.com/data/FDListNAM2021.zip

If the number of files in the header doesn't match the actual number of files found (more or less) then it'll print the two numbers beside each other. This can be an indicator that 1) there is a hidden file, 2) the physical surface of the disk has some errors or dying data, 3) your drive belt is wearing out, or... 4) maybe my program has some bugs in it. (My prog should be safe, but caveat emptor.)

Hidden files will also be indicated by a red square in the file list.
Image
Even better! This is pretty awesome for a tool now. When it comes to the disk listing for the "Written" label it only captures the initial writing date, correct? Like say if I wrote a Doki Doki Panic using FDSStick it would have a written label that's from 1987 instead of 2021, yes?
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: FDS header date fields

Post by ccovell »

ZReport wrote: Sun Apr 04, 2021 1:10 pmEven better! This is pretty awesome for a tool now. When it comes to the disk listing for the "Written" label it only captures the initial writing date, correct? Like say if I wrote a Doki Doki Panic using FDSStick it would have a written label that's from 1987 instead of 2021, yes?
Yes, FDSStick doesn't mess with FDS disk headers of games, which get written in the factory or on DiskWriter kiosks.
ZReport
Posts: 21
Joined: Thu May 31, 2018 11:57 pm

Re: FDS header date fields

Post by ZReport »

ccovell wrote: Sun Apr 04, 2021 5:27 pm
ZReport wrote: Sun Apr 04, 2021 1:10 pmEven better! This is pretty awesome for a tool now. When it comes to the disk listing for the "Written" label it only captures the initial writing date, correct? Like say if I wrote a Doki Doki Panic using FDSStick it would have a written label that's from 1987 instead of 2021, yes?
Yes, FDSStick doesn't mess with FDS disk headers of games, which get written in the factory or on DiskWriter kiosks.
I see! What about the CopyRight date? Should that number be consistent amongst different revisions of the same game? If not what could that mean? From there, I assume that the "Written" date can be overwritten and changed if it was taken to a local kiosk as well, yes? Assuming the kiosk itself must have had an internal clock of some kind.

And finally, what of the the disks that have completely blanked out dates?
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: FDS header date fields

Post by ccovell »

ZReport wrote: Wed Apr 07, 2021 9:50 amI see! What about the CopyRight date? Should that number be consistent amongst different revisions of the same game? If not what could that mean? From there, I assume that the "Written" date can be overwritten and changed if it was taken to a local kiosk as well, yes? Assuming the kiosk itself must have had an internal clock of some kind.

And finally, what of the the disks that have completely blanked out dates?
Your guess is as good as mine for all the above. Different versions of games, for example, Zelda, have different copyright/manufactured dates. Rewritten dates would probably be set by the machines in Nintendo's factories, or by the Disk Writer kiosks' running clocks.

Plenty of games have invalid date codes -- they're supposed to be stored in BCD, so any hex bytes $a-$f renders them invalid, along with a date of all zeroes.

The header contains some bytes useful to FDS units, but a lot of them appear only to be used for version tracking. Plenty of them are not even filled in. For example, the prototype of Air Fortress on the FDS has some text filling up the FDS header!
see:

Code: Select all

52414D4400000000  RAMDQ.D.
000F512E442E2052   RAMDISK
414D4449534B2042   BY SGK 
592053474B203139  1986/10/20
38362F31302F3230
ZReport
Posts: 21
Joined: Thu May 31, 2018 11:57 pm

Re: FDS header date fields

Post by ZReport »

ccovell wrote: Wed Apr 07, 2021 8:56 pm
ZReport wrote: Wed Apr 07, 2021 9:50 amI see! What about the CopyRight date? Should that number be consistent amongst different revisions of the same game? If not what could that mean? From there, I assume that the "Written" date can be overwritten and changed if it was taken to a local kiosk as well, yes? Assuming the kiosk itself must have had an internal clock of some kind.

And finally, what of the the disks that have completely blanked out dates?
Your guess is as good as mine for all the above. Different versions of games, for example, Zelda, have different copyright/manufactured dates. Rewritten dates would probably be set by the machines in Nintendo's factories, or by the Disk Writer kiosks' running clocks.

Plenty of games have invalid date codes -- they're supposed to be stored in BCD, so any hex bytes $a-$f renders them invalid, along with a date of all zeroes.

The header contains some bytes useful to FDS units, but a lot of them appear only to be used for version tracking. Plenty of them are not even filled in. For example, the prototype of Air Fortress on the FDS has some text filling up the FDS header!
see:

Code: Select all

52414D4400000000  RAMDQ.D.
000F512E442E2052   RAMDISK
414D4449534B2042   BY SGK 
592053474B203139  1986/10/20
38362F31302F3230
Haha! That's pretty interesting. But also insanely nuts! I do believe I'll go out of my way and copy down some of these dates for you to take a look!
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: FDS header date fields

Post by ccovell »

Okay, I've had fun making some code to read some of the timings from FDS disks and display them.

http://chrismcovell.com/data/FDListNAM2021.zip

This version has a mode that will report/show the gap sizes at the start of the disk and between files (GAP numbers are not in any direct byte/msec format) and also attempt to run a speed test of the byte data coming in from the disk. It does this by counting the delay between bytes for the first 16 bytes of each file on the disk, and at an average of 1 byte every 147-150 CPU cycles that I get on my disk drive, that comes pretty close to the 12050 bytes/sec ideal data rate of the FDS disk drive.

Anyway, the visual gap / disk layout display is interesting... You can see differences between officially-written disks, home-written disks, and the FDSStick, etc.
Let me know if you find any errors or problems with this version.

Image
ZReport
Posts: 21
Joined: Thu May 31, 2018 11:57 pm

Re: FDS header date fields

Post by ZReport »

ccovell wrote: Thu Apr 15, 2021 7:38 am Okay, I've had fun making some code to read some of the timings from FDS disks and display them.

http://chrismcovell.com/data/FDListNAM2021.zip

This version has a mode that will report/show the gap sizes at the start of the disk and between files (GAP numbers are not in any direct byte/msec format) and also attempt to run a speed test of the byte data coming in from the disk. It does this by counting the delay between bytes for the first 16 bytes of each file on the disk, and at an average of 1 byte every 147-150 CPU cycles that I get on my disk drive, that comes pretty close to the 12050 bytes/sec ideal data rate of the FDS disk drive.

Anyway, the visual gap / disk layout display is interesting... You can see differences between officially-written disks, home-written disks, and the FDSStick, etc.
Let me know if you find any errors or problems with this version.

Image
HAHA! So many revisions! This one is a cool change. Is there something to look for as far as the disk data? Like could I see a bad disk or one that has been demagnetized?

At least, you're giving me reason to save some of these errored out trash games. :shock:

Image
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: FDS header date fields

Post by ccovell »

ZReport wrote: Mon Apr 19, 2021 10:05 pm HAHA! So many revisions! This one is a cool change. Is there something to look for as far as the disk data? Like could I see a bad disk or one that has been demagnetized?
Hmmm... only partially. If there's no disk header at the start, my program will error out, so corrupted disks like this will not be read. 1-sided disks actually have a blank disk header and 0-file counter on the "blank" side, so that can be read and shown.

I did actually attempt a raw-read version of my program that would constantly read $4031 for any and all data, but it didn't consistently get anything that could be interpreted. But perhaps having a raw disk scan display something graphically would be interesting...
Post Reply