VirtualC64:

Hoxs64 1.0.9.9:

VICE 3.2:

Does only the green border mean that the test has passed ?
Yes. Most test programs compare their measured data with data that was recorded on a real C64. If both match, the border is changed to green. Otherwise, the border is turned red or (by some tests) turned into a flickering state.
Most tests are programmed in a really smart way. In their start-up code, they make sure that a certain event (e.g., a timer underflow or raster interrupt) occurs at a specific microcycle of a certain command under test. Most tests run the sequence a couple of times while shifting the target microcycle. Doing so, the timing behavior of an emulator can be verified on a very detailed basis.
Test timerA.prg is somewhat strange, though. It's Readme file says:
Note: the first number (and thus the entire pattern) seems to not only depend
on the type of mechanic used in the drive, but also in the state the
drive was before (preferably before running the test, first load the
directory so the head is on track 18, then powercycle the drive and run
the test)
I didn't look into the source code yet and cannot tell to what extend the drive mechanics influences this test. Neither can I tell if Hoxs64 is really failing on this test, because there seems to be more than one correct result. As VirtualC64 produces a result that differs from Hoxs64 and VICE, I expect my emulator wrong on this test, but I'll need to dig deeper into the assembler sources before I can tell more.
A strange thing happens to me on VICE with the test timerA.prg:
if I run the test with VICE just started the test works.
If instead I first run the test via1.prg (and wait for point B or C) then I run the drag'n'drop of the timerA.prg the result of the VICE is always this:

If I launch via1.prg (and wait for point B or C) then I do a SOFT RESET or HARD RESET then drag'n'drop of the timerA.prg the result of the VICE is always red ...it seems there is the need to re-initialize all the emulator to make the test works after via1.prg test.
Very interesting
I would like, then, to know the cause of this bug and know what is the solution to solve it.
I think this can be closed, because the test seems to rely heavily on the RAM init pattern (which is not unique among the various C64 revisions out in the wild).