I've been wondering since yesterday if it's possible to somehow tweak the screen noise killer to work at 2MHz (and beyond).
So I've spent this morning doing some "Evil Mad Scientist" type experiments.
Now it's time to present the results...
But first, let's recap a bit about the cause of Atom screen noise, and how the current noise killer overcomes it.
On the Atom, the 6502 CPU and 6847 VDG run from different clocks. That make it hard to share the screen memory between the two, because the to clocks are asynchronous. Atom screen noise occurs when the CPU and the 6847 both need to access screen memory at the same time. Acorn dealt with this conflict by giving the CPU priority and allowing the 6847 to briefly read back incorrect data. That incorrect data is what causes screen noise.
The original design for the Noise Killer was from Dr Alan Knowles, of Manchester University Computer Science Dept:
It turns out that memory accesses from the VDG are slow and predictable. The pixel clock is 7.16MHz and screen memory is read every 8 pixels (worst case). That's every 1100ns. Alan Knowles' insight was in 1100ns there is time for three memory cycles, even with slow 200ns RAM. The worst case is:
- a video read cycle (<200ns so video data not quite valid)
- a CPU read or write cycle (500ns)
- a second video read cycle (200ns)
Alan's design works using a transparent latch to preserve the current video data during CPU accesses. The latch LOAD signal is simply the VDG signal (which indicates a CPU access) extended to about 700ns by a 74LS123 monostable - 700ns is long enough for the CPU to complete it's access, plus an additional 200ns for the video data to get re-read. The effect of all this is that 6847 sees only stable video data, and the screen noise is banished.
So, back to the actual experiments....
Let's establish some baseline data using the following small test program:
Code: Select all
10 INPUT B 20 L=#9F00 30 M=#8000 40 P=L 50[ 60 INC M 70 JMP L 80] 90 CLEAR 4 100 *LOAD MNUA/SPLASH 8000 110 ?#BFFE=B 120 PRINT $7$7$7 130 LINK L
- executes a tight loop from screen memory (the worst case for screen noise)
- increments the first location of screen memory (so you can tell it's not crashed)
With the no noise killer, here's what you get:
No Noise Killer - 1MHz No Noise Killer - 2MHz No Noise Killer - 4MHz Next, with the existing noise killer enbled, here's what you get:
Existing Noise Killer - 1MHz Existing Noise Killer - 2MHz Existing Noise Killer - 4MHz At 2MHz and 4MHz the screen actually stops updating.
Why you might ask?
When this test program is running, every CPU cycle is a screen memory access. When the CPU is running at 2MHz, the VDG signal pulses low every 500ns, triggering the monostable. But wait, the monostable is set to 700ns. So it continues to re-trigger, the latch load signal is always low, and so the latch stays frozen at one value.
If you change the lest program a bit to reduce the rate of screen memory accesses, you do see a bit more:
Existing Noise Killer - 2MHz - lower rate of screen memory accesses Existing Noise Killer - 4MHz - lower rate of screen memory accesses But there are still artefacts.
To summarise, the current noise killer design doesn't work well at 2MHz and 4Mhz.
So can we do anything about this?
(to be continued.....)