[Debian-lego-team] Bug#1091823: ITS: brickos

[Matthew Sheets]

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

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.


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

BrickEmu supports sideloading of both firmware and—for BrickOS-style firmwares—the sideloading of individual programs as well.  This greatly reduced cycle times, and without this I might still be trying to fix the dkey_wait() and getchar() call that would effectively lock the firmware to the point that the batteries would need to be pulled and the firmware reloaded.  Additionally, BrickEmu also supports the ability to support GDB.  (The h3800-hitachi-hms was supported up through GDB 7.12.1.)


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.


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


Thank you,
Matthew

https://brickbot.github.io/
https://github.com/BrickBot/

There are nearly 90 repositories, but those specifically referenced in this message include the following:
 • https://github.com/BrickBot/brickOS-bibo
 • https://github.com/BrickBot/brickEmu
 • https://github.com/BrickBot/nqc
 • https://github.com/BrickBot/nqc-libs
 • https://github.com/BrickBot/VisualNQC

Referenced in this message but deprecated within BrickBot:
 • https://github.com/BrickBot/lnpd
 • https://github.com/BrickBot/lnphost