I have a problem with my mouse. I have noticed this in Windows 7, 8.0, 8.1, and 10 (recently upgraded). When Steem is in windowed mode the mouse wants to scroll to the right or left until it reaches the end of the window. I have not had this problem in Windows XP. It seems to affect every version of STeem including 3.1 and 3.2. Is any way to calibrate the mouse in steem so this does not happen?

Hmm, hasn't happened yet with me (I use up to 7).Do you mean the ST cursor or the PC?Is option C1 checked? Are you moving the mouse or does it start by itself?Is it all the time?There's an option for mouse speed in the joystick form.

Steven Seagal wrote:My impression was that EmuTOS was more into Unix/Hatari

By thinking twice, I believe that most EmuTOS contributors are indeed Linux users, except myself.

AFAIK, Hatari is the only ST/STe emulator currently developed for Linux. Thus, it is the only way to play ST games on an up-to-date emulator, then eventually to get support from developers. Also, Hatari is shipped with EmuTOS, as a Free and ready-to-use package. I don't know if XSteem still works on Linux.

ARAnyM is probably the most popular emulator using EmuTOS (Windows, Linux and MacOS). But in that case, EmuTOS is just used as boot stub to start FreeMiNT. ARAnyM partially emulates Falcon hardware, but it is mainly useful for FreeMiNT thanks to its high speed and software extensions.

Steven Seagal wrote:GEMDOS HDD can't be accurate emulation, it's a collection of hacks, both in Steem and Hatari, just different hacks.

This is totally true.

On the other hand, for end users, it is a killer feature. That's certainly the easiest way to setup a pseudo hard-disk and to exchange data between the host and the emulated system. Also, for people like me who like cross-compilation (edit files and compile on Windows, then run on an emulator), GEMDOS hard drive emulation is definitely THE feature I need.

Modern virtualization software also provide similar solution (such as VMware virtual folders), even if in that case the host folder appears as a network share instead of a hard drive.

Yes.ACSI emulation is perfect emulation of real hardware, and must be supported for complete emulation. EmuTOS supports ACSI disks (and more) so that will work as expected.But emulators can be better than real hardware by providing extra features, such as GEMDOS hard drive emulation.

Regarding to "older EmuTOS", be sure that when a new EmuTOS is released, we don't care about old versions. We work hard to make new EmuTOS releases better than older ones, without regression. So all users have interest to upgrade.

The current EmuTOS release is 0.9.4. Since it has been released 6 months ago, before this story, it contains the Steem issues.

Snapshots (intermediate builds) are built from time to time from the current Git sources, so users can easily test the current developments. As you saw, all the Steem issues are gone in the latest snapshot.

Next release will be 0.9.5, and should be out in a couple of months. It will be similar to the latest snasphot, without Steem issue. Be sure that support for Steem GEMDOS hard drive emulation will be a main feature.

So regarding to EmuTOS releases, the Steem issues will stay around for the 2 next months, then they will only be old stories.

Steven Seagal wrote: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.

Indeed, this message is no more relevant regarding to EmuTOS.Of course, with cooperation between Steem and EmuTOS teams, we can ensure that this will always continue to work.

Detecting EmuTOS is easy. Look at the ROM header. If the 4 bytes at offset $2C are 'ETOS', then that's an EmuTOS ROM.If you like, I can contribute to Steem with a patch to check that.

NB: The TOS version bytes are not relevant in EmuTOS, currently they are arbitrarily either 1.02 or 2.06 depending on the ROM type.

Steven Seagal wrote:Hmm, hasn't happened yet with me (I use up to 7).Do you mean the ST cursor or the PC?Is option C1 checked? Are you moving the mouse or does it start by itself?Is it all the time?There's an option for mouse speed in the joystick form.

Actually I just realized that the problem does not seem to arise with STeem 3.7.x. It was a problem with all of the other versions of STeem with 3.6.4 and down. As soon as I would start to use the mouse it would just start moving down or to the right and I could not control it very well. But 3.7.0 and up seem to have fixed it. Sorry, I am still rather new with 3.7. Been busy with the farm all summer. Looks like you took care of the full screen issue too.

Steven Seagal wrote:Hmm, hasn't happened yet with me (I use up to 7).Do you mean the ST cursor or the PC?Is option C1 checked? Are you moving the mouse or does it start by itself?Is it all the time?There's an option for mouse speed in the joystick form.

Actually I just realized that the problem does not seem to arise with STeem 3.7.x. It was a problem with all of the other versions of STeem with 3.6.4 and down. As soon as I would start to use the mouse it would just start moving down or to the right and I could not control it very well. But 3.7.0 and up seem to have fixed it. Sorry, I am still rather new with 3.7. Been busy with the farm all summer. Looks like you took care of the full screen issue too.

BlankVector wrote:AFAIK, Hatari is the only ST/STe emulator currently developed for Linux. Thus, it is the only way to play ST games on an up-to-date emulator, then eventually to get support from developers. Also, Hatari is shipped with EmuTOS, as a Free and ready-to-use package. I don't know if XSteem still works on Linux.

You're wrong on this, I maintain an Unix build of Steem SSE, albeit with fewer features, it is up-to-date emulation-wise. it's called XSteem SSE.But I can offer no support for it unfortunately.

On the other hand, for end users, it is a killer feature. That's certainly the easiest way to setup a pseudo hard-disk and to exchange data between the host and the emulated system. Also, for people like me who like cross-compilation (edit files and compile on Windows, then run on an emulator), GEMDOS hard drive emulation is definitely THE feature I need.

Right. I was almost ready to do ACSI-only but I can see many users would be dismayed.

Regarding to "older EmuTOS", be sure that when a new EmuTOS is released, we don't care about old versions. We work hard to make new EmuTOS releases better than older ones, without regression. So all users have interest to upgrade.

The current EmuTOS release is 0.9.4. Since it has been released 6 months ago, before this story, it contains the Steem issues.

Snapshots (intermediate builds) are built from time to time from the current Git sources, so users can easily test the current developments. As you saw, all the Steem issues are gone in the latest snapshot.

Next release will be 0.9.5, and should be out in a couple of months. It will be similar to the latest snasphot, without Steem issue. Be sure that support for Steem GEMDOS hard drive emulation will be a main feature.

So regarding to EmuTOS releases, the Steem issues will stay around for the 2 next months, then they will only be old stories.

OK, so that's normal for v0.9.4. I certainly hope compatibility with Steem will be a main feature of v0.9.5.

Detecting EmuTOS is easy. Look at the ROM header. If the 4 bytes at offset $2C are 'ETOS', then that's an EmuTOS ROM.

This is easy enough but can we check the version too, so Steem would warn if EmuTOS is older than v0.9.5?

bjjones37 wrote:Actually I just realized that the problem does not seem to arise with STeem 3.7.x. It was a problem with all of the other versions of STeem with 3.6.4 and down. As soon as I would start to use the mouse it would just start moving down or to the right and I could not control it very well. But 3.7.0 and up seem to have fixed it. Sorry, I am still rather new with 3.7. Been busy with the farm all summer. Looks like you took care of the full screen issue too.

Well, look now, I even fix bugs unaware. On the other hand it may be your own mouse acting up.And yes, fullscreen should work for more people now, since v3.7.

bjjones37 wrote:Actually I just realized that the problem does not seem to arise with STeem 3.7.x. It was a problem with all of the other versions of STeem with 3.6.4 and down. As soon as I would start to use the mouse it would just start moving down or to the right and I could not control it very well. But 3.7.0 and up seem to have fixed it. Sorry, I am still rather new with 3.7. Been busy with the farm all summer. Looks like you took care of the full screen issue too.

Well, look now, I even fix bugs unaware. On the other hand it may be your own mouse acting up.And yes, fullscreen should work for more people now, since v3.7.

I am pretty sure you fixed the bug as I was having the same problem on two different laptops with two separate mice. One was Windows 7 that I upgraded to 10 and the other was Windows 8.1 that I upgraded to 10. Besides 3.6.4 and below still act up on my laptop but work fine on my XP desktop. You are just too good!

bjjones37 wrote:Actually I just realized that the problem does not seem to arise with STeem 3.7.x. It was a problem with all of the other versions of STeem with 3.6.4 and down. As soon as I would start to use the mouse it would just start moving down or to the right and I could not control it very well. But 3.7.0 and up seem to have fixed it. Sorry, I am still rather new with 3.7. Been busy with the farm all summer. Looks like you took care of the full screen issue too.

Well, look now, I even fix bugs unaware. On the other hand it may be your own mouse acting up.And yes, fullscreen should work for more people now, since v3.7.

I have a further development on this Windowed mode mouse issue. I am not bothering checking the other versions, but on STeem 3.7.2 the mouse is stable on TOSes 1.02, 1.04, 1.06, and 1.62. It is unstable on TOSes 1.00, 2.05, and 2.06. I really like using TOS 2.06. Is it possible that you could release a patch for these TOSes so the mouse will be stable in Windowed mode? It is thankfully still stable in full screen mode.

HelloI can't get the "Place To Be Again" demo http://www.pouet.net/prod.php?which=20057 to work under Steem.Tested with 3.7, and all I get is a black screen and what seems to be endless reboot after 2-3 sec.Does this demo work for other people ?Nicolas

npomarede wrote:HelloI can't get the "Place To Be Again" demo http://www.pouet.net/prod.php?which=20057 to work under Steem.Tested with 3.7, and all I get is a black screen and what seems to be endless reboot after 2-3 sec.Does this demo work for other people ?Nicolas

bjjones37 wrote:I have a further development on this Windowed mode mouse issue. I am not bothering checking the other versions, but on STeem 3.7.2 the mouse is stable on TOSes 1.02, 1.04, 1.06, and 1.62. It is unstable on TOSes 1.00, 2.05, and 2.06. I really like using TOS 2.06. Is it possible that you could release a patch for these TOSes so the mouse will be stable in Windowed mode? It is thankfully still stable in full screen mode.

For the moment I have no clue as to what could cause it, especially if there's a difference window/fullscreen.

npomarede wrote:HelloI can't get the "Place To Be Again" demo http://www.pouet.net/prod.php?which=20057 to work under Steem.Tested with 3.7, and all I get is a black screen and what seems to be endless reboot after 2-3 sec.Does this demo work for other people ?Nicolas

You probably would have more success with another TOS, demo is buggy.

I managed to get it started. I confirm the demo is buggy, when you boot in STF mode, the module's replay routine will disable the timer B when setting up timer A (it's a bug in the demo...), so you don't have the correct color anymore in the screen (and not green raster at the bottom) Only solution to get a correct menu is to run the demo in STE mode, in that case the replay routine will detect the DMA sound is available, so it will not try to setup timer A (and break timer B at the same time). Crappy code indeed ...Nicolas

First of all, thanks for creating this emulator. I used to have an Atari STF a long time ago and gees this is nice...I'm a newbie at this though, and tried to get it working but with only partial success.Here is my config: Windows 10 Home running inside Hyper-V.I used the TOS102 from http://steem.atari.st/tos_uk.zip and installed the Steem engine from http://steem.atari.st/steem_v3_2.zip (although it does not say it works for Windows 10 64-bit).I can run the emulator but like the previous user posted my mouse is all over the place.Then I saw the user comment, and went online to search for the newer Steem version 3.7. Found it at: http://ataristeven.t15.org/Files/Steem. ... .Win32.zip and extracted the files over the previous install directory.Running "Steem SSE 3.7.2.exe" however gives me the following error: "The program can't start because d3dx9_43.dll is missing from your computer. Try reinstalling the program to fix this problem."

Steem was created by Anthony & Russell Hayward and I update it as "Steem SSE".

As an answer, here's part of the updated FAQ.

Q:With Windows 8 or 10, the mouse is all over the place.A:I haven't been able to reproduce this yet, but I suspect this isn't a Steembug. At this point, you'll have better luck with some search engine.You could try:- With other versions of Steem, including the "NoD3D" ones.- If options C1, mouse speed make a difference (please check manual).

Q:I copied D3DX9_43.dll to the Steem directory, but still Steem refuses tostart (application error (0xc00007b)). I had no problem with previous Steem versions.A:This is a common DirectX install error, no Steem bug.You had no problem with previous Steem versions because those didn't useD3D.Here are some hints:- This error seems to be caused by calling into a 64 bit DLL from a 32 bit appor vice versa.This error message may occur on 64 bit operating systems when the Microsoft Visual C++ 2008 Redistributable Package is not properly configured.You may try to reinstall it. - Apply all Windows updates- Reinstall .Net Framwork 4.5.1- Copy the following files into Steem folder:d3d9.dlld3dx9_43.dllxinput1_3.dll If it doesn't help, some search engine will be more useful than me.There is also a NoD3D build available in case it really won't work.

I don't have Win 10 installed, but I tested with a "live CD", copying D3DX9_43.dll was enough, and I had no mouse issue.Not saying there's no issue, just that maybe it's not up to me.For the moment I blame Micro$oft for both issues.

Getting better... I replaced my D3DX9_43.dll file with the one from http://ataristeven.t15.org/Files/D3DX9_43.zip and was able to launch "Steem SSE 3.7.2.exe".I get to the Atari desktop but still have mouse issues. IOW, when I move the mouse, I hear a bunch of "clicks" from the speakers, and the mouse kinda moves uncontrollably and mostly very quickly along the borders.This being said, I don't have the other 2 files: d3d9.dll, and dxinput1_3.dll Can you also include these as part of the zip please? Thanks!

I can't update my site via FTP for the moment (it's not down though).Normally you already have d3d9.dll somewhere, and there was a typo, it's xinput1_3.dll, not dxinput1_3.dll.Note that those files are widely available on the internet.But it could have nothing to do with the issue. I updated the FAQ again:

Q:With Windows 8 or 10, the mouse is all over the place.A:I haven't been able to reproduce this yet, but I suspect this isn't a Steembug. At this point, you'll have better luck with some search engine.You could try:- With other versions of Steem, including the "NoD3D" ones.- If options C1, mouse speed make a difference (please check manual).

Apparently I do not have the mouse issue when running outside Hyper-V so this must have something to do with the virtual machine. So that is issue is gone. I understand we can't expect you to support all the VMs as well About xinput1_3.dll, I do not have that dll, but xinput1_4.dll in Windows 10... I think it would be best if you could include all the required dlls for Steem since there might be different versions out there, and I would personally prefer to get these from a one trusted source...I was able to launch a game successfully but did not have the time yet to look into it further. I just want to mention that if you use a high resolution, some of the Steem windows do not show very well (tiny windows with overlapping controls), even though the Atari desktop window can be resized, and the resolution must be changed just so the toolbar windows can appear on the screen (Options, Joystick configuration, etc...). If I may suggest, have the config windows pop centered relative to the parent, and allow resizing of these windows.This being said, keep up the good work. I hope you will keep maintaining this great emulator. Long live the Atari STF !

Thx for the report.I also forgot to thank you for all your initiatives on EmuTOS.From the Windows error description, it seems that D3D init fails on your system even though all DLL are present.I added a "max res fullscreen" feature for extended monitor, but this supposes that D3D9 is available.Could you redownload the beta and test, it's a new build with a safeguard (+VC6 build no D3D)?Also, doesn't v3.7.2 crash when you go to options/fullscreen?

Steven Seagal wrote:Thx for the report.I also forgot to thank you for all your initiatives on EmuTOS.

I just would like that two great projects works hand-by-hand, but not in contrary

Steven Seagal wrote:From the Windows error description, it seems that D3D init fails on your system even though all DLL are present.I added a "max res fullscreen" feature for extended monitor, but this supposes that D3D9 is available.Could you redownload the beta and test, it's a new build with a safeguard (+VC6 build no D3D)?Also, doesn't v3.7.2 crash when you go to options/fullscreen?