Ms Pacman

[Old_Bob]

What about speed? An A500 surely couldn't emulate a Z80, or 6502, or anything else at the speed required, on top of doing all the other stuff the game might need. If it could, you might as well create a MAME build for it and be done with it.

Looking at that extensivley commented Ms Pacman disassembly, would it not require far less man hours to simply translate the source, routine by routine, in to 68000 asm as was needed?

B

[S0ulA55a551n]

Originally Posted by Old_Bob

What about speed? An A500 surely couldn't emulate a Z80, or 6502, or anything else at the speed required, on top of doing all the other stuff the game might need. If it could, you might as well create a MAME build for it and be done with it.

Looking at that extensivley commented Ms Pacman disassembly, would it not require far less man hours to simply translate the source, routine by routine, in to 68000 asm as was needed?

B

Must be able to, thought there was spectrum and amstrad cpc emulators for the miggy ?

[jotd]

Emulating is not an option speed wise. Most logical would be to rewrite or transpose functional code, like ghost AI, using original code as base, and write gfx & audio from scratch.

[Old_Bob]

Originally Posted by S0ulA55a551n

Must be able to, thought there was spectrum and amstrad cpc emulators for the miggy ?

I've no knowledge of the CPC emulator, but the Speccy one I used to use, in times of yore, needed a reasonably fast '020/030 and some Fast RAM to approach playable levels of performance. It certainly worked great on my Blizzard MKIV. On an A500 with a 7mhz 68000 and Chip RAM only, it would be simply unusable and I can't see the CPC one being miraculously faster.

B

[roondar]

I seem to recall there being detailed analyses of the Pacman ghost behavior online. This might help avoiding the need to disassemble and recreate all the code - it's the behavior that matters, not the implementation.

Then again, using the original code will certainly lead to the most accurate result.

[jotd]

Nowadays doing an nth clone without the original behaviour is not good enough.working from disassembly would create a game even better than official ports because japanese almost never share the code for home versions

[S0ulA55a551n]

Originally Posted by Old_Bob

I've no knowledge of the CPC emulator, but the Speccy one I used to use, in times of yore, needed a reasonably fast '020/030 and some Fast RAM to approach playable levels of performance. It certainly worked great on my Blizzard MKIV. On an A500 with a 7mhz 68000 and Chip RAM only, it would be simply unusable and I can't see the CPC one being miraculously faster.

B

Fair enough. Had no first had knowledge or had tired it.


Sent from my iPhone using Tapatalk

[NorthWay]

The conversion to C should do real well as it can optimize away dead instructions. I worked on a port of X-Former that morphed into a C= 64 emulator, but seeing all those signals and stuff you _had_ to do for every opcode would fast make you SadPanda when you knew how much of that was never used and just thrown away/overwritten.
Compilers are great stuff for doing mindless and complex tasks...

[idrougge]

Originally Posted by jotd

I really wonder how hard it would be to drop SDL for hardware banging but keep C++ code with all the A.I. etc, and how fast it would be. Not a job for me as I don't know enough about blitter & sprites & audio on the miggy.

Why not go half the way and keep it in C and use OS functions?

[Pyromania]

Did any type of Ms. Pacman ever come out for Amiga. It looks like source is available.

[Pyromania]

Any updates on a Ms Pac-Man for Amiga?

[DanScott]

Originally Posted by Pyromania

Any updates on a Ms Pac-Man for Amiga?

Source is available.. go make one

[jotd]

source for Atari 7600 version, but from the arcade?

[Pyromania]

Originally Posted by DanScott

Source is available.. go make one

I would love to if only I knew ASM. Can you point me to some good beginner tutorials?

[jotd]

you need source asm tutorial and target asm tutorial or write it in C (which would be more reasonable) using Bartman C VSCode plugin.

The hardest part (for having done that for the game "Bagman") is to isolate the "functional" parts from the lowlevel parts (controls, graphics, sound). Of course with comments from source and not just a binary dump it's easier.

I'm contemplating doing a project with Bartman VSCode environment. That could be it.

[VladR]

Originally Posted by oRBIT

Code a Z80-emulator, that will take care of the logic. Rewrite graphics-related parts to be more Amiga-specific.
Probably easier said that coded.

There's no need to code an emulator. You just need to write a simple Z80 -> 68000 translator.

Since 68000 has more registers, it should be quite easy - probably a weekend worth of work, assuming you are verbose with both assemblers.

About a year ago I wrote a Z80 backend for my Higgs compiler, so I got familiar with the instruction set [somewhat]. Z80 is really nice !

This would take care of the logic and behavior being identical, leaving system-specific audio/video/input/os features to be coded from scratch.

Still a lot of work

[VladR]

Originally Posted by S0ulA55a551n

Must be able to, thought there was spectrum and amstrad cpc emulators for the miggy ?

Oh, you'd be surprised how fast 1.79 MHz 6502 can be in 8-bit ops compared to 7 MHz 68000. It has plenty ops that execute in 3-4 cycles (zero-page addressing).

Sure, 68000 can do 16/32-bit signed math in single instruction (unlike pages of 6502 code to achieve same result) and some amazing array indexing.

But you don't need a whole lot [perhaps any] 16-bit ops (or advanced indexing for that matter) for this game.


Now go check how many cycles common ops that access memory take on 68000 and you will see what I mean that the 7 MHz 68000 is not necessarily ~4x faster in raw power compared to 1.79 MHz 6502.

And, on 68000, you need to move more pixels around (2x - 4x), as games don't run in 160x200, do they ?

[pink^abyss]

Originally Posted by jotd

you need source asm tutorial and target asm tutorial or write it in C (which would be more reasonable) using Bartman C VSCode plugin.

The hardest part (for having done that for the game "Bagman") is to isolate the "functional" parts from the lowlevel parts (controls, graphics, sound). Of course with comments from source and not just a binary dump it's easier.

I'm contemplating doing a project with Bartman VSCode environment. That could be it.

Perfect for a first time project in a new environment! Looking forward to it.

[Pyromania]

So an AGA Amiga, 68060 Amiga or Vampire Amiga should be able to handle Ms Pac-Man just fine right?

[VladR]

Originally Posted by Pyromania

So an AGA Amiga, 68060 Amiga or Vampire Amiga should be able to handle Ms Pac-Man just fine right?

68060/Vampire will just give you an option to code it comfortably in high-level language, like C. Probably even using something like SDL or some other gfx layer.

Of course, originally, the game ran on plenty systems clocked around 1.79 MHz, but that's some hardcore assembler coding that you probably don't have time/patience for.

If you had a working base project, in C and SDL, you could probably reimplement core AI behavior over a weekend, assuming you already studied the commented ASM source extensively.

Some long time ago, I studied PacMan AI behavior from ASM code and I sure as hell would not want to reimplement that in ASM from scratch

But if you are determined, why not ?