MMUKO-BOOT: Understanding a Nonpolar, Nonlinear Boot Sequence

By Nnamdi Michael Okpala — Obinexus Uche, OBINexus R&D

Repository: github.com/obinexus/mmuko-boot

This article describes the supplied 0.1-qemu source snapshot. It separates the ringbooting concept, the current implementation, and the work needed to connect them.

Begin with a room, not a computer

Imagine that eight people are sitting around a circular table.

Each person holds a card showing either 0 or 1. If you only want to record the cards, you can write down eight digits and call the job finished.

But suppose the relationships matter too.

Who is beside whom? Which people are paired? Where should the group consider its starting point? If everyone changes position, what should remain the same?

Now you are describing more than a collection of values. You are describing values together with a structure.

That is the simplest way into MMUKO-BOOT.

An ordinary byte contains eight bits. MMUKO represents those bits using an eight-position cubit ring, attaching direction, state and relationship information to each position.

The question behind the project is:

Can startup establish and check a useful arrangement of relationships before handing control to the next program?

I call the broader exploration ringbooting.

To understand it, we need to keep three things separate: how the processor starts, how the software represents information, and what its checks actually establish.

1. What happens when a computer boots?

When you turn on a computer, it cannot immediately run an ordinary application. Some earlier software must prepare the conditions that application depends on.

A simplified startup story is:

1. Firmware begins running.
2. A loader places the kernel in memory.
3. The processor enters the required execution environment.
4. The kernel initializes enough of the machine to continue.
5. A program or service receives control.

Think of opening a workshop. Before anyone can use the tools, someone must unlock the building, turn on the lights and check the equipment.

Real boot systems can already support fallback paths, recovery and verification. They are more capable than a single fragile chain.

MMUKO-BOOT explores a particular additional layer: an explicit model of oriented bits and their relationships during kernel initialization.

Its current hardware entry remains conventional.

In the direct BIOS path, boot16.s loads the kernel from disk into memory at 0x10000, switches into 32-bit protected mode and transfers control to the kernel entry code. That entry code calls kernel_main().

The alternative path uses GRUB Multiboot to reach the kernel.

Both paths lead to the same MMUKO initialization model. The processor continues to execute ordinary instructions.

The experiment begins in how the kernel organizes and resolves its software state.

2. A cubit is a bit with additional information

Let us return to the circular table.

A person's card is the bit value. Their seat is the index. Their assigned compass label is the direction. Their relationship to another person is the pairing.

In the source, a cubit carries information including:

Field	Plain-language meaning
value	The underlying bit: 0 or 1
index	Its position in the eight-element ring
direction	Its assigned compass label
state	A classification derived initially from neighboring bits
spin_mrad	A stored angular tag
entangled_with	The index of a designated partner, or no partner

The eight direction labels are North, Northeast, East, Southeast, South, Southwest, West and Northwest.

They are software labels. The computer does not need a physical compass.

Likewise, cubit is this project's term for a decorated bit. It does not imply a quantum processor. The implementation stores ordinary integers, enumerations and Boolean values.

Words such as spin, superposition and entanglement provide conceptual vocabulary, but their computational meanings must remain explicit.

In this implementation:

• Spin is a stored angular tag.
• Superposition includes an ordered pair of direction labels.
• Entanglement refers to a local pairing rule within a byte.

There are no quantum probability amplitudes or quantum measurements in these structures.

The representation also costs memory. An MMUKO_Byte occupies more space than one ordinary byte because it stores eight cubit records and additional metadata. The scaffold models 16 raw byte values; it does not map the machine's entire RAM into rings.

These definitions are visible in kernel.c.

3. How does a bit acquire a state?

The initial state rule is small enough to explain without specialist knowledge.

Look at one bit. Then look at the next bit around the ring.

The pair determines the state:

Current bit	Next bit	Initial state
1	1	UP
1	0	CHARM
0	1	STRANGE
0	0	DOWN

The final position wraps around to the first position. That wraparound makes the neighborhood circular.

For example, if your card says 1 and your neighbor's card says 0, your initial label is CHARM.

The name is a label for a particular input combination. The useful computational fact is the relationship between two bits.

The state enumeration also includes LEFT and RIGHT, although this initialization rule produces the four states shown above.

This is an important habit when explaining a system: start with the actual rule, then attach the vocabulary to it.

4. What do I mean by “nonpolar”?

Imagine putting a map on the circular table.

You can turn the map without changing which towns connect to which roads. However, everyone needs to know which orientation they are currently using.

The nonpolar design idea is to make orientation explicit and, eventually, changeable without confusing a coordinate choice with the underlying relationships.

That ambition needs a qualification in this version.

The current kernel chooses a fixed anchor.

During frame centering, it looks up base 6. That table entry contains Southwest as the primary direction and East as the secondary direction. The system therefore adopts Southwest as its frame of reference.

Executing that lookup at runtime does not make the choice adaptive. With the supplied table and code, it selects the same anchor.

So the accurate description is that MMUKO-BOOT explores a nonpolar representation while the present scaffold uses a fixed reference policy.

A stronger implementation would need to demonstrate what happens when that policy changes. If we consistently relabel the directions, do the relevant relationships and outcomes remain equivalent?

That is something we can test. The word nonpolar alone does not establish it.

5. What do I mean by “nonlinear”?

Think about inspecting a building.

You might check water, then electrical power, then access routes, then structural supports. The useful order need not match the order in which the rooms are numbered.

MMUKO's diamond traversal visits its selected base labels in this order:

12 → 6 → 8 → 4 → 10 → 2 → 1

Here, base means a classification label used by the model. It does not mean that the processor changes between number systems such as binary, octal and hexadecimal.

The kernel initially calculates a byte's label using:

base_index = (raw_value % 12) + 1;

This produces labels from 1 through 12.

Phase 5 then visits the seven selected labels in the diamond order. For each label, it scans the modeled bytes and updates the direction pair of those with an exact matching base_index.

The implementation still executes sequentially. Its loops still scan the memory array in ordinary index order.

Consequently, “nonlinear” currently describes the project's chosen nonascending resolution order, rather than a demonstrated nonlinear dynamical system.

The code has no adaptive phase scheduler or feedback-driven convergence loop yet.

Those distinctions help us formulate the next engineering question: what should determine which unresolved relationship is processed next?

6. Walking through the actual boot phases

The uploaded kernel implements phases 0 through 7.

The four words SPARSE, REMEMBER, ACTIVE and VERIFY can be useful conceptual groupings, but they are not the phase labels emitted by this source snapshot.

Here is the implemented sequence:

Phase	Operation	Everyday explanation
0	Initialize the vacuum medium	Set the background configuration
1	Initialize cubit rings	Give every modeled bit its position and metadata
2	Align compass directions	Resolve direction labels where necessary
3	Resolve paired states	Apply the rule for designated partners
4	Center the reference frame	Establish the shared orientation
5	Traverse selected bases	Apply direction pairs in the diamond order
6	Check double rotation	Check a particular reversible bit operation
7	Mark boot complete	Permit the example program to run

Phase 0: establish the background

The “vacuum medium” is a structure containing three constants.

The kernel initializes gravity_milli to 9800, and the air and water fields to zero.

In the workshop analogy, this is preparing a configuration sheet. It does not create a physical vacuum or simulate gravity acting on memory.

These fields provide vocabulary and storage for future environmental policies. The present boot logic does not use them to implement a physical model.

Phase 1: build the rings

For each modeled raw byte, the kernel extracts the eight bit values and assigns their metadata.

Imagine giving everyone at the table a seat number, a direction label and a relationship card.

The ring is now a concrete data structure that later phases can inspect.

Phase 2: establish direction

If a cubit's direction is undefined, the kernel examines its two neighboring directions.

The exact fallback behavior matters here. The current function can select a neighboring direction, favors the first examined neighbor when the counts tie, and defaults to North when neither neighbor supplies a direction.

It does not preserve all unresolved cases as uncertainty.

Furthermore, normal initialization already assigns every direction. The ordinary demonstration therefore does not exercise this repair path.

To demonstrate meaningful uncertainty handling, a future test must deliberately introduce missing or conflicting information and check the resulting decision.

Phase 3: apply the pairing rule

The kernel pairs positions 0↔7, 1↔6 and 2↔5. Positions 3 and 4 have no designated partner.

These are the actual lookup-table relationships. They are not all geometrically opposite compass positions.

When paired cubits have the same state, the kernel changes the partner's state through flip_state().

For example, UP flips to DOWN, while CHARM flips to STRANGE.

This changes state metadata. It does not automatically change the underlying bit value.

The engineering consequence is that we must specify what the state field means after resolution: it can no longer be understood solely as the original neighboring-bit classification.

Phase 4: choose a shared reference

The kernel selects the base-6 Southwest/East pair and copies it into every modeled byte. Southwest becomes the system frame.

At the table, everyone now knows which way the shared map is facing.

The choice is explicit and inspectable, although currently fixed.

Phase 5: follow the diamond traversal

The kernel visits the seven selected base labels and writes their corresponding direction pairs into matching bytes.

There is a useful edge case here.

Initialization can produce labels 3, 5, 7, 9 and 11, but the traversal does not visit those labels directly.

Because Phase 4 has already assigned its common pair to every byte, those unmatched labels retain that pair in the current kernel.

An initial nearest-known-base lookup is not the same thing as later resolving every original label.

This is precisely the kind of detail that turns a conceptual explanation into an inspectable specification.

Phase 6: perform the rotation check

The kernel takes each cubit's stored value, rotates it four bit positions, rotates it another four positions, and compares it with the original.

That brings us to the most important distinction in the verification story.

7. Returning to the beginning is a limited test

Turn a circular arrangement halfway around. Then turn it halfway around again.

You have completed a full turn.

For an eight-bit rotation operation:

rotate(rotate(x, 4), 4) == x

This identity holds for every eight-bit value when the operation is implemented correctly.

The current check applies that operation to each cubit's value, which is normally 0 or 1. It does not rotate the entire cubit structure and validate all its direction, state and pairing relationships.

What does it establish?

It checks a simple property of the implemented bit operation.

It does not establish that:

• the whole system will continue making progress;
• all metadata remains consistent;
• hardware is healthy;
• tampering has been detected;
• every required boot transition can complete.

A useful analogy is opening a door and closing it again. That demonstrates something about the door's movement. It does not demonstrate that the whole building is safe.

Even a proposed test requiring eight distinct rotations would need care. The valid pattern 01010101 repeats after two positions. Its symmetry is not a fault.

A stronger verifier must define which transformations are permitted, which relationships must remain consistent, and which repeated patterns are valid.

Verification becomes meaningful when the property being checked is stated precisely.

8. What happens after boot succeeds?

The boot routine returns BOOT_OK only after its implemented phases have completed successfully.

kernel_main() then calls the example mmuko_program_main().

That program rotates the first raw byte by one bit position, rebuilds its cubit ring, prints a checksum and displays selected cubit metadata.

The initial first byte is 0x2A, or decimal 42. A one-position right rotation produces 0x15, or decimal 21.

This provides a concrete demonstration that the scaffold can enter its kernel, run the phase pipeline and launch a small program afterward.

It is still an early kernel scaffold. It does not yet supply a general application environment, scheduler or comprehensive hardware recovery system.

After the example, the kernel enters a halt loop.

The source also needs to maintain consistency when a raw value changes. Rebuilding its cubits is one part of that job; recomputing any dependent base classification is another.

That is a practical next step for developing the model beyond initialization.

9. Where does NSIGII belong?

In the wider design discussion, NSIGII represents a verification boundary.

The relevant aspiration is that a component's claim of success should be supported by evidence that another part of the system can evaluate.

However, this uploaded mmuko-boot snapshot does not implement an NSIGII verification protocol or emit NSIGII_VERIFIED.

Its printed checksum is not a cryptographic attestation, and a success message is not an independent proof.

A future integration should specify:

• what evidence a boot phase produces;
• which component checks that evidence;
• which failures the check can detect;
• how uncertainty remains visible;
• what action follows a failed check.

That would give the verification boundary an explicit contract.

The current scaffold provides places where those checks could be added.

10. Trying the experiment

The repository contains several ways to explore the model.

For the Python simulator:

python mmuko_bootsim.py --bytes 00 ff 2a --bases 12 6 8

This runs a hosted simulation. It does not boot a machine.

The simulator and kernel also have differences, including their default base assignment and some resolution behavior. They should be treated as related implementations that need conformance tests.

For the Windows direct BIOS image, with the required toolchain installed:

.\build-direct.ps1

Then:

qemu-system-i386 -drive format=raw,file=build\mmuko-direct.img,if=ide,index=0 -display none -serial stdio -no-reboot

For the GRUB path, with its cross-compiler and supporting tools:

make
make run

The supplied Makefile also contains direct and run-direct targets. It does not contain a ringboot target.

The exact entry paths and prerequisites are documented in the repository's README.

11. What would make the next version stronger?

The next useful advance is to make the model's promises measurable.

First, define how every field changes when a ring rotates. Specify what happens to indexes, direction labels, pairing references and derived state.

Second, test different reference frames. A configurable anchor is useful; evidence that the system behaves consistently under the intended changes of orientation is stronger.

Third, give unresolved information an explicit policy. A default direction may be acceptable in one situation and unsafe in another. The code should make that distinction visible.

Fourth, specify bounded repair. If resolving one relationship affects another, the system needs a rule for revisiting it, a stopping condition and a clear outcome when convergence fails. Repeating phases alone does not prove convergence or mathematical nonlinearity.

Finally, compare implementations against the same examples. A simulator, hosted C model and freestanding kernel should agree wherever they claim to implement the same semantics.

These steps would let us move from a vocabulary for ringbooting toward a reproducible account of its behavior.

12. The idea I want readers to carry away

Return once more to the eight people around the table.

The cards matter. So do the seats, the relationships and the shared understanding of direction.

MMUKO-BOOT explores how to make those additional relationships part of a startup model that can be represented, inspected and tested.

Today, the implementation is a small freestanding x86 scaffold with a deterministic phase pipeline. Its nonpolar and nonlinear ambitions extend beyond what that scaffold currently demonstrates.

The work is to connect the two through precise rules and evidence.

For me, the central question remains:

Before a system continues, can it explain how its parts relate—and show exactly what it has checked?

That is the direction of MMUKO ringbooting: an explicit model of orientation and relationships, followed by verification whose meaning we can examine together.

---

Nnamdi Michael Okpala
Obinexus Uche · OBINexus Axis R&D
MMUKO-BOOT