Coming soon! Steem SSE 3.5

[nativ]

You know there is an STE demo with that Spaceman dancing !

[Avanze]

Love it. Please continue the good work.

[Steven Seagal]

I notice it's a project with quite some downloads there on sourceforge, which is the best reward for all those "efforts" (it's fun, really). It compares well with "WinUAE" there (Amiga emulator). So maybe this one isn't the sh1t, or that port, or there's another download location, or is ST winning the War in the end? Genuine question, I don't really follow Amiga emulation.

[Steven Seagal]

A new build of Steem SSE 3.5.1 for Windows has been added.
The OPT build is a Visual C++ 6 build with some optimisations turned on.
The file is smaller and it seems to work, so why not?

https://sourceforge.net/projects/steems ... SSE%203.5/

http://ataristeven.t15.org/Steem_all_builds.htm

[dlfrsilver]

A new build of Steem SSE 3.5.1 for Windows has been added.
The OPT build is a Visual C++ 6 build with some optimisations turned on.
The file is smaller and it seems to work, so why not?

https://sourceforge.net/projects/steems ... SSE%203.5/

http://ataristeven.t15.org/Steem_all_builds.htm

Crackdown 2 disks original release is now working further with steem 3.5.1 OPT for windows 32bits

But alas there is a big display bug if i send you the memory saved, can you have a look ?

[Steven Seagal]

Crackdown 2 disks original release is now working further with steem 3.5.1 OPT for windows 32bits

But alas there is a big display bug if i send you the memory saved, can you have a look ?

Could you please report bugs in this thread:
viewtopic.php?f=94&t=25093 (post-mortem)
This 'coming soon' thread must remain optimistic!

Edit: and do you have a link to that game version?

[dlfrsilver]

Crackdown 2 disks original release is now working further with steem 3.5.1 OPT for windows 32bits

But alas there is a big display bug if i send you the memory saved, can you have a look ?

Could you please report bugs in this thread:
viewtopic.php?f=94&t=25093 (post-mortem)
This 'coming soon' thread must remain optimistic!

Edit: and do you have a link to that game version?

[dlfrsilver]

the save state

[lotek_style]

Haven't read the whole thread so don't flame on me if this was already mentioned... I somehow can't switch of the drive info
flickering on the screen... if I switch it off it's on again when I start the emulator again. Known issue?

[npomarede]

Haven't read the whole thread so don't flame on me if this was already mentioned... I somehow can't switch of the drive info
flickering on the screen... if I switch it off it's on again when I start the emulator again. Known issue?

I saw similar things with 3.5.0 too, but I can't say if it's because I turned pasti on or accurate mode on. But once there's no more disk activity, the green led keeps on flickering. I didn't pay much attention to it before, but as it happens to others, there might be a small bug here.

Nicolas

[ecureuil]

Hello,

Steven what's your compiler and thirds parties libraries to build Steem SSE on Windows and Linux (and your distribution, etc) ?

Thanks you,

[DrCoolZic]

Hello,

Steven what's your compiler and thirds parties libraries to build Steem SSE on Windows and Linux (and your distribution, etc) ?

Thanks you,

Please use viewtopic.php?f=94&t=25163#p232774 for this kind of question as Steven wants to keep this thread for features description.

For bug reports please use viewtopic.php?f=94&t=25093 for same reasons

[ecureuil]

Hello,

Steven what's your compiler and thirds parties libraries to build Steem SSE on Windows and Linux (and your distribution, etc) ?

Thanks you,

Please use viewtopic.php?f=94&t=25163#p232774 for this kind of question as Steven wants to keep this thread for features description.

For bug reports please use viewtopic.php?f=94&t=25093 for same reasons

Ok, I posted here, because this topic seems alive. Sorry, for the wrong place.

[emodel]

Thanks for interpolation + scanlines

[Steven Seagal]

Thanks for interpolation + scanlines

I was reluctant at first, but it wasn't hard to do and now I use it all the time!

[Steven Seagal]

http://ataristeven.t15.org/Steem_35_coming_soon3.htm

More screenshots please!

On request, you will have 100,000 (wow!) instead of 1,000 available screenshots for one game, for example:

Crackdown_001.NEO before

Crackdown_00001.NEO now

[Steven Seagal]

Atari Diagnostic Cartridge




What you always desired is now reality: Steem can boot the little known Atari Diagnostic Cartridge. I downloaded the ROM files there and made a stc file (Steem's format) from those using WinHEX.




Steem will also accept 64KB cartridges (like this one). And 128KB cartridges don't need to start with 4 additional null bytes anymore. Also, Steem won't hang anymore when you try to load a wrong cartridge file (it was one of the rare bugs in Steem 3.2).

Technical notes.

1) Notice it's Keyboard rev. 2. It's because the HD6301 program in ROM sends $F1 to the CPU at reset. If it sends $F0 instead then it will say Keyboard rev. 1.

2) The RAM tests won't work well if we keep the MMU confused thing disabled... so now it's back on (a good thing I used #ifdef instead of just trashing the code), and so we've finally found one use of the costly feature that affects all memory read/writes. What I don't figure is where Steem authors got that kind of information, it's one of the most obscure parts of Steem code.

[Steven Seagal]

Riverside



Riverside, a recent 64KB demo by DHS, didn't display correctly in Steem.

It's because the STE-only technique used to remove the left border (line+20) causes an 8-pixels shift of the scanline which wasn't emulated yet.

Don't cry rivers, this is fixed for v3.5.2, but because the core video rendering system of Steem is in assembly and modifying it is involved, I used a hack instead, which makes the display of some other demos using the same trick (eg More or Less Zero) less elegant in the borders, only in 'very large' display size mode. The importance of this is more or less zero, just mentioning it.

There was another problem in the lower border due to some tests not being done if the scanline wasn't supposed to be done yet even though cycles were ahead (eg. we're 516 cycles into scanline). Pure internal issue. This latter fix could very well pollute other programs, so some testing is needed.


Coming soon!

[Steven Seagal]

If you check this page:

http://ataristeven.t15.org/Steem_35_coming_soon3.htm

you will see that there are many bugfixes, some embarrassing, especially concerning the options mess.
This means that version 3.5.2 shouldn't be too long to come, maybe next week or so.

Remember that all those fixes are already in the beta available here:

https://sourceforge.net/projects/steems ... SE%20Beta/

The only difference with future version is that it states 'Beta' instead of version number. This looks cool.

I also "fixed" (hacked) a drive problem where apparently only SainT did it right:



European demos disk detect

[npomarede]

Hello

regarding the fixes you made for fuzion menus, I see you changed some behaviour for the bus error on long access ? If that is the case, that's not the correct fix, the problem in fuzion menus is not that the bus error is not correctly handled, the bus error should not appear at all
You can see these menus work in STE mode, that's because digidrums are using dma sound on STE, while they use timer D in STF mode. At one point, if MFP emulation is not correct, the timer D interrupt will be processed when it shouldn't. This will shift the timer B one line later, cause a bad border removal and eventually crash later with a bus error.
By changing the bus error behaviour, I'm afraid you may break other programs or at least not fix this issue correctly (as far as I know, this simultaneous mfp cases is not handled at all in Steem)

PS : by the way, it's interesting you post changes more regularly to sourceforge, but I think you could improve readability a lot by separating cosmetic/indentation commits from the "real" fix's commit (for example, your changes for fuzion menus have a change to psg.cpp which is not related to the issue). It's much easier to track regression when commit are more "atomic".

Nicolas

[Steven Seagal]

About Fuzion disks it's a bugfix for the loader, not the menu, so it will break nothing.
I will not answer your other points in this thread, it's too technical.

[npomarede]

About Fuzion disks it's a bugfix for the loader, not the menu, so it will break nothing.
I will not answer your other points in this thread, it's too technical.

As you mentionned this change after seeing Fuzion menus in Hatari 1.7's changelog, I thought you wanted to fix the same issue I fixed in Hatari : the menus crash after a while in STF mode. I didn't notice a problem in the loader though.

Nicolas

[Steven Seagal]

As you mentionned this change after seeing Fuzion menus in Hatari 1.7's changelog, I thought you wanted to fix the same issue I fixed in Hatari : the menus crash after a while in STF mode. I didn't notice a problem in the loader though.

Nicolas

Yes I wanted, that's why I checked them. It's a coincidence that there was a regression in Steem v3.5 affecting them.
In Steem the menus don't seem to crash in STF mode, there's nothing to fix there. Not my doing, Steem authors are smart boys.
Notice that there's probably a wrong disk image of Fuzion 78 circulating (the 'a' in TOSEC), both Steem and Hatari crash when the menu appears.

[npomarede]

I noticed you also added a small pause to the acia for delirious demo 4 to always get the mouse pointer centered on the fake GEM desktop intro ; unfortunately I'm afraid this is not necessary as this is a bug in the demo on real HW too (yes, this demo has lots of bugs ).
More precisely, I get the same effect as Hatari 1.7 on my 520 STF : 9 times out of 10, the mouse will be nearly on top of the screen (y=13 instead of y=88). The code to write to the ACIA is correct in the demo (wait for bit 1 in fffc00), but it seems that if you move the mouse during loading (before the 16 bombs appear), this will affect the position sent in the SetInternalMousePos command. This will affect mouse centering on a real 520 STF as well as on Hatari 1.7 in what seems to be rather random in the end (I don't have time to look at the demo code to see what they made wrong and how it can affect initial centering).
All in all, I think you can remove this ACIA patch from your next Steem release.

Nicolas

[Steven Seagal]

All in all, I think you can remove this ACIA patch from your next Steem release.

Nicolas

Yeah, why did I bother?
There's still one possibility though, that it's different on a STE (don't see why).
Anyway I removed the delay as it could break something else.

I uploaded a new beta today:
Some fixes, and OSD: no sector info when fast drive.
Some MFP changes are inspired by Hatari 1.7, but the implementation is in the form of hacks, so option 'Hacks' must be checked, even if I believe that the results are the same as if it was done in a more "serious" manner (maybe later), at least for known cases.

Edit: in other news, I finally found how to add an icon to my website, looks as "pro" as atari-forum now:
http://ataristeven.t15.org/
Edit2: but still not at sourceforge