There is some debate about the meaning of MOSS*, some say it stands for MASH OS, while others say it stands for Matthew's OS. Either way, it is an x86 based operating system, written from scratch. This is effectively the spiritual successor to Mash.
It was started by using this guide for writing a boot-loader.
Uhhhhhhhhhhhhhhhhh
None obviously.
- Finish up enough disk utilities to essentially
read_file("MOSS.BIN"). - Successfully load into moss, printing a hello message.
- Basic OS groundwork.
- Successfully load BASIC from kernel.
- Auto-start BASIC from OS.
- Detect CPU type in kernel, and if available, change jump tables to use more efficient routines (ones that take advantage of instructions added to newer CPUs).
thats awesome
- Micah Wagner
Things that have helped me through this journey.
- Design of the FAT file system: I wish the tables were expanded by default as I missed the existence of some of them early on...
The things the CPU can do.
- X86 Instruction Listings: nothing new to me, but still need to reference it every so often
- X86-assembly/Instructions: while it doesn't cover everything, most instructions on this wiki have very detailed pages - an invaluable website honestly
- MOV - Move: this and any other page, just replace the instruction in the URL with the one you want - it's not the most readable table of info, but can occasionally be useful for seeing just what exactly you can write (remember, assembly still isn't machine language, each mnemonic can have multiple opcodes)
Mainly, BIOS functions - though interrupts are broader than that.
- Ralph Brown's Interrupt List: one of the greatest (interrupt related) resources on the internet - this project makes heavy use of the BIOS through interrupts such as 0x10, 0x13, and 0x16
How things are laid out in the 20-bit memory space of the 16-bit x86 processors.
- Memory Map (x86): honestly this whole website is nice (I wonder why...), but this page gave me a much better breakdown of the memory map than anyone else - they also have a tiny bit about the BIOS data area, but nothing special
- Lecture 19: vaguely useful slide 6 - the above link outshines it in almost every way, but there's some nice descriptions or something idk
This is the area of memory between [0x400-0x500). (Also see Design of the
FAT file system above.)
- The BIOS Data Area: more expansive than most lists
- bios data area:
extremely in-depth list, that also had the value I couldn't find on other
pages, offset
0x:90, which I found in the disassembly of the boot sector created by my Tandy (MS-DOS 3.2)
The file-system often used on floppies, and the one I chose to work with. But oh boy, that 12... I hate that 12. I didn't include the wikipedia article here, as I only used that for info about the boot sector.
- fat12_description.pdf, and
- FAT12_overview.pdf: two very useful student(?) papers that helped me to finally wrap my head around the 12-bit file allocation table
- An Overview of FAT12: this one gets a special mention as it got me started, and got me as far as reading the root directory, but I could not for the life of me understand what this author was saying about the FAT
The assembler I use for this project.
- NASM - The Netwide Assembler: while most of the syntax hasn't required looking at the docs, some of it has... extensively
- Its Wikipedia Article: literally just listing this because of their example hello world for Linux where it shows some neat syntax I hadn't even thought of, and never would have figured out by looking at the docs
An x86 emulator. (Considered using this one.)
- How I found out about it: this (SUPER cool, interactive) website I found, mentioned the bochs package so I looked it up online - literally would have done this entire project without a debugger if not for this webpage
- Or maybe it was this PDF: but I had to share the one above either way
- Chapter 8. The Bochs internal debugger: would not have figured out how to use this program without this - and its been VERY essential in my debugging/learning process...
I'm really stretching this README now, aren't I.
- The segment registers are not guaranteed to be set to zero on boot. I don't even know if the CS register is exempt. Hence, my bootloader sets all of them (though some probably unnecessarily). This caused issues on most of my machines before I figured this out. I learned that from here.
- You can read/write (
mov) from/to RAM locations from any segment apparently. This is just general x86 assembly but for some reason I didn't know you could domov AX, CS:0for example - this fact saved me from adding bloat to my kernel disk routines where I was going to backup and then restore the data segment so I could get my jump table value - no longer necessary since we know CS.
* note: there is no debate on this whatsoever. That was a complete lie. I just haven't yet decided what to do with the name yet. Heck, I might rename the repo at some point.