Jump to content

Koffi Redux project, recoding dlists and fixing a bug


Cafeman

309 views

[EDITED again - added a Before and After pic below] 

 

Back in 2020, I started to tinker with my old 2002 game,  the 32K Atari 5200 homebrew Koffi: Yellow Kopter.    I'm calling it Koffi Redux so far.   I fixed bugs, tweaked gameplay rules,  rewrote various graphics routines to make more efficient, added some colors and graphics, and added 2-player mode.  One nasty bug was in the original on stage Windy Vines - it took AA member @RB5200 to find it and report some clues to me.  The bug mysteriously kills poor Koffi for no reason down near the vine.    I fixed the bug which had a side-effect of simplifying some code there, too. 

 

Even though I reclaimed nearly 1K of ROM by my recoding stuff,  I was again running low. I was down to under 400 bytes of ROM left.   Originally I figured when I ran out of ROM, I'd call it done and release the current version to play.  But there are too many things I want to tweak, and I kept noticing other tables and routines which could take up a much smaller ROM footprint - one of these areas was each screen's Display List.  The screens are primarily high-resolution Antic E mode lines, and each display list was 195 bytes. 

 

In Koffi, there are 4 gameplay screens, a title screen, and LoadLevel (between stages) screen.  MV Mountain Valley and CF Coniferous Forest screens used the same 195-byte display list, but the other screens all had their own unique 195-byte Display List Tables.   This week I implemented the method I used in 5200 Adventure II (which had about 90 different Antic 4 screens),  each of the 4 gameplay screens now uses a common display list table,  which uses well under 100 bytes to produce the 195 byte Display List.   At this point I have 952 free ROM bytes, so I saved over 550 bytes recoding all this. 

 

However, I'll use some of that on the next step - to dynamically set the unique Display List Interrupts into that 195-byte RAM table, a unique footprint for each of the 4 gameplay screens.   This method surgically inserts the value $8E overtop an existing $0E byte, one for each place a DLI should exist as you draw down the screen.    By using my AdvII table idea called DLIMarkerScr and DLIMarkerRow tables, I won't use too many ROM bytes implementing custom DLI's for the 4 gameplay screens. 

 

Diagram 1:    Sample Code which builds the common DLIST from $1000 to $10C2 in RAM.   The actual screen RAM is mapped starting at $2000.   One thing of note is that this Display List requires an extra LMS jump instruction (3 bytes) before you cross screen RAM of $2xxx to $3xxx - yes, a full Antic E screen needs more than 1 page of RAM memory. 

 

; **************************************************************************************************************
BuildCommonDLIST
dlist1Part1
	ldx #$08		; store 9 bytes from dlist1  table from $1000-$1008:
;*** load initial 9 bytes: 
dlloop2A                                                                      
       lda     dlist1,x                                                       
       sta     $1000,x                                                       
       dex        		;next byte
       cpx #$ff		 
       bne dlloop2A
;*** load 186 bytes, all are "0E" values for Antic E mode lines, from $1009 to $10BF.   
dlist1Part2			
	ldx #$09
	lda #$0E		;Antic E mode lines
dloop2B
	sta $1000,x
	inx
	cpx #$C0		;end of display list at $10BF in RAM. 
	bne dloop2B
;*** load MID LMS 3 bytes: 	
dlist1part3
	lda #$4E
	sta $1064
	lda #$00
	sta $1065
	lda #$30
	sta $1066
;*** load end jmp 3 bytes:
	lda #$41
	sta $10C0
	lda #$00
	sta $10C1
	lda #$10
	sta $10C2
;*******************************************  end new dlist1 code
	rts
;***************************************************************************************************************

 

Diagram2:  shows what the built DLIST looks like with some notes: 

 

702565402_KoffiReduxdlist1memorymapsmall.thumb.png.a0afd54e58a329417ebdc7f026f4c9e5.png

 

 

Diagram3:   shows what stage 1 MV looks like with no display list interrupts turned on yet, and AFTER the DLI's are active.  Next I have to add the appropriate DLI rows for CF, WV, and PM stages. At this point I have over 900 bytes left, so it was worth the recoding effort. 

 

 

1193120186_KoffiRedux-recodedlist1beforeandafter.thumb.png.7e23ad94075d2cb1cc9ede865eeb7ad0.png

Edited by Cafeman
added a before and after pic

2 Comments


Recommended Comments

I never ran across that bug myself that I can recall? Interesting! But I am also curious of course to know what additional changes you might in store for the Koffi redux? And while I haven't really the tools or time to design any sprites I'm happy to test anything you want where I can record and document anything I find and ideas. 

 

Another thing is that with Koffi being a unique IP that belongs to you, I think a redux release on cartridge would be nice and include some of your grid paper designs in the manual or as a separate "Making of" booklet that would be included?

 

 

  • Like 1
Link to comment
1 hour ago, -^CrossBow^- said:

But I am also curious of course to know what additional changes you might in store for the Koffi redux?

 

It depends on what I can fit in 32K, I have more ideas than will fit, that much is for sure.    Part of the fun is seeing what I can accomplish in the same 32K size.  I got rid of the end-credits names for this reason.  So far, I've fixed several bugs from the OG game, and I've needed to rewrite (improve) various routines and tables to even get to implementing the fun changes.    I'm working on the Koloring Book Feature to make it more usable. 

 

My main objective is to create a 2-player simultaneous mode.  It needs some work before I reveal it, it is still buggy and I've been attacking other more fun things.  

 

Also I want to freshen-up the visuals, this is the part I'm working on currently.      There are also gameplay tweaks planned.   Hitting fire/fireball may not always immediately kill Koffi but might consume his water and knock him back.  You won't have to hit Pyro as many times as in the OG, but there may be worse lightning and fireball attacks.     On the title screen, I will probably get rid of the difficulty settings and the ability to choose any stage.    Instead, it will be more coin-op-like - you can start at level 1, 2, or 3 - with bonus points awarded if you choose advanced levels. 

 

Once a few more 1-player mode changes are wrapped up, I'll make a thread in the Homebrew section to release the ROM and ask for folks to try it and provide feedback!  

 

 

   

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...