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
![Sad :(](./images/smilies/icon_sad.gif)
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.