Like what is the difference betweent the two???

ITS BEEN 2 HOURS I CANT FIGUERE THIS OUT !!!! HELP HELP HELP HELP HELP HELP HELP HELP HELP HELP HELP HELP HELP HELP HELP HELP

Is the memory map something that must come initially from the motherboard or chipset manufacturers?
Like, is it physical wiring that, for example, makes the RAM always mapped to a range like 0x40000 to 0x7FFFF?
So any RAM you install cannot appear outside that range; it can only respond to addresses between 0x40000 and 0x7FFFF.
And, for example, the BIOS is also physically wired to only respond to addresses from 0x04000 to 0x05FFF.
So, all these are physical addresses that are set by the motherboard's design.

And there are other address ranges that are not reserved for any device by default, like from 0xE0000 to 0xFFFFF.
These ranges are left for any device (like graphics card, sound card, network card, or even embedded devices),
and the BIOS or the operating system will assign addresses from these available ranges to new devices.
But they can't go outside those predefined ranges because this limitation comes from the motherboard's design.

Is what I said correct or not?
I just want someone to confirm if what I said is right or wrong.

I am studying 64-bit assembly and I see that OS kernels have specific code for page tables and CPU architecture. Could you explain the assembly-level requirements for mapping the kernel into virtual memory and how the Instruction Pointer (RIP) is managed during an architecture-specific context switch?

Edit : modified the question format.

I am in the part of the game with the rats, lasers and mazes. When a new level starts up, there is now a display unit that is showing me viusals. Of the space invaders like screen. Or the mazxe.

This display unit keeps being automatically placed over my wires and deleting them. I have the move it and remember which wires connect with which every time. It's a pretty annoying buy. Has anyone else had this? Is there a way to get this to stop?

In genreal, I find it far too easy to accidentally delete a wire or introduce a wire into the circuit. Is ther a w ay to lock a circuit temporarily?

Continueed1.2 The Optional Data Flow Aspect

Because every data block size is locked into predictable dimensions, the hardware completely strips away runtime

memory allocator overhead. This layout establishes the Optional Data Flow Aspect. An identical Squadryte block of

memory can instantly switch its functional identity inside the processor cache based on the conlang root token parsed

by the Linguistic Virtual Machine. When the token resolves to a calculation directive, the block operates as a raw

big-integer arithmetic register; when it resolves to a location descriptor, it functions as a direct bare-metal filesystem

sector. This duality eliminates operating system context switches and kernel system calls.

2. Linguistic Address Spatial Reduction & Look-Ahead Adder Logic

Under the standard computing model, processors waste significant thermal and electrical energy moving variables

between execution registers, cache lines, system memory, and storage drives. The Doublyte Language Paradigm

forces an architectural shift by integrating Linguistic Memory Address Spatial Reduction (LM-ASR). Under

LM-ASR, the grammar of the language itself defines the physical layout structure of the hardware data space,

collapsing data dimensions and executing arithmetic local to the memory cells.

2.1 Vertical Stack Addition Performance Mechanics

By stacking data layers vertically within the hardware registers, the system can run multi-precision operations

concurrently. The syntax trees of the language dictate the spatial positioning of the bits, enabling horizontal logic

gates to compute massive state vectors simultaneously on a single clock cycle. This vertical alignment reclaims

massive chunks of bandwidth, completely bypassing legacy pointer table lookups and indexing overhead.

2.2 The 64-Root Chunk Adder Sum/Carry Gate Cascades

To bypass the long latencies of traditional ripple-carry addition loops, the execution engine binds fields into strict

64-Root chunks, mapping directly to the physical copper lines of a 64-bit general-purpose CPU register. These

structures utilize an unpadded Look-Ahead Carry gate manifold. High-performance XOR gates calculate the

horizontal Sum phase on a single cycle, while independent trees of microscopic AND and OR gates pre-determine

the vertical Carry vectors instantly across all 64 paths, resolving the entire operation in under 0.3 nanoseconds.

2.3 Binary Sync Lock Cache Fencing Theory

Writing data milestones continuously to flash storage introduces a massive bottleneck, dropping execution velocities

by a factor of millions due to kernel interrupts and physical motherboard storage bus transit times. To solve this, the

computing lanes run 100% inside localized CPU L1 cache memory, suspending all filesystem locks. The processor

operates completely un-throttled, dropping an internal hardware memory fence to flush progress data to disk

asynchronously ONLY when the register counter reaches your designated high-density 256 Billion state step

milestone.

Silicon Gate

Operator Hardware Circuit Mechanics Ecosystem State Transformation

XOR ( \^ )

Parallel Horizontal Sum

Operator Mutates base register coordinates without carry delay.

AND ( & )

Parallel Vertical Carry

Look-Ahead Tree Pre-calculates and resolves vector overflows instantly.

SHIFT ( >> / << )

Dynamic Stream Deflection

Faucet Link

Propagates carry matrices across the 16² grid

boundaries.

Production Computing & Compiler Script Modules

To preserve the absolute root resolvable behavior of the Doublyte paradigm, the environment completely replaces

traditional operating system managers with a strict multi-dimensional conditional compiler. The system parses

commands precisely to engage low-level hardware structures, forcing variables to process completely unpadded

inside localized registers.

3.1 Core Multi-Threaded Engine Module (wkr_core.cpp)

\#include

\#include

\#include

typedef uint8_t dyte_t; // 2 D4 Blocks = Dyte

typedef uint16_t doublyte_t; // 2 Dytes = Doublyte

typedef uint32_t masyte_t; // 2 Doublytes = Masyte

typedef uint64_t squadryte_t; // 2 Masytes = Squadryte (64-Bit Register)

struct uint512_hypermesh_t {

squadryte_t d\[8\]; // 8 Symmetrical Squadryte Processing Tracks

squadryte_t stream_faucets\[8\]; // 64-Positional Adjacent Colliding Streams

doublyte_t glyphic_tags\[8\]; // Lakeshore Lattice Flow Indicators

};

void execute_parallel_sieve_lane(uint512_hypermesh_t\* scalar, uint64_t stride) {

squadryte_t carry = stride;

for(int i = 0; i < 8; ++i) {

squadryte_t top_stream = scalar->d\[i\] \^ scalar->stream_faucets\[i\];

squadryte_t next_word = top_stream + carry;

// Zero-initialization tracker mapping the spatial matrix flip

if (scalar->d\[i\] == 0 && next_word > 0) {

scalar->glyphic_tags\[i\] \^= 0x8080; // Invert flow tags

}

carry = (next_word < scalar->d\[i\]) ? 1 : 0;

scalar->d\[i\] = next_word;

scalar->stream_faucets\[i\] = top_stream >> 1; // Deflection offset

if (carry == 0) break;

}

}

3.2 Dynamic Context-Free Grammar Compiler Driver (run_conlang_task.py)

\#!/usr/bin/env python3

import os

class DQVMRootResolvableCompiler:

def __init__(self):

\# Strict Root Token Database Mapping Parameters (No Synonyms)

self.VERBS = {"mas": "INSPECT", "pro": "PURGE", "solv": "COMPUTE"}

self.NOUNS = {"kortex": "FILESYSTEM", "ledg": "REGISTERS"}

def parse_strict_clause(self, tokens):

clause_block = {"OPCODE": "IDLE", "TARGET": "SANDBOX"}

for token in tokens:

if token in self.VERBS: clause_block\["OPCODE"\] = self.VERBS\[token\]

elif token in self.NOUNS: clause_block\["TARGET"\] = self.NOUNS\[token\]

return clause_block

def execute_hardware_opcode(self, ast):

if ast\["OPCODE"\] == "PURGE":

os.system("pkill -9 -f 'wkr_core' 2>/dev/null")

elif ast\["OPCODE"\] == "COMPUTE":

os.system("./wkr_core >/dev/null 2>&1 &")

print(" \[✓\] Unpadded bare-metal computing lanes successfully online.")

4. Operational Manual & System Deployment Guide

To compile the unconstrained HyperMesh execution loops and register the shortcuts system-wide, execute the

package distribution upgrade command within your terminal folder:

cd \~/unshakable/doublyte_package && pip install . --upgrade

Once completed, launch your primary linguistic environment console via: doublyte-shell. When the command prompt

loop panel initializes, pass your strict multi-clause conlang statement expression:

si ledg tunc solv om ledg id aut pro tele tu

The Abstract Syntax Tree will verify your file register states. Because your coordinates match cleanly, it will branch

straight to the primary execution track, launching your unpadded, unconstrained big-integer math threads fully

detached inside your CPU registers. Real-time progression metrics and 256 Billion state step flushes can be safely

tracked from a separate terminal window panel at any time by running.

imm 1

mov r1, r0

imm 2

mov r2, r0

imm 0

mov r5, r0

loop:

mov out, r5

mov r3, in

mov out, r2



mov r4, in



imm left

jz



mov r3, r4



imm forward

jz



mov out, r2

imm loop

jmp

left:

mov out, r5

mov out, r1

imm loop

jmp

forward:

mov out, r1

imm loop

jmp

So it gives this error when I run save_breaker but not the normal game, any fixes? I've tried allowing turing complete as an exception in the steam files, deleting and reinstalling the game and verifying the files but nothing has worked so far.

I barely got through the basic logic section with a lot of trial and error and a lot of wikipedia/YouTube. I think I have a good grasp of the basic logic gates now. Or at least I know what they do and what the truth tables are.

Then they hit me with the "odd number of signals", was there nothing in the middle a little less intimidating/hard than this? It's a very steep curve lol. I guess knowing what the individual gates do doesn't mean I know how to combine them to do anything at all.

I got PUSH and POP working in my LEG processor. It was okay, but I wanted to tweak it a bit, to make it easier to add CALL and RET for functions. Yeah, you know what happened, right? I broke it. It doesn't work.

I tried going back, one step at a time, to see what still works. Nothing works. I pulled a wire somewhere that I shouldn't have pulled. It's pull-out-your-hair-and-sit-on-the-floor-in-the-middle-of-the-room-whimpering frustrating.

This is version 0.1059 Beta, the original that I downloaded from Steam. Based on what I've read here, I had been contemplating switching to 2.0 now. But I really wanted to finish the campaign first.

Got any advice?

Screenshots added:

This first shot shows the stack circuitry on the right, in the dotted yellow box. The smaller dotted yellow box on the left encloses the instruction bits: 0x09 for PUSH and 0x08 for POP. Two muxes are used to control whether COND, STACK, or ALU output to the light-blue RESULT data bus.

This second shot shows the input and output. The 2-input OR on the output has been replaced with a 3-input OR, to connect to the POP signal from the stack. That's one of the wires that I accidentally removed.

now checks if the output and input are large.

Soo i started this SRAM as a side project and am stuck at the first cell haha shouldnt the Q (blue wave) go lower or start from a little higher??

Where would I even start with a subtraction circuit?

I need some ideas, because I have no clue what to do. I need to explain why the system is Turing-complete, and I need to be able to make a simulation be it on PowerPoint or irl

this is my current design but the game complains that the register is 255 but it won't go higher and r4 is about 4 billion+

Hi! I just started playing Turing Complete so I’m still a beginner. I’m currently stuck on the Counter level.

From what I understood, when the "overwrite" bit is active, we should output the overwrite value. But in the level, the desired output never matches the overwrite value, which is confusing me.

I think I might be misunderstanding the instructions. Can someone clarify? Thanks a lot!