Again SVI-3x8

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

By NYYRIKKI

Enlighted (4497)

NYYRIKKI's picture

12-03-2017, 00:03

Manuel wrote:

I put it up here: http://openmsx.org/temp/svi2dmk.exe

Remember, only works for 40 track disks (single or double sided).

I just tested with CP/M & BASIC disks and it seems to work fine. Thanks! This makes SVI emulation a lot more useful. Maybe some day someone will write even a program to insert/extract files to/from these images. :)

For those who like to test the CAS-file support... Please backup first your original _cashandler.tcl from openmsx/share/scripts replace it with this SVI-version and restart openMSX... Most easy way to run the cassette games is to open openMSX console and type "casrun path/filename.cas"

You can also type "set fast_cas_load_hack_enabled true" if you want to use Catapult instead of command line. Tip: You may also want to try "help casload"

Please note: This will disable fast loading hack from MSX machines, but I think this will be fixed rather soon... Stay tuned.

By NYYRIKKI

Enlighted (4497)

NYYRIKKI's picture

12-03-2017, 00:09

Manuel wrote:

The header is different (0x55.... 0x7F instead of 0x1F 0xA6 ... 0x74), but the rest of the file format seems to be the same. Am I correct here?

Yes, the format seems to be closer than I thought... Please note also that in SVI CAS-file the header is not adjusted to 8-byte boundary as on MSX.

Quote:

In other words: if I were to convert this to WAV internally (like is done for MSX CAS files) in openMSX, what do I have to change? I understand it is very much not the same as merely interpreting the contents of the CAS file, but perhaps you know about that too Smile

Unfortunately I don't know about that... I think that the encoding differences needs to be checked with some audio software.

By Manuel

Ascended (12995)

Manuel's picture

12-03-2017, 00:44

I already started to integrate your SVI CAS support into _cashandler without breaking MSX CAS files... I'm testing at the moment.

By NYYRIKKI

Enlighted (4497)

NYYRIKKI's picture

12-03-2017, 01:04

Manuel wrote:

I already started to integrate your SVI CAS support into _cashandler without breaking MSX CAS files... I'm testing at the moment.

Great. I'm really not at home at all with TCL... Really frustrating when you try to get something done and it feels the language is trying to kill you. Smile

I took a quick look at the wave forms and the timing it self looks identical... How ever there are differences in how the data is encoded... MSX carrier wave is all just short pulses, but in SVI it seems that it is repeating "long, short, short, long" sequence... It seems also that the actual data is encoded in different way... I think asking from ie. Johan Winge might be a good idea here... He posted latest version of SVI tools to Facebook 10/2016 so there is good change he might still remember the details.

By Manuel

Ascended (12995)

Manuel's picture

12-03-2017, 01:08

If you feel like it: please ask him. Then we could have 'native' SVI CAS file support in openMSX.

By NYYRIKKI

Enlighted (4497)

NYYRIKKI's picture

12-03-2017, 01:13

It seems that the source is available here: https://sourceforge.net/projects/svitools/

By NYYRIKKI

Enlighted (4497)

NYYRIKKI's picture

12-03-2017, 01:58

Manuel wrote:

If you feel like it: please ask him. Then we could have 'native' SVI CAS file support in openMSX.

After thinking for a while, I think that I'll pass this opportunity...

When I think about it, this what you call 'native support' has not been among the brightest ideas that openMSX team has come up with... No hard feelings, but adding more useless conversion layers still don't make things any better, only more complicated without benefit. I don't think replicating this again with SVI is really a good idea, so I select only to wish you good luck with it.

(That Red Zone video that I posted earlier is a perfect example of why you should not do this. If you load it as WAV it works fine. If you convert it to CAS, it will work fine, but if you after that load it with 'native support' it will fail.)

By NYYRIKKI

Enlighted (4497)

NYYRIKKI's picture

12-03-2017, 10:06

Ha! I found the command "utils::get_machine_display_name", so here is SVI-3x8 updated version of _type_via_keybuf.tcl

By Manuel

Ascended (12995)

Manuel's picture

12-03-2017, 10:13

With that native support I mean that you don't have to convert the CAS file manually outside of openMSX... So it's a convenience feature. Of course this only works if the file is indeed convertible to WAV...

I will add a way to reliably detect in Tcl what machine type is running. After all, it is explicitly present in the machine config XML file.

By NYYRIKKI

Enlighted (4497)

NYYRIKKI's picture

12-03-2017, 14:28

Yet another command converted for SVI usage called "listing"... I also added handling of single precision and double precision number support as lack of those caused the script to fail decoding of rest of the source.

Manuel wrote:

With that native support I mean that you don't have to convert the CAS file manually outside of openMSX... So it's a convenience feature. Of course this only works if the file is indeed convertible to WAV...

"convenience feature", oh man, come on! This is just you guys being stubborn with your principles. If you stitch that TCL script up we have a method to directly load all CAS-files directly in digital format heck of a lot faster and without risk that it is not convertible. This sounds like if someone at the hotel would come to explain to me that "No, we use these CRT televisions with digital broadcast conversion boxes to receive digital broadcasts because it is more convenient to visitors than using those digital LCD televisions." Long story short: No it is not!

WAV-files represent analog data and it is absolutely superb that you have support for that, it is great and I love it! CAS-files represent digital data, so converting that trough analog is just stupid. This is not how those files were meant to be used... If it would be, we would probably see such a support in fMSX where this format originates... and we don't... for a good reason...

I could imagine that the convenience comes from the fact that now if you forget to eject the CAS-file from Catapult the openMSX terminates to fatal error on next start up... as well as from the fact that only this analog format is supported when starting the openMSX from commandline. These are anyway both things that would be a lot more easy to fix than what you are now planning if there would be will to do that.

As we have been in this same discussion at least few times before, I'm very much aware that we both have few good points, but it is unlikely that we will ever agree, so... moving forward... nothing to see here...

Page 3/6
1 | 2 | | 4 | 5 | 6
My MSX profile