The X68000 games porting experiment

[f030]

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

[Anima]

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]

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 ?

[dml]

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

[Anima]

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.

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

[dml]

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

[CiH]

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

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

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.

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.

[CiH]

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!

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!

[wongck]

Great job.
Will try it out later....

[f030]

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

[CiH]

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.

[f030]

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

[Anima]

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.

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

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

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

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!

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

Hope the exception error messages mean something to someone.

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

Cheers
Sascha

[simonsunnyboy]

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?

[Anima]

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.

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

[dml]

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.

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.

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.

[wongck]

Did some quick test.

Was testing EMUTOS, so I also copied Galaga 88 on my CF.
Executed and it ran on EMUTOS
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
RUNS on CT63 with CTPCI/ATI !!!
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.

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

System config as per signature below.

[dml]

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

[dml]

Here is a (poorly lit!) photo of the last version of G88 running happily on a 32MHz 68040 with FastRAM + caches on.

[Anima]

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

[Eero Tamminen]

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

[CiH]

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.

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

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

[calimero]

Super idea and super implementation!

[dma]

Ah, i got an X68000 game back in my mind which would probably be a good candidate for porting : Chelnov (also named Atomic Runner).

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.