thechristelegacy

Wow, very interesting concept. It's way over my head to know what to do about the situation, but I find the idea interesting.

The very first person to invent software didn't have a third party editor either, so it is possible.

Personally, I don't believe it's a waste of time. As hard and abtruse of a topic it is, there is nothing wrong with wanting to learn for your own good. I program for a hobby here in highschool, I'd love to go into as a career, and if and when I ever gain enough knoledge, it sounds like something I'd like to try myself. I wouldn't do this to try and re-invent the wheel for the 50th time, but to do it just to see if I could do it.

Justin Case

When I first started getting into computers, I was really interested in learning how the underlying system worked, how the actually bits and bytes do their thing. So I went to my local library (it has a very up to date computer section) and got myself a book on Boolean Logic. About 6 months later I built a "computer" with just electric relays and light bulbs... It could only add a few binary digits but... I learned a lot.

I reccomend doing something like that (maybe with TTL chips instead of electric relays) if you're into the real basics of it; and if you don't like having to trust other people's code.

I know that's not exactly what you're after grimpirate, but it's along those lines.

__________________
... after all, we're all alike.

grimpirate

OK, now I'm getting somewhere DaWei, yes you're right I didn't fully understand what the BIOS is, so technically without actual hardware manipulation I can't manipulate at THE most fundamental level of the computer. So basically, I HAVE to use BIOS as a BARE minimum in order to achieve what I want. However, upon doing some more research I've discovered that O/S's like Windows only use the onboard BIOS for the initial startup of the system, then the bootstrap loader comes into effect and loads the Windows O/S and a "RAM BIOS" is created which bypasses (to a degree) the usage of the "ROM BIOS". So this is what I'm focusing on now.

My new question is how do I find out what interrupts, functions, calls, etc. my particular BIOS can perform (since each BIOS is different from the next due to different hardware configurations)? Are the functions standardized for the BIOS creation industry (though I find that unlikely)?

Is there a way that I can view the actual instructions loaded in my ROM BIOS? A memory map of the BIOS if you will. I know that on the Pentium IV, instructions begin execution at FFFFFFF0h. Therefore, the first instruction of BIOS, and of course the ROM, have to be located at this address in memory. Then, as I understand it what usually happens is the first instruction is a JMP to the beginning of the BIOS instruction set (which is also thae actual ROM starting address). Now, where I get lost is what BIOS is doing. I know it performs the Power On Self Test, then sends the Power Good signal to get things going, and then it begins executing code at the address stated previously. And of course it performs a whole other slew of "dealies" like searching for other BIOS and so forth and so on.

Finally, this is what NOW want to know, how do I find out what my BIOS can do (instruction wise)?

As an aside, TCL the way to do that is like DaWei said. With the particular chip/microprocessor you're using the device that I've seen actually burns the instructions sequentially inside the chip's onboard memory (whether that be ROM, PROM, EPROM, or EEPROM). And the way to program the instructions is by actually going through each address space and setting the bits (which is how you place the 1s and 0s without a third party editor). My confusion was that I believed that you could actually write the BIOS while on your computer (which you can, but you need to have EEPROM and know a whole bunch of other WAY more complicated stuff to do). I've actually done this but with a much less complex microprocessor (which engineers refer to as a microcontroller, this might interest you Justin Case). It's called the PIC16F84, which is essentially a WAY less complex Intel processor hehe (that's a great oversimplification), and it provides its own onboard EEPROM. And basically we set the 1s and 0s as necessary placed the chip onto the device and burned the instructions into it. My team and I did this to build various mechatronic circuits, to control LEDs, motors, etc. Eventually building up to the construction of a robot.

By the way, perhaps usage of the word trust was misleading to people. I apologize for that, it's not that I don't TRUST their code. I can see it works and it produces the results I need. I'm just a bare essentials person. Since I've studied with many engineers I'm always faced with people that can't do mathematics without the aid of a computer/calculator or in everyday situations people who immediately discard things when something breaks down. I like to know how something works from the ground up so I can understand the why things are happening and maybe improve on them or repair them if they break; which is what engineers do. Like I can tie many knots with rope, but if I don't know how to make rope of what use is it to know how to tie knots if no one around me can provide me with rope?

Again, thanks for any help

__________________
Lo, there do I see my father. 'Lo, there do I see My mother, and my sisters, and my brothers. 'Lo, there do I see The line of my people... Back to the beginning. 'Lo, they do call to me. They bid me take my place among them. In the halls of Valhalla... Where the brave... May live... ...forever.. GrimBB | Mimesis

iignotus

It seems to me like what you should get into doing is reading things like encyclopedias and hardware manuals, etc. Every programming language (even assembly to some degree) has a considerably higher level of separation from the hardware than working with things like bypassing the BIOS.

Wikipedia is a good starting point to research things like this. I've provided some entry points:
http://en.wikipedia.org/wiki/BIOS_Interrupt_Calls
http://en.wikipedia.org/wiki/Booting
http://en.wikipedia.org/wiki/BIOS

Now of course, programming does come into play with things like this -- programming is a basic facet of computing in general. But I think it would be good to research how the hardware works first before diving into obscure ways of manupulating it through software.

__________________

DaWei

Iignotus is correct. Take your original premise: remove ALL software. That has an obvious corollary: only hardware is left. The microprocessor is hardware. The movement of patterns from one storage place to another or to the ALU is accomplished by electrical signals that open and close gates and supply clocks (which are nothing but gates derived from an edge, or transition between two states). When the processor is reset and the reset is removed the IP register gets forced to a state that represents the address of the very first instruction to be performed. For many processors, this is zero, but, as you point out, Intel, in its frenzy to be effed up, chose 0xFF....F0. At any rate, that very first instruction comprises a bit-pattern that causes some pieces of hardware to be gated in certain ways. Perhaps it causes the contents of the accumulator to be inverted. You can replace that pattern with another and it will serve a a pattern that triggers something else. Perhaps the incrementation of the IP, the reading of the following byte as data, and the placement of that byte into the accumulator. Because you can change that very first byte, and all subsequent bytes, and cause the processor to thus do different things, you have just crossed the boundary from hardware to software. That controlling signal, content wise, is soft, malleable. If you've arranged for it to be in ROM, which will retain its contents with power off, it's no longer entirely soft. It isn't hard, either, though, because you can use special techniques to replace the contents (one of which is to replace the chip). That's "firmware."

That's what the BIOS is. That stands for "basic input output system". It provides facilities for reading the keyboard, driving the monitor, and reading some bare set of peripheral devices in some very basic mode. If you want to write that, you must study the keyboard hardware, the monitor driving hardware, peripheral (say, floppy drive) hardware, and so forth.

Surely you realize that there are many people that understand those things and can thus provide software for them. The BIOS didn't spring full-blown from that egg we were discussing in the lounge.

Again, I suggest this: back away from the system as represented by the typical Intel-based motherboard with 12 jillion functions built in. Get a simple single-board computer, some memory, a hex keypad, a 20-40 character LCD display. Either get those that are available to tack right onto you SBC, or build the interfaces yourself. Punch some opcodes and operands directly into the memory at the start address, perhaps something that will put the dot-pattern, "A", on the LCD. Then punch the reset button and watch it happen.

When you're confident you can do that, go back to your desktop machine and, using a cross-assembler, write the code that will read/write one sector from a floppy drive. Add that hardware. Mix in the software. Stir. Continue in this way until you know precisely how the Esso Bee works.

Your view of engineers and engineering is incorrect, by the way. I'm an engineer. I've directed numbers of other engineers in their efforts to design products which can be produced and sold at a profit to the monetary risk-takers (who, incidentally, share the profits with otherwise unemployed people via their paychecks). This includes all facets: mechanical, hardware (analog and digital), and software designs. If I walked into some engineer's office and he was designing something significant WITHOUT using a calculator or some other equally effective tools, I'd fire his ass on the spot.

Learn your material and how to do every last nitty-gritty detail, if you like. Then, if you don't step back and drop the subject, pick up good tools, do the hard work, and leave the scut work to those trained for it, you might as well go get your hand measured for a mop handle, because you're headed for JanitorialsVille.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

grimpirate

So here's the most important thing I've learned thus far through independent research:

In order to create any sort of O/S, a bootstrap loader has to be written onto cylinder 0, head 0, sector 1 of the default boot drive (usually the floppy). This data is then loaded into the memory at address 0000:7C00h. This is essentially the beginning of "blank" memory allotted to the programmer to begin work.

Thus, all that's left to do is to actually input the sequence of 1's and 0's into a binary file and write it onto a disk.

On a lighter note my view of engineering is not that engineers shouldn't use better tools to accomplish their work in a better manner and of course more efficiently. The main goal of engineering is to create a versatile design, efficiently and at low cost, and of course you do that with better tools. My point is that there are engineers who physically CAN'T do the quadratic formula if it isn't programmed into their calculator, and have no concept as to why it is the actual quadratic formula works the way it does. If you rely on whatever tools answer without a knowledge of its underlying principles, then you're not an engineer, you're just a software jockey.

__________________
Lo, there do I see my father. 'Lo, there do I see My mother, and my sisters, and my brothers. 'Lo, there do I see The line of my people... Back to the beginning. 'Lo, they do call to me. They bid me take my place among them. In the halls of Valhalla... Where the brave... May live... ...forever.. GrimBB | Mimesis

DaWei

But, of course, if you rely on the BIOS to load that boot track, without knowing how it does it, you're just a software jockey. On the other hand, being a jockey beats being afoot, I guess.

Good luck with your experiment.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers