The X68000 games porting experiment - Page 2

saimon69 · 11 September 2014, 21:46

For the sound emulation, you said was matter of have instruction liker start and stop; you think could be mapped to in example a Mod player if someone want to convert the music in mod format?
[don't look at me for at least a while, since HOMM2 takes most of my free time :P ]

AnimaInCorpore · 11 September 2014, 22:31

Quote:

Originally Posted by saimon69

For the sound emulation, you said was matter of have instruction liker start and stop; you think could be mapped to in example a Mod player if someone want to convert the music in mod format?
[don't look at me for at least a while, since HOMM2 takes most of my free time :P ]

Correct. Most X68000 games use a "separate" memory resident music driver which is started before and invoked through TRAP calls from within the game. So basically these parts could simply be replaced with the appropriate MOD routines.

[No problem: There's no hurry since these are still only thoughts about how a port could be one.

]

Cheers
Sascha

dlfrsilver · 12 September 2014, 02:57

Quote:

Originally Posted by AnimaInCorpore

Unfortunately I cannot link to the original discussion thread on the Atari-Forum where you can get more details about how the port was done. The AF webserver seems to have some serious problems and I hope that they'll sort it out soon.

However, the sources are disassembled and many important functions commented. The reassembled source runs natively on the X68000 again even with changes. So I was able to make a Pac-Mania trainer for the X68000.

The graphics emulation is done by putting "jsr" hooks in the source code where the sprites and background are being drawn on the Atari. The sound emulation was simply commented out.

The X68000 has indeed a decent sprite hardware but it is still limited by the fact that the memory mapped area of the sprite data is quite small. The games need to refresh that area to get all the sprites displayed so this results in either a DMA copy (Pac-Mania sprite animation) or caching (Galaga 88 compressed sprites) strategy.

What needs to be done for the Amiga port is to replace all the graphics functions and convert the graphics (sprites and backgrounds). This applies to the sound as well but that seems to be a far "simpler" task.

Cheers
Sascha

You mean convert the sprites as tiles to sprites frames right ?

12 September 2014, 08:52

I want to get more info about this topic because I am taking interest in it.

AnimaInCorpore · 12 September 2014, 08:53

Quote:

Originally Posted by dlfrsilver

You mean convert the sprites as tiles to sprites frames right ?

Yes. But be aware that the sprites are composed of the data itself and the colour palette which can be changed dynamically. So this isn't as easy as it might seem. Fortunately both games do not use the sprite flipping feature.

Cheers
Sascha

dlfrsilver · 13 September 2014, 06:18

for instance you have only 16 colors for a sprites, note also that arcade boards use dynamic palette, which doesn't exist on computers. Most of the time, the coin-op games are in fact real 256 colors games, if you get all the sprites with the right colors.

Arcade boards are more of less PC-like architectures without keyboard and driven by a 68000 processor.

AnimaInCorpore · 13 September 2014, 07:49

AF is up again so here's the link where you can find more details about the Atari port: http://www.atari-forum.com/viewtopic.php?f=68&t=24111

Wepl · 13 September 2014, 21:10

Hmm. Read the AF thread.
In AGA Amiga there is no 64k color mode. I have no idea how to display 2x 256 color screens + sprites + text as used in Galaga88.

AnimaInCorpore · 14 September 2014, 09:29

Quote:

Originally Posted by Wepl

Hmm. Read the AF thread.
In AGA Amiga there is no 64k color mode. I have no idea how to display 2x 256 color screens + sprites + text as used in Galaga88.

To make a port for the Amiga I would suggest to disable any graphic function and see if the game logic itself runs properly without them. Then add the appropriate functions step by step. This applies to the sound as well.

Asman · 14 September 2014, 13:08

Quote:

Originally Posted by AnimaInCorpore

To make a port for the Amiga I would suggest to disable any graphic function and see if the game logic itself runs properly without them. Then add the appropriate functions step by step. This applies to the sound as well.

Sorry for stupid question, but how I can be sure that game logic itself runs properly wihout any graphice function ?

AnimaInCorpore · 14 September 2014, 13:50

Quote:

Originally Posted by Asman

Sorry for stupid question, but how I can be sure that game logic itself runs properly wihout any graphice function ?

Of course you need to have a visual "feedback" to see if the main loop is running (e.g. the attract mode). I've done this by emulating and displaying the first sprite on screen. A simple text layer emulation would do the trick also or display a hex value of a known memory address like a frame counter.

AnimaInCorpore · 14 September 2014, 14:37

Ok, here a short description why the source code is universal. It can be assembled and run on the X68000 and with only a few lines changed with additional TRAP and LINEF handlers the same source runs on a Atari ST as well (without any graphics emulation).

Addresses for interrupt vectors and X68000 memory mapped adresses are defined as follows (Pac-Mania):

Code:

	move.l  L_0000007C,OLD_7C_HANDLER.l
	move.l  #NULL_NMI_HANDLER,L_0000007C
	move.l  L_000000AC,OLD_AC_HANDLER.l
	move.l  #NULL_IRQ_HANDLER,L_000000AC
	move.l  L_000000B0,OLD_B0_HANDLER.l
	move.l  #NULL_IRQ_HANDLER,L_000000B0
	move.l  L_000000B4,OLD_B4_HANDLER.l
	move.l  #NULL_IRQ_HANDLER,L_000000B4
	move.l  L_000000B8,OLD_PROGRAM_ERROR_HANDLER.l
	move.l  #PROGRAM_ERROR_HANDLER,L_000000B8

The example above shows the interrupt vectors initialisation. The X68000 source has simply the label definitions like this: "L_0000007C = 0x0000007c" where the Atari source has the label pointing to a long word within the BSS area.

The VBL handling would look like this:

Code:

vbl:
	[Your code]

	move.l	L_00000118,-(sp)
	beq.s	_vbl_no_vdisp_handler

	rts

_vbl_no_vdisp_handler:
	addq.l	#4,sp

	rte

Here the handling of memory mapped registers: the X68000 target has the label defined as being described above where the Atari source defines a buffer within the BSS area:

Code:

	move.w  L_00E80000+0x2A.l,OLD_CRTC_PLANE_ACCESS_MODE_REGISTER.l
	move.w  #0x0,L_00E80000+0x2A.l
	move.w  L_00E82000+0x500.l,OLD_VIDEO_CONTROLLER_PRIORITY_REGISTER.l
	move.w  #0x12E4,L_00E82000+0x500.l
	move.w  L_00E82000+0x600.l,OLD_VIDEO_CONTROLLER_SPECIAL_PRIORITY_REGISTER.l
	move.w  #0x0,L_00E82000+0x600.l
	move.w  L_00EB0000+0x808.l,OLD_BG_CONTROL_REGISTER.l
	move.w  #0x212,L_00EB0000+0x808.l

Code:

L_00E80000:   | CRTC
	ds.b    0x2000
L_00E82000:   | VIDEO CONTROLLER
	ds.b    0x2000
L_00EB0000:   | SPRITE REGISTERS
	ds.b    0x8000

All you now need to do is to read the X68000 registers from the BSS area and emulate it.

meynaf · 15 September 2014, 13:02

Quote:

Originally Posted by AnimaInCorpore

Ok, here a short description why the source code is universal. It can be assembled and run on the X68000 and with only a few lines changed with additional TRAP and LINEF handlers the same source runs on a Atari ST as well (without any graphics emulation).

If it can assemble and run on an Atari ST then maybe I can make it work as well on Amiga.
For a start remapping 64k colors to 256 on the fly may allow seeing something on screen, even if it becomes very slow.
If we can know which screen areas are updated and when, maybe it can even be done in real time.
Perhaps you could put a direct link to the sources here ?

AnimaInCorpore · 16 September 2014, 00:56

Here are the sources for Galaga 88 and Pac-Mania. Both can be assembled with the Human68k toolchain to build executables which will work on the X68000 again.

The additional data files for Galaga 88 can be found in the release for the Atari Falcon (in fact no data has been modified in any way so the files from the original game disks will work as well).

Some notes about the changes to get Galaga 88 running virtually on the Amiga:

Remove the fixed address labels in the header and add the following BSS data. Please note that many memory mapped areas are not used and therefore they've been commented out ("|"). However, the VRAM is always 2 MiB in size due to the special graphics memory map layout so you'll need quite a lot of RAM even for a simple port without graphics emulation.

Code:

L_00C00000:   | VRAM
	ds.b    0x200000
L_00E00000:   | TEXT PLANE 1
	ds.b    0x20000
L_00E20000:   | TEXT PLANE 2
	ds.b    0x20000
L_00E40000:   | TEXT PLANE 3
	ds.b    0x20000
L_00E60000:   | TEXT PLANE 4
	ds.b    0x20000
L_00E80000:   | CRTC
	ds.b    0x2000
L_00E82000:   | VIDEO CONTROLLER
	ds.b    0x2000
|L_00E84000:   | DMAC
|	ds.b    0x2000
|L_00E86000:   | AREA
|	ds.b    0x2000
L_00E88000:   | MFP
	ds.b    0x2000
|L_00E8A000:   | RTC
|	ds.b    0x2000
|L_00E8C000:   | PRINTER
|	ds.b    0x2000
L_00E8E000:   | SYSTEM PORT
	ds.b    0x2000
|L_00E90000:   | FM
|	ds.b    0x2000
|L_00E92000:   | ADPCM
|	ds.b    0x2000
L_00E94000:   | FDC
	ds.b    0x2000
|L_00E96000:   | HDD
|	ds.b    0x21
|L_00E96021:   | SCSI (HDD)
|	ds.b    0x1FDF
|L_00E98000:   | SCC
|	ds.b    0x2000
L_00E9A000:   | I/O
	ds.b    0x4000
|L_00E9E000:   | FPU
|	ds.b    0x2000
|L_00EA0000:   | SCSI
|	ds.b    0xF900
|L_00EAF900:   | FAX
|	ds.b    0x100
|L_00EAFA00:   | MIDI 1
|	ds.b    0x10
|L_00EAFA10:   | MIDI 2
|	ds.b    0xF0
|L_00EAFB00:   | (ToDo)
|	ds.b    0x500
L_00EB0000:   | SPRITE REGISTERS
	ds.b    0x8000
L_00EB8000:   | SPRITE VRAM
	ds.b    0x8000
|L_00EC0000:   | USER I/O
|	ds.b    0x10000
L_00ED0000:   | SRAM
	ds.b    0x4000
|L_00ED4000:   | 'PRELIMINARY'
|	ds.b    0x1C000
|L_00EF0000:   | 'UNUSED'
|	ds.b    0x10000
|L_00F00000:   | CG ROM
|	ds.b    0xC0000
|L_00FC0000:   | 'PRELIMINARY'
|	ds.b    0x20000
|L_00FE0000:   | IPL ROM
|	ds.b    0x20000

Search for instructions accessing "0x18.l", "0xb8.l", 0x118.l" and "0x130.l". Remap them to BSS data labels as well. I noticed that I have not changed those addresses in the source linked above.

Now you should be able to compile the code. You probably need to cleanup the code a bit to meet your assembler syntax demands.

The next step is to add functions to simulate X68000 OS calls. To do so add a handler for TRAP #15 and LINEF like shown in the following code:

Code:

line_f:
	movem.l	d1-d2/a0-a2,-(sp)

	move.l	22(sp),a0
	move	(a0),d0
	addq.l	#2,22(sp)

	cmp		#0xff3d,d0
	bne		line_f_not_open

	move.l	26+LINE_F_OFFSET+0(sp),a0
	move	26+LINE_F_OFFSET+4(sp),d0

	move.w	d0,-(sp)
	pea		(a0)
	move.w	#61,-(sp)
	trap	#1
	addq.l	#8,sp

	bra		line_f_exit

line_f_not_open:
	cmp		#0xff3f,d0
	bne		line_f_not_read

	move	26+LINE_F_OFFSET+0(sp),d0
	move.l	26+LINE_F_OFFSET+2(sp),a0
	move.l	26+LINE_F_OFFSET+6(sp),d1
	and.l	#0x7fffffff,d1

	pea		(a0)
	move.l	d1,-(sp)
	move	d0,-(sp)
	move	#63,-(sp)
	trap	#1
	lea		12(sp),sp

	bra		line_f_exit

line_f_not_read:
	cmp		#0xff3e,d0
	bne		line_f_not_close

	move	26+LINE_F_OFFSET+0(sp),d0

	move.w	d0,-(sp)
	move.w	#62,-(sp)
	trap	#1
	addq.l	#4,sp

	bra		line_f_exit

line_f_not_close:

	clr.l	d0
line_f_exit:
	movem.l	(sp)+,d1-d2/a0-a2

	rte

trap_f:
	cmp		#17,d0
	bne		trap_f_not_contrast

	move	#15,d0

	rte

trap_f_not_contrast:
	cmp		#22,d0
	bne		trap_f_not_fntadr

	move.l	#draw_text_overlay+1024*512/8,d0 | Simply a valid dummy address (font address) where write accesses don't hurt much.

	rte

trap_f_not_fntadr:
	cmp		#0x21,d0
	bne		trap_f_not_b_print

	movem.l	d0-d2/a0-a2,-(sp)

	pea		(a1)
	move.w	#9,-(sp)
	trap	#1
	addq.l	#6,sp

	movem.l	(sp)+,d0-d2/a0-a2

	rte

trap_f_not_b_print:
	cmp		#0x60,d0
	bne		trap_f_not_adpcmout

	rte

trap_f_not_adpcmout:
	cmp		#0x6c,d0
	bne		trap_f_not_vdispst

	cmp.l	#0,a1
	bne		trap_f_vdispst_set

	move.l	a1,L_00000118
	clr.l	d0

	rte

trap_f_vdispst_set:
	clr.l	L_00000118
	clr.l	d0

	rte

trap_f_not_vdispst:
trap_f_exit:
	clr.l	d0

	rte

As you can see there's not much to do. Just fopen(), fread() and fclose() need to be simulated in the LINEF handler (here: mapped to Atari Trap #1 calls) also setting the X68000 VBL handler is the only important function in the TRAP #15 handler. I would suggest to replace the calls within the source directly with the appropriate Amiga DOS functions. However, please note the dummy return values of the remaining TRAP #15 and LINEF calls which the callee expect.

To disable the sound we need to comment out all TRAP #1 calls.

In the next step we will add timing functions. Setup a VBL routine and call the function at L_00000118 if the vector is not 0 (see TRAP #15 handler for the original VBL handler setup).

Alter the COUNT_VDISP_LOW_HIGH_STATE like shown in the following code snippet. This needs to be done because the function tests a VBL state flag which can be replaced by a simpler function.

Code:

COUNT_VDISP_LOW_HIGH_STATE:
wait_for_vbl:		| fixme
	addq.b	#3,70(a4)
	addq.b	#3,72(a4)
	tst	vbl_counter
	beq.s	wait_for_vbl
	clr	vbl_counter
	rts

Also add a VBL wait to the WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS routine as well. Replace the first six lines of code:

Code:

WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS:
	addq.b  #0x3,70(%A4)                            | 0x0002BB32 562C 0046                | S(0x00029C28)
	btst    #0x4,L_00E88000+0x1.l                   | 0x0002BB36 0839 0004 00E8 8001      | [MFP + 0x1]
	beq.s   WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS                              | 0x0002BB3E 67F2                     |

L_0002BB40:
	addq.b  #0x3,72(%A4)                            | 0x0002BB40 562C 0048                |
	btst    #0x4,L_00E88000+0x1.l                   | 0x0002BB44 0839 0004 00E8 8001      | [MFP + 0x1]
	bne.s   L_0002BB40                              | 0x0002BB4C 66F2                     |

with:

Code:

WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS:
wait_for_vbl:
	addq.b	#3,70(a4)
	addq.b	#3,72(a4)
	tst	vbl_counter
	beq.s	wait_for_vbl
	clr	vbl_counter

Finally before starting the main routine of Galaga 88 you need to initialise the virtual joystick data so that the attract mode will not be interrupted:

Code:

	move.b	#0xff,L_00E9A000+0x1.l	| Joystick 1 button and direction bits are inverted.
	move.b	#0xff,L_00E9A000+0x3.l	| Joystick 2 button and direction bits are inverted.

So now the game should run in a attract mode loop internally. As you can see there's not really changed much in the original source. At least the strategy works for Pac-Mania so far as well.

I'm not sure if I have missed something. Some time has passed since the port but I think that were the most important steps to have a good starting point.

meynaf · 16 September 2014, 09:33

Thanks.
I'll have a closer look at all that.
If it can work i may do something out of it, and if it can't i'll know why

turrican3 · 17 September 2014, 02:06

Thanks meynaf, i hope you will success...But it looks really tricky.
Akumajou Draculaon amiga aga !!!!! i want it !

Amiga1992 · 17 September 2014, 10:02

Quote:

Originally Posted by AnimaInCorpore

To make a port for the Amiga I would suggest to disable any graphic function and see if the game logic itself runs properly without them. Then add the appropriate functions step by step. This applies to the sound as well.

Here's the key to a decent port.
What makes a game is the game logic. If you get that right you can work the rest up. You can make the graphics work the way the Amiga needs them to work, you will reduce colors and have the graphics in the format the Amiga needs and you will create a soundtrack that will easily work with the Amiga.

I for one think this would work just great. Galaga'88 is awesome and would be very much welcomed to the Amiga and a proper Pacmania port would be perfect too.

meynaf · 18 September 2014, 10:07

First thing to say, Pac-mania is the one i wish to concentrate on, because it's smaller.

But for making some useful port, I need to plug in :

1. Screen buffer. No idea at all here : resolution is unknown, frame address also is, so i can't even show a background. Only thing i could do is the vbl handler.

2. File i/o. Very easy here (no need for a trap handler, load code is simple). Done. But this means i need the data files as well...

3. Input (joystick and maybe also keyboard) - missing infos could be rebuilt from that nice keyboard_joystick_translation_table. At least the game author seemed smart enough to have a central test routine. These things help a lot ! Partially done : that read_keyboard routine contains trap #15 i don't know a thing about.

4. Sound. That one can be postponed, ok

But if some PCM samples are output, then why not doing it now ? There is some play sample routine, btw. If you can tell me what the trap #15 here are doing, it would be of a great help.

5. Memory management. As everything seems to be in bss, no problem here ?

That asm syntax is a pain to work with. I could somehow cope, but i'm not sure my numerous search-replace didn't break something. It would be safer for me to have a .TOS for the ST (ST .TOS, not Falcon .TOS, even if it contains Falcon code), as a reference (if not as a new starting point). The best for me would be the X68000 version but in .TOS format, where everything internal to the program is relocated. My own disassembler would then warn me about all direct (non-reloc) memory accesses, suspicious code, and so on, and that's of a great help to me.

About the code you posted, what is A4 in that COUNT_VDISP thing ? Counting the busy wait loops is totally unsafe (depends on cpu speed). Besides, we have WaitTOF() to do a vblank wait - and i just hate busy waits.
Replacing that by my good old waitvbl routine is peanuts, but these $70(a4) and $72(a4) variables are in the way.

I have zero knowledge about the X68000 and the sources don't give a clue on what the os calls and hardware accesses do.

The line_f looks a lot like ST's trap #1. But FF23, FF0F, FF0C lead to function numbers that do not exist there. What are they supposed to do ?

Your "vdispst" code seems wrong to me. If A1=0, move A1 to $118. If not, clear $118. The test on A1 is useless ; $118 always ends up cleared (and if the test were reversed, a simple move A1 to $118 would be enough).

Many trap #15 are "unknown" (-> no-op in the handler) : fct #4, #14, #16, #35, (etc). But they have to do something, right ?

Just looking at the start of the code (pac-mania) there are mysteries for me.
A line F call $FF23.
A trap #15 with D0=4.
Some copyright text supposed to be displayed, but the data only remotely looks like text (japanese text maybe ?). Sending that directly to some console output doesn't look like a very smart idea.

There is also some old remnant of protection code. And that trap #10 turned into trap #15 by altering the code has very few chances to properly work on '060 (i doubt it even does on '030).
This, of course, won't tell me what that trap #15 was supposed to be doing...

gulliver · 18 September 2014, 17:23

Quote: