Kryoflux in ST emulators?

[Jeff_HxC2001]

Because kryoflux already support emulating a WD1772 at the bit level, while HxC doesn't ? Are you sure you understand how the disk image are made and what is required to handle them ?
HFE is just a file format, as IPF is. But IPF also comes with the capslibrary to handle these files in an emulator, as far as I know, there's no equivalent library to use in your own program if you want to handle HFE files

...
If HxC provides in the future the necessary WD1772 emulation level to decode HFE file in an emulator, I will look how to add it to Hatari.

Well in fact the libhxcfe is available since some months... It doesn't have yet the WD1772/uPD765 emulation layer, but this is planned.
I have already use it to add the HFE file format support to VFD and ADFOpus.
Anyway this lib will allows you to support more than the HFE file format .
(Note : There are a Kryoflux stream loader/analyzer in the lastest version. I can now play my original disk game from the USB version by using the HxC AFI file format )

[npomarede]

Well in fact the libhxcfe is available since some months... It doesn't have yet the WD1772/uPD765 emulation layer, but this is planned.
I have already use it to add the HFE file format support to VFD and ADFOpus.
Anyway this lib will allows you to support more than the HFE file format .
(Note : There are a Kryoflux stream loader/analyzer in the lastest version. I can now play my original disk game from the USB version by using the HxC AFI file format )

That's good news, having a library that handle all the range of ST disk format would be great.
Do you mean the HxC AFI format allows to run images from the Kryoflux board without requiring to use a processed IPF file ?
If so, it's interesting for kryoflux boards owner, as it allow to use your own dump immediatly (until the corresponding IPF file is officialy released)

Nicolas

[Ian]

In the Windows version at least, the library doesn't support writes, which is a bigger issue than just one game. Because of that, there's an annoying alert box popping up ("command A0 not implemented") in many games and Sundog doesn't work.
I can imagine ways to circle around write support in Steem, but not around the popup boxes, and it would be useless work anyway if a next version of CAPSimg directly supports writes.
The best course now seems to release Steem with IPF support as it is, that is as good as the library itself, and count on Steem fanboys to go scream at the Kryoflux forums. That is, if they have IPF files to play with in the first place.
The same for Lethal Xcess, the game will run when a better version of the library will be released, it's not up to Atari emulators.

and so it shouldnt. The point of ipfs is to keep games preserved in there original state allowing writting to them eill mean we'd end up with hundreds if useless different versions

Have you had a look at winuae? Toni has implemented a save image were any changes are written and combined with the original ipf. Would be great if this was done in steem (and hatari) too.

[Ian]

In the Windows version at least, the library doesn't support writes, which is a bigger issue than just one game. Because of that, there's an annoying alert box popping up ("command A0 not implemented") in many games and Sundog doesn't work.
I can imagine ways to circle around write support in Steem, but not around the popup boxes, and it would be useless work anyway if a next version of CAPSimg directly supports writes.
The best course now seems to release Steem with IPF support as it is, that is as good as the library itself, and count on Steem fanboys to go scream at the Kryoflux forums. That is, if they have IPF files to play with in the first place.
The same for Lethal Xcess, the game will run when a better version of the library will be released, it's not up to Atari emulators.

and so it shouldnt. The point of ipfs is to keep games preserved in there original state allowing writting to them will mean we'd end up with hundreds of useless different versions

Have you had a look at winuae? Toni has implemented a save image were any changes are written and combined with the original ipf. Would be great if this was done in steem (and hatari) too.

[Jeff_HxC2001]

Do you mean the HxC AFI format allows to run images from the Kryoflux board without requiring to use a processed IPF file ?
If so, it's interesting for kryoflux boards owner, as it allow to use your own dump immediatly (until the corresponding IPF file is officialy released)

Nicolas

Yes that's the idea.

[Steven Seagal]

In fact, I already added it to Hatari this summer and it worked succesfully with all the ~200 images I had, except with one game where an error was discovered in the capslibrary that emulates a specific WD1772 command.
As soon as capslibrary is fixed to handle this and no other problem is seen, it will be released for Hatari 1.7

Nicolas

Why the private builds?
What's the point of waiting for just one game, if the fault is in CAPS and development is slow?
Steem 3.5.0 has been released with CAPS support a while ago already.
Not everything works, so what?

[npomarede]

In fact, I already added it to Hatari this summer and it worked succesfully with all the ~200 images I had, except with one game where an error was discovered in the capslibrary that emulates a specific WD1772 command.
As soon as capslibrary is fixed to handle this and no other problem is seen, it will be released for Hatari 1.7

Nicolas

Why the private builds?
What's the point of waiting for just one game, if the fault is in CAPS and development is slow?
Steem 3.5.0 has been released with CAPS support a while ago already.
Not everything works, so what?

It's not a private build in the sense "I keep it for myself", it's a dev version where everything is not completly ready for release, especially I want to add support for IPF for all the versions (linux, windows, osx, ...) and this takes time to ensure everything compiles fine on all OSes. As I knew I wouldn't have time to include it in Hatari 1.7.0 anyway, I worked on other parts of the emulation, it will be postponed to the next release.

Nicolas

[Steven Seagal]

That's why I use #define a lot.
For example, I started preliminary tests with the SDL, but it's for a later version. Some code is there, but not compiled because SS_SDL isn't defined. It's better than having different source versions.

[npomarede]

That's why I use #define a lot.
For example, I started preliminary tests with the SDL, but it's for a later version. Some code is there, but not compiled because SS_SDL isn't defined. It's better than having different source versions.

Depends on the case ; when I'm in the middle of some changes where I know it will take only a few days, I use #ifdef too to be able to switch between old/new behaviour and do some regression tests.
But in the case of IPF integration, I also refactored quite some code, which makes it too hard to keep everything in a single source version ; hopefully I will be able to merge everything with mercurial functionalities later.