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.
Testers and bugs
Moderators: Mug UK, Steem Authors, Moderator Team
- Steem Authors
- Steem Developer
- Posts: 540
- Joined: Tue Apr 30, 2002 10:34 pm
- Location: UK
- Contact:
Re: Testers and bugs
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)
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)
Steem - http://steem.atari.st/
Re: Testers and bugs
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.
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
- Steem Developer
- Posts: 540
- Joined: Tue Apr 30, 2002 10:34 pm
- Location: UK
- Contact:
Re: Testers and bugs
Fair enough - hope someone else picks up the fix.
Steem - http://steem.atari.st/
- Steven Seagal
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
- Contact:
Re: Testers and bugs
This has finally been fixedDio wrote: 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 didn't know the x86 crashed on overflow.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
- Steven Seagal
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
- Contact:
Re: Testers and bugs
In fact original Steem didn't wait, that's why Audio Artistic Demo didn't work, it was fixed in the "SSE" version.Dio wrote: 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.
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.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
- Steven Seagal
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
- Contact:
Re: Testers and bugs
[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.
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
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse