ASM Community

Hi,
As any bare-to-the-metal asm code hacker will agree, we
like to go to the lowest level possible. This means coding in
assembly, but following the same philosophy means also
programming the hardware directly. Those that (like me)
had the luck to live the Vic20, C64 and Amiga eras (I made
commercial games for it, 100% asm + a programming
language created by me) miss much of that freedom on the
PC, where for commercial reasons and for lack of technical
informations (let away the extreme abundance of uncompatible
chipsets) we are "forced" to code in C++, or even Java, and to
use high level, abstract API's to program the graphics and
sounds of the computer.

Fortunately people like you, and this forum is the definitive
proof, don't like to be forced to do silly things, and here we
gained back the right to program in assembly under Winslows.

It is not reasonable, though, to program in Windows for each
graphics and sound chip out there, although I'd be very happy
to help on such a project (an "OpenSourced everybody's OS"..
and I don't mean Linux) if anybody want to endorse it.
Anyway, if we want to remain into a reasonable level, what
we can do though is to go as low level as possible, to the max
possible level where we still get "hardware independence".
So why use DirectX 8, when it is not the lowest level possible
which is "hardware independent"?

If the DirectX DLL's are not specific-chipset dependent, then
there must be an underlying layer. Be it the card's driver, be
it something else, I don't know.. and I'm here to ask it.

I can easily imagine, though, that this layer which DirectX 8
uses is not only still "hardware independent" (being all the
DirectX DLL's the same for all cards), but also considerably
less overheaded (expecially for small objects) than doing
things through DirectX, and also certainly more powerful and
versatile.. since it has to offer all the funcionality required by
all DirectX versions, present and past (and in part even future).

Does anybody know about what this underlying layer may be?
And how to call its functions? And how to get the protos of them?

Although I like to code in assembly even only for the pleasure
of it, I also (and sometimes expecially) see a practical advantage
in doing it. I'm sure that all those of you that agree with my
philosophy, will feel an advantage in skipping useless and
limiting passages if we can.
Using directly the "hardware independent" resource that
DirectX uses seems a much better idea than using DirectX to
me, a more low level idea, and the use we could do of this
increased freedom could very well make our programs a step
superior than going through the GWBASIC coded (well, nearly..
if we consider the overhead) DirectX DLL's.

So I hope this thread gets as many useful posts as possible,
and we start to explore what is behind DirectX 8, since there
must be something usable which is still 100% hardware
independent.. or even partly hardware independent, but
certainly more versatile and performant than being forced
to go through DirectX.

Greets,
Maverick

I think this is what you're looking for:

Hardware abstraction layer

It would definately be a good laugh if you could beat the biggest software company in the world in terms of speed, using a specification they designed and an assembler they created :grin:

*but*:
Even if MS's developers code mainly in C++, I'm betting they already have important stuff written in ASM.
Even if MS has bad coders, they have lots of them working full-time on improving DX.

So, to be short: Good luck :alright: and I mean it too...

Edit: Also try this link. The author certainly seems to have your mindset:

You may want to take a look at the Driver Developer Kits

http://www.microsoft.com/DDK/

although i'm not sure how to get it

Thanks for the replies.. I've got the DDK and will study
how much convenient it would be to go straight to the
Device Driver Interface.

Also, thanks for all the links.

Greets,
Maverick

Hi Maverick !

I would be really happy if there would be a common way to code GFX and SND at a lower level. Also I had coded everything on the good old Amiga in assembler and I'm still missing this machine.

The problem is that nearly every hardware manufactor does his own standard for implementing hardware-functionalities on actual PCs. If you want to code those Hardware-Layers directly your code won't run on others PC's, only if the same hardware is present.
DirectX (exspecially DirectDraw) is a wrapper for all those Hardware-Layers. You only have a hard live as coder if you want ignore that.
(Or you want to code really fast GFX/SND-Apps for the X-Box !)

I think what you want to do will end up into another DX-Interface ... If you want to avoid thousands of constants, structures and interfaces I suggest to deal only with the most simplest of them ...

Greetings, CALEB

Does the DDK specify how to code a Direct3D HAL? If that interface is known then invoking the HAL directly shouldn't be a problem. All the testing for valid features would be left to the application though.

5 Day Lecture/Lab on Driver Programming: $3150 (Ouch!)

Hi Caleb,

You recall the old Seka assembler? Not the easiest of all. And
AsmOne? The best assembler and debugger I've ever seen
in my life (14 years of asm programming, on various CPUs).
I'm sure I know why you miss those old times. ;)
You're right that nowadays device drivers are designed with
DirectX so much in mind, that DirectX becomes more or less
only an intermediatary with the same functions and parameters.
DirectX checks for the parameters, and this slows things down a
bit, let away other things, but all in all the overhead is not too
big, and I think we can live with it. I'll be more sure once I'll have
benchmarked some basic functions, but studying a video card
driver I noticed how much similar were some of its blt functions
to the classic DirectX blt functions. They were almost the same.

Greets,
Maverick

Hi bitRAKE,
I have the W98 DDK, it can be downloaded for free (also other,
but not all, DDK's) from the MS site.
It contains quite all is necessary to write drivers.. I don't think
that you should spend all that money on those lectures ;-)
Also, there are undocumented functions to go to RING0 on
Windows9x OS, and to call most of the KERNEL functions like
a VxD would do; if anybody is interested I'll search for this info
on my HD.

Greets,
Maverick

If there's *one* thing I've come to enjoy about windows, it's that
(well-programmed) applications/games work on most hardware,
unlike the DOS days (and now, linux days) where you have to have
specially written drivers for each and every app, for each and every
card.

This wasn't really much of a problem if you had a SoundBlaster card,
but it was much worse with the video issues... VESA fixed a lot of
problems, but many cards had very flawed implementations. Let's
not go back to *that* mess.

A simple thing using only the simples of the features of DirectDraw,
and doing a full local memory->video memory can easily give me
above hundred fps... if I use video memory sprites and fast blits,
I can get even higher. So I don't really think DirectX is a bottleneck.
The bottleneck is *your* code, and of course the hardware in the
machine.

Ok, perhaps you'd be able to squeeze out a few more fps by
hammering the hardware directly. Or even by using DDI (and even
then very very possibly causing loads of incompatibilities). But what
use is that if you go from 100fps to 110fps? Also, if I remember correctly,
DDI can only be interfaced from ring0, and only by video device
drivers (ie, not generic device drivers). And you'd have to write
code for both NT and 9x. And, guess what, you'd just end up with
a mini DX version, lagging behind compared to the microsoft one.

DirectX might not be the best possible API, but at least it works
pretty reasonably across a broad range of hardware, and it allows
for pretty nifty speeds. Even on older hardware, as long as you
stick to a reasonable subset of the API that doens't require software
paths to be taken.

Perhaps I'm wrong in this, but I think not. Sorry if this sounds a
bit agressive, but it annoys me when people seem to think that they
can get better performance *just* by writing in assembly or *just*
by accessing the hardware at a lower level. This sort of elitism is
one of the reasons assembly has gotten a bad name in some places :(.

Hi Maverick

Yeah ASMOne was a good thing ! Such an assembler is missing on Windows - Short exe and all you need is integrated ... inclusive a debugger !

Hi f0dder

I agree with you, but I think too, it's not an annoying thing to try the best performce which is possible ... even if one tries unconventional ways. They must not be bad ...

But nowadays we think like:

Wow - I've programmed a super effect-funciton, which can do those nasty things ... but it runs a bit lame on my 2 GHz-PC ... OK never mind, tomorrow I'm going to buy a 4 GHz-PC !

And that's not even better !

Greetings, CALEB

f0dder:

Wow.. what a post.. and what did I deserve to get all of your
anger? Perhaps you just had a bad day? Sorry about that, but
that's not my fault.

You practically imply that I'm a dumb wannabe that just because
it's assembly then it must be automagically faster; or that I nag
on the overhead of DX when it's my code instead that simply
sucks.

You wondered if you were maybe too aggressive, well pal, you
indeed were, and I don't think you had any justification to it.

FYI I code asm since 14 years ago, 6502/6510, Z80, 8080, 8085,
x86, 680x0, PowerPC, various PICs and other microcontrollers,
etc.. it sucks to talk like this but evidently I have to.
I invented my programming language, compiler and debugger
(HLA, which stands for High Level Assembly) on the Amiga long
before I (unfortunately) had to read this same word about a PC
product.
I wrote my HLA, with which I wrote commercial games.. because
I (not worse than you do, be sure) know that sometimes to code
in pure assembly is a waste of time. It took me the same time to
write HLA + my Amiga game Virtual Karting, than if I had written
only Virtual Karting in pure assembly. Also, HLA (there are some
old, public posts about it, although it was never released
because it was an internal development tool) had a very good
optimizer, which proven superior to the one of SAS/C in many
tests. Also, there's now a version for PC which I'm developing,
and I'm working on a game while doing it (the best test bench
for a compiler development IMO), just like 7 years ago on the
Amiga.

I hate to talk in this "I did, blablabla" way but you force me to
do it with your "you stupid, assembly alone doesn't make code
faster than the one that the VisualBasic compiler can produce",
or "DirectX has no overhead whatsoever, it's your code that
sucks".
Let away that it's everyone's right to code in whatever style
he prefers, and I never nagged at you (nor will ever do) just
because you probably use MASM instead of the better written,
simpler and more linear NASM, just as an example. I urge to
make you note that when you have to blit thousands of very
small sprites your beloved DirectX can be a *serious* bottleneck
vs the ideal hardware performance. We disagree also on the
fact that to exploit the full potential of the hardware is an
important goal for a coder. For me it is. I don't say "buy a faster
CPU" every time this problem arises, I rather find more optimal
ways to code, if the results are worth the added development
time.

Also, I don't understand why you tell me that assembly alone
doesn't make things faster, father. I don't have the presumption
to go teaching others, I'd like to know why you have it and what
experience do you have that entitles you to do it, when me and
others do not *want* to do it.

By any means, if you're happy with DirectX overhead go with
it, but do not imply that I or others are more stupid or more
ignorant than you, nor call me/us elitist when the other elitist
here evidently is you. You live too much with schemes.. that's
not good for a assembly coder.

Sorry to be that harsh, but you started it with no rights.

Have a nice day,
Maverick

Maverick, no need to get THAT defensive :). You probably read
my post a bit harder than was intended. The "just because it's
assembly it's faster" wasn't targetted at you, it's just an
observation I've done. I think you'll have to admit that *just*
using assembly isn't a magical wand... an asm bubblesort will
still suck compared to a C quicksort.

While I think 100% assembly is a bit silly in most fields, I do
still acknowledge that it has uses, often has uses, and will
for quite a bunch of years to come. I don't like the common
mentality that you should just buy a bigger CPU every few months.
On the other hand, I don't like the way some people (not you)
say that it's not possible to write good code in higher level
languages (let's exclude VB from this thread. It probably has
it's uses, although I haven't seen it ;) ).

Yes, if I write larger code in assembly, I use masm instead of
nasm. If a tool has numerous advantages without (too many)
disadvantages, of course I use it. Sure, you can fix up nasm
pretty well with a lot of macros, but still masm has a better
feel to it. I often do use nasm though, as it has other advantages
that would require quirky workarounds in masm (or stuff that
isn't easily found in the documentation).

Hm, beloved DirectX... I don't love it. And I don't think it's
necessarily the best API. But it's what we have if we want broad
hardware support. While I think it would be interesting to see
whatever you can come up with, I fear that you would lose compatibility.
*if* you manage to come up with some significantly faster that
still has very broad hardware support... well, I'll be just as
happy as everyone else :).

I think it's important to take full advantage of the hardware.
When it's beneficial. When you're actually able to feel the
difference. Yes, graphics is one of these areas. But I'm still
much against going directly at the hardware. This is possible
on a number of platforms, especially the gaming oriented ones,
as they don't have as broad a range of hardware. The PC scene
is notorious for all the crappy different parts and incompatibilities.


Please understand me correctly here. What I mean is... *just*
by writing a thing in assembly doesn't make it faster than the
same thing written in, say, C. If you do a dumb line-by-line
translation that is. A mov is a mov is a mov.
If "myVariable = 1000" generates "mov , 1000" in
C, and you write "mov , 1000" in the assembler...
has the assembler code given you a speed advantage?

Of course it's possible to gain speed advantages by writing in
assembly rather than in a HLL, since you can do stuff in asm
that can't be done in a HLL. I've never disagreed with that.
Sometimes it's easy to beat your compiler, and a few times you
can't (but that's very rare).

Another example... some guy might spend time and write a *perfect*
clipped putpixel, the super fastest code you could *ever* write
for that CPU, in asm. Use that in a sprite drawing app. Chances
are that a non-putpixel based approach in a HLL (with decent use
of pointers) would be faster. Algorithm design can often be more
important than going straight to the assembly (which I don't doubt
you already know - I'm just trying to clarify my opinions.)

I don't doubt you're a better coder than me. There's a lot of
people who are much better than me. I have only been in this
"game" for a handful of years or so. Hell, I wouldn't stand a
chance against BitRAKE or Eo?n and probably not you either. I do
acknowledge this. But looking at the assembly code written by
a lot of people, I can easily defend my statements... of course
this is fine if the people enjoy themselves, as long as they
don't fool themselves and think they're doing a better job than
a compiler.

Am I a hypocrite? Probably. Am I arrogant? Sometimes, probably.
Do keep in mind, though, that this is pure text and doesn't have
any facial mimics, body language (et cetera), and might thus come
out (a lot) worse than intended.


Free speech :).

I don't wish to run a war with you, by the way. I shoudl try to
make my tone a bit friendlier, and perhaps give better explanations
of my statements... that would probably help.

You have a nice day too, and please stay with us - it's always
nice to have people with different opinions.

I kindly ask you and f0dder where did I ever say that I want to
design a new low-level interface, or 10000 drivers? Where/when
did I say that?

Greets,
Maverick

Guys,

He just told he want to go to a LOWER level not to the LOWEST level, he wnat to talk to the HAL, that is he will still be using the drivers that windows provide, he will just bypass DirectX.

And belive it: DX has some bottlenecks esp ::Lock methods are slow. Also lately features that the videoboard universally have (alpha blending in 2D and direct video memory acces) started to be eliminated from DirectX. This is pretty dump for the "profesionals" that do DX.... so IMHO Maverick has a point

if he can or can not do it...that is the question?
Is the HAL enough documented or not?

and fodder we can also choose the best algorithm in asm and then ... i mean given the best algorithm only ASM will give the full speed :). I just wonder why HLL ppl assume ASM ppl can not choose the best algorithms :P

Doing full games/apps in ASM is silly? arghhh Hostile Encounter :P

besides i have just restarted to do my own OS fully in ASM...

hehe i guess i will have to study the same HAL to do my 10.000 drivers for my OS :(

I've never said that bogdan. Just that doing asm *before* choosing
the best algorithm is folly.


Except those (very rare, admitted) occasions where you can only
get to the level of the compiler.

Dear X-Calibre,

All the things that is say here are IMHO, please get my excusses if i did not let everyone understand that. I respect your oppinions but i also expect that you respect mine's.

With DirectX, ::LOCK is not my concern, it was just an example where things could be improved in terms of speed.

Please note that we use DirectX in Hostile Encounter :) so i am not anti DX, and not anti M$. I have a deep respect for each ppl/application that does better that what i did ... but please understand i also find it normal to be critical about what they do wrong IMHO.

Directx developers decided to remove support for direct video memory acces (this in a game library/sdk!) and this is LAME IMHO.

Also the sad fact that video boards support 2d alpha blending from over 6 years now and DX never incorporate this feature in their releases (allthougt the said they will in their docs and they use it in GDI32 and HAL drivers are required to do it if possible) is ALSO LAME.

In order to prove this i usually make my own applications. Partially that is wahy i started HE and now my own OS... i will show in my OS (game oriented) that is possible to get both speed and protection

Quality? well HE never carshed on most of our users not even once! and it is in the pre alpha stages of developement and written in ASM and yeah using that dangerouse (for system stability ::Lock method)

Yes, MS sometimes sucks, and yes i can do better (if i only had the money) but MS has also done some great things for programming and even for ASM programming (see MASM and flat memory model) And I recognise that.

I do not want to be "lowlevel" or "elite" neither am I

I have nothing against a well done VB or VFox or Perl application as long as it suits a certain need.

I myself do quite a lot of VC++ and Vfox HLL programming for a living.

Hovever i know its not the best solution its just a compromise to get a living ;) and get the project done in time (teir time)

And most of all i will never belive a thing because many ppl use it or many ppl say it.

As Socrate stated it: the word of a true master is beter that 100.000 words from normal ppl. (note that i am not a master ;) nor i do consider myself as one)

And please let's keep it to the subject of Maverick's Questions or else let's move to the Crusades

The man just wanted to make a better version of DirectX using the HAL interfaces, what is wrong with this. IRC doing it will be the real hard part...

So let' show him the problems, help him if we can and wish him the best of luck...who knows even if he will not succed he will learn a lot from it and maybe he will share this info with us :)

All this is IMHO
Best regards
Bogdan

This is really sad...

I thought this could have been a really good topic of conversation, but due to a few "people" arguing about why it shouldn't be done (in a very rude manner -- IMHO) I've decided this is isn't worth reading.

If I were Maverick I would copy the first forum topic into a new thread and send the rest of this load of garbage to the Heap...

I wish people where more supportive of other people's ideas.

-Directx isn't written perfectly and if someone wants to "try" to create a better interface to the HAL (or BETTER just talk about how it would be done) I think he should be supported. At least as an exercise in learning.

THE POINT IS: He didn't spend ?? minutes writing a thread -- just to have someone say it's "stupid" or "You can't get much better then ...." reply.

A good idea to follow: Check your additude at the door... If you can't do that then don't respond to thread... it's that easy...

With that said: I'm going to a different topic :alright:

If I would start a poll: Do you want to stop this discussion, would be there anyone here voting with NO ?

Guys - please keep cool. Let's discuss about the basic of Mavericks' Idea and not about the question: Is DX being botched or not ?

Perhabs we should take a look at the LINUX-Scene: There exists a project which try to realize a library for direct-hardware-access to graphiccards. Perhabs someone here knows more about this and can tell something about it ?

(Due to the fact that nowadays only 3 - 4 GPU-families exist the basic idea isn't as bad as we may have thought at the beginning of the discussion ...)

Greetings, CALEB

P.S.: Don't forget to vote ;)

In fact.. what I said (thank you for reading me correctly) is that:

1) DirectX checks and validates for parameters. This is often a
redundant work (and in some cases relatively slow), so why
should I do two times (in my application and in DirectX) the
same thing? When you've to blit thousands of small sprites per
frame it indeed does a big difference.

2) Modern hardware is practically designed with DirectX in mind.
This means that the HAL's DDI functions, which are standard and
exactly the same on all different boards (although, just like with
DirectX, some features may be supported, and some others not),
are in practice extremely similar in functionality to the DirectX
functions; thus I don't see why one, if it's viable, shouldn't call
HAL's blit routine instead of DirectDraw's perfectly equivalent blit
routine.. which simply adds severe (and sometimes relatively
slow) parameter checking/validation, some times grabs the
16bit MUTEX (I don't know if the HAL does that too), and God
only knows how many other things. F0dder, don't get me wrong
pal, but just because you can blit a couple of big sprites at
100 fps doesn't mean that we must be all happy. In the era
of PacMan, having a 100MHz machine would have been a
temptation to code everything in GWBASIC from then on.
Today's 2GHz machines and superfast graphics cards are
useless if we think about yesterday's or today's applications.
IMHO I shouldn't even talk about this in a forum dedicated to
assembly language!
I could have to do it in a Java forum.. but it makes me a bit
astonished that I've to write these things in a asm forum.
Assembly will always have a place, as long as coders will know
how to take advantage from it (IMO forever). Going as low level
as possible in gfx/snd programming is exactly the same thing.



I have read, but haven't checked it myself yet, that under DX 8
locking a texture which is also a rendertarget causes a videomem
to systemmem copy.. and unlocking it causes the opposite thing.
WHICH IS DAMN SLOW.
But under DX 7 this doesn't happen.. and the pointer that lock
returns is in videomem. The DX 8 scenario has such a hit in
performance that it makes the hardware go back practically
of 3 years. The problem is that all of that performance hit is
not really necessary, if DX 7 under the same drivers doesn't
do that silly thing!!

So talking directly to the HAL *has* important, sometimes
dramatic reasons. Sure, f0dder calling whoever is seriously
concerned with these problems an "elitist" doesn't help
nobody. We should all team up and make a real advantage
of our philosophy (reflected in our love for assembly).. of
course we don't must all agree on everything, but I don't
think that being hostile or calling names is a good thing for
any of us.

F0dder, believe me when I say that I have nothing to share
with those people you were referring to. I know very well
also that the example of above may well be that Microsoft
is starting to discourage the use of pointers in videomem,
to make happy those video board manufacturers that want
to use proprietary texture formats to improve performance or
to use undisclosed technologies. Of course Microsoft is more
concerned with market than technology.. but if they want to
discourage to access textures directly because in some years
the hardware will all use secret, proprietary texture formats
(and do the conversion to/from systemmem when loading or
locking/unlocking them), this doesn't mean we've to pay
from today that big price. I mean, I don't see why my today's
application should run 5 times slower than it could. Every wise
programmer will revert back to a compatible mode if those
features aren't supported by the hardware (and the HAL says
this exactly like DX), and future compatibility is assured as well.
In two years maybe that trend will die and all of the sacrifices
eventually done would have been useless anyway, when no
hardware manufacturers wanted anyway to implement secret
and proprietary, directly unaccessible texture formats. Who
knows? Coding well doesn't mean stop thinking with your brain
and do every thing Bill Gates tells us to do. Remember, 640KB
will be enough for everybody, forever. Sometimes even Mr.Gates
returns back to his steps.

Also, for the same reasons AFAIK DX 8.1 doesn't allow anymore
to lock the primary, visible buffer.. but only the backbuffer. I think
that every limitation should have a real, serious justification.
Otherwise the day that I need that feature I will become very
anarchist.. and THEY will be responsible for code that breaks
on some machines.. just like governments are responsible when
a bad, unacceptable and totally useless law makes millions
of people die of hunger, and the people by very consequence
perform actions they wouldn't ever have the need to do (let
away the wish).

Compatibility problems in Dos games were due to a stupid
lack of standards (e.g. VESA came late, and was designed in
a very bad way.. they should have provided the protected
mode interface since the early times, and more features).
There was no serious equivalent to VESA for audio (including
the "VESA audio" itself).. hardware manufacturers didn't agree
on common lines until late.

I'm sure that bad coders would produce crappy and
uncompatible code even in Java.. don't blame the wrong
people please.

Also lately features that the videoboard universally have (alpha blending in 2D and direct video memory acces) started to be eliminated from DirectX. This is pretty dump for the "profesionals" that do DX.... so IMHO Maverick has a point

I also wonder why some basic functionalities present in all
hardware are not available in some DX interfaces.. that maybe
was done (not always, but in some cases) just to make DirectX
look easier to use, etc.. which is a even worse reason than
making happy the board manufacturers.
I don't think I should have these constraints.. nor anybody else
that doesn't want them. Be clear, I do respect whoever thinks
different than me, but I ask this respect as well.

if he can or can not do it...that is the question?
Is the HAL enough documented or not?

And my original post asked for this information, or to team up
to find it. After all, I was asking this into a assembly forum, not
into a Java or VisualBasic forum.

Also, I'm sure that programming directly the HAL would be
easier than going through DX->HAL *if* one (like me but I'm
sure also many other asm coders here) need/want to use only
hardware accelerated functions, and to go straight to the point.
I'm pretty sure that if it wasn't for hardware acceleration, almost
nobody would use DirectX anyway.

and fodder we can also choose the best algorithm in asm and then ... i mean given the best algorithm only ASM will give the full speed :). I just wonder why HLL ppl assume ASM ppl can not choose the best algorithms :P

In fact.. f0dder is right to say that a lame algorithm in asm will
be slower than a good one in HLL, but I'd rather say that if one
knows asm well, and knows why he wants to use it, he most
probably will be incline and experienced enough to use or invent
good algorithms *as well*.
Instead many "I love HLL, asm is for grannies" people don't
even have a real clue about how a computer really works inside..
they'll be happy with whichever algorithm their favourite book
provides them.. but benchmarks show no pity. Let's not start
a polemic though.. I don't want to offend anybody, I just want
code, fun and friendship. It's just that offends me when some
of that kind of HLL programmers call us old farts. :grin:

Doing full games/apps in ASM is silly? arghhh Hostile Encounter :P

Everybody has his own vision to it, which must be fully
respected IMHO. Personally, I started my HLA (High Level
Assembly) on Amiga first as an intelligent macro system,
because I didn't see a point in doing in asm things like
calling the OS's file routines, while writing LOADFILE would
have been more readable and quicker to develop (said
LOADFILE then expanded in a serie of MOVE's and JSR).
But then the idea extended and extended into a HLL compiler,
which anyway still retained complete support to asm and
to "medium level" coding as well.. but also some neat HLL
constructs.

besides i have just restarted to do my own OS fully in ASM...

:)

hehe i guess i will have to study the same HAL to do my 10.000 drivers for my OS :(

;-)


Sincere greets to everyone, whatever are his views on the
argument.

Maverick