Re: [hatari-devel] STX (Pasti support)

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 18/02/2012 14:18, Fredrik Olsson wrote:
> Hi.
>
> I am new to Hatari dev, diffs, and CMake so I thought I should get some verification that I am doing the right thing before I do something completely off the tracks.
>
> I have implemented rudimentary support for STX (Pasti) disk images. Currently it only supports unprotected disks with 512bytes sectors (More support requires some rewrites that I want input on first).
> Many, but far from all, images from http://www.atarimania.com/ works now. Bad Company works and boots as expected. Whereas Bombuzal and Dungeon master disks can be browsed in GEM, but fails copy protection checks due to missing timing and fuzzy sectors.
>
> I have attached my patch as diff-file for the 1.6.1 source tree. I only have access to a Mac OS X machine, so I would also be glad if it could be verified to work on Linux. And also get input on coding style, and what is the official route for submitting patches?
>
> I have added stx.h/stx.c, and modified floppy.c/createBlankImage.c. And relevant CMakeLists.txt.
>
> // Fredrik Olsson

Hello

thanks for sending your patch.

Looking at the stx.h file, I see it's heavily similar to the one from 
the HxC floppy emulator ; I think the least would be to credit 
Jean-François DEL NERO in your file for the work he made to reverse 
engineer the pasti format.

This being said, I'd rather have a complete (or nearly complete) 
emulation before including it in Hatari main tree ; of course you can 
send patches here, so people can try them and see the progress.

But the main problem is that supporting complex protection schemes will 
require a complete rewrite of the disk image storage in memory in 
Hatari. Storing plain bytes as 512 sector won't just be enough (in that 
case, the STX file could even be converted to a .ST file).

We need a more complex structure to hold the track/sector/size of each 
image (eventually .ST images would be stored in this more complex 
structure). We could also need to store the RAW track data (as returned 
by the read track command).

The problem is that the choice of this more complex structure requires a 
good knowledge of the informations stored in an STX file, which is not 
officialy documented (such more complex structure should also be able to 
store IPF files).

In the end, I don't think converting the STX file to fit Hatari's 
structure is the best way to go. A better approach would be to load the 
STX file in its own buffer, then add some hooks for each FDC command to 
call the "STX version" of these FDC commands.

This way, our generic FDC code remains usable, and if an STX disk is 
inserted the STX specific code will be used.


If you're willing to work on this, it will be greatly appreciated (I'm 
looking forward to the day where we can boot the Union Demo in Hatari ;-) )

Nicolas