There's a WHDLoad version in Retroplay's collection on the EAB file server...

/Retroplay WHDLoad Packs/Commodore_Amiga_-_WHDLoad_-_Games_-_Beta_&_Unreleased/M/MsPacMan_v1.0.lha

Found them, thank you very much. I was looking in WHDLoad_-_Games instead.

itch.io contains the .adf with the latest executable and the .slave. I do not distribute the whdload version as lha, that's true

JOTD: Excellent work on the port.

How much of the A500 does it use 80-90% ??

How many raster lines for frame update?

I haven't measured it but I have tested it on my real A500, I had to find an external drive (that I had in store and which worked perfectly) to write a floppy for it on my A1200 (which has CF IDE but the internal floppy drive was dead) so my A500 could boot the game (the A500 drive still works perfectly, after I replaced it by a newer A1200 board drive 25 years ago).

But it uses sprites for ghosts, and is pretty much optimized in assembly, with lookup tables for multiplications & squaring.

I don't even need double buffering (which is somehow painful to do anyway)

Besides, the blitter objects aren't blitted in all planes when possible, using well-thought palette ordering. For instance MsPacman has only 4 colors, and doesn't intersect with the maze ever, so it's blitted on 2 bitplanes only and doesn't use cookie cut blitting

Only moving fruit uses all 4 planes blit and cookie cut to avoid destroying the maze.

I can only imagine how hard it must be to create a 32 color game with blits everywhere, and that is fast enough on a A500...

Thanks for the explanation, and yeah Disks and floppy drives are becoming quite rare and troublesome. :crying

Wasn't that when the coders stopped checking for wait blits?

yes, some games know the blit is finished... And saves cycles not checking it. But it's stupid.

Better check for blits BEFORE the next blit operation, and before that (while the blitter is working) prepare all data so writing to blitter registers is very fast