stevesims
commented
10 months ago NB there are two different sets of FG and BG colours to consider here as text and graphics colours are tracked separately. that's potentially 4 different colours to send across.
if we were to piggy-back this information along with the mode info then the current VDP protocol buffer on the eZ80 side would need to be expanded beyond its current 16 byte size. there's also the question of what format should be used for sending the colours - VDU 23,0,&84,x;y; sends four bytes (red, green, blue and palette index), so should we copy that or just send the palette index value?
if the mode information packet is expanded to include this data then a new version of MOS would be needed that would understand this new data packet format, and expose that data to users
another consideration if this data is sent along as part of the mode information is keeping such information "current" on MOS. this would likely mean that all changes to currently selected graphics or text colour would send back full screen mode information. we could just not do that, but that might not match user expectations.
an alternative approach would be to add a new command to individually read colour values. that could potentially use the same response packet format as VDU 23,0,&84,x;y; (read screen pixel) and thus allow the same OS "scrpixel" info bytes to be used. this would automatically be supported by the current MOS with no changes necessary.
there is an argument that this kind of functionality shouldn't be necessary. we're a mono-tasking system so any program running should be completely in control of the currently selected colours, so it could/should be able to just keep track of whichever colours are active in its own internal state....
having said that, one could imagine for instance having an interrupt-driven clock program resident that periodically draws a clock in the corner of the screen. it would need to change the colours to do so to ensure a consistent display. a "good citizen" version of such a program would change the colours back after it has done its drawing so as to not affect the main application. to do so it would need to be able to read the currently selected colours. this would similarly be useful for a future multi-tasking OS layer
avalonbits
Today it is not possible to know which FG/BG colors are being used without resorting to some printing a character on the screen, and then querying for the pixel colors at different locations of the character (this is what AED does today).
the FG/BG colour should be part of the mode information sent as is width/height/color count.