Colored line as game is booting

[OldAtAtari]

Does anyone know why this colored line at the bottom of the screen appears in programs I build from the old karri/nop template? It's just there for a moment before the title screen comes up.

 

It happens in Handy when I load the *.LNX but not when I load the *.O.

 

Thanks.

 

[42bs]

Because you set the color before video base. So you see part of your code.

[OldAtAtari]

29 minutes ago, 42bs said:

Because you set the color before video base. So you see part of your code.

 

Thanks. So it's because I'm defining the pallette too early. I'll see about moving it down into the function.

 

 

Edited December 15, 2022 by OldAtAtari

[OldAtAtari]

Well that didn't work. I've now created the most minimal program I can think of, and the colored bar still appears. Any ideas? I'll put my program code below:

 

The makefile

include ../Common.mk

objects= \

objlists = \
	../resident/objlist \
	../intro/objlist \
	../game/objlist

others = \
	@../resident/objlist \
	@../intro/objlist \
	@../game/objlist

all: danceBro.lnx danceBro.o

danceBro.lnx : $(objects) $(objlists)
	$(CL) -t lynx -o $@ -m lynx.map $(objects) $(others) lynx.lib
	python3 filler.py danceBro

danceBro.o : $(objects)
	$(CL) -t lynx --config lynx-bll.cfg -m bll.map -o $@ $(objects) $(others) lynx.lib

clean:
	$(RM) $(objects) $(target) lynx.map danceBro.lnx danceBro.lyx danceBro.o

 

game.c

void game()
{
}

 

intro.c

void intro()
{
} 

 

 

 

 

 

[OldAtAtari]

Figured it out, somewhat. It could certainly be debugged more, but I'm thinking it's not necessary for my purposes.

 

When I remove the call to the readSaveData() function in resident.c, the colored bar does not show up. Am I right that as long as I'm not planning on saving any data to the cartridge, then it's ok to not have the SaveData functionality?

 

int main(void)
{
    tgi_install(&tgi_static_stddrv);
    tgi_init();
    joy_install(&joy_static_stddrv);
    lynx_snd_init();
    CLI();

//	readSaveData();
	if(strcmp((char*)saveBuf,EEPROM_MAGIC)!=0)
		resetSaveData();

 

[42bs]

Do not comment out code you do not use, remove it!

 

Also remove the depending code like the "strcmp"!

[OldAtAtari]

5 hours ago, 42bs said:

Do not comment out code you do not use, remove it!

 

Also remove the depending code like the "strcmp"!

Will do. I could get rid of a lot of code, including the call, the function, and anything that depends on it. Now if someone can confirm that I don't need it... The game works fine without it, but is there some reason to keep it anyway? Will it need it if it goes on a cartridge?

[42bs]

1 hour ago, OldAtAtari said:

Will do. I could get rid of a lot of code, including the call, the function, and anything that depends on it. Now if someone can confirm that I don't need it... The game works fine without it, but is there some reason to keep it anyway? Will it need it if it goes on a cartridge?

IIRC the rules say: No save-game option.

[OldAtAtari]

22 minutes ago, 42bs said:

IIRC the rules say: No save-game option.

That's true for the Lynx Jam. So for that, I can get rid of the ReadSaveData function, the WriteSaveData function, and the ResetSaveData function, which is terrific. I just wanted to verify that there is nothing in that code that will be needed later on when this is put on the multi-cart. I don't know how multi-carts work, or regular carts, for that matter, but I assume that none of that functionality will be needed as long as the game itself does not need to read and write in the "saves" directory.

 

42bs, thanks for the help. I'll go ahead and delete all that code, and then if there's a reason to put it back in later on, I can just revert to an earlier version.

[42bs]

Multi-cards likely have a "loader/menu" and just load your ".o" file at the right address and then starts it.

[Fadest]

Yes, after the Lynx boot, the menu display fancy graph and loads the selected .o file and nothing more.

Also, remember some of us are not using the "modern" cc65 toolset, but still the old "newcc65" with BLL library, or even the BLL library in ASM (but I do not think it occured in 3 LynxJam).

So as long as you r.o file runs and does not need extra data from the ROM, it is OK. 

So yes, you can remove all the EEprom stuff.

[OldAtAtari]

26 minutes ago, Fadest said:

Yes, after the Lynx boot, the menu display fancy graph and loads the selected .o file and nothing more.

Also, remember some of us are not using the "modern" cc65 toolset, but still the old "newcc65" with BLL library, or even the BLL library in ASM (but I do not think it occured in 3 LynxJam).

So as long as you r.o file runs and does not need extra data from the ROM, it is OK. 

So yes, you can remove all the EEprom stuff.

Thank you very much! I need to clean up my code anyway, now that the big rush for the Lynx Jam deadline is over. So I'll delete the EEprom stuff as well.

[+karri]

I did fix the boot stuff about a year ago in my cc65 and also in the official cc65. But if you have an older toolchain the garbage pixels are still there during the boot. The booloader was changed to make the palette black at boot time. The easy fi is to grab my bootldr.s from the cc65/libsrc/lynx and link it with your build locally.

 

bootldr.s.txt

[OldAtAtari]

39 minutes ago, karri said:

I did fix the boot stuff about a year ago in my cc65 and also in the official cc65. But if you have an older toolchain the garbage pixels are still there during the boot. The booloader was changed to make the palette black at boot time. The easy fi is to grab my bootldr.s from the cc65/libsrc/lynx and link it with your build locally.

 

bootldr.s.txt 4.45 kB · 0 downloads

Great. So this is a known thing from an old version. That's terrific. I just need to get my environment updated. So you changed the pallet to black. Does that mean that the garbage pixels are still there, just unseeable against the black background? Which is a perfectly acceptable solution as far as I'm concerned.

[+karri]

2 hours ago, OldAtAtari said:

Great. So this is a known thing from an old version. That's terrific. I just need to get my environment updated. So you changed the pallet to black. Does that mean that the garbage pixels are still there, just unseeable against the black background? Which is a perfectly acceptable solution as far as I'm concerned.

Yes, that is the idea. Setting the hw palette to black before booting from the cart.

[OldAtAtari]

5 minutes ago, karri said:

Yes, that is the idea. Setting the hw palette to black before booting from the cart.

Great, Karri. Thanks. I really appreciate your guidance. 

[OldAtAtari]

11 hours ago, karri said:

I did fix the boot stuff about a year ago in my cc65 and also in the official cc65. But if you have an older toolchain the garbage pixels are still there during the boot. The booloader was changed to make the palette black at boot time. The easy fi is to grab my bootldr.s from the cc65/libsrc/lynx and link it with your build locally.

 

bootldr.s.txt 4.45 kB · 4 downloads

 

After trying unsuccessfully to patch up my environment using this version of bootldr.s, I deleted everything and started over with a fresh install. I followed the cc65 README.md instructions, assuming that would get me the latest and greatest. The colored garbage pixels haven't gone away, unless I get rid of the readsavedata() function as described above. Why I am I not seeing the black palette? I can see where you did that in the bootldr.s file, but it's not having the desired effect in my LNX file.

 

### How do I get set up? ###

* Summary of set up
  apt-get install git checkinstall mednafen
* Configuration
  git clone https://karri@bitbucket.org/atarilynx/lynx.git
  cd lynx/tools
  sudo make -f Makefile.deb
* Dependencies
* Database configuration
* How to run tests
* Deployment instructions

 

[+karri]

Could it be that you don't clear the screen before drawing? There is no implicite cls() function at screen init.

[OldAtAtari]

5 hours ago, karri said:

Could it be that you don't clear the screen before drawing? There is no implicite cls() function at screen init

I'm not at the computer now to look at it or edit it, but just from memory, I don't think I do. The colored pixels do go away before the title screen is drawn, but I don't think I'm specifically clearing the screen. I'll add that to intro.c and see if it helps. Or maybe I'll find that it's already in resident.c. I'll let you know.

 

 

[+karri]

The problem is that the memory is not zeroed at the time you do the tgi_init(). The bootloader code is still in the screen buffer area and it shows as those colourful stripes.

 

When you initialize the tgi_init() it will change the hw palette to be visible again.

 

You could either force the palette to be black again. Or fix the screen buffer to show something meaningful. Or clear it to zeroes.

[OldAtAtari]

4 hours ago, karri said:

The problem is that the memory is not zeroed at the time you do the tgi_init(). The bootloader code is still in the screen buffer area and it shows as those colourful stripes.

 

When you initialize the tgi_init() it will change the hw palette to be visible again.

 

You could either force the palette to be black again. Or fix the screen buffer to show something meaningful. Or clear it to zeroes.

You are correct, sir! All I had to do in resident.c was push tgi_init() down a few lines such that it happens after the readSaveData() function. That function is where the garbage pixels happen, so per my understanding, I'm letting the palette stay black while that's happening, and then letting the palette reset once it's done. The colored line is gone now. Thank you!

 

{
    joy_install(&joy_static_stddrv);
    lynx_snd_init();
    CLI();

	readSaveData();
	if(strcmp((char*)saveBuf,EEPROM_MAGIC)!=0)
		resetSaveData();
 
// Moved the following two lines down so that the palette would stay black during the readSaveData() function
	tgi_install(&tgi_static_stddrv);
    tgi_init();