TSX support in OpenMSX.

Page 5/6
1 | 2 | 3 | 4 | | 6

By Tolvatar

Paladin (996)

Tolvatar's picture

20-09-2021, 10:03

Grauw wrote:

So I think that while TZX has a lot of value attached to it in the Spectrum community, this enthusiasm did not automatically carry over to the MSX community. Which is why the reception is lukewarm and the format is looked at critically, and not adopted as a heaven-sent that we must have no matter what.

The TZX was great for the Spectrum community. And for the Amstrad, and for the Commodore 64....

And my question is, why not support this format?
I'm not going to delete muy cas files but i see some advantages from the tsx format.

Openmsx support different formats for Disk images, right? Why not for tapes?

The tsx format is well defined, useful and with all info available. Have many dumps and manteined by some people.

By bore

Master (133)

bore's picture

20-09-2021, 10:11

pgimeno wrote:

Just for fun, I generated an IPS that applies to the conversion of the TSX to WAV. It's 326,732 bytes, compared to the 20 bytes that the above IPS takes.

How did you manage that?
Even if we disregard the IPS overhead an 8-bit @ 4800Hz WAV should only grow with 4 bytes per bit, it comes down to 640 bytes.
Where does the other 300k come from?

By araubi

Champion (432)

araubi's picture

20-09-2021, 10:25

Marty McFly wants to take the DeLorean and go away. The moment someone qualifies the opponent's arguments as merely emotional, this ceases to make sense. It is disrespectful to ignore the arguments in that way.

By ducasp

Champion (460)

ducasp's picture

20-09-2021, 17:25

bore wrote:
ducasp wrote:

TSX is not a faithful copy of the analog audio, but, a faithful copy of the master that created the audio that went into tape, for preservation purposes, that is second only to the original digital memory dump Cool

Unless I have missed some features of TSX that just doesn't make sense.
To be sure that you have a clean recording you will then need to obtain a real master binary from the content creator.
If you have clean data to begin with either format works fine, you can just set a samplerate of 4800 and generate a square wave at full amplitude.

The problem is when you don't have the original binary, just a tape or a recording of it.
From what I have seen you can't convert it to TSX without starting to make decisions of what the bits actually are.
Either way you are removing all the information that could be used to verify that the conversion was correct.
That is absolutely terrible from a data preservation standpoint!

So unless TSX have some way to store the analog format it seems to me that it is best for data that has never touched a tape to begin with.
There may be arguments to use TSX, but unless I have completely misunderstood what the format does, data preservation isn't a reason to use it.

I agree that my (lack of) explanation did not help, but imulilla gave a great explanation on why I think it is a good preservation of what would be the original digital master. Anyway, I think we all agree, TSX doesn't ultimately replace entirely anything and anything will replace TSX entirely as well... There are advantages to it (i.e.: same software, you can have a single hash even if created from different sources, as long as both were created from proper source, smaller source, can be converted back to a WAV that is good enough to be recognize by any system), there are disadvantages... And ultimately, I disagree (now, not with you, just talking about the general sense of the this conversation) that the ultimate advantage of having it integrated would be to stop getting people asking for it... There are good cases for its use, and while I ultimately am on the fence because I understand the OpenMSX team decision so far was not based on prejudice or thinking of not supporting because some childsh reason, but due to complex code, lots of line, they have limited resources and you have your team goals and means to work, to have something like this properly inserted it is not as simple as just merging what is working on a happy day scenario, you have to think about all unlikely scenarios, protect from those and so on. It would be cool to have it, but it is understandable to not have it officially now. Just hope this happens sometime. Smile

By santiontanon

Paragon (1481)

santiontanon's picture

20-09-2021, 17:50

I wonder if there is some middle ground that can be reached. What I see here is two groups of people:
A:the maintainers/developers of openMSX) and
B: the developers of TSX,
Both of them who are doing great work and care deeply about their creations. I understand that incorporating TSX into openMSX would be an increase of workload for A (who are doing this for free on their spare time). But it's also sad that there is a community of people that are excited about some new project (TSX) and are putting a lot of work on it (also for free on their spare time). I see that there is clearly some supporters of TSX, which means that some people would like this feature.

I have never looked at the openMSX source code in too much detail, but I wonder if there is any chance of an intermediate solution where TSX can be added as an extension, maybe via a TCL script or something like that. Basically, I wonder if there is a way in which the maintenance effort for the openMSX developers is reduced as much as possible, and TSX support just becomes an extension script that can be downloaded separately, like the openMSX debugger, or the launcher. Over time, if more and more people use it, it could be eventually bundled as part of the official release.

Again, I am not sure if this is possible. I'm just trying to think of ways in which both parties can be happy, since after all, this is a hobby and not work, and we do this because we have fun with it. So, it should bring us joy, and not dissent Smile

By wouter_

Champion (467)

wouter_'s picture

20-09-2021, 18:18

ducasp wrote:

... same software, you can have a single hash even if created from different sources, as long as both were created from proper source ...

I understand what you're saying. But I have to disagree on this small part of your full message.

Unfortunately when two people make a recording of the same cassette game. And then both convert their recording to TSX, there's a reasonable chance that both TSX files won't be 100% identical. Even if both TSX files work perfectly fine. In other words: there's no one true canonical TSX representation per game.

There can be multiple reasons for this:

  • TSX is complex enough to have multiple valid representations for the same data. So multiple versions of the TSX creator tool may make different (all valid) encoding decisions.
  • TSX can encode the (average) timing of the pulses. Two different recordings may have slightly different timings. Because the timing info is encoded very accurately (in Z80 cycles), even small differences can result in a different TSX file. As a workaround the TSX creator tool could ignore the actual timing and just encode standard (ideal) MSX timing.
  • Between data blocks there usually is a period of silence. The length of this period is also encoded in the TSX file. But between recording the exact duration can (slightly) vary. Here it's not so easy to pick a 'standard' timing for silence (because e.g. if you pick a too low value, the MSX may not be ready yet to accept the next data block). A workaround could be to round up to the nearest 1/100s or 1/10s.
  • TSX can optionally encode the signal level (high or low). Though for many encodings the actual level isn't important, only transitions between high and low matter. Some TSX creation tools may choose to specify the starting level anyway, others may leave it out.
  • And then the obvious stuff like optionally encoding comments in the TSX file.

Many of the issues in this list can be worked around. For example not using comments and using the exact same version of the creation tool (with the same options) already helps a lot.

Anyway all this just to say that your statement "the same TSX-hash for the same software" is not always true.

By Tolvatar

Paladin (996)

Tolvatar's picture

20-09-2021, 21:41

wouter_ wrote:

Unfortunately when two people make a recording of the same cassette game. And then both convert their recording to TSX, there's a reasonable chance that both TSX files won't be 100% identical. Even if both TSX files work perfectly fine. In other words: there's no one true canonical TSX representation per game.

If the quality of the dump it's good the data will be the dame. TSX it's a container, please, check the CRC of the blocks, nor the CRC of the full file.
The same WAV give the same TSX, not like wav2cas

wouter_ wrote:

There can be multiple reasons for this:

  • TSX is complex enough to have multiple valid representations for the same data. So multiple versions of the TSX creator tool may make different (all valid) encoding decisions.

No. Same WAV give same data if the dump it's good. If you use the tool and give any warning then the file it's not verified to be a good dump and nota published

wouter_ wrote:
  • TSX can encode the (average) timing of the pulses. Two different recordings may have slightly different timings. Because the timing info is encoded very accurately (in Z80 cycles), even small differences can result in a different TSX file. As a workaround the TSX creator tool could ignore the actual timing and just encode standard (ideal) MSX timing.
  • No. The data if the MSX blocks will be the same

    wouter_ wrote:
  • Between data blocks there usually is a period of silence. The length of this period is also encoded in the TSX file. But between recording the exact duration can (slightly) vary. Here it's not so easy to pick a 'standard' timing for silence (because e.g. if you pick a too low value, the MSX may not be ready yet to accept the next data block). A workaround could be to round up to the nearest 1/100s or 1/10s.
  • I dont really understand this. Could be some miliseconds of diference between diferent ripped tapes. But the lenght it's the One present on the tape. And all my tape readers for my MSX on the last 30 years has REMOTE, so dont understand the problem

    wouter_ wrote:
  • TSX can optionally encode the signal level (high or low). Though for many encodings the actual level isn't important, only transitions between high and low matter. Some TSX creation tools may choose to specify the starting level anyway, others may leave it out.
  • Are you talking of the audio volume of the WAV recording? Then we can discuss on the quality of the tape readers, the wires and so on....but the data will be the same again if the quality it's good

    wouter_ wrote:
  • And then the obvious stuff like optionally encoding comments in the TSX file.
  • But, but, but... This is the best point for emulators and some users. This is info about the Game, the language, the protection if any, the command to load and whatever info you want about the game. And this is the problem?

    quote=wouter_]Many of the issues in this list can be worked around. For example not using comments and using the exact same version of the creation tool (with the same options) already helps a lot.

    Anyway all this just to say that your statement "the same TSX-hash for the same software" is not always true.

    Sorry, the TSX format it's not a CAS.

    I personally think that TSX format it's by far better than CAS and easy to hundle that WAV. But it's my opinion.
    You have yours. It's ok. No problem

    By imulilla

    Rookie (17)

    imulilla's picture

    20-09-2021, 22:36

    It is difficult to follow the thread, many things are said and I suppose that some of them will miss answering it, besides that maybe do it in a disorderly way. First of all, highlight what Santiontanon says, that this is a hobby, it is to enjoy it
    and it is done for free, which at the time it becomes an obligation or something annoying is not worth it.

    It has been commented that the implementation of the format can be a cumbersome task, but as I already mentioned the code is already done for version 16, and I hope that soon it will be for version 17, which would not be the same as doing it from scratch; want see the possibility of doing it using something based on the tcl "cashandler", maybe it's easier.

    The issue of fidelity to the original tape, I already said that the same tape could generate different WAVS, so I consider
    that trying to take those WAVS as MASTER is not real, the only MASTER would be if a WAV was generated by capturing directly the audio of the machine that has the program in memory, using a format such as tape we will only get approximations of the MASTER, the problem is not the destination format (TSX), but the source format, which does not offer a 1: 1 representation of the MASTER; regarding the level it is the same, it depends on the volume used in the capture, I think it is not possible to know the volume original.

    Regarding the equality between 2 TSX of the same game, if the edition is the same and the dump is correct, the blocks
    of data will be equal at the CRC level, the CRC of those blocks is what we call DATA HASH, which will be the same on the 2 TSX ; in the web of "tsx.eslamejor" you can see how editions in which the content of the tape is the same the DATA HASH coincides.

    By pgimeno

    Champion (300)

    pgimeno's picture

    21-09-2021, 23:27

    santiontanon wrote:

    I wonder if there is some middle ground that can be reached. What I see here is two groups of people:
    A:the maintainers/developers of openMSX) and
    B: the developers of TSX,
    Both of them who are doing great work and care deeply about their creations. I understand that incorporating TSX into openMSX would be an increase of workload for A (who are doing this for free on their spare time). But it's also sad that there is a community of people that are excited about some new project (TSX) and are putting a lot of work on it (also for free on their spare time). I see that there is clearly some supporters of TSX, which means that some people would like this feature.

    My recollection from reading the arguments against merging the pull request was that it boiled down to the patch not being of good enough quality; hence why my first post in this thread was asking if there was anyone willing to write a robust implementation. Personally I think that the increase in workload from maintaining a properly written patch would be negligible compared to the current complexity of the rest of the codebase.

    By pgimeno

    Champion (300)

    pgimeno's picture

    21-09-2021, 23:29

    bore wrote:
    pgimeno wrote:

    Why? It's just a search and replace, he knows how to do that with a text editor and he knows how to do that with a hex editor. They're not that different after all.

    Because in your example he started out with an original tape.

    That's not really relevant. If you want to patch Avenger for immunity, search for the sequence 3A F7 BD B7 C8 and change the C8 to C9; then search for the sequence 00 00 00 FF 28 and change the 28 to 29. It's not TSX-specific; it applies to the CAS version as well.

    bore wrote:

    To get to the point where he would want to apply a TSX specific patch he would have to record the tape (most likely to WAV) and then convert it to TSX. It already took a lot of effort for Marty to get to the point of having a patched TSX.
    At that point he has already passed all the hurdles that makes WAV so unfeasible.
    If hypothetical Marty manages to get that far, converting the TSX back to WAV after applying the patch is an insignificant step compared to the things he already went through.

    That's a fair point, but does Marty really have to store both his original and a patched WAV to invoke it every time he wants to play? Or convert it to TSX every time? That's an extra step that could be avoided.

    Page 5/6
    1 | 2 | 3 | 4 | | 6