Space Harrier 2 - Grandslam

Page 8/9
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9

By araubi

Champion (431)

araubi's picture

29-05-2020, 13:52

nataliapc wrote:
araubi wrote:

Well... I use TAPE2CAS and the fork of OpenMSX: OPENMSX_TSX. This way, I don't need to convert from TSX to WAV. Conversion takes a few seconds by pressing F9.

There is available the TAPE2CAS source code?
It could be very easy to create a TSX2CAS using the same patching process...
The best of this is that we could ensure that the input data is reliable.

https://www.msx.org/es/downloads/utilities/tape/tape2cas

Source included.

By nataliapc

Expert (88)

nataliapc's picture

29-05-2020, 15:35

Manuel wrote:

It's a limitation of the CAS format. For standard blocks, I guess it is indeed possible to directly copy a large part of the data into the CAS file. Correct, nataliapc?

For standard blocks not only a large amount of data... but all the data.

Is the reverse way of:
https://github.com/nataliapc/MSX_devs/blob/master/TSXphpclas...

If the TSX have not standard blocks we need to patch the custom loader, but the data blocks will be copied as is to the CAS, even the not standard.

By sdsnatcher73

Paladin (952)

sdsnatcher73's picture

29-05-2020, 15:40

I like this new energy and vibe Wink clearly a more open mind to this situation now. I applaud you all!

By Manuel

Ascended (16643)

Manuel's picture

29-05-2020, 20:04

How does it work with TSX/TZX regarding the clock? I read something about 1/3500000 seconds, but the T-states on MSX are a different time. Can you explain, nataliapc?

By nataliapc

Expert (88)

nataliapc's picture

29-05-2020, 21:18

Manuel wrote:

How does it work with TSX/TZX regarding the clock? I read something about 1/3500000 seconds, but the T-states on MSX are a different time. Can you explain, nataliapc?

It is just a unit of measure convention.
After all, the pulse times generated, even if using the Spectrum frequency, are adjusted to the MSX standard pulse lengths.

For 1200 bauds:
bit 0: two pulses of 1458 spectrum tstates
bit 1: four pulses of 729 spectrum tstates

By nataliapc

Expert (88)

nataliapc's picture

29-05-2020, 21:17

pgimeno wrote:

Thanks, I didn't have openMSX in mind, but real MSX. Phone apps are of no value to me. But a wav converter lets me feed the MSX cassette line with my PC.

tsx2wav.php are uploaded.
https://github.com/nataliapc/MSX_devs/tree/master/TSXphpclass

Please create an issue at github if you find any bug.

By Manuel

Ascended (16643)

Manuel's picture

29-05-2020, 21:32

Another thing I was thinking about. We talked about making 'canonical' cassette images (two different tapes with the same game giving the exact same data). When doing this right now, it will give slight variation and thus different cassette images.
But in the end, the MSX will read the same data from the two different (original) tapes. In other words: exactly the same data will be loaded.

Is the difference only a small variation in the baud rate (between tapes and inside a single tape)? If yes, wouldn't it make sense to "quantize" the baud rate a bit, so that both images would become the same?

So, the point is to eliminate the variations between tapes that have no influence on the final result on the MSX.

Some points regarding this quantizing and the variations:
- the speed of the cassetteplayer will vary. But there is a bandwidth in which the same data will be loaded in the MSX eventually, there is a tolerance that the BIOS or the proprietary loader has to handle these variations.
- the exact timing of pulses will vary a bit (e.g. not 100% steady tape speed). But the BIOS or loader of the MSX program has some tolerance on that as well.

I suppose these tolerances are smaller when higher baudrates or fast proprietary loaders are used.

So, would it make sense to take these tolerances into account to come to a way to eliminate the small variations to create exactly the same file for the 2 different tapes with the same data on it?

I hope it's clear what I'm trying to discuss Smile

By nataliapc

Expert (88)

nataliapc's picture

29-05-2020, 22:25

Manuel wrote:

Another thing I was thinking about. We talked about making 'canonical' cassette images (two different tapes with the same game giving the exact same data). When doing this right now, it will give slight variation and thus different cassette images.
But in the end, the MSX will read the same data from the two different (original) tapes. In other words: exactly the same data will be loaded.

Is the difference only a small variation in the baud rate (between tapes and inside a single tape)? If yes, wouldn't it make sense to "quantize" the baud rate a bit, so that both images would become the same?

Is hard to know which is the "valid one" having two TSX of the same game. The variations could be:
- Baudrate (pulse timings)
- Silence pause lengths
Anyway the differences are very small for same game copies.

The correct timing values could be easy to known when the baudrate is near 1200 or 2400 bauds, but... there are games with MSX standar blocks at around 1600 and other bauds too...
So, we decided maintain the timings of the first copy translated to TSX in order to keep our main preservation purpose: original distribution timings are information too.

Devices like TZXDuino (TZXDuino soft), TSXDuino (MaxDuino soft) can override the original #4B blocks headers and create on the fly new custom headers to obtain 2400, 3200, or even 3850 bauds that can be read from a real machine.

About the way to check if two TSX are the same we are using the DATA HASH concept instead of the FILE HASH.
We concatenate the DATA bytes of all the DATA blocks (id: 10, 11, 12, 13, 15, 4B) and generate a hash with them. This way we can have a valid HASH without the Baudrate and Silence pause lengths variations.

Was this what you were asking about?

By Manuel

Ascended (16643)

Manuel's picture

29-05-2020, 22:38

Thanks!

Yeah, basing a kind of hash on the really relevant data is a way to go. It will directly compare the data that would get into the MSX. But does that work for custom proprietary loaders with their own encoding as well? (For which you can only store pulse information, right? And for instance, there could be variation in the pulse timing due to varations in tape speed during recording or playing.)

My point is that the differences between two copies are expected (due to the nature of the tape medium) and both copies would be equally valid. So, knowing what the tolerances are, a tool could be made to compare two of these dumps and if the differences are only in things that are not relevant (loaded data content would be the same), then it's clear that they are equivalent. And yes, then I think it's probably best to prefer the one with a baudrate that is closest to standard (at least for the first block). But I expect that the variations are really really small, is that correct?

By nataliapc

Expert (88)

nataliapc's picture

29-05-2020, 23:21

Manuel wrote:

Yeah, basing a kind of hash on the really relevant data is a way to go. It will directly compare the data that would get into the MSX. But does that work for custom proprietary loaders with their own encoding as well? (For which you can only store pulse information, right? And for instance, there could be variation in the pulse timing due to varations in tape speed during recording or playing.)

Custom loaders generally are reading Spectrum blocks to avoid a standard way to read them using BIOS calls.

Other custom loaders are variations of MSX standard blocks: OperaSoft sometime uses a standard block with a custom pilot, games like Elite (Firebird) uses 3 stop bits in each byte instead of the standard that is 2.

And other tape systems like OTLA, RedPoint,... are very complicated and we generally use #15 blocks with them. At least until we discover the internal bits/bytes format.

All the above kind of blocks are suceptible to have a DATA HASH, but #13 and #15 are the blocks with the most variation due to their nature. They are also the least commons.

Manuel wrote:

...And yes, then I think it's probably best to prefer the one with a baudrate that is closest to standard (at least for the first block). But I expect that the variations are really really small, is that correct?

Yes, variations are very small, don't worry.

Page 8/9
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9