Candy Stripe Syndrome

Don't you just love it when you do a simple memcpy() of one graphic buffer to another and realize that the stride '(aka pitch, bytes per line)' is different? It ends up being off by the delta on every line, causing the whole picture to skew. When you've got a particularly busy graphic, it looks like yummy candy stripes.

This is also very fun when one of the buffers is full of patterned data.

I like looking at a display of a mis-registered raster and try and guess what common bug is making it look like that. X variables swapped with y variables. Off-by-one in number of rows or number of columns. Coordinate system inversion. Fixing them is like tuning an old-fashioned TV.

More recently we're experiencing SparklingSyndrome?. You know, when pointers walk over into the great beyond and start putting junk on screen. In this case, however, it's randomly placed, one pixel junk. It causes this neat sparkling effect sometimes when enough of them happen close together.

As near as I can remember, here's a quote from the AmigaDOS Libraries & Devices manual:

"If you are so rude as to not Reply to every Message that Intuition sends to your Port before you close it, Intuition will be rude enough to delete every Message in the queue, including ones you've pulled. If you then Reply to one of these Messages, the Amiga will enter FIREWORKS_DISPLAY_MODE."

Nothing like a well defined API, huh?

In my assembly days (sentimental sigh), I used to sometimes put the stack on screen memory... you could detect quite a lot of stack bugs this way, by watching the stack and grow and shrink. It was also a great way to SEE how big your stack was getting.

If I was using the screen and so couldn't put the stack on the screen memory, I'd put the stack just ABOVE the screen memory, so that if it overflowed I'd see it start to write over my screen. There were many times when I'd invoke the program, see it pause for a second, and then see the screen get written over from one end to the other as an accidental recursion grew the stack. Neat way to debug, very visceral and real. Blinking lights, anyone?

Take a Commodore 64, and run this:

10 POKE RND * 64000, RND * 256 20 GOTO 10

You get to see the most amazing "features" before the inevitable lockup. --PCP

Oh don't tease us, give us a screenshot.

On the Dragon 32 (and so, therefore, probably the TRS CoCo) you could reprogram the SAM to map any page of memory onto the screen. If you did this with page 0 you could see the system clock, keyboard buffer and some other interesting things.

Also see GraphicsPatterns (is this an AntiPattern?)