Going from 4k -> 8k breaks my game :( [SOLVED]

[+Gemintronic]

So, I've got a game I must expand to make room for a title screen and music. Trouble is, the INSTANT I try expanding it from 4k to 8k it locks at the level display screen.

 

I'm using 3 assembly libraries: div_mul.asm, pfhscroll.asm and 6lives.asm

 

I suspect those to be culprits but I don't know what I'm doing wrong. In order to reproduce the problem please change the line:

 

set romsize 4k

 

to

 

set romsize 8k

 

Thanks in advance to anyone that can provide some input. This is terribly frustrating!

lbnfa020.bas

[+Gemintronic]

An update: I found this topic entry

http://atariage.com/forums/topic/214241-inline-6livesasm-help-banks-multisprite-solved/?do=findComment&comment=2789205

 

I changed the end of my game to this:

 inline pfhscroll.asm

 bank 2

 inline 6lives.asm

..and now the lives display works albeit without proper colors. This sounds a little more fixable, though!

[+Gemintronic]

Solved! 6lives.asm changes behavior if you go multi-bank. First off, it seems to need to be in the last bank. Second, lifecolor no longer gets retained. Before every drawscreen you must refresh the value of lifecolor.

 

 lifecolor = $5E
 drawscreen

[RetroFiends]

Can life color be changed in single bank 4k games too, or is this just a weird thing with multibank games? If it can, it's just that much more color we can display
Now if only I could change the PF0 side colors to something else in the multisprite kernel...

[+Gemintronic]

Can life color be changed in single bank 4k games too, or is this just a weird thing with multibank games? If it can, it's just that much more color we can display

Now if only I could change the PF0 side colors to something else in the multisprite kernel...

 

lifecolor gets retained in single bank games using 6lives.asm. It's only after making the game multi bank does it forget lifecolor after the drawscreen. There are also situations where the lives sprite data doesn't need to be refreshed. It's all very confusing. In the future I'll just assume lifecolor and lives: need to be refreshed before the drawscreen command.

 

As for the multisprite kernel.. I did experiment with different colors per side of the screen here:

http://atariage.com/forums/topic/209968-final-fantasy-adventure-sprite-with-boss/

 

One side has a black playfield and the other is white. I bet it also applies to the PF0 columns too.

[RetroFiends]

Well, if these ASM by Andrew Davie tutorials say anything to me and I'm actually understanding it, You'd have to update COLUBK or COLUPF at the appropriate point using WSYNC in order to be able to touch PF0. SeaGtGruff made an example at one point updating the colors in PF1 & 2, or the actually touchable portions of the screen for us bB users, and while it's impressive, it's also a bloody mess in bB code and wholely innefficient use of cycles It looks far, far easier to do something like this (keeping it in mind from the beginning) in ASM.

 

I keep running into things like that. If it keeps up I really will learn ASM.

[+Random Terrain]

Solved! 6lives.asm changes behavior if you go multi-bank. First off, it seems to need to be in the last bank.

 

That's on the bB page:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#lifecounterstatusbar

With 8K or larger games, you must place the inline command in the last bank since your game will look for the module there. See inline for more information about this command (and note the warning). In a 4K game, you can use include instead of inline for minikernels.

[+Random Terrain]

I was just rechecking and the bB page also says:

 

When you assign a number of lives, you ALWAYS need to define (or redefine) the life icon using lives: or the icon won't display correctly.