Testers and bugs

[Dio]

Hi chaps. I exchanged a few emails with russ many years ago and it's good to have STeem back under development.

I'm doing some more ST research at the moment and writing some more testers which I will be opening up as and when possible. STeem is astonishingly accurate - did you guys write testers of your own?

One long-standing STeem bug the CPU tester found I can report straight away, a crash in divide: IIRC, if you divide 0x8000000 by -1 the x86 CPU takes an integer overflow exception and STeem crashes.

I have also found one other very small thing: the real ST waits 4 cycles before taking an interrupt after clearing the ISR in the MFP if there's one pending. The MFP tester seems to think that STeem does the wait for IMR writes but not on ISR clears.

[Steem Authors]

We did various things to try to investigate the real STE, can't remember them all now! But most of our debugging was based upon existing games and demos.

The DIVS problem you mention could be fixed with an exception code... feel free to add it to the cpu.cpp. Are you a committer on Steem? If not let me know your gmail address on steem@gmx.net and I will add you.

MFP timing one could also be committed. It might break some applications and need to be compensated elsewhere (perhaps another timing is also incorrect to compensate for this oversight, e.g. in the shifter)

Ant (Steem)

[Dio]

Thanks for letting me know. I'm really surprised you got to the accuracy level of Steem without automated regression testing. Well done chaps.

I'm rather busy with another project at the moment (plus have a bit of a dislike for SVN, I'm a Mercurial man, and I wouldn't touch gmail with a ten-foot-pole) so I wasn't planning to make changes in the near future. If I get a few spare hours I may give it a go.

However, the other project may be useful to everyone when it's done because a good chunk of it is as many reliable emulator testers as I can manage to make work.

[Steem Authors]

Fair enough - hope someone else picks up the fix.

[Steven Seagal]

One long-standing STeem bug the CPU tester found I can report straight away, a crash in divide: IIRC, if you divide 0x8000000 by -1 the x86 CPU takes an integer overflow exception and STeem crashes.

This has finally been fixed
I didn't know the x86 crashed on overflow.

[Steven Seagal]

I have also found one other very small thing: the real ST waits 4 cycles before taking an interrupt after clearing the ISR in the MFP if there's one pending. The MFP tester seems to think that STeem does the wait for IMR writes but not on ISR clears.

In fact original Steem didn't wait, that's why Audio Artistic Demo didn't work, it was fixed in the "SSE" version.
Now I can add a delay for ISR too, but I don't see any practical use, as ISR is generally cleared before the RTE, IRQ won't trigger at once.

[Steven Seagal]

[warning: for MFP experts!]

As a follow-up on this, I found a case where the ISR delay is relevant: the great game Super Hang-On.
Timer B lowers IPL so that HBL interrupt can trigger for raster animation (sky and road). Because timer B's irq is 8, no ACIA interrupt (6) will be taken.
Except when Timer B clears the service bit, right before the RTE, which messes the colour the HBI will use.
On real ST, ACIA will not trigger before the RTE because of the delay. When the MFP is "aware" of the cleared service bit, IPL has changed again.
It didn't show in Steem before because of a compensating imprecision: ACIA IRQ handled at end of scanline, not at precise cycle.

Code: Select all

Timer B
   move.l d0,-(a7)                                  ; 001AD6: 2F00
   move.w d1,-(a7)                                  ; 001AD8: 3F01
   move.l a0,-(a7)                                  ; 001ADA: 2F08
   clr.b $fffffa1b                                  ; 001ADC: 4239 FFFF FA1B
   move.l $ffff8244,d0                              ; 001AE2: 2039 FFFF 8244
   stop #$2100                                      ; 001AE8: 4E72 2100
   movea.l $23402(pc),a0 {$007658}                  ; 001AEC: 207A 5B6A
   move.l (a0)+,d0                                  ; 001AF0: 2018
   move.l a0,$7658                                  ; 001AF2: 23C8 0000 7658
   movea.l $23402(pc),a0 {$007664}                  ; 001AF8: 207A 5B6A
   move.b (a0)+,d1                                  ; 001AFC: 1218
   move.l a0,$7664                                  ; 001AFE: 23C8 0000 7664
   subq.b #1,d1                                     ; 001B04: 5301
   beq.s +8 {$001B10}                               ; 001B06: 6708
   movea.l (a7)+,a0                                 ; 001B08: 205F
   move.b d1,$fffffa21                              ; 001B0A: 13C1 FFFF FA21
   stop #$2100                                      ; 001B10: 4E72 2100
   tst.b d1                                         ; 001B14: 4A01
   beq.s -44 {$001AEC}                              ; 001B16: 67D4
   bcs.s +8 {$001B22}                               ; 001B18: 6508
   move.b #$8,$fffffa1b                             ; 001B1A: 13FC 0008 FFFF FA1B
   move.w (a7)+,d1                                  ; 001B22: 321F
   move.l (a7)+,d0                                  ; 001B24: 201F
   bclr #$0,$fffffa0f                               ; 001B26: 08B9 0000 FFFF FA0F
   rte                                              ; 001B2E: 4E73