Moving software 26 bit to 32 bit

Start here.

References:
http://www.riscos.com/support/developers/prm/armhw.html
https://heyrick.eu/assembler/32bit.html
https://heyrick.eu/assembler/modcode.html

Tools:
ARMalyser (direct link)
http://www.mw-software.com/software/32bitlib/32bitlib.html

That would be helpful- I know of someone with a module who would like to get it working on newer hardware.

Does anyone fancy coming to the next fireside chat on Saturday, 12th October, to help? I’m appealing to the people in this thread and the wider community.

I think this would also make an interesting topic for a talk.

Is it possible to let us know where to find the module now? Then anyone really interested can have a look, perhaps try things, and be better prepared for the chat.

Thank you, Dave. I reached out to them and now have a copy of the file (zipped); I don’t feel comfortable sharing it on the forum as I don’t know enough about the program. I will share the program if anyone would like to look at it. Contacting me can be done in several ways here <- bottom of the linked article.

I’ve posted to the RISC OS Chat thread on ChatCube. I still don’t know how to contact you to get hold of the module, Andrew. I’m on Telegram and WhatsApp but not Twitter or Mastodon. Except of course we’re both on ChatCube.

Dave, thank you. I’ve dropped the zip file into ChatCube. If that doesn’t work, I still have your email address.

Edit: Email sent with more information, and the zip file.

Rick’s modcode page doesn’t mention the module service call table, or was this only a ROL thing?

I suspect it might have first been in the unreleased 3.8? This stuff is in the code as “Chocolate” options, which were implemented for Ursula, which IIRC was exactly that.

Meaning its first public outing would have been RISC OS 4.
At any rate, it didn’t exist when that ancient stuff was first written.

For anyone interested: there are a couple of projects going on live on ChatCube. Feel free to join in! Not only are we interested in updating modules from 26 to 32 bit, we are also looking at translating from assembly language to C.

Last night I completed the first stage of converting a module to C. No source was available for the module, but it was already 32 bit compatible, and Armalyser generated good source code that could be assembled. The new module has a CMHG header and C main part, and calls the asm routines to implement the star commands. From there it’s just “handle cranking” to convert each one to fully C.

Yes, this has been an easy one, but it’s best to start with an easy one to prove that the method is workable.

Interesting – how did you plan to convert 32bit ARM code into ‘C’?

Work out what it does, then write a replacement.

For bigger tasks, it should be possible to replace a function and still call the lower level functions – replacing one level at a time. But this remains to be tried.

@Dave
What library are you using?
In the MouseMod example, the only code that would need to be transcribed I think, is the insertion into the mouse buffer. The other functions are only used to decode the parameters of the *command.

I’m not done yet…and I need to work on the comments…

In any case, it’s a good opportunity for me to review the coding of the modules.

Note: !Sid gives the name of the functions directly and the use of DDE macros allows you to practically obtain the text to insert into the CmgHdr.

What library are you using?

Other than the Shared C Library, none.

MouseCmd is a bit too simple really. It doesn’t need an assembler file as a start point. But the whole reason, to me, for doing it is to demonstrate the feasibility of one way of doing a translation, where it can be done function by function, and still have a fully working module at each stage.

@Dave
I use the functions of OSLIb which if I’m not mistaken certainly uses SharedClib.
Mousecmd is relatively simple, because it only encodes * commands. The splitting by function was done at the disassembler level. On the other hand, the insert in the mouse buffer causes me some problems for the C coding.
With OSLIb I use xoswordpointer_set_position to move the mouse, but inserting the 9 bytes into the buffer generates an error in the module.
I think we can’t use insv(byte, buffer_MOUSE) without precaution?
I tried disabling interrupts and re-enabling interrupts as in the source program, but same problem:-(

@J-M
I struggled to get the values out of the OS_ReadArgs output buffer, because for each arg it returns a byte followed by a word, which means that only one in every four words is word-aligned. Assigning to an int from a non-aligned int causes an internal compiler error. Eventually it occurred to me to use memcpy instead of assignment; that works fine. I think the solution I have now is elegant enough.

So, now on to the next stage.

Thanks Dave for this information.
I also used memcopy and the parser works well, we find the values ​​, , then the command number allows to direct to the subroutine which moves the pointer and simulates a click of the buttons.

For insertion into the buffer OS_Byte 138 does the job.
The pointer moves correctly,
quick question: the only values ​​of are 1, 2 and 4 (corresponding to bits 0,1,2)?

I looked through the PRM and other Help to find out what values ​​to put in the buffer, but I couldn’t find any.

Note: Basically I think I understand what the module does and I’m trying to reproduce its functionalities, but this may not be the right way to approach the conversion?
Ok for the next stage,