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

[ Thread Index | Date Index | More Archives ]

On 18/02/2012 14:18, Fredrik Olsson wrote:

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 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


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 ;-) )


Mail converted by MHonArc 2.6.19+