05783: sol20: SVT format differs from Solace emu!

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05783	Misc.	Minor	Always	Nov 27, 2014, 14:48	Jun 15, 2016, 08:50

Tester	demotester	View Status	Public	Platform	MESS (Official Binary)
Assigned To	Robbbert	Resolution	Fixed	OS	Windows XP
Status [?]	Resolved			Driver	skeleton/ptcsol.cpp
Version	0.156	Fixed in Version	0.175	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	05783: sol20: SVT format differs from Solace emu!
Description	I have made 2 files: one that works on solace emulator but not in MESS, and the other one that works in MESS but produce loading error in Solace emulator. (test files attached below) Note: The 1st one is almost same as metron in softlist, the other one is made with replacing the D data with those from "tinyc.ent" file. I noticed that Solace emu report loading error just a few second after start loading the other one file, and that is around address 0100. (see on attched picture) If you compare two files, you will notice that after a block of zeros in Solace file the 1st byte is 3C and on the other file the 1st byte is 2A ?! If you load the file that works in Solace emu with "GET" command and dump the mem with "DU 0100", you will see that there is no 3C on 0100 address than 2A. If you load the Solace version of file in MESS emu, on addres 0100 will be 3C ?! Thus the 3C must be some of code known to Solace emu loader that is not implemented in MESS emulator. (Probably that is why a lot of SVT files have a problem to start when loaded in MESS.) I found something mentioned on the folowing link -> http://www.sol20.org/solace/solace_tape.html quote: "Finally, there is the "magic hex" values MM, which represents one character time of carrier. This is used to model fine-scale timing; the C command models time on the scale of tenths of seconds. The MM value may not be preceded by the error flags." ... and probably this is what is not emulated in MESS! Link to latest version of Solace emu -> http://www.sol20.org/solace/solace3_2.zip Solace emu is free according to "building.txt" found in "build" folder of Solace emu ... quote: "CODE OWNERSHIP: If you want to take pieces of code out of Solace, feel free. If you take large parts of code, I'd like to be given a bit of credit for my work; including it in a comment in the code itself would be nice. Please drop me a line if you make use of my code; I'd get a kick out of knowing that somebody found it useful." There is also "src" folder with "vtape.c" and "vtape.h" that should explain all.
Steps To Reproduce
Additional Information	0.153: Added partial support for SVT format (used in Solace emulator) [Robbbert].
Github Commit

Flags
Regression Version
Affected Sets / Systems	sol20

Attached Files	SVT_test.zip (23,222 bytes) Nov 27, 2014, 14:48 Uploaded by demotester
	SVT_test.png (14,490 bytes) Nov 27, 2014, 14:49 Uploaded by demotester
	SVT_test_solace.png (13,216 bytes) Nov 29, 2014, 13:59 Uploaded by demotester
	Another example.zip (6,167 bytes) Jun 3, 2016, 18:08 Uploaded by demotester Another test case example files !

No.11269 Robbbert Senior Tester Nov 27, 2014, 21:47	The only SVT files we could support are those created by Solace and not edited afterward. If you're modifying the file by hand who knows what will happen. The 3C byte is a data byte and not preceeded by any error flag, there is nothing to say it should be omitted. Please supply a SVT file that has come directly from Solace without modification.
No.11270 demotester Tester Nov 28, 2014, 12:42 edited on: Nov 29, 2014, 14:00	tinyc-work-in-Solace.svt == same as metron.zip from softlist (only the 1st file -> the TC file) tinyc-work-in-MESS.svt == above file modified with data from tc.ent (http://www.sol20.org/tapes/tinyc/tinyc.zip) Note: Hope you know the .ent file is dump of memory, right? Now do following ... in Solace emu and then in MESS emu: 1) attach metron.zip file in emu 2) load the 1st TC file into memory with command ... GET TC 3) dump the memory locations ... DU 0000 010F (do you see 3C on 0100 location?) 4) start the file in emu ... EX 0 (does it work?) 5) Compare the metron.zip file with tc.ent file in an text editor: metron.zip == D 3C2A4605F9C30605C304C0CD0E01C9C5 tc.ent == 0100: 2A 46 05 F9 C3 06 05 C3 04 C0 CD 0E 01 C9 C5 47 Is your findings same as mine? The byte 3C exist in metron.zip but not in memory dump when loaded in Solace emu, right? (see on attached SVT_test_solace.png)
No.12746 demotester Tester Jun 3, 2016, 18:11 edited on: Jun 3, 2016, 18:26	Here's another example (see Attached Files), this time recorded directly from Solace emulator. Of course, in Solace emulator it will work after has been loaded, but not in MESS emulator !? Analyzing / comparing the data in the memory of Solace emulator, after loading from the .svt file, can come to the conclusion that after each 256-byte in .svt file is sort of control byte and the same is not present in the memory of Solace emu after loading. As for the MESS emulator, situation is that MESS all bytes from .svt file treated as data, and the same also are there in memory of MESS emulator after loading. After this it turns out, if the MESS emulator dropped every 256-th+1 byte, it seems then data could have been properly loaded into memory. So it is now all together a little clearer, but still have not managed to find a formula that Solace emu use to calculate each 256 byte in next control byte.
No.12749 Haze Senior Tester Jun 5, 2016, 12:32	sounds like one version of the file format has a checksum byte every 256 bytes or similar? who is breaking the spec, MAME, or the other emulator?
No.12750 demotester Tester Jun 5, 2016, 12:51 edited on: Jun 6, 2016, 14:33	Well, the .svt tape format is 1st made for Solace emu, so MAME should support the same spec if want to be compatible with the Solace, right? EDIT: Seems the Solace is doing it right; so find the needed infos in the Music System User Manual -> see last 2 pages !!! ( http://www.sol20.org/manuals/music.pdf ) If after this someone still not clear what is the problem, I give up :-).
No.12757 Robbbert Senior Tester Jun 11, 2016, 14:03	Extra byte was a checksum byte.
No.12758 demotester Tester Jun 11, 2016, 14:39	We finally figured out what was the problem, excellent ! :) Thanks for the repair.
No.12760 demotester Tester Jun 12, 2016, 14:59 edited on: Jun 13, 2016, 08:48	Thanks for the new Bleeding-edge release of MESSUI ! :) So, I checked it today and found a possible new problem: if in a .svt file program header name is 2 letters, the MESS has a problem to load it ! F.e. if check above "attached" tinyC, it has 2 letters but more than one space in header name between TC and 43 - so it works fine in MESS and Solace, but the tinyC from SW-list has only one space between header name TC and 43 so it fail in MESS - but works fine in Solace ! Hope this could be fixed easy ! (thx) EDIT: it seems that this problem with a header name exists since before , so it's not new !
No.12766 Robbbert Senior Tester Jun 15, 2016, 05:09	Since it's an unrelated problem, can you make a new bug for it?
No.12767 demotester Tester Jun 15, 2016, 08:50	New MT bug opened! :-)