New ST project - Pole Position arcade conversion

All about ST/STE games

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

junosix
Captain Atari
Captain Atari
Posts: 288
Joined: Sun Jul 08, 2007 3:22 pm
Location: Plymouth

Re: New ST project - Pole Position arcade conversion

Postby junosix » Sun Apr 27, 2014 12:08 am

Yowser!

User avatar
Stefan jL
Atari God
Atari God
Posts: 1297
Joined: Thu May 09, 2002 3:21 pm
Location: Sweden
Contact:

Re: New ST project - Pole Position arcade conversion

Postby Stefan jL » Sun Apr 27, 2014 3:40 pm

chicane wrote:Feeback welcome as always.


Getting better for sure :)
But it is hard to tell if the gameplay is good from a youtube video, i hope you can release a demo eventually :)
Image

chicane
Atari freak
Atari freak
Posts: 73
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Mon Apr 28, 2014 8:39 pm

The problem with releasing a demo or any kind of preview binary to the public is that I have a nasty habit of losing interest afterwards!
My list of things to finish is getting shorter by the day so I'll hopefully be in a position to push out the finished game in the next 2-3 months.

chicane
Atari freak
Atari freak
Posts: 73
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Thu Aug 07, 2014 9:33 pm

It's been over 3 months since I last updated this thread, so I thought I'd better come back with some kind of news. I've really been struggling to spend time on this project recently, but I figured it would be better to give something to the community rather than just let the code sit unused on my hard drive. So, attached to this post is a zipfile containing an .ST disk image with a "public preview" version of ST Pole Position.

Please note - this software is in a very early stage of development and is full of bugs. Testing has taken place on Hatari 1.8 emulating a 512k STE running TOS 1.4, and it boots to the title screen most of the time in this configuration. I can't guarantee that this public preview will even load on any other emulator or a real ST(E) - it may crash the emulator or break your real hardware. Chances are that any missing features, glitches, slowdown, bugs or crashes you encounter will already be very well known to me, so no need to report them at this stage.

With the slightly patronising warning out of the way, here's what you should be able to do with this preview:

- View a looping demo mode;
- Take part in a qualifying session, which will lead to a race if you complete a lap in 72 seconds or less;
- Take part in a race.

Control is via joystick - can't remember which port, so try the other if your usual selection doesn't have any effect. Fire to start a game from when the looping demo mode is running. Up for accelerate, down for brake, left and right for steering and fire for gear change. There's a rather severe bug in this build which makes it difficult (if not impossible) to change back down to the low gear once you've changed to the high gear - sorry about that.

Not sure what else to say - download and enjoy! Any feedback (bearing in mind everything above) is most welcome.
You do not have the required permissions to view the files attached to this post.

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: New ST project - Pole Position arcade conversion

Postby FedePede04 » Fri Aug 08, 2014 5:56 am

Hi
Thx for the look, it is looking a lot better then some of the youtube videos :)
i got it to run under Hatari 1.8 1mb, uk1.02 tos,

if i just use the tos that Hatari use as default, the car you control is mess up (graphic)
and it does not start using Steem SSE 3.6

poleposition.png
You do not have the required permissions to view the files attached to this post.
Atari will rule the world, long after man has disappeared

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

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Fri Aug 08, 2014 7:00 am

For the start the good news: it worked in Hatari 1.8 with TOS 1.04 UK . Framerate is not bad at all, and it seems playable, although I was not able to start race, since it stucked at end of qualification. It worked even with TOS 2.06 in hatari 1.8 .

Now the longer bad news part, with some technical details: I found it very strange that it works in Hatari (latest version only ?) but not in Steem. Expacially considering that there is only 2 TOS executable. With Steem Dabugger (what is recommended developing platform for ST games - I have nothing against Hatari, but Steem Debugger is light years ahead with tracing features) I found that there is serious bug in executable POLEPOS . When running with TOS 1.04 UK, ececutable goes to loc. $AA56 . It crashes at address $169D0 because there is $0CBA,$0001 ... instead sane code. That is in middle of Timer-B routine. The biggest question is how to Hell it works in Hatari with this error ???

Well, I will not trace it in Hatari, and I'm sure that fails on real HW too, what should be real concern. Just tested on real Atari, and it throws 4 bombs after loading - what is exactly that - illegal instruction error.

I don't like at all idea of using some Mint based compiler for game targetting 512KB Ataris with old TOS versions. + it adds lot of code overhead, so eats already limited RAM with useless crap (sorry for my hard formulation). Title pic displaying could be done with short ASM code long some 20 lines, and exec. long 32120 bytes - from what 32032 goes for bitmap and color data. Some packing would make it much shorter and loading faster from floppy.

Another thing: you should use joystick 1 and not 0, because people don't like to remove mouse without real need. Joystick 1 is normal port for games using only 1 joystick.

And I must repeat what already said: if memory is tight, forget TOS executables. Using TOS independant code gives at least 40 KB more free RAM. And since you load it all at once, before start, it can be done very simple, by loading via GEMDOS, after what just moving all code, data to low RAM. It is really not hard to replace few used TOS calls with ASM code.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Fri Aug 08, 2014 10:59 pm

FedePede04 wrote:if i just use the tos that Hatari use as default, the car you control is mess up (graphic)


Happens also with latest EmuTOS. Not all the car frames are corrupted, only some of them.

Because it works with 512k and 256k EmuTOS, but causes 192k EmuTOS (which uses much less RAM) to crash into address error, I think game is overwriting/corrupting TOS memory.

In case code rings any bells, this was the last thing the game did at startup (drawing screen black after startup "pole position" screen), before EmuTOS went into la-la land:

Code: Select all

... game ...
$037b74 : d6fc 0100                            adda.w    #$100,a3
$037b78 : 1a1a                                 move.b    (a2)+,d5
$037b7a : 1a31 5800                            move.b    (a1,d5.l),d5
$037b7e : 82b3 5880                            or.l      $80(a3,d5.l),d1
$037b82 : 1a1a                                 move.b    (a2)+,d5
$037b84 : 1a31 5800                            move.b    (a1,d5.l),d5
$037b88 : 82b3 58c0                            or.l      $c0(a3,d5.l),d1
... EmuTOS interrupt handler ...
$fc03ba : 617c                                 bsr.s     $fc0438
$fc0438 : 46fc 2700                            move      #$2700,sr


EDIT: address error, not bus error.
Last edited by Eero Tamminen on Fri Aug 08, 2014 11:38 pm, edited 1 time in total.

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

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Fri Aug 08, 2014 11:36 pm

AtariZoll wrote:For the start the good news: it worked in Hatari 1.8 with TOS 1.04 UK . Framerate is not bad at all, and it seems playable, although I was not able to start race, since it stucked at end of qualification. It worked even with TOS 2.06 in hatari 1.8 .

Now the longer bad news part, with some technical details: I found it very strange that it works in Hatari (latest version only ?) but not in Steem.


It works fine also in Hatari v1.6.2.


AtariZoll wrote:Expacially considering that there is only 2 TOS executable. With Steem Dabugger (what is recommended developing platform for ST games - I have nothing against Hatari, but Steem Debugger is light years ahead with tracing features)


While STeem debugger has GUI and is otherwise much nicer to use interactively (visual breakpoints etc), I wouldn't say it's ahead in tracing or debugging features, just in convenience. The only major feature missing from Hatari is breaking on read/write to specific memory address, when the content of that address does NOT get changed. And STeem is missing a lot of features that Hatari debugger has (e.g. profiling with callgraphs & cycle counts and more advanced breakpoints).

AtariZoll wrote:I found that there is serious bug in executable POLEPOS. When running with TOS 1.04 UK, ececutable goes to loc. $AA56 . It crashes at address $169D0 because there is $0CBA,$0001 ... instead sane code. That is in middle of Timer-B routine. The biggest question is how to Hell it works in Hatari with this error ???


The interesting question is what is the difference. Is it due to STeem or Hatari emulating something differently (incorrectly), or a difference in your STeem and Hatari configuration. (crash on real HW indicates STeem is more correct, but it could be different issue too)

AtariZoll wrote:Well, I will not trace it in Hatari, and I'm sure that fails on real HW too, what should be real concern. Just tested on real Atari, and it throws 4 bombs after loading - what is exactly that - illegal instruction error.


What is exact configuration for your real Atari? Where exactly in loading it bombs?

AtariZoll wrote:I don't like at all idea of using some Mint based compiler for game targetting 512KB Ataris with old TOS versions. + it adds lot of code overhead, so eats already limited RAM with useless crap (sorry for my hard formulation).


If you're referring to MiNTlib (its POSIX API support increases binary sizes a lot), GCC can be used also without that. GCC generated code is larger than older compilers' but the produced code is also clearly faster, so using GCC makes sense if there's time critical C/C++-code in addition to ASM.

AtariZoll wrote:Title pic displaying could be done with short ASM code long some 20 lines, and exec. long 32120 bytes - from what 32032 goes for bitmap and color data. Some packing would make it much shorter and loading faster from floppy.

Another thing: you should use joystick 1 and not 0, because people don't like to remove mouse without real need. Joystick 1 is normal port for games using only 1 joystick.

And I must repeat what already said: if memory is tight, forget TOS executables. Using TOS independant code gives at least 40 KB more free RAM. And since you load it all at once, before start, it can be done very simple, by loading via GEMDOS, after what just moving all code, data to low RAM. It is really not hard to replace few used TOS calls with ASM code.


Tracing the game code with Hatari shows that after Ikbdws() call and the screen being drawn black at start, only OS call is for Setscreen(). That will also need working TOS. Then there are also interrupt handlers used by TOS, which need to be either disabled, or TOS needs to be in good enough condition to still perform them. For saving the high-scores, TOS would also need to remain functional.

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Sat Aug 09, 2014 6:31 am

I don't want to discuss here about tracing quality of Steem Debugger and Hatari. Normal is that people prefer what is used on, or involved in development. In this case, I traced down bug in POLEPOS in about 1-2 minutes with Steem Debugger - and that's what matters. Cycle counting was not necessary :D
I gave enough info about where the bug is. But will give more: in file POLEPOS.PRG error is on loc. $BF96 (what is $169D0-$AA56+$1C) is illegal opcode $0CBA followed by $0000 - not $0001 because $0001 is after relocation. It will go to PC when Timer-B is activated. And cause illegal instruction exception - 4 bombs. I guess that work in Hatari is because some strange illegal exception handling.
And this error has nothing how I did set Steem or Hatari. Both were set to minimal system - 512KB RAM, only ST floppy image active. All other was off.
As I said, error happened on real Atari right after finished floppy load - what was just reading of second, longer PRG file. More details are irrelevant. There is bad code in POLEPOS.PRG, and it will crash on every real Atari. Just it seems that all people is on vacation, or their Ataris are broken.

No need for TOS by arcade ST games. All can be done with even shorter code than TOS calls except floppy access - where need some 200-300 bytes of direct FDC code, what may save highscore too . IKBD reading is little harder part, but only for those who don't read literature. So, you spend 300 bytes for FDC code, while get 40 KB more space. Can set game start to very low RAM space - $400 for instance.
Setting interrupt, MFP vectors is trivial. TOS vectors will be overwritten if they are used, or just can disable not used interrupts. Custom IKBD - so keyboard, joystick, mouse reading code takes about 100 bytes in average game.

Here is concrete example of full title pic displaying code:

Code: Select all


   move.b   #$7,$FFFF8201.w
   move.b   #$80,$FFFF8203.w    * Will became screen base at next Vblank
* Only 2 instructions for setting screen base to $78000 - compare that with equal. XBIOS call !

     lea  titlep(pc),a0
     lea  $78000,a1
     move.w   #7999,d1
.scp   move.l  (a0)+,(a1)+   * Copy bitmap
    dbf  d1,.scp

    lea   $FFFF8240.w,a1
    moveq   #15,d1
.pcp   move.w  (a0)+,(a1)+   * Copy palette
    dbf   d1,.pcp

     rts

titlep    incbin  "TITLE.RAW"   * 32000 bytes bitmap
        incbin   "TITLE.PAL"   * 32 bytes palette data

* That's all folks

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Sat Aug 09, 2014 10:40 pm

AtariZoll wrote:I gave enough info about where the bug is. But will give more: in file POLEPOS.PRG error is on loc. $BF96 (what is $169D0-$AA56+$1C) is illegal opcode $0CBA followed by $0000 - not $0001 because $0001 is after relocation. It will go to PC when Timer-B is activated. And cause illegal instruction exception - 4 bombs. I guess that work in Hatari is because some strange illegal exception handling.


Having "illegal opcodes" in TEXT section is normal, compilers include data into code section in many cases. Question may be more why the program ends up "calling" that as instructions, instead of why those "instructions" are there. Can you provide assembly trace from program start until the issue?

AtariZoll wrote:No need for TOS by arcade ST games.


Just a personal opinion: If game is floppy only, it's OK. If it's also HD installable, it's nasty. :-)

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Sun Aug 10, 2014 3:24 am

Here is floppy image with skipped error:
POLEPOSU.ZIP

Note: I changed joystick to port 1, so no need to remove mouse, + disabled keyboard click, so sound will not disappear by accidental keypress.

I was unable to guess what should go there, so just inserted short jump to skip bad code section. It works now in Steem and real HW.
Timer-B routine missing something at end now, but what is exact effect of that I can't know. In any case, will not work worse than unchanged image in Hatari.
That error seems to me as compiler error. Really no other reasonable explanation how it could happen, especially as there was no transfer with floppies in relation Atari-PC-Atari or some unreliable operation what could corrupt couple bytes.
Please, instead further questions look what is changed, and trace self when it goes to that section.

I think that if C compiler is a must for this, should consider of using some reliable one. Of course, pure ASM would be real thing.
Then, in that corrupted Timer-B routine I saw some inefficient code: using not movem when 3 registers are pushed to stack, data copy with using data register instead straight move.w (a0)+,(a1)+ ....
A lot of time is spent in this for sure, and would be too bad if it would stall because some bad tool.

P.S. : considering running from hard drive - how this is coded currently will not work from hard drive. It works only if run from floppy AUTO folder. The reason is that screen is set to fixed address $70000, so PRG must load to low RAM location.
And there are ways to make it running from hard drive despite that - HAGA http://atari.8bitchip.info/fromhd.php will ensure that code and data is on it's low space, while by disk access hard disk driver will be operative. Even if game killed TOS (workspace), and is placed in very low RAM (at $400 ...) . Of course, then will need min 1MB RAM, but everybody with hard disk has at least so much in machine. All in all, everything can be solved, and there are many things well known, just need to use proven solutions. I can make this working from hard drive, Flash cards in less than half hour, so let that be not concern of Chicane :D

How it looks in Steem:
POLEPOSF_RS.png

There is no draw error of players car. Under Steem 3.2, 4MB, TOS 1.04 UK .
One thing more: should change joystick read code to allow gear shift (low-high-low) via fire button while joystick is moved in some direction too.
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
NGF
Captain Atari
Captain Atari
Posts: 389
Joined: Tue Nov 22, 2005 9:22 pm
Location: Stockholm, Sweden

Re: New ST project - Pole Position arcade conversion

Postby NGF » Sun Aug 10, 2014 8:11 am

Tried it now i Hatari, works fine with tos 1.04. Great progress. Smooth gameplay and good handling. Looking forward to the finished product, thank you :D
"4160" STE with Ultrasatan | Falcon 030 14MB with CF-reader | TT030 | STacy | 520STFM x 2 | 520ST x 2

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

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Sun Aug 10, 2014 6:07 pm

AtariZoll wrote:There is no draw error of players car. Under Steem 3.2, 4MB, TOS 1.04 UK .


Draw error happens only with EmuTOS, and even then only for some of the player sprite orientations.

Game doesn't do any graphics related (i.e. VDI or Line-A) OS calls which EmuTOS implementation could be buggy, so the bug seems to be in game itself. It's wierd that TOS version can affect something like that otherwise.

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Sun Aug 10, 2014 6:38 pm

Draw error under EMUTOS happens most likely because it uses more RAM, and as is explained, game don't like it.

Now the interesting part: finally I was able to use Hatari Debugger - why not earlier? Because there is no proper usage in it's manual for Windows users. Another critic about Hatari developers: they should find following before me - I just expected that will be more interested in finding emulation bugs.

So, this Pole Position preview works in Hatari only because serious bug in CPU emulation: Hatari Debugger says that at address $169D0, where it crashes on proper emulators (Steem, Saint) is instruction cmpi.l #$16B1E,$16ABC(pc) :mrgreen:
I put smiley because everyone experienced in 68000 coding knows that there is no such addressing mode by MC68000 .

So, most likely i was right when wrote that this is compiler error - and that compiler has something common with Hatari - maybe same CPU libraries. Actually, assembler part of compiler did it wrong most likely, since Timer-B code is written in ASM, I'm sure.

It would be nice if Chicane show up here. Not interested in feedback about his work ? Anyway, I will e-mail him if not comes here in following days.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1303
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: New ST project - Pole Position arcade conversion

Postby npomarede » Sun Aug 10, 2014 9:42 pm

AtariZoll wrote:Draw error under EMUTOS happens most likely because it uses more RAM, and as is explained, game don't like it.

Now the interesting part: finally I was able to use Hatari Debugger - why not earlier? Because there is no proper usage in it's manual for Windows users. Another critic about Hatari developers: they should find following before me - I just expected that will be more interested in finding emulation bugs.

We (hatari developpers) are certainly interested in any bug report and finding where the errors come from.
But, hey, it's holidays and it's also the week end, you can't expect everybody to debug any problem in the following hours :)
So, this Pole Position preview works in Hatari only because serious bug in CPU emulation: Hatari Debugger says that at address $169D0, where it crashes on proper emulators (Steem, Saint) is instruction cmpi.l #$16B1E,$16ABC(pc) :mrgreen:
I put smiley because everyone experienced in 68000 coding knows that there is no such addressing mode by MC68000 .

So, most likely i was right when wrote that this is compiler error - and that compiler has something common with Hatari - maybe same CPU libraries. Actually, assembler part of compiler did it wrong most likely, since Timer-B code is written in ASM, I'm sure.

It would be nice if Chicane show up here. Not interested in feedback about his work ? Anyway, I will e-mail him if not comes here in following days.

I will have a look at this, but maybe the game was erroneously compiled in 68020 mode ? I can't tell myself what compilers options were used with the C compiler.

Nicolas

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1272
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby MasterOfGizmo » Sun Aug 10, 2014 9:57 pm

Does the original game also display the speed in kilometers? Kilometers per hour seems more appropriate.

A quick search returned screenshots giving mph, km and no unit at all. So this seems to be perfectly redone with respect to this.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

User avatar
npomarede
Atari God
Atari God
Posts: 1303
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: New ST project - Pole Position arcade conversion

Postby npomarede » Sun Aug 10, 2014 10:03 pm

AtariZoll wrote:So, this Pole Position preview works in Hatari only because serious bug in CPU emulation: Hatari Debugger says that at address $169D0, where it crashes on proper emulators (Steem, Saint) is instruction cmpi.l #$16B1E,$16ABC(pc) :mrgreen:
I put smiley because everyone experienced in 68000 coding knows that there is no such addressing mode by MC68000 .

What do you mean ?? Of course "cmp.l #data,d16(An)" is a valid 68000 instruction , are you sure you're an experienced 68000 coder ? :D

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Sun Aug 10, 2014 10:18 pm

Huh - cmp.l #data,d16(pc) is not valid even on 68030 . Wake up. I don't know am I "experienced", but guys, you own me a beer for finding this :lol:
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

chicane
Atari freak
Atari freak
Posts: 73
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Sun Aug 10, 2014 10:27 pm

Thanks everyone for the feedback! I'm a bit gobsmacked by the level of detail, especially that of AtariZoll and Eero, so particular thanks to you both.

Down to business then. Having looked at the instruction at $169d0, this is indeed within the Timer B code, specifically the code that cycles one of the palette entries between several colours to create the "flashing letters" effect shown at the end of a qualifying/race session. All of my Timer B code is written in assembly rather than C, but the strange thing was that the offending instruction ("cmpi.l #$16B1E,$16ABC(pc)") didn't look at all familiar as I've never used pc-relative addressing in my code. I used the instruction history in the Hatari debugger to establish that the instruction at $169d0 was assembled from the following instruction in my source file:

Code: Select all

cmp.l #cycling_colours_end,(cycling_colour_pointer)


So from what I can tell, m68k-atari-mint-gcc is not just assembling my opcodes into binary - it appears to do other things like changing addressing modes of individual instructions! As a side note, I've also noticed a move instruction within my source file being translated by the compiler into a moveq instruction in the disassembly, so it would appear that m68k-atari-mint-gcc is trying to perform some rudimentary optimisations on my source. With all this in mind, and assuming that the instruction at $169d0 is not a 68000 instruction (and there seems to be some debate on this), I've tried explicitly setting m68k-atari-mint-gcc to generate 68000-compatible code (using the -m68000 switch) but this makes no difference to the generated binary.

From what we now know, it would seem to be easy enough to work around this issue to get a binary working on all emulators along with the real hardware. But, like everybody else, I'm now a little curious about whether the instruction at $169d0 is 68000-compatible or a valid instruction at all, and if not, why m68k-atari-mint-gcc feels it necessary to transform my original instruction into something that either isn't valid or isn't valid on the plain 68000.

Lots of other interesting points raised in recent posts - I'll take some time to digest these and respond at a later point.

User avatar
npomarede
Atari God
Atari God
Posts: 1303
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: New ST project - Pole Position arcade conversion

Postby npomarede » Sun Aug 10, 2014 10:32 pm

AtariZoll wrote:Huh - cmp.l #data,d16(pc) is not valid even on 68030 . Wake up. I don't know am I "experienced", but guys, you own me a beer for finding this :lol:

It's valid, have a look at the motorola's 68000 cycle table and you will see it even takes 24 cycles (see http://dbug.kicks-ass.net/dbugforums/cgi-bin/yabb2/YaBB.pl?num=1346218770 for a copy of this table). If I enter this bytes' sequence under MonST, it correctly disassembles to "cmpi.l #xxxx,dd(pc)"
What seems invalid to you ? d16(pc) instead of d8 ? cmpi.l works with this <ea>. Are you sure we're talking about the same bytes sequence "0cba 0000 c0c8 00e6" ?

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Sun Aug 10, 2014 10:48 pm

So, my real Atari has broken CPU, because it executes not seq. 0cba 0000 c0c8 00e6 :D
Instead Monst, try to assemble something like cmp.l #333,huh(pc) .... huh dc.l 0 (2 lines of code) with Devpac3 - may set it to 68030 CPU if like .
OK, I can understand that this is some kind of shock to you, and MON really disassembling it as said, but it is 100% invalid - $0CBA is invalid opcode on 68000-68030, so must trigger illegal exception.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Sun Aug 10, 2014 11:03 pm

Chicane, here is general rule, what stays for 680000-68030: if it is CPU instruction with 2 operands, second one may never be pc-relative.
So, invalid is : move.w #123,label1(pc) - if pc relative code is must, it needs at least 2 lines : lea label1(pc),a1 ; move.w #123,(a1) .
Or compare: cmp.l (w,b) #321,label2(pc( is invalid .

I always set all ASM optimisations off, because they may change some unwanted things - for instance self-modding code, where exact length of instructions is a must.

But in this case, it is clear Gcc bug. Even if you set to 68030 accidentaly, it should stop assembling with addressing mode not allowed messafe. But it done opposite - added pc relative mode as optimisation, and complete wrong.
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 ?

As said, I suggest to change compiler. Use something intended for TOS. I never used C compiler on Atari, so can not give advice. Here, in forum there is C section at coding, so feel free to ask for help there. Although best would be to do all in pure ASM IMHO .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Mon Aug 11, 2014 1:07 am

Nothing is perfect.
What happens when you can not sleep because medical cure ? Finding bugs in 20 year old SW :D
There is bug in Devpac3 too: it says "addressing mode not allowed" for $OCBA opcode ( cmpi.l #data,d16(pc) ) when Processor is set to 68030 .
But as I tested on Falcon, it works on 68030 .
I did not expect it, because Devpac3 worked flawless for me over 2 decades, and it is one of rare assemblers which generated correct code for 68030 PMMU and cache instructions.

But on 68000 it is illegal for sure, and following is from certainly reliable source, Motorola self:

cmpi68K.png


6801 at the end ??? I think that 1 zero is missing there ..
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Mon Aug 11, 2014 6:02 pm

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 ?


If those were GEMDOS calls, it's probably linked against MiNTlib (default C-library for GCC). Presense of specific functions can be tested by calling them, TOS will just return function code for non-existing functions.

AtariZoll wrote:As said, I suggest to change compiler. Use something intended for TOS.


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

For more info on that, see the initial announcement of it year ago:
http://sourceforge.net/p/emutos/mailman ... /31099219/

Direct link to sources is here:
http://www.atariforge.org/gf/project/li ... sources%2F

User avatar
npomarede
Atari God
Atari God
Posts: 1303
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: New ST project - Pole Position arcade conversion

Postby npomarede » Mon Aug 11, 2014 6:22 pm

AtariZoll wrote:Nothing is perfect.
What happens when you can not sleep because medical cure ? Finding bugs in 20 year old SW :D
There is bug in Devpac3 too: it says "addressing mode not allowed" for $OCBA opcode ( cmpi.l #data,d16(pc) ) when Processor is set to 68030 .
But as I tested on Falcon, it works on 68030 .
I did not expect it, because Devpac3 worked flawless for me over 2 decades, and it is one of rare assemblers which generated correct code for 68030 PMMU and cache instructions.

But on 68000 it is illegal for sure, and following is from certainly reliable source, Motorola self:

I'm back home and have access to my docs, and I confirm CMPI is not allowed with d(PC) in 68000, so some :cheers: :cheers: :cheers: and beers for you.
But as d(PC) is allowed in 68020+, I removed a few beers :)
This is now fixed in Hatari devel version and will be in Hatari 1.8.1
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.

Nicolas


Social Media

     

Return to “Games - General”

Who is online

Users browsing this forum: No registered users and 3 guests