Coming soon! Steem SSE 3.8

[ijor]

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.

Probably not, but a Shifter wakestate, at least on the STf, can produce unstable effects. Not just the 16 pixels black one, although that is the most common.

True that it doesn't seem to be the case here. GLUE switches alone (50 - 60 Hz) don't go to SHIFTER and shouldn't be affected by SHIFTER wakestates. Those wakestates seem to be most sensitive to right border switches. The wakestate affects exactly how many cycles SHIFTER internally runs at mono (32 MHz) before going back to low (8 MHZ). At least that's what happens at the STf.

[Steven Seagal]

But do you have a better explanation?
Today I tested again, whether Nordlicht boot and NPG World of Music clown flicker or not varies with cold boot, and not warm reset.

[troed]

But do you have a better explanation?
Today I tested again, whether Nordlicht boot and NPG World of Music clown flicker or not varies with cold boot, and not warm reset.

Which screen exactly is "Nordlicht boot", so that I know what to look for. I seem to have four regular STEs for some strange reason (I promise, I'm not hoarding) so hopefully I should be able to replicate it on one of them at least.

/Troed

[Steven Seagal]

Yes, it wasn't very precise.

The World According to Nordlicht:
https://demozoo.org/productions/151599/
Screen is a sphere of dots right at the start.

World of Music by New Power Generation
https://demozoo.org/productions/72923/
You must wait a while for the clown to appear.

[ijor]

But do you have a better explanation?
Today I tested again, whether Nordlicht boot and NPG World of Music clown flicker or not varies with cold boot, and not warm reset.

If it were on the STf, and not (only) on the STE, I would say that it is most likely a SHIFTER wakestate issue. Only that probably is not caused by bottom border removal (at least not if using GLUE switches). It has to be a SHIFTER switch ...

Again, if that applies to an STE as well, I don't know.

[Steven Seagal]

Coming soon, Steem SSE 3.8.3!

Most changes are internal, but there will still be a couple of visible features.

First one is gamma correction.



Think it was requested at some point. I thought it was some arcane DirectX stuff, but we can do it ourselves in Steem, just like for brightness and contrast.

Comparing on real hardware with a CRT display, I couldn't confirm that Steem needs gamma correction, but it's always a handy setting.
Option 'Brightness/Contrast' has been renamed 'Colour Control'.

As you can see, there's a glider for each RGB colour. So at least you may do funny things, or improve readability...

EDIT: typo

[Steven Seagal]

Second feature, it has been talked about in another thread, support for some sound cartridges:
http://www.atari-forum.com/viewtopic.php?f=4&t=30389



The MV16 for BAT I, BAT II and Music Master.
The Pro Sound for Wings of Death and Lethal Xcess (STF mode).
The Replay 16 of 2-Bit Systems (only playback).

And it was hard to do that without opening another fun field of emulation, dongles and other special adapters.
That's because BAT II and Music Master were protected by a dongle in the serial port.

To emulate this, a new option has been added in Steem SSE, on the Ports page.



As you can see, we also emulate some other adapters. Some of them were plugged in the mouse or joystick port.
If you think this option is similar to something in WinUAE, it's no coincidence.

The Pro Sound cartridge is also there because it was a Centronics adapter. You also can select the 'freeze' switch of some "ripping" cartridges.

Please no requests for audio software dongle emulation.

[dlfrsilver]

Thanks Steven for Adding those. At last BAT II in pasti format french release will be playable !!! cool !

[Maartau]

Rhaaaa, lovely !!!

Huge thanks STeven [smilie=greencolorz4_pdt_01.gif] .

[ijor]

You need "round cycles up to 4" only for RAM and Shifter accesses.
Funny but this was already in the Engineering Hardware Specification of 1986:
...
See how the Memory controller (MMU) sits between the CPU and the RAM/Shifter?
...
In the schema above, there's also "Buffers" near the Shifter, don't know what it is.

The scheme is a bit misleading. MMU doesn't really sit between the CPU and RAM, those buffers are.

There are two data buses in the ST, the main CPU bus, and the RAM/SHIFTER (and nothing else) bus. Four TTL chips (two buffers and two latches) connect or separate both buses. MMU is connected to the main data bus. But it controls the buffers and the RAM address bus.

Where "is" $ffff8260?

Yes. It lives in both chips, GLUE and SHIFTER. You can say it is actually a SHIFTER register, only shadowed by GLUE. Reads are performed from SHIFTER, not from GLUE.

... GLUE can definitely detect manipulation of it with 2 cycle accuracy

Actually within a single cycle accuracy, not two

But obviously, shift mode and HSCROLL are in the Shifter, with maybe only a bit for each in the GLUE (on/off).

Don't know about HSCROLL, but GLUE shadows BOTH bits of Rez (Shift Mode). You'll wonder why? Why it cares exactly about which color resolution is currently selected, low or med. After all GLUE only cares about frequency, not about resolution ... Well, there is a reason most wouldn't expect ... let's make it a mini quiz of it.

[Steven Seagal]

The scheme is a bit misleading. MMU doesn't really sit between the CPU and RAM, those buffers are.

There are two data buses in the ST, the main CPU bus, and the RAM/SHIFTER (and nothing else) bus. Four TTL chips (two buffers and two latches) connect or separate both buses. MMU is connected to the main data bus. But it controls the buffers and the RAM address bus.

Do those buffers hold 16bit values?

Yes. It lives in both chips, GLUE and SHIFTER. You can say it is actually a SHIFTER register, only shadowed by GLUE. Reads are performed from SHIFTER, not from GLUE.

Ha, it's right in Steem.

Don't know about HSCROLL, but GLUE shadows BOTH bits of Rez (Shift Mode). You'll wonder why? Why it cares exactly about which color resolution is currently selected, low or med. After all GLUE only cares about frequency, not about resolution ... Well, there is a reason most wouldn't expect ... let's make it a mini quiz of it.

Argh! I had changed it in Steem (one single bit in GLUE).
Don't think I'll win this quiz, though, no idea what the reason could be.

[Steven Seagal]

Last visible features of Steem SSE 3.8.3, STW Strikes Back!

To help our MFM disk format, we added two little features to Steem SSE.
First, STW (and HFE) images will only run as slowly as on hardware if the Disk Manager option 'Accurate Disk Access Times (Slow)' is checked. Otherwise, it's notably accelerated. Most disk images should work in this mode, but not when timing is important, nor if the program uses WD1772 commands READ TRACK or WRITE TRACK.


Second, we added a context option in the Disk Manager, 'Convert to STW'. It immediately converts a regular DIM, MSA or ST image to a STW image.




That's all.
Features are presented with some more details here (thx again to exxos for hosting):

http://ataristeven.exxoshost.co.uk/Stee ... g_soon.htm

[ijor]

Do those buffers hold 16bit values?

Yes, of course. Each chip buffers or latches 8 bits. Two chips are used for performing read cycles, and the other two for write cycles.

Argh! I had changed it in Steem (one single bit in GLUE). Don't think I'll win this quiz, though, no idea what the reason could be.

No need to change it back. LOL. The only reason GLUE wants to know if you are running low or med rez, is for the non-working interlace logic:
http://www.atari-forum.com/viewtopic.php?f=15&t=30303

[ijor]

At the same time, like all that concerns wake-up states, emulation is very pragmatic. I don't have a real model yet. Just adding cases to a collection of hacks, without breaking the rest (eg Overdrive/Dragon).

Don't know if it is still relevant. But for building a good model, and because you are emulating the hardware, I think you have to think from the hardware, and not from the software point of view. Sometimes the approach is exactly the opposite. See for example this sentece from the wiki:

Due to the internal workings of the GLUE it will latch 820a (FREQ) one cycle later than 8260 (RES). At any specific comparison cycle this means the GLUE will use the FREQ value written one cycle before RES.

So I think you have to model GLUE and MMU without thinking on the wake state consequences. The internal timing on the chips, from their own point of view, is constant. It doesn't change depending on the wake state.

[Steven Seagal]

The only reason GLUE wants to know if you are running low or med rez, is for the non-working interlace logic:
http://www.atari-forum.com/viewtopic.php?f=15&t=30303

Got it now:

Btw, the interlace logic is for low rez only. It is completely shut off for other resolutions.Let me post the relevant page from the schematics ...

At the same time, like all that concerns wake-up states, emulation is very pragmatic. I don't have a real model yet. Just adding cases to a collection of hacks, without breaking the rest (eg Overdrive/Dragon).

Don't know if it is still relevant. But for building a good model, and because you are emulating the hardware, I think you have to think from the hardware, and not from the software point of view. Sometimes the approach is exactly the opposite. See for example this sentece from the wiki:

Due to the internal workings of the GLUE it will latch 820a (FREQ) one cycle later than 8260 (RES). At any specific comparison cycle this means the GLUE will use the FREQ value written one cycle before RES.

So I think you have to model GLUE and MMU without thinking on the wake state consequences. The internal timing on the chips, from their own point of view, is constant. It doesn't change depending on the wake state.

Yes, it's still relevant.

For the moment, in Steem (SSE), there are 4 WS, which change some GLUE timings, by 0, +2 or -2, in "emulator cycles":
DE Start cycle, end cycle, HBlank, HSync, etc.

Those timings are used when Steem checks for overscan tricks.

There's no cycle by cycle emulation of the GLUE and the MMU if that's what you mean.

EDIT
And if Steem thinks that the Shifter has some words inside at the start of the line, it shifts the display and the planes accordingly, using nice formulas! That's how LJBK's bee demos and the rest work. I don't think we have a model for that already.

[Marcer]

One buggy issue.. Do two reset and i get a med/low mix.. All The time.. How Come?

[Steven Seagal]

One buggy issue.. Do two reset and i get a med/low mix.. All The time.. How Come?

If you find a bug in Steem, please fill a report in this section:
http://www.atari-forum.com/viewforum.php?f=112

[sitgestraveller]

Hi there everyone.

I'm running Sundog - A Frozen Legacy on Steem 3.8.2 and I find that I can't save any games to the library. Does anyone know if it's a bug in the game or if it's simply a glitch when running with Steem? I noticed that apparently there is the same type of problem using a 'PC Emulator' as highlighted in the following link (though it suggests it's a PC emulator rather than an ST emulator but it may be something to do with emulators in general...?

http://www.lukin.com/sundog/misc/faq.html

Thanks everyone and most of all, thanks to Steven Seagal for Steem! (Great fighting, by the way! )

Mike.

[Steven Seagal]

Hi there everyone.

I'm running Sundog - A Frozen Legacy on Steem 3.8.2 and I find that I can't save any games to the library. Does anyone know if it's a bug in the game or if it's simply a glitch when running with Steem? I noticed that apparently there is the same type of problem using a 'PC Emulator' as highlighted in the following link (though it suggests it's a PC emulator rather than an ST emulator but it may be something to do with emulators in general...?

http://www.lukin.com/sundog/misc/faq.html

Thanks everyone and most of all, thanks to Steven Seagal for Steem! (Great fighting, by the way! )

Mike.

Hi Mike,
Thx, but
1) Thank Steem authors Anthony & Russell Hayward for Steem, I'm just adding on it (SSE version).
2) Please fill a bug report in this section:
http://www.atari-forum.com/viewforum.php?f=112
And I'll look at it.

In this thread, there are no bugs, only features.

[Steven Seagal]

Checking the calendar, it seems the ideal date to release the new version would be around 24/12.

That way, even if Santa Claus forgets you, you'll have something to play with.

[Hypnotoad]

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.

I seem to be getting a bit of fuzz or slight vibration too which is a bit annoying. If it helps, my card is an AMD Radeon HD 7950.

[Steven Seagal]

I seem to be getting a bit of fuzz or slight vibration too which is a bit annoying. If it helps, my card is an AMD Radeon HD 7950.

Hi, please take bug reports here:

http://www.atari-forum.com/viewforum.php?f=112

[Steven Seagal]

Little size comparison.

In general, 384 x 270 is fine. But in some cases it looks better on 413 x 275.
Case in point, Obsession, that uses the STE small left border trick.

obsess_384.png

In 384 x 270 mode, as on an LCD TV, the picture isn't centred. It is annoyingly drawing to the left.

obsess_413.png

In 413 x 275 mode, as on a CRT monitor, it is better centred.

[troed]

In 413 x 275 mode

Currently max used vertical lines (for pixel graphics) in an ST demo: 274
Max possible lines that can be used (and will certainly be used at some point): 276

... and if you want to be REALLY future proof, 18 (IIRC) pixels to the extreme left of line 277 are actually possible to use as well.

413 horisontal pixels is the maximum I've managed to get, but it's dependent on wakestate and the border opening technique.

/Troed

[beel1]

Hello!
Is there a "test suite" (could be a set of apps/demos/games) of all video tricks used on STE in low/med/hi(?) resolutions (overscan, palette shifting, 50/60Hz...)?
My SC1435 CRT is dying and I would like to evaluate different replacement solutions using a LCD...
I know it may not be the best topic to ask this question (maybe in hardware?), but after having a look at "brag pages" of Steem SSE and seeing how good it is I'm asking here first