From Newsgroup: comp.sys.raspberry-pi

As the subject header would imply, this morning I got a Raspberry Pi 1
model B from eBay. I was initially tempted to futz around with Slackware
ARM on it, but that distro last supported the Pi 1 in version 14.2,
while the latest stable, 15.0, doesn't support it.

Raspberry Pi OS was right out since I recently saw its performance in
the modern day in a recent Jeff Geerling video on YT.

So I went with the best possible choice for a fast and reliable OS on
such old hardware: NetBSD.
So far, things have been pretty decent, especially in the TTY. In X11
there's not a whole lot I can run at once, but it's OK for light
websites (as in, SUPER-light - even SearXNG will crash most browsers I
try).

But aside from super light work, what can I actually do with this thing?
I doubt emulation's much of an option, and I remember seeing one of
these running Quake, so that might be worthwhile to get working.

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

One thing that comes to mind is a serial terminal. If it supports ethernet
that could be expanded to a terminal server.

hth,

bob prohaska

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

I believe software for the RPi Zero (v1) will just work on it,
except slightly slower due to the 700MHz clock speed (or maybe you
could try over-clocking). So pick any of the endless RPi Zero
projects that don't require the full 40-pin GPIO header.

Or anyway it's plenty of power for most things I do with PCs except
using Firefox (which I only do when lightweight browsers like Dillo
and Links don't work at all with an important website).
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Computer Nerd Kev wrote:

Or anyway it's plenty of power for most things I do with PCs except
using Firefox (which I only do when lightweight browsers like Dillo
and Links don't work at all with an important website).

I never owned a pre gen3 Pi, I did watch Jeff's video, and it seemed
that anything GUI is a complete waste of time, Midori browser did run,
it was OK as an SSH host, e.g. to run PiHole
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 06/06/2025 02:04, TronNerd82 wrote:

But aside from super light work, what can I actually do with this thing?
I doubt emulation's much of an option, and I remember seeing one of
these running Quake, so that might be worthwhile to get working.

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it 🙂

Works very well here as an NTP server, running with a GPS/PPS patch antenna indoors. Can support dozens of clients.

https://www.satsignal.eu/mrtg/performance_raspi-1.php

Mine is like this, but Ethernet rather than Wi-Fi connected:

https://www.satsignal.eu/ntp/RasPi-3-with-u-blox-RX.jpg
--
David
Web: https://www.satsignal.eu
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

TronNerd82 <tronnerd82@aol.com> writes:

If you can think of any productive use-cases for an original Pi model
B (not even the B+) let me know, and I'll consider it :-)

I have a couple of (much newer) Pis around the house with temperature
sensors on, feeding a Grafana instance. I expect the 1B would be fine in
a sensor host role, if you can arrange connectivity.

In principle it can do a reasonable job of displaying video but based on https://www.downtowndougbrown.com/2024/06/playing-1080p-h-264-video-on-my-old-256-mb-raspberry-pi/
getting it working is a bit of a run-around these days and the audio performance is poor. It might be OK as a ‘digital picture frame’ but probably not for anything you’re going to actively watch.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Richard Kettlewell <invalid@invalid.invalid> wrote:

TronNerd82 <tronnerd82@aol.com> writes:

If you can think of any productive use-cases for an original Pi model
B (not even the B+) let me know, and I'll consider it :-)

I have a couple of (much newer) Pis around the house with temperature
sensors on, feeding a Grafana instance. I expect the 1B would be fine in
a sensor host role, if you can arrange connectivity.

Agreed, I'd suggest they're best as a 'one function' appliance. I just used
an original Pi Zero to bridge between a USB OBD-II device and wifi, that
allow phone OBD-II apps to connect to the USB OBD cable I already had. Installed OpenWRT and a few minutes of setup and that was it. Similarly I
have a Pi 1 to bridge between Modbus and ethernet, and another Pi Zero as a
VPN endpoint.

I'm sure I could do something similar with an ESP32 or a Pico or similar microcontroller, but the setup with a full-fat Pi is quicker and easier.

Main irritation is the Pi 1 doesn't have wifi, but a $5 wifi dongle fixes
that if you need it.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 06/06/2025 02:04, TronNerd82 wrote:

As the subject header would imply, this morning I got a Raspberry Pi 1
model B from eBay. I was initially tempted to futz around with Slackware
ARM on it, but that distro last supported the Pi 1 in version 14.2,
while the latest stable, 15.0, doesn't support it.

Raspberry Pi OS was right out since I recently saw its performance in
the modern day in a recent Jeff Geerling video on YT.

So I went with the best possible choice for a fast and reliable OS on
such old hardware: NetBSD.
So far, things have been pretty decent, especially in the TTY. In X11
there's not a whole lot I can run at once, but it's OK for light
websites (as in, SUPER-light - even SearXNG will crash most browsers I
try).

But aside from super light work, what can I actually do with this thing?
I doubt emulation's much of an option, and I remember seeing one of
these running Quake, so that might be worthwhile to get working.

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

Put on PIOS as a server. Don't run X or any GUI.

Then its fine for any serverish app.

Back in the day we used to run obsolescent 366 machines as DNS servers...

The modern equivalent - a Pi Zero - is great for many things.
One runs my central heating controller.

Another acts as an audio input to my hifi, that can play any music on my server and some internet radio stations.
--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 06/06/2025 10:22, Theo wrote:

Richard Kettlewell <invalid@invalid.invalid> wrote:

TronNerd82 <tronnerd82@aol.com> writes:

If you can think of any productive use-cases for an original Pi model
B (not even the B+) let me know, and I'll consider it :-)

I have a couple of (much newer) Pis around the house with temperature
sensors on, feeding a Grafana instance. I expect the 1B would be fine in
a sensor host role, if you can arrange connectivity.

Agreed, I'd suggest they're best as a 'one function' appliance. I just used an original Pi Zero to bridge between a USB OBD-II device and wifi, that allow phone OBD-II apps to connect to the USB OBD cable I already had. Installed OpenWRT and a few minutes of setup and that was it. Similarly I have a Pi 1 to bridge between Modbus and ethernet, and another Pi Zero as a VPN endpoint.

I'm sure I could do something similar with an ESP32 or a Pico or similar microcontroller, but the setup with a full-fat Pi is quicker and easier.

I think that is my conclusin with the SZero

A Pico can run a single function, but once it gets more complicated -
like a web server, a pi zero running linux is just *easier*

Main irritation is the Pi 1 doesn't have wifi, but a $5 wifi dongle fixes that if you need it.

Or an ethernbet hat

Theo

--
"Fanaticism consists in redoubling your effort when you have
forgotten your aim."

George Santayana

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 06/06/2025 at 13:09, The Natural Philosopher wrote:

On 06/06/2025 02:04, TronNerd82 wrote:

As the subject header would imply, this morning I got a Raspberry Pi 1
model B from eBay. I was initially tempted to futz around with Slackware
ARM on it, but that distro last supported the Pi 1 in version 14.2,
while the latest stable, 15.0, doesn't support it.

Raspberry Pi OS was right out since I recently saw its performance in
the modern day in a recent Jeff Geerling video on YT.

So I went with the best possible choice for a fast and reliable OS on
such old hardware: NetBSD.
So far, things have been pretty decent, especially in the TTY. In X11
there's not a whole lot I can run at once, but it's OK for light
websites (as in, SUPER-light - even SearXNG will crash most browsers I
try).

But aside from super light work, what can I actually do with this thing?
I doubt emulation's much of an option, and I remember seeing one of
these running Quake, so that might be worthwhile to get working.

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

Put on PIOS as a server. Don't run X or any GUI.

Then its fine for any serverish app.

Static webserver, network backup, here.

Back in the day we used to run obsolescent 366 machines as DNS servers...

The modern equivalent - a Pi Zero - is great for many things.
One runs my central heating controller.

Another acts as an audio input to my hifi, that can play any music on my server and some internet radio stations.

--
Chris Elvidge, England
SHERRI DOES NOT "GOT BACK"

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 6/6/25 08:01, Chris Elvidge wrote:

But aside from super light work, what can I actually do with this thing? >>> I doubt emulation's much of an option, and I remember seeing one of
these running Quake, so that might be worthwhile to get working.

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

I've got two Pi1s and a P1A with Si7021 temperature/humidity sensors
that send via UDP the temperature every minute to a Pi3 with a
temperature display. They also record the temperature and humidity
every 1/10th of an hour to a file. They could easily be doing other
work but I have none for them.
--

Knute Johnson
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

TronNerd82 wrote:

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

You could run Volumio or MoOdeAudio on it. I have a Pi2 for that
purpose, but a Pi1 will have enough cpu power to run it. Sound output
from the headphone jack is not too good, so a cheap usb sound card would
make sense...

-jw-
--
And now for something completely different...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-06-06, TronNerd82 <tronnerd82@aol.com> wrote:

As the subject header would imply, this morning I got a Raspberry Pi 1
model B from eBay. ...

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

It should be able to run an OSS home thermostat with plenty of
CPU time left over.

A couple of things I used to use my Pi 1 for (same unit doing
both functions but not at the same time):

1. The Pi 1 captured off-the-air TV from a PVR-USB2 device and
directed the stream to a named pipe. A netcat session read from
the named pipe. The other end of the netcat session was a Linux
machine with plenty of disk storage. SSH on the larger Linux
machine set up and tore down the stuff when activated by cron.
If interested in that, I have the command options and so forth.
The PVR-USB2 hardware and/or driver would sometimes lock up and
require a reboot, and it was easier for me to reboot the Pi 1
than the bigger machine.

2. Had an HP 6300c scanner that would work with an old (roughly
2010-era) OS and libraries but not with current libraries.
Connnected the scanner to the Pi 1 running the old OS (on a
private LAN so no internet exposure) and used SSH to stream the
scanner output to a newer/larger Linux machine.
--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 06/06/2025 09:27, Richard Kettlewell wrote:

TronNerd82 <tronnerd82@aol.com> writes:

If you can think of any productive use-cases for an original Pi model
B (not even the B+) let me know, and I'll consider it :-)

I have a couple of (much newer) Pis around the house with temperature
sensors on, feeding a Grafana instance. I expect the 1B would be fine in
a sensor host role, if you can arrange connectivity.

I was going to suggest that, as that is what I used my old 256MB and
512MB Model Bs when I got the newer much more capable multiple core models.

You'll need a Pi compatible WiFi dongle, and reliability might be a bit questionable, but that could have been down to using old mobile phone
chargers with the original Pi's, I would recommend the official PSU used
on later ones.

In principle it can do a reasonable job of displaying video but based on https://www.downtowndougbrown.com/2024/06/playing-1080p-h-264-video-on-my-old-256-mb-raspberry-pi/
getting it working is a bit of a run-around these days and the audio performance is poor. It might be OK as a ‘digital picture frame’ but probably not for anything you’re going to actively watch.

I did briefly use it as KODI media player on the bedroom TV, and it
could do a lideshow of camera photos from the NAS OK, but it wasn't
until the Pi 2B that many videos were possible.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In article <101teqs$1rt4d$2@dont-email.me>,
TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

I use one as a print server. I put Alpine Linux on it, and run two
instances of this to drive a laser printer and a label printer:

https://gitlab.alfter.us/salfter/lp_server
--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Andy Burns <usenet@andyburns.uk> wrote:

Computer Nerd Kev wrote:

Or anyway it's plenty of power for most things I do with PCs except
using Firefox (which I only do when lightweight browsers like Dillo
and Links don't work at all with an important website).

I never owned a pre gen3 Pi, I did watch Jeff's video, and it seemed
that anything GUI is a complete waste of time, Midori browser did run,
it was OK as an SSH host, e.g. to run PiHole

I didn't watch the video but I'm posting from an old laptop with
only slightly better specs (1GHz CPU, 768MB RAM), and I've played
around with GUI programs on my RPi Zero W. But it's about the
software you choose, Dillo and Links would run even better than
Midori. I'd also pick a lightweight Window Manager / Desktop
Environment.

Heck you can surely use most Usenet newsreaders fine on a Pi 1.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Richard Kettlewell <invalid@invalid.invalid> wrote:

In principle it can do a reasonable job of displaying video but based on https://www.downtowndougbrown.com/2024/06/playing-1080p-h-264-video-on-my-old-256-mb-raspberry-pi/
getting it working is a bit of a run-around these days and the audio performance is poor. It might be OK as a 'digital picture frame' but
probably not for anything you're going to actively watch.

Bah, just convert the videos to SD resolution for it using ffmpeg.
That's what I've been doing with the hacked Playstation 2 I've used
for videos since before RPis, and checking the specs for that:

CPU: Emotion Engine @ ~300?MHz
Memory: 32?MB?RAM, 4?MB?Video?RAM
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-06-06, TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

Nothing running a desktop. It is fine for light server/connectivity stuff, interfacing/sensor data etc..

I use old PIs as ethernet to JTAG/SWD adapters:

https://www.schwingen.org/jtag-hat/

and Ethernet-to-GPIB adapters:

https://www.schwingen.org/yoga-gpib/

(the latter requires the 40-pin GPIO connector, but the compute power of the oldest Pi 1 would be fine).

cu
Michael
--
Some people have no respect of age unless it is bottled.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

druck wrote:

I did briefly use it as KODI media player on the bedroom TV, and it
could do a lideshow of camera photos from the NAS OK, but it wasn't
until the Pi 2B that many videos were possible.

That's why I only mentioned MoOde and volumio as possible media players
for the Pi1, and since nowaways quite a lot of videos available appear
to be in HEVC (x265) the minimum hardware for Kodi/LibreElec would imho
be a Pi4 since it does the decoding natively on its GPU, stutter-free in
4k.

-jw-
--
And now for something completely different...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Fri, 6 Jun 2025 01:04:28 -0000 (UTC), TronNerd82 wrote:

So I went with the best possible choice for a fast and reliable OS on
such old hardware: NetBSD.

I read Pi OS Lite should be possible.

But aside from super light work, what can I actually do with this thing?

Pi-Hole & Unbound.
--
s|b

ElectronDepot is fooling you. Get a direct feed on Usenet at comp.sys.raspberry-pi
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 07/06/2025 11:52, s|b wrote:

On Fri, 6 Jun 2025 01:04:28 -0000 (UTC), TronNerd82 wrote:

So I went with the best possible choice for a fast and reliable OS on
such old hardware: NetBSD.

I read Pi OS Lite should be possible.

Its recommended.
This seems to be about Pi Zero power wise. But with Ethernet already
Zeros make good little servers

But aside from super light work, what can I actually do with this thing?

Pi-Hole & Unbound.

and other things

Good little linux machines with the ability to control stuff via the IO pins

--
Climate is what you expect but weather is what you get.
Mark Twain

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 06/06/2025 10:22, Theo wrote:

Agreed, I'd suggest they're best as a 'one function' appliance. I just used
an original Pi Zero to bridge between a USB OBD-II device and wifi, that allow phone OBD-II apps to connect to the USB OBD cable I already had. Installed OpenWRT and a few minutes of setup and that was it. Similarly I have a Pi 1 to bridge between Modbus and ethernet, and another Pi Zero as a VPN endpoint.

I'm sure I could do something similar with an ESP32 or a Pico or similar microcontroller, but the setup with a full-fat Pi is quicker and easier.

I think that is my conclusin with the SZero

A Pico can run a single function, but once it gets more complicated -
like a web server, a pi zero running linux is just *easier*

My main reason to pick a Pico over a Zero is reliability: I can be sure a
Pico will boot up every time, but I find it a lottery whether a Pi will successfully boot or whether it's corrupted its SD for some reason or
another and won't boot. I thought PiOSs was supposed to automatically
fsck the disc and reboot with everything clean if a problem was detected,
but for whatever reason this doesn't work - I have to keep pulling cards and fscking them before the Pi will boot again.

Anyone have any insights into why this is? These Pis are getting power
pulled from them rather than a proper shutdown, but in the case where
they're sensors or whatever it's just a fact of life they get power
interrupted without shutdown sometimes.

One of my Pis has OpenWRT which I thought would help the corruption issue as it's designed for routers which don't modify their flash very often, but
even that's got to the state of not booting - I need to investigate further.

Main irritation is the Pi 1 doesn't have wifi, but a $5 wifi dongle fixes that if you need it.

Or an ethernbet hat

Pi1B has 100M ethernet, but things get more awkward if you're on a Zero or a
1A without. You might need an ethernet or wifi HAT to keep your single USB port free for something else, especially if your Pi needs to be a USB device rather than a host.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Theo <theom+news@chiark.greenend.org.uk> writes:

My main reason to pick a Pico over a Zero is reliability: I can be
sure a Pico will boot up every time, but I find it a lottery whether a
Pi will successfully boot or whether it's corrupted its SD for some
reason or another and won't boot. I thought PiOSs was supposed to automatically fsck the disc and reboot with everything clean if a
problem was detected, but for whatever reason this doesn't work - I
have to keep pulling cards and fscking them before the Pi will boot
again.

Anyone have any insights into why this is? These Pis are getting
power pulled from them rather than a proper shutdown, but in the case
where they're sensors or whatever it's just a fact of life they get
power interrupted without shutdown sometimes.

One of my Pis has OpenWRT which I thought would help the corruption
issue as it's designed for routers which don't modify their flash very
often, but even that's got to the state of not booting - I need to investigate further.

I’ve just restored a Pi which had been gradually accumulating filesystem damage (without any reboots/power cycles) over time. It’s not the first
time. My interpretation is that commodity micro-SD cards are mostly
designed and tested on the assumption that the user will be storing a
lot of smartphone photos on them, not a live root filesystem, and
accordingly wear out disappointingly fast. But this is just guesswork.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 07/06/2025 16:45, Theo wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 06/06/2025 10:22, Theo wrote:

Agreed, I'd suggest they're best as a 'one function' appliance. I just used
an original Pi Zero to bridge between a USB OBD-II device and wifi, that >>> allow phone OBD-II apps to connect to the USB OBD cable I already had.
Installed OpenWRT and a few minutes of setup and that was it. Similarly I >>> have a Pi 1 to bridge between Modbus and ethernet, and another Pi Zero as a >>> VPN endpoint.

I'm sure I could do something similar with an ESP32 or a Pico or similar >>> microcontroller, but the setup with a full-fat Pi is quicker and easier. >>>

I think that is my conclusin with the SZero

A Pico can run a single function, but once it gets more complicated -
like a web server, a pi zero running linux is just *easier*

My main reason to pick a Pico over a Zero is reliability: I can be sure a Pico will boot up every time, but I find it a lottery whether a Pi will successfully boot or whether it's corrupted its SD for some reason or
another and won't boot. I thought PiOSs was supposed to automatically
fsck the disc and reboot with everything clean if a problem was detected,
but for whatever reason this doesn't work - I have to keep pulling cards and fscking them before the Pi will boot again.

Anyone have any insights into why this is? These Pis are getting power pulled from them rather than a proper shutdown, but in the case where
they're sensors or whatever it's just a fact of life they get power interrupted without shutdown sometimes.

Never had a problem. Mind you I do work to ensure my SDcards are 'read only..' by and large, and buy good ones

One of my Pis has OpenWRT which I thought would help the corruption issue as it's designed for routers which don't modify their flash very often, but
even that's got to the state of not booting - I need to investigate further.

Yiou do. I have not hears that issue before ever

Main irritation is the Pi 1 doesn't have wifi, but a $5 wifi dongle fixes >>> that if you need it.

Or an ethernbet hat

Pi1B has 100M ethernet, but things get more awkward if you're on a Zero or a 1A without. You might need an ethernet or wifi HAT to keep your single USB port free for something else, especially if your Pi needs to be a USB device rather than a host.

Indeed.

Theo

--
“It is not the truth of Marxism that explains the willingness of intellectuals to believe it, but the power that it confers on
intellectuals, in their attempts to control the world. And since...it is futile to reason someone out of a thing that he was not reasoned into,
we can conclude that Marxism owes its remarkable power to survive every criticism to the fact that it is not a truth-directed but a
power-directed system of thought.”
Sir Roger Scruton

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 07/06/2025 17:00, Richard Kettlewell wrote:

Theo <theom+news@chiark.greenend.org.uk> writes:

My main reason to pick a Pico over a Zero is reliability: I can be
sure a Pico will boot up every time, but I find it a lottery whether a
Pi will successfully boot or whether it's corrupted its SD for some
reason or another and won't boot. I thought PiOSs was supposed to
automatically fsck the disc and reboot with everything clean if a
problem was detected, but for whatever reason this doesn't work - I
have to keep pulling cards and fscking them before the Pi will boot
again.

Anyone have any insights into why this is? These Pis are getting
power pulled from them rather than a proper shutdown, but in the case
where they're sensors or whatever it's just a fact of life they get
power interrupted without shutdown sometimes.

One of my Pis has OpenWRT which I thought would help the corruption
issue as it's designed for routers which don't modify their flash very
often, but even that's got to the state of not booting - I need to
investigate further.

I’ve just restored a Pi which had been gradually accumulating filesystem damage (without any reboots/power cycles) over time. It’s not the first time. My interpretation is that commodity micro-SD cards are mostly
designed and tested on the assumption that the user will be storing a
lot of smartphone photos on them, not a live root filesystem, and
accordingly wear out disappointingly fast. But this is just guesswork.

It's supported by evidence
Many cards are basically made as WORM drives.

To get full RW performance takes a bit more
--
It is the folly of too many to mistake the echo of a London coffee-house
for the voice of the kingdom.

Jonathan Swift


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Sat, 07 Jun 2025 00:20:28 GMT, Scott Alfter wrote:

... and run two instances of this to drive a laser printer and a
label printer:

https://gitlab.alfter.us/salfter/lp_server

Had a look at this source file <https://gitlab.alfter.us/salfter/lp_server/-/blob/master/src/lp_server.c?ref_type=heads>,
which I think is the guts of the thing.

Would be better to use poll(2) instead of select(2), to avoid the
limitations of the latter. I notice you only handle one connection at
a time.

Also, in the Check_restriction() function, you have

b = strdup( restrict );

but I never see anywhere that the string allocated in b is freed.

This is the kind of thing I would write in Python, rather than C. It
would be a lot less code, and a lot less trouble worrying about
memory.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Sat, 7 Jun 2025 17:22:20 +0100, The Natural Philosopher wrote:

It's supported by evidence
Many cards are basically made as WORM drives.

To get full RW performance takes a bit more

There are filesystems available on a standard Linux kernel that include wear-levelling explicitly in their allocation algorithms. Maybe one of
those would be better suited to an SD card than the usual default ext4.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Richard Kettlewell <invalid@invalid.invalid> wrote:

Theo <theom+news@chiark.greenend.org.uk> writes:

My main reason to pick a Pico over a Zero is reliability: I can be
sure a Pico will boot up every time, but I find it a lottery whether a
Pi will successfully boot or whether it's corrupted its SD for some
reason or another and won't boot. I thought PiOSs was supposed to automatically fsck the disc and reboot with everything clean if a
problem was detected, but for whatever reason this doesn't work - I
have to keep pulling cards and fscking them before the Pi will boot
again.

Anyone have any insights into why this is? These Pis are getting
power pulled from them rather than a proper shutdown, but in the case
where they're sensors or whatever it's just a fact of life they get
power interrupted without shutdown sometimes.

One of my Pis has OpenWRT which I thought would help the corruption
issue as it's designed for routers which don't modify their flash very often, but even that's got to the state of not booting - I need to investigate further.

I’ve just restored a Pi which had been gradually accumulating filesystem damage (without any reboots/power cycles) over time. It’s not the first time. My interpretation is that commodity micro-SD cards are mostly
designed and tested on the assumption that the user will be storing a
lot of smartphone photos on them, not a live root filesystem, and
accordingly wear out disappointingly fast. But this is just guesswork.

While I'm sure that's sometimes the case, I don't think that's what's
happening here. The SD card itself is fine - no read/write errors, no long pauses - but the filesystem is broken. Which is to be expected if it wasn't properly unmounted, but for some reason the automatic fsck-and-reboot
mechanism in PiOS doesn't seem to work. I end up having to pull the SD,
plug it into another machine, fsck it (both the FAT and the ext4), put it
back into the Pi and then it boots.

If I don't do that and I have video attached to the Pi (ie I have already pulled the machine to connect to a monitor) the boot stalls somewhere but without a clear log as to why.

I also have this with a USB SSD, so I don't think it's a hardware problem. (although that one runs Ubuntu, maybe it's not so good at fsck-and-reboot?)

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 08/06/2025 10:18, Theo wrote:

While I'm sure that's sometimes the case, I don't think that's what's happening here. The SD card itself is fine - no read/write errors, no long pauses - but the filesystem is broken. Which is to be expected if it wasn't properly unmounted, but for some reason the automatic fsck-and-reboot mechanism in PiOS doesn't seem to work. I end up having to pull the SD,
plug it into another machine, fsck it (both the FAT and the ext4), put it back into the Pi and then it boots.

If I don't do that and I have video attached to the Pi (ie I have already pulled the machine to connect to a monitor) the boot stalls somewhere but without a clear log as to why.

I also have this with a USB SSD, so I don't think it's a hardware problem. (although that one runs Ubuntu, maybe it's not so good at fsck-and-reboot?)

Theo

Fsck on reboot is not guaranteed.
There are many ways to enforce this.
Google them
--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Theo <theom+news@chiark.greenend.org.uk> writes:

While I'm sure that's sometimes the case, I don't think that's what's happening here. The SD card itself is fine - no read/write errors, no
long pauses - but the filesystem is broken. Which is to be expected
if it wasn't properly unmounted, but for some reason the automatic fsck-and-reboot mechanism in PiOS doesn't seem to work. I end up
having to pull the SD, plug it into another machine, fsck it (both the
FAT and the ext4), put it back into the Pi and then it boots.

If I don't do that and I have video attached to the Pi (ie I have
already pulled the machine to connect to a monitor) the boot stalls
somewhere but without a clear log as to why.

I also have this with a USB SSD, so I don't think it's a hardware
problem. (although that one runs Ubuntu, maybe it's not so good at fsck-and-reboot?)

I don’t cut power to my Pis regularly but when we’ve had power cuts
here, they’ve come back cleanly as far as I remember.

Ubuntu and Raspberry Pi OS are both Debian variants, so a shared
software issue is plausible. Saying anything beyond that would be
guesswork though.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 08/06/2025 16:37, Richard Kettlewell wrote:

Theo <theom+news@chiark.greenend.org.uk> writes:

While I'm sure that's sometimes the case, I don't think that's what's
happening here. The SD card itself is fine - no read/write errors, no
long pauses - but the filesystem is broken. Which is to be expected
if it wasn't properly unmounted, but for some reason the automatic
fsck-and-reboot mechanism in PiOS doesn't seem to work. I end up
having to pull the SD, plug it into another machine, fsck it (both the
FAT and the ext4), put it back into the Pi and then it boots.

If I don't do that and I have video attached to the Pi (ie I have
already pulled the machine to connect to a monitor) the boot stalls
somewhere but without a clear log as to why.

I also have this with a USB SSD, so I don't think it's a hardware
problem. (although that one runs Ubuntu, maybe it's not so good at
fsck-and-reboot?)

I don’t cut power to my Pis regularly but when we’ve had power cuts
here, they’ve come back cleanly as far as I remember.

Yes. Although mine are relatively low usage so don't write to
filesystenms aq lot

Ubuntu and Raspberry Pi OS are both Debian variants, so a shared
software issue is plausible. Saying anything beyond that would be
guesswork though.

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 08 Jun 2025 10:18:05 +0100 (BST), Theo wrote:

... but the filesystem is broken. Which is to be expected if
it wasn't properly unmounted, but for some reason the automatic fsck-and-reboot mechanism in PiOS doesn't seem to work.

There isn’t actually a need to do an fsck normally. If you were using ext4 (or even ext3), that includes a journal. On reboot, you should see a
message “replaying journal”, after which the filesystem should be back to a consistent state. This should be very quick, much quicker than a
filesystem integrity check.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Sun, 8 Jun 2025 10:36:28 +0100, The Natural Philosopher wrote:

Fsck on reboot is not guaranteed.

Back in the days when fsck was necessary, the OS would refuse to mount a volume if it was too badly damaged.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 08 Jun 2025 10:18:05 +0100 (BST), Theo wrote:

... but the filesystem is broken. Which is to be expected if
it wasn't properly unmounted, but for some reason the automatic fsck-and-reboot mechanism in PiOS doesn't seem to work.

There isn’t actually a need to do an fsck normally. If you were using ext4 (or even ext3), that includes a journal. On reboot, you should see a
message “replaying journal”, after which the filesystem should be back to
a consistent state. This should be very quick, much quicker than a filesystem integrity check.

I've had times where it's the FAT partition that's been corrupted, which has resulted in a boot failure. I can't say for sure (because they're usually headless and I can't SSH in to check anything) but I suspect this is potentially a reliability problem - bad FAT partition means never booting as far as being able to run anything.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 09/06/2025 at 10:27, Theo wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 08 Jun 2025 10:18:05 +0100 (BST), Theo wrote:

... but the filesystem is broken. Which is to be expected if
it wasn't properly unmounted, but for some reason the automatic
fsck-and-reboot mechanism in PiOS doesn't seem to work.

There isn’t actually a need to do an fsck normally. If you were using ext4 >> (or even ext3), that includes a journal. On reboot, you should see a
message “replaying journal”, after which the filesystem should be back to
a consistent state. This should be very quick, much quicker than a
filesystem integrity check.

I've had times where it's the FAT partition that's been corrupted, which has resulted in a boot failure. I can't say for sure (because they're usually headless and I can't SSH in to check anything) but I suspect this is potentially a reliability problem - bad FAT partition means never booting as far as being able to run anything.

Theo

Always keep a copy of the files on the first partition of the SD card.
They (copies) don't need to be on a FAT filesystem. Better even
cross-copy the boot files to another machine (rsync?).
--
Chris Elvidge, England
I WILL NOT WHITTLE HALL PASSES OUT OF SOAP

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Chris Elvidge <chris@internal.net> wrote:

On 09/06/2025 at 10:27, Theo wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 08 Jun 2025 10:18:05 +0100 (BST), Theo wrote:

... but the filesystem is broken. Which is to be expected if
it wasn't properly unmounted, but for some reason the automatic
fsck-and-reboot mechanism in PiOS doesn't seem to work.

There isn’t actually a need to do an fsck normally. If you were using ext4
(or even ext3), that includes a journal. On reboot, you should see a
message “replaying journal”, after which the filesystem should be back to
a consistent state. This should be very quick, much quicker than a
filesystem integrity check.

I've had times where it's the FAT partition that's been corrupted, which has
resulted in a boot failure. I can't say for sure (because they're usually headless and I can't SSH in to check anything) but I suspect this is potentially a reliability problem - bad FAT partition means never booting as
far as being able to run anything.

Theo

Always keep a copy of the files on the first partition of the SD card.
They (copies) don't need to be on a FAT filesystem. Better even
cross-copy the boot files to another machine (rsync?).

They're just the kernel and firmware, so trivial to recreate. But you can't
do that on a headless machine that doesn't boot.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 09 Jun 2025 10:27:35 +0100 (BST), Theo wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

There isn’t actually a need to do an fsck normally. If you were using
ext4 (or even ext3), that includes a journal. On reboot, you should see
a message “replaying journal”, after which the filesystem should be
back to a consistent state. This should be very quick, much quicker
than a filesystem integrity check.

I've had times where it's the FAT partition that's been corrupted, which
has resulted in a boot failure.

Ah, OK. FAT has no journal, of course, and being a simplistic filesystem design originating from the 8-bit era, it is particularly prone to
corruption.

Does the FAT partition need to be writable, at all? It seems to me you
want to put as little stuff on there as possible.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 09 Jun 2025 10:27:35 +0100 (BST), Theo wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

There isn’t actually a need to do an fsck normally. If you were using
ext4 (or even ext3), that includes a journal. On reboot, you should see
a message “replaying journal”, after which the filesystem should be
back to a consistent state. This should be very quick, much quicker
than a filesystem integrity check.

I've had times where it's the FAT partition that's been corrupted, which has resulted in a boot failure.

Ah, OK. FAT has no journal, of course, and being a simplistic filesystem design originating from the 8-bit era, it is particularly prone to corruption.

Does the FAT partition need to be writable, at all? It seems to me you
want to put as little stuff on there as possible.

Yes it does, because unattended-upgrades will install kernel updates there.

Ideally you want it mounted read-only the rest of the time, but that's not
what the OS does. You could have pre-/post- apt hooks for that, but it's getting into custom hackery territory. Because I tend to reflash from
scratch with minimal config, I just want it to be reliable out of the box.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In article <101teqs$1rt4d$2@dont-email.me>,
TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

I have a few (dozen) of these - 1B and 1B+ (40 pin GPIO header). I run an
older Debian Jessie on them for Linux and am experimenting with Devuan,
but I also have my own bare-metal framework under which I run either my
own RTB Basic (a modern basic where line numbers are optional) which
supports high resolution graphics but not (yet) sound. I can also run
my own OS under the same framework which is written in BCPL which allows
local editing and compiling of BCPL programs.

What I don't have is good USB support, so no USB serial,
Ethernet/Wi-Fi. Keyboard and mouse is the limit. The filing system is
VFAT but the SD card driver is somewhat creative and really needs more
work, but it's all a matter of time & energy.

I'm using the BCPL OS as the front-end to my campervan sensors and
monitoring project but that's just a personal thing so I can have nice graphics, but again things I can't do (yet) is read the touchscreen in
a nice way, so I'm looking at actually running the BCPL OS under a Linux
that does support nice USB things. (The core of it all is really just a
big (well, about 12KB) ARM32 assembler program that creates a VM for
the compiled BCPL code)

So that's something that the old Pi's are good for I guess.

-Gordon
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Gordon Henderson <gordon+usenet@drogon.net> wrote:

In article <101teqs$1rt4d$2@dont-email.me>,
TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B >(not even the B+) let me know, and I'll consider it :-)

I have a few (dozen) of these - 1B and 1B+ (40 pin GPIO header). I run an older Debian Jessie on them for Linux and am experimenting with Devuan,
but I also have my own bare-metal framework under which I run either my
own RTB Basic (a modern basic where line numbers are optional) which
supports high resolution graphics but not (yet) sound. I can also run
my own OS under the same framework which is written in BCPL which allows local editing and compiling of BCPL programs.

If you're going non-Linux, RISC OS runs well on the Pi1. It was designed
for an 0.5MB 8MHz ARM2, so a 512MB 700MHz Pi1 is ample. It can't use
multiple cores so the Pi1 being single core is no problem. Also it doesn't
do wifi so you'll have to use the ethernet anyway. Most apps are designed
to run on 1990s CPUs so a Pi is no sweat.

The main issue is likely to come for heavyweight apps like web browsers, but then you aren't running an ultra lightweight OS on underpowered hardware to surf the web anyway.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In article <kKm*zLLeA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Gordon Henderson <gordon+usenet@drogon.net> wrote:

In article <101teqs$1rt4d$2@dont-email.me>,
TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

I have a few (dozen) of these - 1B and 1B+ (40 pin GPIO header). I run an
older Debian Jessie on them for Linux and am experimenting with Devuan,
but I also have my own bare-metal framework under which I run either my
own RTB Basic (a modern basic where line numbers are optional) which
supports high resolution graphics but not (yet) sound. I can also run
my own OS under the same framework which is written in BCPL which allows
local editing and compiling of BCPL programs.

If you're going non-Linux, RISC OS runs well on the Pi1. It was designed

I know what it is and what it was designed for. I was there in the early
days, owned an Arc, have followed it's development over the years, etc.
I'm just not interested in it right now, thanks.

for an 0.5MB 8MHz ARM2, so a 512MB 700MHz Pi1 is ample. It can't use >multiple cores so the Pi1 being single core is no problem.

I have a scheme for multiple cores in my own system, (it's capable of pre-emptive multi-tasking) but not got the energy to implement it over
multiple cores for now.

This is it in it's original incarnation on a 16Mhz 65C816 CPU demonstrating multi-tasking:

https://www.youtube.com/watch?v=ZL1VI8ezgYc

The graphics is via a 115K serial link to a "smart" terminal running on
a Linux desktop. It uses Acorn VDU style commands for graphics, etc.

Over recent years I've ported it from the 816 to RISC-V and now to ARM32.

The Pi version has native graphics and works well on the Pi 7" screen
thing (or external HDMI). It boots to Basic or BCPL in under 2 seconds.

Thanks,

-Gordon
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Gordon Henderson <gordon+usenet@drogon.net> wrote:

In article <kKm*zLLeA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Gordon Henderson <gordon+usenet@drogon.net> wrote:

In article <101teqs$1rt4d$2@dont-email.me>,
TronNerd82 <tronnerd82@aol.com> wrote:

If you can think of any productive use-cases for an original Pi model B >> >(not even the B+) let me know, and I'll consider it :-)

I have a few (dozen) of these - 1B and 1B+ (40 pin GPIO header). I run an >> older Debian Jessie on them for Linux and am experimenting with Devuan,
but I also have my own bare-metal framework under which I run either my
own RTB Basic (a modern basic where line numbers are optional) which
supports high resolution graphics but not (yet) sound. I can also run
my own OS under the same framework which is written in BCPL which allows >> local editing and compiling of BCPL programs.

If you're going non-Linux, RISC OS runs well on the Pi1. It was designed

I know what it is and what it was designed for. I was there in the early days, owned an Arc, have followed it's development over the years, etc.
I'm just not interested in it right now, thanks.

That was aimed at the OP who was asking the question, not you :-)
If you've written your own OS I'm sure it works exactly how you want so no reason to use something else.

for an 0.5MB 8MHz ARM2, so a 512MB 700MHz Pi1 is ample. It can't use >multiple cores so the Pi1 being single core is no problem.

I have a scheme for multiple cores in my own system, (it's capable of pre-emptive multi-tasking) but not got the energy to implement it over multiple cores for now.

As long as you don't need synchronisation, there's not a lot to running multiple cores - you just set them going with different PCs. It's when they need to talk to each other, or you need them to work on the same data, then things get more complicated.

(in the case of RISC OS, a whole load of legacy APIs are not thread safe.
In a custom OS you control everything so you can avoid such problems)

This is it in it's original incarnation on a 16Mhz 65C816 CPU demonstrating multi-tasking:

https://www.youtube.com/watch?v=ZL1VI8ezgYc

The graphics is via a 115K serial link to a "smart" terminal running on
a Linux desktop. It uses Acorn VDU style commands for graphics, etc.

Looks neat. I see a certain Acorn heritage there too :)

(does that serial protocol have any similarity to the Tube, by any chance?)

Over recent years I've ported it from the 816 to RISC-V and now to ARM32.

The Pi version has native graphics and works well on the Pi 7" screen
thing (or external HDMI). It boots to Basic or BCPL in under 2 seconds.

That's the nice thing about not having to boot Linux or systemd...

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In article <jKm*77LeA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Gordon Henderson <gordon+usenet@drogon.net> wrote:

In article <kKm*zLLeA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

That was aimed at the OP who was asking the question, not you :-)

Hm. Maybe my threading got mixed up. No matter though.

If you've written your own OS I'm sure it works exactly how you want so no >reason to use something else.

Other than the sheer effort of getting "stuff" going where there is more
lines of verilog (or whatever) in the hardware than the software driver
needed to actually use it - e.g. USB... (or vice-versa, but essentially
things are now too complex to be fully understood by one person now)

for an 0.5MB 8MHz ARM2, so a 512MB 700MHz Pi1 is ample. It can't use
multiple cores so the Pi1 being single core is no problem.

I have a scheme for multiple cores in my own system, (it's capable of
pre-emptive multi-tasking) but not got the energy to implement it over
multiple cores for now.

As long as you don't need synchronisation, there's not a lot to running >multiple cores - you just set them going with different PCs. It's when they >need to talk to each other, or you need them to work on the same data, then >things get more complicated.

It's interestingly complex in my scenario in that there is a virtual
machine written in the native assembly language ('816, RISC-V or ARM32)
- it's like a sort of microcode and that's the level the multi-tasking
happens. Think Inmos Transputer if you know them... The neat thing is
that when I ported it from the '816 onwards it was/is binary compatible
from the output of the compilers point of view.

The one "big lock" needed right now is the memory allocator - it's a flat memory system with no MMU so all calls to it's equivalent of malloc()
need locking, but that's OK for now and I've been looking at other models
like CSP but time is limited and there's only so much I can do for what's really a little hobby.

(in the case of RISC OS, a whole load of legacy APIs are not thread safe.
In a custom OS you control everything so you can avoid such problems)

This is it in it's original incarnation on a 16Mhz 65C816 CPU demonstrating >> multi-tasking:

https://www.youtube.com/watch?v=ZL1VI8ezgYc

The graphics is via a 115K serial link to a "smart" terminal running on
a Linux desktop. It uses Acorn VDU style commands for graphics, etc.

Looks neat. I see a certain Acorn heritage there too :)

Well - that was the evolution. I started with a 65C02 system and made
it vaguely Apple II compatible, as that's the first 6502 system I used,
but then I wanted a better Basic, so threw that away and wrote an
Acorn MOS compatible OS for it - compatible to the point it will run
some Acornsoft ROMs unchanged including BBC Basic. The MOS has calls
you might expect like *exec, *spool, *. and so on... as well as enough
osbyte, osword, oscli, etc. to make BBC Basic happy.

(does that serial protocol have any similarity to the Tube, by any chance?)

I don't know as I've never done a deep dive into the Tube - but it's good enough for BBC Basic to run with most of the plot commands working as
they should - although the output resolution isn't scaled to 1280x1024
like the Beebs is but it's whatever the native resolution of the display happens to be.

So if you type

PLOT 4,0,0 : PLOT 4,200,200 : PLOT 85,200,0

in BBC Basic running on my '02 or '816 board with my smart serial terminal
it will draw a triangle.

If theory, if you used a temrinal program on a real Beeb and just had it echo what it got from the serial port to the screen it should "just work"... I've not
tried this yet.

Over recent years I've ported it from the 816 to RISC-V and now to ARM32.

The Pi version has native graphics and works well on the Pi 7" screen
thing (or external HDMI). It boots to Basic or BCPL in under 2 seconds.

That's the nice thing about not having to boot Linux or systemd...

But I may have to boot a Linux for my campervan project as I'd really like
to use a USB serial line to talk back to the MCUs that form the sensor network. Running the VM under Linux should be easy as the upper layers (in BCPL) assume a Posix style interface to the underlying whatever. What's another 20 million lines of code in a little hobby project anyway...

-Gordon
(Probably the 2nd last person on the planet to code in BCPL)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 11/06/2025 12:06, Gordon Henderson wrote:

I have a few (dozen) of these - 1B and 1B+ (40 pin GPIO header). I run an older Debian Jessie on them for Linux and am experimenting with Devuan,
but I also have my own bare-metal framework under which I run either my
own RTB Basic (a modern basic where line numbers are optional) which
supports high resolution graphics but not (yet) sound.

Talking of bare metal; you can run Circuit Python on the Pi without the
OS. After all the original 1B is closer in memory footprint and
performance to the Pico than it is to the 5B.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 07/06/2025 08:36, Computer Nerd Kev wrote:

Andy Burns <usenet@andyburns.uk> wrote:
I didn't watch the video but I'm posting from an old laptop with
only slightly better specs (1GHz CPU, 768MB RAM),

I think a typical single thread 1GHz x86 CPU can probably totally knock
the spots off a single thread 700MHz ARMv6 CPU.
--
Brian Gregory (in England).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-06-06, TronNerd82 <tronnerd82@aol.com> wrote:

As the subject header would imply, this morning I got a Raspberry Pi 1
model B from eBay. I was initially tempted to futz around with Slackware
ARM on it, but that distro last supported the Pi 1 in version 14.2,
while the latest stable, 15.0, doesn't support it.

Raspberry Pi OS was right out since I recently saw its performance in
the modern day in a recent Jeff Geerling video on YT.

So I went with the best possible choice for a fast and reliable OS on
such old hardware: NetBSD.
So far, things have been pretty decent, especially in the TTY. In X11
there's not a whole lot I can run at once, but it's OK for light
websites (as in, SUPER-light - even SearXNG will crash most browsers I
try).

But aside from super light work, what can I actually do with this thing?
I doubt emulation's much of an option, and I remember seeing one of
these running Quake, so that might be worthwhile to get working.

If you can think of any productive use-cases for an original Pi model B
(not even the B+) let me know, and I'll consider it :-)

I have an original Model B rev 1 with 26way GPIO and only 256M RAM
which I must admit I don't use much.

But my Raspberry Pi 1 Model B rev 2 with 26way GPIO and 512M RAM is
hooked upto a Gert Board, and I use it for my odd forays into AVR chip programming, and to play interfacing.

My RPI 1B+ with 40way GPIO and 512M RAM was until 6 months ago my backup server. It had a 1GB USB2 attached hard drive, and it could be powered
on and off from my Pi4B home server to do a secondary backup of
important stuff. Backup was using rsync so only changes saved, and yes
it was slow, but it all happenned automagically at night for many years.
Been replaced by a 3B+ and a bigger disk connected by a powered USB3
adapter.

I would only run the early Pi's headless. They'd make a reasonable time server, DNS server, probably even pi-hole. My god, we used to NFS serve
home directories for a couple of biggish labs of Linux machines from a
Sparc server with 32M RAM in the 1990's :-) It's amazing how little
grunt you need for some jobs.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Tue, 17 Jun 2025 20:37:51 -0000 (UTC), Jim Jackson wrote:

My god, we used to NFS serve home directories for a couple of
biggish labs of Linux machines from a Sparc server with 32M RAM in
the 1990's :-) It's amazing how little grunt you need for some jobs.

Back then, servers were considered the big, grunty machines, while clients were expected to be somewhat wimpy and lightweight in comparison.

Nowadays, a typical web browser is far more complex and resource-hungry
than any web server ...
--- Synchronet 3.21a-Linux NewsLink 1.2