How did they write the first software as initially there was no software platform/tools to work with.

When a computer boots up where is the fundamental point where it's loads data from a certain section/sector of the HD into the memory/cpu etc, is the Bios pre-programmed to search and load this data from a pre-defined sector of the HD in which case the BiIOS must have it's own memory/CPU and HD manager to start the initial process. So can the Bios be seen as an OS in it's own right. How was the first ever BIOS programmed?

Where is the fundamental point where the PC's OS takes over, in other words what data is loaded into memory first from the OS and by which OS process.


So your given a new PC with a blank BIOS,HD, and all the hardware specs, i.e instruction sets, hardware maps/data paths. Where do we go from here. What device is used to program the BIOS(assuming we have no other software loaded device to do this), what language is used for BIOS programming and and what is the order of operation of the BIOS. In other words how does the BIOS work. say I now want to create my own language/compiler what is the next step. If there is no software(apart from the BIOS) how do I write/store my compiler and language specs.

I like to have a go at writing a very basic lanague/compiler this where all my language will do is write out text and maybe allow for the four basic arithmetic operatios. Any tips on where I start.

If you want info about how the BIOS works, I think what you were looking for is http://wiki.osdev.org , but I'm pretty sure that's not what you mean.

The rest of your question makes no sense: language compilers have nothing to do with the BIOS, and it's not the language (or the compiler) that implements the writing of text to the screen; the operating system that provides APIs for that, and it's the device drivers (controlled by the operating system) that make the hardware display written text; the arithmetic operations are performed by the CPU.

Now, in the old days, there used to be an old language called BASIC, and it would allow you to write and compile programs that could be run directly from the BIOS, but that is no longer the case... With regular PCs, today everything is done through an operating system. you no longer have any access to the BIOS.

So, it's been awhile since I took the classes, so I might not be 100% correct about everything but....

When the computer first powers on, it does a few things that it was built to do regardless of operating system, at a certain point in the boot up process there is an instruction that tells it to jump to the location where the operating system is installed which is when the OS takes over.

Everything about how a computer runs is binary data. It just depends on how that data is being interpreted that determines what happens.

As pointed out already, the instruction pointer is pretty much the most important piece of data... the instruction pointer contains the memory location of the next piece of data to be considered an instruction. Registers contain data that is to be interpreted as parameters.

Every program a computer executes is in machine code, machine code is nightmarish to write/debug because it has only the most basic of statements. Add/sub/increment/jump/and/or/not etc... there isn't even any output or input commands. (Output is implemented as moving data to specific memory locations output devices are looking at to interpret as output and Input is implemented as devices setting data values in specific memory locations OSs look for to interpret as input)

The advantage of machine code (Other than the computer being able to read/interpret it) is that it is so simple that it was fairly easy to map to Assembly code. Assembly has the same instruction set as machine code, but is *more* human readable. With assembly code it became possible to write the first higher language compilers such as fortran/basic. As the languages became easier to comprehend it became easier to do more complicated things and thus higher and higher level languages became possible, to the point now that Java and .Net are able to compile to an intermediate virtual machine code which could than be re-compiled or interpreted to machine specific machine code.

Apparently, the first programs where written in assembly by hand and translated manually into machine code. So the first tool to convert asm to machine code was written in machine code. The first C compiler was likely written in Asm, and c++ in C, etc. Of course once you have an asm compiler you can rewrite a better one in asm.

Since I am also an old fart, let me tell you some war stories.

I have written programs without an assembler. This was for a Z80 processor in an MSX2 computer (1987, perhaps?). I had bought an assembler/disassembler for MSX on 1986 (they were separate programs), and when I updated to an MSX2, the assembler stopped working. So I would plan the program similarly to how Sandy White did it, enter the program byte by byte and then use the disassembler to verify I didn't make any mistakes. I don't recommend this to anyone, other than perhaps to convince yourself that it can be done. I only did it because I really wanted to learn assembly and because I was 12, which means I had a lot of free time.

When I bought a PC in 1992, I spent a few weeks writing assembly programs from DEBUG (a command-line low-level debugger that was shipped with MS-DOS). This was a big improvement. :)

Among other things, I wrote a program that would switch to 320x200 8-bit color graphics mode (using INT 10h services from the BIOS), would draw a picture of a Mandelbrot set, and would allow you to zoom in different parts of the image (navigating with the numeric keypad). The whole thing was only about 350 bytes and didn't use any OS services, just the BIOS. So I put it in the boot sector of a floppy disk and I added code to try to boot again if you pressed 0. It was basically a fancy version of the "Non-System Disk, Press any key" message you would normally get from a floppy disk (which is also a program stored in the boot sector).

I also spent some time figuring out how some viruses work. Stoned was a brilliant piece of work.

To be totally honest, I don't know how anyone can learn how a computer really works these days. Computers are fantastically complicated, and modern OSs make it very hard to really interact with the machine directly. On the other hand, beginners now have access to the Internet, so perhaps that's enough to offset the complexity.

I once was so fed up with the slowness of BASIC that I typed a several pages long listing of numbers from a journal into C64 BASIC data statements and a tiny loop to poke them into memory to get access to a monitor (thats basically just a crude hex-editor, not even an assembler). Then I could start it up and use two cryptic statements to write it to a floppy disk for later use. I would then look up opcode numbers from a machine language book one by one to "program" something and put in some hex numbers. I never got very far cause there must have been a number wrong in the journal and it would crash sometimes, it was also too tedious to actually get more than a trivial program that way.

Somehow I got my hands on an assembler later that was a bit like a slightly modified version of the BASIC editor with line numbers and single line input and could compile that, but it was still very difficult to get something working and documentation was a rare thing, I just had 2 books and the computer manual.

I remember that thing would when getting a signal on a reset, NMI or IRQ line load one of the 3 last 2 byte words from memory and jump there. Because there the ROM was placed it could jump back a bit at start up and initialize the stack pointer and the IRQ and NMI pointers (double jump so programs could change them in RAM) and then jump into the BASIC ROM and show the prompt.

I think I read once (IIRC) even a PC did start at the end of the first MB and the higher bits were masked such that the program would run from wrap around into the beginning of address space with the BIOS ROM and that would enable keyboard and monitor to make you able to edit the BIOS-settings, print a bit of text and then search for connected drives to load up a bootsector.

You might want to try programming on some old console game systems. GBA is my favorite and lets you do almost everything, and is powerful enough to run compiled languages (usually C). NES is even more barebones, and could at least do your super simple learning language, but for any actual game making you pretty much have to use assembly.

As you get lower and lower level, the line between software and hardware begins to blur. Starting from a totally blank modern PC may not even be possible, because we're so far removed from the days of no other computers being around to work off of. I doubt they're designed to ever function from a totally software-free state. And even if it is possible, you're so close to hardware fiddling, you might as well learn that too, in which case you can start from an even lower level point, such as designing the CPU itself :) I kind of want to try that sometime... routing transitors and all to read opcodes from memory, operate on registers accordingly, and write back to memory. And then you might as well learn how to create transistors from raw materials... or go with vacuum tubes. Either way, then you'll have to go out digging to find some raw materials in the ground to work from :lol: Then you're pretty much as low level as you can get.