Improved documentation to reflect sytle information obtained.

This commit is contained in:
Jeremiah Orians 2016-06-12 18:25:38 -04:00
parent 002e6f8693
commit 5f4e55b309
No known key found for this signature in database
GPG Key ID: 7457821534D2ACCD
2 changed files with 54 additions and 27 deletions

8
README
View File

@ -1,7 +1,13 @@
This is a set of manually created hex programs in a Cthulhu Path to madness fashion.
Which only have the goal of creating a bootstrapping path to a C compiler capable of
Which only have the goal of creating a bootstrapping path to a C compiler capable of
Compiling GCC, with only the explicit requirement of a single 1 KByte binary or less.
Additionally, all code must be able to be understood by 70% of the population of programmers.
If the code can not be understood by that volume, it needs to be altered until it satifies the above requirement.
WE DON'T WANT YOUR CLEVER CODE. Only stupidly simple code will be accepted.
The Madness must be satisfied and only with the Blood ritual of code we perform here.
This repo contains a few of my false start pieces that may be of interest to people who
want to independently create the root binary, I welcome all bug fixes and code that aids
in the above stated goal.

View File

@ -6,26 +6,31 @@ BE VERY VERY THANKFUL for those that came before us and made such wonderful
things as assemblers and C compilers that hide most of the horrible darkness from our eyes...
*** Default memory map
16-bit mem map (seg:off)
0x0000:0x0000 -> 0x0000:0x0500 BIOS stuff
0x0000:0x0500 -> 0x0000:0x2100 root
0x0000:0x2100 -> 0x0000:0x3300 fat
0x0000:0x3300 -> 0x0000:0x6c00 14,25kb free space
0x0000:0x6c00 -> 0x0000:0x7c00 IDT and GDT (256 desc. eatch)
0x0000:0x7c00 -> 0x0000:0x7e00 bootsector
0x0000:0x7e00 <- 0x0000:0xffff ~32,5kb stack for boot
0x1000:0x0000 -> 0x9000:0xffff 576kb free space
0xa000:0x0000 -> ............. VGA mem etc.
| 16-bit mem map (seg:off) | What is there |
|--------------------------------+-------------------------------|
| 0x0000:0x0000 -> 0x0000:0x0500 | BIOS stuff |
| 0x0000:0x0500 -> 0x0000:0x2100 | root |
| 0x0000:0x2100 -> 0x0000:0x3300 | fat |
| 0x0000:0x3300 -> 0x0000:0x6c00 | 14,25kb free space |
| 0x0000:0x6c00 -> 0x0000:0x7c00 | IDT and GDT (256 desc. eatch) |
| 0x0000:0x7c00 -> 0x0000:0x7e00 | bootsector |
| 0x0000:0x7e00 <- 0x0000:0xffff | ~32,5kb stack for boot |
| 0x1000:0x0000 -> 0x9000:0xffff | 576kb free space |
| 0xa000:0x0000 -> ............. | VGA mem etc. |
*** Restart code
To restart the segment loaded from the bootsector:
68007C ; push 7C00
C3 ; ret
| Hex | Assembly Equivelent |
|--------+---------------------|
| 68007C | push 7C00 |
| C3 | ret |
For an intersegment restart:
6A00 ; push 0
68007C ; push 7C00
CF ; iret
| Hex | Assembly Equivelent |
|--------+---------------------|
| 6A00 | push 0 |
| 68007C | push 7C00 |
| CF | iret |
* Testing notes
** Making blank floppy disk images
@ -45,49 +50,65 @@ change floppy0 blank_floppy.img
** Building binaries for testing
*** stage0_monitor
There are literally hundreds of ways of building the root bootstrap binary.
All that is required is a simply hex compiler written in any language on
any system available to the user.
This repository contains a hex compiler written for Linux in hex and assembly as
well as a platform independent C implementation.
Then to complete the build process write to the master boot record of a floppy disk.
Or should you desire simply use qemu to boot the compiled file directly.
* Creation journal
** Linux bootstrap
The initial prototyping was done on linux with the goal of not
requiring anything other than the linux kernel.
However it was pointed out to me that should a trusting trust attack be in the compiled kernel,
there would be no way to even trust the binaries produced by these programs.
The initial prototyping was done on linux with the goal of not requiring anything other than the linux kernel.
However it was pointed out to me that should a trusting trust attack be in the compiled kernel, there would be no way to even trust the binaries produced by these programs.
That being said they may be of some use to you.
** Stage 0
Lacking a good basis for reducing the trusting trust attack, it was decided to reduce the scope down.
By writing the stage 0 code in commented hex, it becomes possible for universal cross compilation and verification.
The only real problem is that the commented hex has to be manually validated [An insanely painful process] and
each and every single platform has to perform the exact same tasks.
The only real problem is that the commented hex has to be manually validated [An insanely painful process] and each and every single platform has to perform the exact same tasks.
Since all such projects have to start somewhere, I have choosen to do it myself and with the 8088.
To make my work easier, I first created the working code in 16bit assembly. Then after testing is validated,
I begin the pain staking process of manually converting the code to hex [With usually a dozen bugs along the way].
To make my work easier, I first created the working code in 16bit assembly.
Then after testing is validated, I begin the pain staking process of manually converting the code to hex [With usually a dozen bugs along the way].
What I however require is someone with a completely alien platform verify the compiled hex for the stage0_monitor.
Which has the following checksum values:
md5: 9e29544f0220636437741cb5092cc411
sha1: b26c72762d2f77d8634cb532d581c1e76adceb3f
sha256: 045ef96e1c8fb011cba89f268f823c06b21f91270fb9afb0af42a1ac8c3ee44b
| Name | Value |
|--------+------------------------------------------------------------------|
| md5 | 9e29544f0220636437741cb5092cc411 |
| sha1 | b26c72762d2f77d8634cb532d581c1e76adceb3f |
| sha256 | 045ef96e1c8fb011cba89f268f823c06b21f91270fb9afb0af42a1ac8c3ee44b |
If your compiled hex is different in any way, please let me know as the process should produce bit idential binaries.
** Stage 1
Stage 1 attempts to save myself from alot of manual typing and the inevitable errors that occur.
It simply provides the functionality required to produce 32KB or smaller binaries from Commented Hex files.
This is a minor stopping point of functionality that provides a stable nub for our much more ambitious stages that come later.
The editors lack the ability to correct mistakes and always writes a 64KB file onto the B: floppy.
The loader is so stupid is only loads 64KB from the A: Floppy and doesn't even prompt the user.
However despite those stupid limitations, they have saved alot of manual work compared to stage0.
Having these binaries are a huge step forward compared to not having them but they assume you don't make mistakes.
** Stage 2
Stage 2 will be introducing enhancements to Stage 1 programs that allow you to fix the problems you accidentially introduce.
We will also begin to introduce programs that make software development alot easier.