The X68000 games porting experiment

[AnimaInCorpore]

Another hint for the DMA usage in Pac-Mania: writing to the address $E84087 initiates a DMA transfer to copy or fill memory blocks. The last instruction of "DMA_BLOCK_COPY" and "DMA_BLOCK_ERASE" are doing this so you need an own copy/fill subroutine to be invoked at that point. Also search for "L_00E84000+0x87.l" within the code and put your subroutine at the right place as well. I am also checking if the target memory lies between $EB8000 and $EB8000+0x6000 because that is the sprite data memory. In fact, the DMA is used for the animation of the characters.

Here's a short example how it works:

x68k_dma:
	move	#0x2700,sr

	movem.l	d0-d7/a0-a6,-(sp)

	lea		L_00E84000+0x80,a0
	cmp.l	#L_00EB8000,20(a0)
	jlt		1f
	cmp.l	#L_00EB8000+0x6000,20(a0)
	jge		1f
	move	10(a0),d0
	move.l	12(a0),a0
	lsr		#7-1,d0
	jbsr	convert_sprites

1:
	lea		L_00E84000+0x80,a0
	move.l	12(a0),a1
	move.l	20(a0),a2
	move	10(a0),d0

	move	d0,d1
	lsr		#5,d0
	and		#0x1f,d1
	move	#32,d2
	sub		d1,d2
	add		d2,d2

	cmp.b	#0x5,6(a0)
	jne		x68k_dma_not_copy

	jmp		x68k_dma_copy_loop(pc,d2.w)
x68k_dma_copy_loop:
.rept 32
	move	(a1)+,(a2)+
.endr
	dbf		d0,x68k_dma_copy_loop

	jra		x68k_dma_exit

x68k_dma_not_copy:
	move	(a1),d1

	jmp		x68k_dma_fill_loop(pc,d2.w)
x68k_dma_fill_loop:
.rept 32
	move	d1,(a2)+
.endr
	dbf		d0,x68k_dma_fill_loop

x68k_dma_exit:
	movem.l	(sp)+,d0-d7/a0-a6

	move	#0x2300,sr

	rts

[meynaf]

Well after thinking about it, i've changed my mind about the way to make these ports. It appears we're not using the right methods here.

We have two Atari game ports. We need two Amiga game ports.
But, wait. If we had a common platform interface, rewriting that code would be all that's needed to make one.

So the idea is to replace every X68000 (or Atari, depending where you start from) specific thing by some call to an external, well-documented function which you invent yourself. The fact the function is just a place holder does not matter as long as it behaves correctly (and we can leave the most difficult ones for later).
If the same functions are used for every port (they clearly are for my ST ports, even my Mac HOMM2 port works with that very same set), then it's just a matter of implementing them. These functions have to be high level enough, like load a file at some place, wait next vbl, update screen region, etc, but certainly not "emulate X68k register xyz". They need to be put in an include file so nothing specific remains in the main source. This way, whether the port is made on Atari or Amiga would simply not matter : only the special functions would differ !
And cherry on the cake, having that for the x68k itself would make a great reference...

About the asm syntax, try assembling on Atari with Devpac and you will see what needs to be changed (we need to use a common syntax of course).
You could also try VAsm on the PC (perhaps it's able to make an x68k exe, if not i can request it).

Are you ready to work this way ?

[AnimaInCorpore]

Originally Posted by meynaf

But, wait. If we had a common platform interface, rewriting that code would be all that's needed to make one.

I agree.

Originally Posted by meynaf

So the idea is to replace every X68000 (or Atari, depending where you start from) specific thing by some call to an external, well-documented function which you invent yourself. The fact the function is just a place holder does not matter as long as it behaves correctly (and we can leave the most difficult ones for later).
If the same functions are used for every port (they clearly are for my ST ports, even my Mac HOMM2 port works with that very same set), then it's just a matter of implementing them. These functions have to be high level enough, like load a file at some place, wait next vbl, update screen region, etc, but certainly not "emulate X68k register xyz". They need to be put in an include file so nothing specific remains in the main source. This way, whether the port is made on Atari or Amiga would simply not matter : only the special functions would differ !
And cherry on the cake, having that for the x68k itself would make a great reference...

I agree as well.

I would suggest to use a platform like GitHub or Bitbucket to keep the sources and the use of "define" for the platform specific parts. You can choose what you like. I already have a Bitbucket account but I can also register at GitHub. What do you think?

Originally Posted by meynaf

About the asm syntax, try assembling on Atari with Devpac and you will see what needs to be changed (we need to use a common syntax of course).

Definitely.

Originally Posted by meynaf

You could also try VAsm on the PC (perhaps it's able to make an x68k exe, if not i can request it).

Ok, it seems that vasm is the way to go.

Originally Posted by meynaf

Are you ready to work this way ?

Yep. So my first step is to prepare the source for vasm to have a working X68000 binary again. I'll check if the human68k toolchain is able to work with the vasm output.

[meynaf]

Originally Posted by AnimaInCorpore

I would suggest to use a platform like GitHub or Bitbucket to keep the sources and the use of "define" for the platform specific parts. You can choose what you like. I already have a Bitbucket account but I can also register at GitHub. What do you think?

This kind of site has a problem : i can't go there with IBrowse, at least not when it's https. Why would we need to host the sources on a commercial site anyway ?

Originally Posted by AnimaInCorpore

Yep. So my first step is to prepare the source for vasm to have a working X68000 binary again. I'll check if the human68k toolchain is able to work with the vasm output.

Ok. Let's see what will come out of that first step.

[phx]

Originally Posted by meynaf

You could also try VAsm on the PC (perhaps it's able to make an x68k exe, if not i can request it).

Is the Human68k executable file format documented somewhere?

[AnimaInCorpore]

Originally Posted by meynaf

This kind of site has a problem : i can't go there with IBrowse, at least not when it's https. Why would we need to host the sources on a commercial site anyway ?

I would like to keep the sources in a GIT repository or an appropriate alternative. It doesn't have to be one of those sites.

Originally Posted by meynaf

Ok. Let's see what will come out of that first step.

So far the ELF output format does kind of work but the result crashes on the X68000 probably caused by some nasty jump address calculations or wrong labels. I need to check that later on.

[AnimaInCorpore]

Found some time to have a look at the problem. So the ELF format is fine. Checked the (now vasm compatible) disassembler output of another X68000 game in combination with the human68k toolchain and the reassembled result now works on the X68000.

[Retro1234]

holy @!#.? [ Show youtube player ]

[AnimaInCorpore]

Who dares to do a port of Cho Ren Sha 68k for the Amiga 1200? The sources are available in a vasm compatible syntax.

[Amiga1992]

I love ChoRenSha 68k, would love an AMiga version!

[Locutus]

Cho Ren Sha made my brain melt after a while

[phx]

Originally Posted by AnimaInCorpore

Who dares to do a port of Cho Ren Sha 68k for the Amiga 1200?

Certainly not. The port looks awesome! Is it running on a 68060-Falcon? How much of the game was rewritten and adapted to use the Falcon's coprocessors? Or is it all rendered with the CPU?

The sources are available in a vasm compatible syntax.

Where are they?

[frank_b]

Originally Posted by phx

Certainly not. The port looks awesome! Is it running on a 68060-Falcon? How much of the game was rewritten and adapted to use the Falcon's coprocessors? Or is it all rendered with the CPU?

Where are they?

That's an *unaccelerated* Falcon I believe. IE DSP, blitter + 16 mhz CPU.

[AnimaInCorpore]

Originally Posted by phx

Certainly not. The port looks awesome! Is it running on a 68060-Falcon? How much of the game was rewritten and adapted to use the Falcon's coprocessors? Or is it all rendered with the CPU?

Thanks. The [ Show youtube player ] linked above shows an alpha version running on a stock 16 MHz Atari Falcon with 14 MB RAM.

The original game source contains only a few modifications (21 conditional "ifd __ATARI__" parts) to invoke the appropriate sprite/graphics routines. In fact, the same game source can be assembled for the X68000 as well to check if it's still 100% identical to the original. The system related routine calls (DOS and IOCS) are being emulated by redirection since those are Traps and Line-F calls. So the Atari version could be called a 50% emulation.

Except for the DSP which supports the CPU for sprite drawing there's no special use of the other Atari Falcon custom chips. But even that shouldn't be a problem since the graphics interface is quite clean due to the aforementioned simple game source modifications. I.e. the Amiga specific routine calls could be put at the very same places.

Originally Posted by phx

Where are they?

They're not public but available on request. If someone is interested to have a look at them please send me a pm.

That's an *unaccelerated* Falcon I believe. IE DSP, blitter + 16 mhz CPU.

Except for the Blitter you're right.

[meynaf]

Originally Posted by AnimaInCorpore

I.e. the Amiga specific routine calls could be put at the very same places.

Not so easy if the game asks for a 65536 color (16-bit) frame buffer...
It does use such a mode, doesn't it ?

[Retro1234]

What screen modes does the x68000 have? You need graphics converted to 256? thers a few artists about here on eab.
Can I get a copy of one of them maybe pacman compiled just some text output? - Im sad like that.

Have you had any running on others in Atari ST family Like the ST/Mega/TT/ etc?

I think Atari just smashed Amiga

[meynaf]

Originally Posted by Boo Boo

You need graphics converted to 256? thers a few artists about here on eab.

'Tis more about graphical routines than the graphics themselves. For converting to 256, the code must be changed. And that's the big part.

[AnimaInCorpore]

Originally Posted by meynaf

Not so easy if the game asks for a 65536 color (16-bit) frame buffer...
It does use such a mode, doesn't it ?

Actually the game just says what sprite (ID) should be displayed at the position x, y and also if it is flipped. You may prepare your sprites for the optimal display while loading the data. Nothing more and nothing less. So it's completely up to you how to display the sprites. The background and text display is also not bound to any special graphic modes as well.

[meynaf]

Originally Posted by AnimaInCorpore

Actually the game just says what sprite (ID) should be displayed at the position x, y and also if it is flipped. You may prepare your sprites for the optimal display while loading the data. Nothing more and nothing less. So it's completely up to you how to display the sprites. The background and text display is also not bound to any special graphic modes as well.

So even the file i/o routines are supposed to know that they load ?
I mean, it's not just general i/o to load data regardless of what it is ?

[AnimaInCorpore]

Originally Posted by meynaf

So even the file i/o routines are supposed to know that they load ?
I mean, it's not just general i/o to load data regardless of what it is ?

There are routines for loading the samples and the sprites which also track the sprite/sample IDs and storage addresses. Because the game has been written originally in C all of them are using the standard fopen(), fread(), fseek() and fclose() functions. So you can easily add/inject your own conversion routines.

However, you should be aware that up to 512 sprites (16 x 16 pixels) are being displayed on the screen simultaneously.