Show newer

I am victorious in my battle with packman. Newest version installed, convinced to list all the packages available, and it even knows which packages I already have installed.

OK it did things the hard way, literally reinstalling everything, but I had all the zips so at least I didn't have to download it all.

Show thread

I'm feeling very frustrated with the packman package manager in . Not only is the new version dropping files, it wants to delete half my working packages and keeps trying to install Perl5.8 which segfaults on my pi2.

Worst of all I can't seem to get the original version to work at all now! Grrrr!

So now I'm converting the docs for an old FOCAL interpreter to clearview.

Clearview is ok. I'm not super in love, but tbh I've never been super in love with any of the systems I've written for.

Show thread

A guy on the ROOL forums ported clearview, an old hypertext system (non html) from 26bit RISC OS to modern 32bit RO.

Had some trouble getting it to run on picky ARMv7 boards because ARMv7 is picky about NULL dereference. Turns out the bug was in RISCOS_LIB and had been there for 30 years!

Anyway I'm happy to see more 26bit riscos code dragged into the 32bit world.

I made my life in RISC OS a bit simpler tonight!

I finally hacked together a stupid perl script that Filer can run to uncompress gzip files!

The perl script converts the RISC OS path like sdfs::riscospi.$.work.src.sed-src/tar/gz to a proper unixy path and feeds it to gzip -d

I don't really know perl well. I was too busy messing with awk when perl was a big thing.

Also RISC OS perl 5.8 seems broken on the pi2. 😣

Got an old Pascal S compiler to compile and run under RISC OS. Then I read about Pascal S on the web (the compiler helpfully includes no documentation) and discover that Pascal S is a toy subset of Pascal. No pointers, no file IO, or function parameters...

No wonder nobody bothered recompiling it for 32bit RISC OS....

But that's OK because I learned a little about the history of Pascal. And about the .... unique architecture of the CDC6600.

Had more fun with under

In order to muck around with video to make a Pi look like an Archimedes adffs needs EDID turned off in config.txt

Since my monitor is an old DVI single-mode flatscreen this was complicated. I'd wrestled with this monitor and the Pi0 when I was trying to get an HDMI sound box to work and it defeated me.

This time I win! EDID is ignored, monitor is getting fed the mode it likes, adffs is happy, so I can play Star Trek!

I am kind of proud of . It's an old startrek that was turned into a full-screen graphics game. Pretty well done, too.

It's pure BASIC so I thought it would run under regular 32bit RISC OS, but nope, turns out it pokes directly at the old Acorn video chip.

I was able to figure out how to make it work under and I'm proud of that.

Show thread

is complicated.
I'm running 5.24, the current stable version on a Pi2.
One of the 26bit sort-of-emulators, , now requires RO 5.27, a beta OS version.
They didn't mention this new requirement... until after I'd upgraded.

For some reason, it was not simply a matter of reinstalling the old version, as the old versions also refused to work!

After a lot of crashes I replaced the CMOS file with one from a stock RO5.24 image and got ADFFS 2.64 to work again. stopping cuz it works.

Porting code to RISC OS. So, dispite it living in unixlib (a, you know, unix compatibility library), the readdir() that is included in the DDE is completely different from unix readdir(3).

For what I needed the RISC OS readdir() is actually simpler to use, so thats ok.

Success! Current build of !browse and a current gopher fetcher module can view gopher://sdf.org

drand48() is definitely in the RISC OS clib, but doesn't seem to be in the header files or docs?

also it returns values from [0,MAXFLOAT) instead of [0,1) which is weird but ok.

I may have to experiment a little with srand48(). Also RISC OS time values are different, so srand48(time()) might not be quite that simple...

BASIC, preprocessed with the C preprocessor.

Sweet Skuld, I don't know if I love the idea or hate it!

I will say however, if the preprocessor was a seperate binary from cc, it could have an option to not insert lines and you wouldn't need another program to remove them...

Only in

I did an idle webcrawl through some old archives, and found a neat app that works on RO5 on the Pi! (anymode may be needed)

It's a little math program for algebra/geometry/calculus.

I remember a program like this (for cga pc) being used in my high school geometry class.

drobe.co.uk/archives//ftp.mirr

DDE includes diff but not patch. diffutils and patch packages from riscos.info made me happy.

Yep the only function rcs needs that wasn't in the old GNU utils lib is fatal(), which isn't exactly a difficult function to write. πŸ˜‚

Maybe I'll attempt the compile in the next couple of days.

The ancient version of gpasm (a cross assembler for PIC) compiled after I updated the paths in the makefile.

I do wonder why an assembler would need to be linked against socketlib though?

I can't really test this one, I've never done PIC assembly and there's no way to program such things from a Raspberry Pi.

"to compile this you also need my private utils library, which is not included or available anywhere."

gee that's useful πŸ˜”

I might be able to work around this one though, his private lib looks a lot like the old GNU utils lib that uemacs uses.

oh sure, now that I'm used to sgit, i finally find a RISC OS port of RCS with source that I can maybe compile for the Raspberry pi. πŸ˜‘

Show older
Mastodon @ SDF

"I appreciate SDF but it's a general-purpose server and the name doesn't make it obvious that it's about art." - Eugen Rochko