Didn't people complain how TOS 2.06 boots too slow, and asking to make it faster. Then I removed some tests there ...
Now you asking for more tests in TOS 1.xx
OK, I agree that it may be useful, especially this years when machines are very old.
But there is RAM test in all TOS versions, surely not very accurate, but it does it's job well in most cases. Some really better test would make boot much slower, with 10-20 secs only for RAM test.
Number of drives ? That's visible, isn't ? I mean that's easy to add, but don't see sense.
It's not well defined what is TOS RAM . I think that what is on that screen shot is not correct.
TOS RAM would be RAM what TOS uses for work - and it is in case of TOS 1.04: low RAM up to $611C at disk boot and AUTO start. But in reality, area until approx $A900 is what is reserved - I talked about that wasted space, and there is TOS fix by me to make it usable.
When Desktop starts, more RAM is allocated, and it's more when starting PRG than when starting TOS . Bad thing is that when you exit PRG, and start TOS, TOS will keep that extra RAM for self, and starting TOS then will be with less RAM for it. Bad memory management. Every restart of same type executable will start at 14 bytes higher address. That's minor bug, and don't see it fixed even in later TOS versions. So, those who talk how TOS-s RAM handling is very good and recommended instead own solutions have no clue (Joska for instance) .
At the end of RAM is screen usually. Whom it belongs ? To TOS or to user ?
That's irrelevant in most cases.
So, instead 'TOS.RAM' should show rather free RAM for user SW. And that would be total ST RAM (512KB) - screen + 768 wasted bytes at end (32768) - RAM used by TOS - latest varies, as is explained.
Diagnostic should be optional - triggered by some keypress in very early stage. But I'm really not in situation to deal with it this months. That could be pretty much time consuming, even if I can access some sources (what doubt) .