Steem SSE 3.7 bug reports

[kodak80]

Hi Steven,

I thought one of my SCP images was duff as it crashes in Steem 3.7.1. The game is I Ludicrus (disk 1). I thought the SCP image was duff but the image works when I copy it back to a real floppy disk. When I convert the SCP image to STX using AUFIT, the STX works fine in Steem.

Here is discus 1 SCP:
https://mega.co.nz/#!IR9mRRya!ZXUxtxG5R ... I_2KQv19bk

[Steven Seagal]

It happens because an ID address mark $FE is right on the index pulse.
Thx for the report.

[Steven Seagal]

For this problem of "data over IP", Steem will use a new tactic, that works with this case, Leavin' Teramis and Turrican.

- We always switch from rev1 to rev2 when going over index pulse, so emulation is bit precise
- We reload rev1 as soon as possible (in find ID phase when the AM detector is enabled)

That way, 2 revs are enough.

This implies:
- 2 revs or 1 perfect rev for Steem
- some more file IO when 2 revs

[bjjones37]

The HD image option of pasti works just fine on STeem SSE 3.7.1 with all version of TOS I tested with one minor exception. If I set the option "Pasti only for STX" when using TOS 2.06 (and 2.05), my hard drive image is disabled. I works fine with the other TOS versions. Is this maybe a peculiarity of TOS 2.06? Seems odd it would work with TOS 1.62 on down (did not try 1.0 actually, seemed pointless) but not 2.06 (or 2.05).

[Steven Seagal]

Yes there was another bug report about HD emu and TOS 2.0x, but not pasti.
I'm not sure Steem should handle TOS 2, the scope is STF + STE, were there plain vanilla STE with TOS2?

[bjjones37]

The Pasti mode does not allow me to use 1.4MB floppy image files which is a minor inconvenience. But PLEASE do not remove the the TOS 2.0x option. I have a MegaSTE and this is one of my favorite emulation modes in STeem. I probably spend more time with it than any other.

Incidentally, does the blitter option in TOS 2.06 do anything at all in STeem? Is there any benefit in using it or should I just ignore it?

I know this is a bit off topic, but I have never actually seen an SS movie. Could you recommend one for a first time viewer?

[Steven Seagal]

I know this is a bit off topic, but I have never actually seen an SS movie. Could you recommend one for a first time viewer?

They're all good if you like "B" or even "Z" movies.
My favourite is Fire Down Below. Fans generally prefer Out For Justice.

[kodak80]

Not sure if I have found a bug or if this is a cofiguration setting issue but I cannot boot IPF images in Steem. I have the capsimg.dll in the directory with the Steem.exe

I am correct in thinking Steem supports IPF disk images?

I am running Steem on Windows 8.1 64 bit.

Another issue I am not sure is really a bug is working SCP files that don't work in a real ST. I have converted some STX files to SCP files using HxC floppy emulator. Sometimes these SCP files work when written back to floppy sometimes they don't. I have a couple that don't work on my ST but do work in Steem. They are Sleepwalker by Ocean and Goblins 2. I am only raising this because it seems Steem is not truly emulating the disk side of things with these SCP images as they should not work. Here are the converted STX to SCP files:
https://mega.co.nz/#!BYskhI4D!G_yZ1k3ih ... JKkYKx4AHQ
https://mega.co.nz/#!EAF3CJIT!zTirb20v3 ... En5n1mqobY

[Steven Seagal]

Not sure if I have found a bug or if this is a cofiguration setting issue but I cannot boot IPF images in Steem. I have the capsimg.dll in the directory with the Steem.exe

I am correct in thinking Steem supports IPF disk images?

I am running Steem on Windows 8.1 64 bit.

Yes it still works with v3.7.1, at least on Vista/32bit.
I know nothing of 32 vs 64bit but did you put the right DLL in?
Do you get a message? Does it fail with CTR files? Did you try previous versions of Steem?

Another issue I am not sure is really a bug is working SCP files that don't work in a real ST. I have converted some STX files to SCP files using HxC floppy emulator. Sometimes these SCP files work when written back to floppy sometimes they don't. I have a couple that don't work on my ST but do work in Steem. They are Sleepwalker by Ocean and Goblins 2. I am only raising this because it seems Steem is not truly emulating the disk side of things with these SCP images as they should not work. Here are the converted STX to SCP files:
https://mega.co.nz/#!BYskhI4D!G_yZ1k3ih ... JKkYKx4AHQ
https://mega.co.nz/#!EAF3CJIT!zTirb20v3 ... En5n1mqobY

You're upset because it works... I'll see what I can do to make it miserably fail

[kodak80]

I re-downloaded the capsimg.dll library and the 32bit capsimg.dll works fine now. Looking at the size of the x64 dll, this was the one I had in with the Steem.exe! I have the 32bit version of Steem so this makes sense. I had copied the dll from the 64bit Hatari folder! Anyway, works now. My bad.

Sorry, I would rather that these SCP images fail as this would be the true disk emulation. Maybe you could have a settings option to still allow them to work and the end-user can choose which they want?

[avtandil]

Dear Steven,

again we found some bug in the border between STeem and EMUTOS -
loaded *.ACC files are not showing while they are in the root of C: (they working OK from disk A:).

People reported that in AranyM and Hatari everything is working perfect.
Also it is working while STeem is runnng normal TOS (latest pic).

Could you please have a look from your side ?

Please see attached pics.

Dima-

emutos.jpg

Disk_A.jpg

tos102.jpg

[Steven Seagal]

again we found some bug in the border between STeem and EMUTOS -
loaded *.ACC files are not showing while they are in the root of C: (they working OK from disk A:).

Thx for the report, this is the opportunity to anticipate on the "coming soon" thread.

When Steem uses your PC hard disk directories as if it were an ST disk, we call it GEMDOS emulation because it is based on TRAP interception.
This is a gigantic hack. It relies on TOS behaviour. If EMUTOS behaves another way, some hacks won't work.
But this isn't real emulation, and those aren't real bugs.

When Steem (future version) uses an image file of an Atari hard disk, we call it ACSI emulation, based on the name of the SCSI-like interface.
It is straightforward and low-level (IO level), and real emulation, because on the Atari, the controller was in charge of everything. The interface is almost only reading/writing absolutely indexed sectors.
EDIT: And what is on those sectors, including partition table, FAT and directory, is the business of TOS and drivers.
ACSI emulation doesn't rely on TOS behaviour. If it works on a real ST, it should work in Steem, including EMUTOS.

In future version, GEMDOS emulation will be restricted to Atari TOS 1.04 and 1.62, because the hacks fortunately work with those.
For other TOS, you'll need to use ACSI emulation.

[avtandil]

again we found some bug in the border between STeem and EMUTOS -
loaded *.ACC files are not showing while they are in the root of C: (they working OK from disk A:).

Thx for the report, this is the opportunity to anticipate on the "coming soon" thread.

When Steem uses your PC hard disk directories as if it were an ST disk, we call it GEMDOS emulation because it is based on TRAP interception.
This is a gigantic hack. It relies on TOS behaviour. If EMUTOS behaves another way, some hacks won't work.
But this isn't real emulation, and those aren't real bugs.

When Steem (future version) uses an image file of an Atari hard disk, we call it ACSI emulation, based on the name of the SCSI-like interface.
It is straightforward and low-level (IO level), and real emulation, because on the Atari, the controller was in charge of everything. The interface is almost only reading/writing absolutely indexed sectors.
EDIT: And what is on those sectors, including partition table, FAT and directory, is the business of TOS and drivers.
ACSI emulation doesn't rely on TOS behaviour. If it works on a real ST, it should work in Steem, including EMUTOS.

In future version, GEMDOS emulation will be restricted to Atari TOS 1.04 and 1.62, because the hacks fortunately work with those.
For other TOS, you'll need to use ACSI emulation.

Does it mean that on all latest EMUTOS version (they are mentioned as TOS 2.06 by their functionality) would be impossible to use GEMDOS emulation ?

If so, it's a big pity, because using real HDD folder is much more confortable. And also Hatari guys found suitable solution for that, so maybe you can check their way.

I still like to stay with STeem, as it really becoming great, so I hope you will find the solution for GEMDOS way of HDD emulation at least for TOS 2.06 (seems that all above versions for the moment using only ASCI emulation).

[Steven Seagal]

Does it mean that on all latest EMUTOS version (they are mentioned as TOS 2.06 by their functionality) would be impossible to use GEMDOS emulation ?

Yes, that's an implication.

If so, it's a big pity, because using real HDD folder is much more confortable. And also Hatari guys found suitable solution for that, so maybe you can check their way.

Maybe EMUTOS targets/is tested against Hatari and not Steem.
If you check their sourceforge page:

http://emutos.sourceforge.net/en/

there's mention of ARAnyM, STonX, Hatari, not Steem.

[avtandil]

Does it mean that on all latest EMUTOS version (they are mentioned as TOS 2.06 by their functionality) would be impossible to use GEMDOS emulation ?

Yes, that's an implication.

If so, it's a big pity, because using real HDD folder is much more confortable. And also Hatari guys found suitable solution for that, so maybe you can check their way.

Maybe EMUTOS targets/is tested against Hatari and not Steem.
If you check their sourceforge page:

http://emutos.sourceforge.net/en/

there's mention of ARAnyM, STonX, Hatari, not Steem.

There is a fact, that EMUTOS people are mostly *nix thinking, so that's why they prefer Hatari as multiplatform emulator.
But for me STeem is much more attractive and I made lots of effort with MIDI implementation in bros Hayward times, so you can believe, that I made strong tests as I prefer to stay with STeem.

And it would be nice to make possible also use this feature with EMUTOS, as despite of Atari real TOSes it still developing and improving.

Last time you found a bug in EMUTOS regarding *.RSC recognizing while not in C: root, maybe recognizing *.ACC files in the root of C: in another small thing, which is important for STeem, but could work with other emulators ?
I mostly rely to Hatari, because AFAIK AranyM is always working only with HDD images.

[Steven Seagal]

If it had been up to me, there wouldn't be any GEMDOS emulation.

Those (not enabled) switches show my sinister intentions:

Code: Select all

//#define DISABLE_STEMDOS
//#define DISABLE_STEMDOS2//TODO


So instead I try to limit to what is known to work.

Here's part of the next "coming soon" screen (anticipating):

When I see the simplicity of ACSI emulation compared with the GEMDOS way, I wonder if we, collectively, shouldn't have gone another way. Of course, it is very convenient as it is, but the ideal way would maybe have been to use a 3rd party file manager to edit ST floppy and hard disk images, and emulators would only handle simple image files.

(GEMDOS code, rather confusing and fragile)
http://sourceforge.net/p/steemsse/code/HEAD/tree/trunk/steemsse/steem/code/stemdos.cpp
(ACSI code, rather simple and effective)
http://sourceforge.net/p/steemsse/code/HEAD/tree/trunk/steemsse/steem/code/SSE/SSEAcsi.cpp

edit: no offense to Steem authors, it's because of the task (a big hack) that code is like that

[avtandil]

again we found some bug in the border between STeem and EMUTOS -
loaded *.ACC files are not showing while they are in the root of C: (they working OK from disk A:).

Thx for the report, this is the opportunity to anticipate on the "coming soon" thread.

When Steem uses your PC hard disk directories as if it were an ST disk, we call it GEMDOS emulation because it is based on TRAP interception.
This is a gigantic hack. It relies on TOS behaviour. If EMUTOS behaves another way, some hacks won't work.
But this isn't real emulation, and those aren't real bugs.

When Steem (future version) uses an image file of an Atari hard disk, we call it ACSI emulation, based on the name of the SCSI-like interface.
It is straightforward and low-level (IO level), and real emulation, because on the Atari, the controller was in charge of everything. The interface is almost only reading/writing absolutely indexed sectors.
EDIT: And what is on those sectors, including partition table, FAT and directory, is the business of TOS and drivers.
ACSI emulation doesn't rely on TOS behaviour. If it works on a real ST, it should work in Steem, including EMUTOS.

In future version, GEMDOS emulation will be restricted to Atari TOS 1.04 and 1.62, because the hacks fortunately work with those.
For other TOS, you'll need to use ACSI emulation.

I still think that something is wrong here between STeem and EMUTOS - look, 192 K of latest EMUTOS (which is labeled as TOS 1.02) also not showing loaded *.ACC fies, while with STeem and real TOS 2.06 it working OK, so maybe it is not a question of TOS version ?

And all other GEMDOS HDD emulation features for me are working OK with TOS 2.06 , isn't it ?

[Steven Seagal]

Instead of disabling GEMDOS emulation on other TOS than Atari 1.04, 1.62, Steem will just warn you:

GEMDOS_TOS_warning.png

Or something like this, it may change before release.

But I won't investigate EMUTOS issues anymore, that project supports other emulators.

[avtandil]

Instead of disabling GEMDOS emulation on other TOS than Atari 1.04, 1.62, Steem will just warn you.

Or something like this, it may change before release.

Great ! I think it would be te best - do not limit some fuction but just warn the user.

But I won't investigate EMUTOS issues anymore, that project supports other emulators.

I will investigate this, don't think it was intention to exclude STeem from list of emulators, just typo.

[kodak80]

When I have a pasti.dll enabled in the SteemSSE folder, Kryoflux CTR & IPF files don't seem to load for me? If I rename the DLL and disable pasti STX ability CTRs & IPFs load fine.

I have tried downloading and replacing the capsimg.dll but this makes no difference with this issue.

Anyone else come across this issue or am I doing something wrong? I have tried both versions on the pasti DLL from the Steem site and have the same issue with both.

I am running the latest 3.7.2 version of Steem SEE.

**** UPDATE ****
I have now fixed this issue. I have ticked the option "Pasti only for STX"!

I am surprised that Steem is attempting to use the pasti.dll for IPF and CTR files?

[Steven Seagal]

**** UPDATE ****
I have now fixed this issue. I have ticked the option "Pasti only for STX"!

I am surprised that Steem is attempting to use the pasti.dll for IPF and CTR files?

This option is recommended.
If it's not checked, [EDIT: and 'use Pasti' is checked, of course] all floppy images are sent to Pasti, even those it can't handle.
Normally Steem has better emulation of ST, MSA now, but it was not the case before.
I'll fix this for CTR, IPF, STW, HFE in next version.

[kodak80]

**** UPDATE ****
I have now fixed this issue. I have ticked the option "Pasti only for STX"!

I am surprised that Steem is attempting to use the pasti.dll for IPF and CTR files?

This option is recommended.
If it's not checked, all floppy images are sent to Pasti, even those it can't handle.
Normally Steem has better emulation of ST, MSA now, but it was not the case before.
I'll fix this for CTR, IPF, STW, HFE in next version.

OK. Thanks.

[avtandil]

But I won't investigate EMUTOS issues anymore, that project supports other emulators.

Glad to inform you that *.ACC correct loading in EMUTOS under STeem was fixed by EMUTOS team. Also drive C: is now showed in the list of drives on a EMUTOS Welcome screen.

And the question about STeem support was raised on the relevant forum, and STeem support (to be exact SSE) was already added.

[BlankVector]

It seems that Atari-Forum does not send email notifications anymore
As a result, I just discover the new messages on this topic.
Definitely, there are a few misunderstandings, so I need to restore the truth.

There is a fact, that EMUTOS people are mostly *nix thinking, so that's why they prefer Hatari as multiplatform emulator.

This is wrong.

I had been the EmuTOS project manager for last 5 years, until recently. I can assure you that Windows is my preferred operating system for daily usage. I also know Linux quite well. Both are not mutually exclusive.

Furthermore, Steem is my favorite STe emulator. I started using it long ago, long before I knew ARAnyM, Hatari, or even EmuTOS. I use ARAnyM for FreeMiNT stuff because it is fast. I use Hatari because it has accurate emulation for ST/TT/Falcon as well as many custom options like CPU type which are useful for EmuTOS testing. And I use Steem for other ST stuff, because it is nice. With the limitation of the GEMDOS hard drive emulation bugs, which are fortunately fixed now.

So please don't say wrong things as a generality.

EmuTOS is just software which expects accurate hardware emulation, like games and demos. It doesn't care about which emulator is used, provided that the emulation is accurate. Of course, if the emulator has extra features, EmuTOS can gladly use them. This is why cooperation between projects is essential.

NB: Of course, other EmuTOS developers or users may have different preferences than mine. But since I was the boss for last 5 years I feel a bit concerned when you speak globally about "EMUTOS people".

Maybe EMUTOS targets/is tested against Hatari and not Steem.

EmuTOS targets real Atari hardware (and more) thus any emulator. I always test EmuTOS releases with Steem, but testing was limited due to that GEMDOS hard drive emulation bug.

The real question is:
Why wasn't that EmuTOS/Steem GEMDOS hard drive emulation bug fixed long ago?

There are several reasons:

1) Not so long ago, Steem was closed source and an abandoned project. There was a bug between EmuTOS and Steem, and no clue to identify what was wrong. And no chance to get the bug fixed if it was on Steem side. So EmuTOS testing focused on other Free emulators.

2) Then Steem sources were open sourced. We could have looked at the sources to try to understand what was wrong, but due to lack of time and other priorities, we didn't do that.

3) Then Steem SSE appeared, with active support from Steven. Dumbly, I missed that information. Then, due to lack of time, I never took the time to try Steem SSE and investigate that bug - until a few days ago.

Fortunately, the bug is now fixed (see below).

If you check their sourceforge page:

http://emutos.sourceforge.net/en/

there's mention of ARAnyM, STonX, Hatari, not Steem.

This was true. Because that page was old and rarely updated. And also because of that bug, it was not a good idea to advertise Steem too much (to avoid too many bug reports like the ones tainting this topic). However, there was a link to legacy Steem on the links page.

Anyway, since the bug is now fixed, I have updated the above page. You can see that Steem is now at the right place, near other actively developed emulators.

But I won't investigate EMUTOS issues anymore, that project supports other emulators.

You have just seen this was a wrong interpretation of the facts.
I sincerely hope that we will continue the cooperation between our projects.

Now the facts about the GEMDOS hard drive emulation bug. Actually there was 2 bugs, and both have been fixed in EmuTOS.

1) EmuTOS Fdup() bug. Many thanks, Steven, to have spotted that. This prevented some files to be accessed from C:, particularly resource files.

2) Wrong detection of C: as boot drive. It prevented C: to be listed on the EmuTOS welcome screen, and to be set as boot drive. So AUTO programs and accessories were not loaded from C:. By reading the Steem SSE sources, I saw that Steem C: was initialized on the first call to BIOS Drvmap(). In EmuTOS, that call was made too late, while it was done earlier in Atari TOS. So I added an early call to Drvmap() in EmuTOS, and that immediately fixed the problem.

So there is no more bug between Steem and EmuTOS regarding to GEMDOS hard drive emulation
This is the power of Free Software: anything can be fixed, it is just a matter of time.

This fix will be part of the next EmuTOS release, and will certainly be a main feature.
Meantime, you can test the fix in the latest EmuTOS snapshot:
http://sourceforge.net/projects/emutos/ ... /20150825/

As usual, the emutos-256k-*.zip archive is the right one for Steem. Just extract the ROM of your favorite language.

Enjoy EmuTOS on Steem SSE

[Steven Seagal]

Thx for the clarification. My impression was that EmuTOS was more into Unix/Hatari, those other emulators I don't know, excluding Steem. It was based on the info I had.

GEMDOS HDD can't be accurate emulation, it's a collection of hacks, both in Steem and Hatari, just different hacks.
With ACSI emulation, there's no problem with older EmuTOS.

For example, drive map is stored by TOS on $4C2 after its boot tests. Since you can't set this variable on reset, Steem authors chose an appropriate step in Atari TOS init, call to Drvmap(), as you have seen, which was reasonable.
I will correct this in next version, Steem function stemdos_update_drvbits() will be called on non-intercepted new GEMDOS HDD commands.
Anyway, as you say, Steem now works with the "snapshot" versions of EmuTOS, both 192K for STF and 256K for STE, with or without that fix, so that's fine. On v0.9.4, apparently there's still a Fdup() issue, don't know if that's supposed to be. Fdup() is essential for Steem's hacks.

Apparently, Fdup() was an EmuTOS issue, $4C2 a Steem issue.

There remains a "problem", Steem SSE checks TOS version when GEMDOS HD emu is enabled and emits a warning if it's not 1.04 or 1.62, so it does on EmuTOS.