Coming soon! Steem SSE 3.5

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sat May 04, 2013 5:33 pm

npomarede wrote:Hello
regarding Steem SSE 3.5.0, disk loading times are too slow when setting the "accurate mode" in the disk windows (this was not the case before).

For example, take the "Decade Demo" by Inner Circle. If you measure time between pressing "space" during the first boot intro and the start of the countdown on the next screen, you get :
- Steem with accurate : 12 sec
- Steem with Pasti : 7 sec
- Hatari : 5 sec
- My 520 STF : 5 sec

So, disk accesses in accurate mode are way too slow, more than twice what it should be.

Nicolas


Yeah, I guess that's what happens when you decide that 'Verify' should take at least 3 revs. :)
It's an enormous bug, strange that not more is broken!
I'll rectify this, thx for the clear comparison.
A bit surprised by the pasti difference though.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
npomarede
Atari God
Atari God
Posts: 1239
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Coming soon! Steem SSE 3.5

Postby npomarede » Sat May 04, 2013 8:28 pm

Steven Seagal wrote:Yeah, I guess that's what happens when you decide that 'Verify' should take at least 3 revs. :)
It's an enormous bug, strange that not more is broken!

Well, from my experiment, few games/demos rely on strict FDC timings when running from MSA/ST images (because they were cracked or doesn't use any special formatting).
I'll rectify this, thx for the clear comparison.
A bit surprised by the pasti difference though.

I think pasti "transform" the ST/MSA format to an internal track representation with a fixed set of gaps/interleved sectors/...
In the end, this gives different values than the one that could be used on my original ST floppy for this demo, but this is the same order of timings nevertheless (similar issue to the Microprose Golf timings Petari and I had a look recently and for which he told me you fixed some gaps timings in next version)

Nicolas

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sat May 04, 2013 9:47 pm

npomarede wrote:Well, from my experiment, few games/demos rely on strict FDC timings when running from MSA/ST images (because they were cracked or doesn't use any special formatting).


Those at least revealed bugs at some point (DIM, MSA, ST)
(note I keep editing the list, you recognise many "usual suspects"):

Code: Select all

Amiga Demo
BIG Demo
Blood by Holocaust
Delirious 3
Delirious IV
European Demos
FDCT (by Petari)
Froggies Over The Fence
Garcimore
Japtro
Microprose Golf
Noughts and Mad Crosses STE
Punish Your Machine
Overdrive by Phalanx
ProCopy
ST-NICCC 2000 Final by Oxygene (STF+STE version)
War Heli


I think pasti "transform" the ST/MSA format to an internal track representation with a fixed set of gaps/interleved sectors/...
In the end, this gives different values than the one that could be used on my original ST floppy for this demo, but this is the same order of timings nevertheless (similar issue to the Microprose Golf timings Petari and I had a look recently and for which he told me you fixed some gaps timings in next version)

Nicolas


Microprose Golf: in the cuurent dev build of Steem it still loads without hacks but too slowly.
Based on what Petari said there could be a real drive timing issue here, which CAPS (IPF) can handle better, or a future (?) version of Pasti; or there are more enormous bugs to find...
Last edited by Steven Seagal on Sat Jun 01, 2013 6:07 pm, edited 6 times in total.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sun May 05, 2013 8:29 am

Cyprian wrote:
Steven Seagal wrote:Coming soon, a step version 3.5.1 with bugfixes and some nice additions:

- Scanlines + interpolated display mode, more like on a real monitor, it was a request but I like it much.

that display mode looks great.

What do you thing about adding a screen filters/masks in the same manner as in WinUAE? They use masks defined as PNG file.


That looks interesting, but more involved, I can't do that with a little trick like the 'Scanlines + interpolated display mode'.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sun May 05, 2013 8:34 am

Drive Info on screen

While debugging the drive emulation of Steem, wondering if some program loads or is stuck, this was the opportunity to add a nice feature, showing on the display current drive, side, track and sector.
The new option is here (not in SSE tab):
Image

So you launch Microprose Golf and it takes much time (I'm aware it's a bug...):
Image

At least, you know it's still working somehow: it's reading (green led) on drive A:, side 2, track 29, sector 3, while a scroller informs you which emulator is the best just in case. The title screen finally appears, the silly music plays:
Image

Magnetic Scrolls loader
I still remember this dude that had an electronic gadget attached to his ST, giving on big red leds the track info. So he showed me how his ('hardcopied' :( ) disk of The Pawn was reading the tracks backwards (here the Pasti version):
Image

Now we can check that in Steem, and we get sector info to boot. Notice the high number (beyond doc spec), it's part of the protection schema.

Yeepee!
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Coming soon! Steem SSE 3.5

Postby AtariZoll » Sun May 05, 2013 8:53 am

Considering Microprose Golf: gap size affects speed a lot even on real Atari, so I don't think that there is more bug. I need to make some tests with different formatted floppies. Then can try to repeat same loading times in emulators by correcting emulated gap values - what should help to find optimal values. And of course, it will be still just simplified emulation.
If some SW is much sensitive on exact floppy timings, best is to make STX image of it - then should be better, and even better would be to make IPF, as it seems more accurate - but with IPF is not simple. Other way is to add some floppy related settings in emulators, what will be not easy for most of users. Maybe some settings predefined for specific titles ? We can not expect Pasti improvements in near future, really. Kryoflux people is needed to create IPF images. So additional things in emulators are needed, I think. And may be worth to try problematic demos with STT images made from original - then will have exact sector order.
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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Coming soon! Steem SSE 3.5

Postby AtariZoll » Sun May 05, 2013 8:56 am

Great idea to add that disk info !
And I'm one who made floppy track # display too in past .
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.

User avatar
Brume
Red eyes
Red eyes
Posts: 4158
Joined: Mon Apr 22, 2002 10:16 am
Location: France
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Brume » Sun May 05, 2013 9:02 am

Displaying track info is a very nice feature, thank you :D

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Coming soon! Steem SSE 3.5

Postby AtariZoll » Wed May 08, 2013 8:12 am

I made little proggy which tests some relevant timing of floppy, FDC on real Ataris. Since I'm short at moment with working Ataris, would be good that people help little with performing simple test:
All what need is working Atari ST, STE, Mega ST or Mega STE (at 8MHz) with floppy disk in good shape (don't use some with valuable datas on, test writes little on disk) .
Test takes about 15 seconds. Usage and some tech. info included. Please post here your machine type and the result. Thanx.
You do not have the required permissions to view the files attached to this post.
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.

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sat May 18, 2013 6:40 am

The value for Steem 3.5.1 is: 13716 T


Edit: seeing the post by Sonus below, I changed parameter to get 12736 T, closer.
Last edited by Steven Seagal on Sat May 18, 2013 6:47 pm, edited 1 time in total.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sat May 18, 2013 6:48 am

ProCopy

Image

What you always desired is now reality: in Accurate disk access mode, Steem will be able to Analyze (F9) a regular disk image without hanging. Note that Steem 3.2 already could make a working disk copy using the Protect option (F5) of ProCopy.

Analyze also works on IPF disks, but not STX. Also, you can use ProCopy to copy some IPF disk images to normal ST disk images, again not STX.

With this latest fix, all in all and excepting bugs, floppy drive emulation has much progressed again between v3.5.0 and v3.5.1. Care has also been taken to leave emulation unchanged in fast drive mode, so we shall break nothing essential just in case.

Pasti revisited
In v3.5.1, toggling Pasti on/off in the disk manager will not force a reset anymore, nor eject the disks.

The reset thing has always annoyed me, and it keeps you from doing some experiments.

The price for this is: you're responsible, you must know what you're doing. There's no real "risk" anyway, so this is all fine.


That's it for the features. Testing, debugging, cleaning-up the source and it's...

Coming soon!
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Coming soon! Steem SSE 3.5

Postby AtariZoll » Sat May 18, 2013 8:02 am

Another very useful change, for what annoys me too - Pasti on/off reset, desk eject. It will help to make some tests faster and simpler.

Btw. there is strange problem with Pasti imager and floppies with certain sector gaps - will not detect sectors at all . While Steem STT imager detects sectors well on same floppies. I will investigate it more when catch some time - it may be the reason for some not successfull STX imagings, and my Track copy SW suffers from same problem.
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.

Sonus
Retro freak
Retro freak
Posts: 15
Joined: Fri Apr 18, 2008 6:31 pm

Re: Coming soon! Steem SSE 3.5

Postby Sonus » Sat May 18, 2013 9:30 am

FDCT 1040STF: 12512 - 12540 - 12568 T
FDCT 1040STE: 12540 - 12568 - 12596 T

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sat May 18, 2013 8:35 pm

AtariZoll wrote:Btw. there is strange problem with Pasti imager and floppies with certain sector gaps - will not detect sectors at all . While Steem STT imager detects sectors well on same floppies. I will investigate it more when catch some time - it may be the reason for some not successfull STX imagings, and my Track copy SW suffers from same problem.


It's too bad that Pasti isn't updated anymore when you consider the impressive body of disk images at atarimania for example, and the 3 actively developed ST emulators. But maybe this is for another topic.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Tue May 21, 2013 6:34 pm

Sentinel revisited
Image

Recognise this screen? This is Automation 001, when it was still called LSD/Was (Not Was). There has long been a problem in emulators with the 7th game, Sentinel.

In fact there were two problems, a slow mouse issue, already fixed in Steem since v3.4, and a stranger issue where the mouse was stuck on the bottom of the screen, which only existed in this version of the game, and only in TOS1.02.

Running some tests I realised that...

Image


As of v3.5.1, the Automation version will also work provided you select slow disk drive option. This is correct emulation.

That was the problem, who would have thought?
Image

Another screenshot to celebrate the closing of a quite frustrating case.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
npomarede
Atari God
Atari God
Posts: 1239
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Coming soon! Steem SSE 3.5

Postby npomarede » Sat May 25, 2013 1:46 pm

Steven Seagal wrote:The value for Steem 3.5.1 is: 13716 T


Edit: seeing the post by Sonus below, I changed parameter to get 12736 T, closer.


Hello
just wondering, what is affected in the FDC by this parameter you changed ? I mean, dma transfer should have a fixed value anyway, as well as computing the current position on the spinning disk relative to the index. So, is this a constant delay you add at the start of each "read sector" command ?
Did you check if modifying this parameter changed the duration of the STNICCC demo by Leonard ?

Nicolas

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sun May 26, 2013 8:36 am

npomarede wrote:
Hello
just wondering, what is affected in the FDC by this parameter you changed ? I mean, dma transfer should have a fixed value anyway, as well as computing the current position on the spinning disk relative to the index. So, is this a constant delay you add at the start of each "read sector" command ?
Did you check if modifying this parameter changed the duration of the STNICCC demo by Leonard ?

Nicolas


The parameter is a little hack after the read, before IRQ, that IMO compensates imprecision due to counting drive timings in HBL in Steem, but it changes very little for that demo, it's just for the test program.

In v3.5.1, drive timings are computed using the following table:

Code: Select all


Bytes per rotation = 6250+40

from JLG, floppy disk gaps

# bytes
Name                       9 Sectors  10 Sectors  11 Sectors     Byte
Gap 1 Post Index                  60          60          10      4E

Gap 2 Pre ID                    12+3        12+3         3+3     00+A1
Gap 3a Post ID                    22          22          22      4E
Gap 3b Pre Data                 12+3        12+3        12+3     00+A1
Gap 4 Post Data                   40          40           1      4E

Gap 5 Pre Index                  664          50          20      4E


    Note that the index position can be anywhere when the disk begins
    to spin.


I know I'm bragging but I think it has become quite accurate, at least in behaviour.
The +40 is a bit arbitrary, but more than 6250 bytes/track is the key to satisfying emulation for both the demo and MPS Golf.
Note that in Steem 3.2, the value was 8000 for some strange reason.


...
About Steem SSE 3.5.1, a little delay will be needed before release, it's still too buggy (not drive, but ACIA).
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Coming soon! Steem SSE 3.5

Postby DrCoolZic » Sun May 26, 2013 10:18 am

Steven Seagal wrote:In v3.5.1, drive timings are computed using the following table:

Code: Select all


Bytes per rotation = 6250+40

from JLG, floppy disk gaps

# bytes
Name                       9 Sectors  10 Sectors  11 Sectors     Byte
Gap 1 Post Index                  60          60          10      4E

Gap 2 Pre ID                    12+3        12+3         3+3     00+A1
Gap 3a Post ID                    22          22          22      4E
Gap 3b Pre Data                 12+3        12+3        12+3     00+A1
Gap 4 Post Data                   40          40           1      4E

Gap 5 Pre Index                  664          50          20      4E


    Note that the index position can be anywhere when the disk begins
    to spin.


I know I'm bragging but I think it has become quite accurate, at least in behaviour.
The +40 is a bit arbitrary, but more than 6250 bytes/track is the key to satisfying emulation for both the demo and MPS Golf.
Note that in Steem 3.2, the value was 8000 for some strange reason.

In this table ( http://info-coach.fr/atari/software/FD- ... 2B_formats) I only give "standard" values for the gap. In reality different values are often used. But for timing these values should be close enough.

About Steem SSE:
As most everybody I admire the work you are doing on Steem. As you may remember I have done some experiment on Steem source (http://info-coach.fr/atari/software/projects/steem.php) to compile with Microsoft Visual C++ compilers and to cleanly split the .h and .cpp files.

But I am totally puzzled that you are building Steem using compilers from the previous millennium. VC6 and BCC55 are not maintained dinosaurs that do not respect C++ definitions and do not generate optimized code for recent processors.

I have just started yesterday to look at modifying your latest published code to compile on Microsoft Visual C++ 2012 (the express version of the compiler is available for free). Each new release of this Compiler provides better detection of possible errors and more optimized code generation. For example a preliminary compilation of the code from source forge trunk (3.5.0?) gives about 500 warnings (from just informative information about performance penalties to usage of uninitialized variables…).

I will try first to do minimum modifications so it compiles without error under VC++2012 because I am interested in the IPF reading feature you have added as I have done some work on Kryoflux (http://info-coach.fr/atari/software/pro ... yoflux.php - I have my own version of the 1772) and IPF (http://info-coach.fr/atari/software/projects/IPF.php).

Possible next step would be to split the code correctly (see http://info-coach.fr/atari/software/pro ... ion%20.pdf) because the current organization of the code breaks a lot of the basic features of modern IDE like VC2012.
This is not a complex task but it takes time to do it cleanly (about 2 weeks if I remember well on your version 3.3). It probably only make sense if you are interested because it would be stupid to maintain many different branches of Steem. However when I have done this work I have completely ignored the Linux code because it add much more works and it does not seem that anybody is using a Linux version of Steem. For information I have an unpublished version of my Steem sources that completely removes the Linux code as well as not used conditional code (for example ONE_GAME which does not compile clean). This results in a much more clean and readable code (note I have also added Doxygen documentation).
Let me know what you think.

User avatar
npomarede
Atari God
Atari God
Posts: 1239
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Coming soon! Steem SSE 3.5

Postby npomarede » Sun May 26, 2013 10:47 am

DrCoolZic wrote:I will try first to do minimum modifications so it compiles without error under VC++2012 because I am interested in the IPF reading feature you have added as I have done some work on Kryoflux (http://info-coach.fr/atari/software/pro ... yoflux.php - I have my own version of the 1772) and IPF (http://info-coach.fr/atari/software/projects/IPF.php).

Hello, about the KF tools you wrote, have you considered writing a tool that would convert a standard ST/MSA to an IPF file with standard GAP ? (as there would be no protection info required, the IPF file should be rather "standard" to produce).
Having a way to convert ST/MSA to IPF would be interesting to compare disk timings of all mode of FDC emulation (internal, pasti, IPF) and help reaching a more accurate result.

Nicolas

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sun May 26, 2013 12:21 pm

DrCoolZic wrote:About Steem SSE:
As most everybody I admire the work you are doing on Steem. As you may remember I have done some experiment on Steem source (http://info-coach.fr/atari/software/projects/steem.php) to compile with Microsoft Visual C++ compilers and to cleanly split the .h and .cpp files.

But I am totally puzzled that you are building Steem using compilers from the previous millennium. VC6 and BCC55 are not maintained dinosaurs that do not respect C++ definitions and do not generate optimized code for recent processors.


For our purpose modern C++ definitions aren't very important, we mainly use "C with classes".
We want compatible binary code.
It should be possible to add compilers without breaking others.

I have just started yesterday to look at modifying your latest published code to compile on Microsoft Visual C++ 2012 (the express version of the compiler is available for free). Each new release of this Compiler provides better detection of possible errors and more optimized code generation. For example a preliminary compilation of the code from source forge trunk (3.5.0?) gives about 500 warnings (from just informative information about performance penalties to usage of uninitialized variables…).

I will try first to do minimum modifications so it compiles without error under VC++2012 because I am interested in the IPF reading feature you have added as I have done some work on Kryoflux (http://info-coach.fr/atari/software/pro ... yoflux.php - I have my own version of the 1772) and IPF (http://info-coach.fr/atari/software/projects/IPF.php).


I thought you would volunteer to help with this, as you seemed much interested. You left me all the glory.
But the work was more one of integrating features in the existing Steem system, the reading is done by the DLL, a "black box" if you will.

Possible next step would be to split the code correctly (see http://info-coach.fr/atari/software/pro ... ion%20.pdf) because the current organization of the code breaks a lot of the basic features of modern IDE like VC2012.


As it is though, VC6 finds variables, functions and classes.
This is not a complex task but it takes time to do it cleanly (about 2 weeks if I remember well on your version 3.3). It probably only make sense if you are interested because it would be stupid to maintain many different branches of Steem.


I plan to do it myself after the release of v3.5.1.


However when I have done this work I have completely ignored the Linux code because it add much more works and it does not seem that anybody is using a Linux version of Steem.


There are users and of course I keep a Unix build.


For information I have an unpublished version of my Steem sources that completely removes the Linux code as well as not used conditional code (for example ONE_GAME which does not compile clean). This results in a much more clean and readable code (note I have also added Doxygen documentation).



I'm not too sure about Doxygen documentation, maybe make it a separate issue (I know nothing of it, simply).
Steem SSE source will never be clean because all old code and comments are kept, all mods are protected by directives (eg SS_IPF for IPF support).

Code: Select all

int ExtensionIsDisk(char *Ext,bool returnPastiDisksOnlyWhenPastiOn)
{
  if (Ext==NULL) return 0;

  if (*Ext=='.') Ext++;
  int ret=0;
  if (MatchesAnyString_I(Ext,"ST","STT","DIM","MSA",
#if defined(STEVEN_SEAGAL) && defined(SS_IPF)
    "IPF",
#endif   
    NULL)){
    ret=DISK_UNCOMPRESSED;
  }else if (MatchesAnyString_I(Ext,"STZ","ZIP",NULL)){
...


Compile switches are life-savers when something is broken.


Let me know what you think.


I welcome any help, but we must break nothing. The best is that you have a look after the release of v3.5.1 (I haven't uploaded since 3.5.0 Unix, I'm afraid). When you do you'll be happy to find some of your doc in the drive emulation code (like the table above).
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Coming soon! Steem SSE 3.5

Postby DrCoolZic » Sun May 26, 2013 12:23 pm

npomarede wrote:Hello, about the KF tools you wrote, have you considered writing a tool that would convert a standard ST/MSA to an IPF file with standard GAP ? (as there would be no protection info required, the IPF file should be rather "standard" to produce).
Having a way to convert ST/MSA to IPF would be interesting to compare disk timings of all mode of FDC emulation (internal, pasti, IPF) and help reaching a more accurate result.

Nicolas

First of all as you may have notice I have been away from Atari stuff because I had other priorities :)

To reply to your question: No I did not think of having ST/MSA to IPF conversion, but I have considered having an STX to IPF and IPF to STX converter. I have spent quite some time looking at the STX format and I found several information not documented. I have contacted Ijor and asked questions but unfortunately he had not enough time to answer all of them so there are still some open issues.

I have a problem with IPF in general. I am not sure that SPS people are spending enough time regarding support for Atari. I have submitted about 100 dumps of games with Kryoflux in 2011 and I have never received any IPF file in return :(
The IPF format is very nice, powerful, expandable, … (info here http://forum.kryoflux.com/viewtopic.php?f=7&t=365) but unfortunately the only “official” way of generating IPF files is by SPS people only. For that matter they used a semi-automatic software that analyze the FD information at the flux level and look for matching protection mechanism in a predefined set (this is an extremely simplified explanation look at SPS site for more info). The resulting IPF file can be used for writing FD (allowing perfect backup like it was possible with the Discovery Cartridge http://info-coach.fr/atari/hardware/devices/dc.php) or for emulation.

For FD write you need a “perfect” IPF file to get back a working FD, but I believe that it is less important for emulation. This is where it should be possible to write IPF files from ST/MSA/STX as it is done for Amiga (http://forum.kryoflux.com/viewtopic.php?f=7&t=324).

The way protection is handled in IPF is interesting: My approach about protection is to analyze (sometimes at the flux level http://info-coach.fr/atari/documents/my ... ection.pdf) the FD without any knowledge of a predefined set of protections. But both IPF and STX assume a set of predefined protections and therefore the FD protection analysis consist at finding their presence. This is why I believe (need to be confirmed) that it should be possible to convert from STX (obviously with less accurate information) to a good enough for emulation IPF file.

Another piece of information: My 1772 emulation works directly from Kryoflux Stream files. This might be useful to be able to simulate directly from these files. The drawback is that Stream files are very verbose (typical 40 MB uncompressed for one FD).

Jean

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Coming soon! Steem SSE 3.5

Postby DrCoolZic » Sun May 26, 2013 12:38 pm

Steven :)
Thanks for your reply. I am not going to comment all your detailed replies.
From what you say it seems that you would be interested only by adding VC++ 2012 to the list of compilers and I think this make sense. This is what I am experimenting as we speak and it is already more challenging than with the original code.

It would be very nice if you could split the source so that we do not have any .cpp including other .cpp and with definitions in .h files. Yes classes are detected correctly but functions like finding information or debugging are not handled correctly with the current structure... and as you volunteer this is even better :lol:

For IPF it seems that you have done a very good job :cheers:

I hope that supporting VC2012 should be minimal

User avatar
npomarede
Atari God
Atari God
Posts: 1239
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Coming soon! Steem SSE 3.5

Postby npomarede » Sun May 26, 2013 12:55 pm

DrCoolZic wrote:To reply to your question: No I did not think of having ST/MSA to IPF conversion, but I have considered having an STX to IPF and IPF to STX converter. I have spent quite some time looking at the STX format and I found several information not documented. I have contacted Ijor and asked questions but unfortunately he had not enough time to answer all of them so there are still some open issues.

I thought about this when we recently saw the difficulties to run "Microprose golf" (where the game crashes because it loaded too fast both in Hatari and Steem). This required to take into account all GAPs and precise spinning position. In the meantime, I was able to get an IPF version of the game from SPS, which allowed to compare timings and see where the problem was. MP Golf has no protection on the disk (just some password check), so converting an ST/MSA version to IPF would give a close enough result to run it with the CAPS emulation of the WD1772 and compare it against Hatari/Steem internal FDC mode to see where the differences are. In that case, an IPF dump of MP Golf was available, but in the case of the ST-NICCC demo (which also showed some bad timings), being able to build an IPF file could be interesting to see if all FDC emulation modes are now using similar timings.

I have a problem with IPF in general. I am not sure that SPS people are spending enough time regarding support for Atari. I have submitted about 100 dumps of games with Kryoflux in 2011 and I have never received any IPF file in return :(
The IPF format is very nice, powerful, expandable, … (info here http://forum.kryoflux.com/viewtopic.php?f=7&t=365) but unfortunately the only “official” way of generating IPF files is by SPS people only. For that matter they used a semi-automatic software that analyze the FD information at the flux level and look for matching protection mechanism in a predefined set (this is an extremely simplified explanation look at SPS site for more info). The resulting IPF file can be used for writing FD (allowing perfect backup like it was possible with the Discovery Cartridge http://info-coach.fr/atari/hardware/devices/dc.php) or for emulation.

I have the feeling that converting disks is really the slow part of the process. But apart from that I managed to get positive answers from them on various subjects, sometimes with delay, but always constructive. At the moment, I guess C64 and some other platforms are more maintained because they were historically developed before the ST archiving process began.

Nicolas

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Coming soon! Steem SSE 3.5

Postby Steven Seagal » Sun May 26, 2013 3:10 pm

npomarede wrote:I have the feeling that converting disks is really the slow part of the process. But apart from that I managed to get positive answers from them on various subjects, sometimes with delay, but always constructive. At the moment, I guess C64 and some other platforms are more maintained because they were historically developed before the ST archiving process began.

Nicolas


Then you're fortunate because I was extremely disappointed in their response to my inquiries and suggestions, they more or less sent me off and I could implement IPF support on my own. I had the feeling they didn't care.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Coming soon! Steem SSE 3.5

Postby DrCoolZic » Sun May 26, 2013 4:56 pm

Steven,
Sorry to bother I must do something stupid but I have problems with CAPS :(
First in the source on sourceforge two include files CapsLib.h and Comlib.h are missing from the 3rdparty/caps directory ???
Where did you get the files in this directory? from ipfdevlib_win32, from ipfdevlib_win_x64, from ipf_source4.2 ? or a combination ???
I am stuck with a linker error (compilation now goes through :) ) LNK1104 cannot open file ../../caps/CAPSIMG.lib and whatever I try fails :( this is driving me nuts :cry:
Not even sure if linker is trying to read or write this file :roll:


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 1 guest