Zilog z80 to Motorola 6809 Transcode – Part 015 – Sprites on the Demo Maze

Not much to report, just adding more routines… I got as far in the attract mode as the first scene finished (where Pac man eats the power pill and the Dark Blue ghosts) then the maze is drawn and Pac man goes to the left, but Pac Man and the ghosts go through some of the walls…  I think the PaletteRAM is where the game checks for walls and they aren’t being setup properly  or detected properly.  But at least there is some progress to see on the screen…

screen-shot-2017-02-05-at-2-54-27-pm

See you in the next post…

Advertisements
This entry was posted in CoCo Programming, Uncategorized. Bookmark the permalink.

5 Responses to Zilog z80 to Motorola 6809 Transcode – Part 015 – Sprites on the Demo Maze

  1. I could very well be wrong here, but I doubt that the palette RAM is involved in the game logic. On a lot of arcade machines, for example, palette RAM is write-only. The only realistic case I could think of is hardware that employs sprite collision-detection, which Pacman doesn’t.

    I’m all-but-certain that the ‘logical’ playfield is represented in work RAM distinct from any video memory.

    But again, I could very well be wrong.

  2. Looking very pretty though! :O

  3. nowhereman999 says:

    Hi Mark, I still haven’t looked into this yet, found some other weird bugs to work on. You’re probably right but I did notice some code the writes some special bytes into the palette RAM in front of the tunnels and a few other places in the game that the ghosts never enter on their own…

    • I went back and reminded myself about the Pacman hardware architecture, and see that you’re probably talking about the attribute RAM, rather than what is normally referred to as palette RAM. The attribute RAM – which is indeed R/W on Pacman – sets the palette entry (via the colour lookup table – AKA CLUT) for each tile. Palette RAM, OTOH, is special RAM that allows the CPU to actually set a palette entry’s RGB values directly. Pacman doesn’t have palette RAM, but Defender for example, does.

      So you could be quite right in this instance; it could be using the attribute memory to denote a forbidden area for the ghosts.

      • nowhereman999 says:

        Hi Mark, thanks for digging into this a little more. I guess I did have the wrong name for the attribute RAM.

        I’m getting closer to fixing my ghosts chasing problem. It turns out I was doing a 16 bit add which included a carry from the first byte into the second byte when it was moving the ghosts X & Y coordinates. But what the code really needs was to keep the bytes separate (no carry) which of course makes sense, since X & Y should not effect each other. Things are looking a little better now… I think the bugs are in the position prediction code. That’s where I’ll be digging into next. Cheers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s