In all my projects including FAB, i use "bootprog" see here: http://alexfru.chat.ru/epm.html#bootprog
if you what to load from hdd there a fat16 ver and programs to use it from a hdd, see doc for how to. in the above zip.

fat 16 is a proprietary file system.

In everything in life, in my opinion, simpler is better.
Not all FASM forumers agree with me, many PREFER obscurity, some even go out of their way to achieve obfuscation.
I believe that this community project will improve with a healthy dose of both clarity, and simplicity. Since fat32 is proprietary, one ought perhaps commence with one of the Linux file formats, ext2, for example, rather than omitting file formatting.

then ok, i'll document the start of this code... it risk to take a lot of time.

as you said i'll commant all the code.
and show how it works.

as it's not only pure asm, there is a little of hll inside, hidden under all the dd xxxx,xxxx,xxx statments.

Well, edfed, I am not trying to waste your time. I don't think it is necessary for you to introduce comments on your code right now, I do think it is appropriate to spend a few minutes figuring out EXACTLY what and how this project should proceed. It is a VERY good project, and it was YOUR inspiration that has elicited such excellent responses from Dex4u, among others, so, please don't misunderstand my comments. I simply wish to encourage all participants to ENGAGE in the task of communication--very difficult, and underappreciated, especially on the FASM forum. It is far easier to add some comments to existing code, than to create an outline of what one seeks to accomplish, how, and why. The point is this: upon completing the latter, one may realize that the former is now obsolete, hence, in no need of commenting!!!

comments and that's all.

the main thing to do when coding is to try to understand, before to ask for ease.

so, please, try to understand, use your brain a little.

BW05 is for Boot Writer 0.5
it is the 5th evolution.
do ask for the first, i erased it from the surface of the planet.

both Loco, and Octavio, responded with messages indicating that they too understood edfed's goal to include both booting, and "directly browsing".




So, here too, Dex indicates his understanding that the time parameter for this project INCLUDES booting.


and, this reinforces my own thinking that the goal is to show how fast one can access FASM forum, in text mode, starting from POWER ON, not bootup.







In other words, edfed prefers to boot into a non-proprietary file system....


So, Dex and edfed agree that this project entails granting access to the forum directly upon switching the power on, not, with the intermediate step, requiring the user to invoke FAB, as I had envisioned:
power on;
boot
user types in FAB, hits carriage return,concurrently begin timing;
arrive at FASM forum, text mode;
measure elapsed time.

Since the above description is NOT correct, then one seeks to elaborate a more accurate description, perhaps this:
Power on, start boot;
boot complete, start measuring elapsed time by unknown mechanism, WITHOUT USER INTERFACE REQUIREMENT;
enter protected mode;
access FASM forum;
display elapsed time;

My opinion, for what it is worth:
1. The project will be simpler, (and faster) if we agree to boot into a hard drive, formatted with fat32, rather than fat16 or fat12 (floppy).
2. Instead of working on a boot loader, I believe it is more efficient (simpler at the outset) to invoke FAB as an executable sitting on a fat32 partition.
3. After reaching the goal of accessing FASM forum within three seconds, upon the user starting FAB, THEN one can attempt to further reduce this time, by, among other improvements, constructing a boot loader program to execute FAB from power on, without human intervention. Further revision can eliminate the fat32 file system, replacing it with some other design, or simply an open address space as suggested by edfed.

I would instead favor the BOOT LOADER approach, IF WE WERE MEASURING TIME from power on, but, as I understand it, the concensus is, alternatively, to commence measuring elapsed time only upon completion of boot up, therefore like many other improvements (mouse, graphics, etc), it is my opinion that measuring time from power on, instead of from boot up, is just another improvement, to be added later...
Can we agree to specify the direction of this project, stepwise:
1. boot, protected mode, display hello world;
2. boot, protected mode, message to indicate starting FAB, connect to FASM forum, display elapsed time, all in text mode, no mice, no graphics.
If so, then, my point is that we still do not have the first step above, accomplished as of today, 01 March 2008. Are we booting into hard drive? Is the hard drive with or without partition, with or without file system? Will the user invoke FAB, or must the first version depend upon a boot loader to go from power on to FASM forum? It seems to me that this first step in the design must be established, before anything else....

tom tobias: It won't be possible to achieve the time limit unless you allow the BIOS to finish the POST and then start your timer. The reason being some BIOSes take a very long time doing POST before even getting close to loading the boot sector. I'm not sure from your post above if that is what you meant, it is not clear. So I thought I would clarify.

1. power on
2. BIOS does POST
3. BIOS loads first sector (boot sector)
4. *start your timer
5. FAB initialises itself and the system
6. board.flatassembler.net DNS query sent
7. *stop your timer
8. DNS query completes, fasm forum contacted, etc.

Using any other timing mechanism is going to be subjected to outside influences not under the project team's control.

I agree that revolution, that if you time it from power on, you are going to get big difference's in times, as some bios are slower than other's.
Also it would make a difference if you set fast boot in bios options or not.
So any timing as to be after the Bios post.

With this approach, how will someone verify that FAB has NOT begun, until AFTER the boot has completed? Someone like Madis or vid or Octavio or Tomasz or rugxulo or fudder or MazeGen or shoorick will certainly come along and incorporate a significant portion of the initial boot right into FAB, if control of the initiation of FAB rests outside the hands of the observer, AT LEAST FOR THE VERY FIRST iteration. After having FIRST verified that FAB completes in less than three seconds, THEN one can introduce automatic generation.

tom tobias: One can easily place a small text message on the screen when the boot loader starts. Then you can start your manual stopwatch. You must allow the timer to be stopped when the DNS query is sent (can also be another message telling you when this happens) because after that stage all timing is out of your control. If the DNS server is slow and/or your ISP is slow and/or the fasm board is slow then you are timing things that you have no control over. Just now I initiated a reload of the forum and it took 7 seconds to get a response from the forum. You can't expect this type of uncontrollable delay to be part of your timing analysis.

It can easily be verified that the text messages are not cheating you. The source code will show when the messages are displayed. The boot loader can say "start your timer" and the DNS code can say "stop your timer". It is a simple matter to verify in the source code that these messages are not generated by any other code at a different time.

it's not too soon, as it assume parsing of html loaded page is done (parsing for me is the rendering of the html, sorry for the language error)

then, the boot process is part of the project, then, the first task to do, after real mode segments initialisation,

directlly init the timer, rtc or pit based, or both.

then, when the page is fully rendered, the timer can stop and show the exact time it took to start, connect, load, parse.

Thanks edfed and revolution. So, what about the hard disk question?
Repeating from the post above:
"Is the hard drive with or without partition, with or without file system?"

the best is to have the both.
but as partition table is an old principle, i invite to ignore it and restart the OS design at it's begin, this will simplify the disk access.

about the file sytem, for the moment, we don't need one, cause all the system is supposed to only parse html, load html page, send messages.

this file system can be a non disk file system, more a simple structure, support independant, that assume the memory ( ram, rom, drive, etc...) as linear addressing space.

then, the files and the folders will be only pointers.

by evidence, it will be totally uncompatible with all existing softwares, as the all have partitions and file system dependance.
i feel is can be very good to be different, as for security and for progress.
it will expand the possibilities of computers, and bring them a scheme where they become specific use machines, with only one task to do.

after, a meta process (in boot sector) can emulate (with direct code excution) many machines, and then simulate a multitasking operating sytem. i'l really exited of the idea to make a totally backward uncompatible design.

Thanks edfed. I am grateful to you for your patience with me, and I appreciate your many useful, and creative solutions. I wish to clarify a couple of points here.
first:
I think we need input on this subject from Dex and Dosin, if they are still following the project, as I expect they are,
Secondly: I sound a bit like a broken record here, and I apologize for that, but, I think it is VERY important to nail down with great clarity, exactly what the scope of this endeavor is, and to date, that remains a tad enigmatic, at least to me. I am taken aback, just a tiny bit, upon reading from you, something about an OS design, not because your sentiments are wrong, nor because I disagree with them, on the contrary, I find your enthusiasm for an asm OS EXCELLENT, but, I believe, maybe in error, that THIS PROJECT is NOT an OS per se, but rather, a stand alone application, which does NOT pretend to represent a nascent operating system......
I may be completely wrong here....
Here's my summary, based upon reading your helpful suggestions yesterday, and revolution's luminous contributions (thanks!):
TASK: write a program to boot directly into FAB which will connect to FASM forum within three seconds of completing the boot process. Timing this task to confirm the three second maximum duration in execution will be derived from the motherboard crystal, by an as yet unspecified mechanism.
The hard drive containing the bootable FAB program will be either formatted as a FAT32 partition, else an unformatted disk.

they are, i'm sure they follow the project with care, but if they don't reply, it only means they hard work on.
on the last news, dosin is working on the html render, and dex is working on his various projects, including FAB.

yes, this is not an OS, as it don't need an os to work, it can be considered like an OS, but it isn't.

the OS idea is not important, as it will be OS indpendant.
but we shall predict the implementation in an OS. or build an OS onto this, to make it more atractive for users.

no, fat 32 is to ban of this project, the only use of fat 32 or any existing file system is for the OS where we devellop this. for me, it's fat 32 and win98.
for others, it can be ext3 and ubuntu, fat16 and menuet.
the target and the source are different.

the taget is the drive where FAB will be.
the source is the drive with an OS, fasm, and the FAB source code and utilities.

unformatted drive is the one to use for a totla control from FAB itself.
yes, total control of the machine.
the only external ints to use are int10h for video and int13h for drive.
the rest is garbage including int18h and 19h.

and then, this FAB project will be interresting, and a good proof, it will pouve that OS, file system, partition tables, bios int, are only garbages. pure informatic concept.

i am electronician, i can design hardware (i have the experience and the knowledge for) and nowhere in electronics we are confroted to obsolete restrictions, the goal is to make it work.

partition table is obsolete.

I am still working on the inner workings of FAB, from my point of view all early Dev work will be from floppy, then i will do a fat16 hdd ver, once we get to a stage of doing some time trials.
I will also be doing some mock up text mode of the forum, if they do not come out well, we will go back to high-res, as the only reason for going text mode was to make it simpler, if it works out more work or not very useable, then theres little point in using it.

text mode is not simpler to use.
really not.
it's very boring to code fro text mode.
we can at least try to code for the mode 12 or 13
mode 13 is so little resolution that it will be better to code for mode 12

then, dj mauretto experience in mode 12 will be usefull.

please, listen, fat16is a proprietary file system.
and as i said, no partition table and no file system will simpify the project a lot.

Ok, graphics mode 12h = 640 x 480 x 16 colors, as opposed to text mode, 03h = 80 x 25 x 16.
There may be two different meanings to "simplify". One meaning is "easier to create code", a second meaning is "more logical design". Sometimes these two ideas conflict, particularly, if one ALREADY has some code, which then must be modified ONLY SLIGHTLY, to employ on this project, FAB. I understand, perhaps incorrectly, that BOTH edfed and dex have already written the code which they have proposed: edfed--blank disk, unformatted, dex: floppy, then FAT16. It is reasonable for the temporary fork to be tested, I will try to check edfed's method today. What's the worst that can happen, I lose my OS with win98? It's not a big problem. I will give it a try, and report back. Then, when Dex has his next version using floppy, or FAT16, I will try that. Point is, we cannot lose sight of the MAIN goal,
Bootable browser to access FASM forum within 3 seconds following boot. We still need to elaborate the mechanism for counting cycles from the motherboard clock, without disabling interrupts--i.e. without slowing down the motherboard components. The last time I thought about doing this, one marveled at how much faster the new 386 was....