Page 1 of 2

Problem with tap2dsk

Posted: Tue Jun 08, 2010 7:00 pm
by Chema
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:

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);
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.

Posted: Tue Jun 08, 2010 8:03 pm
by Dbug
Hum, I wonder if instead of allocating the new descriptor with "find_free_sector" it was trying to allocate it at the end of the disk, perhaps this would work.

Or perhaps the tool could be modified to count first the number of descriptors it will need, and make sure they are allocated at the beginning of the disk layout?

I believe Fabrice or Symoon are the persons who know the most about that.

Posted: Wed Jun 09, 2010 10:10 am
by Chema
You are right Dbug.

Anyway I realize that this is not a fault in tap2dsk, but in the way I read data files sector by sector.

Strange there is a known bug in sedoric3 which has not been fixed, anyway.

Posted: Wed Jun 09, 2010 7:06 pm
by Symoon
Fabrice is the one to ask! I'm no expert of this part of Sedoric. I took a look at Sedoric à Nu and didn't see any mention of a bug in this part of the code. Maybe Fabrice is referring to a bug in another part of Sedoric, affected by this, or maybe he saw something André didn't see when writing Sedoric à Nu.

BTW Chema, your file must be quite big! :)

Posted: Wed Jun 09, 2010 7:43 pm
by Chema
Symoon wrote: BTW Chema, your file must be quite big! :)
Yep. The file with data that is to go in overlay+savegame slots+mission code is currently 31794 bytes :)

Anyway I will think about contacting Fabrice and clarify this point.

Posted: Wed Jun 09, 2010 7:52 pm
by Symoon
If you have a question about how to read the sectors, maybe I can help with Sedoric à Nu, but sure if you need an explanation about the "bug comments" in the program, this is for Fabrice ;-)

Posted: Wed Jun 09, 2010 8:24 pm
by ibisum
I am looking at tap2dsk right now, and wondering if you guys have sedoric3.h laying around anywhere .. ?

Posted: Wed Jun 09, 2010 8:41 pm
by Symoon
Forgive my poor knowledge in C but I don't see any include of a sedoric.h file in the source code ? (tap2dsk.c, 6308 bytes)

EDIT: ok I was looking at an old version, the V1 probably since the latest is labelled V2.

Posted: Wed Jun 09, 2010 10:01 pm
by Chema
There is an #include "sedoric3.h" indeed inside a byte array definition. I didn't have it either, so I had to figure it out...

It seems it is a bytedump of the os, so I stripped it from the executable or a sedoric disk (or checked both, I don't remember), run bin2txt and created it by hand.

It works, it seems, but I am not sure if it is buggy...

I can send it to you by email, if you wish. Anyway it would be better to grab the original, which I could not find in any of the sources.

Posted: Thu Jun 10, 2010 8:56 am
by ibisum
If you could send it to me, that would be very useful - I don't really want to get into a lot of hacking of tap2dsk right now, I just want to use it under Linux to convert some TAPs to DSK files for use in PandOricutron ..

Maybe you could just PM it to me, or send it to me by email - my email address is my Defence Force ID + gmail . com ..

Re: Problem with tap2dsk

Posted: Wed May 07, 2014 9:17 pm
by Hialmar
Sorry to bring up this very old thread but I'm trying to modify tap2dsk and had the problem with the sedoric3.h file.

I searched and found this message.

I also found Fabrice's sourceforge project including tap2dsk here:
http://sourceforge.net/projects/euphori ... ic%20tool/

Why are we not using his last version of the tool ?

Is the modification Chema talked about included in our version of tap2dsk ?
Should I include it in my new version ?

What I am modifying is the following:
- to avoid the nonameXXX.com in the dsk image I'm taking the name of the .tap file instead ;
- then I will make two options to give a paper and ink color to the title.

Re: Problem with tap2dsk

Posted: Wed May 07, 2014 9:46 pm
by Dbug
Hialmar wrote:Why are we not using his last version of the tool ?
The version in the OSDK is the one that was released from Fabrice's old site, since I don't use it I never updated it.
That's as simple as that.

Now, there are two possibilities:
- I stop using the version I have on SVN and get the version from SourceForge
- We update the SVN version with the updates from SourceForge

As the OSDK packager, the first version is more work for me, on the other hand it means that SourceForge is the main version.

(And a third possibility: I give Fabrice and you access to the SVN on Defence-Force and we keep all the files there.)

Re: Problem with tap2dsk

Posted: Wed May 07, 2014 9:52 pm
by Hialmar
I will talk with Fabrice about this and tell you what he thinks is best.

Thanks.

Re: Problem with tap2dsk

Posted: Thu May 08, 2014 9:07 am
by Hialmar
Ahem I just found that there is another tap2dsk in the osdk/main part of the SVN and this one is the 2.1.

I'll do my modifications on this one.

Dbug, if you want to give me an account to your svn I will be able to upload those modifications.

I'll also add an option to give a name to the tapes in tap2dsk (putting a default name instead of "" as well).

Re: Problem with tap2dsk

Posted: Thu May 08, 2014 11:30 am
by Chema
I think that the tap2cd version in SourceForge is not exactly the same I am using and which is on the OSDK repository (with sources).

Not sure how to organize all this, but it is a problem. Having different versions of the same tools with different behaviour, options, etc. could rapidly become a mess and a nightmare to maintain...

I'd go for having a kind of mirror here in defence-force, even if in a particular OSDK distro some tools are outdated. But I understand this has two drawbacks:
- More work for Dbug, and he's already doing too much...
- Will make the transition towards integrated tools (such as TapTool) more difficult.