sarnau wrote:This should help the guys working on e.g. Hatari to deal with Pasti files...
ijor wrote:Nice work Markus (not angry at all, just in case you wonder)
Please keep in mind that the public imaging tool wasn't the only one used for producing the images. Many images out there were produced, or sometimes post-produced, by tools not widely/publicly available.
DrCoolZic wrote:Can we assume the description is accurate and complete ...
...or not publicly available tools can produce different format?
DrCoolZic wrote:Ijor/Sarnau: Is it possible to store macrodos protection in stx? If yes how?
bringing this old subject to life, I'm actually looking at the pasti format description made by Sarnau, and I'm also wondering how clock variation are stored for read track or read sector ?
DrCoolzic, did you find more information about this (maybe you wrote your own parser in the meantime) ?
Maybe by comparing macrodos' disks with other disks we could see a bit in a flag that indicates clock variation infos are present ?
DrCoolZic wrote:Yes indeed I have the full STX description and where the timing info are located. I have discussed the format with Ijor and now I believe I got it right.
there is only one thing that is missing this is the the timing unit used in the "timing block"
and yes I have a parser that read STX file.
Can you give me few days because I need to find where all this info is located ...
I am currently spending 200% of my time on my new program that analyzes the Kryoflux stream output. You can look at some of the outputs in http://forum.kryoflux.com/viewtopic.php?f=3&t=749
The goal of this program is to analyze the input (currently stream file) to detect protections and to produce .st or .stx files (so yes I will soon need to look at stx format information).
I hope you will support stx format in Hatari because the IPF road seems to be blocked for quite some time as SPS people seems to have other priorities
FYI I have just learned about a new product called SuperCard Pro that is better than the Kryoflux board. This guy knows exactly what user wants: be able to either copy or generate emulation files from their FD without worrying about nonsense technical details. I am in contact with the person responsible of the product and I intent to support the format as input ... more on this latter
DrCoolZic wrote:After all it did not took me too much time to check my Past documentation.
So here you are attached to this post.
The things that you will have to watch is the section on timing variation specially speedlock/macrodos.
This is hopefully clearly explained but let me know if something is not clear.
For the code it is embedded with other part of another experiment so I will need few days to publish.
There is a .h file that define the format and a reader library + a test program that check and display the content of any Pasti file.
I will probably post it soon but may be not before next week or year
I will make all this public domain so that it can be used as a reference for further development probably on Github.
npomarede wrote:Thanks for the doc, although I was only missing the infos on the timing, the gfx are very clear and this gives a very good reference doc.
From previous discussions here, I thought some games could also used inter gap bitcell variations, which would require a per-track timing table instead of a per-sector one. But maybe this was just theoretical discussion and no game use such protection ?
From your experiments, are speedlock/macrodos games imaged with embedded timing table (version 2), or are they using the one contained in the DLL (version 0) ? Do you have the table used for version 0 ? (if not, I could build it, if I recall correctly, macrodos are made of only 4 or 8 blocks with different timings per sector).
npomarede wrote:Just a question about your description of the sector header : you say the default read time is 16480 or 515 bytes for a sector, which seems strange to me, because as the DMA read bytes by blocks of 16, there's no way to know the timing for 512+3=515 bytes which is not a multiple a 16.
Also, what would be those 3 extra bytes ? Sector AM + 2 CRC bytes ?
In its docs Sarnau gives a default value of 16384, which gives 512 bytes at 32 microsec, which seems more coherent to me.
Maybe you made a typo in your doc ? (note I didn't have a look to a real STX file to check its value, so maybe I'm wrong, it's just that 515 bytes seems odd)
DrCoolZic wrote:FYI: I plan also to add a section on how/when to write the different parts of the STX file based on detected protections. This will be only useful for people that want to write STX
By the way I have also found my STX dump program if interested I will publish the source?
Users browsing this forum: No registered users and 1 guest