Steem SSE beta

[npomarede]

Here is an example of a CTR file. Same trouble as dlfrsilver. Game doesn't boot and the disk seems to be corrupted with Steem beta.
http://stonish.net/Ballistix.zip
I have tried other games that I imaged with KF over the last weeks : had the same results.

I confirm that this CTR of Ballistix works with Hatari and CapsImg.dll v5.
By the way, the CTR file is rather big compared to other I saw, maybe you recorded a lot of revolutions ?

[Brume]

Good to know it works with Hatari. Does it work only with the beta version or may I use the regular version (1.7.0)?

I haven't changed the default option to create the CTR file with Kryoflux GUI. But I used the 'multiple' function (RAW + CTR + MFM sector image in the same batch).

[Steven Seagal]

Thx for the image Brume.
Doesn't the "hot beta" work with option 'Hacks' checked? It does in the current dev build (at least loads).
One problem seems to be that "platform ST" isn't set.

[dlfrsilver]

Oh ok ! I was not aware that CTR files where actually activated by 'hacks' in steem.... LOL

I have tried a tool, very rare, that i have dumped back in the day on my amiga, called SPACK from Esat Software for Atari ST.

Esat was a french house known for its nasty protections on disk.

https://app.box.com/s/c4053rig1eye2iq42zpc

And also Dragon Flight english version for atari ST (This game perform a copy protection check at the beginning in track 79 sector 02.
It then fails big time by loading up to track 83 sector 18.

There must be an FDC bug somewhere.....

Here are the 3 disks in CTR format :

https://app.box.com/s/3k3yqddywelakmia8uah

And Z-out for atari ST in CTR format (runs pretty well ) :

https://app.box.com/s/8uw07c1ifjtq2orkat3x

Enjoy Steve !

PS : ballistix works good under steem in CTR format (It checks track 83 sector 03 )

[npomarede]

Good to know it works with Hatari. Does it work only with the beta version or may I use the regular version (1.7.0)?
I haven't changed the default option to create the CTR file with Kryoflux GUI. But I used the 'multiple' function (RAW + CTR + MFM sector image in the same batch).

Not in 1.7, you can get CapsImg support in Hatari if you compile the current dev sources available in the public source repo.

[Steven Seagal]

Oh ok ! I was not aware that CTR files where actually activated by 'hacks' in steem.... LOL

Not activate, the hack was used to run unofficial IPF images. Of course, all CTR are unofficial.
Now you won't need the option anymore.
Anyway, I'm shocked to learn that not everybody uses the option, quite unique among emulators.

I have tried a tool, very rare, that i have dumped back in the day on my amiga, called SPACK from Esat Software for Atari ST.

Esat was a french house known for its nasty protections on disk.

https://app.box.com/s/c4053rig1eye2iq42zpc

It seems an interesting case that you should report to the Kryoflux team, apparently command $D4 not followed with $D0?

And also Dragon Flight english version for atari ST (This game perform a copy protection check at the beginning in track 79 sector 02.
It then fails big time by loading up to track 83 sector 18.

There must be an FDC bug somewhere.....

Here are the 3 disks in CTR format :

https://app.box.com/s/3k3yqddywelakmia8uah

This was in fact a CPU bug in Steem SSE, fixed now, thx for the report!

And Z-out for atari ST in CTR format (runs pretty well ) :

https://app.box.com/s/8uw07c1ifjtq2orkat3x

Enjoy Steve !

PS : ballistix works good under steem in CTR format (It checks track 83 sector 03 )

At least some images work.

[dlfrsilver]

I got the latest beta, Dragonflight still refuses to run ! I'm using STE config with 1mb of ram, the game loads disk 1, then get stuck on track 83 sector 18.

Can you help with that ?

[Steven Seagal]

Oops, yeah your right, it only worked in the debug build, it's fixed now. Thx again!
I also added a Steem patch to pass the protection in Jupiter's Masterdrive STX.
That's strange, there's an option to disable Randomize in pasti but it looks like it doesn't work.
And if someone could test Turrican CTR, I doubt it will work.

[IFW]

I am not sure what should happen in SPACK when it does not work...
But what I can see with the latest development build of Hatari+lib is that you can select the machine type, and after some loading you see an IDE like thing.
Note, that this build works with Lethal Xcess correctly, and it had an issue related $D4 command which sounds similar.

[IFW]

Turrican CTR (at least one I made from a stream dump) does work, but you need to implement the revolution restart in the host emulator as discussed in the other thread.

[Steven Seagal]

I am not sure what should happen in SPACK when it does not work...
But what I can see with the latest development build of Hatari+lib is that you can select the machine type, and after some loading you see an IDE like thing.
Note, that this build works with Lethal Xcess correctly, and it had an issue related $D4 command which sounds similar.

In Steem is hangs after machine selection.
Wait and see then...

Turrican CTR (at least one I made from a stream dump) does work, but you need to implement the revolution restart in the host emulator as discussed in the other thread.

Yes the question was if it was correctly implemented in Steem.
Same question for Dungeon Master-like protections.

[IFW]

So how is it implemented exactly?

[IFW]

No need to wait

[Steven Seagal]

Yep, both Lethal Xcess IPF and Spack CTR work now with this version, cool. Funny coincidence for Spack being the same problem.

So how is it implemented exactly?

I won't give annoying details here, we'll see if that's wrong with tests.

[IFW]

Yes, never thought I'd see that again - never say never
Additionally, Damocles is working due this as well.

[dlfrsilver]

Guys, i have two working dumps of Turrican for atari ST (i made 2 KF stream dumps of them before my father burnt the house).

I'll post the CTR files here

EDIT : i have a problem again with Dragon Flight, the disk A loads correctly, however, there is a problem with disk B-C (both sides disk).

I can't create a disk copy nor play with the CTR or STX file of disk B-C, because what a real atari ST is doing is creating actually a disk which does NOT contains the copy protection (it checks it when asking Disk B-C if you start the game) and stands on Disk B track 01 sector 06.

Steem needs either to create a copy holds 6x1024bytes sectors per track, and with this condition, the game will operate normally. MSA converter is not able to make disks with less than 8 sectors. Can you help here ?

[avtandil]

Hi, Steven,

I read somewhere before that you deal with Notator issue (while playing midi-file it sounds very jerky).

Tried your last version - it's now better, started to play normally, but after 10-15 seconds, the sound start delay from the real bar.

Could you please check ?

[Steven Seagal]

Guys, i have two working dumps of Turrican for atari ST (i made 2 KF stream dumps of them before my father burnt the house).

I'll post the CTR files here

It seems to work in Steem (loads to game), but you checked that, right?

EDIT : i have a problem again with Dragon Flight, the disk A loads correctly, however, there is a problem with disk B-C (both sides disk).

I can't create a disk copy nor play with the CTR or STX file of disk B-C, because what a real atari ST is doing is creating actually a disk which does NOT contains the copy protection (it checks it when asking Disk B-C if you start the game) and stands on Disk B track 01 sector 06.

Steem needs either to create a copy holds 6x1024bytes sectors per track, and with this condition, the game will operate normally. MSA converter is not able to make disks with less than 8 sectors. Can you help here ?

Argh!

[Steven Seagal]

Hi, Steven,

I read somewhere before that you deal with Notator issue (while playing midi-file it sounds very jerky).

Tried your last version - it's now better, started to play normally, but after 10-15 seconds, the sound start delay from the real bar.

Could you please check ?

Hi
Does it work in another version?
Is option 6301 true emu checked?

[Steven Seagal]

Argh!

I've looked at it, the backup disk has a fancy format, with different tracks and different sector sizes, and manipulated sector ID as well.
It's a nice challenge, we need either another disk image format or write support in CAPS library!

[dlfrsilver]

Argh!

I've looked at it, the backup disk has a fancy format, with different tracks and different sector sizes, and manipulated sector ID as well.
It's a nice challenge, we need either another disk image format or write support in CAPS library!

It should not be a problem steve, because the amiga version operates the same way.

Since St disk formats are simpler than the amiga ones, it should not be a problem.

The back-up format uses also a 6x1024bytes sectors like the original. The only thing is to allow steem to create any image with the requested sector numbers. You did it, and you win. ST file format should perfectly be usable for that.

No need to image a backup disk under pasti. my problem is that actually no tool allows to create an image of 6x1024 sectors. only tracks with 8 sectors minimum, and this is not what the game wants.

[npomarede]

Argh!

I've looked at it, the backup disk has a fancy format, with different tracks and different sector sizes, and manipulated sector ID as well.
It's a nice challenge, we need either another disk image format or write support in CAPS library!

It should not be a problem steve, because the amiga version operates the same way.

Since St disk formats are simpler than the amiga ones, it should not be a problem.

The back-up format uses also a 6x1024bytes sectors like the original. The only thing is to allow steem to create any image with the requested sector numbers. You did it, and you win. ST file format should perfectly be usable for that.

No need to image a backup disk under pasti. my problem is that actually no tool allows to create an image of 6x1024 sectors. only tracks with 8 sectors minimum, and this is not what the game wants.

Hello
the format is 5x1024 + 1x512. The problem is that in .ST file, there's no header, you just have a file size, so it's quite hard to guess what the image contains : 11x512 ? 10x512 or 5x1024 ? and so on. You can do some divide with some common values and it's often possible to guess, but in the end, this really not a failsafe format and not appropriate for anything else than 512 byte sector.
And in fact, it's easier on the Amiga, because you always write the whole MFM track when writing a sector, whereas on ST you must locate the sector in the track and overwrite it. From an emulation point of view, the ST case is more complicated because you need to be aware of the sector layout in the file. On Amiga, you just write approx 6200 bytes.

Nicolas

[dlfrsilver]

It should not be a problem steve, because the amiga version operates the same way.

Since St disk formats are simpler than the amiga ones, it should not be a problem.

The back-up format uses also a 6x1024bytes sectors like the original. The only thing is to allow steem to create any image with the requested sector numbers. You did it, and you win. ST file format should perfectly be usable for that.

No need to image a backup disk under pasti. my problem is that actually no tool allows to create an image of 6x1024 sectors. only tracks with 8 sectors minimum, and this is not what the game wants.

Hello
the format is 5x1024 + 1x512. The problem is that in .ST file, there's no header, you just have a file size, so it's quite hard to guess what the image contains : 11x512 ? 10x512 or 5x1024 ? and so on. You can do some divide with some common values and it's often possible to guess, but in the end, this really not a failsafe format and not appropriate for anything else than 512 byte sector.
And in fact, it's easier on the Amiga, because you always write the whole MFM track when writing a sector, whereas on ST you must locate the sector in the track and overwrite it. From an emulation point of view, the ST case is more complicated because you need to be aware of the sector layout in the file. On Amiga, you just write approx 6200 bytes.

Nicolas[/quote]

you got a point about track write on amiga. But there are games using trackloading on ST (i should say sector loading), and even better, there's no MFM used, the track contents on ST are readable. what's the point of the sectors headers ? In ST format, you have a header saying 10 or 9 sectors per track, otherwise how a game could find back his babies ?

If the ST format miss some NEEDED informations, then it's not suitable for emulation. Because we won't start writing and modifying the STX files.
This has to be done is another disk container format.

[npomarede]

you got a point about track write on amiga. But there are games using trackloading on ST (i should say sector loading), and even better, there's no MFM used, the track contents on ST are readable. what's the point of the sectors headers ? In ST format, you have a header saying 10 or 9 sectors per track, otherwise how a game could find back his babies ?

I think you're confusing tracks and MFM and sectors. The ST tracks *are* MFM, there's no other way, the WD1772 read MFM data.
Yes, it's possible to build a track with only data and no sector (Lankhor games for example), but this has some drawback because you need to avoid using some specific bytes that would confuse the WD1772 when reading the track (and you would get wrong data), so you loose some space in each track to 'escape' those bytes with a different code when you need to store them. In the end, I think most game developpers considered it was not worth the effort to gain a few hundred bytes per track when you could get much more by compressing data (and many games didn't need more than 800 kB, so regular 10 sectors per track is enough)
The point of sector header is that when you tell the WD1772 to read a sector, then it doesn't get confused about some bytes like the read track command would be; this is a known "bug" in the WD1772 that read track can't read back all bytes as they were written at first.

If the ST format miss some NEEDED informations, then it's not suitable for emulation. Because we won't start writing and modifying the STX files.
This has to be done is another disk container format.

It could be a simple file with a linked list of sectors, each sector having a track, side, size information, then the sector data, then a pointer to the next sector.
If you need to write a sector that already exists, you overwrite it ; if it's a new sector to save, you add an entry at the end of the linked list.
But there could be many other way to store this ; the format should also be able to store the result of a "write track" command.

Nicolas

[IFW]

.ST format is a pure sector dump.
As such it's perfect for standard disks, demos, work, etc. - and that's the only purpose of it.
If you need to store something more complex, you should use something different.
The need for more complex formats only emerged after emulation has matured enough to get more complex things than just user created disks running.