flat assembler
Message board for the users of flat assembler.

Index > Main > tree view

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 17 Mar 2011, 18:22
there is the first try of the tree view.

a blue dot means a node (folder)
a green dot means an item (file)

then, this first attempt to display something like a tree is successfull, and don't needs a lot of code.

of course, it is very primitive. no texts, no icons, no possibility to play with the tree, but it is there, a tree view.

Code:
        org 100h
        mov ax,0a000h
        mov es,ax
        mov ax,13h
        int 10h
        mov si,tree
        call caller
        ret

tree:   dw node,@f-$-2,\
        .F,.D,.1,.2,.3,.4,.5,.6,.1
        @@:
.1:     dw node,@f-$-2,\
        .7,.8,.9,.A,.B,.C,.D
        @@:
.2:     dw node,@f-$-2,\
        .E,.F,.1,.3
        @@:
.3:     dw node,@f-$-2,\
        .1,.A,.B,.C,.D,.1
        @@:
.4:     dw node,@f-$-2,\
        .7,.8,.9,.A,.B,.C,.D
        @@:
.5:     dw item
.6:     dw item
.7:     dw item
.8:     dw item
.9:     dw item
.A:     dw item
.B:     dw item
.C:     dw item
.D:     dw item
.E:     dw item
.F:     dw item
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
caller:
        push ax
        cmp si,0
        je @f
        mov ax,[si]
        cmp ax,0
        je @f
        call ax
@@:
        pop ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
node:
        push bx cx [x]
        add [y],1
        mov [c],1
        call putpixel
        add [x],3
        add [y],4
        mov cx,[si+2]
        shr cx,1
        dec cx
        jl .end
        mov bx,0
@@:
        push si
        mov si,[si+4+bx]
        call caller
        pop si
        add bx,2
        loop @b
.end:
        pop [x] cx bx
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
item:
        inc [y]
        mov [c],2
        call putpixel
        add [y],2
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
putpixel:
        push ax bx cx
        mov ax,[x]
        mov bx,[y]
        shl bx,2
        add bx,[y]
        shl bx,6
        add bx,ax
        mov cl,[c]
        mov [es:bx],cl
        pop cx bx ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
x       dw 0
y       dw 0
c       db 0                   

based on the same principle as fool.

now, i have to find a way to travel in the tree as windows does (explorer), by clicking on the [+] it will show inside the node, etc...
for this, i think that i will create a set of flags to tell if the node is opened, or not.

i will need to connect items to the node they come from.
Post 17 Mar 2011, 18:22
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 21 Mar 2011, 20:12
Are you asking or saying/teaching/informing?
Post 21 Mar 2011, 20:12
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 21 Mar 2011, 20:31
both.
try to inform, and launch some development around trees in asm.
Post 21 Mar 2011, 20:31
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 21 Mar 2011, 20:48
Hmm Interesting. The reason why I was asking was because I had an I dea to contribute, but I think you may have already thought about it.

I was thingking that you make an event callbacks engine that will dispatch the events to registered listeners. Like when you click on a DOT, the callback engine will dispatch what type of click it was {Double Or Single Click or maybe the middle button, path of the tree, parent branch ( With a pointer to it's children branche(s)) } With the location of the cursor, if needed.

So let's say I made an app with a tree. So I would register a routine that would receive the dispatched events.

Ex.
Code:
let's say the event dispatcher calls the registered routines with the following parameters

BX points to tree .The one I created
DI points to tree  data sctructure. 
AX points to eventId


MyTreeEventRoutine: ; proc
 PUSH BP SP DI BX
  
  cmp ax,TREE_CLICKED
  je    .clicked
  cmp ax,TREE_COLLAPSED
  je    .collapsed
 ...
.clicked:

DI contains what we want

[DI+4]  which button was clicked ( Left, Middle, Right) 
[DI+8]  High byte (point: X) Low byte(Point: Y)

etc

jmp  .loopCode
  POP ...
ret
endp

    


You get what I mean ? Smile Smile
Post 21 Mar 2011, 20:48
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 21 Mar 2011, 22:12
i get it, it have a name.
fool.

with trees, the dimension of programming changes a lot.

instead of having sequantial code with branches like you stated, you have multiple trees of action, items, initialisations, options, etc..
it looks a little like the windows registry, but is direct, no extra layer, direct asm execution behind the items.

tree programming is like a virtual machine.

instead of sequential CPU, you have item CPU. thaat will travel in a tree instead of a sequence.

from outside, it is the same as any programming langage.
but the difference is data vs code.
Post 21 Mar 2011, 22:12
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 22 Mar 2011, 01:01
Sounds like a lot of recursive?

Anyways, I'm yet to see nested recursive functions in Assembly though.... Can you make the nested fibonacci recursive function that calls itself in another fibonacci function......Heheheheh.......right now.... I'm not demanding Very Happy
Post 22 Mar 2011, 01:01
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 22 Mar 2011, 01:02
BTW, does your tree have a fixed length and size ?
Post 22 Mar 2011, 01:02
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 22 Mar 2011, 01:11
recursion is possible, but should be limited with a counter.

@@:call @b
is an example of impossible recursion.

mov cx,10
@@:
dec ecx
je @f
call @b

is possible reccursion..

a tree by definition have not a fixed size, nor lengh.

each tilme you add a node, you can add nodes inside, etc, etc...
Post 22 Mar 2011, 01:11
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 22 Mar 2011, 01:17
Hmmm.....sorry, this is about your tree but I have some questions.

So which is faster....

@@:
...
call @b


or

@@:
...
jmp @b


or does it depend on what goes in between ? Question
Post 22 Mar 2011, 01:17
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 22 Mar 2011, 01:38
jmp @b is a loop

call @b is a recursion.

when programming something like that, don't care about what is faster, but what is better.
Post 22 Mar 2011, 01:38
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 22 Mar 2011, 02:28
edfed wrote:
when programming something like that, don't care about what is faster, but what is better.


point well taken Wink Very Happy Laughing
Post 22 Mar 2011, 02:28
View user's profile Send private message Reply with quote
iic2



Joined: 26 Jun 2008
Posts: 122
iic2 24 Mar 2011, 02:32
Only a foo could find this one ... but it's in C++.

http://www.bogotobogo.com/cplusplus/binarytree.html
....
....
output

Code:
size = 9
max depth = 4
min depth = 2
This tree is not balanced!
Min value = A
Max value = I
Min value of subtree B as a root is A
Max value of subtree B as a root is E
In Order Successor of B is C
In Order Successor of E is F
In Order Successor of I is None
In Order Predecessor of B is A
In Order Predecessor of E is D
In Order Predecessor of I is H
The lowest common ancestor of A and C is B
The lowest common ancestor of E and H is F
increasing sort order
A B C D E F G H I
post order
A C E D B H I G F
pre order
F B A D C E G I H
D is in the tree
M is not in the tree
printing paths ...
F B A
F B D C
F B D E
F G I H
5th maximum data is E
New array: A B C D E F G H I
12 subtree: 1
13 subtree: 1
14 subtree: 0
23 subtree: 0
32 subtree: 1
printing with Breadthfirst traversal
E B G A C F H D I


Press any key to continue . . .


    
Post 24 Mar 2011, 02:32
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 24 Mar 2011, 14:10
a little advance in the tree viewing.

now, i will make multiples parts:

data structure methods (folder, file, lba, sectors, header)
tree exploration (down1level, up1level, current path , show content, etc...)
graphics display (container, wire, name, properties...)

for the moment, it gives that:
Image

one very hard thing about tree management is when it is intended to be a file system, then, stocked on drives, with the problems by usage of the drives (bad sectors, fragmentation, variable sector size,...) but i think there is a possible layer for this:

the current code is a little more structurised, explaining why the view is more structurised.
Code:
        org 100h
        mov ax,0a000h
        mov es,ax
        mov ax,13h
        int 10h
        mov si,tree
        call caller
        ret

tree:   dw node,@f-$-2,\
        .F,.D,.1,.2,.3,.4,.5,.6,.1
        @@:
.1:     dw node,@f-$-2,\
        .7,.8,.9,.A,.B,.C,.D
        @@:
.2:     dw node,@f-$-2,\
        .E,.F,.1,.3
        @@:
.3:     dw node,@f-$-2,\
        .1,.A,.B,.C,.D,.1
        @@:
.4:     dw node,@f-$-2,\
        .7,.8,.9,.A,.B,.C,.D
        @@:
.5:     dw node,@f-$-2
        @@:
.6:     dw item
.7:     dw item
.8:     dw item
.9:     dw item
.A:     dw item
.B:     dw item
.C:     dw item
.D:     dw item
.E:     dw item
.F:     dw item
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
caller:
        push ax
        cmp si,0
        je @f
        mov ax,[si]
        cmp ax,0
        je @f
        call ax
@@:
        pop ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
node:
        push ax bx cx [x] [y]
        mov [c],1
        call spot
        inc [y]
        mov cx,[si+2]
        shr cx,1
        je .end
        mov bx,0
        add [x],lengh
@@:
        push si
        add [y],3
        mov [c],35
        call horizontal
        mov si,[si+4+bx]
        call caller
        pop si
        add bx,2
        loop @b
.end:
        pop ax [x] cx bx
        push [y]
        sub ax,[y]
        neg ax
        mov [yl],ax
        mov [c],33
        call vertical
        pop [y] ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
item:
        mov [c],4
        call spot
        inc [y]
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
firstpixel:
        mov ax,[x]
        mov bx,[y]
        shl bx,2
        add bx,[y]
        shl bx,6
        add bx,ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
putpixel:
        push ax bx cx
        call firstpixel
        mov cl,[c]
        mov [es:bx],cl
        pop cx bx ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
spot:
        push ax bx cx
        call firstpixel
        mov cl,[c]
;        mov [es:bx],cl
        mov [es:bx+1],cl
        mov [es:bx-1],cl
        mov [es:bx+1+320],cl
        mov [es:bx-1+320],cl
        mov [es:bx+1-320],cl
        mov [es:bx-1-320],cl
        mov [es:bx+320],cl
        mov [es:bx-320],cl
        pop cx bx ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
plot:
        push ax bx cx
        call firstpixel
        mov cl,[c]
        mov [es:bx],cl
        mov [es:bx+1],cl
        mov [es:bx-1],cl
        mov [es:bx+320],cl
        mov [es:bx-320],cl
        pop cx bx ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
vertical:
;yl
        push ax bx cx
        call firstpixel
        mov dl,[c]
        mov cx,[yl]
        cmp cx,0
        jl .end

@@:
        sub bx,320
        mov [es:bx],dl
        loop @b
.end:
        pop cx bx ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
horizontal:
;yl
        push ax bx cx
        call firstpixel
        mov dl,[c]
        mov cx,[xl]
        cmp cx,0
        jl .end

@@:
        sub bx,1
        mov [es:bx],dl
        loop @b
.end:
        pop cx bx ax
        ret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
x       dw 0
y       dw 0
c       db 0
yl      dw 1
xl      dw lengh
lengh   = 8    
    
Post 24 Mar 2011, 14:10
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 25 Mar 2011, 00:26
^What video mode are you using ?
Post 25 Mar 2011, 00:26
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20430
Location: In your JS exploiting you and your system
revolution 25 Mar 2011, 00:28
typedef wrote:
^What video mode are you using ?
When all else fails, read the source.
Code:
        mov ax,13h
        int 10h    
Post 25 Mar 2011, 00:28
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 26 Mar 2011, 21:49
^Did not see that hheheehe, and I did not have to read since you are here Very Happy Cool
Post 26 Mar 2011, 21:49
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
typedef 26 Mar 2011, 21:52
Oh, and Btw, I had to add
Code:
mov ah,0
int 16h
    


after
Code:
call caller
    
Post 26 Mar 2011, 21:52
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 26 Mar 2011, 23:27
maybe yes, wait a keystroke can let you see the screen if you are not under windows 98.

on my machine, it is not a problem since the console don't close when ret from mode 13h.

to close the console, should reswitch in mode 3, and ret.

no need of int 20h or else, by testing, it appears that just a ret is enough to quit a .com program.


now that i have retested the tree layer with succes, i plan on the file descriptor layer.

fdesc will be simple:

fdesc:
.type dd ?
.name dd ?
.size dd ?
.loc dd ?

each entry in a folder will be a pointer to a fdesc.

then,
folder: ;(is a file)
.size dd size of entry list
.entry dd ?
.entry dd ?
etc...

entry points to a fdesc inside the folder file

fdesc.name points to a asciiz string.


fdesc.loc will be the lba of the first sector of the sector list.

zones list will be a list like this:
.size dd ?
.lba dd ?
.sectors dd ?
.lba dd ?
.sectors dd ?
.lba dd ?
.sectors dd ?
.lba dd ?
.sectors dd ?

each zone (lba, sectors) will be a chunk of the file.
there will be the possibility of just one single zone, as there will be possible to have thousand of them, repartited in several sectors.

if there are more than one sector for the zones list, the last dword of the sector will contain the lba for the next.

file should be recorded as contiguous paged bytes, without extra formating. than the zones list.

from the application view, file will be a linear adress space, starting at 0.
from the specific uses of files (depends on type), the loading adress will be determined. for example, if fdesc.type = "com", file will be loaded by com function at 100h, induce the creation of the psp, and lanch it...

every file types will consist on either a id (just a 32 bits number) or a string (4 bytes string)...

for a file system, apparently, there is the need to cut the tree in severals layers, due to the polymorphism of the data structures... and then, the tree layer (the subject of this topic) is closer to the user than the others stated in this post.

fdesc, zonelist, bitmap, etc... should be transparent.
Post 26 Mar 2011, 23:27
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20430
Location: In your JS exploiting you and your system
revolution 26 Mar 2011, 23:37
edfed wrote:
no need of int 20h or else, by testing, it appears that just a ret is enough to quit a .com program.
I hope that the one byte you save is really important to you. Is the one byte saved enough of a compensation to risk having some incompatibility? Is it really worth it? Question
Post 26 Mar 2011, 23:37
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 26 Mar 2011, 23:42
it is not the question of one byte, but just because it is easier (and faster) to write ret than int 20h
Post 26 Mar 2011, 23:42
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.