Calls to check capabilities

[stevesims]

Ideally MOS should have API calls to allow for software to check for the capabilities of the machine on which it is running.

A Console8 for instance has joystick ports which may not be present on other Agon Light machines.

If software can interrogate the MOS about the capabilities of the machine then it can intelligently offer choices to the user.

[julianregel]

This sounds like a useful feature! In reading this, I was reminded of a couple of comments made by JGH over in Stardot (https://stardot.org.uk/forums/viewtopic.php?p=395021#p395021):

In general, you should not interrogate the OS to decide what facilities are present. You should test to see if the facilities themselves are present.

Wrong: IF NOT Master THEN no real-time-clock Correct: IF OSWORD 14 returns the real-time-clock THEN there is a real-time-clock

Wrong: IF NOT Master THEN no configuration memory Correct: IF OSBYTE 162 returns null value THEN no configuration memory

etc.

And more recently (https://stardot.org.uk/forums/viewtopic.php?p=400748#p400748):

The only way to deteramine if ANYTHING is present, is to attempt to use it and not what happens. You test for the presense of a real-time clock by trying to read the real-time clock, not by making assumptions based on other things. You test for the presense of a filing system by trying to select the filing system, not by making assumptions.

IMHO, this seems like a very sensible approach, especially given the open source nature of the Agon platform.

[stevesims]

Yeah - agreed, and the things you're suggesting here chime with my way of thinking.

In web development for a while devs were checking the "user agent" string of the browser and using that to work out browser capabilities. That approach is similar to the "IF NOT Master THEN ..." examples. When the "browser wars" were happening with web pages showing up saying "works best in Netscape", and developers starting to restrict features based on the user agent, the browser developers ended up just including loads of identifiers in the user agent string. This is why, for instance, Safari on iOS's user agent string starts with "Mozilla". Eventually best practice shifted to "test for presence of feature", and ideas of "progressive enhancement" have become more common.

For the Agon platform, we have the slight difficulty of the MOS and the VDP essentially being two different computers. There's a limited ability right now from MOS side to check whether the VDP will be able to successfully process a VDU stream, from the perspective of whether features are present. One such example could be a future Console8 VDP version with an embedded Lua interpreter - sending over Lua code to a Quark VDP and expecting it to run is unlikely to meet with success, indeed you're more likely to just the Lua code output onto the screen.