Rick's b.log - 2021/03/06
It is the 24th of November 2024 You are 3.133.128.227, pleased to meet you!

ARCbbs - a blast from the past!

In past years, I'd been in touch with both Hugo and Keith Hall (ARMbbs) to enquire about making a 32 bit coversion of the software, but as with most questions along those lines, they never went anywhere.
I have heard that somebody is working on a port of ARMbbs, but I don't know if that's true or how far they've gotten.
Just "for the hell of it", I have written my own BBS system. It is unfinished, I work on it from time to time, but I don't know if it'll ever be finished. You can access it by connecting to my personal server (my Pi) with telnet. Unlike traditional BBS servers, mine only speaks telnet. It doesn't deal with serial devices at all.

Earlier in the week, Hugo dropped ARCbbs onto GitHub. Now, the problem here is that the sources to the version that we were all using (1.64ß32) have been lost along the way. The sources that Hugo has are apparently for 1.64 which seems to be largely the same as 1.63 in several respects.
Unfortunately, my copy of the "ßnotes" file is corrupt (all null bytes) so I can't see what changed when.

The software itself is largely written in K&R style C, with a module written in assembler to act as an interface into the back end files (message data and user data).
Unfortunately, the message data structure is not the same as the one from my old BBS. I'm aware that it did change at some point, as I have a program to convert 1.63 data to 1.64 data, but again without the change notes, I'm not sure what or when. It might need some pulling apart of the code and the data files to work out what the format should be. This is important as something somewhere is following duff pointers and writing junk into ther parts of system memory. I have managed to get the server up by using a copy of the data from an early demo of the server. However, it is extremely fragile and in the process of getting this far, I've never reset my Pi so often in such a short period of time. Suddenly we're seeing the problems of having third party extensions run with kernel level privileges and the utter lack of memory protection in RISC OS. That's not to blame Hugo here, it's a fault inherent in the design of RISC OS that just the ARCbbs module just happens to show up.
Well... having some sort of version identifier in the file and sanity checking, instead of blindly accepting the data as valid, probably would have helped, but that's the beauty of hindsight - it's easy to look back twenty eight years later and say "duh", but we have all learned that lesson the hard way - and nothing is immune, RISC OS itself is tight and fast because you can pass any old crap to a large number of OS functions, and whether or not the system blows up is basically Russian Roulette. I'm sure most C programmers have encountered the "I ran my program and the whole thing fell over like a house of cards in a hurricane" because oh oops, you passed a null pointer to something... ☺

I have not looked at the architecture of the BBS. As an overview, it is a directory with a mass collection of source files that are all used to build several things. I'm not sure if there is any overlap. I think it might help to pull the thing apart and make it be separate DDE-style builds, in order to better compartmentalise everything, and allow Sh^C from Zap to build the current part.
Then, the fun of trying to work out what the heck is going on with all the crashiness. I know that ARCbbs worked without particular issue on a 26 bit system. Arcade BBS used it for decades. So I'm pretty sure all that is going badly wrong is down to the code acting upon faulty data and doing the wrong thing.

Here is why I know the data file "works but is still duff":

Say what?

So it looks like the lookup data might be the problem.

Still, after translating some of the file paths of libraries to point to the correct locations, and a lot of patching up of the unholy mess that was the full screen editor (note - that was not written by Hugo) because K&R has a much looser definition of how functions are mdefined than ISO C, I was able to coax the server into starting up.

The World Of Cryton main menu.

Still, it does just work on a 32 bit RISC OS 5 machine now. That's a big leap forwards from last week...

You can see the original ARCbbs sources on GitHub at https://github.com/hfiennes/arcbbs.
If you're using NetSurf (or a mobile browser), here is a direct link to the zip download.

Or, you can download an archive with my modifications (builds on RISC OS 5 on a Pi2 using the DDE).

Generic 4012B "MP5" car radio

Caoimhe had a radio. A Clarion device that offered FM/MW/LW with RDS on FM and a CD player, plus Aux input. Sadly no USB, and probably didn't support MP3 so I'd need to burn a number of CDs.

So I looked on Amazon and, well, there's a lot of cheap (Chinese?) stuff. Some of it looks interesting, but as we shall see, it's a combination of blatant lying and reasonable hardware let down by deplorable firmware.

Deceptive advertising

Part of the promotional description of this radio - note the underlined parts.

The screen is not tactile. It doesn't respond to touch at all.
Likewise, the radio reception breaks FM into three sections (FM1, FM2, and FM3) in order to allow you to set up six different channels in order to remember eighteen channels in total. There is no support for AM at all.

Installation

Hooking up the radio.

Connecting the reversing camera was an entirely different thing. I figured out that the upper yellow RCA socket was for the camera input (not the antenna, as marked!). The camera was wired up, powered from the reversing lamp, and the long video cable laid into the trim from the rear of the car up to the dashboard. But... the radio just wouldn't switch to the camera even when a valid video signal was present.

It turns out that an extra connection is required. The long co-ax has a little bit of red wire sticking out of each end. Well, one end needs to be joined into the 12V power to the reversing light (isn't it lucky I'd just recently bought a battery powered soldering iron?), and the other end joins to the "pink" wire from the power supply ISO connector to the radio. You can just about see that in the above picture.

In use - MP3s on a USB key

Playing MP3 from a USB key.

It will read MP3 tags for the song title, the artist, and the album name. It will also display the album art, if present.
Annoyingly, if the tag isn't present, it will say "NULL" rather than simply saying nothing.
The text is too small. It probably looked good on the programmer's 21 inch screen, but when you're in a car trying to read that on a 4.1" display, it's not the best, is it?

It is possible, when you've worked out how, to access the underlying filesystem to choose a song in a folder. Unfortunately the device makes no attempt at restricting playback to only the songs in the selected folder. It's a case of all or nothing.

I have only tried the player with MP3, so I can't report on what happens with other formats such as AAC or OGG. I wonder what it displays if there are no identity tags? Probably the filename.

The device claims to support media up to 32GB. I'm not aware of any specific difference below and above 32GB (using a 512 byte sector size, that would be about 61,282,631 (note that media GB isn't the same as memory GiB!) which would require 26 bits to address...).
So what they probably mean is that the device supports FAT32 and not exFAT, which considering that exFAT is patent encumbered, it isn't a surprise. Not a lot of things support it.

Turning the big button adjusts the volume. Pressing it enters a mode where you can tweak the bass and treble, set the balance (left/right and front/back), choose a predefined EQ mode, and turn loudness on or off. Really, this sort of thing probably ought to have been in a setup menu rather than the big button.

Leaving everything at its defaults sounds "okay", but bear in mind I'm driving an Aixam which is inherently noisy.
Changing the EQ or turning on loudness feels like it is introducing distortion.

In use - radio

FM radio.

I've not used the radio much.

In use - Bluetooth

In use - video

Watching videos on a car radio.

In my (brief) tests, it seemed to cope with MP4 H.264 (640×480), MKV H.264 (720p), AVI XviD (576p), AVI MJPEG 1080p, and MP4 H.264 1080p.
It does not support HEVC, and to be honest the support for 1080p is lousy. It can do it, it just can't do it in realtime. So expect the video to be slow, and the sound to stutter. This happened both with H.264 and MJPEG.

It is worth pointing out that the above video is actually wrong. Airwolf is supposed to be 4:3 aspect, as it was created before widescreen was a thing. The player just displays everything at 16:9 aspect.

In use - reversing camera

In use - controls

Radio controls.

If sometimes incomprehensible key functions aren't enough, it gets better. When you finally find either the list of files/folders or the main menu, the up button makes the selected item move down (and vice versa). Additionally, it isn't debounced, so a press of the button may be registered as anything from zero to three presses (that I have observed).
It is utterly useless to have a controller that fixes to the steering wheel for on-the-go controls when said controller is unpredictable. Also, again, the on-screen text is often too small. I wonder how long it will be until somebody is involved in a crash because they were paying more attention to the assinine and obfuscated controls than the oncoming traffic?

In use - other

The rear circuit board.

I didn't need to take anything apart for this photo. The top cover just flips off, it isn't even screwed down.
The front board would be more interesting, but it appears to be two boards soldered together with the intelligence sandwiched between, so I cannot say what is actually powering this thing.
The on-screen version identification says it's a 4022 (interesting, it says 4012 on the device itself), then a serial number, then 8035EU-EN-201109. I'm guessing that means the 9th of November 2020?
It also identifies the MCU as "M5F4AV06", to which Google isn't my friend...

The controls can light up in seven colours. By standard it will cycle through the colours. Thankfully it is possible to configure it to stick to one colour.

The screen seems reasonably bright. It can be read in daylight. Unfortunately there is no mechanism to dim it at night. Or maybe there's some wire to hook up to the headlights, that the user guide didn't bother to mention?
The resolution appears to be something in the order of 800×600. Certainly, there are no obvious pixels when looking at it from a normal distance. It has a reasonably wide viewing angle. The pictures show up fairly blue in my photos, but I suspect this is the camera being tricked by the backlight. Visually it isn't as blue as it seems from the photos.

I noticed when my phone switched to GSM that the radio picked up the "duh-duh duh-duh" sounds when playing MP3s. So it would seem that it isn't shielded well enough to avoid such interference.

Summary

It's also a good reason why the firmware for this sort of thing really ought to be released as open source. If the company isn't willing, or capable, of creating firmware that does the sorts of things users require (or, for that matter, a coherent and bug free interface), then why not leave it to people who can?
I get that some companies are protective of their firmware, but they really need to ask what they're trying to sell here - a bit of software, or a piece of hardware? Just think how many more they could shift if it had a nice feature set and could do the sorts of things that people expect?

And...?

Given that it only cost €36,99, should I put up with it for now, or what? There's a better CAMECHO device for about €50. The spec sounds good, but the bad reviews are rather unsettling - the device seems to be prone to crashing and getting stuck in reboot loops (well, it is running WinCE!).

Your comments:

David Pilling, 8th March 2021, 18:56

Very interesting about Hugo and the sources. I am passing the info on...