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

Fri Apr 11 00:47:37 BST 2025

Hello Nicolas,

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

Indeed—same here!

> 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?

It was based on this thread with the owner of the repository that has the GPC patches posted, in particular the last couple paragraphs.
 • https://github.com/hebisch/gpc/issues/3#issuecomment-2333996289

Technically, the tests aren't need, but passing tests should theoretically provide a level of assurance that what was built still functions as expected.  I feel so close and yet so very far away at the same time:  I'm getting messages like "libgcc.a: file not recognized: file format not recognized".  From what I have been able to find, that can perhaps be a problem between 32-bit and 64-bit binaries, but it seems I end up with that message no matter what I try.  I even tried building on openSUSE Tumbleweed, if perchance I didn't have something right in the basic multiarch backport I've attempted on the "multiarch-backport" branch, but it has ultimately ended up being basically about the same issue there, too.  If a native build is not needed, I might be getting close to the point where I can be easily convinced otherwise….

> 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.

Nice, thank you, I will try removing that step.

> I would like to package BrickEmu
> first, which could be an easy target.

That would be great!  I do need to note a few things about BrickEmu in that regard:
 (1) The configuration/makefile setup is very basic and not quite as full-featured as BrickOS-Bibo.
 (2) I could only ever get the original BrickEmu source code to run for about 12 minutes or so.  From what I was able to ascertain in troubleshooting, the problem was due to a 32-bit rollover.  There seemed to be a lot of cascading dependencies and impacts, so my (very) hackish approach was to define a cycle_count_t type that is currently "unsigned long long."  I have not yet merged this from the "cycle-count-typedef" branch to the master branch, but it seems to be at a stable "works for me" status.
 • https://github.com/BrickBot/brickEmu/issues/2
 • https://github.com/BrickBot/brickEmu/blob/c3e7f0d17fee12491d77f88801d5e4b99a9a26cc/types.h#L38
 (3) There are some processor-specific assembly sources that per my understanding facilitate a deeper level of debugging; however, I have not been able to get the x86-64 assembly sources to build and have updated the Makefile so it doesn't attempt to compile the assembly sources when building for x86-64.  Also, it seems some folks are looking to use the Debian packages on ARM devices like the Raspberry Pi, and there are currently no ARM or ARM64 assembly sources.
 • https://github.com/BrickBot/brickEmu/issues/1
 (4) Even if sound builds, hearing RCX sounds via the emulator might be an issue.  Maybe this is just limited to Windows Subsystem for Linux v2, though?
 • https://github.com/BrickBot/brickEmu/issues/7

All that said, I have found BrickEmu to be a very valuable asset to development work.  I have added a number of "demo" program to BrickOS which not only serve to demonstrate how to do various things but also provide a way quickly to test and exercise functionality before committing code or publishing a release.

> About brickos, it seems to be sufficiently different than bibo that both
> may be packaged separately, what do you think?
One could probably make a case either way.  Based the bibo documentation, "the main incompatibility is that there are no time slices any more."  From what I've seen in the code, a lot of it is basically the same BrickOS.  For example, the dkey_wait() / getchar() bug that was present on BrickOS was still present after the Bibo patches.  By and large, most code written for BrickOS should also build for BrickOS-Bibo.  I made a change to how motor power is set, which also now allows reading the motor power, and while that did introduce a breaking change in the API, a few #defines could make it backwards compatible.  I've also done some work to reduce the firmware size.  The two lists below should capture most of the changes introduced since the last "official" release of BrickOS on SourceForge.
 • https://news.lugnet.com/robotics/rcx/legos/?n=4057
 • https://github.com/BrickBot/brickOS-bibo/blob/master/CONTRIBUTORS

An example of something that might on the surface seem like a breaking change is that string support is no longer included by default—at least to a couple of us working on it at the time, it used far too much space compared to the value provided.  Text (and even free-style LDC manipulation) can still be written to the display, but now you just use #defined CHAR_* values.  For example, to write the word "hello" in just 4 characters on the LCD, one can use CHAR_H, CHAR_E, CHAR_PARALLEL, CHAR_O ("HEllO").  It's a little more to type out but seemed a worthwhile tradeoff compared to the space reclaimed.  If someone still really wants string support, it is still there and just need to be enabled in the include/config.h file.

Also:  I have not yet investigated this, but the dkey_wait() / getchar() issue sounds a lot like this rotation sensor issue that was reported.  Putting things on their own waitqueue seem to address that issue, so perhaps the same might be needed here?
 • https://news.lugnet.com/robotics/rcx/legos/?n=4060
 • The dkey_wait() / getchar() fix:
    – https://github.com/BrickBot/brickOS-bibo/commit/d9fe641b2c37d0ed53c32255a5a9a8741b23ce69

> Can [the TCP utility] combine a real tower with the virtual one?

Yes, which should enable scenarios such as having physical and virtual RCXs communicate with each other, using a remote to send the same message to both, etc.  I also added an "upstream" link option so that two different instances of the TCP utility could work with each other.  Because each TCP utility can also have its own physically-connected IR tower, this also opens up scenarios such as having physical RCX devices that are in separate physical locations communicate with each other.

In a more advanced scenario, I think this should make it possible for USB devices to be usable under 64-bit Windows by leveraging usbipd-win and WSL.  I have successfully recompiled the WSL kernel and configured usbipd-win to recognize the LEGO USB IR tower, and combined with a com0com+com2tcp setup on the Windows side and the TCP utility on the WSL side, I think USB towers should be usable with Windows apps again.
 • https://github.com/BrickBot/Archive/releases/tag/com0com

The basic version of this utility (ir-server) is in BrickEmu; the one with more advanced capabilities is in BrickOS so as to more readily reuse the standard/common capabilities for those tools.  (I brought other tools into BrickOS, such as lnpmsg, for that same reusability reason.)

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

Compared to BrickOS, the changes there were comparatively minor and more along the lines of enhancements.  I've thought about aligning the NQC tty conventions with the BrickOS ecosystem, but if I recall correctly, NQC is still not at parity with what BrickOS supports (though the changes do help towards that end).

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

I'm not sure.  I've been intrigued by the various different programming languages for which folks added support.  Among the BrickOS updates are support for xs:Lisp (tools included with BrickOS) and Esterel (requires a binary download).  The Esterel part will be skipped if the Esterel compiler is not detected.  Other languages not yet incorporated include Cyclone (open source) and .NET (based on support added to a separate branch of GCC).

Despite all the RCX projects already uploaded to GitHub, I still have more yet waiting to be uploaded.  The amount of low-level hacking and tinkering that took place with the RCX is quite intriguing in and of itself.  Many probably won't end up getting packaged, but it's still nice to preserve for reference, and some I've been working to incorporate into more established projects (like adding the capabilities of the On-Screen Programming firmware as a BrickOS program).

> For everything, licensing must be clear and dfsg[1] free to be included
> in Debian.

I don't anticipate any such issues, but if there is anything in the work I've done that might need a licensing change, I'm open to doing so.  Except for a random pull request to update the NQC readme.md file, I've pretty much been the only person committing code under BrickBot on GitHub.

> We are preparing a Debian release in the next few weeks, so it is
> unlikely to be ready on time

Agree there is likely more here than will fit within that timeframe, so no worries there.

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

Yes, I have been receiving "Debian FTP Masters" emails and other email communication on this Debian Lego team list, so hopefully everything will get through.

Thank you,
Matthew

________________________________________
From: Nicolas Schodet <nico at ni.fr.eu.org>
Sent: Thursday, April 10, 2025 4:06 PM
To: Matthew Sheets <mesheets at hotmail.com>
Cc: Debian LEGO Team <debian-lego-team at lists.alioth.debian.org>
Subject: RCX packages (Was: Re: [Debian-lego-team] Bug#1091823: ITS: brickos)

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