Zilog z80 to Motorola 6809 Transcode – Part 012 – Pacman is in the building and handling the z80 RLCA instruction

I’ve started implementing sprites and I’ve got the red ghost animating and Pac man moon walking a little across the screen.  You can’t see it from the picture below but you can see that I finally have Pac Man on screen!!!

screen-shot-2017-01-23-at-8-21-05-pm

Pac Man is a little lower then the Red Ghost which I’ll have to figure out.  I’m still missing tons of code to transcode but I think once I can get this little animated scene working then a lot of the game will actually be complete.

I’m running out of memory again!  The big scrolling screen really does take a lot of RAM away from the 64k available memory the CoCo3 can use at one time.  I thought I’d be able to keep the sprites in main memory at all times but that is not going to be an option.  The sprites take 8k of space that I can’t spare anymore.  I don’t know if I’m going to have room for adding audio!  Which is one thing I wanted to do since I haven’t worked on sound in assembly on the CoCo before and that would be a great thing to learn.  We’ll see…

 

Edit – (better way to do this is described at the bottom below this section) – Another bit on transcoding (pardon the pun)…  The z80 RLCA and RRCA are 7 bit rotate instructions that rotate the accumulator or memory location.  If you rotate left then bit 7 goes to bit 0 and if you rotate right then bit 0 goes to bit 7.  The 6809 doesn’t have this function so to get around this I use the following code:

        ANDCC   #$FE
        BITA    #$80
        BEQ     >
        ORCC    #$01   * Set Carry Bit
!       ROLA                           ;0231 07          RLCA

First it clears the C – Carry flag, then checks to see if bit 7 is clear, if it is then it does a normal ROL, but if bit 7 is set then it sets the C – Carry flag which will be copied into bit 0.

I figured out a faster way to do the 7 bit shift using the LSL and BCC instructions as shown below:

        LSLA
        BCC     >
        ORA     #$01                   ;0231 07          RLCA
!

Johann Klasek commented below with a way to save another byte in the code above by using INCA instead of ORA  #$01.  as per the code below,  Thanks Johann   🙂

        LSLA
        BCC     >
        INCA                           ;0231 07          RLCA
!

and for RRCA: 

        LSRA
        BCC     >
        ORA     #$80                   ;0307 0F          RRCA
!

See you in the next post…

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

12 Responses to Zilog z80 to Motorola 6809 Transcode – Part 012 – Pacman is in the building and handling the z80 RLCA instruction

  1. A couple of notes:

    * There are known bugs (features) in the Pacman hardware sprites to do with pixel position. See the MAME Pacman driver for details.
    * If you load both accumulators with the same value, then
    LSLA, ROLB == RLCA.

    • nowhereman999 says:

      Thanks for the info Mark, that sounds really weird… I’ll have to look through the code and see if I can find any of these weird “features” in action. I do a lot of debugging using the MAME debug feature. So I should be able to find out when part of my transcode is broken. Definitely good to keep in mind though.

      Cheers,
      Glen

  2. Also, sprite priority depends on the hardware sprite number. For example, when running away from ghosts, they have a higher priority. But when chasing them, the code switches around the sprite associated with the player, so that it has higher priority!

    As for memory limitations; don’t forget you don’t need the entire screen mapped into 6809 address space at any one time. Because you’re (generally) only updating a handful of sprites spread around the screen, you could just switch in the 8K bank of screen memory that you’re addressing for each update?!? It gets messy on boundaries… but then you could just use 2 banks and still save 16KB in your address map?!?

    • nowhereman999 says:

      I just found the code today that picks the sprite priority based on the Power pill being eaten. I’m having a hard time getting my sprite engine to not flicker on screen. I might have to settle with less flicker but the possibility of some junk being left behind when the ghosts cross paths. I’m actually fighting with that stuff right now.

      Are you saying the video RAM $9000 bytes of space doesn’t have to be in the 64k of useable space in order to be viewed? Wow! That makes sense, it is just memory that the GIME is using to draw the screen data! Thanks so much for that insight!!! It will be a little tricky as the ghosts move around the $2000 byte blocks but it should be ok. I think that means I can try double buffering with two super large $9000 byte screens. This also means I can probably also have sound which I was thinking I’d run out of space for. That is another thing I want to learn… You’ve just given me so much more work, I mean fun 🙂

      • Yeah overlapping sprites can be… ‘fun’ to implement in software! Do you keep a copy of screen memory being overwritten by a sprite? There’s a couple of approaches; one is to wipe all sprites before displaying them (in any order), another is to wipe & draw each one in turn but then you have to be mindful of the order in which you do them so the wipe doesn’t leave junk. I’m wondering if there’s time on the VBLANK to do all your sprite updates at once, to eliminate flicker without any double-buffering?

  3. nowhereman999 says:

    Hi Mark, I’m trying all kinds of approaches including the methods you described above, I don’t think I have enough time before the VBLANK so I will probably have to use double buffering to make it not flicker. 😦 I’m actually getting a little sick of writing sprite code, I might get it close with some flickering and move on to more transcoding to give myself a break from it. Since you opened my mind to the possibility of using more RAM maybe I can try having a second copy of the background screen to copy from, that should speed up the restore and lessen the flickering. I sure do wish the CoCo3 had hardware sprites 🙂
    I have the little attract scene playing now (with flickering) and Pac Man is now level with the ghosts, it was a bug in my sprite code. It gets as far as Pac Man eating the 4 ghosts and showing the score while eating them. But the ghosts are moving erratically, before and after Pac man eats the Power Pill. Lot’s more coding fun to do…

    • Good strategy – get things showing and worry about optimisation later! You’ve had great progress in such little time, looking forward to seeing the results!

      • nowhereman999 says:

        Thanks Mark, it’s nice to here from another CoCo nut. Progress has been going quite well so far. Only a few big gotchas so far, of course one was related to the IRQ and page flipping while doing some character writing. You think from the space invaders IRQ trouble I would have learned… 🙂 You know how it goes, three steps forward and two steps back… I’ve made some nice progress tonight optimizing my Sprite backup and restore code utilizing the S and U Stacks even more. Currently it is super fast at backing up and a little faster at restoring the background. I think I can do some more tweaking and improve the restore time and take a little hit on the backup time. The restore time I think is the most important to be fastest. But all sprite routines are important…


  4. LSLA
    BCC >
    ORA #$01 ;0231 07 RLCA
    !

    Not faster, but saves one byte:

    LSLA
    BCC >
    INCA ;0231 07 RLCA
    !

    Alas, because the CMP changes the carry flag not in that way a 6502 does, this would be elegant, but won’t work:

    CMPA #$80
    ROLA

    6809 clears the carry flag on greater or equal (but works well on a 6502). 😉

    • nowhereman999 says:

      Hi Johann,

      Thanks for the tips, good idea to use INCA. I like tighter code if I can use it. 🙂

      Cheers,
      Glen

      • Found a workaround for the CMPA #$80 variant, which works for a 6809:

        SUBA #$80
        SUBA #$80
        ROLA

        It’s neutral to the contents of A but turns around the carry (copy bit 7 into carry).
        It takes 6 cycles compared to 5/7 of the LSLA-BCC-INCA version, with the advantage of constant runtime if needed. But it takes one byte more for the code.

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