Glenn Saunders wrote:
>>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 ;)
You should get two cycles there :)
But, as the code is getting clearer in my mind, I think you may not have
to save/restore X at all. That will give you 4 more cycles :)
> 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:
I don't know what that NOP is useful for, hopefully we can utilize the
cycles for something useful or merge them with other free time.
But don't forget, that in kernels where the missiles *don't* start at
the same % 2 line, you will need 2 HMOVEs and 2 HMCLRs.
> 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.
You should move the TombstoneIndexer routine at the end of the loop.
That way you save the extra JMP TombstoneScanline (3 cycles).
The setup will look like this:
sta WSYNC
... ; waste the correct number of cycles
jmp .enter
.contBlock:
...
.enter: ; somewhere around here
...
.nextBlock:
;main kernel code
;TombstoneIndexer routine:
...
DEX
BNE .mextBlock
> Best case 38 cycles for the players and 52 for both missiles yields 90
> cycles, which means we have 1 cycle left to spare!!!
With the changes above you get some 100% more :-)
> 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)
You will need 20 cycles when you need SEC. If you can avoid this, you
have the 18 cycles I was talking about, and yes, the illegal opcode
version takes 18 cycles too (and doesn't depend on the carry state).
I posted an "illegal" version with illegal opcode support some months
ago (07/2000 or 02/2001?).
> 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.
That problem can be solved with enabling/disabling VDEL quite easy. The
bigger problem are the missiles. You will have to start their code at
the end of the previous line, so that you are ready before the are
displayed on the playfield line (which is fortunately about the same
time you have to start the write to the playfield registers :).
In the end, the code in kernels where both missiles start on the same
line, will look something like:
|mmmmfffffffgggg|ggggglllmmmm| or |ggggfffffffmmmm|mmmmmlllgggg|
(g=graphics, m=missiles, f=playfield, l=looping, |=cycle 76/0)
> BTW, I do encourage people to use the VCS.H I put up there. It's a
> combination of Ekhard's and Nick's.
I think, it's better to leave VCS.h untouched and create an additional
header-file where you are doing the defines. That file could also use
"include vcs.h" to include the original VCS.h. This will avoid some
confusion.
Have fun!
Thomas
_______________________________________________________
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at web dot de |
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
