Steven Seagal's Atari ST Web Site


"Out for a Bug"

  Coming soon! Features, fixes, hacks, etc. for Steem SSE 3.5.3.






  Argh!!! Here it is already, the first bugfix of v3.5.3.

On the ACIA chip (MC6850), the first byte you write will be copied in the shift register pretty soon (time of one scanline), but as long as it isn't, the status register won't indicate 'free'.

  And this is Hades Nebula when we overrate this delay:  


  Nice screen!

Also the Pandemonium Demos are sensitive to this 'fix' because of the insane way the loader floods the ACIA with data.

This is still just an approximation, but it seems that it snaps at 240 CPU cycles. So we stop at 200 instead of 512 now.


Wake-up states

  LJBK at atari-forum (this thread) is doing interesting work on the ST's (in)famous video shifter, finding ways to shift the screen at the cost of very few CPU cycles. It offers scrolling possibilities but it depends on the wake-up state. He identified no less than 4 states!

For the moment, we recognise only 2 wake-up (WU) states in Steem, 1 and 2.

  So if you ignore WU state:  

  And you launch beeshift0 you get this:  

  For some reason the program thinks that Steem is in WU4!

And then you get a badly shifted bee:


  For HW detection to work, right border removal by shift mode changes must work. The feature was in original Steem 3.2 (guess who removed it...).

If not, you get this kind of irritating screen (this reminds me of Forest):


  OK. It's been reintegrated. Now this program will detect WU1 and 2...  

  ...and the bee shifts in a better way. Still not perfect because of the gross hack I use at rendering stage.



  And now the funny part. When you leave to the desktop (F1) the shifter is still unstable and you could get something like that, which is probably correct emulation (here beeshift5):  

  Steem, the quality emulator!

Note that changing the WU state option will always "reset" the shifter, so you can get a correct display.

Update: forget it, this wasn't correct emulation (too bad) as 60hz scanlines should reset the shifter as well.

But that will correctly work for program TOSHIFT.TOS on the same disk.


Shifting bee in action

  Pay attention to the side borders, this is the point of this program.  




Beware! It's getting closer.

Trying to make it look like here:

At first I thought - without any real reason - that the scrolling happened between the normal borders. A bit strange though!

You better see the intent in beesclr4 (4 bit horizontal sync scrolling): it's the programmer's task to hide border glitches, the result is smooth (to check this in Steem, use fullscreen at 50hz).



Download Beeshift beesclr4


Revisiting Dragon by Ghost (STF)


  This is the method: first scandalous hacks without really understanding, but the demo runs (v3.4.1, STF2), then come back later. This demo screen is part of the Overdrive Demo (slow disk drive). It runs only on a STF.

In previous versions, the top of the screen was wrong, like this:



  Thanks to progress in shifter understanding, we now can try to explain it:

At the end of the frame there's a savage and useless removal of the left border, not followed with a "stabiliser" switch. The effect is dramatic! When the left border is removed, the MMU fetches 26 more bytes than in a regular scanline. As the 4 shifter IR input registers are 16bit, they hold 8 bytes max. A scanline divisible by 8 will empty the shifter registers.The scanline without the left border has 160+26 bytes, or 160+24+2. Two bytes remain in the shifter by the end of the scanline, and the frame. As long as the shifter gets multiples of 8 bytes, there will remain 2 bytes at the end of each scanline. They're still there at the start of next frame, and as long as there's no border effect, in the top part.

The effect that must be emulated is that each of those scanlines is shifted, both the planes and the pixels. The shift in pixels is exactly 4, just like in the bottom lines, that are shifted because of the left border removal. Those lines are stabilised.

The nice thing: the shifts are compatible with those we use for the bee (see above), so it all holds up together. And it is a nice demo.

Option wake-up state. If set to "ignore", no shifter "preload" (still hesitant how we must name this) is emulated.

Update: ha ha, later on I reintroduced some dirty hacks to have the demo menu screen display correctly in WU1.


Revisiting Omega Full Overscan (STF)


  Remember this?

Depending on the WU state and other factors, overscan without a stabiliser may produce that result, where the shifter displays 16 pixels bitmap followed with 16 pixels of "border".

I stated: One day we could try to emulate this behaviour (as an option)

The day has come!


  See, I even managed to stop emulation at the exact same point in the scroller. What's still missing is the bending of top lines, maybe another version.  
  New option is here:  

  Notice that it costs some more code, some more variables in Steem, but for such "correct" emulation it's worth it, right?  

Video synchronisation


  Well, the theme of this page is out for a bug, by now I guess you understand why. This miserable insect revealed not a bug, but a limitation that has nothing to do with wake-up states. The grey pixels weren't displayed, because very precise video sync is needed for this case. Not that the pic is a lot more beautiful with them, but it's closer to a real ST.

To remedy this, and potentially other cases, we need to make a more general check. Done, and...


36.15 GEN4 100%


  This was the opportunity to improve that video RAM test, and the annoying mysterious glitch in the left border of 3615 GEN4 has now disappeared, hence the claim, 100% (compare v3.5.2 with v3.5.3). I always wondered if it was so in the demo or an emulation bug. Now we know.

Technical: In the 1st test, we were comparing the shifter counter to the address bus, with a 32 byte window.This was a problem if no "shifter event" occured before the end of the line; the counter wouldn't "move" until the end. That's the way Steem works. In the 2nd test, we compute a theoretical counter based on value at start of line, and cycles into the line. Obvious but I hadn't thought of it at once. This is a basic calculation however, wrong with some shifter effects, but we must still mind performance. We don't use the full 'Read SDP' function... yet.

Talking of it, there's no real performance issue caused by extra checks, even in debug mode. Yet it remains to be seen if some other programs are affected by this, you never know.


On screen debug info

  This improvement is rather specialised, only a minority of people, me especially, will find it useful, it exclusively concerns the debug build.

This is put here only to make the competition jealous!

Some important information debug info will now be displayed directly on the screen, much like disk drive info.

  Yes, TOS 1.02 checks for the blitter, on a STF, it causes a bus error. This is the first exception.  
  This program uses the MC68000 microprocessor trace mode, probably for protection purposes.  
  This demo uses the prefetch trick, also for protection purposes.  
  This is one of the ultra-rare demos reprogramming the HD6301 keyboard chip.  

File Associations



Now those are switches on/off

  File associations:
- Can now create and remove association in options
- Now uses registry part HKEY_CURRENT_USER, not HKEY_CLASSES_ROOT so you
don't need to run as administrator.
- Simplistic: when you associate, Steem takes the extension for itself,
disregarding other programs. When you remove the association, Steem deletes
the extension from the registry.
- No auto-association at startup, including .PRG,.TOS,.APP,.GTP,.TTP.
- No association with .STC (cartridge) possible
- Removing previous Steem associations is up to you.
- You must reassociate with subsequent versions. It's because the name of the
executable changes.
Those changes also reduce the executable file size by 4KB.



  This program uses a rather obscure feature of the disk controller (WD1772) to check the drive speed.

Here it appears slow, but it's faster in medium resolution!


  Maybe because our timing system is based on HBL (scanline) timing.  

Hey where's the beta?



Previous screen

Next screen (v3.5.3 more)


Demos (1) (2) (3)