QUIKMAN 2008 for the unexpanded VIC 20

[e5frog]

Reading a few posts back I wanted to try the online version - but it's "404" - guess it was some time ago now.

[rhurst]

Apologizing in advance for necromancing this thread, but I did not think it warranted a new post either... I'll leave it in the hands of its moderators.

I was home sick today, and did not want to do any (real) computer work. So, I've been itching to fix the maze wall "glitch" in the top-center of the Ms. Pac-Man maze #2 run, starting at Peach level.

I had these two reserved graphic characters for "gender", a male and female symbol, I thought I would use in the menu selection, but never did. Well, shuffling such tightly-addressed graphic characters around would mean a lot of work on each maze as well as the game internals... I thought I might never get around to it.

Plus, I moved the "SPEED" table into the RODATA segment, which means the PRG binary is 8-bytes longer because of that, but it freed up one spare VIC graphic character where that data was. So, I used it to make a cool italic exclamation point to enhance its authentic look.

Finally, I addressed the "feature" whereas in some spots on the Ms. Pac-Man mazes, the ghosts would just "slow down", thinking they were in the Pac-Man's tunnel. Alas, I only do a fixed X/Y check for that, really should have used another maze tile for that, but the code almost completely fills an 8k memory expander, so it is what it is and the ghosts will never slow down in any of those other maze tunnels.

Complete code changes can be reviewed here.

The updated 2011 version is online and its splash screen indicates that. Get the program binary or complete archive with source.

[matsondawson]

You can save 4 bytes in SSSWRITE: by doing moving all those RTS's to the end like this...

SSSWRITE:
CPX #$10
BCC @skip ; hidden by left border
CPX SSSCLIPX
BCS @skip ; hidden by right border
CPY #$10
BCC @skip ; above top border
CPY SSSCLIPY
BCS @skip ; below bottom border

PHA ;++
JSR SSSPEEKXY
LDA CRSRCOLOR
AND #$10 ; static cell?
BEQ @ok5
PLA ; yes, don't overwrite it!
RTS
;
@ok5: LDX CRSRCOL
LDY CRSRROW
JSR SSSPLOTS
PLA ;--
JSR SSSPOKE
@skip
RTS

EDIT: same for SSSREAD

[matsondawson]

In SSSIMAGE: there's this...

PLA ;--
CMP #$80 ; is character reversed?
BCC @cont

wouldn't that be the same as:

PLA
BMI @cont (or is it BPL?)

[rhurst]

You can save 4 bytes in SSSWRITE ... and the same for SSSREAD

Yep, brain took a break on the first one and copy-paste was a Power UP! to make it 2X bloated. It's been corrected, thank you!

BMI @cont (or is it BPL?)

It would be BPL if I understand this correctly that PLA also affects the 'N' status bit (<$80 is not negative, >=$80 is negative)?

My Programmer's Reference Guide shows PLA not affecting SR at all, but now I am looking at a scanned 6th edition print, and it clearly shows both 'N' and 'Z' flags are indeed affected. I tested it and it works, interesting!

It can be checked-out until I re-make its ZIP file and re-compile it into the games to take advantage of the 10-byte savings and the CMP #$80 cycles:

Code: Select all

svn co https://robert.hurst-ri.us/svn/vic-sss/trunk vic-sss

[matsondawson]

SSSPEEKXY has the same bit of code that SSSWRITE & SSSREAD had as well... There's a bunch of other places for optimization to do with CLC's and SEC's when C is already set or cleared. But I think I remember you saying you'd rather have readable code

[matsondawson]

There's another 2 bytes to save in SSSPEEKXY (edit: also in SSSREAD, another 2 bytes!)

-- original
@ok4: TYA
SEC
SBC #$10
LSR
LSR
LSR
TAY
;
TXA
SEC
SBC #$10
LSR
LSR
LSR
TAX

-- new
@ok4: TYA
LSR
LSR
LSR
TAY
DEY
DEY
;
TXA
LSR
LSR
LSR
TAX
DEX
DEX

[matsondawson]

I see two spots where it says:
AND #%1
BNE @Cfb2

save 2 bytes by doing:
ROR A
BCS @Cfb2

[matsondawson]

There may be a bug in SSSIMAGE in that ROL will rotate the initial state of the carry into your answer. And the state of the carry seems to be related to the value of the character code passed to it.

@cont: STY YCOPY
ROL
ROL
ROL
ROL
AND #%00000011
ORA YCOPY
TAY ; save image high byte
RTS

[Kananga]

There may be a bug in SSSIMAGE in that ROL will rotate the initial state of the carry into your answer. And the state of the carry seems to be related to the value of the character code passed to it.

The state of the carry is of no relevance, because of the "AND #%00000011" after rotating 4 times, i.e. shifting the initial value of the carry bit to bit 3 (or %0000b000).

No bug here, sorry

[matsondawson]

7 more bytes and few cycles I think here...

SSSINIT:
... this occurs twice
; CLC
; ADC #$02
; ASL
; becomes...
ASL ;
ADC #04 ; + 1 byte (twice!!)

....

SSSCLEAR:

; LDX #$00
@reset: ; LDA #$00
; STA DIRTYLINE,X
; LDA PLAYCOLS
; STA DIRTYLINE2,X
; INX
; CPX PLAYROWS
; BNE @reset

LDX PLAYROWS ; reversed the loop
@reset: DEX ;
LDA #$00 ;
STA DIRTYLINE,X ;
LDA PLAYCOLS ;
STA DIRTYLINE2,X ;
BNE @reset ; + 2 bytes


......


SSSPRINTS:

@ctrl: CMP #$F0
BCC @cont ; color code?
AND #$0F ; filter for 16-colors
STA COLORCODE ; 0=blk,1=wht,2=red,3=cyn,4=mag,5=grn,6=blu,7=yel
; JMP @next
BCS @next ; + 1 byte


......


@vsync: LDA VSYNC
BNE @vsync ; and wait for it to occur

; MATT CHANGED
; BIT VSYNC2 ; No need LDA already set MI + 1 byte
BMI @ok
STA VSYNC2 ; fast flip, gauge again for next frame
;

......

SSSREFRESH:
;LDX #$00
@loop: ;CPX SPRITES
;BCS @fini
;JSR SSSTOUCH
;INX
;BNE @loop

LDX SPRITES ; goes in reverse now
BEQ @fini
DEX
@loop: JSR SSSTOUCH ; + 1 byte + 4 cycles per loop?
DEX
BCC @loop

[Kananga]

7 more bytes and few cycles I think here...

......

SSSREFRESH:
;LDX #$00
@loop: ;CPX SPRITES
;BCS @fini
;JSR SSSTOUCH
;INX
;BNE @loop

LDX SPRITES ; goes in reverse now
BEQ @fini
DEX
@loop: JSR SSSTOUCH ; + 1 byte + 4 cycles per loop?
DEX
BCC @loop

BCC doesnt work here, what you need is BPL, provided there are never more then 129 sprites.

[rhurst]

First, thanks for all the code reviews ... always comforting to know someone has poked around under the hood, looking for ways to improve its software rendering, reduce size and complexity.

... another 2 bytes to save in SSSPEEKXY

Fini!

... also in SSSREAD

Yes, you already caught that and I implemented.

7 more bytes and few cycles I think here... (in SSSINIT)

I don't see how your replacement algorithm could work for computing SSSCLIPX based upon the current state of VIC register for number of columns (defaults to 21 for a 22-column display), i.e., games like Quikman change the screen geometry upfront. Can you detail it all and explain it?

Also, please explain how/why carry state in SSSPRINTS will sustain, even when 0? SSSPRINTS can be excluded (I've done so in some games when it is not used) and the $F0-$FF for changing color codes on the fly is not fixed either -- it depends on what your gaming needs are -- so I left it kind of 'generic' to avoid introducing an unwanted 'feature'.

And further you suggest:

LDX PLAYROWS ; reversed the loop

Yeah, but I can re-use X/Y values (0) from SSSPLOT, because it returns X/Y passed values intact, so I saved 2-bytes by not LDX #$00 and another byte with TYA instead of LDA #$00. Your BNE @reset should use BPL instead to iterate index X when reaching 0.

... may be a bug in SSSIMAGE in that ROL ...

Yeah, no bug there -- and you're the one that replaced its original code with this optimization.

... I remember you saying you'd rather have readable code

For certain I said that, but I recall upon further reflection I had implemented your earlier pass at such SR states to squeeze wherever possible (and internally document your contributions). This is not an application nor a learning tool, but it is suppose to reduce programming complexity to the game programmer. So its internals is going to be complex and its internal efficiency is a must. Anyone who can build a better mouse trap, and not break the current API unless it has benefits too great to ignore, is always welcomed.

LDX SPRITES ; goes in reverse now

Yeah, that ain't happening... I cannot guarantee the sprite internals won't get borked from that nevermind added complexity to the programmer: at the very least, I'd have to rewrite every game that uses this and reverse their sprite ordering to maintain its current color-clash, hit-detection, etc. Ugh!

BCC doesnt work here, what you need is BPL, provided there are never more then 129 sprites.

That's correct! I'm trying to wrap my mind around 129+ software rendered sprites on a VIC 20 . . .

Hope I got all of this. It compiles to 6-bytes less. I will commit to the project's subversion repository for you gurus to check-out. Thanks!

[matsondawson]

For SSSPRINTS:

Code: Select all

@ctrl:
CMP #$F0 
BCC @cont	 ; color code?  <--- Since this didn't branch we know carry is SET
AND #$0F	 ; filter for 16-colors 
STA COLORCODE	; 0=blk,1=wht,2=red,3=cyn,4=mag,5=grn,6=blu,7=yel 
; JMP @next 
BCS @next ;  <--- We can use that knowledge here to save one byte

[Kananga]

Hope I got all of this. It compiles to 6-bytes less.

6 Bytes! Woohoo!

For SSSPRINTS:

Code: Select all

@ctrl:
CMP #$F0 
BCC @cont	 ; color code?  <--- Since this didn't branch we know carry is SET
AND #$0F	 ; filter for 16-colors 
STA COLORCODE	; 0=blk,1=wht,2=red,3=cyn,4=mag,5=grn,6=blu,7=yel 
; JMP @next 
BCS @next ;  <--- We can use that knowledge here to save one byte

Personally, I try to avoid relying on flag values for branches that are set a couple of instructions earlier, because, if you later insert a few instructions in-between due to new needs, you may forget that they shouldnt change the flag.
So, unless it is e.g. BCS following directly after BCC, I prefer the JMP.