Steem SSE beta

[Steven Seagal]

In compliance with GPL rules, a public beta is available, containing latest bugfixes and new features, and quite often horrible regressions as well.
The public beta is built using the source code uploaded at sourceforge. The build is available at sourceforge:

https://sourceforge.net/projects/steemsse/

And at the Steem SSE site:

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

[Steven Seagal]

Post #1 is copied from the blog at https://sourceforge.net/projects/steemsse/.
More info here:
- Current beta has just bugfix option 'disk drive track info'.
- I'll try to keep 'Coming Soon' brags and beta and code in sync!
- I do this because I will upload code more often anyway; so I don't annoy people with a lot of emails with buggy releases; next release of Steem can't be every few weeks.
- Don't hesitate to report beta bugs, of course, please not in the 'Coming Soon' thread.

[Avanze]

I think the public beta system, at sourceforge, is a great idea. I hope you will continue to post here, as and when, new betas are released.

Anyway, great work, and as always it much appreciated.

[Steven Seagal]

It"s also good because so the code is updated more often in sourceforge instead of one "megaupload" (hmm) every X months. I have my own backups but since I must use SVN let's make it useful.
Normally features claimed in the Coming Soon! thread are already in the available beta.

[Steven Seagal]

Well, there's already a new beta for next version of Steem as I found a little bug in ACIA emulation, that breaks 'Nightdawn' (but, I think, little else).

[npomarede]

Well, there's already a new beta for next version of Steem as I found a little bug in ACIA emulation, that breaks 'Nightdawn' (but, I think, little else).

Regarding the TDRE bit, it's value is not updated after a fixed delay of 512 cycles, the delay can be variable (it's related to the next clock's tick in the acia serial transfer). This is where emulating the ACIA at bit level in Hatari prove to be handy, even if overkill most of the time

[Steven Seagal]

Regarding the TDRE bit, it's value is not updated after a fixed delay of 512 cycles, the delay can be variable (it's related to the next clock's tick in the acia serial transfer). This is where emulating the ACIA at bit level in Hatari prove to be handy, even if overkill most of the time

Yes certainly 512 cycles is just an approximation.
But Steem uses 3rd party code for 6301 emulation, that doesn't work at bit level, so ACIA emu in Steem should remain at byte level for a while.

[npomarede]

A serial byte in that case is in fact 10 bits, so even without splitting everything at the bit level, you could still evaluate that a new transfer will start at the next multiple of "delay to transfer 1 bit in the acia" and that the complete byte will be available after 10 x "delay to transfer 1 bit in the acia". What you would just need is an additional variable to hold the time of a possible bit transfer -> 1 bit is 1024 cpu cycles, so you need to update tdre on the next multiple of 1024 cycles.

[Steven Seagal]

By the way, in the current beta, the original nice 'fuji' plazma animation has been restored when you start emulation (on screen display).

(top of the screens, 2 phases but you must see this 'live')




https://sourceforge.net/projects/steemsse/

[Steven Seagal]

For those using the beta, I just uploaded a new version after squashing a nasty bug that could crash Steem.

[Steven Seagal]

If everything goes well, last beta before release of v3.5.3 (Win32) has been uploaded.

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

[wietze]

In case this is not the appropriate thread for questions with regards to the SSE release, please forgive me and point me to the right direction.

I am a big fan and heavy user of the STEem Debugger. However, currently this version is only built for Windows. The only way I am able to use the STEem debugger on other platforms (linux,osx) is through Wine.

I am wondering if it is possible to release a STEem version for Linux that includes this wonderful Debugger.

Regards,
Wietze

[Steven Seagal]

In case this is not the appropriate thread for questions with regards to the SSE release, please forgive me and point me to the right direction.

Well, there was the Linux build thread in the same subforum if that's what you're using.

I am a big fan and heavy user of the STEem Debugger. However, currently this version is only built for Windows. The only way I am able to use the STEem debugger on other platforms (linux,osx) is through Wine.

I am wondering if it is possible to release a STEem version for Linux that includes this wonderful Debugger.

Regards,
Wietze

For the moment it is not possible, the debugger was intended as WIN32 only by Steem authors, there are no #ifdef UNIX blocks like for XSteem itself.
I'm sure it's manageable, it could be a long term project, but myself have no concrete plan yet as I'm not a Linux nor OSX user.

[Avanze]

If everything goes well, last beta before release of v3.5.3 (Win32) has been uploaded.

Great stuff. I have been following development rather obsessively, lol.

[Steven Seagal]

Great stuff. I have been following development rather obsessively, lol.

Good to know those "Coming Soon!" pages have some readers.
Those pages are part of the fun for me.

[Steven Seagal]

So guess what I found a bug that could crash Steem in 'very large' display mode, so a new beta is available, and next release will be very soon.

Beta is here:

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

[Steven Seagal]

New beta, please some people test, release planned for Sunday.

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

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

Code: Select all

v3.5.4 beta changes (R163)
==========================

- Bugfix crash in very large display size on some systems.

- Bugfix option 'Pasti only for STX' could make Steem treat pasti images as
  native on loading a snapshot.

- Bugfix drive internal variable "motor on" (European Demos OVR V).

- Bugfix (useless) feature STE HIRES HSCROLL wasn't available (oops).

- Bugfix VBL jitter (Japtro).

- 'Cold reset & run': reset IKBD buffer (Transbeauce 2).

- Bugfix drive complete command on empty drive (European Demos "insert B").

- Bugfix ACIA timing when not using true 6301 emu (Sapiens).

- Bugfix display 400x278 interpolated scanlines shift.

- New option "VSync".
  This gives you the best display provided your monitor has the correct
  refresh rate (50hz/100hz for most programs).
  Combined with 'Interpolated Scanlines' this should give you the best
  experience of the great game Goldrunner in window mode on LCD screen.
  This should work in window mode as well as in fullscreen mode.
  This consumes some CPU power (but not as much as Triple Buffering).

  This could interfere with "Compositing" (Desktop Window Manager) in Windows
  Vista and 7 in window mode. In Windows 8 you can't disable Compositing!

- New option "Triple Buffering".
  This may be useful to eliminate "tearing" or "ghosting", at the price
  of high CPU use.
  This should work in window mode as well as in fullscreen mode (stretch
  mode only).

  "Compositing" (Desktop Window Manager) in Windows Vista and above makes
  this option useful only in fullscreen mode, in window mode there's already
  no tearing.
  This illustrates that those display problems may also be handled at driver
  or OS level.

- New status info in the tool bar, giving:
  ST model, TOS version, available memory, plus whether 6301 and pasti
  or Caps, or accurate drive emulation (ADAT).
  Also option for the name of current disk.

- New display size options.
  384 x 270 normal
  400 x 278 max in fullscreen 800x600 mode
  412 x 280 max overscan
  416 x 286 max plasma
  Depending on the program, one or the other size will be better.
  Generally the smallest is sufficient.
  The sizes count only for border effects in colour mode.
  Steem displays what's inside the video RAM even at the extremities of the
  borders, regardless of blanking or plane shifs introduced by shifter tricks
  on a true ST. That's why 412 x 280 may be actually more faithful than the
  max size. If option 'Hacks' is checked, the image will show 52 left
  border pixels in 412 x 280 and 416 x 286 modes. If not, only 48.
  I believe 52 is the right number, but am not sure. In order to avoid
  rewriting the rendering system we also use tricks to obtain those 4 more
  pixels. It may break in some yet unknown cases.
  Note that internally 400 x 278 is emulated as 416 x 286, and a trick is used
  to change resolution at rendering time (blit).
  This may cause the display to go black or be shifted or another kind of
  bizarre when the emulator isn't running.
  400 x 278 allows one to read the full text of Best Part of The Creation.
  416 x 286 has recently been modified, so this mode and derived modes
  400 x 278 and 412 x 280 could still be a bit buggy.
  In short, all bigger than normal (384 x 270) display sizes use various
  tricks.

- Wake-up state:
  Normally you'll use this option only if the display of some demo isn't
  correct without. You don't need to understand all technical aspects
  to use the option, of course.

  The option has become much more complicated, with 4 states instead of 2.
  It is that complicated on the ST.

  +------------------------------------------------------------+
  | Steem  option    |              Wake-up concepts           |
  |    variable      |                                         |
  +------------------+---------------+------------+------------+
  |  WAKE_UP_STATE   |   DL Latency  |     WU     |      WS    |
  |                  |     (Dio)     |    (ijor)  |    (LJBK)  |
  +------------------+---------------+------------+------------+
  |   0 (ignore)     |      -        |     -      |      -     |
  |        1         |      3        |   2 (warm) |      2     |
  |        2         |      4        |   2 (warm) |      4     |
  |        3         |      5        |   1 (cold) |      3     |
  |        4         |      6        |   1 (cold) |      1     |
  +------------------+---------------+------------+------------+

  WAKE_UP_STATE is just the Steem option.
  DL is a latency electronically measured by Dio (atari-forum) between two
  signals, 'DE' and 'LOAD', in cycles.
  WU are the two wake-up states first found by ijor.
  WS are the more detailed "wake states" found by LJBK.
  They're in a strange order for "historical" reasons.

  The "Bee" demos by LJBK will recognise WS1-4, and the demos will behave as
  expected in all WS.

  The option may help for some flickering screens.

  Emulation of those states is still not complete.

  Needless to say, Steem is leading the way for this issue.

- Save WU state with snapshot; reset on switch STE/STF.

- No line +2 when Shifter destabilised: Darkside of the Spoon STE
  (choose one of the wake-up states to remove flicker, because otherwise
  Steem will ignore destabilisation).

- 'Shifter panic': swap good/bad bands to be more like screenshot of
  Omega Full Overscan.
  Shifter panic is only WU2, by choice, to limit options.
  Omega works in WS2, Death of the Left Border in WU1 (at least, in
  Steem).

- Rearrange some options, "drive track info" in SSE page, when it's
  checked the drive led of 'OSD' page is suppressed.

- Disk manager: right click on name to read full name, useful for very
  long names.

- Internal:
  Reordering of shifter tricks analysis, refactoring.
  Some tests for shifter tricks now handled in a state machine-like
  manner, not looking for specific switches anymore => better emulation,
  more performing tests.
  Debugging and removing some hacks related to "wake-up" and "wake-state".
 

Sites:

https://sourceforge.net/projects/steemsse/files/Steem%20SSE%20Beta/?

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









[AtariZoll]

Just a short impression:
Tried GoldRunner with Vsync in windowed mode. It really looks great As my monitor can only 60Hz it runs then faster, but this is something what can not be solved by SW, I'm sure. There is strange behaviour of WIndows mouse cursor - it is invisible when is positioned over Steem window, and Disk manager + other windows too. Especially bad when try to click on something at top, like Stop icon. I use Windows XP, don't know is this because of Window (version) general behaviour when Vsync is on ...

Now there is lot of switches at SSE options, and it may be pretty confusing. Just as example: I checked on 'Pasti only for STX' . Later tried to mount some hard disk image file, so I checked on 'enable' , selected file, but it worked not. Took some minutes while I realized that it may be because Pasti only with STX, and there was no STX image 'inserted' Maybe it is possible to make that switch affect only floppy emulation, and leave ACSI hard disk emulation on always (at least when Use Pasti is checked) ?
I guess that we may see other, similar problems because those switches - so usage needs more care and thinking . Hopefully, when development will reach some more advanced stage it can me made simpler for user .

[Steven Seagal]

Just a short impression:
Tried GoldRunner with Vsync in windowed mode. It really looks great As my monitor can only 60Hz it runs then faster, but this is something what can not be solved by SW, I'm sure. There is strange behaviour of WIndows mouse cursor - it is invisible when is positioned over Steem window, and Disk manager + other windows too. Especially bad when try to click on something at top, like Stop icon. I use Windows XP, don't know is this because of Window (version) general behaviour when Vsync is on ...

I don't have those problems with my XP, nor in Win7. But rendering slows down when you hover on the task bar, for example. There's a setting in 'startup' to hide mouse cursor when blit, could be related, but for me it changes nothing.

Now there is lot of switches at SSE options, and it may be pretty confusing. Just as example: I checked on 'Pasti only for STX' . Later tried to mount some hard disk image file, so I checked on 'enable' , selected file, but it worked not. Took some minutes while I realized that it may be because Pasti only with STX, and there was no STX image 'inserted' Maybe it is possible to make that switch affect only floppy emulation, and leave ACSI hard disk emulation on always (at least when Use Pasti is checked) ?
I guess that we may see other, similar problems because those switches - so usage needs more care and thinking . Hopefully, when development will reach some more advanced stage it can me made simpler for user .

All I can do now is change the option name and tooltip to make it clear that only floppy STX will be handled by pasti, not ST, MSA, and not HD.

Unless it works with this version:

http://ataristeven.t15.org/Files/Steem%20SSE%20Beta.zip

[Steven Seagal]

For the "status bar", I chose the # symbol to indicate that option 'Hacks' is selected. I know it's silly but I couldn't find anything better (important to be short). If someone has a better idea, let me know soon or it's for another release.

[Steven Seagal]

It really looks great As my monitor can only 60Hz it runs then faster, but this is something what can not be solved by SW, I'm sure.

Some rare programs are meant to run at 60hz, I just checked HighResMode (available on my site in case: http://ataristeven.t15.org/Steem_demos3.htm ), it's perfect at 60hz + VSync.
So the little hiccups weren't an emulation issue.

[AtariZoll]

...
All I can do now is change the option name and tooltip to make it clear that only floppy STX will be handled by pasti, not ST, MSA, and not HD.
Unless it works with this version:
http://ataristeven.t15.org/Files/Steem%20SSE%20Beta.zip

It is OK now - hard disk emulation works regardless from setting.
Considering invisible mouse pointer: it likely depends from video driver in Windows. I remember some setting about HW mouse cursor earlier, but now don't see it in CCC (Catalyst Control Center).
Demo at 60Hz is surely good for usual LCD monitors.

[Steven Seagal]

It is OK now - hard disk emulation works regardless from setting.

It will be for the next version then, v3.5.4 still blocks HD access when option is checked.
That's no drama...

[Steven Seagal]

Demo at 60Hz is surely good for usual LCD monitors.

I found another at 60hz, the Little Sound Demo by TEX, never noticed before.

Edit: And 'Read Me' apparently

[Stefan jL]

Steven do you think you could add support for GIMIC?
http://gimic.jp/index.php?Getting%20Started%20with%20GIMIC

It is a USB device that can hold soundchip boards like OPL3 and YM2151, but the most interesting is the YM2608 board ( also know as OPNA) as it is software compatible with YM2149. I don't know how difficult it is to add GIMIC support to Steem but if you find it interesting then please do a try even if you don't have the device, i can test for you

There is a Dosbox build that support GIMIC with OPL3 sound board, maybe it helps to look at the source to understand more quickly if it is possible add GIMIC to Steem, but with the OPNA module then of course.
Dosbox for GIMIC source:
http://www.vesta.dti.ne.jp/~tsato/software.html

It requires a control.. thing..? also... called (C86CTL.DLL) i don't know much as all info is in japanese, but it is a DLL you put in the same dir with the program you gonna use with GIMIC.
Pictures here:
http://gimic.jp/index.php?USB%E5%88%B6%E5%BE%A1FW
And it's source:
https://launchpad.net/c86ctl