Rick's b.log - 2020/04/13
It is the 29th of April 2024 You are 3.138.33.178, pleased to meet you!

Mower alternator

With this now found, I went out and started the mower to see what sort of charging was taking place.

It was a surprise how solid and stable the output actually is. Felicity gives out around 12.6V at idle, and 14.1V when doing 50kph.
The mower? The 'scope measured 12.16V when idle, rising to 12.37V (shown) when running at full speed. You can also see it is a pretty stable output as well. I was half expecting to see peaks from rectification, but at various timebases, nothing looked like a sine wave. Or anything other than a fairly flat line.
It is, mind you, a fairly weak output. The average charging voltage of a lead acid battery is between 2.15V~2.35V per cell, which for a typical six cell battery, equates to 12.9V~14.1V. A value often noted is 13.8V, which is a typical "standard charge" value, although smart chargers will vary the output depending on current.

Cough sneeze wheeze

Programming obscurities

Then, the joy of reading the keyboard. The OS offers OS_ReadC and OS_ReadLine, both of which do exactly as they suggest; but it is worth noting that both will block until something is available to be returned.
There are calls to ask "is a key pressed?" and "is this key pressed?", but now we're delving around in the mad maze of OS_Byte. Then we walk into the distinction that the call to return a keypress (within optional time limit (OS_Byte 129)) returns the character as an ASCII code in R1, however you have to check R2 to see if a character was actually returned as R1 will be junk otherwise (instead of doing something useful like returning 0). But the code to check if a specific key is pressed? Well now we're dealing with "internal key numbers". Clearly extra codes will be required to detect pressing non-character keys like Shift and Alt, but the thing is that the internal keys bear no obvious relationship to the characters or the keyboard.

There is actually an explanation for the bizarre internal keyboard arrangement. Consider that Tab is 96, Z is 97, Space is 98, and V is 99.
How is this possible? What do those keys have in common?

That diagram is from a PDF version of the BBC AUG. I don't know where my copy is, else I'd make a more readable scan. ☺

The penultimate line of the keyboard matrix (the one with all the diodes) reads Tab, Z, Space, V, B, M, and indeed B and M are the next numbers in the sequence.
Let's try the second line down. Q, 3, 4, 5 and for some bizarre reason F4. Looking at the key table, yup. Q is 16. 3-5 are 17, 18, and 19. And F4 is indeed 20.

But, wait, we can further break this down. The keyboard matrix consists of ten columns and eight rows. If we consider the columns to be four bits and the rows to be three, we can try something. The R key, is pretty much in the middle. It is a bridge between column 3 and row 4. In binary, %0011 for the column and %100 for the key, but this doesn't match the keypress (51, or %0110011).
If we try the next key up in the matrix, it's a T, key code 35. In binary, that is %0100011. This doesn't make sense though, the row values are going down instead of up. To put this to the test, the key below the R is F, which according to this logic ought to be %1000011, or 67 in decimal. Which is exactly what it is. I can only guess it is wired up back to front or something?

At any rate, the internal key numbers used by RISC OS directly relate to how the BBC Micro's keyboard matrix was arranged in hardware.

Your comments:

David Pilling, 18th April 2020, 02:34

I am surprised if all VDU calls do not by now have SWI equivalents - unless things like text output and clearing the screen are deprecated.  Keyboard - yeah mess. Recall Acorn having their own keyboard design at the start of the Archimedes - Gr key or something on right control.  I did the UniversalKeyboard module for Hearsay and OPro, not perfect but it shows the way. Simon Vantage bloke told me the thing was to replace keyboard buffer with something 1 word (4 bytes) wide.  As ever all the apps use the old code, so it has to go on.

J.G.Harston, 24th April 2020, 23:22

Yes there is. SWI 256+12.

Rick, 25th April 2020, 00:16

Yes, OS_WriteI+char will send the character to the VDU stream, as would OS_WriteC if it was in R0...  ...but however it is being done, we're still essentially spitting bytes to the VDU drivers.  There is OS_NewLine but there is no OS_ClearScreen. There is no obvious way to set VDU variables so positioning the text cursor is still VDU 31,x,y (and limited in that x and y are bytes so max out at 255).    As for the keyboard, isn't that sort of what DeepKeys does? At any rate, the keyboard handling strikes me as a rather icky mess that was cobbled together for Arthur and then just hack upon hack since then.