mov eax,[eax*4+4]
-> eax*4 in temp
-> eax+4 in temp
-> temp as a pointer
->[temp] in eax
show as eax have the value that was at [eax*4+4]
    

scenario0:
.0:
show the ram, 'cs:ip' and an arrow to the ram location
.1:
show the content of the location, a rectangle, and hex value '40h'
or a binary value for crazy explanation
.2:
arrow to source code line,text of code= 'inc eax'
.3:
arrow to the 'ALU', one to 'A', one to 'function select'
.4:
text value '1' in 'A'
text 'inc' in function select
.5:
highlight 'eax'
.6:
arrow to 'reg eax'
.7:
show eax 'value'
.8:
arrow to ALU, 'B'
.9:
execution in 'alu'
.10:
ALU output in 'C'
.11:
arrow to 'reg eax'
C to REG eax
    

a sort of debugger, based on source code, that will explain step by step the code.

the code can be simulated (animation). and then explain what is doing the single instruction.

the main problem with asm is to explain the memory mapping, access to address, address computation, result of xor eax,eax, etc

the Q is how to code this program?

From the title I thought it was going to be about a new filesystem project. Smile

To add to edfed's example, maybe you could make something like a very simple OllyDbg (HelloWorld! example), but with some more details and more user-friendly texts/descriptions inside round or rectangular callouts like in comics, that appear gradually as you trace through the code.

yep
for example:
'inc eax' instruction

Code:

scenario0:
.0:
show the ram, 'cs:ip' and an arrow to the ram location
.1:
show the content of the location, a rectangle, and hex value '40h'
or a binary value for crazy explanation
.2:
arrow to source code line,text of code= 'inc eax'
.3:
arrow to the 'ALU', one to 'A', one to 'function select'
.4:
text value '1' in 'A'
text 'inc' in function select
.5:
highlight 'eax'
.6:
arrow to 'reg eax'
.7:
show eax 'value'
.8:
arrow to ALU, 'B'
.9:
execution in 'alu'
.10:
ALU output in 'C'
.11:
arrow to 'reg eax'
C to REG eax
    

11 steps, and a lot of basic events, inculding transparent events, like hide a signal, a line or something.

Great project Smile, i am always being asked for a good tut on fasm, but the biggest thing that is missing is a 32bit mode asm programming tut (not window as we have them).

99% of the asm tuts are based on 16bit realmode, the best thing to do is to take a good asm dos tut and convert it to 32bit mode with the same examples etc, so newbees can learn and compare the two.

I also think your tut should be based around a fasm hobby OS's, maybe MenuetOS/KolibriOS
As i am making a MenuetOS/KolibriOS functiom wrap, so the same code will work on DexOS too.

very nice idea
I started my vCalculator some months ago. The concept is something like edfed says in his example/explanation, but related only to calculations that will be showed regarding flags and partial results.
For example
setting a variable in eax and ecx

1) xor eax,eax ;<--- show flags / result of eax
2) and eax,ecx ;<--- show flags /results for eax /ecx
...
and so on

Also, it is possible to study flags and partial results at each single step , for the common logical/arithm operations. In this way it may become more accessible task that of start coding a simple xor engine, or a decompression module, for example.

At the moment i have no time to dedicate myself to this nice idea.
I am releasing fasmlab (with code hihlight/block commenting/verticals selection etc..) in few days, it is to say, before Christmas
fasmlab before Christmas ....
but pehraps the new year will bring something really cool from this
thread,
or i hope so...

Regards,
hopcode

The first and most important thing to learn is ethics. Most textbooks leave this until a late section, which often makes tempting situations before revealing the seriousness of having decent ethics. As a programmer, you will take on both the fames and burdens of other programmers. Just like joining a religion, if you do bad things, you make everyone else look bad. However, unlike a religion, there are only a few simple guidelines to follow (though, many would love to make more). These are mostly rules accepted by programmers to insure that only good things happen (much like the ethics followed in a scientific community), but unfortunately, not everyone follows the rules (like people in the scientific community with an agenda).

First and foremost, you can indeed impress someone by making a supervirus that can make the computer act strangely, but releasing it on the world and annoying those less informed will win you no attention (unless you get arrested) and will surely ruin the view people have of programmers. I, for one, have lots of bad experiences where people end up with a computer problem, then they blame me because I'm the only person they know personally who knows how to make computer programs. They simply assume that I must be the cause.

This leads me to the second rule, you can't be lazy. Lazy people make buggy programs which tend to fall apart. I'm sure you would never use microsoft word if it were to receive a fatal error every 2 or 3 pages of typing and you couldn't recover your documents. You need to make things that are reasonably "robust." "Robust" is often a keyword used by many programmers and employers who wish to describe the quality of someone's code ("code" is what programmers write which turns into a usable computer program). If it's robust, it's never bad unless you're trying to show an example of a bad program or security system. Conversely, as part of this rule, sometimes robustness needs (or can reasonably be) sacrificed for speed, which is often important, because you don't want to wait 10 minutes for the computer to add two numbers together simply because you felt that the program should continually check to make sure the user typed a number. If robustness is sacrificed (usually only best when coding for another programmer), it's expected that you tell the person using your code what all could go wrong and what would cause that to go wrong.

Now, like before, the third rule was led into by the last statement. You must communicate with people about using your code, and let them know of the dangers of your code. This is called "documentation." This term is used alot, and not just inside programmer circles. Nothing except a slow and buggy program angers people more than a program that they paid for but don't know how to use. It's bad to underdocument, but don't overdocument either because then people will be too bored with it to figure out how to use it. Ever had to figure out how to use a fancy coffee pot or your first cellphone? Surely you thought it was easy, you ended up making a mess of things, then you looked in the trash for the instruction booklet. Sometimes, if the code is small enough, and it's only for programmers, keeping it "readable" is sufficient documentation. In the next lesson, you'll be introduced to some code, and something called a "comment" will prove useful for documenting code that is difficult to read. This rule is also very useful to you, because you may easily forget what something in you code was intended to do.

These rules essentially fall under only section 1.2 of the ACM's "Code of Ethics." I recommend everyone get to understand the responsibility that comes with programming, looking up many codes of ethics and so forth to get a real feel for what's expected of you. My most recommended reading is the following url, which is often copied into many, many textbooks for programmers:

http://www.acm.org/about/code-of-ethics