Coloring of FLI-bug area does not work in Super-FLI.

[madhackerslab]

SuperCPU (and now also BeamRacer) allows a degree of control over colors in the FLI-bug area. Full explanation is available at http://unusedino.de/ec64/technical/c=hacking/ch21.html (section "Introducing Full-Screen FLI mode for the SuperCPU"), but the gist of it is that in addition to bit combination "00" controllable with $d021, you can also adjust colors of "01" and "10" pixels by writing to the data bus at the right moment, i.e. in the three cycles immediately following the badline-forcing write to $d011.

This is similar to how one can change gray pixels in FLI-bug area by setting up the data bus with the bit pattern of the instruction following STA $d011, but while in regular C64 the CPU gets halted right after that, both expansions can continue to modify the data bus.

Here is an image demonstrating the problem:

It's a simultaneous capture from S-Video (top) and component (bottom) outputs. Please disregard everything but the three leftmost character columns. Going from the top, 1/4th of the screen are pixels "10" in all three columns (so 12 pixels wide), then "01", then "00" (which can only be changed once per line). Final 1/4th are three identical columns, each with "00", "01", "10", "10" pixels.

As you can see, VideoMod outputs gray color in all cases except "00" pixels.

For comparison, here is a regular FLI picture with gray area modified by data left on the data bus during the final instruction fetch, so that they become bits 8-11 of c-fetch. Here, everything works perfectly.

As usual, I will gladly help with the testing.

[laubzega]

I've just noticed I was logged into another account. It was me above. :)

[c0pperdragon]

For the latest firmware, I followed the well known reverse engineering document. Eithet they did get something wrong, or the CMOS version of the VIC behaves differently. In any case I will change it so that the VIC accepts the data in these cases.

One detail is not totally clear. I guess the VIC will take d8-d11 from the dedicated color data lines. The fact that they also always carry the low bits of the last bus read access is just a result of how the busses are wired together. So if you want the BeamRacer to support fullscree FLI with all colors, you need to drive these color signals also.

[laubzega]

If we are talking about the same document, then I think this passage is missing one important detail:

"Nevertheless, the VIC accesses the video matrix, or at least it tries, because as long as AEC is still high in the second clock phase, the address and data bus drivers D0-D7 of the VIC are in tri-state and the VIC reads the value $ff from D0-D7 instead of the data from the video matrix in the first three cycles."

...unless VIC #CS line is selected, which apparently also lets D0-D7 be loaded from the data bus. It does not happen in vanilla C64, because even if the instruction that follows STA $d011 was being loaded from IO memory range, PLA would still not assert the IO line (see here for details https://groups.google.com/g/comp.sys.cbm/c/wdVBsz16qLw/m/CcxIRuZF8xgJ?pli=1).

However, both SuperCPU and BeamRacer do not rely on a read, but rather make a legit write to the data bus. When R/W is low, PLA no longer cares about the state of BA line (which is low in case of SuperCPU, as the internal 6510 is stopped, and likely high for BeamRacer, since it lets the CPU run unimpeded most of the time). The D0-D7 values are thus fetched by VIC as a video matrix data, i.e. the colors for pixels "01" and "10".

The story ends here for SuperCPU, because D0-D3 is connected to D8-D11 by the 4066 switch, thus making pixels "10" and "11" be of the same color. BeamRacer can go a step further, because it separates the system and VIC data buses - you can control colors "00", "01" and "10" with a display list, and simultaneously use the regular CPU technique to leave data on D0-D3 for the "11" pixels.

[c0pperdragon]

So I will change the code to accept the inputs in this condition on D0-D7 when AES or CS is low. But I have no access to D8-D11 when AES is high brcause these signals are multiplexed (to save some wires) with A2-A6. So I can only use the data on D0-D3 for this which works nearly everywhere (even with SuperCPU) With the BeamRacer and the Standard Adapter Board you can not feed all 12 data bits through to the FPGA when AES is set high by the VIC. But when you integrate the adapter into the BeamRacer anyway, you could probably override this behavior.

[laubzega]

Thank you, D0-D3 will work for us, too. As for hardware changes - maybe in BeamRacer 2 or BeamRacer 128. ;)

[c0pperdragon]

Experimental firmware as usual at: https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/firmware

[laubzega]

I did some FLI testing with and without the extra writes, looks like it's all working great with 2.10b1. Thank you!

[Icelvlan88]

.