Steven Seagal's Atari ST Web Site

Steem

"Today You Emulate"

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

 

 
 

 IPF support

 
 

 
  Here is Crystal Castles, a great game and the first IPF disk image I had the pleasure to see loading in Steem.

You need the DLL CAPSimg to use this new feature, and floppy disk images made with the Kryoflux hardware. The extension of those disk images is IPF.

Very preliminary. For the moment only some disks like this one load. But it's a start.

There must be some silly missing bit somewhere.

 
     
 

Magnetic Scrolls loader

 
 

 
  Is this Gandalf? It was frustrating as The Pawn was the first disk I tried, and the silly bit I was talking about prevented it from loading. This one has been fixed, thanks to a comparison with the Pasti version (I'm on my own for this).  
  There are more things to take care of, like the drive led, snapshots, etc. And probably bugs, only some disk images have been tested.  
     
 

Burger Man

 
 

 
  After some debugging, we get this program to load fine, which is better than this:  
 

 
  This is what happens when you forget to check that PSG port for side... please keep in mind that I started with very poor knowledge of floppy disk drive emulation.  
     
 

Turbo Outrun

 
 

 
  Same cause for this one, and not some horrible problem of DMA (Direct Memory Access) timing like I feared at first. In fact, emulating the WD1772 controller with a 'HBL' resolution (every 512 CPU cycles) and approximate DMA emulation is enough for this delicate loader.  
     
 

Lethal Xcess

 
 

 
  What a fine game and what a fine case for emulation! To have the IPF image loading, we must hack the WD1772 emu. Still investigating but for the moment I think this hack compensates something missing in the emu itself (in CAPSimg.dll). The disk was dual format Amiga/ST (like the great Starglider 2, which also works, but is password-protected).

The hack will not be present in the release version of Steem 3.5, so as not to interfere in case the CAPS library was corrected.

After this I thought it was OK, but it wasn't...

 
     
 

Vindicators

 
 

 
  A little bug in the custom DMA chip emulation had this one stuck on 'loading'. I think the fix vindicates my approach.  
     
 

Archipelagos

 
 

 
  Another little DMA fix for this one that kept on crashing... a disadvantage of those exact copies of the originals is that the game isn't cracked! I hope you kept your damn manual...  
     
 

Double Dragon II

 
 

 
  The Revenge! I'm not sure it's a great game, but it revealed a little drive interrupt bug in my code.  
     
     
  It should be mentioned that IPF support in Steem improves thanks to... Pasti, the Steem boiler and nobody else!

It is by comparing the output of both emulations for those games that I could fine tune IPF/Steem. Now it's in, dudes! Well, more or less... Other features (fast speed, write support...), if they're indeed desirable, could be for another version. What we get here is good enough for v3.5.

Today every write command triggers an annoying popup message window telling you the command isn't implemented. Most games work despite this, one that doesn't is Sundog.

Note that just like HD6301 emu, this one is another drag on your processor. It is run only if you have some IPF disk in a floppy drive.

 
     
 

AVI support

 
 

 
  There will be another cool new feature in v3.5, a 'record to video' facility using the AVI format.

You need to assign a shortcut for that. You use it for both starting & stopping recording.

The video will be saved in Steem's directory as 'SteemVideo.avi', erasing the previous file if necessary.
If the MPG4 codec is in your system, it will be used, if not the MSVC codec will be used.

Sound isn't compressed and the result is so so, but you can already create videos in Steem. I didn't want to use "directshow" right now (need SDK?), but I'm not sure it would be far better. Maybe the attempt will be made for another version.

Note that some users complain of Steem recording the whole screen, no idea why yet.

 
     
 

UnRAR support

 
  In Steem 3.5, you may directly load your RAR files in the disk manager. It uses the free unrar.dll, which must be accessible (in Steem's directory or in a system path).  
     
 

NEOchrome snapshot

 
  Beside other formats, you now can take a snaphot in NEO format (an Atari format). It can be handy in some cases. I needed it for a little surprise I'm preparing for the next release...

Notice that if you place the FreeImage DLL in Steem's directory, a lot of other formats are available. This facility was already present in Steem 3.2 but I wasn't aware of it until I tried to add the NEO format,  hence the notice, many Steem users could be ignorant of this great feature.

 
     
 

6301 emulation

 
 

 
  Captain Blood is one of the rare programs (I know of) using the clock included in the 6301 chip. Investigating why the clock seemed to run too fast, I first blamed the hardware, of course, before checking my code... well there were a few bugs inside, so thanks Captain for revealing them!  
     
 

Delay loading the DLL

 
  It's a very interesting problem but it has little to do with emulation. It's more a generic coding issue. A DLL is a dynamic link library. Steem uses quite a few DLL now, and will do more in the future:

unzipd32.dll, unrar.dll, CAPSImg.dll, pasti.dll, etc.

There are 3 main ways of loading a DLL. You may (1) link it directly in your C++ project using lib files; you may (2) use Windows functions to open the DLL dynamically and find all the functions in the DLL. Or you may (3) directly link using lib files, but you instruct the linker to load the DLL dynamically at the first function call in the DLL (the linker actually generates code).

The problem with method (1) is that if the DLL isn't found at startup, your program will display an error message box and leave at once. With method (2), your program may run with or without the DLL, but you must assign all functions of the DLL to your own function pointers, which is heavy and error-prone. Method (3) is the best because you use the functions of the DLL as defined, so no pointers, and the DLL may be missing at startup, it will only be a problem at the first function call.

Problems of method (3) are that if you don't pay special attention, the DLL missing will cause a horrible crash instead of just quitting, that the way to set it up is a bit obscure (linker options), and non-standard. Steem must compile in both Visual Studio 6 and Borland C++. Each compiler/linker has its way, and its lib format! Thankfully, there's the internet, there are tools and we should have it working fine in both builds now, for some of those libraries.

It took some pain but does simplify code (need no 'capsplug' for IPF support for example).

http://msdn.microsoft.com/en-us/library/vstudio/151kt790(v=vs.100).aspx

http://edn.embarcadero.com/article/28515

http://www.codeproject.com/Articles/9428/Delay-Loading-a-DLL

http://www.codeproject.com/Articles/3499/Delay-Loading-DLLs

 

 
     
 

Titan

 
 

 
  Titan didn't work in Steem 3.2. It worked in STE mode since v3.3 (CPU fix) and will now work in STF mode as well (IO fix, thx to Petari). So this game demanded titanic efforts.  
     
 

Pasti-aware

 
 

 
  The mention in the disk manager window title should make it clear whether Pasti is handling disk emulation or not. Simple, I'll just pass on the crashes I had while adding this little thing.  
     
 

Cernit STE

 
 

 
  Trying to fix this screen of the demo for Steem (working fine in Hatari), it seems it was broken because of the way Steem rounds cycles didn't work in this case (ADD, ADDA).

This means that there could be more problems of the same kind!

In fact, CPU emulation in Steem is very good, but knowledge lacked at the time concerning rounding and prefetch in the ST, and those aspects are not so good, which has been compensated by some hacks, there was no other way. It is not so hard to undo and correct, it just will take time and method, if we don't want to break all the working cases (and do we?)

 
     
 

Summer Delights (STE)

 
 

 
  This also fixes the similar effect in this other DHS demo in Steem, which is now 100%.  
     
 

Wake Up State

 
     
 
The STF can awake to one of two states depending on chip temperature and other random variables!

This state dictates how access to the bus is shared between the CPU and the video shifter (to simplify) for every chunk of 4 cycles.

Wake-up states: how every 4 cycles are shared

State 1
+-----+
| CPU |
+-----+
| MMU |
+-----+


State 2
+-----+
| MMU |
+-----+
| CPU |
+-----+

The way to share doesn't change after start-up and is the same at the start of every scanline. One can imagine that shifter tricks depend on the wake-up state. This is in fact how programmers got aware of it, by seeing strange behaviour on some STs at times.

 
     
 

 
  It's not that the MMU wake up state of the Atari ST is precisely emulated, but at least we're trying. Having this apart option will encourage us to probe this mystery. Apparently, both STF and STE know a wake up state, but it's different on the STE.

STE would be in state 1 all the time for cycle sharing, but there would be a variable delay in the palette update delay. To make it simpler, 'wake up state 2' changes only this delay for the STE.

 
     
  And so now you have the pleasure of beholding this familiar picture with some spots (STE WU1):  
 

 
     
  And here in STF WU2:  
 

 
  Steem SSE, the quality emulator! We're just having fun, right?

Note: the different size of the window is a SSE option.

 
     
  Later, we decided to enforce the alternative MMU/CPU in a more serious way: reads/writes to the video registers are delayed if the cycles belong to the MMU/shifter. As this could be a breaking change, an option was added:  
 

 
  You can set the ST in wake-up state 1 or 2 or just ignore wake-up state.  
     
     
 

Prefetch Timing

 
  Prefetch for a microprocessor means loading the next instruction (or more) while an instruction is being executed.

To learn more about prefetch on the 68000, check this article by ijor:

http://pasti.fxatari.com/68kdocs/68kPrefetch.html

Before this article, very little was known about prefetch on the M68000, the concept was still mysterious.

Steem authors had to try things out and see if they worked with games and demos.

They did an amazing work, so many demos already work in Steem 3.2 because the timings globally are very good, but unfortunately the prefetch timings weren't well placed in general. They came at the start of an instruction, even before operands of the current instruction were gathered. It doesn't make sense if you know that operands and instructions follow the "PC" (program counter) and the next instruction is fetched while the current one is being executed (all directly commanded by microcode), but there was much confusion about prefetch really (and about "extra prefetch").

 PC -> PC -> PC -> PC -> PC ->
Instruction 1 Operand 1 Operand 2 Instruction 2 Operand 1

In the table above, it's clear that instruction 2 can be fetched only after operands 1 & 2 of instruction 1 have been fetched.

Steem authors suspected that something was wrong, as indicated by a comment in MOVE, where the premature fetch must be compensated later in the instruction, with strange things like INSTRUCTION_TIME(10-4);

A consequence of this premature fetch timing is that memory was read too late in emulation. In particular when reading the shifter counter, Steem was 4 cycles backward. To make up for that, so that programs work, the value returned is different from what a real ST would return at the same cycle. In other words, it's a hack compensating wrong timings of almost all instructions! Steem authors weren't aware of that, they just returned the value that worked.

Note that the exact same problems seem to plague Hatari (AFAIK, v1.6.2)!

Hopefully, the "read SDP" hack will be removed in Steem v3.5 (depending on... timing).

It remains to be seen if other parts of emulation were dependent on bad timings.

 

 
 

WD1772

 
 

 
  Integrating IPF support in Steem has had some positive consequences: insights gained through reading the WD1772 disk drive controller doc and the CAPS source - not to mention Hatari - may be useful in Steem's native drive emulation as well. Steem 3.4 already loaded demos Overdrive by Phalanx (here the infamous boot screen on which Steem was stuck) and Blood by Holocaust only thanks to sordid hacks, of which I was actually proud but that just circled around emulation inaccuracies.

Now the Disk manager option Accurate Disk Access Times (ADAT for those in the known) is even more... accurate.

 
 

 
  This is a good taste screen by "Holocaust".  
     
  The ADAT option is here:  
 

 
  Notice the little snails, they were already there.

Also notice that those two demos, that are well worth checking, already were running in Pasti mode (fall back on it if the new feature doesn't work well).

After that, of course, I just had to debug a bit: BIG demo, Darkside of the Spoon, etc., were broken!

 
     
 

Aladin

 
 

 
  A little CPU fix has the Macintosh emulator Aladin working (again?) in Steem. That's what you want, right? In Windows (or in Wine!), you launch the Steem emulator, and in the Steem emulator, you run the Mac emulator. Makes sense.  
     
     

 

Previous screen

Next screen

Games

Demos (1) (2) (3)

Apps

Steem