the problem was multiple.
the push and pop weren't balanced, pop ds, but no push ds, come from the RM version...i just forgot to erase all segments push and pop.

the pic wasn't initialised

now, i'll upload the new version and work on the OO structure.
the OO structure will simplify the building of menues and frames.

i'll make:

OO version of graphics for builts. but not needed, we can make the frame in html and draw it with the sequantial version.
sequential version will be saved for use with parser. and easy tests.

Update on work i have done to FBrowser
[update] See screenshot bellow

cool, where is the update?
seek everywhere, and didn't find it

looks real good Dex...

I wonder how far things need to be complete before anyone else joins in?

@edfed, its a challenge to code a fast bootable browser, so all you need is the basic template.
@dosin ,Also i have challenged some C coders to do it, they think they can do it better than asm.
@all, Here is the new FBrowser.exe for you's to try, it got many new things eg:
IDT, keyboard, time/date, skinable gui, large fonts (as well as small).
I have taken the go back to realmode out, as its not needed, its a bootable browser, that means it does return, also it sets vesa mode once on bootup in realmode.
Regards Dex.

See below for latest ver.

good, but how do i make it work?
it's not a binary, it needs a formated floppy, and i don't find it cool.
C coders, they probably can make it before us, but, the goal is not to make it in C language. they can try in asm if they are interrested.
before us , but not better and not faster. impossible.
you shall think about a pure floppy image version, there it can be interresting. exe format is M$ and IBM based.
so, as i see on the screenshot, it looks pretty...

see you later, i'll work on the binary version. the one to directlly put on the floppy without file system.

You just needed to make a floppy from the old selfextracting exe and replace the exe on the floppy with that exe.
Anyway i have updated the selfextracting exe and the qemu image so you can, just us them.
Here is the NEW self extracting exe to put it on a floppy
http://www.dex4u.com/FBrowser/FBrowser.zip
Here is the NEW floppy image and .bat file to test it in a emulator qemu.
http://www.dex4u.com/FBrowser/FBrowserE.zip

If you want the res to be 1024*768, i have put it in a folder on the floppy, just replace the one in the root dir.

sensational.
Wow, C programmers think they can OUTPERFORM ASM, what a joke. Brilliant.

Well I think it's more about the programmers outperforming other programmers, not the languages themselves. The well written C code backed with good compiler can outperform badly written assembly, of course.

Update on work i have done to FBrowser, add new suff including added icons
EDIT Moved here:
http://board.flatassembler.net/topic.php?p=70861#70861

Here is the question raised by this FASM project: is it possible to construct a browser to permit access to the forum within three seconds from power on? So, I wish to turn Tomasz' statement on its head: Badly written C Code is AS DIFFICULT to debug, as badly written ANYTHING. The premise of this FASM project, however, is NOT to produce a "product" capable, in the marketplace, of dominating NOT ONLY the Intel architecture, by complying with the three second requirement, BUT ALSO to execute with measureably equal rapidity in RISC machines, such as ARM, or NEC's architecture, or the (now defunct) Apple/IBM/Motorola cpu, or any other cpu architecture. So, that particular advantage of C, the ability to transcend individual instruction sets, by functioning across many different machines transparently, represents no advantage at all for this project. It is my premise, perhaps erroneous, that this is where Dex's challenge arises, i.e. my assertion that THERE EXISTS NO C Compiler, TODAY, that is capable, on a conventional P4/3ghz cpu of running FASTER than the FASM assembly language version of this FBrowser project. In other words, I challenge Tomasz, or anyone else, to produce a (well written) C program (of more than ten lines!) capable of executing FASTER than the equivalent (well written) program written in Assembly language. The reason for the commercial success of C has nothing to do with performance, and very little to do with its aforementioned independence across various cpu architectures, and much to do with PROGRAMMER PRODUCTIVITY, i.e. how much of a project can be completed within a particular amount of time. There have been MANY studies addressing this question, and invariably, HIGH level languages result in greater productivity, than assembly language programmers can generate AS A TEAM. Such studies tend to IGNORE real time execution performance of the final product, however. Further, most, but not all, assembly language programs are inscrutable to anyone but the author, therefore, a large group effort tends to result in chaos, rather than success, whereas most C programming efforts tend to generate code of more uniformly readable character. What, in my opinion, Dex had proposed, to his friends in the C programming field, was strictly performance related, (beat the three second limit!), and aimed at demonstrating neither comparable readability of the source code, nor productivity of the group effort, when compared with C.

I haven't followed this topic much - but it seems that after a while its starting to get in shape. The goals are clearer and some serious something is already ready

yeah
exact
and i'll say something:

i code rarelly, i'm too lazy lazy lazy.
sorry, if i coded really frequentlly, some job can be achieved faster.
sorry.

i spend the most of i time in sleeping and do nothing, watch dragon ball z movies, smoknig weed and drinking beers, i'm really not serious, sorry.

i'll try to work more frequentlly, but i think my creativity come from my inaction.

The "big three" compilers these days seem to be Intel, MSVC, and GCC. Surely they are correctly considered "good enough" for lots of tasks and are used frequently. However, it's very difficult to target speed for multiple machines unless you really really know what you're doing (e.g. make it run well on a 486 as well as a 586). These compilers have had a lot of work done to them, so they don't quite totally suck. BUT, it's true that assembly gives you finer control and smaller size. A program could be "well written" for a PPro but run relatively slow on a plain Pentium. It seems that you either have to have multiple optimized routines for the same thing for various processors and/or you have to drop down to raw assembly.

keywords: pipelines, clocks, loop unrolling, simple vs. complex, alignment, cache, stalls, strength reduction, profiling, AGI/address generation interlock, register dependency.



Ever heard of IOCCC? And there are various flavors and extensions of C (plus different styles, e.g. bracket indentation, variable naming) that can compound things. But assembly is worse re: different syntaxes (although mostly similar but not quite good enough, IMHO).

i have a serious problem about speed.
can you explain, you who have experienced this before, why is it too slow?

the test is about fbboot.bin & .asm.
simply copy this on a boot drive and see how much it's slow.

edit:

updated, added some functions in the FB KB.zip
FB KB2 is the old version.

DOSIN:
update, 4 usefull functions added.

Turn on caching and it will be much faster.

Thanks!

bitrake.
ok, i'll try it..... !!!

it don't change anything

and cache is only for instruction and data prefetch, screen memory is external, and caching screen memory, for high modes, is a waste of ressource.

Dosin:
i have a bug, if i make this fbboot.asm format MZ, nothing appens...

but for the boot version, it's ok...
and as it's a boot project, i think we don't need the MZ version..

does anybody know how to obtain a good frame rate, for video, it's 24 FPS, so... i don't understand why it's too slow with my algorithm...
please, help there is a solution, i'm sure, direct X and opengl are able to print fast...