Improved documentation to reflect sytle information obtained.
This commit is contained in:
parent
002e6f8693
commit
5f4e55b309
8
README
8
README
|
@ -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.
|
||||
|
|
73
notes.org
73
notes.org
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue