Rick's b.log - 2022/04/15
It is the 21st of November 2024 You are 3.145.180.152, pleased to meet you!

RISC OS outside

So as I sit here stuffing a double-raspberry Magnum into my cakehole, I am outside, with RISC OS, and the most important part, there's a connection to the outside world.

The first idea, and possibly the most useful, is to get a second Vonets VAP11G (or 11N) adaptor. But this is not only €30, it also needs a USB power source which I don't have. The battery has two outputs - the Pi and the monitor.

There is a much simpler and cheaper solution that needs no power source.

Watching me writing this!

As you can see, the clever "solution" was a five euro twenty five metre Cat5e network cable. One end is plugged into the Livebox, the cable runs through the living room, out the door, across a way, and into the Pi.

You'll note, also, that the LCD panel is brighter and more visible than the tablet. Plus it's easy to pick a larger font size in Zap so I can see clearly even with a 1024×600 display in a seven inch (diagonal!) device.
Add a baseball cap to keep the sun out of my eyes, and we're good to go!

Both of the devices are logically connected via ShareFS. My ShareFSWindow size is 2, I think this might be the default? I don't transfer big files, so I haven't bothered fiddling with this.
Both root drives are shared. This Pi with read/write access, and the main Pi with read-only access.

What I really ought to do is find a smallish µSD card to allow me to upgrade to using the Pi2. The original Pi1 is noticeably slower, and since I have the Pi2 not doing anything, it would make sense...

Fun with oscilloscopes

Sometimes it works just fine, like this:

Oscilloscope working.

Sometimes, however, it's not so good:

Scope not working so well.

I had originally throught that it might have been a faulty timebase causing the jitter, but the voltages there all seem to check out. Looking at it in more detail, it seems to be a fault with the display. I'm not sure if it's the tube, or the HT circuitry.
In addition to this, it is Schrödinger's Oscilloscope. It is both functional and faulty, and one will not know which until it is switched on!
This last part is quite frustrating. In my world view, things that are broken are broken. This scope? It's like debugging a C program where something crapped on the stack eighteen functions ago and you've got to try to unwind what happened when nothing makes sense.

I tried to recalibrate the device, having measured the 1kHz test signal as 971.370Hz and the 10kHz test signal as 9.626kHz. Both are hardwired, there's no way to tweak the outputs. Still, close enough. Oddly, the calibration, when set to one timing, as shown in the first (working) photo, is slightly off in other timings. I guess the age of the appliance will have something to do with it - it dates from the early '80s, I think. So it probably needs its capacitors overhauled as well!

I found another, dusty, in Le Bon Coin for twenty euros. I make that "about thirty five with postage". I sent a message to the seller, but have not heard anything back since. Useful.
Still, I'm not prepared to spend much on this (or a replacement/one-for-parts). I've seen some listed at around €100, but twice that will get me a much better tablet-like digital scope from some no-name Chinese outfit. Claiming a gigasamples per second, it very clearly won't do 1GHz like some of the promo blurb suggests, but it ought to be good for at least 100MHz, maybe twice that.

My main oscilloscope, actually, is my little hand-held one. Because it is digital, the sample-and-hold makes it simple to poke around for discovery. A conversation along the lines of "oh, I wonder what's on this pad... oh, that's interesting... oh, now that looks like serial data". ☺
And as I demonstrated a while back, because oscilloscopes display a waveform over time, it's also possible to look at the data to determine its speed (in case you don't want to just assume 115,200bps) and if you look closely, you might also be able to count the pulses to determine the data format (in case you don't want to just assume 8N1).

Example digital scope screen
(probably much larger than life size on your screen!)

The thing is, my dinky little abuse-of-an-STM32 handheld jobbie only has one input, so can't display one waveform in relation to another, and being an abuse of an STM32's ADC input, it is also limited in its sampling speed. I think it maxes out at around 200kHz or so. More than enough for a lot of things, but it cannot accurately render a generic PAL video waveform.
The analogue scope? Greatly limited in having no memory, but on the other hand it is absolutely immediate. The input signal controls the dot on the screen. Plus, some clever beam shifting inside allows for it to be dual input, so it can display one waveform against another. And if you're more interested in looking rather than measuring, the Y position is easily fiddled so you can have one input on the top half and the other on the bottom half. And, at your leisure, bring them over top of each other.
An example? An input video signal, and then perhaps the extracted line sync signals, to ensure that everything lines up correctly.

I can imagine that I will, at some stage, get one of the better digital gizmos. It's just not currently a priority.

And if anybody has any suggestions as to what to check regarding the tube not seeming to have enough power to maintain a stable picture, I'd love to hear from you. Nothing looks wrong. I wobbled all of the cable connectors. I don't fancy trying to meter anything running at hundreds/thousands? of volts, though. Also, I don't think there are any lose/dry joints. I tapped around with the wooden handle of a knife and nothing showed up on the screen.

My veg

Watering system.

And...

Anna realising that it turns!

Nothing has sprouted yet.

Actually, I lie. Some of the potato bits left over from last year are starting to sprout. I'll need to hoike them out tomorrow.
Also, everywhere, but especially the new patch, there are little bits of bramble coming up. I'll have to grab them with the business end of a pair of pliers and yank them out too.

Crit'Air

Crit'Air sticker.

Applying was easy, and online. The site could speak English and German as well as French, but I did it all in French. Partly out of preference, and partly because I missed the "En" thing until afterwards. Maybe my paranoid script blocking prevented an animated "click here, stupid" British flag from being displayed? ☺

I think it cost about €3,50 which includes postage. All I had to do was enter the licence plate and the date of first registration.

The barcode is a 2D-Doc containing the licence, the category, the VIN, what sort of fuel it takes, and a cryptographic key verifying it was validly issued by AriadNEXT on such-and-such a date.

I'll probably never need it, but for five minutes and three euros, it's useful to have on the very unlikely chance that I ever need to drive into Rennes... or anywhere else these things might be required.

AU attack 3D 'game'

On the face of it, the idea is simple. There is a two dimensional "map" which contains walls. In a simple version, as we have here, all wall units are square. Within this map is the player character.

Now the screen is a set of pixels. So many across, and so many up and down. So what the renderer does is something called ray casting. This isn't the same as ray tracing, because that (tracing) takes an absolute ton of processing power and creates beautiful images by working a ray for every single pixel on the screen, which can include reflections and light sources and such.
Ray casting is a much simpler affair, that chops the screen into vertical slices for every column across the screen. Then, it sends out one single ray from the player position to work out how and when it hits 'something' (a wall object). When this has been determined, the result gives a distance, which tells how big this sliver of the object should be drawn. Then, for the simplest (non-textured) example, it's simply drawing a line of that size above and below the centre point.

That's about as far as I am capable of explaining at this point, as it rapidly descends into heavy duty maths. There is a guide on the internet that I have used to make a functional SVGA quality example, but it fails (and flickers massively) if I try a 720p size picture. Perhaps because the code makes extensive use of floating point, which the DDE compiler sucks at (well, it doesn't suck, it just uses the emulated FP which sucks because there's hardware FP that's at least two orders of magnitude faster).
The basic routine is, actually, really astonishingly simple. Just mathematically heavy.

Back in the summer of 1997, Acorn User ran a series of articles called "Virtuality" which explains in more detail how these sorts of games work. Because it is written for RISC OS hardware, it uses fixed point which helps retain some of the accuracy of FP while actually working with straight integers, which is quick.

3D world demonstration.

I am working my way through the series, but decided to have a crack at porting the final incarnation to a 32 bit world.

The original code was written for the EasyC compiler (remember that?). The code itself is... let's just say there are four things that really bugged me.

• The first is the code layout. From having actual functions and code in a header file, to a general lack of indenting, it makes the code harder to read.
• There are various references in the code and the magazine articles saying that "stuff is complicated, get in touch if you want to know more". I don't know whether this was a subtle way of seeing how many people were reading/interested, or if it was an article author going above and beyond, but a quarter century later I can't help but wonder if some time spent elaborating the comments in the code mightn't have been a better idea?
• There's quite a bit of weirdness in the code. I don't know how much is idiosyncratic of the programmer, and how much was due to EasyC. For example, I removed a lot of storing R1-R4 around things like a call to OS_Byte. Did EasyC not support the APCS calling convention? That means the function called is able to freely corrupt R0-R3, which means a call to OS_Byte (which only uses R0-R2) can simply be followed by pushing R14 (the return address) into PC. There's no need to stack/unstack anything.
  Loads of functions had to be defined. I guess EasyC was a less rigid (read: non-standard) compiler?
• There's a lot of code kicking around in the assembler section that simply isn't used. Either entire functions, or bits commented out here and there (with, as I note, no explanation why).

ObjAsm had fun with an LDRBS instruction... a what now? LDR(B) doesn't mess with the flags, and has no mechanism to do so.
ObjAsm also choked on the nonsense that was MOV R9, #0, LSL #16.

Sadly this code is hardwired all over the place to work with a MODE 13 screen, that's 320×256, which means unpicking it to work with something more modern would be quite difficult. The value '320' appears 43 times in the assembler code, including a few times as a shifted value for setting up write pointers.

I think, therefore, that my understanding may work best by using the article series to better follow the concepts, and then try to apply the fixed point method to the simpler FP example; to have something that is both reasonably fast and comprehensible.

Moreso, given that there are... issues. I'm not sure what, but sometimes the casting goes astray and a massive phantom object appears directly in front of you. Shortly afterwards, the program usually crashes.

If you would like to give this a whirl, you may need to have a Pi set to have the GPU scale the output to fit a fixed display size (this isn't the default these days). AnyMode may work, I don't know.
If you have the GPU handling your video output in this way, simply add the following to your screen modes file, and then drag the file to the monitor icon to load it.

  # 320 x 256 (MODE13)
  startmode
  mode_name:320 x 256 (13)
  x_res:320
  y_res:256
  pixel_rate:25200
  h_timings:0,0,0,320,0,0
  v_timings:0,0,0,256,0,0
  sync_pol:3
  endmode

This will give your machine the ability to use the ancient 320×256 screen mode (MODE 13).
All other machines, and Pi devices where RISC OS controls the video output timings... give up, no modern monitor will touch a resolution that low; and I think the lowest many TVs can handle (if supported) is 384×288 (CEA CIF, perhaps only because it's the VCD standard resolution?).

Here's the compiled executable, sources, etc. Builds with the modern DDE. I've mostly worked on the assembler part. All function titles are mine, as well as commenting out unused functions. Other comments of mine within the code are prefixed "[Rick]".

The articles run from April to September 1997, which may be found at The 8bs Acorn User scans page. Note that the scans are PDF files within Zip files (why?) and they are huge (expect ~50MB each), so perhaps best handled with a decent smartphone/tablet or desktop computer that isn't RISC OS?

Your comments:

David Pilling, 16th April 2022, 23:37

Problem with the scope is - the rounded off square wave? Probes have a thing you twiddle to make square waves square with the x10 thing. Bit of stray capacitance somewhere in the signal path.

J.G.Harston, 24th April 2022, 00:49

I remember managing to write a straight-line line-of-sight maze viewer on th ZX Spectrum back in '84 or so. One of my first sleeves-rolled-up in-depth programming efforts.    It worked quite well, you could "walk" around the maze and see updated views, along with a little localised plan view. That's as far as it went, as I have no imagination, so had no ability to make it into any sort of game.    It's on one of my Spectrum tapes somewhere, I want to get the code off somehow.