It is currently Wed Dec 13, 2017 5:40 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Tue May 09, 2017 12:55 am 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 298
Location: Hong Kong
Maybe I misunderstand something, but I'm curious(I haven't really downloaded the project files so correct me if this has already been addressed):

1. Since during boot, the system will load file #1, #2, etc., until the number of files as depicted in offset #25 of Block 1, does the drive stops immediately after this file is read? Having the file count at least 1 higher than the number of boot files does this mean that offset #25 also has to be higher than the real number of boot files? Or just set offset 25 to the actual number of files loaded and the drive will continue spinning regardless, as long as the 2nd byte of Block 2 is set to a too-high number?

2. Setting the number of files higher than the actual number to be loaded at boot may cause problem with games that require to load more files in-game. Normally, say for example, if there are 5 actual files on a side of the disk, and files #1 thru #3 are to be loaded during boot, whereas #4 and #5 are to be loaded at some point while playing a game, should we just set the total number of files to 6 and the drive will continue spinning after #3 is loaded during boot? Or it will just stop spinning when it hits file #4, which may not give enough time for the NMI to fire? In this case it could be complicated to have a boot side that supposes to be able to load more data while playing the game. I have a silly idea though, and I don't even know whether this works or not, which is to, instead of placing files #4 and #5 after the boot files, place them before files #1 to #3 and then load all the files in the side during boot, presumably contents of files #4 and #5 loaded earlier into RAM will be overwritten by the contents of #1 to #3.

I may try to hack my old test project to see whether this works, but I am not able to atm and that I have no means to test on the real system.


Top
 Profile  
 
PostPosted: Tue May 09, 2017 1:09 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5896
Location: Canada
As I understand it, files are loaded by ID, rather than their number. When it goes looking for a file, it will check the header of every file until it either finds one with the correct ID, or the file count is reached.

The boot loader is sort of an exception because it is searching for every file with an ID lower than the boot ID value, so it is required to check the header of every file on the disk. Having extra files past the [$90] -> $2000 bypass file should also be good enough to cause a delay long enough for an NMI to occur as well, so I don't think you necessarily have to have an invalid file count to pull this off, you just need a sufficient delay. (Your NMI will bring an end to the disk search though, so it doesn't actually end up going to the end of the disk.)

I think the negative consequences are:
  • A search for a nonexistent file will take longer to return with error, because it will search the entire disk rather than stopping after the last file.
  • When copying the disk you should must zero out the entire disk past the last file. This means copying the disk will take longer, since you have to write the whole surface.

Maybe the repeating bytes idea is good too, just you will need more than 256 bytes on the PowerPak. (Not sure how long a file would make it robust, would probably have to count the cycles by hand.)


I could be wrong about any of this, though, I haven't done any thorough testing of these behaviours.


Last edited by rainwarrior on Tue May 09, 2017 1:24 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Tue May 09, 2017 1:22 am 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 298
Location: Hong Kong
Yeah. I reread the wiki, and I think I understand it now, though the wording of the wiki is still confusing, and may need some revision.

In offset 25 of Block 1:
Quote:
Boot read file code
Refers to the file code/file number to load upon boot/start-up

It's referred to "file code" or "file number".
And the 3rd byte of Block 3 (i.e. header of a file) reads "file identification code" (or simply "file ID").
Which should be the same thing, but the difference in naming makes it very confusing, especially the "file number" part in Block 1, will make anyone mistaken it to be the physically file number instead of the ID.

Now I looked at the source of my test project and I indeed got it wrong, as the game loads 3 files at boot(and it does not contain any other files) I put the value 3 at offset 25 of Block 1. In fact I assigned ID #1 to all the files, so it sufficed to put just the value 1 at offset 25. It just worked without problems, for obvious reasons though. (Also, it's been a while since I touched that project, and I now see from the wiki that the purposes of many more bytes in various blocks are now more or less known, compared to what we knew back then).


Top
 Profile  
 
PostPosted: Tue May 09, 2017 1:25 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5896
Location: Canada
Gilbert wrote:
Yeah. I reread the wiki, and I think I understand it now, though the wording of the wiki is still confusing, and may need some revision.

It is definitely confusing and needs an overhaul.

Also:

Gilbert wrote:
I may try to hack my old test project to see whether this works, but I am not able to atm and that I have no means to test on the real system.

Emulators seem to be good enough for testing this stuff. FCEUX and Nintendulator and Nestopia all failed/passed the same tests as my FDSStick + FDS did. PowerPak is the one outlier because it has its own modified BIOS.


Top
 Profile  
 
PostPosted: Tue May 09, 2017 1:36 am 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 298
Location: Hong Kong
rainwarrior wrote:
Emulators seem to be good enough for testing this stuff. FCEUX and Nintendulator and Nestopia all failed/passed the same tests as my FDSStick + FDS did. PowerPak is the one outlier because it has its own modified BIOS.

By testing I originally meant to have a game able to both bypass the license screen and load data in game though, which is pretty much irrelevant after the file number/ID confusion is cleared up. Maybe it's still worth testing though, in case there are some other unknown pitfalls this method may cause.

That also makes me think, as long as there are some files(e.g. data files to be loaded in game, or just some other large enough dummy file) in the disk after the last boot file(i.e. the one to make the NMI fire) I think we no longer need to make the total file count higher than the actual number, right?


Top
 Profile  
 
PostPosted: Tue May 09, 2017 1:40 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5896
Location: Canada
Gilbert wrote:
That also makes me think, as long as there are some files(e.g. data files to be loaded in game, or just some other large enough dummy file) in the disk after the last boot file(i.e. the one to make the NMI fire) I think we no longer need to make the total file count higher than the actual number, right?

Yes I think this is true.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: LocalH and 9 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