FridgeGrid is a tool intended to help planning cycle exact code for effects on old school hardware.
Think of it as a combination of grid paper and fridge magnets in digital form with save and load functions.
Originally developed for creating Atari 2600 VCS demos, it was extended be usable for other systems as well. Templates include also the VIC-20 and the C64.
Other implementations of "raster paper" are done by tjoppen for the 2600 or lft for the C64.
Let's take an example to explain the idea of the tool. For demonstration purposes, let's use the screen/effect from 4kraVCS:
The demo part planning looks like this:
Doing 8 different colors in one line isn't that hard, but when you want to display some additional graphics, it's not that easy as well. Some planning is needed, where this tool will help you keep track of your CPU cycles, so it's a good example. For understanding it, some knowledge of the interna of the Atari 2600 VCS are needed, which I will not provide here.
The red lines above are from the template and are not relevant for this case. The effect uses the background color and playfield color alternating for the stripes. These are shown using the top green lines. Note that they are overlapping a bit sometimes as both are used during the same CPU cycle, since the video chip is three times as fast. The line with the yellow blocks show where the letters are drawn using the two sprites twice. That's the description of the screen.
Now let's take a look at the description of the code, which is below the empty lines. This first of the two lines is for displaying without text, the second one is with text. Note that the COLUxx blocks are 5 squares wide, as the CPU needs 5 cycles to execute the two commands needed to set the color. Setting the graphics data for the sprites is more complex though, so it takes 7 cycles for the two commands.
The first line (the one without text) is straight forward. There are only two function blocks needed to "waste" CPU cycles until the beam is at the right place. After setting the graphics data a loop is run (white block) and synced to the beam (black block). Note that writing every graphics data is completed at least 1 cycle before it's been used, no big problem there.
Displaying the sprites during the color changes is a bit more complex, as the timing gets a bit tight: notice the second GRP0 block has been split into two parts (GRP0R and GRP0W)? There the blocks show the read and the write operation standalone, because without the split, setting the colors would have been either too early or too late. Finding this configuration using FridgeGrid was rather easy.