my mp3Player is almost done now, so i started another project. :cool:
i started playing around with the master boot record (mbr) of a floppy. i created some bootcode and wrote "hello world" on the screen - at bootup. finally i thought of making some kind of a OS. so i want to launch my core by reading it from the disk and jumping to the entry point.

i can read the TOC of the disk and i printed it on the screen, but i can't interpret it - where do i really (which C.H.S) get this file?
i've searched the board & the internet for it, but couln't find matching things.
does anyone have related links or tipps/suggestions?
Posted on 2002-12-01 10:29:51 by hartyl
please post your mp3 player please
Posted on 2002-12-01 11:09:20 by Thor0Asgard
i can't upload anything, becaus my IE would hang the system.
but i still want to know how i can interpret the (& get) the ToC of a FDD or HDD!
Posted on 2002-12-02 12:53:53 by hartyl
Thor0Asgard, I have attached three mp3-players. Not very pretty
to look at. But they play mp3's(none coded by me).
Posted on 2002-12-02 13:07:03 by natas
could you please stop converting my "ToC of a FloppyDisk"-thread into a mp3Player-thread?
Posted on 2002-12-02 13:30:39 by hartyl
Hartyl, dont get all crazy on me now? this is not
the first thread were someone asks a question wich
jumps out of the topic? so lighten up. ( :) )

Anyway, you say you have searched all over the net etc.
Well have you checked out this webpage?
I think you should be able to find anything you need there.
Posted on 2002-12-02 13:52:50 by natas

since this job is really interesting I recommed two things.
- first search the web for "FatFormat.pdf" from M$- second search the board for "MenuetOS" which is the
first step just to get an idea of coding an own OS which
as far as I remember already includes FAT support.

Bye Miracle
Posted on 2002-12-03 04:17:49 by miracle
no problem at all - but i didn't like it, that the first answer i heard, was offtopic...

SURE! why didn't i think of it myself? a fdd/hdd uses the FATFormat - i've always searched for "read ToC of Floppy" or fimilar. brilliant idea! i already got menuetOS (brilliant thing too), but i don't want to copy it, and i want to completely understand what i'm doing.
Posted on 2002-12-03 12:54:00 by hartyl
Operating System Resource Center

The floppy disk may or may not be formatted in FAT12. The only real way to detect what format a floppy disk is in is to try all the various ways a floppy disk can be formatted... FAT12 seems to be the PC standard though.

As for the hard disk, there is also a standard for it. In the MBR, offset 0x01BE through offset 0x01FD is the 64 byte partition table (old standard). Starting at 0x01BE, the partitions are 16 bytes long and there are 4 of them.

Sounds easy, but you are stepping into a world of hurt by worrying about such things in the order of creating an operating system.

Typical First Steps
-Hard Code a simple floppy bootsector in assembly, it doesn't have to be dynamic, it can know how big your kernel is in size and where it is on the floppy disk and where to load it to.

-Write a Kernel in Assembly, C, or Both... but remember not to #include any files when you are doing C since your kernel will not support libraries... not yet at least.

-Decide what processor you will first run it on, and what possible modes of the processer... (i.e. intel 80386 in 16-bit segmented mode, intel 80386 in 16-bit flat-unreal mode, intel 80386 in 32-bit protected mode)

-In case of 32-bit protected mode, you will need a Global Descriptor Table, this tells how memory is split up and what kind of code can execute it or call it. Currently, there are 4 levels called "Rings". Ring-0 is the highest level and is considered Kernel Mode execution. Ring-3 is the lowest level and is considered Application Mode execution. Ring-1 and Ring-2 can be used by adds for extra wait cycles and confusion.

-Intel Architecture is interrupt driven, there are exceptions (internal to the CPU), and interrupts (external to the CPU). Exceptions are usually triggered by INT, BOUND or processor errors. Interrupts are triggered by hardware externel to the CPU, which could be from RAM in case of data parity errors and many other things as well. The IDTR (Interrupt Descriptor Table Register) holds the offset in memory of the IDT (Interrupt Descriptor Table) base. The IDT is a series of 4-byte tables in 16-bit real/unreal mode (In which case it is called the IVT and is mapped by the BIOS from boot), or a series of 8-bytes tables in 32-bit protected mode. Exceptions and Interrupts are indexed from the base of the IDT, this indices points to an offset in memory in which the actual code to process the exception/interrupt exists. Think of the IDT as one giant CALL table. The IDT and its handlers are the key to how well your operating system development will proceed.

-Video and User I/O should be next on the list. This is where operating system begins to become more of an artform than a science, there are dozens of ways to implement video and user I/O.

-Finally you will get to Drive I/O which beyond the standards for reading a disk/disc drive, is even more of an artform... there are hundreds of ways to implement this.

I do not expect you to understand all this stuff yet, but you can come back and use this as you learn more and more.

PS: I've heard of a tool called Kernel Builder, it is suppose to help you make a kernel easily... but don't ask me how it works... never used it.
Posted on 2002-12-03 13:33:49 by SpooK
you wrote down exactly what i thought about to do (even in the same order :))!
i don't have enough time yet, to try this, but i will! i've actually started writing my bootcode loading my core (i wont call it kernel, sounds like "kern?l" :)) i already know about the main structure of an OS (the exeptions, interrupts, IVT, etc.).
but i want to develop it on my own; indeed, i want no sample code. datasheets like the fatformat.pdf sould be the only information for me :)
Posted on 2002-12-03 14:59:16 by hartyl
I don't call mine the "kernel" either... I call it the "core".

I am working on an Operating System myself... have been for about 9 months on and off. So far it has been 100% assembly (NASM/hand translated). I have about 75% of a CUI (Console User Interface) done, what type of card is installed (Monochrome/CGA/EGA/VGA), it knows what the base of video memory is depending on what card is installed, what mode the card is in, moves the console cursor, accepts keyboard input, has a command buffer, and is entirely from my ideas.

Next step is to implement basic drive I/O, advanced drive I/O, and filesystem recognition.

GL with your OS.

PS: Anything OS Design/Implementation specific goes into The Heap :)
Posted on 2002-12-03 15:59:17 by SpooK