Star Rider's initial color 'test' is almost useless

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
ROM:F162 Fill9FFFto0WithY:                       ; CODE XREF: GoCmpCC07AndFWith9+15D j
ROM:F162                 ldb     #$15
ROM:F164                 lda     #8
ROM:F166
ROM:F166 WatchdogThink:                          ; CODE XREF: GoCmpCC07AndFWith9+155 j
ROM:F166                 stb     HW_Watchdog     ; this address has something to do with watchdog timer
ROM:F169                 deca
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.