are there any docs about the Pasti DLL? I'm planning to write an advanced image conversion utility that can directly access the virtual disks on USB-keys used with floppy-emus so that one can write disk-images in various formats directly from the PC.I plan to support STX-images, too, but I'm missing information about the API of the Pasti DLL.Can anybode help here?TIA!

are there any docs about the Pasti DLL? I'm planning to write an advanced image conversion utility that can directly access the virtual disks on USB-keys used with floppy-emus so that one can write disk-images in various formats directly from the PC.I plan to support STX-images, too, but I'm missing information about the API of the Pasti DLL.Can anybode help here?TIA!

Chris

There is already partial Pasti (STX) support for HxC floppy emulator. It is coded by Jeff self, but he abandoned further development couple years ago.There were several problems, and lack of documentation was just one of them. For instance SD version of HxC supports not variable density, what is base of some protections - like popular Copylock (after 1990) .What floppy emulators do you plan to support ?

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll wrote:There is already partial Pasti (STX) support for HxC floppy emulator. It is coded by Jeff self, but he abandoned further development couple years ago.There were several problems, and lack of documentation was just one of them. For instance SD version of HxC supports not variable density, what is base of some protections - like popular Copylock (after 1990) .

No. I have done the very first reverse of this format 7 years ago. The problem is that this format was designed to be used with software emulators, not to recreate a floppy disk at the support/mfm level. The USB HxC Floppy Emulator have all the needed support to emulate protected disks. But the pasti just doesn't provide enough information to recreate with a 100% success rate a working track at the MFM/pulses level. Some "guessing" code can be added, but this kind of things will not lead to a reliable solution...

Jeff, I did not say anything about when you started, but when you stopped. Of course, everyone can join this open project. But somehow I don't see that it will happen - because people capable of doing it is busy with other things.I know that USB HxC has needed features - I tested a lot of STX images with .. But as see, SD version is more popular.In any case, I'm personally not much interested in STX support, because I prefer hard disk run of old quality SW, so spending time on it. And often more time goes on fixing bad things in games than removing copy protection(s) for instance. There was lot of people involved in gaming industry, with pretty low knowledge about 68000 coding and ST HW, TOS . What is interesting is that DrCoolZic worked (and still works ?) on making STX images writeable - by converting to SPC format, I guess. I don't know much details about it, as I don't own any HW for writing protected floppies, and don't plan to deal with .. I think that STX support for HxC can be improved, and in meantime we discovered some limitations of Pasti format, + bug about track lead in pasti.dll . Only question is, is it worth of time needed to develop it .

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll wrote:Jeff, I did not say anything about when you started, but when you stopped. Of course, everyone can join this open project. But somehow I don't see that it will happen - because people capable of doing it is busy with other things.I know that USB HxC has needed features - I tested a lot of STX images with .. But as see, SD version is more popular.In any case, I'm personally not much interested in STX support, because I prefer hard disk run of old quality SW, so spending time on it. And often more time goes on fixing bad things in games than removing copy protection(s) for instance. There was lot of people involved in gaming industry, with pretty low knowledge about 68000 coding and ST HW, TOS . What is interesting is that DrCoolZic worked (and still works ?) on making STX images writeable - by converting to SPC format, I guess. I don't know much details about it, as I don't own any HW for writing protected floppies, and don't plan to deal with .. I think that STX support for HxC can be improved, and in meantime we discovered some limitations of Pasti format, + bug about track lead in pasti.dll . Only question is, is it worth of time needed to develop it .

@AtariZoll: Hum some confusion here. I am not working on making STX image writable. As far as I know this is only done in Hatari latest version?I only have a converter from Raw kryoflux and from SPC file formats to STX

@Jeff: apart from some protections not supported by STX (for example fuzzy track) I think it should be feasible to create files at the pulse level that should gives the right emulation result. In other words it might not be same as original but close enough to get good emulation.

It seems that I misunderstood it. Writing Pasti files. and not floppies from Pasti files How about conversion to SCP format

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

Pasti is a one way, lossy conversion - 50% of the data is simply missing, all the clock cycles.The WD controller also transforms some patterns to other "random" patterns - this has been discussed in various threads before.You can only guess the original data on the disk, in practice you need to write a new analyser based on real samples to recreate the data. But if you have the real data to work from (ie the disks sampled) then you already have what you wanted

It seems that I misunderstood it. Writing Pasti files. and not floppies from Pasti files How about conversion to SCP format

Hum again not talking about the same thing!By writable I thought you mean in an emulator the capability to read and write STX file. For example in Hatari 1.8 I think it is feasible to "write" on a STX file.But yes of course Aufit can can write STX from KF / SCP.

Conversion to SCP format does not exist yet but is on the plan for future.Potentially the idea is to be able to convert from any format to any format (like HxC does).As IFW mentioned in theory this is not always feasible especially from STX format. However the good news is that there is only a limited number of FD "low level layout" (protected or not) used on Atari. So by using automatic (or guided) recognition techniques (something similar to what SPS people use to create IPF) it should be possible to recreate low level description of most floppies.

SCP format might get more interest if CosmosEx support it in the future ( see viewtopic.php?f=103&t=26804&p=258251#p258223 for example).In that case it would be very interesting that Hatari support it also.If this happen then it would be easy to write a converter from KF raw file to SCP

Thanks guys for all that information. I'll have a look at the sourcecode links you provided.So if I got it right there is no 100% certainty to extract single sector data from an stx image by simply trying to convert the data?How is that done in an emulator? I mean, the emu still has to read the disk in any way that the contents stay valid?

ChrisTG wrote:Thanks guys for all that information. I'll have a look at the sourcecode links you provided.So if I got it right there is no 100% certainty to extract single sector data from an stx image by simply trying to convert the data?How is that done in an emulator? I mean, the emu still has to read the disk in any way that the contents stay valid?

Emulator does not read disk. it reads image file. Or in other words, emulator (better said pasti.dll ) decodes not MFM flux coming from floppy drive.It is best visible in case if track read. What is used in copy protections, but as data container too - so some games, like Vroom have no sectors at all on floppy (except bootsector, of course). WD1772 reads track in special way, and resync always after specific bit pattern. Therefore it will not read exactly what is written on track. Pasti images simply hold track dump as it is read on real Atari, with which it is made. Only 1 dump for each track. And that is btw. insufficient for few protections having fuzzy data in track. There are timing informations in STX images - how fast sectors load, instead of exact flux data. + other things as fuzzy info ...All in all, Pasti is not real floppy image - it is some kind of hack, made special for emulators. Good thing is that you don't need special equipment for making images, only regular ST(E) .There are no source codes, just format description, made by few people by analysing STX image files and how work in Steem.Extracting single sector from STX is easy. If you look at specs, will see that it is easy part. Problem is with some protections.

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

Emulator does not read disk. it reads image file. Or in other words, emulator (better said pasti.dll ) decodes not MFM flux coming from floppy drive.It is best visible in case if track read. What is used in copy protections, but as data container too - so some games, like Vroom have no sectors at all on floppy (except bootsector, of course). WD1772 reads track in special way, and resync always after specific bit pattern. Therefore it will not read exactly what is written on track. Pasti images simply hold track dump as it is read on real Atari, with which it is made. Only 1 dump for each track. And that is btw. insufficient for few protections having fuzzy data in track.

Vroom use amiga tracks (same things as Maupiti islands, format created on amiga).

Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

This has nothing with this thread, and additionally it is incorrect. Because WD1772's way how it reads track all track dumps which contain data must add special prefix byte, what assure that byte sequence what resyncs WD1772 does not will happen. On Amiga no need for that. After reading track, special code on Atari will correct data to original, by removing prefixes and inserting proper values. Calling them Amiga tracks just because they wrote such tracks on Amiga in developing phase is silly. All it is described on my Pasti specs page: http://atari.8bitchip.info/STXdesc.html

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.