Re: [stella] perfect timing

Subject: Re: [stella] perfect timing
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Sun, 11 Nov 2001 11:32:50 -0800
At 11:14 AM 11/11/2001 +0100, you wrote:
should work, if you simply swap DEY, TYA. That way, A get's the previous
Y value, which in result will delay your row-blocks by one line.

Okay, that fixed it after some fiddling.

90 cycles sound's a bit to low for me. How are the other 62 used? (PF +
HMOVE + loop = max. 55)

After changing the STX Temp/LDX Temp to TXS/TSX (which sacrifices more ROM in the process by having to save/restore the stack) I get one extra cycle. So we've got 91 ;)

In order to issue an HMOVE at the beginning, I needed to throw a single NOP in after the STA HMOVE. If I can get away with doing an HMOVE a little late, then we can have 93 free cycles with the first 2 cycles of the playfield scanline being the last operation of the sprite scanline... Assuming that isn't done, though, here is the breakdown:

HMOVE = 5 (with the NOP)
TombstoneIndexer routine = 15 (includes end-of screen logic and X restore from stack)
LoadTombstones = 30 (includes saving X to stack)
BlankTombstones = 9 (includes a .W to keep the cyclecount even, which can
ultimately be removed when more code is added)
JMP TombstoneScanline = 2

TOTAL USED = 61 out of 152 avaialble

yields 91 left in two chunks.

28 available after the playfield writes, and 63 after tombstones are blanked.

With 26 cycles (which is my count), you'd gain 8 more cycles here, the
optimal player drawing routine need 18 cycles, so 38 cycles are enough.

Both player writes can't be squeezed into the playfield scanline as the code is currently aligned.

Best case 38 cycles for the players and 52 for both missiles yields 90 cycles, which means we have 1 cycle left to spare!!! BTW, the current VDEL-style sprite code I have is 20 cycles long. So I'm assuming you are referring to the illegal opcode variation of that? I haven't used that yet because I'm not too sure how to do it in .BYTE syntax. (I'm still waiting for a DASM binary, official or otherwise, with illegal opcode support)

That isn't taking into account avoidance of the tearing effect or how to achieve single-scanline precision with at least the cars...

It looks like I can't just group all the car sprite stuff on one scanline because VDEL only drops down one sprite or the other, but not both.

It will be pretty tricky to get both cars to start on the playfield lines without tearing.

I guess the next step is to tackle that problem and wait on the missiles until later.

Since I think I've posted a bit too much sourcecode to the list in a short span of time, I will post URLs for now in case anyone wants to look at it:

I'll wait until more of a major milestone to post code again.

BTW, I do encourage people to use the VCS.H I put up there. It's a combination of Ekhard's and Nick's.

Glenn Saunders - Producer - Cyberpunks Entertainment Personal homepage: Cyberpunks Entertainment:

Archives (includes files) at
Unsub & more at

Current Thread