First post, by GloriousCow
- Rank
- Member
Thought I'd start a new thread for this as it's an interesting discussion that could go on for a while.
The discussion began here: Re: MartyPC
CGA snow is a visual artifact generated by CPU-CGA bus contention in the high-resolution mode of the CGA due to the fixed READY suppression timing of the CGA card not adapting to the HCHAR character clock. Therefore READY is reasserted too soon on bus access in 80-column mode and artifacts appear on the screen in single-row spans of 8 pixels as incorrect bytes are used for glyph and attribute lookup during scanout of a single character gylph row.
Some reading on CGA wait states:
https://www.reenigne.org/blog/the-cga-wait-states/
https://martypc.blogspot.com/2023/05/explorin … ait-states.html
PCRetroTech has an excellent video on the CGA in general but explores CGA snow as well:
https://www.youtube.com/watch?v=IQ2UeIx1qIA
point in video where snow is discussed:
https://youtu.be/IQ2UeIx1qIA?t=2128
Emulating snow exactly, in theory, requires sub-instruction accuracy; consider a single MOVSW instruction from VRAM to VRAM on an 8088 could have 4 bus operations, each with their own set of wait states and potentially resulting in 4 'snowflakes' on screen.
The CGA device must be either ticked to update its clock to the CPU's T3 on each transfer, or some sort of data provided to the CGA on MMIO regarding the bus timings for snow post-calculation. The latter is probably more performant. The former would strictly be more 'accurate', as a program could 'race the beam' with VRAM writes, but of course, would be drawing snow all over while doing so; however, this could be intentional in the case of a theoretical demo that precisely controls the appearance of snow using lockstep.
MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc