Coding Meetups - social event, tutorials and videos

Following the first developer meetup in November last year, several videos were created and shown at the previous meetup on 21st January; they centred around Git.

I thought they were helpful to anyone interested in using Git for programming on our platform.

Here’s a link to them, and I also made different videos; follow the link.

We aim to show some more videos for the next meetup scheduled for 4th March and then discuss the next steps.

The aim is to provide helpful tutorials for anyone interested in coding on RISC OS. So here’s a snapshot of what we discussed at the last meetup. For further details, see the link.

We thought it would be helpful to create a set of examples that single task, but do the following:-

• Turn the keyboard caps lock on and off (for fun, it could be any keyboard light)
• As an extension, turn an LED on and off on the GPIO (or equivalent)
• Write a message to the screen

If anyone has already done this in any language available on our platform or if you’ve created some videos or a tutorial, let us know below.

Come and join the conversation here, on Git Hub, or at the next meetup.

This ought¹ to flash the CapsLock LED on any RO from Arthur onwards:

REP.SYS6,202,16,255:SYS6,118:U.INKEY25>-1

¹ Not emulators though, sadly

Yep, That works on a Pi 4.

Leaves CapsLock undefined when escape pressed

And if you are in an emulator, you have to make do with virtual LEDs

Thank you, Nemo, for a good start. And thank you Bryan for your input and observation.

Nemo, I appreciate the second example as well. What do those things mean? I guess some of them might be obvious looking at the Basic manual. How did you construct the line?

I assume that we can’t restore the caps key functionality, which is why you provided the second traffic light example. I suppose a reboot would be how you solve Bryan’s observation.

What do those things mean?

Right… <gets soap box out and steps on it>

This is a rich thirty-five year old operating system. Whatever you want to do, there’s probably already three APIs for doing it. There’s buffering APIs, there’s DeviceFS, there’s ADVAL even.

But for the keyboard lights, the obvious thing is the Keyboard Status, which holds the state of the modifiers, the Lock keys and a couple of bits (literally) of keyboard driver state. It can be read and written using OS_Byte 202.

However, for boring technical reasons, changing the state doesn’t magically cause the keyboard LEDs to update. Instead you must call OS_Byte 118 to cause the LEDs to reflect the Status.

The Keyboard Status being one of the venerable MOSvars (that date back to the BBC Micro, and which ROOL broke in the high-vector build by forgetting to update the API that tells you where they are in memory – see MOSVarFix ) are read or written using an EOR/AND pair, which makes it easy to set, clear or toggle bits.

So, that one-liner toggles the CapsLock state, tells the LEDs to update, then waits ¼ second for a key, and then repeats.

The “CapsLock undefined” comment is unhelpful. It merely means that when you press Escape, the CapsLock may be on, or off. Well, yeah.

reboot

You could do that.

Or you could just press the CapsLock key again.

Whichever is more convenient.

traffic light

The LEDs module merely represents the three keyboard LEDs on the iconbar. And in less than 2000 bytes including the sprites. They’re useful in an emulator because though changes to the Host’s keyboard state is reflected within RISC OS, changing the state in RISC OS does not (at least in VirtualRPC) cause the emulator to change the Host’s state. This means that changing state in RISC OS has no effect on the actual keyboard LEDs.

I like these here, I think I’m going to keep them. But I want them to not scroll with the iconbar but always be visible. Like the Windows ‘tray’. Hmmm.

I suppose this might also be useful to people whose funky keyboards don’t have LEDs. Should I release it?

Whichever is more convenient.

monitor += coffee

Should I release it?

Of course!

monitor += coffee

Tea, in my case, but… you can just imagine a completely deadpan delivery, can’t you?

Hi All,

you were looking for examples of flashing capslock lights.
This is my ugly attempt to flash capslock in Armbob.

// an armbob app to switch on caps lock

r=newvector(8);
do { flashonce() ;
}
until ( true ) ;
} // end of main

flashonce(){
pokecaps(16) ;
wait(50);
pokecaps(8);
wait(50);
} // end of flashonce

pokecaps( reg2){
r[⁰]=202;
r[¹]=16 ;
r[²]=reg2 ;
swi(“OS_Byte”,r);
r[⁰]=118;
swi(“OS_Byte”,r);
} // end of pokecaps

wait( howlong ){
local starttime , endtime ;
starttime=time();
endtime=starttime+(howlong) ;
do {} until
(time()>endtime) ;
} // end of wait

It does what it says on the tin, but sometimes it takes over the machine, whilst at other times it happily multitasks, depending on how it is run. Eventually I will figure out why. It will always stop with Ctrl_Pause-break. This is on aPi4B in a fourtress housing from riscosbits. Also, I have had to mess with the code to fit in with the forum markup. Sorry.

Also, I have had to mess with the code to fit in with the forum markup.

Just put the code into a code block, and you don’t need to do any messing with it. Prefix the first line with bc..<space> to open a multiline Block-Code, then prefix the first line of the following paragraph with p.<space> to bring the block to the end. For example, if I do the following with your code in Textile…

bc.. // an armbob app to switch on caps lock

main(){
  r=newvector(8);

  do { flashonce() ;
  }
  until ( true ) ;
} // end of main

flashonce(){
  pokecaps(16) ;
  wait(50);
  pokecaps(8);
  wait(50);
} // end of flashonce

pokecaps( reg2 ){
  r[0]=202;
  r[1]=16 ;
  r[2]=reg2 ;
  swi("OS_Byte",r);
  r[0]=118;
  swi("OS_Byte",r);
} // end of pokecaps

// like BASIC wait, also in centiseconds

wait( howlong ){
  local starttime , endtime ;
  starttime=time();
  endtime=starttime+(howlong) ;
  do {} until
  (time()>endtime) ;
} // end of wait

p. It does what it says on the tin,

…then it should come out something like this:

// an armbob app to switch on caps lock

main(){
  r=newvector(8);

  do { flashonce() ;
  }
  until ( true ) ;
} // end of main

flashonce(){
  pokecaps(16) ;
  wait(50);
  pokecaps(8);
  wait(50);
} // end of flashonce

pokecaps( reg2 ){
  r[0]=202;
  r[1]=16 ;
  r[2]=reg2 ;
  swi("OS_Byte",r);
  r[0]=118;
  swi("OS_Byte",r);
} // end of pokecaps

// like BASIC wait, also in centiseconds

wait( howlong ){
  local starttime , endtime ;
  starttime=time();
  endtime=starttime+(howlong) ;
  do {} until
  (time()>endtime) ;
} // end of wait

It does what it says on the tin,

PS. I’ve no idea what your spacing or indents should have been, so I’ve improvised a bit.

// an armbob app to switch on caps lock

It is great to see armbob being used. Is this a first on the ROOL forum?

Colin, you’ve misunderstood the parameters for OS_Byte 202 (in that I’m sure you’re not intending to do what that code actually does).

[Additional nonsense removed due to reading the wrong bit of code]

Thanks for the feedback all.

Steve – the formatting info is great. I shall use it in future, thanks.

Gavin – I like the clean syntax of armbob, and the fact that it does not need compiling suits me at my present low level of riscos coding skill. I find the BASIC too shouty with all those upper case letters!

Nemo – I am sure you are right about OS_Byte 202. I just saw the light flashing on and off, which is what I thought I wanted to achieve. Bearing in mind that I am not a career IT person, and I have only recently started to use riscos, can you explain what the problem is? I am very willing to learn.

202 is one of the MOSVars, which are read & written using a pair of parameters (R1 and R2 on the ARM, X and Y on the 6502). The first is an EOR mask (which is good for toggling) and the second is an AND (which is good for clearing), and combined they can set (AND clears, EOR toggles the 0 to 1).

So the new value is (old AND R2) EOR R1. Hence to toggle a single bit, you’d put 255 (or -1) in R2 (to keep all the bits), and the bit to toggle in R1 (to EOR it).

The MOSvars are defined to be stored as bytes (and can be accessed as memory), so despite “OS_Byte” being a 32bit API, there is not usually any point worrying about bits 8-31 for those calls (it is possible for a module to extend them, but that would be very unusual).

Nemo – thanks for the clarification. I will study and experiment to fully understand it.

The logic I used for setting and clearing CapsLock was based on this table relating to icon flags using lines 3 and 4, but toggling is clearly a more elegent solution in this situation.

Clear 	EOR 	Meaning
0 	0 	Preserve the bit’s status
0 	1 	Toggle the bit’s state
1 	0 	Clear the bit
1 	1 	Set the bit 

Colin

this table

The table is wrong, or at least misleading. Let’s be clearer:

R1   R2   Effect
EOR  AND  on a bit
---------------------
0    0    clear
0    1    preserve
1    0    set
1    1    toggle

In your code above, the pokecaps() function takes a parameter that you use as R2. You only want to toggle one bit, and the rest you must preserve, so R2 must be 255 in both cases. The pokecaps(16) and pokecaps(8) are misguided – reg2 should be 255 for both.

pokecaps(16) does toggle CapsLock, but clears all other bits. pokecaps(8) would preserve the Shift state and set the CapsLock while clearing all other bits, but the previous call had cleared the Shift state anyway.

HTH.

The table is wrong, or at least misleading.

Not really. The table is perfectly correct and very clear… but – as Colin hinted in his post – it is for Wimp_SetIconState and has no bearing on OS_Byte. So it’s a correct table, but being used in an incorrect context.

For completeness, Wimp_SetIconState does

new_value% = (old_value% AND (NOT R1!12)) EOR R1!8

while the OS_Bytes in question do

new_value% = (old_value% AND R2) EOR R1

Steve suggested

Not really.

The table is wrong in that it is the wrong table.

The table is misleading in that it has misled Colin to the wrong code.

it’s a correct table, but being used in an incorrect context

Colin sitting politely while Steve explains tables to nemo

Colin sitting politely while Steve explains tables to nemo

Oh, all the right numbers, just not necessarily in the right order…

I think I understand now, Nemo’s a purist ;)

Anyone know where I left my coat?

should I release it?

Of course!

The LEDs module is now all nicely allocated and published and all that.

Thank you, Nemo, for making the LED module available. I look forward to giving it a whirl at some point. Your humour and the help you are providing here are appreciated :)

I meant to include everyone else who’s assisting and contributing – thank you.

I very nearly added the cassette motor LED too, but I’m certain mine’s the only RISC OS machine that has implemented that in 35 years…

As a matter of interest – how do you contact to the the tape recorder?

I wonder if anyone ever implemented Filing System number 1 or 2? I implemented DFS, but didn’t have a reason to implement the CFS too. However, the cassette motor API is present and correct.

There was a well-known BBC Micro modification which I think was invented at Oundle School (could be wrong) that cut a wire on the keyboard PCB and connected it to the cassette relay instead. Which meant you could switch the Break key off by switching the motor on. I did that modification to my Beeb.

One could emulate the same behaviour in RISC OS. But to save people from pressing Break at the wrong time I wrote the BreakAche module which does make the same noise as a BBC Micro.

So, no. There’s no tape recorder. But I can type this:

*MOTOR 1
Motor 00000001
*