Member Avatar for Bill_47

Assume a basic x86 PC (or if it is impossible due to locked access/firmware blobs etc assume the closest modern equivalent of a PC e.g an open RISC system with cpu ram hardrive and a way to interface with a keyboard mouse and a VGA/HDMI monitor)

NO OS is present.

input could be serial/parallel port keyboard floppy CDROM or even more low level ways e.g pads/jatags on the CPU/mobo if needed/applicable)

How would it be possible to enter raw binary (ones and zeroes) to it in order to compile a basic assembler for it from scratch without using any existing programming languages including existing assembly languages.

  • 3 Contributors
  • 2 Replies
  • 127 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by Schol-R-LEA

Dani AI

Generated

asked how to feed raw binary into a bare machine to build a protoassembler from scratch. The idea is simple in principle but depends on breaking the work into very small, verifiable stages. and point in useful directions; below is a practical, minimal bootstrap plan that complements their observations without assuming any existing toolchain.

  1. Create a tiny monitor that you can reliably get into the CPU and run. That monitor only needs to receive bytes, store them to an absolute address, verify them, and optionally jump to an address. Getting this first blob into the box can be done with any hardware write path the platform exposes (debug/boot interface, external memory programmer, or a vendor debug port). Keep it tiny so it is easy to hand-encode and verify.
  2. Use the monitor to load a slightly larger loader that implements a compact, token-based translator (a tiny virtual ISA of a few opcodes). That translator interprets short token streams (labels, simple ops, immediates) and emits native machine code into RAM. Two-pass label resolution can be implemented in the translator to support branches.
  3. Iteratively expand the translator into a minimal assembler: add directives, longer encodings, and convenience macros. Each step is tested by loading known patterns and running self-checks.

A simple, robust block format and minimal commands make the process repeatable:

0x55            ; start marker
[ADDR:4]        ; 32-bit address
[LEN:1]         ; payload length
[DATA:LEN]      ; bytes to write
[CHK:1]         ; checksum = sum(ADDR+LEN+DATA) & 0xFF

Monitor commands (example): W write block, D dump memory, G go/jump.

Troubleshooting tips: always test in an emulator first; use short, incremental loads; verify with echo/ack and checksums; use recognizable byte patterns to diagnose bus/bit-order issues. Be aware of modern firmware protections and write-protecting flash; an external programmer is often easier and safer. For background on staged compiler/assembler bootstrapping and common transfer formats see Bootstrapping (compilers), XMODEM, and Intel HEX.

Recommended Answers

All 2 Replies

Member Avatar for JamesCherrill

Given some way to set memory bytes, then it's totally possible. I did something like that with an IBM System 7 process control machine when we were preparing low-level software around 1970 in preparation for the first hardware shipments. It didn't even have an assembler at that time, so I hacked one together in APL and punched the resulting binary onto paper tape. We then set the hardware to read the contents of the tape verbatim into memory starting at address 0 then start executing at address 0.

So all you need to do is to write the necessary minimum code in an assembly-like language and compile it by hand into binary for input to the hardware.
The main (only?) problem I see is that, where you could do something useful on a System 7 in a few kilobytes, you will need megabyte upon megabyte of code for x86 class machine. With zero transcription errors.
Good luck. Maybe your children and grandchildren will be able to take over and finish it for you.

Edited by JamesCherrill
Member Avatar for Schol-R-LEA

There is a developer on the OSDev forum, David Cooper, who managed to do something like this for his OS project, though I am pretty sure he started off cross-developing his toolkit. He created what he describes as a sophisticated suite for editing code in hex, though presumably if you really wanted to you could do it in binary.

He's a bit of a crank, but that's true of everyone on that forum, myself included.

Edited by Schol-R-LEA
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.