Here's the "OS Version" code from HTMLGEN which I extracted into its own program. It does a test for the Tube, and then a test for BAS128. This is a bit of a bodge, but it's my best guess at how we can detect if BAS128 is running. So: if the operating system version reported by OSBYTE 0 is less than 6, meaning it's an 8-bit machine, and the Tube is off, as BAS128 doesn't support the Tube, and PAGE is &10000 at least, then we assume that we are running BAS128.
The way OSVer works is that it intercepts OSWRCH and saves the bytes which would be written to the screen into a memory block, doing *HELP, to then copy the OS message into a string. Bodgy, but it works, and it has a side effect, which I quite like, which is that if there is a second processor active, the version string it captures will in fact be the Tube OS message. Of course, that strictly speaking isn't the OS version, but I think it's better, as I can see - and you can see, by looking at the HTML source of one of these pages - what environment was used to generate the page.
This doesn't work without modification in BAS128, because vectors in the BBC Micro only point to a two-byte memory location. Pointing the OSWRCH vector to code assembled in BAS128's space, which is a 17-bit location, points to the wrong place and it doesn't work.
Instead, we have to use the extended vector facility. This involves pointing the relevant vector to the extended vector space, and then setting the extended vector itself to the code in BAS128. This facility is in fact for use with sideways ROMs, but as BAS128's memory is in sideways RAM, it can be used here.
The first step is to get the extended vector locations with OSBYTE &A8, shown at line 16170. This hasn't changed since OS 1.20, and is at &D9F even in MOS 3.50, but it's prudent to use the OS call to get the location rather than guessing.