This was my wish for
longer time, and as we now have Steem sources published, I did
it: purpose is very specific: easier and faster trackdown
of 68030 incompatible code parts in Atari ST SW, mostly games.
68030 (and some others in family) has different stack frame than 68000, what makes troubles (crashes) with SW where we have some stack manipulating code.
Example code snippet: subrutine where we have: move sr,-(sp) ; some code .... ; rte . It will return to caller on 68030, but sp will get incorrect value after rte, as by 68030 it changes by 8, not 6. We need to replace it so that ends with: move (sp)+,sr ; rts . Instead rte . And there are some other examples, often not so simple to understand. But for work on TT, Falcon we must to correct those code parts, according to different stackframe.
The hard part is to find this stackframe incompatible parts. On real HW tracing is very hard, especially by games which take usually complete control over machine, so debugging SW will not work. So, idea to use some emulator's debugging is normal. Steem Debugger has very advanced tracing possibilities, history etc. Much-much better than Hatari. But emulates not TT or Falcon.
The problem by tracing is that crash and program run errors appear not right by 'bad' code, but later, because rte, rts usually jumps back to correct place, only that stack is corrupted. So, crash comes later, many times much later, after possible longer executions. This is where history (of Steem Debugger) may help a lot.
This mod is based on changing Steem's 68000 CPU emulation - to have stackframe as 68030 by usual interrupts, traps and rte. So, partially 68030 compatible CPU emul. And it should be enough for tracing down stackframe related problematic parts. Of course, not other TT, Falcon incompatible code, what is another and long story. To be able testing SW without special acrobatic we need proper TOS modding too. What I had already done in pretty large % in past (GOS) . Concrete, some TOS modded so, that is compatible with 68030 stackframe. TT, Falcon TOS are of course no usable in Steem. I took my so called TOS 1.08 from 2009, what is actually combination of TOS 1.04's GEMDOS, BIOS part and TOS 2.06's Desktop, AES. It is good, as I disassembled GEMDOS part, and already made it 68030 compatible, while Desktop, AES of 2.06 are already 68030 compatible, except small detail by loading NEWDESK,INF (corrected). Basically, what is needed to change in TOS are Trap calls, where some stack manipulating is.
I changed drive icons too in Desktop, just to have some sign of special version. Otherwise, it is surprasingly good working combo of TOS 1.04, and 2.06. In any case good for this purpose.
Of course, it is possible to mod any TOS version ( for ST(E) ) that work with 68030 stackframe, but it is lot of work. Just to say: Desktop of TOS 1.04 uses Line-F emulator of CPU, and there is a lot of stackframe incompatible code, what all must be corrected.
Steem modding was much easier than I expected: needed to change only 2 lines and add 1 line in sources. And it showed as really usable - I already found problematic parts in 3 games, after shorter tracings.
Usage: only for experienced 68000/68030 knowers, coders, games adapters and similar. Only Steem Debugger has sense with this. This version works basically same as regular Steem Debugger, you can use Gemdos emulated hard drives, Pasti emulated ones. Don't run regular SW with this. Only purpose is tracking down ...
Not tested yet much, but games are fine runneable. Problems may appear by HW, CPU detection. Tester should take care about detections in his SW, as it will hardly happpen that CPU will be detected as 68030, so to test corrected code right in this, you need to set your tested SW that activate code changes for 68030 even in STE environment.
Modded TOS has version 1.08 in header, what is good for Steem. But it can be used even in Hatari, in TT mode. Then must change TOS version to 3.06, otherwise Hatari will refuse it.
Well, I don't expect that it will be something used by thousands :-) Use at own risk - and I believe that this, same as regular Steem (Debugger) will not damage any of your data, even after zillions of crashes. By me such never happened (I don't mean crash in emulation here :-) ).
While at Steem modding, I corrected 2 annoying bugs: first is bad date/timestamp shown (and used) by files in GEMDOS hard disk emulation. Instead time of file's last modification creation time is shown. It is incorrect, as TOS (and DOS) shows time of last modification on file. So, replaced CreationTime with LastWriteTime in stemdos.cpp . Other bug corrected is in floppy disk image creation - Steem creates only 1 FAT on floppy images. Here it creates correct 2 FATs and FAT length is set to better size too.
Download - modded Steem Debugger, special TOS 1.08 for, and short usage.
PP, Dec. 2011.
68030 (and some others in family) has different stack frame than 68000, what makes troubles (crashes) with SW where we have some stack manipulating code.
Example code snippet: subrutine where we have: move sr,-(sp) ; some code .... ; rte . It will return to caller on 68030, but sp will get incorrect value after rte, as by 68030 it changes by 8, not 6. We need to replace it so that ends with: move (sp)+,sr ; rts . Instead rte . And there are some other examples, often not so simple to understand. But for work on TT, Falcon we must to correct those code parts, according to different stackframe.
The hard part is to find this stackframe incompatible parts. On real HW tracing is very hard, especially by games which take usually complete control over machine, so debugging SW will not work. So, idea to use some emulator's debugging is normal. Steem Debugger has very advanced tracing possibilities, history etc. Much-much better than Hatari. But emulates not TT or Falcon.
The problem by tracing is that crash and program run errors appear not right by 'bad' code, but later, because rte, rts usually jumps back to correct place, only that stack is corrupted. So, crash comes later, many times much later, after possible longer executions. This is where history (of Steem Debugger) may help a lot.
This mod is based on changing Steem's 68000 CPU emulation - to have stackframe as 68030 by usual interrupts, traps and rte. So, partially 68030 compatible CPU emul. And it should be enough for tracing down stackframe related problematic parts. Of course, not other TT, Falcon incompatible code, what is another and long story. To be able testing SW without special acrobatic we need proper TOS modding too. What I had already done in pretty large % in past (GOS) . Concrete, some TOS modded so, that is compatible with 68030 stackframe. TT, Falcon TOS are of course no usable in Steem. I took my so called TOS 1.08 from 2009, what is actually combination of TOS 1.04's GEMDOS, BIOS part and TOS 2.06's Desktop, AES. It is good, as I disassembled GEMDOS part, and already made it 68030 compatible, while Desktop, AES of 2.06 are already 68030 compatible, except small detail by loading NEWDESK,INF (corrected). Basically, what is needed to change in TOS are Trap calls, where some stack manipulating is.
I changed drive icons too in Desktop, just to have some sign of special version. Otherwise, it is surprasingly good working combo of TOS 1.04, and 2.06. In any case good for this purpose.
Of course, it is possible to mod any TOS version ( for ST(E) ) that work with 68030 stackframe, but it is lot of work. Just to say: Desktop of TOS 1.04 uses Line-F emulator of CPU, and there is a lot of stackframe incompatible code, what all must be corrected.
Steem modding was much easier than I expected: needed to change only 2 lines and add 1 line in sources. And it showed as really usable - I already found problematic parts in 3 games, after shorter tracings.
Usage: only for experienced 68000/68030 knowers, coders, games adapters and similar. Only Steem Debugger has sense with this. This version works basically same as regular Steem Debugger, you can use Gemdos emulated hard drives, Pasti emulated ones. Don't run regular SW with this. Only purpose is tracking down ...
Not tested yet much, but games are fine runneable. Problems may appear by HW, CPU detection. Tester should take care about detections in his SW, as it will hardly happpen that CPU will be detected as 68030, so to test corrected code right in this, you need to set your tested SW that activate code changes for 68030 even in STE environment.
Modded TOS has version 1.08 in header, what is good for Steem. But it can be used even in Hatari, in TT mode. Then must change TOS version to 3.06, otherwise Hatari will refuse it.
Well, I don't expect that it will be something used by thousands :-) Use at own risk - and I believe that this, same as regular Steem (Debugger) will not damage any of your data, even after zillions of crashes. By me such never happened (I don't mean crash in emulation here :-) ).
While at Steem modding, I corrected 2 annoying bugs: first is bad date/timestamp shown (and used) by files in GEMDOS hard disk emulation. Instead time of file's last modification creation time is shown. It is incorrect, as TOS (and DOS) shows time of last modification on file. So, replaced CreationTime with LastWriteTime in stemdos.cpp . Other bug corrected is in floppy disk image creation - Steem creates only 1 FAT on floppy images. Here it creates correct 2 FATs and FAT length is set to better size too.
Download - modded Steem Debugger, special TOS 1.08 for, and short usage.
PP, Dec. 2011.