Trying to bankswitch ... having troubles

[+darryl1970]

I added Popeye to bank 9 (144k), and he plots on the screen too.

I am hoping I can split all of my sprites up between the always visible banks.

 

I had to make sure the graphics for Level1 were included before the NumLetpng, which is used in Level1

 

    incgraphic Level1png.png 160A 0 2 1 3 0

    incgraphic Level1apng.png 160A 0 1 2 3 1

    incgraphic Num.png 160A 0 2 1 3 5

    incgraphic NumMidpng.png 160A 0 2 1 3 5   

    incgraphic NumLetpng.png 160A 0 2 1 3 5 

    incgraphic PopeyeLife.png 160A 0 1 2 3

 

Main1

    restorescreen

Edited September 10, 2020 by darryl1970

[+mksmith]

Good work Darryl! Looking at your most recent code your heading in the right direction.

 

With reorganising your images - I can't remember how the characterset/mapfile works but perhaps as you have found these images are best list first so they are in GFX block 0 (@RevEng, @Muddyfunster - you guys got any thoughts on this?).

 

In your bank breakdown try to make sure the background gfx are located in the bank you are running the level from and stick whatever main core sprites you can fit into the shared gfx bank. That way if you need to duplicate sprite gfx this will hopefully be minimised as references will need to be updated. As Mike has said there is potential duplication of images or code with banking - it's just the way it is unfortunately but try to embrace it!

 

Review the compile log to determine what is fitting into each gfx block as you can sometimes fit more in by re-ordering things.  If you are using the Plotsprite 'frame' parameter all the gfx for that animation will need be located in the same gfx block (more info here).

 

Swapping between banks during redraw is a bad move - it tends to glitch the screen (I've tried!).  Fit everything you need into the bank you are running from (or the shared bank).  You can before starting a level do some bank swapping whilst the screen is blank before the first drawscreen.  Both Millie and Molly and Arkanoid go something like from Bank1 (Initialise level) -> Bank4 (Level setup and initial render) -> Bank2 (Game) before drawing.  This is really where my suggestion about using a 128KRam configuration comes from as it's can be very hard to fit everything in either you game or shared bank (both code and data such as lookup tables or pokey tunes). 

 

 

[+Muddyfunster]

As Matt said, sometimes you need to change the order of how things are called in the graphics block to make efficient use of the block or blocks. I spend a bit of time tweaking this for sprites etc to squeeze every last byte out if the blocks. Moving small sprites into different blocks to fill up those few spare bytes that might be there.

 

I think mapfile tiles need to be together in the same block, and you need to tell maria which block you are drawing from (characterset), otherwise she gets confused and uses whatever, that's when you see garbage I think. (Mike might correct me on this ). 

 

If you are using frames, sometimes I found animations will glitch if the sprites for the animation sit across two blocks if you are using indexes (as in gfx blocks where the sprites are stored, not blocks on screen). So try to keep animations frames in the same block if you are using indexes to animate and call.

 

You can demarcate the blocks using "newblock" if you want to force things. I tend to see what goes where in the compile messages and see which blocks have free space or if something is straddling two blocks.

 

For E.X.O. i'm using 256k+RAM. 

 

Each level lives across or uses 3 banks and taps the persistent bank for sprites.  The game has multiple levels (4 currently). Each level shares the same base engine code (more or less) but the code is duplicated rather than trying to make one core and have everything hang off of it. In many ways, duplicating code is better than trying to follow the "efficient" branching code instinct (great advice from Mike and Matt).

 

So for example on E.X.O. Level 1 looks like this :

 

Bank 2 = background gfx tiles specific to that level only (fills block 0) + executable code for the engine.

Bank 3 = mapfiles for screens 1-12

Bank 4 = mapfiles for screens 13-25

Last Bank = shared sprites like enemies, explosions, players ship etc. that can be used for any level. 

 

My execution path follows what Matt suggested above & the loop does some code like this :

• Has there been a screen # change ?
• if yes, Check what screen I'm on.
  • if the screen is <12 goto bank 3 and copy the correct mapfile into memory - do some palette stuff
  • if the screen is >=13 goto bank 4 and copy the correct mapfile into memory - do some palette stuff
• Plot the mapfile & save screen
• Jump back to bank 2
• Plot sprites etc. game logic etc.
• Draw the screen 

I'm plotting the maps in bank 3 or 4, but I'm not drawing the screen until I'm in bank 2 so it's using the graphics tiles from bank 2 + any common sprites stashed in the last bank.

 

Bit of a rambling explanation but I hope that's helpful! Keep at it, Popeye is looking great

 

 

Edited September 11, 2020 by Muddyfunster
tyops

[RevEng]

1 hour ago, Muddyfunster said:

I think mapfile tiles need to be together in the same block, and you need to tell maria which block you are drawing from (characterset), otherwise she gets confused and uses whatever, that's when you see garbage I think. (Mike might correct me on this ). 

You got it. ? The mapfile uses characters, so the characters need to be part of the current character set graphics. Maria only uses one character set at a time.

[+darryl1970]

Are there any other cartridge bank sizes that allow the 1st and last bank to be visible at all times, other than 144k and 528k?

I don't think I'll need 528k, but who knows, since intros and level clears might need to be their own bank. I haven't gotten that far.

 

Do any others allow RAM with two always-visible banks?

 

Popeye and Brutus frames barely fit into 32k. (That's not including Popeye dying. That's okay, because I think I'll make that sequence its own bank. I can do something similar with an intro sequence.) I have Brutus's movement routines in a separate bank, while his plot routines are in the always present bank.

 

I could possible do this with Popeye too, but I don't know if all of the bank jumping will cause issues.

 

From what I can tell, I've lucked out that all of I don't need any more in-game frames for Brutus & Popeye.

 

How will this affect things when the music needs added?

 

--D

[RevEng]

272k is between those two.

 

There's no format with 2x 16k permanent banks and extra ram. It needs to get mapped somewhere in the address space, and there's only so much address space.

 

If you're not already using dmaholes, you can use them to squeeze more code into banks that are full with graphics. That way you shouldn't need to bank away to run code.

 

Since you're using double-buffering, you can never be quite sure when the visible screen is being drawn, so you have no choice but to squeeze music data and routines into a permanent bank, a currently visible bank, or one with the same graphics. The general rule is, if you have graphics in a temporary bank, you can't jump away to any other bank that doesn't have the same temporary graphics. That's true whether you're talking about music routines, game logic, a hamburger money-lending routine, or whatever.

 

Additional info for completeness, which you can ignore for this project: If were weren't relying on double-buffering, you could try to bank away after your plot* routines were done, but then you're engaged a race between completing the music updates and when the next visible frame appears. If you lose the race you get visible screen glitches.

[+darryl1970]

13 minutes ago, RevEng said:

272k is between those two.

 

There's no format with 2x 16k banks and extra ram. It needs to get mapped somewhere in the address space, and there's only so much address space.

 

If you're not already using dmaholes, you can use them to squeeze more code into banks that are full with graphics. That way you shouldn't need to bank away to run code.

 

Since you're using double-buffering, you can never be quite sure when the visible screen is being drawn, so you have no choice but to squeeze music data and routines into a permanent bank, a currently visible bank, or one with the same graphics. The general rule is, if you have graphics in a temporary bank, you can't jump away to any other bank that doesn't have the same temporary graphics. That's true whether you're talking about music routines, game logic, a hamburger money-lending routine, or whatever.

 

Additional info for completeness, which you can ignore for this project: If were weren't relying on double-buffering, you could try to bank away after your plot* routines were done, but then you're engaged a race between completing the music updates and when the next visible frame appears. If you lose the race you get visible screen glitches.

I chucked at the Wimpy reference.

 

One of the things I love about these classic systems is working around the limitations.

 

One of the things I hate about these classic systems is working around the limitations.

 

If worse comes to worse, I could scrap my current graphics and downsize. I'll definitely try the dmaholes. Is that per-bank, or does one setting define it globally?

 

--D

[RevEng]

DMA holes are created in any bank that has an "ingraphic" statement in it. Basically it's an island of ROM between the different graphics blocks in that bank, and unless you stick code in there the ROM space is just wasted. If you look at your compile messages, you'll see stuff like...

 

*** (): INFO, bank #1, GFX Block #0 starts @ $6000
        NumLetpng Num NumMidpng PopeyeLife
*** (): INFO, bank #1, GFX block #0 has 2784 bytes left (174 x 16 bytes)


*** (): INFO, bank #1, DMA hole #0 starts @ $7000
        no code defined for DMA hole

...in this case it means you could stick code in Bank 1's DMA hole by issuing the "dmahole 0" statement in the bank, and any code that follows will go in that hole.

 

If you stuff the bank with graphics, you may have multiple dmaholes, and can use "dmahole 1" once you've filled the DMA hole 0. Just be sure to search the compile output to see if the DMA holes exist, before you start trying to stick code in them.

 

[R_Leo_1]

Atarius Maximus had mentioned earlier that a bank can have 2 graphics blocks, but every time I try to compile it states that I have ran out of space in the main area. The only way to get it to compile is to use "dmahole X noflow" for all the dma holes, however then the code I wrote wont function at all. So I'm wondering what the proper format is to use the 2 graphic block per bank setup, as I definitely need the extra graphics space since I'm doing a graphics demo lol.

[RevEng]

One clarification. The number of graphics blocks that fit in a bank actually depends on the zoneheight, and the last bank will be able to get one less than the others, because it also has to host the 7800basic common code. Additionally, I improved the layout since AM wrote that.

 

Anyway, back to the question of how to put code in a fully stuffed bank... When you use regular dma holes, 7800basic tries to add a little code to allow your code to seamlessly flow across the dma holes. But when you've stuffed the game with graphics, there's no room for that code, so you need to use "noflow". The bank will more or less look like this...

 

[graphics block]

[dma hole 0]

[graphics block]

[dma hole 1]

[...]

 

...which isn't a big deal, but you need to explicitly "goto" or "gosub" whenever you need to run code in the dma hole. Once you've done running inside that dma hole, you need to either "goto" or "return" to get out (depending on how you got in) even just to reach the next dma hole.

[R_Leo_1]

I have this exact format and I am still unable to get anything on the screen, can't even get the background color to change. So none of my code is being reached for some reason. If you can spot what I am doing wrong with the format please let me know, apologies for the continued confusion ?

 

LL128K.bas

[RevEng]

It's impossible to say for sure, without actually compiling and seeing the messages, but I think you have so many graphics in bank 1 that they've displaced your code start. For now the only way around that is to back off until you have space at the start of the ROM for code. (at a minimum, until the first "dmahole 0" works without the noflow)

 

I'll see if I can figure out a way to flag an alternate game start location in ROM, so you can point 7800basic to run your game from the dma hole instead, but I won't be able to get a new 7800basic release out for a week or so.

[+mksmith]

@R_Leo_1 Can you post your compile log?

[R_Leo_1]

Here's what I get:

 

C:\Users\dusti\Desktop\ATARI7800\7800basic>7800bas.bat Programs\LadyLadyDemo\LL128K.bas
7800basic v0.10 Jun 15 2020 23:49:14
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value

*** (): INFO, bank #1, GFX Block #0 starts @ $8000
        Background1 Background2 LLTitleRow1Chunk1 LLTitleRow2Chunk1
        LLTitleRow3Chunk1 LLTitleRow3Chunk2 LLTitleRow4Chunk1
        LLTitleRow4Chunk2 LLTitleRow5Chunk1 LLTitleRow5Chunk2
        LLTitleRow6Chunk1 LLTitleRow7Chunk1 LetP LetR LetE LetS LetF LetI
        LogoRow1Chunk1 LogoRow1Chunk2 LogoRow1Chunk3 LogoRow2Chunk1
*** (): INFO, bank #1, GFX block #0 has 16 bytes left (1 x 16 bytes)

*** (): INFO, bank #1, DMA hole #0 starts @ $9000
        DMA hole code found and imported

*** (): INFO, bank #1, GFX Block #1 starts @ $A000
        LogoRow2Chunk2 LogoRow2Chunk3 LogoRow2Chunk4 LogoRow3Chunk1
        LogoRow3Chunk2 LogoRow3Chunk3 LogoRow3Chunk4 LogoRow4Chunk1
        LogoRow4Chunk2 LogoRow4Chunk3 LogoRow4Chunk4 LogoRow5Chunk1
        LogoRow5Chunk2 LogoRow5Chunk3 LogoRow5Chunk4
*** (): INFO, bank #1, GFX block #1 has 2368 bytes left (148 x 16 bytes)

*** (): INFO, bank #1, DMA hole #1 starts @ $B000
        DMA hole code found and imported

libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value

*** (): INFO, bank #8, GFX Block #0 starts @ $E000
        TrojanRow1Chunk1 TrojanRow2Chunk1 TrojanRow3Chunk1
        TrojanRow3Chunk2 TrojanRow4Chunk1 TrojanRow4Chunk2 NewMars1
        NewMars2 NewMars3 NewMars4
*** (): INFO, bank #8, GFX block #0 has 2336 bytes left (146 x 16 bytes)

7800basic compilation complete.
User-defined 7800.asm found in current directory
   0 bytes of ROM space left in the main area of bank 1.
             4041 bytes of ROM space left in DMA hole 0.
             4083 bytes of ROM space left in DMA hole 1.
   16380 bytes of ROM space left in the main area of bank 2.
   16380 bytes of ROM space left in the main area of bank 3.
   16380 bytes of ROM space left in the main area of bank 4.
   16380 bytes of ROM space left in the main area of bank 5.
   16380 bytes of ROM space left in the main area of bank 6.
   16380 bytes of ROM space left in the main area of bank 7.
   5904 bytes of ROM space left in the main area of bank 8.
     $1880 to $1fff used as zone memory, allowing 27 display objects per zone.
     2429 bytes left in the 7800basic reserved area.

Complete.
Read $C000 bytes of cartridge data.
Cartridge hash area is from $F000 to $FFFF.
Cartridge signature for 'C:\Users\dusti\Desktop\ATARI7800\7800basic\Programs\LadyLadyDemo\LL128K.bas.bin' appears to be empty.
Encrypting... 00 01 success!

A valid cartridge signature is:
04 9e ac 53 d5 c6 21 11  18 bf ba ca 96 60 ee 98
d2 ff 45 c4 8f a5 48 67  60 1f a6 e2 39 7d cd b1
75 a5 75 b6 3e 9e 8c 1a  46 62 42 c3 ca 32 55 2c
09 87 7e 4d 1c d3 e8 dc  52 95 59 98 31 5e 99 d7
e6 c2 3e bf be df 43 84  e8 1e 47 ac 1d 9f 4f 37
c8 7f 30 89 13 92 b8 d8  a2 d9 7f 79 07 f5 bc 4f
d4 06 1b ef 0e 22 84 49  79 e7 f0 43 4a 00 af 30
e2 44 c4 e3 66 9c ea 97

Wrote back 120 bytes to 'C:\Users\dusti\Desktop\ATARI7800\7800basic\Programs\LadyLadyDemo\LL128K.bas.bin'.

7800header 0.10 Jun 15 2020 23:49:19
  opened parameter file a78info.cfg
7800makecc2 v0.1
  The ROM 'C:\Users\dusti\Desktop\ATARI7800\7800basic\Programs\LadyLadyDemo\LL128K.bas.bin' is compatible with CC2.

[+mksmith]

Thanks @R_Leo_1. 

 

Was just doing a search and found a topic where you previously raised something similair 7800 Basic Compiler Warning Help? - Atari 7800 Programming - AtariAge Forums. SmittyB and RevEng thought that message might be something you could potentially ignore.  From the log it does appear to be compiling so maybe it's still affecting something. 

 

Some questions

What package are you using to export your gfx?

Can you do a very stripped back project and see if individual images display?

There is a reboot call in dmahole 1 - is that getting activated?

 

Things to try

Try putting the incgraphic entries at the very top of the bank before setting any dmaholes

There isn't a lot of code so maybe remove dmahole 1

 

[R_Leo_1]

To answer your questions:

I use Graphics Gale to export my graphics.

I have currently stripped back everything to just the first bank and still no dice.

I removed the reboot and that wasn't the issue apparently.

 

I went ahead and removed dmahole 1 and moved the incgraphic entries at the very top of the bank and just tried to display the letter 'P' from my stored graphics, and still no luck...

If the "libpng warning: Incorrect bKGD chunk index value" is causing the issue, I'm not really sure how to correct it at the moment ? as I can't get ImageMagick that SmittyB mentioned to run on windows' Linux Kernal no matter what I do. 

[RevEng]

Is the first line of your code that's supposed to run inside your dmahole, or before it?

[R_Leo_1]

It's inside the dmahole. This is the most recent code: 

 

;init

	set tv ntsc
	set romsize 128k
	set screenheight 224
	set basepath Programs\LadyLadyDemo\gfx_LadyLady
	
	bank 1
	
;titleScreen

	;Load first gfx block
	
	;Background chunks
	
	incgraphic Background1.png 160A 0 3 2 1
	incgraphic Background2.png 160A 0 1 2 3
	
	;LadyLady 
	
	incgraphic LLTitleRow1Chunk1.png 160B 0 1 3 7 2 6 5 13 11 10 9 14 0
	incgraphic LLTitleRow2Chunk1.png 160B 0 1 2 6 5 3 7 13 14 0 0 0 0
	incgraphic LLTitleRow3Chunk1.png 160B 0 1 7 3 5 13 2 11 6 14 10 9 0
	incgraphic LLTitleRow3Chunk2.png 160B 0 1 14 11 10 9 2 13 0 0 0 0 0
	incgraphic LLTitleRow4Chunk1.png 160B 0 1 7 6 5 11 10 14 13 9 2 0 0
	incgraphic LLTitleRow4Chunk2.png 160B 0 14 11 10 9 13 1 3 2 5 0 0 0
	incgraphic LLTitleRow5Chunk1.png 160B 14 11 10 13 1 5 0 7 6 9 3 2 0
	incgraphic LLTitleRow5Chunk2.png 160B 1 14 0 0 0 0 0 0 0 0 0 0 0
	incgraphic LLTitleRow6Chunk1.png 160B 0 14 13 11 10 9 1 2 3 5 0 0 0
	incgraphic LLTitleRow7Chunk1.png 160B 0 1 14 13 11 10 9 0 0 0 0 0 0
	
	;Letters
	
	incgraphic LetP.png 160A 0 3 2 1
	incgraphic LetR.png 160A 0 3 2 1
	incgraphic LetE.png 160A 0 3 2 1
	incgraphic LetS.png 160A 0 3 2 1
	incgraphic LetF.png 160A 0 3 2 1
	incgraphic LetI.png 160A 0 3 2 1

	dmahole 0 noflow
	
	clearscreen
	
	asm
	
	lda #$0f
	sta $35
	
	lda #$5c
	sta $36
	
	lda #$86
	sta $37
	
end

	BACKGRND=$25
	
	plotsprite LetP 5 40 192
	
	savescreen
	
	drawscreen
	
	
	
	
	;LadyLady Logo
	
	incgraphic LogoRow1Chunk1.png 160A 0 1 3 2
	incgraphic LogoRow1Chunk2.png 160A 0 1 3 2
	incgraphic LogoRow1Chunk3.png 160A 0 1 3 2
	incgraphic LogoRow2Chunk1.png 160A 0 1 3 2
	incgraphic LogoRow2Chunk2.png 160A 0 1 3 2
	incgraphic LogoRow2Chunk3.png 160A 0 1 3 2
	incgraphic LogoRow2Chunk4.png 160A 0 1 3 2
	incgraphic LogoRow3Chunk1.png 160A 0 1 3 2
	incgraphic LogoRow3Chunk2.png 160A 0 1 3 2
	incgraphic LogoRow3Chunk3.png 160A 0 1 3 2
	incgraphic LogoRow3Chunk4.png 160A 0 1 3 2
	incgraphic LogoRow4Chunk1.png 160A 0 1 3 2
	incgraphic LogoRow4Chunk2.png 160A 0 1 3 2
	incgraphic LogoRow4Chunk3.png 160A 0 1 3 2
	incgraphic LogoRow4Chunk4.png 160A 0 1 3 2
	incgraphic LogoRow5Chunk1.png 160A 0 1 3 2
	incgraphic LogoRow5Chunk2.png 160A 0 1 3 2
	incgraphic LogoRow5Chunk3.png 160A 0 1 3 2
	incgraphic LogoRow5Chunk4.png 160A 0 1 3 2
	
	bank 2

	bank 3

	bank 4

	bank 5

	bank 6

	bank 7

	bank 8
	
	
	

 

[RevEng]

Try using "dmahole 0" instead of "dmahole 0 noflow". The game starts running at the beginning of the cart rom in bank 0, and by definition a dmahole isn't located at the beginning of your cart. So you either need to goto/gosub to your code, or drop the noflow.

[R_Leo_1]

Okay so I tried changing it to just "dmahole 0" and the compiler tells me "-3 bytes of ROM space left in the main area of bank 1." Which was the issue I was having earlier where the extra bit of asm that is removed with noflow is causing issues. And as for the goto/gosub being used to get to my code, I can't place a goto command before the dmahole 0 noflow command is placed and if I place it after, it will compile but my code is still not running

[+mksmith]

2 hours ago, R_Leo_1 said:

Okay so I tried changing it to just "dmahole 0" and the compiler tells me "-3 bytes of ROM space left in the main area of bank 1." Which was the issue I was having earlier where the extra bit of asm that is removed with noflow is causing issues. And as for the goto/gosub being used to get to my code, I can't place a goto command before the dmahole 0 noflow command is placed and if I place it after, it will compile but my code is still not running

Hi @R_Leo_1 - sorry I haven't had a change to get back to help with this.  Sorry can you post the compile log again for this one?

[RevEng]

It sounds like your first bank is still stuffed, if you have -3 bytes of space.

 

Here's a preview of the upcoming 7800basic release's startup.asm. Stick it in the same folder as your basic file, go back to "dmahole 0 noflow", and put a label called "altgamestart" in the dma hole, but prior to your game code.

startup.asm

[R_Leo_1]

Okay so I tried it and still no dice, all I get is a black screen. I'm starting to think that there may be an issues related to the "libpng warning: Incorrect bKGD chunk index value" I keep getting, as if I delete the incgraphic commands for the 160B grahpics, I get a black screen AND some ear grating audio from the TIA for some reason, which makes me think this is somehow causing a crash?

14 hours ago, mksmith said:

Hi @R_Leo_1 - sorry I haven't had a change to get back to help with this.  Sorry can you post the compile log again for this one?

Oh no need to apologize. You're under no obligation to help me so I appreciate any help I get whenever I can

Oh and here's the compiler log you asked for:

7800basic v0.10 Jun 15 2020 23:49:14
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value
libpng warning: Incorrect bKGD chunk index value

*** (): INFO, bank #1, GFX Block #0 starts @ $8000
        Background1 Background2 LLTitleRow1Chunk1 LLTitleRow2Chunk1
        LLTitleRow3Chunk1 LLTitleRow3Chunk2 LLTitleRow4Chunk1
        LLTitleRow4Chunk2 LLTitleRow5Chunk1 LLTitleRow5Chunk2
        LLTitleRow6Chunk1 LLTitleRow7Chunk1 LetP LetR LetE LetS LetF LetI
        LogoRow1Chunk1 LogoRow1Chunk2 LogoRow1Chunk3 LogoRow2Chunk1
*** (): INFO, bank #1, GFX block #0 has 16 bytes left (1 x 16 bytes)

*** (): INFO, bank #1, DMA hole #0 starts @ $9000
        DMA hole code found and imported

*** (): INFO, bank #1, GFX Block #1 starts @ $A000
        LogoRow2Chunk2 LogoRow2Chunk3 LogoRow2Chunk4 LogoRow3Chunk1
        LogoRow3Chunk2 LogoRow3Chunk3 LogoRow3Chunk4 LogoRow4Chunk1
        LogoRow4Chunk2 LogoRow4Chunk3 LogoRow4Chunk4 LogoRow5Chunk1
        LogoRow5Chunk2 LogoRow5Chunk3 LogoRow5Chunk4
*** (): INFO, bank #1, GFX block #1 has 2368 bytes left (148 x 16 bytes)

*** (): INFO, bank #1, DMA hole #1 starts @ $B000
        no code defined for DMA hole

7800basic compilation complete.
User-defined 7800.asm found in current directory
segment: INITIAL CODE SEGMENT 8000          eqm       vs current org: 8003
   -3 bytes of ROM space left in the main area of bank 1.

C:\Users\dusti\Desktop\ATARI7800\7800basic\Programs\LadyLadyDemo\LL128K.bas.asm (495): error: Origin Reverse-indexed.

Cartridge size not a multiple of 4K bytes!

7800header 0.10 Jun 15 2020 23:49:19
*** WARNING: The file size of C:\Users\dusti\Desktop\ATARI7800\7800basic\Programs\LadyLadyDemo\LL128K.bas.bin isn't correct.

  opened parameter file a78info.cfg
7800makecc2 v0.1
  The ROM 'C:\Users\dusti\Desktop\ATARI7800\7800basic\Programs\LadyLadyDemo\LL128K.bas.bin' is compatible with CC2.

Edited September 20, 2020 by R_Leo_1
Sent wrong compiler log

[RevEng]

It's probably easiest if you get me a zip of the project. (in PM, or here). That way I can reproduce it, and look at the finer details of what's going on.

[+mksmith]

It's certainly quite a strange one as everything on the face of it looks right...