[Debian-lego-team] RCX packages (Was: Re: Bug#1091823: ITS: brickos)

[Nicolas Schodet]

Hi Matthew,

Thanks for your email, it’s always nice to see you are not alone working
on those old software :)

* Matthew Sheets <mesheets at hotmail.com> [2025-04-10 04:05]:
> Seeing some of the recent email traffic regarding the h3800 toolchain
> and other RCX packages, I thought I would provide additional follow
> up.
> In continuing to maintain BrickOS, maintaining the h8300-hitachi-coff
> toolchain has turned into a side quest, with the repository (including
> GitHub Actions running in Ubuntu) available at the link below.  The
> cross-toolchain is building, but I have been trying to get a native
> build going so that the tests can execute.  Towards that end, there
> are a few extra things that need to be addressed when building on
> Debian, as multiarch wasn't introduced into GCC until v4.6 / v4.7
> (patches were released for both at the same time).
> • https://github.com/BrickBot/GNU-Legacy-Toolchain

Can you explain why native build is required to pass the tests? Does it
need to use this gcc to compile programs running on the build machine?

While reading your CI script, “needed to prevent gcc/c-parse.c from
sometimes being regenerated during build”: this one should be fixed by
010_fix_bison.patch.

> There are at least three use cases of which I am aware that have
> supported the continued of GCC 3.4:
>  • h8300-hitachi-coff
>  • GNU Pascal Compiler (GPC)
>  • GNU Fortan 77 Compiler (g77)
> The GPC aspect is doubly intriguing because in the version of BrickOS
> that was (and still is) available through Bricx Command Center
> (BricxCC), both a Pascal library and a GPC cross-compiler were
> provided (with, of course, that GPC cross-compiler being build to run
> on Windows like BricxCC itself).  The Pascal library for BrickOS
> targeted an older version, but on my list is to bring that current and
> incorporate it.
> If the h8300 toolchain is switched from h8300-hitachi-coff to a newer
> version of GCC that instead uses ELF, that newer GCC version would
> likely cause GPC support to be lost.

I do not intend to switch to elf, brickos depends on the coff target and
I have no interest in trying to do the switch, so you are safe on this
side :)

> In another email here, there was a question about lnpd.  In the
> version of BrickOS that I have been maintaining, this has been
> deprecated and replaced by a newer utility that was introduced to
> support the BrickEmu emulator.

We actually decided to stop shipping lnpd seeing your deprecation
notice.

> At a high level, communicating with BrickEmu effectively involved
> adding a TCP communication support in additional to the serial and
> (later) USB options that existed in RCX tools.  The versions of both
> BrickOS-Bibo and NQC for *nix under the BrickBot organization on
> GitHub have both been updated to support this.  (Through the NQC
> update, VisualNQC [an icon-based programming environment] also
> supports this.)

Thanks for all the details about this. I would like to package BrickEmu
first, which could be an easy target.

About brickos, it seems to be sufficiently different than bibo that both
may be packaged separately, what do you think?

GDB would be nice to have too.

> [...]
> This TCP utility can be used multiple different ways, including
> serving as a hub to virtually reflect TCP communication like one might
> expect of an IR-based experience in a room (e.g. multiple RCX device
> communicating with each other, a PC-based IR tower broadcasting to all
> RCX devices) or communicating through a physical IR tower connected to
> a remote system.  This newer tool is available in both the
> BrickOS-Bibo repository and the BrickEmu repository, but the version
> in BrickOS has more features.

Can it combine a real tower with the virtual one?

> Per the earlier feedback in this thread, I understand that updated
> releases for each of these would need to be properly packaged and
> version for Debian to be able to use them, but once past the compiler
> situation I hope to get to that….

We are preparing a Debian release in the next few weeks, so it is
unlikely to be ready on time, but after this, I am open to work on
packaging more tools for the RCX, and keep some time to actually play
with the real brick :)

For brickos and bibo: I have to look at the patches that you took in
your repository, and decide whether we need to have both or just replace
the brickos package with bibo.

For nqc, I may set your repository as the new upstream, this may be an
easy target.

For gpc, I am not very familiar with pascal, so I do not have too much
interest in it, are there many potential users?

For brickemu, and gdb, this looks very interesting.

Maybe the virtual tower could be packaged separately, I have to try and
get familiar with it.

For visualnqc, I do not have a large personal interest for it myself,
because, yeah… GUI and java… but I may give it a try.

For everything, licensing must be clear and dfsg[1] free to be included
in Debian. I can strip out some parts on import time if needed (like the
LEGO firmwares for example). Actually the LEGO firmware may be included
in a separate non-free package, but distribution must be allowed by
LEGO, I don’t know if this is the case.

The team list is moderated, so I hope your mails will all go through,
are you subscribed to the list?

Thanks and happy building!

Nicolas.

[1]: https://wiki.debian.org/DebianFreeSoftwareGuidelines