# HG changeset patch
# User Paul Boddie <paul@boddie.org.uk>
# Date 1356134540 -3600
# Node ID 53cd92fd0b9670d7cb3d0b77cc22aa2bab4f8fe8
# Parent  731d6b286df8bf58f6f7724b6c4123506b025f02
Added a note about flashing colours.

diff -r 731d6b286df8 -r 53cd92fd0b96 ULA.txt
--- a/ULA.txt	Tue Oct 30 23:37:12 2012 +0100
+++ b/ULA.txt	Sat Dec 22 01:02:20 2012 +0100
@@ -296,6 +296,21 @@
 from the ULA, it is likely that the ULA is expected to provide only "high" or
 "low" values.
 
+Flashing Colours
+----------------
+
+According to the Advanced User Guide, "The cursor and flashing colours are
+entirely generated in software: This means that all of the logical to physical
+colour map must be changed to cause colours to flash." This appears to suggest
+that the palette registers must be updated upon the flash counter - read and
+written by OSBYTE &C1 (193) - reaching zero and that some way of changing the
+colour pairs to be any combination of colours might be possible, instead of
+having colour complements as pairs. It is conceivable that the interrupt code
+responsible does the simple thing and merely inverts the current values for
+colours 8 through 15, and this might be verified by looking for an operation
+that involves the bit pattern 11001100, since this value would be EORed with
+the existing palette register values in order to perform this value inversion.
+
 Palette Definition Lists
 ------------------------