Ghost Hunt - Pac-Man hardware - FINAL (bugfixes)

[Hurray Banana]

Hi

still working on my Pac-Man demo, but took time out to produce a really simple (and rather naff) shooting game running on Pac-Man hardware.

I made this for my students so we had some real example of a moderately complex assembly language program so we could explore the make up and features of assembly language as well as the features of an assembler that help us when coding.

It's also cool to write programs for old hardware, so that's a bonus.

Because I wrote this to use with my students I fully commented the code. I'm sharing this here as well in case there are any budding arcade homebrew coders just trying to get a foot hold.

Final version of roms and source (update with bug fixes)

The roms are here: https://1drv.ms/u/s!AnPHAdPvv8fFh_4ztgW_Yuk1-A6XRw

The Final Source code is here: https://1drv.ms/u/s!AnPHAdPvv8fFh_42aTtsdIZd2XSpHw

I develop my assembler stuff using Visual Studio 2015 with SJASM and Mame as external tools. I am putting a short guide to setting this up for my students and I'll share this if anyone wants to have a go at assembling themselves.

Here's a short video of the game in action

I'll include the roms generated in a zip file. To use them create a clean Mame folder with mame in it and a rom folder with the pacman.zip file in it.

You will then need to launch mame from the command window (to ignore the crc check errors) using Mame pacman

hope someone finds this useful

Hurray Banana2016-06-18 12:54:10

 

[Pacman83]

Fascinating stuff

Don Hodges of the US is a programme assembler and famous for his work with Pac Man. I have a contact for you if you like?

 

[philmurr]

Great work Eric! Thanks for posting this and also commenting everything in the code.

It's really interesting to see what was available in hardware back then, just shows how far ahead of home computers the hardware was - how things have changed...

 

[cmonkey]

Nice work Eric. I'm really chuffed that I inspired you to start asm coding again with the homebrew stuff that I did

 

[Hurray Banana]

Nice work Eric. I'm really chuffed that I inspired you to start asm coding again with the homebrew stuff that I did

Cheers Ade.

It's funny I really enjoy coding in Assembler again. I'm even starting to get round some of my short term memory problems and don't have to continually look up allowable addressing modes or t-state usage.

 

[Hurray Banana]

I've just remembered I said in the video there was an interesting bug. I forgot about this (I have short term memory problems

). I've just got to do some hardware testing then I'll do a video about it.

 

[Robert]

Excellent stuff !

 

[Hurray Banana]

Don't anyone bother burning this, I have come across a sprite problem on my board, which I'm investigating. Haven't really done much work with sprites so this is not surprising, most of my time has been tricking about with the video ram.

As anyone will tell you, working in Mame does not equate to working on hardware

Not being helped by scrabbling round for roms that will actually allow me to write to them.

I'll report back when I have sorted the issue.

Excellent stuff !

Cheers - not mean't to be anything amazing

 

[cmonkey]

The 72 bytes of data from offset $06e5 in 6f in the attached binaries don't resemble the equivalent data in the source. For starters, according to the source, there should be 96 bytes of data here, not 72 (48 bytes each for spr_initial_tile_data and spr_initial_game_data). Not sure which version of sjasm you're using but I've just assembled the source using sjasmplus v1.07 RC7 and it assembles those 96 bytes correctly. I also altered the source to make is pasmo friendly and assembled with that and it too assembles those 96 bytes correctly.

The end result is that my assembled binary doesn't look and play like the binaries you've attached to this thread (mine has extra sprites in the shape of letters C and D moving right to left across the screen at the menu).

I'm not sure what you've assembled the source with but the attached binaries do not reflect what's in the source.

 

[Hurray Banana]

I did have a serious file overwrite problem where i thought i lost my days work maybe I've cocked something up. Thanks for looking ade I'll follow this up.

 

[Hurray Banana]

Ade I just realised the source wouldn't be the same as the binaries as that source doc is live and I've been making changes to try and investigate why sprite 0 is not being displayed by the pac board.

So it wouldn't assemble to the same as the binaries, not too self - don't link to active build files. I'll take down the links temporarily till I investigate.

I need to tidy my dev environment up a little and see what I've got, then burn 6e and 6f with my test build and see what that does.

cheers

 

[Battlezone]

Nice job so far Mr Banana.

I've been re-working an old 1982 computer (PET) game of mine

for the Scramble hardware. So I'm sure your nicely commented Z80

source will make an interesting read. I'll keep my powder dry for the

moment until I have have a bit more to show but I'm progress on

the game framework, sprites, graphics, sound and input control.

I also picked up a fair amount of Scramble related technical details

in passing that might assist hardware with debug.

 

[Hurray Banana]

Sounds interesting John. Got a scramble board somewhere. So wish I had more time to work on projects

 

[Hurray Banana]

Ok finished sorting out my sprite misunderstandings.

This is now the final version (by me) of this little demo game

here's a video showing it running on my pac board

The roms are here: https://1drv.ms/u/s!AnPHAdPvv8fFh_4ztgW_Yuk1-A6XRw

The Final Source code is here: https://drive.google.com/file/d/0B12mPLloTZFKVlAydWd4aWd6cEU/view?usp=sharing

 

[Hurray Banana]

Just an update on what was wrong with the sprites

There are 8 sets of sprite regsiters

In the Mame driver all of these are rendered on screen, but the hardware only works with 6 of these sprite sets.

The regsiters are at addresses:

$4ff0 to $4fff (1 byte for sprite number an flipping and 1 byte for pallete)

$5060 to $506f (1 byte for x position and 1 byte for y position)

So I assumed addresses $4ff0 to $4ffb and $5060 to $506b where for the first 6 sprites, but I was wrong. It turns out it's the middle 6 pairs that are used $4ff2 - $4ffd and $5062 t0 $506d.

Once I'd figured this out (which involves writing test code, burning roms and trying the code on the pac board) I was able to make adjustments to my equates for sprite registers with out too much impact on the original code i wrote.

Quite pleased with the result overall and the nicest thing is I learnt some new stuff in the process, can't be bad.

Thanks for looking and many thanks to Adrian for getting me back into this shizz

 

[cmonkey]

No need to thank me my friend, just glad you're enjoying asm coding once again. I'm sure if I hadn't started the UKVAC arcade homebrew ball rolling then someone else would have come along eventually and done so.

I'm curious as to why you chose to do tile based collision detection rather than sprite-to-sprite based collision detection. I assume you did the former to make the code simpler to understand for your students?

Well done on getting the sprite issue sorted. It's very satisfying when you resolve an issue on hardware which simply doesn't exist when testing in MAME. I've had a few of those moments in my extensive work on the L System.

Overall I'd say this is a fantastic effort on your part and it's an even further credit to you that you've decided to share your heavily commented source. Hopefully other potential homebrewers can study this and make a game/demo of their own, whether that be on Pac-Man hardware or any other arcade hardware.

Well done Eric

 

[Hurray Banana]

No need to thank me my friend, just glad you're enjoying asm coding once again. I'm sure if I hadn't started the UKVAC arcade homebrew ball rolling then someone else would have come along eventually and done so.

I'm curious as to why you chose to do tile based collision detection rather than sprite-to-sprite based collision detection. I assume you did the former to make the code simpler to understand for your students?

Well done on getting the sprite issue sorted. It's very satisfying when you resolve an issue on hardware which simply doesn't exist when testing in MAME. I've had a few of those moments in my extensive work on the L System.

Overall I'd say this is a fantastic effort on your part and it's an even further credit to you that you've decided to share your heavily commented source. Hopefully other potential homebrewers can study this and make a game/demo of their own, whether that be on Pac-Man hardware or any other arcade hardware.

Well done Eric

Yeah it keeps the collision very simple, rather than doing AABB testing which would of been a little more complex.

I probably won't release the commented source for any super cool demos I do tho - more on that soon I hope

 

[cmonkey]

I figured that was the reason. Maybe you could task your students with converting the collision detection routines to AABB ;-)

My source is generally too messy for me to even consider releasing it :-(

 

[Hurray Banana]

I figured that was the reason. Maybe you could task your students with converting the collision detection routines to AABB ;-)

My source is generally too messy for me to even consider releasing it :-(

You wanna see my game engine, huge swathes of commented out code, with no stuff to let me know why I commented it out

 

[big10p]

Cool stuff! Brought back memories of doing Z80 assembly and BCD on the Speccy.

Do you ever use any of the 'undocumented' op codes? I seem to remember there was one for LD A,A which seems pointless, but actually has the side effect of resetting the zero flag with a single op (byte).