The X68000 games porting experiment

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

f030
Atari User
Atari User
Posts: 41
Joined: Wed Dec 07, 2011 1:46 pm

Re: The X68000 games porting experiment

Postby f030 » Sun Dec 16, 2012 7:22 pm

does not run from tt-ram, two bombs, (mighty sonic 32 with 20mb tt-ram)

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sun Dec 16, 2012 7:46 pm

f030 wrote:does not run from tt-ram, two bombs, (mighty sonic 32 with 20mb tt-ram)


Damn... :(

Thanks for testing on that configuration. Obviously it's not enough to use Mxalloc() for screen memory allocation and let all the other code reside in Fast RAM.

Are you able to give me some more infos about the crash? Memory dump or register values?

Cheers
Sascha

f030
Atari User
Atari User
Posts: 41
Joined: Wed Dec 07, 2011 1:46 pm

Re: The X68000 games porting experiment

Postby f030 » Sun Dec 16, 2012 8:08 pm

Anima wrote:
Are you able to give me some more infos about the crash? Memory dump or register values?


I do not know how to do it, some advice ?

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Sun Dec 16, 2012 8:31 pm

Anima wrote:Thanks for testing on that configuration. Obviously it's not enough to use Mxalloc() for screen memory allocation and let all the other code reside in Fast RAM.


Could there be anything in the X68000 part of the source that assumes 24bit addressing? STRam is usually only needed by screen, blitter, audio/scsi/floppy dma.

That leaves the old 68k addressing problems...

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sun Dec 16, 2012 8:52 pm

dml wrote:Could there be anything in the X68000 part of the source that assumes 24bit addressing? STRam is usually only needed by screen, blitter, audio/scsi/floppy dma.

That leaves the old 68k addressing problems...


In fact, the X68000 code is totally address independent so the problem is probably caused by my code.

f030 wrote:I do not know how to do it, some advice ?


Sadly I have no machine with Fast (or TT) RAM so I cannot give an advice how to do that either. :(

Cheers
Sascha

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Sun Dec 16, 2012 10:05 pm

On a 68040 with FastRam + I/D caches enabled I get 3 bombs and a corrupt screen.

However, trying again with both caches disabled, it seems to run. :P Not bad!

I checked the PRG flags and the FastRAM bits seem to be set already, is that correct? (not looked at this in years so I could get that wrong)

Trying again with D cache enabled, still works.

This is not terribly surprising - the 040 has a big instruction cache and if copyback mode is on, it needs pushed back to ram (instead of just clearing it). Or it may not have been cleared properly after SMC.

In any case FastRAM doesn't seem to be a problem here.

My 68040 MMU driver is a bit tricky though and maps the FastRam to exactly 16MB onwards - not sure where the MS board puts it...

User avatar
CiH
Atari God
Atari God
Posts: 1121
Joined: Wed Feb 11, 2004 4:34 pm
Location: Middle Earth (Npton) UK
Contact:

Re: The X68000 games porting experiment

Postby CiH » Sun Dec 16, 2012 10:13 pm

The news from my end is mixed, but better than some have been reporting :D

Centurbo 2, in 'TOS 7.0' mode, with Fastram enabled, works! :cheers:

A screengrab is enclosed. The CT2 prefers a VGA display, as SCART/RGB seems to hit an unobtainable video frequency and I get a 'no signal' message. The program is still able to 'esc-exit' back to the desktop. This issue with RGB and CT2 is not uncommon, and can be found also with the game 'Running', which also needs a VGA screen, so this is not an issue with anything you've done.

ct2_success.jpg


However, it works just fine with VGA and Fastram, also working with Centscreen enabled, and even starting from an extended (800 x 600) resolution as well.

With CT60 and CTPCI, perhaps I was pushing things a bit too hard, as I got this..

Hope the exception error messages mean something to someone. :mrgreen:

ct60_ctpci fail.jpg


When I rebooted without CTPCI, the program managed to get to the intro text screen, then appeared to try to start as it went black, but nothing more happened and I had to reset.
You do not have the required permissions to view the files attached to this post.
"Where teh feck is teh Hash key on this Mac?!"

User avatar
CiH
Atari God
Atari God
Posts: 1121
Joined: Wed Feb 11, 2004 4:34 pm
Location: Middle Earth (Npton) UK
Contact:

Re: The X68000 games porting experiment

Postby CiH » Sun Dec 16, 2012 10:49 pm

Just to further clarify something on my previous post. These were all run from plain TOS mode, including CTPCI. I've not fancied my chances at crashing and burning on Mint or Magic! :mrgreen:

Caveat - I've still as yet to try CT60 either with delayed cache option, or caches switched off, but I'm short of VGA cables, and cannot be arsed to fumble about and swap back tonight! :mrgreen:
"Where teh feck is teh Hash key on this Mac?!"

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12420
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: The X68000 games porting experiment

Postby wongck » Sun Dec 16, 2012 11:22 pm

Great job.
Will try it out later....
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

f030
Atari User
Atari User
Posts: 41
Joined: Wed Dec 07, 2011 1:46 pm

Re: The X68000 games porting experiment

Postby f030 » Mon Dec 17, 2012 12:04 am

CiH wrote:However, it works just fine with VGA and Fastram, also working with Centscreen enabled, and even starting from an extended (800 x 600) resolution as well.


are you sure about that?
it seems that always load into st ram
try it with 4mb st-ram

User avatar
CiH
Atari God
Atari God
Posts: 1121
Joined: Wed Feb 11, 2004 4:34 pm
Location: Middle Earth (Npton) UK
Contact:

Re: The X68000 games porting experiment

Postby CiH » Mon Dec 17, 2012 12:32 am

f030 wrote:
CiH wrote:However, it works just fine with VGA and Fastram, also working with Centscreen enabled, and even starting from an extended (800 x 600) resolution as well.


are you sure about that?
it seems that always load into st ram
try it with 4mb st-ram


Good point. That will have to keep until later as I'm closed down for tonight. My configuration on CT2 is 14mb ST Ram and 64mb Fastram. I guess yours is 4mb and 20mb respectively?

Having said that, we've still got an improvement from the Pacmania initial test which was completely leery about Fastram and needed it switched off to run at all.
"Where teh feck is teh Hash key on this Mac?!"

f030
Atari User
Atari User
Posts: 41
Joined: Wed Dec 07, 2011 1:46 pm

Re: The X68000 games porting experiment

Postby f030 » Mon Dec 17, 2012 12:55 am

CiH wrote:Good point. That will have to keep until later as I'm closed down for tonight. My configuration on CT2 is 14mb ST Ram and 64mb Fastram. I guess yours is 4mb and 20mb respectively?


4/14mb adjustable via jumper and 20mb tt-ram.
with 4mb i get two bombs, with 14mb works

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Mon Dec 17, 2012 8:33 am

Hello guys,

thanks for all the tests and reports.

Please be aware that the game uses a lot of memory. The amount of Fast RAM should not be a problem since most machines have at least 16 MB but, however, about 3 MB of ST RAM is required for the VIDEL display. This memory is being requested by using Mxalloc(), hoping this would do the trick on all accelerated machines. So probably this could cause some problems on 4 MB ST RAM configurations but at least the Mxalloc() should've failed and the program exits in this case.

dml wrote:On a 68040 with FastRam + I/D caches enabled I get 3 bombs and a corrupt screen.

However, trying again with both caches disabled, it seems to run. :P Not bad!

I checked the PRG flags and the FastRAM bits seem to be set already, is that correct? (not looked at this in years so I could get that wrong)

Trying again with D cache enabled, still works.

This is not terribly surprising - the 040 has a big instruction cache and if copyback mode is on, it needs pushed back to ram (instead of just clearing it). Or it may not have been cleared properly after SMC.

In any case FastRAM doesn't seem to be a problem here.

My 68040 MMU driver is a bit tricky though and maps the FastRam to exactly 16MB onwards - not sure where the MS board puts it...


I am just using the m68k-atari-mint cross-tools for the assembling process. I don't know how to change the Fast RAM bits at all. I guess that the cross-tools are having this as the default!?

In respect to the 68040 I just tried different Hatari CPU types for the emulation (68040 and even 68060) and it works so far. So I guess the emulation is not that accurate!? However, I think it could have something to do with the sprite code compilation and I can try to clear the I-cache after each sprite compiling process.

CiH wrote:The news from my end is mixed, but better than some have been reporting :D

Centurbo 2, in 'TOS 7.0' mode, with Fastram enabled, works! :cheers:

A screengrab is enclosed. The CT2 prefers a VGA display, as SCART/RGB seems to hit an unobtainable video frequency and I get a 'no signal' message. The program is still able to 'esc-exit' back to the desktop. This issue with RGB and CT2 is not uncommon, and can be found also with the game 'Running', which also needs a VGA screen, so this is not an issue with anything you've done.


Great. Good to see it running on other machines as well! :D

So, as far I understand, having an "option" for directly selecting an RGB monitor output would help in your case?

CiH wrote:Hope the exception error messages mean something to someone. :mrgreen:


Unfortunately not much yet. Did this exception come up right after the start?

Cheers
Sascha

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5007
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: The X68000 games porting experiment

Postby simonsunnyboy » Mon Dec 17, 2012 8:48 am

Anima wrote:
simonsunnyboy wrote:Great effort, seems to work okay over here. I have to boot my Falcon into TOS to make it run, it does not run from FreeMinT.


What actually happens when you start it under Mint?

Cheers
Sascha


The TOS file simply terminated, it showed the output and terminated. Maybe the main proces waiting to be launched with SPACE is loaded into memory but does not receive the SPACEBAR pressing event. In any way RAM is pretty cramped then (NVDI, some ACCs, Teradesk, TOS2WIn loaded) so from 14MB only 7 or 8 are left IIRC. Maybe this is just too small for the game to fit.

Another issue: your ZIP distributes a lot of files. Are all needed or is the development stuff simpy packed for convenience?
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Mon Dec 17, 2012 9:18 am

simonsunnyboy wrote:The TOS file simply terminated, it showed the output and terminated. Maybe the main proces waiting to be launched with SPACE is loaded into memory but does not receive the SPACEBAR pressing event. In any way RAM is pretty cramped then (NVDI, some ACCs, Teradesk, TOS2WIn loaded) so from 14MB only 7 or 8 are left IIRC. Maybe this is just too small for the game to fit.


Exactly. The initial message is printed on screen before it tries to obtain the VIDEL screen (3 MB) and sprite code (2 MB) memory areas. If the allocation fails the program just exits without a message which is definitely not best practice. :roll:

simonsunnyboy wrote:Another issue: your ZIP distributes a lot of files. Are all needed or is the development stuff simpy packed for convenience?


Well, the game is actually not a classic port where the program is completely optimized for a certain system - it's still an optimized emulation layer with some Atari specific routine "hooks" within the original code. This is one of the reasons why it requires so much memory and also all the original X68000 data files. In fact, a few of them can be omitted but I am not really sure which so I left them in the folder. ;)

The advantage is that almost all of the Atari routines in this game can be reused on other X68000 "ports" like PacMania or... well let's see. ;)

Cheers
Sascha

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Mon Dec 17, 2012 9:34 am

Anima wrote:I am just using the m68k-atari-mint cross-tools for the assembling process. I don't know how to change the Fast RAM bits at all. I guess that the cross-tools are having this as the default!?


That is possible. I'll check it more closely later on.

Anima wrote:In respect to the 68040 I just tried different Hatari CPU types for the emulation (68040 and even 68060) and it works so far. So I guess the emulation is not that accurate!?


As far as I've been able to tell, the emulators don't emulate cache behaviour at all. I saw the same while reworking NEMBENCH for cache hit/miss cases. They emulate the instructions and virtualize the 'times' from the reference manuals for average case (?). I think it stops there.

Anima wrote:However, I think it could have something to do with the sprite code compilation and I can try to clear the I-cache after each sprite compiling process.


That should solve it I think.

I don't know offhand the behaviour of the i-cache contents being 'written' while in copyback vs writethrough mode so I would assume clearing the i-cache might be dangerous on 68040. I always use 'cpusha ic/dc/bc' (flush i-cache/d-cache/both caches back to RAM) to be sure since this will always work - although that will mean adding a 68040 satellite source file or a hand assembled opcode to do it...

Not sure about the 68060 yet - probably the same.

In any case if you decide to make a change let me know and I'll retest.

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12420
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: The X68000 games porting experiment

Postby wongck » Mon Dec 17, 2012 12:22 pm

Did some quick test.

Was testing EMUTOS, so I also copied Galaga 88 on my CF.
Executed and it ran on EMUTOS :D
But there was no sound.

Switch back to TOS 4.04 and tried.
Sure it runs as expected but same as EmuTOS, no sound.

Switched on CT63 with CTPCI
:megaphone: RUNS on CT63 with CTPCI/ATI !!! :thumbs:
The welcome screen was on the ATI and looks freezed after pressing spacebar.
Switch over to Videl, and there is was..... needless to say, speed was good. :mrgreen:

But I have to find my joystick.... I easily get killed using the keyboard.

System config as per signature below.
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Mon Dec 17, 2012 3:07 pm

dml wrote:
Anima wrote:I am just using the m68k-atari-mint cross-tools for the assembling process. I don't know how to change the Fast RAM bits at all. I guess that the cross-tools are having this as the default!?


That is possible. I'll check it more closely later on.


I checked the header of one of my own files generated by m68k-atari-mint-gcc, and prgflags == 0x00000007, which seems to mean all the speedy bits are set by default! That's quite handy - except perhaps when you don't expect it :-) OTOH any well-written TOS program shouldn't care - especially the FastLoad bit.

00000000h: 60 1A 00 02 F5 A0 00 00 08 84 00 02 1A 28 00 00 ; `...õ ...„...(..
00000010h: 00 00 4D 69 4E 54 00 00 00 07 00 00 20 3A 00 1A ; ..MiNT...... :..
00000020h: 4E FB 08 FA 00 00 01 08 00 02 F4 BC 00 00 08 84 ; Nû.ú......ô¼...„

http://toshyp.atari.org/en/005005.html

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Mon Dec 17, 2012 3:36 pm

Here is a (poorly lit!) photo of the last version of G88 running happily on a 32MHz 68040 with FastRAM + caches on.
You do not have the required permissions to view the files attached to this post.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Mon Dec 17, 2012 4:24 pm

Thanks to all who have tested it so far.

I have prepared and uploaded a new version (Doug already mentioned it) of Galaga 88 for the Atari Falcon030 which is now compatible with machines running on an 68040 (and hopefully 68060 as well). In fact, it's the same download link you may have used before but the program version now says "v0.1a".

Cheers
Sascha

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

Re: The X68000 games porting experiment

Postby Eero Tamminen » Mon Dec 17, 2012 7:14 pm

dml wrote:I checked the header of one of my own files generated by m68k-atari-mint-gcc, and prgflags == 0x00000007, which seems to mean all the speedy bits are set by default!


VBCC defaults to 0x7 too. "mintbin" package contains "flags" program to change the program load flags:
http://sparemint.org/sparemint/html/pac ... ntbin.html

If you don't have sparemint distribution, you can extract RPM package contents on Linux with according to instructions here:
http://koti.mbnet.fi/tammat/hatari/deve ... #vbccnotes

"flags" binary works fine under TOS, if you rename it to "flags.ttp".

(If that binary is too large, ancient SozobonX compiler utils package contains a smaller binary for changing program flags.)

User avatar
CiH
Atari God
Atari God
Posts: 1121
Joined: Wed Feb 11, 2004 4:34 pm
Location: Middle Earth (Npton) UK
Contact:

Re: The X68000 games porting experiment

Postby CiH » Mon Dec 17, 2012 8:56 pm

Wongck, I'm guessing you're running it on CT60/CTPCI with either caches turned off, delayed copyback cache set on the CT60 config menu, or both.

It took me a fair bit of fiddling around to get Galaga 88 to run on mine, but I got there in the end. The game itself defaulted to the 'secondary' Videl output when running as you described. as with my testing with the CT2 yesterday, speed was NOT an issue!

You may want to dig out a decent auto-fire joystick to play this, as trigger finger blisters and tiredness are a distinct possibility!

Just for shits and giggles, I had an RGB display plugged into the Videl, so two dissimilar displays on the two outputs yeah, great idea you might think, but Galaga ran perfectly in a native RGB mode on that screen, no distortion or weirdness or anything. :mrgreen:
"Where teh feck is teh Hash key on this Mac?!"

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12420
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: The X68000 games porting experiment

Postby wongck » Mon Dec 17, 2012 11:18 pm

CiH wrote:I'm guessing you're running it on CT60/CTPCI with either caches turned off, delayed copyback cache set on the CT60 config menu, or both.


Mine is always set as delayed copyback cache. This slows down the system slightly but most program works in this mode.
I have to switch between Videl and CTPCI as I only have a single LCD panel but does so via a KVM.
LCD display not center, slightly shifted to the right.

I am also on the beta Boot v1.02 which suppose to work for the Ethernet/USB.

Yeah I need to find me joystick :mrgreen:
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2208
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: The X68000 games porting experiment

Postby calimero » Thu Dec 20, 2012 6:17 pm

Super idea and super implementation! :) :cheers:
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

User avatar
dma
Atari Super Hero
Atari Super Hero
Posts: 846
Joined: Wed Nov 20, 2002 11:22 pm
Location: France
Contact:

Re: The X68000 games porting experiment

Postby dma » Sun Dec 23, 2012 11:31 am

Ah, i got an X68000 game back in my mind which would probably be a good candidate for porting : Chelnov (also named Atomic Runner).
Image Image
https://en.wikipedia.org/wiki/Chelnov
https://www.youtube.com/watch?v=SHaL1lTi15g
http://www.illusionware.it/x68000/Atomic-Runner-Chelnov.html
It's an excellent arcade game by DATA EAST, part shooter and part plateformer, first released as real arcade then ported to X68000 (and SEGA Genesis on lower specs).
I don't think it uses advanced graphic system, just scrolling and sprites. But it's really an arcade gem imo.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 3 guests