New ST project - Pole Position arcade conversion

All about ST/STE games

Moderators: simonsunnyboy, Mug UK, Doctor Bob Gordon, ICS, Moderator Team

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2314
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Mon Aug 11, 2014 7:18 pm

What made me think that it is invalid in 68030 too is Devpac3 - as is explained. Unfortunately, even Motorola docs have errors, so I started new thread in coding section about all this. Should make list of exact instructions where pc-relative addressing is not allowed in case of 68000 .
I think that there may be other errors in Hatari, for instance with move , when destination is pc-relative addressed.
I'm not against GMO, I'm against that children play with fire.

chicane
Atari freak
Atari freak
Posts: 58
Joined: Mon Jul 02, 2012 11:25 am

Re: New ST project - Pole Position arcade conversion

Postby chicane » Mon Aug 11, 2014 7:21 pm

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:
http://www.atariforge.org/gf/project/libcmini


I'm already using libcmini for this project - I like it a lot :D

The hefty size of the executable comes not from the standard library - but a combination of game logic, graphics data and lookup tables. The lookup tables that support drawing of the track are 128k, the car graphics are around 64k, and the game logic reverse-engineered from the arcade game is around 80k ... it all mounts up! I now feel a lot more sympathy with the poor teams tasked with converting arcade games to the ST back in the day - it's a real balancing act between performance, features and graphics/sound quality when you're playing with just 512k.

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.


I've reviewed the documentation for m68k-atari-mint-gcc today and it's supposed to generate 68000 code by default. This would appear to be the case where it's working with C source files, but not where it's working with assembly source files. I did try compiling an assembly file with an explicit switch to generate 68000 code (-m68000) but it made no difference to the generated object file. I might well follow up with the maintainer at some point if I'm feeling sufficiently community-minded.

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.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2314
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Mon Aug 11, 2014 7:58 pm

I did not go in details about POLEPOS.PRG executable. There is certainly lot of routines, so judging compiler overhead is something what would need a lot of time. But first executable, for just drawing 1 screen is 35 KB, from what 31.28 is screen data, so there is 3.7 KB of code, while all what is necessary is to copy bitmap and palette data to place - 100 bytes of code is enough for that. I know, that it is not much relevant, and will be overwritten by later code, but it is just something what I consider as opposite effect than coder wants: using C for so trivial thing is for sure more complicated than doing it in ASM .

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.
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 ...
There is move.w (a0),d1; move.w d1,(a1) instead move.w (a0),(a1) .
I'm not against GMO, I'm against that children play with fire.

chicane
Atari freak
Atari freak
Posts: 58
Joined: Mon Jul 02, 2012 11:25 am

Re: New ST project - Pole Position arcade conversion

Postby chicane » Mon Aug 11, 2014 8:17 pm

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.


I've now thankfully managed to find the switch to find my 68k asm from being "optimised". So no longer any need for workarounds! The code now works on Steem without further modifications!

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 ...


I'm having problems with this - I'm not that familiar with movem. I thought I'd be able to do this:

Code: Select all

        ;move.l a0,-(a7)
        ;move.l a1,-(a7)
        ;move.l d1,-(a7)

        movem.l a0-a1/d1,-(a7)


and this:

Code: Select all

        ;move.l (a7)+,d1
        ;move.l (a7)+,a1
        ;move.l (a7)+,a0

        movem.l (a7)+,a0-a1/d1


but strange things are happening. Any thoughts?

AtariZoll wrote:There is move.w (a0),d1; move.w d1,(a1) instead move.w (a0),(a1) .


Thanks - I've now put this in place. Can you tell that I'm from a x86 assembly background? :D

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2314
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Mon Aug 11, 2014 8:32 pm

Movem requires that data registers be listed first. So:

movem.l d1/a0-a1,-(sp)
...
movem.l (sp)+,d1/a0-a1

Order is actually false in second case, but it is done so, to make it easier for coders.

I'm one of those who coded a lot on MC68000. I tried later little x86 ASM too. But first CPU was Z80. MC68000 is nicest for coding, indeed. Because it has pretty consistent instruction set. But those who are used on different CPU (Intel based, and Z80 is such too) must learn new approach.
I saw at zillion places funny and inefficient 68K code in games. They use this: move.w loc,d1 ; then tst.w d1 - what is waste, because move to Dn sets flags immediately. Unlike by Z80. Or even worse - they use instead tst.w cmp.w #0,d1 :D This was simple case, in complexer code may be more inefficiency. Lot of registers by 68K is nice too - you can make faster and shorter code by avoiding slower RAM access if can perform all operations with CPU registers.
I'm not against GMO, I'm against that children play with fire.

chicane
Atari freak
Atari freak
Posts: 58
Joined: Mon Jul 02, 2012 11:25 am

Re: New ST project - Pole Position arcade conversion

Postby chicane » Mon Aug 11, 2014 9:11 pm

AtariZoll wrote:Movem requires that data registers be listed first. So:
movem.l d1/a0-a1,-(sp)
...
movem.l (sp)+,d1/a0-a1
Order is actually false in second case, but it is done so, to make it easier for coders.


Hmm ... still not having any joy with this. Just corrupted screen followed by bombs. I have a feeling I've tried this before. It seems like it should work though.

chicane
Atari freak
Atari freak
Posts: 58
Joined: Mon Jul 02, 2012 11:25 am

Re: New ST project - Pole Position arcade conversion

Postby chicane » Mon Aug 11, 2014 9:18 pm

Oops ... beginnner mistake. I was trying to comment out lines with ';' whereas this compiler requires them to be commented out with '|' !
All working fine now.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1448
Joined: Sun Jul 31, 2011 1:11 pm

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Mon Aug 11, 2014 9:25 pm

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.


Nowadays it's quite common for people to use GCC for compiling C code for the program and VASM for compiling the assembly code, as they're best available for both of these tasks. Objects built with them can be linked together fine, VASM is still maintained and has Devpac compatibility mode, see: http://sun.hasenbraten.de/vasm/

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2314
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Mon Aug 11, 2014 10:39 pm

Just one thing more: to make it more compatible, and runnable from hard disk need one simple change: set alternating screen base not to $70000, but to regular screen (which is normally at top of RAM) - $8000 location. With that, on 512K machines, alt. screen will go to same $70000, but on machines with more RAM higher, so executable can be located higher. Then no need for AUTO start at all cost, and will be space for hard disk driver too. On 1MB machines alt. screen will be at $F0000, on 4MB machines at $3F0000 .
I'm not against GMO, I'm against that children play with fire.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 616
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: New ST project - Pole Position arcade conversion

Postby mfro » Tue Aug 12, 2014 5:54 am

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:
http://www.atariforge.org/gf/project/libcmini


I'm already using libcmini for this project - I like it a lot :D


Great! I really appreciate when this is of any use to other projects!

Please let me know if you need improvements or run into bugs!

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 616
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: New ST project - Pole Position arcade conversion

Postby mfro » Tue Aug 12, 2014 6:25 am

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 ?


In fact (at least as far as I can tell), there is only one single call to MiNT in libcmini: the call to Pdomain().

If MiNT is available, libcmini switches to the MiNT domain so it doesn't need to work around TOS I/O redirection oddities (not to say bugs) itself.

I consider that an optimization. If MiNT is not available, that call doesn't do any harm (it's called only once during initialization).

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1448
Joined: Sun Jul 31, 2011 1:11 pm

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Tue Aug 12, 2014 7:17 pm

Pole Position's TITLE.PRG does 3 MiNT calls, in this order:
GEMDOS 0x154 Ssystem()
GEMDOS 0x119 Pdomain()
GEMDOS 0x104 Fcntl()

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1448
Joined: Sun Jul 31, 2011 1:11 pm

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Tue Aug 12, 2014 7:21 pm

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2314
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Tue Aug 12, 2014 7:57 pm

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.


You are wrong, or nicer said - not experienced with TOS games. It has nothing with how much RAM is in machine. As many games, this is coded in way that screen is set to $70000, because is intended for 512K machines (one of examples is Flight Simulator 2) .- I already talked here about this, but it seems that not reading/understanding it. So, if TOS uses more RAM, and it is always low RAM. POLEPOS.PRG will be loaded higher in RAM than with recommended TOS 1.04 (when loads to $AA56 if starts from AUTO) . Result of that higher load is that some parts of game, variables will go to address area above $70000, and as code starts with screen generation it will kill those variables or whatever. And opposite - variables may show as garbage on screen.
Therefore need to set screen flexible - if there is more RAM in machine, need to set screen to higher location - see my post above. That will allow even running from hard drive.
I'm not against GMO, I'm against that children play with fire.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1448
Joined: Sun Jul 31, 2011 1:11 pm

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Tue Aug 12, 2014 8:54 pm

AtariZoll wrote:It has nothing with how much RAM is in machine.


Yes, that's exactly what I said. :-)

User avatar
calimero
Atari God
Atari God
Posts: 1882
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: New ST project - Pole Position arcade conversion

Postby calimero » Tue Aug 12, 2014 9:13 pm

^
to bad that english is not motherlanguage to us all...
(I also did not realize that you said same thing)

Multiple language really make things more complicated than they should be.
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2314
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Wed Aug 13, 2014 2:08 am

Well, proper formulation would be that there is lack of RAM in first 512KB of RAM :mrgreen:
When some higher TOS version is used, or just started from Desktop instead AUTO .
But real proper is to say that TOS eats diverse amounts of low RAM depending on it's version, and that code should be fully relocatible, including screen location.
I'm not against GMO, I'm against that children play with fire.

User avatar
Marakatti
Atari God
Atari God
Posts: 1256
Joined: Sat Jun 18, 2005 9:58 am
Location: Finland
Contact:

Re: New ST project - Pole Position arcade conversion

Postby Marakatti » Wed Aug 20, 2014 2:10 pm

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 :(
-------------< Member of Atarimania >-----------
-< ST / STe / Falcon030 / TT030 archiver >-
-------------> www.atarimania.com <-------------

chicane
Atari freak
Atari freak
Posts: 58
Joined: Mon Jul 02, 2012 11:25 am

Re: New ST project - Pole Position arcade conversion

Postby chicane » Wed Aug 20, 2014 2:31 pm

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 :(


Thanks for your feedback Marakatti. Did you run the executable that I originally posted, or the patched executable subsequently provided by AtariZoll? The one I originally posted has a serious bug in the executable which means that it'll never run on a real ST - it only runs in Hatari because of a bug in the 68000 emulation!

User avatar
Marakatti
Atari God
Atari God
Posts: 1256
Joined: Sat Jun 18, 2005 9:58 am
Location: Finland
Contact:

Re: New ST project - Pole Position arcade conversion

Postby Marakatti » Wed Aug 20, 2014 7:35 pm

I tried both versions. I'll try it next with STfm and a real diskdrive. Being the racing game nut i am, i would love to see it running on real hardware :)
-------------< Member of Atarimania >-----------
-< ST / STe / Falcon030 / TT030 archiver >-
-------------> www.atarimania.com <-------------

chicane
Atari freak
Atari freak
Posts: 58
Joined: Mon Jul 02, 2012 11:25 am

Re: New ST project - Pole Position arcade conversion

Postby chicane » Fri Aug 29, 2014 5:32 pm

I've just posted a new video on YouTube (https://www.youtube.com/watch?v=KLKrqcY ... e=youtu.be) showing the latest build of ST Pole Position.

This video should be of particular interest to those who liked the idea but thought that the frame rate wasn't up to scratch. I've been working on performance of late and have managed an average frame rate uplift of about 50-60% on the previous video. Let me know what you think! I'll be putting another disk image up in a couple of days once I've ironed out a few issues.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2314
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Fri Aug 29, 2014 6:15 pm

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.
I'm not against GMO, I'm against that children play with fire.

chicane
Atari freak
Atari freak
Posts: 58
Joined: Mon Jul 02, 2012 11:25 am

Re: New ST project - Pole Position arcade conversion

Postby chicane » Fri Aug 29, 2014 6:24 pm

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.


Thanks - you don't know how satisfying it is to finally receive some positive feedback on the frame rate!

With respect to the trackside objects, I know what you mean - I've seen it too. The vertical on-screen positioning of the trackside objects and cars is reverse-engineered from the Z8002 arcade code, and I think I might have got it slightly wrong. It doesn't help that the original Z8002 code for this purpose just looks like a random mashup of adds, shifts and table lookups - I can't make any sense of it at all :D

User avatar
Marakatti
Atari God
Atari God
Posts: 1256
Joined: Sat Jun 18, 2005 9:58 am
Location: Finland
Contact:

Re: New ST project - Pole Position arcade conversion

Postby Marakatti » Fri Aug 29, 2014 8:33 pm

Great improvement! Any chance for a new demo to try out?
-------------< Member of Atarimania >-----------
-< ST / STe / Falcon030 / TT030 archiver >-
-------------> www.atarimania.com <-------------

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 784
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: New ST project - Pole Position arcade conversion

Postby FedePede04 » Fri Aug 29, 2014 8:54 pm

It starts to look really solid keep up the good work :)
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)


Social Media

     

Return to “Games - General”

Who is online

Users browsing this forum: No registered users and 3 guests