Problem with tap2dsk
Posted: Tue Jun 08, 2010 7:00 pm
Hi all. When adding the 8th mission to 1337 I strumble upon another issue with OSDK. This time with tap2dsk.
The thing is that the data file (which is accessed on a sector basis with all the data to load in overlay as well as mission code) was corrupt in the last mission.
A closer look revealed a bunch of 0s in between the text strings. I examined the process of creating the dsk file up to tap2dsk. I downloaded the sources for this tool and tried to have a look.
The first thing I noticed is that it needs a sedoric3.h file, which is not included, so I had to guess its content (an byte dump of the os, I pressume).
Then I changed all the int defitions to long, as I supposed the problem was there, with no good result.
In the end, the problematic code was here:
Okay, so it seems that for Sedoric, there is a bug needing a free sector filled with zeros, each time we fill up one descriptor, but that is not the case for data files accessed sector by sector.
No idea why, or what this means, as my knowledge about Sedoric is very limited (nearly inexistant).
I am not sure how to deal with this, without heavy modification of the program (and adding options in the command line to avoid or include this trick on a file basis), so I just added a flag, so it avoids the trick in my case for the data file.
It works, but also means that my tap2dsk is specific for building 1337
Not sure how to proceed: maybe Dbug should add this for the next release, if necessary, or maybe contact Fabrice so he fixes it... maybe with more knowledge I could try to fix it... don't know.
Just thought it would be a good idea to have this written down somewhere.
The thing is that the data file (which is accessed on a sector basis with all the data to load in overlay as well as mission code) was corrupt in the last mission.
A closer look revealed a bunch of 0s in between the text strings. I examined the process of creating the dsk file up to tap2dsk. I downloaded the sources for this tool and tried to have a look.
The first thing I noticed is that it needs a sedoric3.h file, which is not included, so I had to guess its content (an byte dump of the os, I pressume).
Then I changed all the int defitions to long, as I supposed the problem was there, with no good result.
In the end, the problematic code was here:
Code: Select all
while (sectors--) {
find_free_sector(buf);
buf+=sizeof(sector);
descriptor[desc_off++]=track;
descriptor[desc_off++]=sect;
if (desc_off==0x100) { // Sedoric bug work-around : allocate a second descriptor when the first is full, even if not needed
find_free_sector(descriptor);
descriptor[0]=track;
descriptor[1]=sect;
update_sector(desc_track,desc_sect,descriptor);
memset(descriptor,0,sizeof(sector));
desc_track=track;
desc_sect=sect;
desc_off=2;
}
}
update_sector(desc_track,desc_sect,descriptor);
No idea why, or what this means, as my knowledge about Sedoric is very limited (nearly inexistant).
I am not sure how to deal with this, without heavy modification of the program (and adding options in the command line to avoid or include this trick on a file basis), so I just added a flag, so it avoids the trick in my case for the data file.
It works, but also means that my tap2dsk is specific for building 1337
Not sure how to proceed: maybe Dbug should add this for the next release, if necessary, or maybe contact Fabrice so he fixes it... maybe with more knowledge I could try to fix it... don't know.
Just thought it would be a good idea to have this written down somewhere.