The X68000 games porting experiment

[dml]

Great progress! And nice to see the stages in between.

Are the 'corrupt' sprites just unhandled tile rotation/flipping codes or some other issue? They seem to all have shared orientation, and the first line/column seems to be from another tile, like it was supposed to be rendered backwards.

Just curious

[Anima]

Great progress! And nice to see the stages in between.

Are the 'corrupt' sprites just unhandled tile rotation/flipping codes or some other issue? They seem to all have shared orientation, and the first line/column seems to be from another tile, like it was supposed to be rendered backwards.

Just curious

Thanks. Well, the sprite emulation is quite complete and also supports the X/Y flipping. The interesting part is that I see different "broken" sprites on my real Falcon compared to running it on Hatari. The "XSP mode 1" on the X68000 works so it's most likely a bug on my side.

Edit: spelling.

[Anima]

Whew. I finally found the sprite corruption "bug"... a real bug from hell... I'll go into details later on because I have to go to bed now.

So here's the most recent version of Cho Ren Sha for the Atari Falcon. Now the sprite count goes up to 512 but the priorities are messed up again. However, you can now see all the enemies in all their glory. Please note: use the sz2_hata.tos for Hatari and select the fastest CPU.

[EvilFranky]

Sorry I forgot to ask, is this VGA & RGB compatible Anima?

[Anima]

Sorry I forgot to ask, is this VGA & RGB compatible Anima?

Yes, it should work on a machine connected to a VGA monitor as well. However, I only tried this on Hatari.

I just noticed that there's still a problem with the bombing effect.

[dml]

This is really shaping up, fast!

[EvilFranky]

I've made a video of the latest release running on my CT60 :-

http://youtu.be/niSewajHMPY?list=UUb7IU ... kUmsz45owQ

YouTube has destroyed the quality though, but it gives a good view of how well it runs.

EDIT - Looks like YouTube has sorted itself out now, 1080p version is there. Still quality isn't amazing.

[Anima]

I've made a video of the latest release running on my CT60

Wow, thanks. That looks great. Adding the text and the background is rather easy so I think a version for accelerated machines could be available in the next days.

You're running the game on a MC68060 at 66 MHz, right?

[EvilFranky]

Yes I am Anima

[EvilFranky]

JagPad support at some point too hopefully

[Anima]

Yes I am Anima

Ok, thanks. That gives me an idea of the expected performance. Good to see it running quite fluidly even without special optimisations.

JagPad support at some point too hopefully

Sure, why not? If you have one you'll have to test it then. Probably I should buy one for myself some time.

[dml]

That looks even more awesome than last time.

Some of my 040 cables are in storage now but if I can improvise I might be able to test it on that.

[EvilFranky]

Yes I am Anima

Ok, thanks. That gives me an idea of the expected performance. Good to see it running quite fluidly even without special optimisations.

JagPad support at some point too hopefully

Sure, why not? If you have one you'll have to test it then. Probably I should buy one for myself some time.

Yeah I have a JagPad mate. The game would lend itself well to a controller I think.

So what optimization work has been done so far? If this runs on a CT60 I guess your blitter routine isn't in use? (I recall for some reason that the blitter is switched off when CT60 is used).

[Anima]

That looks even more awesome than last time.

Some of my 040 cables are in storage now but if I can improvise I might be able to test it on that.

I suppose you're referring to Galaga 88!? Yes, Cho Ren Sha feels more modern compared to Galaga 88. The amount of sprites and the dynamic animations make it very impressive. Also there is no special code like compiled sprites so the performance can be improved by a good margin.

The reason why Galaga 88 fails on MC68060 is that it creates the compiled sprites in realtime which fails on machines with a bigger cache sizes but that's not necessary in this case.

Getting some performance figures on the MC68040 would be appreciated.

[Anima]

So what optimization work has been done so far? If this runs on a CT60 I guess your blitter routine isn't in use? (I recall for some reason that the blitter is switched off when CT60 is used).

Actually there's no optimisation yet. I've chosen this way to see if the graphics engine of the game works correctly without getting in trouble with some error prone optimised sprite routines. In fact, the Blitter has absolutely no advantage on a CT60 as the CPU could do everything faster.

All in all it looks already quite promising even without optmisations on a CT60. Thanks again for recording the video.

[EvilFranky]

No problem mate, I'm pleased it helped.

It actually looked pretty damn good on a plain Falcon also...and it's not even optimised yet.

Will be very interesting to see what you can do to make it faster.

[bear]

Incredible! Keep the good work up Anima!

[joska]

So here's the most recent version of Cho Ren Sha for the Atari Falcon.

Does this require 14Mb ST-RAM? It does not start on my Falcon/AB with 4Mb ST-RAM and 64Mb Fast-RAM.

[Anima]

Does this require 14Mb ST-RAM? It does not start on my Falcon/AB with 4Mb ST-RAM and 64Mb Fast-RAM.

Yes it does. However, I'll prepare a special version for accelerated machines which will run in the Fast-RAM. Please stay tuned.

[Strider]

Does this require 14Mb ST-RAM? It does not start on my Falcon/AB with 4Mb ST-RAM and 64Mb Fast-RAM.

Yes it does. However, I'll prepare a special version for accelerated machines which will run in the Fast-RAM. Please stay tuned.

I've just tested it in both 030 and 060 modes and it's amazing!
The game itself is brilliant, with more and more powerful waves, lots of colours and sounds. It looks like fireworks.
On 030 it's not too slow, except when enemies or bullets are surrounding the player. The game is indeed easier in 030 mode because you can avoid missiles or bullets
On the 060 (66 MHz) it's very smooth. However I have to run it from MiNT for maximal speed. From TOS it's even slower than 030 mode.
I prefer playing with the keyboard, so I can switch faster between regular shoots and super-missiles.

Keep up the good work!

[Eero Tamminen]

On the 060 (66 MHz) it's very smooth. However I have to run it from MiNT for maximal speed. From TOS it's even slower than 030 mode.

I wonder whether game uses gcc/MiNTlib for anything. Some of MiNTlib (timing) functions behave differently under TOS domain than MiNT one, but worst issues with that "should" have been fixed with latest MiNTlib versions (in CVS at least, not sure about Vincent's cross-gcc)...

[Anima]

On the 060 (66 MHz) it's very smooth. However I have to run it from MiNT for maximal speed. From TOS it's even slower than 030 mode.
I prefer playing with the keyboard, so I can switch faster between regular shoots and super-missiles.

Keep up the good work!

Thanks for the report. Haven't had the time to prepare the promised version for accelerated machines yet. Hope to find some time in the next days.

I wonder whether game uses gcc/MiNTlib for anything. Some of MiNTlib (timing) functions behave differently under TOS domain than MiNT one, but worst issues with that "should" have been fixed with latest MiNTlib versions (in CVS at least, not sure about Vincent's cross-gcc)...

The program uses only a few GEMDOS functions (mostly file functions) and no additional libraries. The game synchronisation is completely bound to the VBL interrupt.

[Anima]

Here's a short explanation why the sprite graphics were corrupted.

First the original disassembled compiled C source snippet:

Code: Select all

[...]
L_00020872:
	movea.l LONG_000221E2(pc),A2
	lea     8(A2),A2
	lea     PCG_REV_ALT,A4
	movea.l OX_CHK_POINTER(pc),A5
	move.l  #L_00EB8000+$0,D4
	move.l  PCG_DAT_ADDRESS(pc),D5
	move.w  OX_CHK_SIZE(pc),D7
	move.b  D6,D2
	subq.b  #$2,D2

	bra.s   L_000208A0

L_00020898:
	bra.w   L_000209BE

L_0002089C:
	move.b  D1,1(A0)

L_000208A0:
	movea.l (A7)+,A0
	move.w  (A7)+,D0
	bmi.s   L_00020898

	move.b  0(A3,D0.w),D1
	bne.s   L_0002089C

L_000208AC:
	cmp.b   (A5)+,D2
	dbhi    D7,L_000208AC

	bls.w   L_00020938

	tst.b   -(A5)
	bne.s   L_000208C0

	movea.l OX_CHK_TOP(pc),A5

	bra.s   L_000208AC

L_000208C0:
	move.w  A5,D1
	sub.w   A6,D1
	move.b  D1,1(A0)
	move.b  D6,(A5)+
	move.b  D1,0(A3,D0.w)
	add.w   D1,D1
	move.w  0(A4,D1.w),D3
	move.b  D4,0(A3,D3.w)
	move.w  D0,0(A4,D1.w)
	ext.l   D0
	lsl.l   #$7,D0
	add.l   D5,D0
	ext.l   D1
	lsl.w   #$6,D1
	add.l   D4,D1
	movea.l D0,A0
	movea.l D1,A1

	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+
	move.l  (A0)+,(A1)+

	dbf     D7,L_000208A0
[...]

On the X68000 the label "L_00EB8000" is directly mapped to the address $eb8000 while on the Atari it's a simple memory space of the same size in the .bss area. So far everything seems to be ok. Also the memory access itself works fine using the register D4 on the X68000 and the Atari.

However, something looks strange about how the register D4 is being used. In fact, the compiler decided to choose a very "clever" optimisation which is probably caused by a "maximum optimisation" switch of the original X68000 C compiler (see instruction "move.b D4,0(A3,D3.w)"). Instead of using a "clr.b" it simply uses the lower byte of the data register D4 because that's faster on the MC68000. The compiler knows that the register holds the constant value $eb8000 and so the optimisation is completely legal. Using a different address in D4 which is not aligned at 256 bytes will result in corrupted sprites. So I just replaced that instruction with a simple "clr.b" to fix it.

[Eero Tamminen]

On the 060 (66 MHz) it's very smooth. However I have to run it from MiNT for maximal speed. From TOS it's even slower than 030 mode.
I prefer playing with the keyboard, so I can switch faster between regular shoots and super-missiles.

Keep up the good work!

Thanks for the report. Haven't had the time to prepare the promised version for accelerated machines yet. Hope to find some time in the next days.

I wonder whether game uses gcc/MiNTlib for anything. Some of MiNTlib (timing) functions behave differently under TOS domain than MiNT one, but worst issues with that "should" have been fixed with latest MiNTlib versions (in CVS at least, not sure about Vincent's cross-gcc)...

The program uses only a few GEMDOS functions (mostly file functions) and no additional libraries. The game synchronisation is completely bound to the VBL interrupt.

MiNT replaces TOS GEMDOS with its own GEMDOS function implementations. I guess file functions in MiNT could utilize caching, but I would assume that all the file reads are done before & between levels, not during level. What GEMDOS (or BIOS) functions you use during level play?

[Anima]

MiNT replaces TOS GEMDOS with its own GEMDOS function implementations. I guess file functions in MiNT could utilize caching, but I would assume that all the file reads are done before & between levels, not during level. What GEMDOS (or BIOS) functions you use during level play?

Yes, all the file operations are used only at the program start. So far it uses only the following GEMDOS file functions: Fopen, Fread, Fseek and Fclose. There are indeed some standard C library functions in the original binary like "printf" but these are disabled in the Atari binary.