Coming soon! Steem SSE 3.8

[lotek_style]

Well I didn't do the ISO so I can't recreate a new one... but no one else reported a problem yet.

[lotek_style]

Here's a couple of images from that CD in that .DIM format.

[Steven Seagal]

Thx. Steem is correct for those DIM files, they are fake.
If you change to .ST they will load.


DIM Format:

Code: Select all

Offset Contains
$00     $4242 ("BB") identifier
$02     low byte=1=get used sectors, hi byte=1=read disk conf
$04     seems to be always(?) zero

$06     hi byte=sides
$08     hi byte=sectors
$0a     hi byte=start track
$0c     hi byte=end track

$0e     RECSIZ sector size (bytes) 
$10     CLSIZ  sectors per cluster
$12     CLSIZB cluster size (bytes) 
$14     RDLEN  root dir size (sectors) 
$16     FSIZ   FAT size (sectors) 
$18     FATREC first sector if 2nd FAT (the one that is used by TOS)
$1a     DATREC Number of 1st data sector 
$1c     NUMCL  Total number of clusters minus DATREC
$1e     BFLAGS (Bit 0 is 0 for 12 bit FAT, 1 for 16 bit FAT)

[lotek_style]

I used DIM2ST to convert them... conversion worked without problems... if those were not .DIM shouldn't there be problems already converting?

What about the files from Paskud collection?

ftp://ftp.pigwa.net/stuff/collections/paskud/

[Steven Seagal]

I used DIM2ST to convert them... conversion worked without problems... if those were not .DIM shouldn't there be problems already converting?

I don't know DIM2ST but DIM files should start with $4242.

What about the files from Paskud collection?

ftp://ftp.pigwa.net/stuff/collections/paskud/

Can't access! Is there some login?

[lotek_style]

nope... works fine in my browser

[Steven Seagal]

I see the lists but can't download a file

[lotek_style]

There never was any limitation on pigwa.net... downloading works from here... I'm sorry I have no clue where the problem is.

[Steven Seagal]

It mostly doesn't work for me.
I could just download one, 0315, header was wrong as well.
Starts with 601C, 'jump' in M68000 assembly, like an ST image.

[Steven Seagal]

Steem SSE 3.8.2 is planned for release.
Strategic date chosen: 30/6, so that even the poor may have a great holiday.

It's a minor release. The most important fix seems to be the drifting mouse cursor issue.

To help debugging, the main build will also produce a little trace file.

steem_clock.png

Also an optional clock on the screen, some bugfixes...

[Steven Seagal]

Steem SSE 3.8.2 has been released on 30 June 2016.
Happy holidays!

Note
______

As of v3.8.2, the main build of Steem SSE only uses Direct3D9 for all
video rendering, windowed and fullscreen, not DirectDraw. This build requires
a SSE-enabled microprocessor, of course.
This makes some options simpler.
Another fully functioning build only uses DirectDraw 2 for video rendering,
and older C++ libraries for maximal compatibility. It is less optimised.

Also as of v3.8.2, the main build will produce a TRACE.txt file that can
help bug reporting. It is based on the same Boiler feature, but less
sophisticated.

A 64bit build of Steem is also available. It's fully operational but does
need 64bit DLL libraries (so, no Pasti.dll for now).


v3.8.2 Features
_________________

- New OSD option 'Time'.
- New Fullscreen mode option 'Fullscreen GUI'.
- DirectDraw build: fullscreen working with 32bit-only video card drivers.
- New SSE option 'VM-friendly mouse' to help when Steem is run in a
virtual machine (works with VirtualBox). The cursor isn't bound
by the window frame. You don't need a VM to use this option.
Thx galax for tests.
- CPU: stabler E-clock emulation.
- New TOS flags for Czechia, Finland, Greece, Norway (thx Dima Sobolev).


v3.8.2 Internal
_________________

- Remove hack for high frequency tone waves in YM-2149 emulation (YMT-Player).


v3.8.2 Bugfixes
_________________

- Fix Steem SSE crash on some long switches between HIRES and LORES
(stf1pix_512k).
- Extended monitor hack: ignore VBASE changes (potential crash).
- ACSI: reload TOS to remove "no ACSI" patch.
- Fix stop icon staying on screen after stopping Steem SSE (bug v3.7.0).


Download
__________

http://sourceforge.net/projects/steemsse/
http://ataristeven.exxoshost.co.uk/Steem.htm

[Maartau]

Steven, my hero !

for that special date (as most of us will be on Holidays soon) .



- that's a perfect date for me to do "new skin",
- let's go back in the business,
- let's be more active from my side : bored by my sooooo much unfinished projects ...

[Steven Seagal]

There seems to be some problem with default download at sourceforge.
I tried to fix it.

The main build is:

Steem.SSE.3.8.2.Win32.zip

(not Win64)

[Hypnotoad]

Hey Steven Seagal, nice work on this fork. I'm having some trouble however, the full screen mode (even when set to my desktop resolution) is blurred and I cannot seem to enable a crisp image. In contrast, a resized window maintains a crisp image with clear pixels.

Here are some images as an example:

Full screen mode:
https://i.gyazo.com/88ce8dfbf929701a084 ... 74d1c4.png
https://i.gyazo.com/ad8f7da0f18f80888d3 ... 4fd4cf.png

Window:
https://i.gyazo.com/38c6d34a1b1f439da18 ... a32ddc.png

Now perhaps the slightly blurred image is how it's supposed to look, I don't really recall (it has been 20 years since I've used a real ST). Otherwise, is there some way to have the full screen mode look as crisp as the window?

Thanks.

[FedePede04]

Hey Steven Seagal, nice work on this fork. I'm having some trouble however, the full screen mode (even when set to my desktop resolution) is blurred and I cannot seem to enable a crisp image. In contrast, a resized window maintains a crisp image with clear pixels.

Here are some images as an example:

Full screen mode:
https://i.gyazo.com/88ce8dfbf929701a084 ... 74d1c4.png
https://i.gyazo.com/ad8f7da0f18f80888d3 ... 4fd4cf.png

Window:
https://i.gyazo.com/38c6d34a1b1f439da18 ... a32ddc.png

Now perhaps the slightly blurred image is how it's supposed to look, I don't really recall (it has been 20 years since I've used a real ST). Otherwise, is there some way to have the full screen mode look as crisp as the window?

Thanks.

Hi in the control panel you should have a fan call fullscreen mode.
try to enable crisp rending.

fullscreen.png

[Hypnotoad]

Hey Steven Seagal, nice work on this fork. I'm having some trouble however, the full screen mode (even when set to my desktop resolution) is blurred and I cannot seem to enable a crisp image. In contrast, a resized window maintains a crisp image with clear pixels.

Here are some images as an example:

Full screen mode:
https://i.gyazo.com/88ce8dfbf929701a084 ... 74d1c4.png
https://i.gyazo.com/ad8f7da0f18f80888d3 ... 4fd4cf.png

Window:
https://i.gyazo.com/38c6d34a1b1f439da18 ... a32ddc.png

Now perhaps the slightly blurred image is how it's supposed to look, I don't really recall (it has been 20 years since I've used a real ST). Otherwise, is there some way to have the full screen mode look as crisp as the window?

Thanks.

Hi in the control panel you should have a fan call fullscreen mode.
try to enable crisp rending.
fullscreen.png

Already tried, doesn't appear to make a difference.

[Kochise]

Question, with no more real Atari hardware under the hand, I'd like to know what is the current level of IDE/ACSI/SCSI emulation for me to continue the development of my old driver ?

[Steven Seagal]

Already tried, doesn't appear to make a difference.

Could be hardware. Crisp fullscreen works on the systems I tried, but it's no proof.
For example, on a system, window stretch mode, double size, is crisp, on another it's blurry.
As a consolation, a bit of blur is merciful in fullscreen mode.

[Steven Seagal]

Question, with no more real Atari hardware under the hand, I'd like to know what is the current level of IDE/ACSI/SCSI emulation for me to continue the development of my old driver ?

In current version (Steem SSE 3.8.2), there's emulation of 1-4 ACSI hard disks as img files of sectors (SH-204, megafile).
Normally Hatari emulates IDE and SCSI, in Steem I'm not sure it's important (Steem is STF/STE, not TT/Falcon).

[Steven Seagal]

More wake-up state madness...

A good tester reported a bad scroller in World of Music by New Power Generation in STE mode.
I saw that on the real STE, the scroller staid smooth, only changing colour.

NPG_WOM1-min.png

NPG_WOM2-min.png

This is how it looks on a real STE. The clown picture is shifted.

On an STF this should look like this:

NPG_WOM_STF-min.png

The scroller staying in the same colour.
On the STE, the problem is a "line +2" triggered by a late switch back to 50hz after the lower border has been removed by a switch to 60hz, because timings are different on an STE, which is emulated in Steem SSE (if it looks better in other emulators, maybe they don't emulate this difference). It's quite frequent.

But a "line +2" by itself will destabilise the Shifter, there's one more word (2 bytes) loaded in it. This explains the shift of the picture above: the Shifter is destabilised at the lower overscan limit, and stays in that condition during the next frame.


The beauty of this is that it also fixes the Nordlicht case in STE mode.

nordlicht-min.png


I'm not one to brag, but If you want to check STNICCC 2015 demos, you know which emulator to use.

By chance I rechecked those two demos on my STE today and they both flicker, as in Steem without the WS option.
It points to the STE having some variable wake-states, or at least mine. Sometimes it takes a line +2, sometimes it doesn't.
As seen on Cuddly Demos "patched" too.

edit: or different timing triggers or not the +2

edit: or the +2 has a different effect on Shifter registers, in some WS they will be reset at the end of the line, in another one, not.

[troed]

By chance I rechecked those two demos on my STE today and they both flicker, as in Steem without the WS option.
It points to the STE having some variable wake-states, or at least mine. Sometimes it takes a line +2, sometimes it doesn't.
As seen on Cuddly Demos "patched" too.

edit: or different timing triggers or not the +2

Different timing triggers.

/Troed

[Steven Seagal]

By chance I rechecked those two demos on my STE today and they both flicker, as in Steem without the WS option.
It points to the STE having some variable wake-states, or at least mine. Sometimes it takes a line +2, sometimes it doesn't.
As seen on Cuddly Demos "patched" too.

edit: or different timing triggers or not the +2

Different timing triggers.

/Troed

I edited the post again, because the "+2" triggers anyway, the effect on the frame is different because the Shifter keeps one word too many at the end of each line.

[troed]

edit: or the +2 has a different effect on Shifter registers, in some WS they will be reset at the end of the line, in another one, not.

The STE has no wakestates. Tell me where I should see this effect on real hardware and I'll look into it

(That isn't to say that you cannot create weird code where some effects are different on STE between machines and/or how long it has been turned on though - but so far I've only seen "every other 16 pixels blank" caused by that)

/Troed

[ijor]

The STE has no wakestates. Tell me where I should see this effect on real hardware and I'll look into it

It has no MMU-GLUE (or CPU-GLUE if you prefer to call them) wakestates, but it probably still has SHIFTER wakestates.

[troed]

The STE has no wakestates. Tell me where I should see this effect on real hardware and I'll look into it

It has no MMU-GLUE (or CPU-GLUE if you prefer to call them) wakestates, but it probably still has SHIFTER wakestates.

Indeed - like "Spectrum 512 pixels". But there's no sub wakestate that I know of that would cause different amounts of words being cleared at the end of sync manipulated lines.

/Troed