Unless you own a Star Rider arcade game or are fairly familiar with it, you probably don't have any idea of what happens when the game is powered on.
Well, let me tell you. The first thing that happens is the video RAM is filled with a solid color. This fill is performed by the CPU and is quite slow. This loops through the entire color palette (16 colors) and adds a significant amount of time to the overall boot time. I had always assumed that this test was testing to see whether the video RAM was any good. But after revisiting this test recently, I discovered that the code does not actually check to see whether the value that it stored can be read back. So how useful is this test? The only use that I can see is if a human is watching the monitor while the test is running and is familiar enough with what is supposed to be shown to spot a problem. But really, there is no excuse for the CPU to not read back what it wrote and save the human from this kind of trouble.
Here's the relevant code:
ROM:F15F WhileBigColorFillNotDone: ; CODE XREF: GoCmpCC07AndFWith9+163 j
ROM:F15F ldx #RamStartA000 ; fill all video memory with a single color (go through palette)
ROM:F162 Fill9FFFto0WithY: ; CODE XREF: GoCmpCC07AndFWith9+15D j
ROM:F162 ldb #$15
ROM:F164 lda #8
ROM:F166 WatchdogThink: ; CODE XREF: GoCmpCC07AndFWith9+155 j
ROM:F166 stb HW_Watchdog ; this address has something to do with watchdog timer
ROM:F16A bne WatchdogThink
ROM:F16C sty ,-x ; this appears to be inefficient; since we are storing 2 bytes at a time, X could be decremented by 2 instead of just 1.
ROM:F16F cmpx #0
ROM:F172 bne Fill9FFFto0WithY
ROM:F174 leay $EEEF,y ; subtract by 1111h (so FFFFh becomes EEEEh)
ROM:F178 bne WhileBigColorFillNotDone ; fill all video memory with a single color (go through palette)
ROM:F17A lda #2
ROM:F17C ldy #PostRugTestBoot
ROM:F180 jmp RugPatternTest ; Does Rug Pattern test, jumps to address in Y when finished.
ROM:F180 ; Carry may be set if test failed.
NOTE at $F16A the loop to 'feed' the watch dog. I don't fully understand what is needed to keep the watch dog from barking, but I'd be willing to bet that this loop is completely unnecessary. Also, $F16C writes two bytes but only decrements its index by 1. I can see no reason why it wouldn't decrement by 2 here and accomplish the same thing. Not only is this test slow because it is using the CPU to write to video RAM, but it is slow because it is wasting time for no good reason.
Changes that I would make to this test: completely skip it :) The rug pattern test also tests video RAM so this test is redundant.