andy_threos_io

    2010–2024: Wireless voting system for a bank’s annual shareholder meetings.

        ARM-based handheld terminals with 2.4GHz RF and LDPC error correction

        Custom embedded OS, base stations, and 3D-printed enclosures

        Deployed and used continuously for 14 years

    2006–2014: Distributed IoT platform (prototype)

        Embedded VM and bytecode execution on custom hardware

        Desktop CAD-style app for dataflow programming

        Fully working prototype demonstrated at trade shows

    2014–2017: Hardware/software unit for tax inspection system

        Project delivered; final deployment halted due to partner backing out

    2015–Present: Threos OS (https://threos.io)

        Object-oriented, modular real-time operating system

        Single virtual address space with memory protection, multitasking

        POSIX subset, package manager, dynamic linking and relocation

        Dynamically linked libraries

        Ported applications: GCC, Python, nano, etc.

        Functional on x86_64 hardware

    2017–2021+: Remote network monitoring system for a telecom company

        1U embedded Linux device with modular IO, deployed and in daily use

        Web-based configuration UI

        Modules: LTE, environmental sensors, backup battery

    2020–2025: Wireless IoT system for utility monitoring

        Proprietary RF protocol over 433MHz LoRa

        Battery-backed modules for impulse counting, DSMR, environmental monitoring

        Gateway with LTE, Wi-Fi, and LoRa, managed via web UI

        Fully functional prototype state

  Location: EU / Hungary
  Remote: Yes
  Willing to relocate: Mostly no, but open if absolutely necessary
  Technologies: Embedded systems, OS development, C/C++, Assembly, Python, Java, Lua, JavaScript, TypeScript, React
  Résumé/CV: Available on request
  Email: [email protected]

We’re a small team of experienced developers based in the EU, looking for new contract opportunities. We're at a transition point and open to engaging with new projects, especially those that value deep technical expertise and long-term reliability.

We’ve worked across various hardware/software domains, including embedded systems, custom operating systems, and networked IoT platforms. Some highlights of our work:

  next comment

    Me – Product manager, embedded senior dev, hardware design reviewer, Threos OS architect, C/C++/asm/Python/JS and others, some Django, 3D design

    Teammate 1 – Software developer/designer (C/C++ and others)

    Teammate 2 – Software developer/designer (C/C++, JavaScript, TypeScript and others)

We love working on challenging technical projects—especially those involving embedded systems, custom hardware, or low-level software. We're not afraid to roll our own solutions when needed, whether that's a communication protocol, a lightweight virtual machine, or a custom scheduler. If you think we might be a good fit for your team or project, feel free to reach out at [email protected]. We'd love to hear from you.

The implementation should store a state machine for the game, a struct for each pieces, and also the board with index to the pieces (occupation).

There is only 16 pieces for each player, the two players move one another.

The Naive would be that you index the pieces (4 bits) and store the movement after that,

Pawns 2 bits for movement (2 forward, 2 diagonal)

King 4 bits for movement (normal move 1 + 3 bits, castle 1 + 1 bits)

Knight 3 bits for movement (8 possible move)

Rook 4 bits for movement ( 1 bit orientation horizontal/vertical 3 bit new position )

Bishop 4 bits for movement ( 1 bit orientation left/right diagonal 3 bit new position)

Queen 5 bits for movement ( 2 bit orientation horizontal/vertical/ left/right diagonal 3 bits for new position)

This way you need

Pawn 4 (index) + 2 (movement) = 6 bits

King 4 (index) + 4 (movement) = 8 bits

Knight 4 (index) + 3 (movement) = 7 bits

Rook, Bishop 4 (index) + 4 (movement) = 8 bits

Queen 4 (index) + 5 (movement) = 9 bits

But you can encode the pieces index in another way, that the Queen got 3 bit index and other pieces got longer index (Pawn 5 bits)

index bits + movement 000 + 5 movement Queen -> 8 bits

00100 + 3 movement King Normal -> 8 bits

00101 + 1 movement King castle -> 6 bits

0011x + 3 movement Knight (2) -> 8 bits

01xxx + 2 movement Pawn (8) -> 7 bits

10x + 4 movement Bishop (2) -> 7 bits

11x + 4 movement Rook (2) -> 7 bits

Also other bit allocations are possible, I don't know if it's worth it to make the Pawns index 1 bit longer, but in this way the max 8 bits required for a movement. (You need the state machine for the "decompression", also have to track that the black and white Pawns are moving in the opposite direction. )

There can be further compression, if you check the possible move for the piece. ex. the first possible Knight movement is only 1 place, so no need to store the movement. But this need more calculation.

Example.

In file threadx-master/ports/cortex_a7/gnu/src/tx_thread_schedule.S

in this code

    /* Increment the run count for this thread.  */

    LDR     r2, [r0, #4]                    // Pickup run counter
    LDR     r3, [r0, #24]                   // Pickup time-slice for this thread
    ADD     r2, r2, #1                      // Increment thread run-counter
    STR     r2, [r0, #4]                    // Store the new run counter

But it can be made it easier, with another layer and macro preprocessing. So make a header one for the assembly and one for the C code, and define the struct with the macro. The assembly code can be compiled with C preprocessor, so the macros will work.

This way the C and the ASM stay sync. Only drawback, that the struct must be defined with this macros. But this is only for the structures that are used both in assembly and C or higher level.

Anyway if the indexes in the assembly code would be macros, that would be also much easier to modify.

G codes in fact have command for arcs.

G02 establishes a mode for clockwise circular arcs. G03 establishes a mode for counter-clockwise circular arcs.

  -no segmentation, flat address space
  -better interrupt handling
  -better system call
  -more registers
  etc.

All sort of magic happens in BIOS, but after transition to 64bit, it should be fine.

The only problem is when BIOS programs some kind of hardware (usb), to write things into the memory like descriptors etc. and the hardware will overwrite portion of the memory.

This happens on some board with some versions of u-boot for ARM. There you should disable all the hardware devices before running your kernel, u-boot may be left the device enabled.