Moderators: Mug UK, ijor, Moderator Team
DrCoolZic wrote:I have been testing more Pasti file and I have found an interesting case not covered in the documentation.*
As you know the fuzzy record in the file can be "dispatched" to several sectors. For example you have one fuzzy record of 1024 bytes -> dispatched to two 512 bytes sector ...
I have found that the same can happen with Timing records.
DrCoolZic wrote:Theme Park Mystery Track 02.0 02.1
But I do not understand why not Track 00.0 -> 04.0 & 00.1 -> 04.1
all track looks the same they have a no flux area at the end and adding timing info in NFA has no meaning ?????
IFW wrote:DrCoolZic wrote:Theme Park Mystery Track 02.0 02.1
But I do not understand why not Track 00.0 -> 04.0 & 00.1 -> 04.1
all track looks the same they have a no flux area at the end and adding timing info in NFA has no meaning ?????
You may want check that it actually works... Many games using NFA have non-trivial protections, that pass even if the protection fails, but the game e.g. becomes unplayable, like Theme Park Mystery does. In this case, no matter what you do, you won't be able to get on the train between the game zones.
DrCoolZic wrote:I found another strange thing for track with one "data sector" like Maupiti Island
Here we have a track descriptor that have TrackFlag=0x61 => Track data with only track image size (versus flag 0xE1 sync off + track size).
- First of all I am surprise to see 0x61 because this Pasti latest version 3.2 and I would have expected 0xE1 that provides more information ??? Therefore I do not understand when/why 0x61 versus 0xE1 ???
- But the problem is that when I add up all the fields as described in the doc I am ONE BYTE SHORT to where next track descriptor point ??? If I look at the data with an hex editor it seems that indeed the first two bytes in the Track Data records is the track lenght but I have an orphan byte at the end. I cant find why? is it to be on an even boundary ??? ....
I am investigating and will let you know..
AtariZoll wrote:Pasti images are made on Atari, so no wonder if track data must be on even boundary. Did you ever see track data starting on odd address ?
AtariZoll wrote:Btw. even DMA chip works always with even base address, because it accessing RAM 16-bit wise. If you give odd base address, bit 0 is ignored (just don't try this in Steem, as is not correct emulated) .
npomarede wrote:Hello
looking at the different structures, I wonder how we can compute easily the start of the Timing Record (for variable bit rate sectors in revision 2) ?
Timing Record is after the Track Data ; Track Data's start is easy to compute, Optional Sectors Image is also easy to compute.
From there, Timing Record can be seen as :
- either after the last sector in the Optional Sectors Image block, but we don't know directly how many sectors are stored there, nor their size
- either after the Track Data block, but here also we don't know the size of this Track Data block
I can think of a way by looking at all the sectors' DataOffset to compute the max position in the TrackData for all the sectors ; adding the size of the corresponding sector to this max position would give the end of the TrackData block.
Do we really need to scan all the sectors of a track to compute the start of the Timing Record, or is there a more straightforward way to do it ?
Nicolas
DrCoolZic wrote:npomarede wrote:Hello
looking at the different structures, I wonder how we can compute easily the start of the Timing Record (for variable bit rate sectors in revision 2) ?
Timing Record is after the Track Data ; Track Data's start is easy to compute, Optional Sectors Image is also easy to compute.
From there, Timing Record can be seen as :
- either after the last sector in the Optional Sectors Image block, but we don't know directly how many sectors are stored there, nor their size
- either after the Track Data block, but here also we don't know the size of this Track Data block
I can think of a way by looking at all the sectors' DataOffset to compute the max position in the TrackData for all the sectors ; adding the size of the corresponding sector to this max position would give the end of the TrackData block.
Do we really need to scan all the sectors of a track to compute the start of the Timing Record, or is there a more straightforward way to do it ?
Nicolas
I have asked myself the same questions and I have not found an easy way to compute the start of the timing data. What I am doing is to store the maximum value for the offset while reading the track data and the sector data. You cant just take the last offset value. I have run in some cases where the last sector was inside the track data for optimization!
If you really want to compute before reading the data I guess it is possible: you have the offset in the sector descriptor from track data start, and you have the size given in sector size of the address field (128 << size). So I guess you can scan all the sector descriptors and compute the max value from there
Users browsing this forum: No registered users and 3 guests