Thanks a million for testing Ben. I don't believe it's anything you've done wrong. I'm willing to bet that when you put the Flipull roms back in the board that everything was OK.
What you're seeing there are similar results to the ones that I saw when I first tested this code on my Plotting board. I was adamant that it was a failed ram chip (one of the 4 x 32Kb 62256 rams that make up the combined tile/sprite/text ram) so I started piggybacking known good rams on top of the existing ones. When I piggybacked the ram at IC4 the problem went away. So I desoldered IC4 and tested it out of circuit and it was fine! Weird huh! So I socketed IC4, put the original ram back, put the original Plotting roms back in and powered it up (Plotting does extensive ram tests on boot and would have reported any problems with the ram at IC4 if there were any). No issues were observed and the game played fine.
Put my 256 colour demo roms back in and got similar artefacts to the results you're seeing above. So I piggybacked the ram @ IC1 and the issue went away. But as soon as I remove the piggybacked ram the issue comes back. Putting the Plotting roms back in and powering the cab up shows that there's nothing wrong with IC1 during ram tests at boot.
So I'm a bit baffled. I checked my voltages and was getting exactly 5v when measured across a few different chips so I even tried boosting the voltage to 5.2v at the chips to see if my demo code was particularly power hungry. Didn't cure it.
So here I am with a demo that only works correctly if the ram @ IC1 is piggybacked with a known good ram, even though there's actually nothing wrong with the ram @ IC1.
All the boot up init code in this demo is exactly the same as it's been in all the rest of the homebrew stuff that I've done and they've all been fine so that leads me to believe that the L System doesn't really like to be pushed quite as hard as this. This is another reason why it's probably not wise to run it for extended periods of time.
I've just done a test where I've changed the code slightly so that it does the screen transitions stuff first then does the 256 colour demo at the end of the screen transitions section. I assembled the binary and burned it to my EEPROM and tested it without the piggybacked ram @ IC1 and the screen transitions section worked perfectly, with no issues or corruption. When it got to the 256 colour demo and I switched palettes from the 256 colour palette to the 220 colour palette I started to get graphical corruption and missing colours in the palette rotation routine.
If I were a betting man I'd say that the palette rotation routine pushes the L System right to the very edge of its capabilities and it starts to get unreliable at that point with varying visual results. I think I'm going to submit the code to Taito and ask them to fix up their sh*t!
Anyway, I'm attaching the rejigged binary which does screen transitions first and then 256 colour demo. Please give this a try for me and let me know if it's any different.
I also noted on your video that all sound effects seemed to play during the screen transitions and all were at the same volume. Was that the case? If so then there must be something wrong with the sound hardware on my board because I only get 3 sound effects which play at normal volume level and the rest play really quietly (almost inaudible). Maybe I need to chuck this Plotting board and look for another one.
https://www.ukvac.com/forum/data/uploads/1497/256_demo_ic10.zip