Steven Seagal's Atari ST Web Site


page 1 - page 2 - page 3 - page 4 - page 5



"Pending Danger"

  Fifth screen of brags for v3.7.  



The MC68901 multi-function peripheral (MFP) is a member of the M68000 Family of peripherals of Motorola.

It was used on the Atari ST and that's quite a nasty chip to emulate. Its clock isn't a simple fraction of the CPU's. Coordination with the CPU is intricate. Double use of some timers is confusing.


New Option


  A new option is dedicated to MFP improvements because those require more CPU power.

By the way, option names are changed again.
C1 and C2 stand for chipset 1 and 2. Chipset 1 covers the MC6850 ACIA, the HD6301 IKBD and the MC68000's E-clock. For the moment Chipset 2 only covers the MC68901 MFP.
When the options are checked, emulation switches to a lower level for more precision.

The options are also indicated as C1 and C2 in the status bar.



  Since v1.7, Hatari boasts some MFP improvements that I tried to cheaply, quickly imitate in Steem. Those hacks "worked" somehow but only in some cases.

In Steem v3.7, it's done more thoroughly at least for interrupt acknowledge (IACK).

When some chip like the MFP wants to interrupt the CPU, it asserts an IRQ (interrupt request) line. The CPU sees that and starts an IACK cycle, asking the MFP for a vector (a number converted to an address). It may happen that another interrupt, of same or higher priority, gets pending during this interrogation latency. In that case, the MFP will clear that later interrupt and send the corresponding vector to the CPU.

It happens all the time and is sometimes important.


  There was an anomaly with this demo. After MFP improvements, the screen was flickering. The timers had been made more precise, but now they were in conflict and this wasn't handled (previous hack only worked with the same interrupt pending twice, like Final Conflict, Froggies/OVR).  

GPIP/IRQ delay

  If the GPIP input has just transitioned, IRQ hasn't fired yet, as documented by Motorola. Emulating this allows us to run V8 Music System without hacks.  

  This was already running in Steem SSE so for you, the player, it changes nothing.  

Writing Delay


  It's not that good a demo, just some music, but very interesting for emulation.
This will now work in Steem with snappy power.
The reason why the music played too fast and the program didn't respond was some delay the MFP needs to work the data it just received from the CPU (about 4 cycles), that wasn't emulated yet. This gives the program time to stop the timer before it gets into its infinite loop. Once it's in it, no IACK delay could save it, the routine is too long, the timer too short, the interrupt will always be pending on the RTE no matter what. I do hope this is the definitive explanation because I've lost enough time on this one. I even wonder if the accelerated version isn't better.

Spurious Interrupt


  To obtain this nice result, we had to add a new function in MFP emulation!
There are 24 bombs because the spurious interrupt vector starts with $18 (24).
This happens when the MFP asserts IRQ just before the program changes the conditions in the MFP registers, voiding the IRQ. The CPU has started an IACK cycle regardless, and when the MFP doesn't answer, the GLUE chip triggers a bus error. The CPU interprets the signal as spurious interrupt because it happens in the middle of an IACK cycle.

In the case pictured above, we get all the bombs and the mouse cursor still moves. Depending on exact timing you may have a reset instead, or fewer bombs and freeze.

This was generally caused by programmer error. So it's an important feature for programmers who code against an emulator: code apparently working in Steem would crash on a real ST otherwise.


  Or here, caused by emulation error, another artistic screen, illustrating the fact that this new function could well break programs working until now. It's another reason for the new 68901 option. But it's so fun!  

Timer precision

  Contrary to other emulators, Steem uses a ratio held in a double variable to convert MFP cycles into CPU cycles. Since v3.5.1, the fractional part of those cycles is handled. In v3.7, cycle accuracy is guaranteed, whatever the CPU clock.  

CPU Clock fine tuning


  The hack supreme!
It changes the CPU clock relative to the MFP's (so: the ratio).
I did it for myself, to experiment in real time (!) with this very important parameter, and I give it to everybody who's interested. Needless to say it's a dangerous option, better left unchecked.


Previous screen

Next screen

Games (1) (2)

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