7800Basic plotmapfile multiple palette corruption

[+Karl G]

I'm using plotmapfile with two source images to display part of the screen, and it works fine if the palettes for both source images are set to the same palette for the incgraphic commands. However, if they are set to different palettes, then the display is corrupted. The actual palette used for them does not matter, but they have to be the same as each other to avoid the corruption.

 

Does this issue sound familiar to anyone offhand? I can provide a zip of the source+graphics privately if anyone has time to take a look at it. Thanks in advance for any advice!

[+Karl G]

Sometimes I forget that I can look a the generated assembly. Doing a diff of the generated assembly having only changed the palette number in the source file I see that the generated assembly with the corrupted display has 180 more bytes of data than the working generated assembly.

 

[RevEng]

Every time plotmapfile hits a chunk of characters with a different palette, it has to create a new character object. So it's normal that using characters sticking to one palette throughout your plotmapfile would generate a lot less data than spreading the characters on your display across 2 or more palettes.

 

Nothing leaps to mind as to your corruption issue, though.

[+Karl G]

Edit: Am I maybe running out of DMA time here?

 

Edit2: The more I look at it, the more I suspect running out of DMA time. The rows with the globes are the ones that are truncated, and where all of the palette-switches happen.

 

I pared it down to the minimum needed to demonstrate the glitch, and am attaching a source zip. Has anyone else seen this issue before? In the example, if both images are set to palette 0 or palette 1, then it works fine. If one is set to 0 and the other to 1, however, then the glitched output occurs:

 

  

palettemap.zip

[+Muddyfunster]

Karl, I used a similar technique extensively in EXO (multiple tilesets in a tiled map with different palettes), I got similar corruption unless I threw some more memory at the display.,

 

I took a look at your code. There are a few odd things in the tiled map but nothing that should prevent it from rendering. FYI this is how I set up with zone height 8 :

 

 

If I added set extradlmemory on everything seems to render up ok.

 

 

I think that there isn't enough juice to render the multiple charsets / palettes without adding some extra DL room. In EXO/ARTI/Koppers, I use extra cart ram to extend the dlmemory.

 

 

and without :

 

 

[Ecernosoft]

2 hours ago, RevEng said:

Every time plotmapfile hits a chunk of characters with a different palette, it has to create a new character object. So it's normal that using characters sticking to one palette throughout your plotmapfile would generate a lot less data than spreading the characters on your display across 2 or more palettes.

 

Nothing leaps to mind as to your corruption issue, though.

If you know ASM, you can write a special "160D" generator in which a bunch of 16*16 sprites are present in a grid, and each can have it's own pallete. This is also useful for DMA reasons, as not only do 16*16 sprites take less dma than 2 characters in a row (14 vs 18) you can also set it to holey DMA for blanks and even get more characters as you have a 16 bit adress space instead of only 8. (This is because the upper 8 bits are taken up by CHARBASE.)

[+Karl G]

1 hour ago, Muddyfunster said:

If I added set extradlmemory on everything seems to render up ok.

I think that there isn't enough juice to render the multiple charsets / palettes without adding some extra DL room. In EXO/ARTI/Koppers, I use extra cart ram to extend the dlmemory.

Yeah; it looks like that was it. Thank you! However, I think maybe it's a bad design choice for my project since I'm wasting a lot of resources with all of the DL entries for the frequent palette switches.

 

So, to check my understanding of how it works "under the hood" - if a row is being plotted from a RAM or ROM location without any palette changes, then it would all be one DL entry (up to 32 bytes), and therefore less RAM needed to store DL entries, and also less DMA time since there is less overhead from the overhead of each entry being processed?

[RevEng]

11 minutes ago, Karl G said:

So, to check my understanding of how it works "under the hood" - if a row is being plotted from a RAM or ROM location without any palette changes, then it would all be one DL entry (up to 32 bytes), and therefore less RAM needed to store DL entries, and also less DMA time since there is less overhead from the overhead of each entry being processed?

Correct