Pacman - the Amiga conversion from the arcade game

[jotd]

link to code is dead

[mcgeezer]

Here's how I would handle this one...

I'd start by analysing the opcodes that are used in the pacman disassembly, the z80 cpu has about 700 different opcodes... as shown here:

http://z80.info/opcodes.txt

I'd then be looking to come up with a strategy to mapping the z80 registers to the 68k regs.

I don't see the above being too difficult..

The hard part as I see it is knowing how to do the memory mapping. I'm not sure (yet) how I would be able to distinguish a 16bit memory mapped address from a 16bit absolute value used for other purpose.

You could keep an address register at a 64kb boundary and somehow map the z80 addresses to it.

I really haven't thought this post through at all have it.

I'll keep thinking.

Geezer

[kamelito]

The converter is here
“
https://nowhereman999.wordpress.com/about/

[alexh]

Originally Posted by kamelito

The converter is here
“
https://nowhereman999.wordpress.com/about/

Yeah.

http://www..com/file/eqlgx1t0vsl0r6n..._15.c.zip/file

[Anubis]

Never mind - for some strange reason you can't post M E D I A F I R E links on EAB. (or write that word here )

Uploaded file to the zone..

[DamienD]

Originally Posted by Anubis

Never mind - for some strange reason you can't post M E D I A F I R E links on EAB. (or write that word here )

Yeah blocked; been like that for many years now...

Not sure of the exact reason behind it.

[mcgeezer]

So I had a bit of a further think about this, apologies but I haven't been able to test any of it yet.

@mods - you might want to move this into a technical section.


I'd setup my z80 -> 68k registers like below, the I register does not seem to be directly updated.

REGISTERS:
	A	equr	D0
	B	equr	D1
	C	equr	D2
	D	equr	D3
	E	equr	D4
	H	equr	D5
	L	equr	D6
	HL	equr	A0
	BC	equr	A1
	DE	equr	A2
	IX	equr	A3
	IY	equr	A4
	SP	equr	SP
	SCRATCH	equr	D7

• The high word in D7 would be set to Amiga Chip ram 64Kb page where the PACMAN rom is actually loaded as per the... MAME driver doc: https://github.com/mamedev/mame/blob...ers/pacman.cpp
• A5 would probably point to the top of the Amiga copper list or Chip base
• A6 would point to something sensible.

I'd approach this by using a translator that reads the rom code section and creates equivalent 68000 code, all of the instructions that relate to branches/loops would need to be calculated and the status register honored.

If any of Z80 instructions update a register I would create code from the macros below. (i.e. if address reg HL updates then the H and L data regs must be updated too. This will probably be fast enough.

; Update 8 bit regs...
UPDATE_DATA_HL MACRO
	move.l	HL,L			; HL into H
	move.w	L,H			; L done
	lsr.w	#8,H			; H done
	ENDM
	
UPDATE_DATA_BC MACRO
	move.l	BC,C			; BC into B
	move.w	C,B			; C done
	lsr.w	#8,B			; B done
	ENDM
		
UPDATE_DATA_DE MACRO
	move.l	DE,E			; DE into D
	move.w	E,D			; E done
	lsr.w	#8,D			; D done
	ENDM
	
; SCRATCH (d7) register holds memory base 64k segment.  for example.... $30000
UPDATE_ADDR_HL MACRO
	move.w	H,SCRATCH			; H into Scratch reg
	lsl.w	#8,SCRATCH			; shift up into high byte
	or.b	L,SCRATCH			; fetch L into low byte
	move.l	SCRATCH,HL			; Update HL
	ENDM
	
UPDATE_ADDR_BC MACRO
	move.w	B,SCRATCH			; B into Scratch reg
	lsl.w	#8,SCRATCH			; shift up into high byte
	or.b	C,SCRATCH			; fetch C into low byte
	move.l	SCRATCH,BC			; Update BC
	ENDM
	
UPDATE_ADDR_DE MACRO
	move.w	D,SCRATCH			; D into Scratch reg
	lsl.w	#8,SCRATCH			; shift up into high byte
	or.b	E,SCRATCH			; fetch E into low byte
	move.l	SCRATCH,DE			; Update DE
	ENDM

I just want to caveat the above with that it would be a fallback when no optimised translate instructions could be used. For example adding 1 to H would go..

move.w #1,SCRATCH
add.w SCRATCH,HL
add.b SCRATCH,H

As the translated code runs each frame I'd opt for a Copper or VBL interrupt to read the memory mapped IO ports described in the MAME driver, the ISR would effectively do all of the Amiga side screen updates.


The status register could be tricky (would need to store that somewhere possibly in D7?).

One massive improvement a 68020 would have over this is that data regs can be used as address registers, so effectively... it would fly.

Thoughts...? Am i crazy?

[jotd]

the program would need to reside in 0-$8000 addresses right? because of the 16 bit registers and the 32 bit signed?

There's a "nibble" status register too. I'm zoning the Z80 to 68000 converter I dug up.

[mcgeezer]

Originally Posted by jotd

the program would need to reside in 0-$8000 addresses right? because of the 16 bit registers and the 32 bit signed?

No, because the address registers are updated via the scratch register (d7)...

So in the high word of d7 the 64kb segment... i.e. $0003 which would have the rom loaded at $30000.

[hitchhikr]

You forgot undocumented registers accesses like IYL, IYH, IXL and IXH.

[mcgeezer]

Originally Posted by hitchhikr

You forgot undocumented registers accesses like IYL, IYH, IXL and IXH.

They are not in pacman as far as I can see.

[jotd]

is there anything about tiles (maze) and chars (letters/score) somewhere? the info on sprites is very clear in MAME (wow, they went C++!!) but nothing on tiles/charset.

Damn this game could just be done with sprites and a few bobs. I've already converted some sprites to amiga format and displayed a ghost on a amiga 4-planar screen... but the trickiest part remains the code (unless it's rewritten from the very detailed specs given in some links below, but that's not the point)

[SyX]

Sorry, we have people working in home and i have not time for coming here...

Originally Posted by jotd

is there anything about tiles (maze) and chars (letters/score) somewhere? the info on sprites is very clear in MAME (wow, they went C++!!) but nothing on tiles/charset.

What exactly is your problem with the tiles?

You can find the tile format in "src/mame/drivers/pacman.cpp". More exactly this piece of code:

static const gfx_layout tilelayout =
{
    8,8,    /* 8*8 characters */
    RGN_FRAC(1,2),    /* 256 characters */
    2,  /* 2 bits per pixel */
    { 0, 4 },   /* the two bitplanes for 4 pixels are packed into one byte */
    { 8*8+0, 8*8+1, 8*8+2, 8*8+3, 0, 1, 2, 3 }, /* bits are packed in groups of four */
    { 0*8, 1*8, 2*8, 3*8, 4*8, 5*8, 6*8, 7*8 },
    16*8    /* every char takes 16 bytes */
  };
.
.
.

static GFXDECODE_START( gfx_pacman )
    GFXDECODE_ENTRY( "gfx1", 0x0000, tilelayout,   0, 128 )
    GFXDECODE_ENTRY( "gfx1", 0x1000, spritelayout, 0, 128 )
GFXDECODE_END

In short, Pac-man uses 256 tiles of 8x8 pixels in two planes.And the tiles will live in $0000 from the gfx1 memory range and sprites will live in $1000.


Then, later in that file, you can see which roms are used for graphics and where in the memory map are (even if the roms are interleaved or not):

ROM_START( puckman )
    ROM_REGION( 0x10000, "maincpu", 0 )
.
.
.


     ROM_REGION( 0x2000, "gfx1", 0 )
    ROM_LOAD( "pm1_chg1.5e",  0x0000, 0x0800, CRC(2066a0b7) SHA1(6d4ccc27d6be185589e08aa9f18702b679e49a4a) )
    ROM_LOAD( "pm1_chg2.5h",  0x0800, 0x0800, CRC(3591b89d) SHA1(79bb456be6c39c1ccd7d077fbe181523131fb300) )
    ROM_LOAD( "pm1_chg3.5f",  0x1000, 0x0800, CRC(9e39323a) SHA1(be933e691df4dbe7d12123913c3b7b7b585b7a35) )
    ROM_LOAD( "pm1_chg4.5j",  0x1800, 0x0800, CRC(1b1d9096) SHA1(53771c573051db43e7185b1d188533056290a620) )

     ROM_REGION( 0x0120, "proms", 0 )
.
.
.

ROM_END

As you can see for the original japanese version, the tiles are in pm1_chg1.5e and pm1_chg1.5h rom files.

And in the attached picture, you can see the tiles in a graphic ripper. It is not maptapper, because it doesn't support this format, but you can see the tiles and sprites using the mame graphic viewer (F4) and it is not very difficult to rip from there.

With respect to the tilemap, the information is in "src/mame/video/pacman.cpp" (the palette information is there too); but the tilemap is simple, it is fixed in $4000-$43FF in the z80 memory map; and every byte is a tile number, there is not mirroring or another extra feature. The only thing to remember is that the arcade uses a vertical monitor (and graphics and tilemap are encoded in that way).

In my CPC implementation, i used a dirty buffer for only updating the tiles that were changed between frames. And with respect to the graphics, i extracted and my artist partner retouched until get the best result in the CPC 4 colour screen mode. Just in case, you can find this version here.

[SyX]

Originally Posted by Hewitson

Would be better to do Ms. Pac Man. A far better game, in my opinion.

Well, a nice and clean Pac-Man implementation would help to bring other games that run in the same hardware configuration. Aside of a lot of pac-man clones and hacks, there are a few nice games using this hardware with minimal changes (support extra rom or more ram), specially Ms. Pac-Man (like you, i think is a better game) and Pengo (nice pop corn music that it could be remastered for Amiga, hehehe).

Those two games are not possible in the CPC without extra hardware (the memory paging system in the CPC is very limited), but i have a test with Ms. Pac-Man and Pengo working in the Amstrad PCW and MSX systems, although need extra polishing for releasing them.

[oRBIT]

Converting from one CPU platform to another is exciting but be careful. Some instructions that looks similar between processors doesn't affect the condition-status register flags (CCR on the Amiga) the same way. I've investigated 6502 -> 68000 conversion and encountered this problem.
If considering emulation, I can also highly recommend storing the emulated CPU-registers using the Amiga-registers instead (D0,D1...), storing them in RAM would slow down things very much (been there, done that. First few unreleased versions of A/NES did just that).

[malko]

Pac-man related info on Worthy's thread

[Anubis]

I never programmed any emulators/games, specially nothing in ASM, but this thread make me wonder on internet for info and try to understand what is going on and how emulators on different systems are made.

Found very instructional web page emulator 101 - http://emulator101.com/

Using Space Invaders to explain how 8080 processor works and how to emulate it, also how to disassemble code in C++.

Author also posted reference for both 8080 and 6502.

There is also link for step-by-step explanation what 8080 code does and how program works: http://computerarcheology.com/Arcade...ders/Code.html

At the moment I am playing with 6502 disassembler, found here on github: https://github.com/kpmiller/emulator...bler/dis6502.c

This is really interesting, probably will spend some more time learning about this, and how can this be used in amiga. Thank you for thread.

[tcdev]

Did you end up deciding on an approach and did you get anywhere with it?

The first transcode I came across was Arcade Donkey Kong (Z80) to the CoCo3 (6809). That was done 'algorithmically' if not fully automated. Impressive work and it inspired my own project (below). As mentioned elsewhere in this thread, there's Glen's Pacman (he also did Space Invaders and Defender is WIP). Also mentioned was the Pentagram port to Atari 8-bit which used optimisations of the original source to run at full speed.

I ask because I've done a few hand-transcoded projects myself.

Arcade Donkey Kong (Z80) -> 68k ASM (Neo Geo, 50% complete)
Apple II Lode Runner (6502) -> 6809 ASM (CoCo3) & C (Neo Geo)
Arcade Space Invaders (8080) -> 6809 ASM (CoCo3)
Z80 Spectrum Knight Lore (Z80) -> 6809 ASM (CoCo3) & C (Amiga, Neo Geo)
Asteroids (6502) -> 6809 ASM (CoCo3) & C (WIP)

I've also done a few patches/ports of original code (same CPU) to different systems:
Arcade Space Invaders -> TRS-80 Model 4
Arcade Tutankham -> CoCo3
MSX Lode Runner -> TRS-80 Model 4
Arcade Asteroids -> Apple IIGS

I've got a few more projects in mind, targetting the 68K, primarily Z80.

I was thinking this time, get an emulator running on the 68K, even if woefully slow, just to see things running. Not sure if that'll help the process ultimately, but it's another step along the way.

[jotd]

well, I decided to port another arcade game to amiga instead, Bagman

I had written the game in C++ for SDL. I ported it to native amiga.

So no, nothing at the moment. But your work looks very interesting.

[jotd]

okay, back to Pacman after all.

We'll see the AI later on.

Decided to go 100% asm. 4 planes.

1 plane for maze
1 plane for pacman using blitter (1 plane)
1 plane for dots
1 other plane (to be able to blit bonuses with proper colors)
sprites for ghosts (4 different color palettes preventing to use a sprite for pacman)

hoping to avoid double buffering and getting 50Hz with only 1 blit on 1 plane. That should be doable.

I'm not too concerned about the AI ATM.