...
The hard part is to create the images, which is done.
The easy part is to write it into an eprom. This is not an atari-specific task.
...

Surely, writing to EPROM is just a rutine job. But that 'creating the images' sounds not good. I think you meant coding changed TOS (or whatever OS). That may take months, years, and need to be tested much better than some user SW. Creating image is just reading the content of ROM in file

There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

I think a in-built diagnostic system would have been really useful. Things like proper RAM test like YAART built into ROM, also screen test pattern, audio test, blitter test etc.

Also like I said before...

1.jpg (22.26 KiB) Viewed 752 times

That patch has been one of the most useful things in development of boosters! Simply because if it outputs strange RAM values, I know something is wrong in a couple seconds after power up.. also if text freeze I know something wrong.. or bit planes get messed up I can tell quick. it also test keyboard as I can press space to continue.. That alone should be default in all TOS versions!

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) .

There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Well, I looked little about that lost piece of RAM after exiting some APP. Overall, code for RAM allocation and free is is pretty messy. When you start *.TOS it adds 14 bytes to basepage start address, where stays for me useless 'PATH= ..' . When start *.PRG, it adds much more, for AES workspace needed by such type of APP. About 13 KB in case of TOS 1.04 . And now comes interesting part: when APP is terminated, TOS frees only RAM segment from basepage of executed APP, not segment below it. The result is slow filling of RAM with useless crap after every APP run. And that after running once PRG, you will have 13 KB less RAM for TOS type APP. I don't think that this is bug, rather just some lazy programming - as we know already, they did not care too much for economic RAM usage. So, I think that it is not bad to restart machine sometimes when running lot of it ... I may try fixing it, but will be not easy to orient in all it ...

There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

More bad discovered - sorry, but it is good to know why and when some things happen, and to be prepared for ...
There is max total 14 partitions limit in TOS - letters C-P. So, something like R is disabled ? Not really, you can have such partition if driver SW mounts it, and when you click on it to open some bad things will happen - instead message like "Sorry, max 14 partitions C-P supported". Bad can be really bad, because what really happens - and I traced it over some hours - is overwriting some variables, because there is only workspace for 14 partitions. There is no real prevention. Sometimes it will show 'Out of Internal memory ... Use Folder100.prg ..." But that PRG will not solve this problem. And data loss may happen before it.
Drvbits system variable is 32 bits long. While TOS supports only 16 logical drives A-P . That's really stupid. Again seems as not well coordinated cowork.

So, I will add some protection in my next driver update + selection of active partitions in case of more than total 14 - when multiple medias are attached.
Will be not possible to open logical drive over P .

There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

And something really hard to understand and trace: storing year in IKBD chip, and how it is handled. I seen this problem 10 years ago, and made little program what overrides it somehow. That works not well in TOS 2.06, as I seen it today, probably because TOS code for reading IKBD date is little different.
So, writing of time, date to IKBD chip goes in packed BCD format. For year 80 it will write there $80 - what is for year 1980 actually. I find it very stupid, especially when date format is following: 7 bits for year, 0 means 1980 . So, it can go up to 1980+$7F = 2107 - in TOS self. With IKBD chip's BCD it could go to 1980+99 = 2079 . But no, they start it at BCD 80 ! so, year count is only 20 - 0 to 19. Or better only 15 - from 1985 to 1999 .
Why not writing there 0 for 1980 ? My fix SW does it. I need to see what is exact problem with it in TOS 2.06, and then will post here ...

There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.