Steven Seagal's Atari ST Web Site


page 1 - page 2 - page 3 - page 4


"Siege of Emulation"

  Development screen of Steem SSE 3.8.0  



If it ain't broke, don't fix it, say people who don't want us to have fun.

Here's a cool collection of broken program screenshots due to some major timing refactoring.

Technical note: In Steem, screen "events" such as scanlines, blanks, interrupts, were scheduled on a frame basis, according to Shifter frequency: 50hz, 60hz, or 72hz.

That made it relatively quick and robust.

But many ST programs, using all sorts of Shifter (or GLU) tricks, mix 50hz, 60hz or 72hz lines within the same frame, and timings in Steem were hard to adapt to this. The typical case is the demo setting video at 60hz at the start of the frame then at 50hz to actually display lines. Steem could handle some of these, but the frame would end at the wrong timing, with or without consequences.

Previous versions of Steem SSE contained various hacks that corrected the timings in most cases, but it could be a headache.

In v3.8, we do away with the frame schedules. Much like the real GLU, a function computes screen events line by line, using a counter instead of a table. It's less quick and robust, of course, but it saves memory and is less confusing for mixed frames. It makes Steem a (still) more low-level and faithful emulator.

That's a very big internal change in Steem, and implementation was progressive, as illustrated on this page.


  Right border is fine, but not the bottom one in the Amiga demo.  

  Part of bottom border is right, not all.  

  The scroller displayed as if it was monochrome.  

  No bottom or top overscan, yet both left and right borders are OK.  

  Here we get the top. There's another "off by one" error.  
  Only Steem could correctly display 3615GEN4-ULM demo... for the moment it looks compromised.  
  Our little "hacks" don't help us much here.  

I spent hours on this silly bug, it was recently introduced too. Steem thought it was in HIRES at some point. The scroller still right because the video counter is set during the frame.

  European Demos, pretty bad, like the European Union. Oops, a political opinion.  

Far better now but the same "off by one" bug kills the bottom overscan.

Too bad we can't fix the European Union.


"Forest" can make GLU miss a VBL. What then? The good news is that you get this message instead of a real program crash. My little "safeguard" worked (C++ try block).


Not a good emulator? How dare you?

It worked, then not, then again, because of compensating bugs. Now it works naturally in Steem, without any compensating hack.

  It's dead! On the other hand the Kraftwerk music is still playing  
  Then it will soon crash.  
  No crash but the display isn't great.  
  Fine! Only missing vertical overscan.  
  Another effort and it will be OK...  

Nice screen but it should be fullscreen...



No overscan, shifted display.

By the way, it's not Jambala as indicated, it's Tekila.



Let's just call it Surecrash 49% then.



The Dragonnels demo is very interesting for emulation.

On this screen, we have a nice example of broken HBI/VBI interaction. The VBI writes 34, the HBI counts down to 0. One too many or too few and vertical overscan is lost.

Like many others, this screen was also trouble to resume right on loading snapshots. This problem kept me from removing the VBI timing hack in Steem for a long time.

  And now the good news, some improvements at last...  


This actually is the way Panic v1 should display on a STE.

But it now works in STF mode without any trick (option C2). I don't claim this as an improvement though, because it's not supposed to work on most STFs, though people who could have provided feedback didn't.


  And this is how the Ultimate GFA Demo should look on a STE. Quite similar issue, with a shift and only the right border missing.  

Time Slices


  Refactoring allows us to support a monochrome demo that uses STE abilities, Time Slices. Somehow, don't know what made the difference. In previous versions of Steem, it was really bad.

We still needed to add raster effect support. Like monochrome hardware scrolling, this is emulated in C++, not in assembly. Fortunately, as there is only one bitplane, performance is still acceptable.

Monochrome HSCROLL emulation was already in v3.7 of Steem SSE. I was happy to see that it worked, as it hadn't been tested before.

The result isn't too bad, considering we're still using the same basic rendering system for monochrome mode.

A further step could be to add real-time rendering like for colour scanlines.




  It is time for a disclosure: Steem SSE v3.8 will support a new demo by Sync shown first at STNICCC 2015, called Closure.

Thanks to video timing refactoring, and the fact that wake-up states were already handled in Steem SSE.
Despite this new progress, emulation of wake-up states is still tentative (many hacks...).

Important: You must select a wake-up state on the Machine option page for it to work, and accurate disk access times in the Disk manager for it not to crash later. Option Hacks for WS1 and 2.

STE: WS1; STF: not WS1



  Not only the video side has been refactored, but also the way cycles are counted in general.

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:  
          | MC68000 MPU   |<--
          |               |   |
           ---------------    |
                              |                           ----------
                              |<------------------------>|192 Kbyte |<--->EXPAN
                     ---------|------------------------->| ROM      |
                    |         |                           ----------
                    |         |                           ----------
                    |         |                          |512K or 1M|
                    |         |                       -->| byte RAM |<--
            ----------        |        ----------    |    ----------    |
           | Control  |<----->|<----->| Memory   |<--                   |
           | Logic    |-------|------>|Controller|<--                   |
            ----------        |        ----------    |    ----------    |
             |||||            |        ----------     -->| Video    |<--  RF MOD
             |||||            |<----->| Buffers  |<----->| Shifter  |---->RGB
             |||||            |       |          |        ----------      MONO
             |||||            |        ----------
             |||||            |        ----------         ----------
             |||||            |<----->| MC6850   |<----->| Keyboard |<--->IKBD
             |||| ------------|------>| ACIA     |       | Port     |
             ||||             |        ----------         ----------
             ||||             |        ----------         ----------
             ||||             |<----->| MC6850   |<----->| MIDI     |---->OUT/THRU
             ||| -------------|------>| ACIA     |       | Ports    |<----IN
             |||              |        ----------         ----------
             |||              |        ----------         ----------
             |||              |<----->| MK68901  |<----->| RS232    |<--->MODEM
             || --------------|------>| MFP      |<--    | Port     |
             ||               |        ----------    |    ----------
             ||               |                      |    ----------
             ||               |                       ---| Parallel |<--->PRINTER
             ||               |                       -->| Port     |
             ||               |        ----------    |    ----------
             ||               |<----->| YM-2149  |<--     ----------
             | ---------------|------>| PSG      |------>| Sound    |---->AUDIO
             |                |       |          |---    | Channels |
             |                |        ----------    |    ----------
             |                |                      |    ----------
             |                |        ----------     -->| Floppy   |<--->FLOPPY
             |                |<------| WD1772   |<----->|Disk Port |     DRIVE
             |                |    -->| FDC      |        ----------
             |                |   |    ----------
             |                |   |    ----------         ----------
             |                |    -->| DMA      |<----->|Hard Disk |<--->HARD
             |                |<----->|Controller|       | Port     |     DRIVE
              ----------------------->|          |        ----------


  The CPU accesses RAM and the Shifter through the MMU, which forces it to share cycles with the video system. All the rest is directly available on the bus.

It's quite clear but I guess most emulator programmers didn't get the message. I know it didn't strike me at once.

In v3.8, we endeavour to eliminate rounding for GLU, MMU, ROM or IO accesses (not the cartridge yet).



  "Cycle-precise" ACIA/6301 transmission (before, there was a 512 cycle imprecision), using the "event" system.  



  Finally, aspects of MFP emulation (when option C2 is checked) have been refactored.

IACK cycle and latch delay are now handled in "real time".

Instead of looking up which timers will trigger during IACK, we just trigger events themselves, related or not to the MFP.

And a new "event" was created to emulate the latch delay when writing to MFP registers.



Previous screen

Next screen

Games (1) (2)

Demos (1) (2) (3) (4)



Other downloads