32bit version of SlotMachine Module avalable

Hi everyone,
I just 32bitted a module called SlotMachine that is heavily used by LIRC client.

I already have contacted armware.dk for the LIRC sources.

Did the ZapRedraw 32bit and then found on here that super Rick already did that, so reversed back to Rick’s work. I know I am a lazy googler…

Did the conversion of SlotMachine and would like to contact the original author. The module report a copyright, so I would like to ask permissions to redistribute the module and the reverse engineered and 32bitted sources, so we could have a free IRC client for RISC OS 5 again.

if anyone here is still in contact with Thomas Olsson (the original SlotMachine author), can you please help me to get in touch with him?

Thanks in advance for the help everyone.

Nice work, Paolo :-)

I already have contacted armware.dk

…and…

if anyone here is still in contact with Thomas Olsson

…are actually the same thing, since Thomas Olsson IS armware.dk.

Thanks guys,
Thomas has emailed me back today with permissions and the sources he could provide, so I think I can keep moving forward with 32bitting LIRC :)

Thomas has emailed me back today with permissions and the sources he could provide

Great to hear that Thomas is alive and well!

Now that you’ve started your lucky streak, could you try the same with Guttorm Vik?

@ Steffen

Now that you’ve started your lucky streak, could you try the same with Guttorm Vik?

My queue is really full ATM, this one was a one shot to add more tools to the DME project. Anyway what is it with Guttorm? I think most of his software is already maintained, no?

Beside, LIRC has an internal BBC BASIC extension library that seems to need to be modified together with some hack to crunch the final work (which obviously the regular cruncher cannot crunch given the extra tokens), so I am not near the end of it yet.

I am using a 32 Bit LIRC version since many years on my BBxM. So I am a bit confused about your remarks regarding LIRC.

A 32bit LIRC 1.86a (28May12) is here

ZapRedraw needs to be 32bit. SlotMachine is 32bit. The Speak module was called for, version 1.47 is here

It starts up on the Titanium.

I am using a 32 Bit LIRC version since many years on my BBxM. So I am a bit confused about your remarks regarding LIRC.

Fair enough, so the LIRC release on the official repository, which few of us have tried, fails to run on RPi 3B+ and other 32bit RISC OS 5 platforms.

So, I had a look at the code and found a couple of modules that are definitely NOT 32bit:

1) ZapRedrew
2) SlotMachine

I have 32bitted both, then found that Rick Murray already did the ZapRedraw, so reverted to Rick’s ZapRedraw (I do not want to have duplicates that would confuse people).

So, now I have both the 2 above 32bit.

Then I have tried to run LIRC and there seems to be still few issues that need fixing, and, before doing anymore work on it, I asked permission to the original author (and to the official website that still distribute it) to be able to distribute the final work to everyone.

I have received permissions today to proceed, as long as I do not release a specific library that is copyright from 3rd parties, so probably that one will need to be rewritten from scratch.

So, clearly, there seems to be no official 32bit version of LIRC (at least that me and the original author are aware of) or, at least, there isn’t an official 32bit and open source version of it (yet), but there will be soon.

If you would like to help on this effort, I’d be very happy to work together on it :)

What do you think about it?

@ David

A 32bit LIRC 1.86a (28May12) is

Thanks, hopefully we can open source your one and also put it in !PackMan then?

Meanwhile I’ll keep working to ensure sources are 32bitted and preserved :)

Also, please can someone update riscos.info as well :S

https://www.riscos.info/index.php/LIRC

A 32bit LIRC 1.86a (28May12) is here

My version is 1.86c (12 Jul 2012). There are bugs I agree and I never tried it on my RPi 3B+ until now.
I can’t renember where I downloaded it from.

ZapRedraw

I using Zap since two years on my RPi 3B+ and Nettle also requires ZapRedraw and works without any problems on the machines. Why it is not 32 Bit compatible?

Perhaps we should setup an own forum named “Lost Technologies” and collecting all links and sources about old programs. We are facing every day problems like “where is”, “where the heck was”.

Perhaps we should setup an own forum named “Lost Technologies” and collecting all links and sources about old programs. We are facing every day problems like “where is”, “where the heck was”.

I wonder whether it might be worth using something like the compatibility list as a base. At present the first column contains a link to the relevant website, but I wonder whether the Notes column could contain further details where relevant.

I using Zap since two years on my RPi 3B+ and Nettle also requires ZapRedraw and works without any problems on the machines. Why it is not 32 Bit compatible?

Sorry my bad English, I meant the ZapRedraw module provided with LIRC itself (from it’s original website, aka armware.dk). That specific ZapRedraw module is not 32bit and given that the copyright of the “official” LIRC is 1998, I went straight to convert those modules instead of trying with new stuff that may give me different problems (until I had the LIRC sources, which was today).

Perhaps we should setup an own forum named “Lost Technologies” and collecting all links and sources about old programs. We are facing every day problems like “where is”, “where the heck was”.

Absolutely agree, I created that GitHub repo mostly to collect and 32bit old techs, which I am doing together with the new stuff I am working on.

Most of us aren’t following all the little changes and we need a way to find software easy, RISCOSSearch should become that way (whenever it will be available), but both RISCOSSearch and the Preservation Project focus on collecting stuff in an “executable” format that may or may not be 32bit suitable, hence I have started to collect sources instead, and slowly 32bit them or share them to have help to 32bit them.

Any place is good for me, as long as we start to have a repo of source of old RISC OS tech (with the original authors permission of course) :)

Beside all of this, wouldn’t it be better to just use PackMan? (P.S. I do not get paid by Allan, but honestly it does a really good job IMHO).

@ David Pitt

A 32bit LIRC 1.86a (28May12) is

I tested that version on an RPi 3B+, and JFYI:

The ZapRedraw module it contains is still NOT 32bit, so if a user has no 32bit ZapRedraw already loaded then LIRC will fail to start.

The !Run file still falls back to the LIRC provided ZapRedraw module in case it doesn’t find ZapRedraw 0.30 loaded.

Hope this helps.

@ Chris M.

I wonder whether it might be worth using something like the compatibility list as a base. At present the first column contains a link to the relevant website, but I wonder whether the Notes column could contain further details where relevant.

These lists needs to be kept up-to-date, please note my asking to update riscos.info link.

I think the best way is just create a repository on github where people can collaborate or just keep the software up-to-date and then distribute it via !PackMan. It’s probably going to be less effort than having multiple lists everywhere. As a matter of fact, the list you linked doesn’t even contain LIRC32, not even a Chat or Messaging category, so I doubt it actually reports all RO 5 compatible software to date.

Thoughts everyone?

[better than] having multiple lists everywhere

the best way is just create [another list]

No comment :)

the best way is just create [another list]

No comment :)

Chris, I appreciate the humor, but PackMan it’s actually a package manager not a list, JFYI ;)

I guess, meanwhile, I’ll keep going with my idea and keep collecting sources and try to 32bit as much as I can of them and make them available on PackMan.

There seems to be a way to actually use GitHub itself as both Package repository and list repository too, which means also scalable service and a more robust infrastructure than self-hosted services.

I am doing some experiment with Packman and GitHub and it seems to be viable (on the early days).

That, combined with Gerph’s build and test services, may completely automate everything from the source to the delivery to RISC OS users.

A package manager with a list of packages behind it :)

I’m all in favour of having everything in PackMan, although there’s still the issue of separation between free and commercial software. There’s also a fair amount of free software in Store but not in PackMan, which doesn’t help matters.

I’m also a little unsure about putting development ‘stuff’ in there. Is there a standard way of distributing something like HTTPLib where it’s not an app, just an object file and associated C header? There’s a “Section” in RiscPkg called “Library” but there doesn’t appear to be any official advice on how they should actually be packaged.

completely automate everything

That’s certainly helpful! For HTTPLib I’ve automated as far as “create the zip files” and if it was in PackMan then I’d be able to automate the upload too (I already have the directory exposed via Omni).

I’m also a little unsure about putting development ‘stuff’ in there. Is there a standard way of distributing something like HTTPLib where it’s not an app, just an object file and associated C header?

Yes, the category for this is ‘Library’.

I am distributing my Gennan port lib this way, Gennan had a lot of downloads so far and no one has complained, so I guess it’s good enough.

There’s a “Section” in RiscPkg called “Library” but there doesn’t appear to be any official advice on how they should actually be packaged.

AFAIU, PackMan tries to use categories used/set by people, so, “the rule” is: either use an existing category or set one in your repository file, that should be pulled down by PackMan and displayed as a new category (I think). Probably worth to send an email to Alan for a confirmation.

That’s certainly helpful! For HTTPLib I’ve automated as far as “create the zip files” and if it was in PackMan then I’d be able to automate the upload too (I already have the directory exposed via Omni).

Indeed. So, Github actions support uploading stuff and you can hide the secrets in your GitHub account and write your automation using macros-like variables that will be expanded at the build/upload moment only.

If you do not trust GitHub secrets then you can use tools like HashiCorp Vault, which allow you to store secrets wherever you want and then use the same technique of above to use them in your scripts during automation time.

Another tool that can help with complex automation is Travis-CI which has “this world and beyond” of tools and integration services.

PackMan packages are (as you’ve mentioned) zip files with a specific structure (and support text files), so, you can generate all of that using a script and pulling the binary from wherever you have built it.

Here, for instance, I am writing an automation that pushes them from RISC OS to a server (public) and then GitHub pulls it from there, this because on the RISC OS Community we have decided not to store the binaries in the repo itself. So my GitHub action will just pull a binary and package it and then push it to my public repository and update the famous list you like so much automatically.

Now the reason of my comment on your joke, was because the “list” for packman is generated fully automatically and not by me, and it also includes extra info as the checksum of the zip together with the categorisation that the developer originally did, so the amount of human errors are way more limited than these manually managed lists that also point to separate websites that may or may not be maintained and may or may not be on-line… (yes read APDL if you would like to).

I’m all in favour of having everything in PackMan, although there’s still the issue of separation between free and commercial software.

You are 100% correct on this one, I have few ideas on how to solve this, but, as I said before, right now my queue is full and I need to have a life too :D, so this is something for another time.

The !Run file still falls back to the LIRC provided ZapRedraw module in case it doesn’t find ZapRedraw 0.30 loaded.

A 32bit fall back would be good.

The ZapRedraw module is supplied in ZapFonts which sets Zap$Redraw to point to the module.

The RMEnsure could look like this. (ZapRedraw 0.48 is the first 32bit build, done by the Zap developers, that came with Zap 1.47.)

RMEnsure ZapRedraw 0.48 If "<Zap$Redraw>" <> "" Then RMLoad <Zap$Redraw> Else RMLoad <LIRC$Dir>.ZapRedraw

LIRC 1.86a does error while connecting at line 4990:-

*where
Address &FC024350 is at offset &00003EC0 in module ‘UtilityModule’
*

Ok the ZapRedraw change is added, now I am looking at the various errors I had.

The good news is, my copy connects fine to libre.chat and I can enter the historical riscos channel. But I do get still one error after it has connected, which doesn’t seems to prevent the initial connection.

It also fails to authenticate the user, and, obviously, it’s not using SSL yet (that has to be added).

Anyway progress.