Any optimization tips?

[jbs30000]

I wrote a program that only displays a single color sprite on an asymmetrical, multicolor playfield (the background is a single color). It doesn't do anything else, but that's fine because that's all I want it to do.

 

I'm just curious if anybody has any tips or advice for writing the code to look a little neater, or have any optimizations that could squeeze out an extra cycle or two in the scanline code. Or if there's anything I could, or should do differently.

 

If any of you decide to look over the code, then here a few notes first:

 

It's a 1SLK. I came up with a sprite display routine that only uses 14 cycles instead of 18. The drawback is the Y register is devoted solely to the sprite. It can't be used for anything else (unless some cycles can be freed up. Each scanline is 75 cycles).

 

In order to get the timing right the left side PF0 and PF1 are set before the first scanline, and then within the scanline they're set at the end to be displayed on the next scanline.

 

I know some of you don't like too many comments, so I'm letting you know that I commented the hell out of my routine.

 

Anyway, if you choose to look at it, thank you.

 

Program.zip

[Thomas Jentzsch]

At first glance I can see two possible optimizations:

1. remove WSYNC (3 cycles), this requires perfect cycle counting and data alignment
2. move DEX to the end of the loop and branch to DrawLoop (2 cycles)

Also have a look at SkipDraw. It might not help in the current case, but it frees one index register for other use.

[jbs30000]

At first glance I can see two possible optimizations:

1. remove WSYNC (3 cycles), this requires perfect cycle counting and data alignment
2. move DEX to the end of the loop and branch to DrawLoop (2 cycles)

Also have a look at SkipDraw. It might not help in the current case, but it frees one index register for other use.

1 - Good point, but I'm not quite sure how I would use the 4 cycles at the end of the scanline. Although I guess it would be good to play around until I found something that worked.

2 - I need DEX where it is because if X isn't 0 then I need to fill PF0 & PF1 for the next scanline.

And I am using a form of SkipDraw. If I go the traditional rout which uses 18 cycles I'll have to do with STA COLUPF what I did with the left side PF0 & PF1. Which wouldn't be too bad actually.

[Thomas Jentzsch]

1 - What do you need those cycles for?

2 - If X is zero, you can still overwrite PF0 and PF1 after the WSYNC. And since you enable VBLANK anyway, you have all the time of the world to clear PF0 and PF1. Also you could move the PF0/1 writes to the beginning of the loop (before WSYNC).

[Mr SQL]

Getting cycle exact is difficult but it's nice to get the WYSNC cycles back, they add up. An easier variation on that is you could change to a 2LK to free every other WYSNC without having to be cycle exact; I will take a look at the code and see what else comes to mind.

 

btw could you patch your awesome Qbert port to run on the Portable? Nukey and I were just discussing it; we discovered that the superchip RAM just needs to be initialized to FF to make the game compatible, think you are setting it to 0.

[jbs30000]

1 - What do you need those cycles for?

2 - If X is zero, you can still overwrite PF0 and PF1 after the WSYNC. And since you enable VBLANK anyway, you have all the time of the world to clear PF0 and PF1. Also you could move the PF0/1 writes to the beginning of the loop (before WSYNC).

1 - Why, to cram more code in, of course.

2 - I see what you're saying. I'll give it a try. Thanks.

[jbs30000]

Getting cycle exact is difficult but it's nice to get the WYSNC cycles back, they add up. An easier variation on that is you could change to a 2LK to free every other WYSNC without having to be cycle exact; I will take a look at the code and see what else comes to mind.

 

btw could you patch your awesome Qbert port to run on the Portable? Nukey and I were just discussing it; we discovered that the superchip RAM just needs to be initialized to FF to make the game compatible, think you are setting it to 0.

I'll be honest. I haven't touched bB in about 9 years. The QBert.bas code is here,

http://atariage.com/forums/topic/124726-qbert-game-completed-formerly-titled-ok-i-lied-one-more-update/?do=findComment&comment=1511150

You can check it out for yourself. I opened it up and had a look, but I'm not sure what I would need to change.

 

Edit: Looks like it might be the code I had before I added pushing the fire button to start the game. Unfortunately I don't think I have the later code on my computer any more.

Edited June 3, 2017 by jbs30000

[jbs30000]

2 - If X is zero, you can still overwrite PF0 and PF1 after the WSYNC. And since you enable VBLANK anyway, you have all the time of the world to clear PF0 and PF1. Also you could move the PF0/1 writes to the beginning of the loop (before WSYNC).

OK, instead of BEQ overscan I changed it to BNE DrawLoop. Getting rid of the JMP gained 3 extra cycles for a total of 4 free cycles total. And getting rid of the STA WSYNC will get rid of 3 more for a grand total of 7. I could make the sprite multi-colored, but it's for the best if I make my personalized SkipDraw, actually it's a DoDraw, into a standard DoDraw.

 

Anyway, it's 3:07am so done for a while.