Sending the RISC OS boot messages to an I2C device

I’ve been building a rack-mounted A4000 from a spare motherboard I picked up, and finally got around to building the “version 2” soft power on/off board with LCD/VFD interface this weekend. At the moment it displays a static message, but can also display text sent over I2C.

I’ve written a module which listens for the “shutdown complete” service call and turns the power off – and this works great. Now I’d like to send the “RISC OS 4096K, Acorn ADFS” boot messages and the output from !Boot to the display — but I’m having trouble with this.

I figured the easy way was to use OS_Claim to claim the WrchV vector, then send an I2C byte with IIC_Control every time a character is printed to the screen – but when I call the IIC_Control SWI from the vector, the machine locks up (only the cursor moves).
Obviously I’ll only get the RISC OS messages if I put it in ROM, but for now just the Boot messages is fine.

Is there a way to do what I want?

Thanks
Phil

I’m not an expert, but… low level VDU stuff is a bit finicky, and it may not like working in such a manner.
Perhaps copy the VDU data into a ring buffer and have your IIC routine look at that on a periodic callback “when it’s safe”?

@ Phil

Just a thought, have you tried to buffer the characters (instead of send them as soon as you receive them) and then sending them at regular intervals (or later time), maybe via call backs or setting up an OS event to trigger periodically (using OS_Byte or similar) and check if there are characters in the buffer to send over I2C?

Basically avoid doing the call from the vector.

Just my 0.2c

Just a thought

🤷 Am I talking to myself again? 😉

I’d suggest that summats wrong with IIC_Control if it can’t be called from WrchV. Double-check that vector code!

🤷 Am I talking to myself again? 😉

Oh you should see when I am coding on RO lol ROOL may have removed the swearing from the sources, but here the old habits are still going strong! XD

Double-check that vector code!

You did remember to stash R14 around the call to IIC_Control, right? You’re in SVC mode… ;)

Addressing all of these …

Just a thought, have you tried to buffer the characters (instead of send them as soon as you receive them) and then sending them at regular intervals (or later time), maybe via call backs or setting up an OS event to trigger periodically (using OS_Byte or similar) and check if there are characters in the buffer to send over I2C?

That was my first idea, but I figured I could send from the vector to start with, then add the buffering later.

I’d suggest that summats wrong with IIC_Control if it can’t be called from WrchV. Double-check that vector code!

I’m pretty sure it’s right:

.wrchHandler:
  STMFD R13!, {R0-R12,R14}  ; save all the things
  LDR R12. [R12]  ; Get module workspace
  STRB R0, [R12, #w_txbuf] ; save incoming byte to the w_txbuf
  MOV R0, #iicAddrWr
  LDR R1, [R12, #w_txbuf] ; get buffer address
  MOV RT, #1     ; only one byte to send
  SWI "XIIC_Control"
  LDMFD R13!, {R0-R12, PC} ; restore regs, but put R14/LR into PC to return

You did remember to stash R14 around the call to IIC_Control, right? You’re in SVC mode… ;)

Saved it right at the start of the function!

add the buffering later.

Why buffer at all?

LDR R1, [R12, #w_txbuf] ; get buffer address

You meant ADD R1, R12, #w_txbuf surely?

I would paranoically clear V after the XIIC_Control too.

Why buffer at all?

I2C packet overheads. Each packet needs a start sequence, addressing byte, and stop sequence. For a single-byte transfer, that’s slightly under 50% efficiency – which improves the more bytes you send.

Also buffering the data from WrchV means it’ll return faster, and the I2C transaction can be done somewhere less time critical (e.g. some kind of timer tick vector)

You meant ADD R1, R12, #w_txbuf surely?

I tried that, and it earned me a “Bad immediate constant” error … and now I’ve just realised why that doesn’t work. I borrowed a chunk of code to allocate the workspace from a post by Steve Fryatt (https://www.riscosopen.org/forum/forums/11/topics/16298?page=3#posts-119636) and it’s got a bug which makes it return wrong addresses if you allocate a 4-byte block, then a 64-byte one like I did.

I was going to post a bit about the wrapper code from Chapter 10 “Interrupts” under “Calling SWIs” (http://www.riscos.com/support/developers/prm/interrupts.html) but it seems that’s unnecessary.

Now I’m getting the text sent to the display perfectly at the F12 prompt, but when the WIMP is running it prints absolute heaps of garbage when I interact with the desktop. Ideally I need to filter out the noise from the WIMP and only display what’s printed at the star-prompt.

… It also slows the desktop to an absolute crawl, but that’s not a huge surprise given how much noise it’s printing when I move windows around.

it prints absolute heaps of garbage when I interact with the desktop

Yup, it’s amazing how much UI stuff goes through WrchV. It turns up in Spool files as well.

Ideally I need to filter out the noise from the WIMP and only display what’s printed at the star-prompt.

What comes to mind is to hammer OS_Byte ¹. Specifically OS_Byte 117, which will return the VDU status flags in R1, and if bit 5 is set then you’re in VDU 5 mode. In that case, probably best to just discard the data as I can’t imagine stuff printed in VDU5 mode would make much sense.

Obviously this won’t work with TaskWindows (but then mine use ZapRedraw so that isn’t even an issue).

¹ Even that will be faster than spewing unwanted junk through IIC.

how much UI stuff goes through WrchV

If actually gets worse if you sit on WrchV! OS_Plot has to send the VDU sequence, etc.

I thought I had it working, but it seems like it works intermittently. Sometimes it crashes, sometimes it runs and works. I can’t figure out the pattern.

Would anyone mind taking a look at this and seeing if any errors stand out?

I’m happy for suggestions for a better way to do this — I started implementing buffering (there are some placeholders for this) but stopped when I couldn’t think of somewhere to print out the contents of the buffer.

   10REM Control module for Arduino power control module
   20REM Phil Pemberton <<a href="mailto:philpem@philpem.me.uk">philpem@philpem.me.uk</a>>
   30
   40ON ERROR PRINT REPORT$+" at "+STR$(ERL):END
   50
   60REM RISC OS services and SWIs
   70Service_ShutdownComplete = &80
   80OSModule_Claim           = 6
   90OSModule_Free            = 7
  100WrchV                    = &03
  110
  120REM CPU flags
  130SVC_Mode                 = 3
  131V_bit                    = (1<<28)
  140
  150REM I2C address
  160iicAddrWr                = &60
  170iicAddrRd                = &61
  180
  190REM Allocate workspace
  200workspace_size% = 0      :REM updated as we go
  210txbufsz    = 64          :REM I2C transmit buffer size
  220w_txbufpos = FNworkspace(workspace_size%, 4)  :REM txbuffer bytes used
  230w_txbuf    = FNworkspace(workspace_size%, txbufsz)
  240w_vdu5     = FNworkspace(workspace_size%, 4)  :REM VDU5 flag
  250
  260PRINT "Workspace size "; workspace_size%
  270REM END
  280
  290REM begin assembly...
  300DIM mcode% 2048          :REM Reserve memory for assembling code
  310
  320FOR pass%=4 TO 7 STEP 3  :REM Two pass assembly
  330P%=0                     :REM offset zero - all offsets from start off module
  340O%=mcode%
  350[OPT pass%
  360
  370; Module header
  380  EQUD     0             ; Application start code
  390  EQUD     init%         ; Initialisation
  400  EQUD     fini%         ; Finalisation
  410  EQUD     svcc%         ; Service call start
  420  EQUD     title%        ; Module title string
  430  EQUD     help%         ; Module help string
  440  EQUD     0             ; Command table offset
  450  EQUD     0             ; SWI Chunk base number
  460  EQUD     0             ; SWI handler offset
  470  EQUD     0             ; Unaligned offset to SWI name table
  480  EQUD     0             ; Offset to Messages file name
  490  EQUD     0             ; Module flags
  500
  510; Module title string
  520.title%
  530  EQUS "PowerMod"
  540  EQUB 0  ; null terminator
  550  ALIGN
  560
  570; Module help string
  580.help%
  590  EQUS "PowerMod"+CHR$(9)+"0.01 ("+MID$(TIME$,5,11)+") © Phil Pemberton"
  600  EQUB 0  ; null terminator
  610  ALIGN
  620
  630
  640;
  650; Initialsation routine
  660;
  670; Entry
  680;   R0   Pointer to environment string (init parameters passed to module)
  690;   R11  I/O base or instantiation nuber
  700;   R12  Private word
  710;   R13  SVC stack
  720;   R14  Return address.
  730; Exit
  740;   R0-R6,R12,R14  can be corrupted
  750;   R7-11 and R13  must be preserved.
  760;   V set if R0 is an error block
  770;
  780.init%
  790  STMFD  R13!,{R7-R11,R14}
  800  
  810  ; Claim some workspace
  820  MOV    R0, #OSModule_Claim
  830  MOV    R3, #workspace_size%
  840  SWI    "XOS_Module"
  850  BVS    init_exit
  860  
  870  ; Save the workspace
  880  STR    R2, [R12]
  890  
  900  ; Make R12 point to the workspace
  910  MOV    R12, R2
  920  
  930  ; Do the rest of the initialisation
  940  
  950  ; Clear VDU5 flag
  960  MOV    R0, #0
  970  STR    R0, [R12, #w_vdu5]
  980  
  990  ; Claim the WrchV vector
 1000  MOV    R0, #WrchV
 1010  ADR    R1, wrchHandler
 1020  MOV    R2, R12
 1030  SWI    "OS_Claim"
 1040  
 1050.init_exit
 1060  LDMFD  R13!,{R7-R11,PC}
 1070
 1080;
 1090; Finalisation routine
 1100;
 1110; Entry
 1120;   R10  Fatality indication -- is 1 as finalisation is always fatal
 1130;   R11  Instantiation number
 1140;   R12  Private word
 1150;   R13  SVC stack
 1160;   R14  Return address
 1170; Exit
 1180;   R0-R6,R12,R14  can be corrupted
 1190;   R7-11 and R13  must be preserved.
 1200;   V set if unable to quit and R0 is an error block
 1210;
 1220.fini%
 1230  STMFD  R13!,{R7-R11,R14}
 1240  
 1250  ; Get our workspace pointer into R12
 1260  LDR    R12, [R12]
 1270  
 1280  ; Do the other finalization...
 1290  
 1300  ; Release the WrchV vector
 1310  MOV    R0, #WrchV
 1320  ADR    R1, wrchHandler
 1330  MOV    R2, R12
 1340  SWI    "XOS_Release"
 1350  
 1360  ; Free our workspace
 1370  MOV    R0, #7
 1380  MOV    R2, R12
 1390  SWI    "XOS_Module"
 1400.fini_exit  
 1410  LDMFD  R13!,{R7-R11,PC}
 1420
 1430;
 1440; Service call handler
 1450;
 1460; Entry
 1470;   R1   service number
 1480;   R12  private word
 1490;   R13  a full, descending stack
 1500; Exit
 1510;   R1 = 0 = service claimed
 1520;   R0, R2-R8  may be altered to pass back a result, depending on the call
 1530;   Registers must not be corrupted unless they are returning values!
 1540;
 1550.svcc%
 1560  TEQ    R1, #Service_ShutdownComplete
 1570  ; TEQNE R1, #OtherServiceWeAreInterestedIn
 1580  MOVNES PC, R14           ; Reject services we don't care about ASAP
 1590
 1600  ; start of service handling
 1610  STMFD  R13!, {R0-R12,R14}  ; Save all the things
 1620  LDR    R12, [R12]      ; get module workspace from private word
 1630
 1640  ; code goes here
 1650  TEQ    R1, #Service_ShutdownComplete
 1660  BEQ    svcc_ShutdownComplete
 1670  B      svcc_done
 1680
 1690.svcc_ShutdownComplete
 1700  MOV    R0, #iicAddrWr     ; IIC write address
 1710  ADR    R1, iicShutdownData  ; Data block
 1720  MOV    R2, #8             ; 8 byte magic knock
 1730  SWI    "XIIC_Control"
 1740
 1750.svcc_done
 1760  LDMFD  R13!, {R0-R12,PC}  ; Restore all the things (and return too!)
 1770
 1780; Shutdown command string
 1790.iicShutdownData
 1800  EQUS "ShUtDoWn"
 1810  ALIGN
 1820
 1830;
 1840; WrchV vector handler
 1850;
 1860; In:
 1870;   R0 = Character to write to active output streams
 1880; Out:
 1890;   R0 preserved
 1900;
 1910.wrchHandler
 1920  STMFD  R13!, {R0-R12, R14}  ; Save registers
 1930  
 1940  LDR    R12, [R12]           ; Get module workspace
 1950
 1951;  LDR    R1, [R12, #w_vdu5]   ; Get VDU5 flag
 1952
 1960;  CMP    R0, #5               ; VDU5?
 1970;  MOVEQ  R1, #1               ; Set VDU5 flag
 2000;  CMP    R0, #4               ; VDU4?
 2010;  MOVEQ  R1, #0               ; Yes, clear VDU5 flag
 2011  
 2020;  STR    R1, [R12, #w_vdu5]   ; Save updated VDU5 flag
 2021  
 2022;  CMP    R1, #1               ; VDU5 flag set?
 2023;  BEQ    wrchExit            ; Don't print
 2050  
 2110.wrchPrint:  
 2120  STRB   R0, [R12, #w_txbuf]  ; Save character in I2C buffer
 2130  MOV    R0, #iicAddrWr
 2140  ADD    R1, R12, #w_txbuf    ; get address of block
 2150  MOV    R2, #1               ; number of bytes to send
 2160  SWI    "XIIC_Control"
 2161  BICS   PC, PC, #V_bit     ; Clear V (error) flag
 2170
 2180.wrchExit:
 2190  LDMFD  R13!, {R0-R12, PC}   ; Restore registers and return
 2200
 2210
 2220]
 2230NEXT
 2240SYS "OS_File", 10, "IDEFS::4.$.Develop.IICPower.PowerMod",&FFA,,mcode%,O%
 2250END
 2260
 2270
 2280REM Function to allocate workspace
 2290DEF FNworkspace(RETURN size%, dim%)
 2300size% += dim%
 2310= size%-dim%

Also, DarkLord on the Stardot Discord has provided a better implementation of FNworkspace which aligns to 4 bytes:

  DEF FNworkspace(RETURN ws%, size%)
    ws% = (ws% + 3) AND NOT 3 : REM Align to 4 bytes
    LOCAL oldws%: oldws% = ws%
    ws% += size%
  = oldws%

  870  ; Save the workspace
  880  STR    R2, [R12]
  890  
  900  ; Make R12 point to the workspace
  910  MOV    R12, R2

Aren’t these two back to front?

You will of course get R0=4 and R0=5 in the middle of other VDU sequences! If you’re going to do it this way, you’d have to have a table of VDU control sequence lengths so you can skip that number of subsequent values.

Aren’t these two back to front?

At a glance, that looks OK; the allocated address gets stored in the private word, then r12 becomes the wsptr.

in the middle of other VDU sequences!

That’s why I said to spam OS_Byte 117 to read the VDU5 status, it saves having to try to make assumptions about what passes through WrchV.

I’ve changed the code to hit OS_Byte 117 … and it seems like that crashes it too!

After bisecting it, I found that ending the vector with:

BICS PC, PC, #V_bit
LDMFD R13!, {R0-R12, PC}

crashes the machine. The fix is to change it to:

LDMFD R13!, {R0-R12, R14}
BICS PC, R14, #V_bit

Which restores LR then returns, clearing the V-bit as part of the return. Still two instructions but no crash.

Doing that and adding code to check OS_Byte 117 seems to be doing mostly what I need, but for two issues:

• There are still some VDU commands in the output stream which need filtering out (mostly when moving windows or exiting ShellCLI). They mostly seem to have bit 7 set.
• It’s outputting everything from a ShellCLI or Taskwindow to the display… which slows things down a lot.

I think I need to have a ponder about how to buffer the incoming characters and send them in larger blocks. The obvious answer is to do the send in WrchV, but that just means it’ll delay at the end of the line, or whenever the buffer fills up. I’d rather do it somewhere less time-critical.

Sorry I didn’t notice this earlier. There are many problems.

• As of RISC OS 3.8 the service handler needs a service table
• You’re dereferencing your workspace twice – before the OS_Claim and then during the Claimant
• As Stuart has pointed out, the entire plan is wrong – not only will “&05” appear during VDU sequences, R0 is not guaranteed to be a byte
• VDU5 is part of the VDU Status which can be read at any point via OS_Byte,117

If you want to filter out VDU sequences (OS_Plots, graphics and text windows, cursor movements, clear screens, beeps etc) then you need to do a bit more work. It’s not just the VDU5 state that you need to look at – crucially you need to check the VDUQueueDepth read via OS_Byte,218,0,-1.

So read VDU Status and if that says VDU4 (if that’s what you want) then read the VDUQueueDepth and if that’s zero you can redirect your byte if it’s a printable (and maybe LF) but you’ll probably also want to map VDU9 to space and perhaps even be clever about 8 and 127 if you’re buffering.

Finally, WrchV doesn’t need flags preserved, so to cope with a SWI returning V just do SUBVSS R1,R1,R1 or similar – WrchV doesn’t care what the other flags are. [Note that this is in contrast to VDUXV where it is vitally important not to return with C set!]

So you’ll want to do something more like:

WrchVHandler
 STMFD   R13!,{R0-R2,R14}
 AND     R0, R0, #&FF     ; we shall not entertain UTF-16 today
 TEQ     R0, #9
 MOVEQ   R0, #32
 TEQ     R0, #8           ; } obviously only if your device supports
 MOVEQ   R0, #127         ; } delete, else map 127 to 8
 CMP     R0, #10
 CMPNE   R0, #32
 LDMCCFD R13!,{R0-R2,PC}  ; even if it is a chr, it's a ctrl
 ;
 MOV     R0, #117         ; read VDUStatus
 MOV     R2, #-1
 SWI     XOS_Byte
 ADDVSS  R1, R2, #0       ; unlikely to error, but clear V
 ANDS    R1, R1, #&A0     ; not VDU4 (or error)
 LDMNEFD R13!,{R0-R2,PC}
 ;
 MOV     R0, #218         ; read VDUQueueDepth
 SWI     XOS_Byte         ; note R1=0 and R2=-1 here
 MOVVS   R1, #1           ; unlikely to error, but...
 CMP     R1, #0           ; clears V
 LDMNEFD R13!,{R0-R2,PC}  ; mid-sequence (or error)
 ;
 MOV     R0, #iicAddrWr
 MOV     R1, R13          ; the byte’s already on the stack
 MOV     R2, #1
 SWI     "XIIC_Control"
 CMPVS   R0, R0           ; clear V
 LDMFD   R13!,{R0-R2,PC}

Which you’ll notice uses no workspace and is CPU agnostic. The Knuthian Defence applies – proceed with caution.

[Yes, UTF-16 is a RISC OS Alphabet. Yes it means R0 isn’t a byte in WrchV. Yes there’s a way to cope in general. I’ll write that up elsewhere.]

You may be thinking that this is a lot of stuff to do to work out if you should be doing something with WrchV, and you’d be right. eg all of these have to do this kind of thing:

It’s almost like VDUStatus and VDUQueueDepth should have been part of the WrchV API!
<slaps ancient Acorn around the muttonchops>

Those of you with sharp eyes will note that some of those modules have set their R12 sensibly. RO5 broke the API for reading the MOSVars address (fix module on my site), but the VDU Workspace must be inferred from what you are allowed to read – an exercise for the reader.

To cope with Alphabets that aren’t 8bit, use Service_International,332:

I wrote about the complexities of the ill-defined WrchV in the ReadMe for my ArthurASCII module:

Nobody knows what the API of WrchV is. They may think they do, but they do not, for it has never been properly defined. As a result, every version of RISC OS shipped since RO3 has contained two implementations of WriteC that not only do not agree, one explodes with a Data Abort when given a character code the other is happy to display.

Having said that, I advise against the use of UTF-16 as an Alphabet because it has significant implications for many APIs, not least OS_ReadC and ReadLineV. Having OS_ASCII recognise CR correctly when in UTF-16 is therefore an exercise in errant pedantry – I know you would expect no less.

Out-of-band codes such as -1 MUST NOT be special-cased, as there may one day be a fully 32bit Alphabet for which this is a valid codepoint.

Good example – the Wimp and how it deals with function keys and the way that UTF-8 is sent as multiple keypresses instead of just a word-sized value.

introduced an Alphabet Change Service (&43,&10C) to push Alphabet (and Fallback) changes to interested modules

Thank <Deity$Name> that something now broadcasts a Service Call for this now.

Good example – the Wimp and how it deals with function keys

A better example than you think, because originally Wimp_ProcessKey accepted 32b keypress codes, as you’d expect. DeepKeys was written for that version of WindowManager and the intention was that we could coin virtual keycodes for things like the “Scan” button on a desktop scanner or multifunction printer. Unfortunately this was broken in RO4.37 (and 5) where to save a few bytes the codes are stored as one or two bytes. I view that as a regression and a bug.

the way that UTF-8 is sent as multiple keypresses instead of just a word-sized value.

If it were a word-sized value it wouldn’t be UTF-8. It would just be Unicode. Which is what it ought to be for Alphabet 118 “Unicode” (unofficial – I’m just not cruel enough it appears). So you may find it awkward, but it’s actually correct that a single “character” be delivered over multiple Wimp_Poll events, eg ‘🏴󠁧󠁢󠁥󠁮󠁧󠁿’ is 28 events, and ‘👩🏼‍👩🏼‍👧🏼‍👦🏼’ is 41 in UTF-8, and they’d still be 7 and 11 events respectively if delivered as 21b Unicode (whether they display as single “characters” depends on font support in your device).

<Deity$Name>

Just call me nemo.

BTW, the biggest problem with dealing with 41 (or whatever) KeyPress events isn’t the stitching the bytes together, but that the entire sequence is probably atomic (as in the above cases), so one should either insert all of it or none of it – only inserting the first n bytes that fit in the writeable (for example) will result in broken sequences and, if one’s display system supports Fallback, unintended characters (mojibake).

This is why I coined the StyledText message, which carries not only a text fragment but also a “Font Name” (in the API sense – it doesn’t have to contain a Typeface name). Here’s the Emoji Panel using StyledText to deliver an emoji to an application that implements the message to ensure the content is treated atomically.

Then if there isn’t room (or the encoding is inappropriate, whatever) it can complain with a tooltip:

If StyledText isn’t supported, the EmojiPanel has to guess whether the sequence will fit, which isn’t so good.

[StyledText is 25 years old, but I wish I’d put the fontname first — it can’t be used with UTF-16 for example because of the termination of the first string. D’oh. Not that “\EUTF16” does anything sensible anyway thanks to the frankly insane behaviour for “\EUTF8”, but that’s another story]