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