Re: [hatari-devel] IPF file format support (Kyroflux) (in addition to STX)

[ Thread Index | Date Index | More Archives ]

On 18/02/2012 17:55, Matthias Arndt wrote:

it seems another storage scheme for copy protected disks is coming up.

There is also a sort of library for this:

Maybe Hatari should feature a common API for adding the formats, so that
in the end only FDC wrappers are needed and they forward all access to
sublibraries which are then seperate for fileformats?

Basically put the existing code for ST/MSA/DIM into on sublibrary and
late add for STX and IPF?



regarding IPF format, I already contacted the authors some weeks ago ; they would interested in an ST emulator that would support their format and hopefully, they shouls send me a few code examples to see how to init the different structures (although I understand how their library work, I don't have time to figure out myself the correct way to init the different structures).

As for sperating the different formats in a more general abstraction, I already started working on this (for ST/MSA/DIM, it's not a huge work). I'm waiting for spare time to work on STX and/or IPF to finish this more generic abstraction.

But in the end STF/IPF are so much complex, that we would in fact need two kinds of "API" : one for simple formats like ST/MSA/DIM (fixed sector size, no special status register, ...) that would go in the current fdc.c code, and another one for complex formatz such as STX/IPF.

For these complex formats, the "API" is already here : intercept all access to $ff86xx and do the work outside of fdc.c :) This may look simplistic, but there's no way to make a common API (in the way of using common functions) when both formats have different logic and eventuallt mimic the full behaviour of the FDC.

Best approach is a low level interception of all accesses.

The only common code that would be shared would be the one for the dma disk that buffers bytes by blocks of 16.


Mail converted by MHonArc 2.6.19+