Eero Tamminen wrote:To get (much!) smaller binaries and avoid MiNT GEMDOS calls with GCC, it's enough to use C-library intended for TOS. For example:
npomarede wrote:As for the game, it seems it was compiled with 68020 mode instead of 68000 only, but I can't tell what options should be used. As Eero suggested, maybe just use another C compiler.
AtariZoll wrote:Considering fixing Timer-B rutine: just use something like lea label(pc),a1 ; cmp.l #address,(a1) instead 1 line code . Then compiler will not generate invalid code for sure.
AtariZoll wrote:And I see there space for making it little faster, shorter. Use movem for saving to stack and restoring 3 registers at once , instead 3x move ...
Code: Select all
Code: Select all
AtariZoll wrote:There is move.w (a0),d1; move.w d1,(a1) instead move.w (a0),(a1) .
AtariZoll wrote:Movem requires that data registers be listed first. So:
Order is actually false in second case, but it is done so, to make it easier for coders.
chicane wrote:As for using a different C compiiler - I'm really not sure that this is a realistic option. As far as I know, gcc is the only C compiler capable of generating sufficiently optimised binary output to support this type of game. The optimizations it performs are pretty astonishing in some cases - things that you'd never imagine a compiler would do. Given that all of the alternatives are 20+ years old, I can't see the level of optimisation they offer to be anything like as sophisticated as that of gcc.
In summary, I reckon my best option is to simply rework the Timer B routines to use different instructions that don't get "optimized" to 68020 code by gcc. I can't see it being a massive amount of effort.
chicane wrote:Eero Tamminen wrote:To get (much!) smaller binaries and avoid MiNT GEMDOS calls with GCC, it's enough to use C-library intended for TOS. For example:
I'm already using libcmini for this project - I like it a lot
AtariZoll wrote:Btw. I seen strange things in executables - there are some TOS calls, with high function numbers, most likely for Mint only. What they do in PRG intended for 520 ST and old TOS ?
AtariZoll wrote:Draw error under EMUTOS happens most likely because it uses more RAM, and as is explained, game don't like it.
Eero Tamminen wrote:AtariZoll wrote:Draw error under EMUTOS happens most likely because it uses more RAM, and as is explained, game don't like it.
Draw error looks same regardless of whether it's 1MB, 2MB or 4MB Atari, so the error isn't at least due to lack of RAM.
AtariZoll wrote:It has nothing with how much RAM is in machine.
Marakatti wrote:Tried this on my STe yesterday. It gave three bombs when the gamescreen appeared. It's a 4meg Tos 1.62. I was running it from cosmosex and usb-stick. Also tried from msa-image but no luck
AtariZoll wrote:Good framerate, really.
I don't know is that because video recording (done with Hatari, I guess) but sometimes objects on track side move funny - little back in some frames.
Visible for instance about sec. 35-37 from start - right side panels.
Users browsing this forum: No registered users and 5 guests