flat assembler
Message board for the users of flat assembler.

Index > Examples and Tutorials > Future Assembler: 22 Examples, Graphics, Library

Author
Thread Post new topic Reply to topic
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
FUTURE ASSEMBLER

Image
Image

Download: "Future Assembler" Programming Package

* EASIEST ASM LIBRARY EVER!
* 400+ USEFUL FUNCTIONS+MACROS. All hand-written. Never used anyone else's code
* 100S OF UNIQUE SYNTAXES, IDEAS, ALGORITHMS
* ULTIMATE SYSTEM STRUCTURE. See illustration below
* 100% PORTABLE GRAPHICS. All drawing - images, fonts, controls, etc - is directly to linear memory VGA (memory.copy a, b, n) for easy portability to BIOS, MenuetOS, DexOS, embedded systems, etc
* 22 EXAMPLES included
* FREE GRAPHICS, fonts and cursors


EASY INTERFACE TEMPLATE

New custom interface template with event-based structure like JavaScript. "Z77 makes ASM programming easier than VB!"
Code:
include 'z.inc'
use interface

TEXT t(256), title='My Application'

devices.f db \
 'Key: ''%c''=%n=%hh=%bb' R\
 'Mouse: X/Y=%nx%n' R\
 'Click: %n. %n. Wheel: %n', 0

; !on.create: when application begins...

! create
; ...
!end

; !on.draw: when screen is redrawn...

! draw
locate
draw.red.fade
print t, devices.f, [key], [key],\
 [key], [key], [mouse.x], [mouse.y],\
 [mouse.1], [mouse.2], [mouse.wheel]
draw.caption.s t, CENTER
draw.title.bar title
!end

; !on.mouse: when a mouse event occurs...

! mouse
; ...
title.bar.input
redraw
!end

; !on.key: when a key event occurs...

! key
; ...
redraw
!end

; !on.timer: every x ms (set.timer x)...

! timer
; ...
!end    


Image

Z77 LIBRARY

35 *.INC FILES: ARRAY, BMP, BOX, CLIP, COLOR, CONSOLE, COOL, CRYPT, CURSOR, DOCUMENT, DRAW, EXE, FILE, FONT, ICON, IMAGE, IMPORT, INPUT, INTERFACE, LANGUAGE, MACHINE, MEMORY, OS, PARSE, RANDOM, SOUND, SYNTAX, SYSTEM, TEXT, TGA, TILEMAP, TIME, USER, VGA, WINDOWS

Image

UPDATES: Easy event-based structure/template like JavaScript or VB. Alternate C-style names: void, integer, structure, string, strcpy, strcat, strchr, malloc, realloc (default types are UPPERCASE to avoid name conflicts). Updated DRAW.INC, LANGUAGE.INC, etc. Optimized "let", reordered by precedence, ==> for movzx. Improved comments, indents.

Image

"FASM programmers who use HL compilers 90% of the time (C++/C#/Java/etc) are only 10% FASM programmers"


Last edited by uart777 on 02 Feb 2013, 22:41; edited 2 times in total
Post 01 Feb 2013, 05:20
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16901
Location: In your JS exploiting you and your system
revolution
Ouch, my ears. The whole post is shouting at me. Can someone please turn down the volume. Razz
Post 01 Feb 2013, 05:40
View user's profile Send private message Visit poster's website Reply with quote
Spool



Joined: 08 Jan 2013
Posts: 154
Spool
[ Post removed by author. ]


Last edited by Spool on 17 Mar 2013, 10:08; edited 2 times in total
Post 01 Feb 2013, 06:26
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
Any questions? PM. No time. Only stop by once every 3-5 days. Thanks.
Post 01 Feb 2013, 07:43
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:49; edited 1 time in total
Post 01 Feb 2013, 15:02
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 820
Location: Jakarta, Indonesia
TmX
My only complaint at the moment is the UI doesn't look native.
Reminds me of Linoleum
Post 01 Feb 2013, 17:15
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
First, this post is mainly intended for LL graphics programmers, OS developers and embedded systems programmers who must define their own graphics+interfaces from scratch.

HaHa: See OS.INC. Not yet (first release), but most functions are X86 portable and standalone (no globals/relocations) to inject in memory or executables in any OS.

TmX: UI is 100% customizable, portable and ensures a consistent appearance on all systems. It's not supposed to have a typical Windoze design. This post is for graphics+GUI programmers who want absolute control of their interface/s on different systems without OS restrictions.

Sorry, no time. Questions? PM.
Post 01 Feb 2013, 19:05
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8507
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
i think this is very cool, uart777,
but why the cpu gone higher after launching the application?

the mouse gone sluggish, is this expected behaviour?
Post 01 Feb 2013, 19:22
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
sleep: Just a quick beta release. Drawing is optimized, problem is how often it occurs. You can increase speed by reducing the number of "redraw"s or edit it to only update the section of screen that changes. Just little previews/examples I threw together overnight to give programmers something to play with while I work on my real programs. I didn't post this to have a discussion about it. I'm working on a visual tutorial program that explains everything, and I don't have to time to stop and answer individual questions. Thanks for understanding.

PS: What if the F in FASM meant something else? "Future Assembler"? Start a discussion in Heap: Flat or Future? At one time, humans thought the world was flat.
Post 02 Feb 2013, 06:37
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
thumbs UP again for me, the output looks very good.
AV deleted some EXES (Suspicious.Cloud ?), some other dont work as expected.
Quote:
TEXT t(256), title='My Application'
devices.f db \
'Key: ''%c''=%n=%hh=%bb' R\
'Mouse: X/Y=%nx%n' R\
'Click: %n. %n. Wheel: %n', 0

this is good, imho. look please the IUP thread. it may give you some hints:
http://board.flatassembler.net/topic.php?p=144377#144377

Now some general guidelines pros/contras about ML programming,
and how to get a good set of macros in a ML. consider symbols and how they
are being developed:
Quote:

1) the symbol for itself
using LET when i can do in 3 digits in most cases MOV or
why "LET" instead of "SET" or "DIM". information should not be overloaded!
then an essential physical matter: the coder should type physically less.
possible compounded use of the symbol. pseudocode example

let [a]=2
let [a]=eax
let [a]=get[c]
let [get [c]]=3
let a = eax
let a[3] = eax
let a[c.field] = eax
etc..

2) the symbol against the rest
example problem: why using [ in let [x] where i may think to use [ to access only array.
or why not using SET that couples GET and may allow set[x = get[y]]
where [ nests itself

it is a mere permutational matter a syntax allowing labels
starting with letters [A-z], while prohibiting them when starting with digits [0-9].
this and all similiar choices are not trivial. for the case above, it impacts directly
on the hashing algo over labels. the bad choiche may drive to collisions or memory wasting.
and because it is all actually built on assembly, all will become harder to be parses,to be executed.

3) macro must not break the standard behavour of the engine
if i use [ for something like
let[x] = y it must not break/conflict with mov [eax],0
it must allow the user (note: assembly user!) to write it barely
mov eax,y
mov [x],eax

4) macro must not break inside macros
the solution to this conflict gives the ml flexibility.
the solution is writing guidelines in a BNF chart http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form
also, the fact that it is a macro language includes still more restrictions
than it provides, because you have already rules from the engine running
underneath (i.e. fasm)

5) portability and/or running mode (emulated/native)

if you dont like that BNF formal description, you may think to list all possible
cases as done on point 1) above, then develop the symbol following the guideline of all other steps.
warning!! it may require days, weeks or months, but that is not optional. there is a basic reason to consider all those steps. they are valid for every new language. i have only assembled them in a scheme. it is up to you to discover why.

Cheers,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 02 Feb 2013, 11:23
View user's profile Send private message Visit poster's website Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
New logo design. Flat+Z77=Future
Image
Post 02 Feb 2013, 22:27
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
hopcode: Hi, good ideas. Your AV might have deleted EXE.BIN which is my partial PE .EXE template. "WRITE MACHINE CODE" won't work without it.

Well, I've been studying HL compilers and optimizations for years in my freetime (since about 98'), even made little toy compilers in C (DOS 16BIT), and there is so much that could be said on this subject.

For let/get, I think there should just be one symbol for all HL operations like '.': . eax=edi+(ecx<<4), c=rgb(x,y,z), etc. Then get/set would be reserved to access class/object members.

Unsigned is still undefined by Z77. Just write pure ASM for unsigned. I must be extremely careful about every little change I make and how it will effect my entire library. I think the best way to handle this situation is to declare variables with 'u' prefix for unsigned: byte/integer=signed, ubyte/uinteger=unsigned.

We must be able to get individual tokens as in a real expression parser. Someday, I will upload a Infix>RPN>UASM>ASM converter.

Code:
EXPRESSIONS

1. Parenthesis: ()
2. Unary: -a, ~a, &a, *a
3. Array, Structure: a[i], s.m or s->m
4. Function: f(a, b, c)
5. Multiply, divide: a*b, a/b, a%b
6. Add, subtract: a+b, a-b
7. Shift: a<<b, a>>b
8. AND, OR: a&b, a|b

DECLARATIONS

* Pointer: IMAGE *image     ; create address size variable
* Array: IMAGE images<4>    ; create fixed array
* HL array: IMAGE images[4] ; create dynamic ARRAY.INC
* Or: IMAGE images[?]       ; unknown #, index size is known    


If anyone is interested in writing compilers, please check out the famous "red dragon compiler book": http://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886

Ultimately, my "Dream Language" would be the simplest pure English syntax. Something like this:

Code:
CREATE, DESTROY

; "create/destroy" any object/class or create file or destroy pointer.

create object, ...
create image, pixels, w, h, bpp
create button, text
create caption, text, box, color
create menu, texts

create file
destroy pointer

LOAD, MOVE, DRAW, UPDATE, ETC

; "load/move/draw/update" any loadable/moveable/drawable/updatable object/class.
 
load object, ...
load image, file
load button, file
load tilemap, file

move object, ...
move image, x, y
move button, x, y
move tilemap, x, y

draw object, ...
draw pixel, x, y, color
draw box, b, color
draw image
draw image, x, y
draw button
draw window
draw etc

update object, ...
update button
update window
update dialog    
Post 04 Feb 2013, 14:12
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
uart777 wrote:
...Ultimately, my "Dream Language" would be the simplest pure English syntax
your "Dream Language"... well the following are my personal possible tipps how to lay it out.
i cooked up "transgressive" the flow structure in GRADIENTS.ASM. imo you find there some
cool pros and features
1) a place: WHERE
Code:
! main
load.defaults
!end    

2) an action,in a verb: WHAT
Code:
! draw
font.height
let ecx=[screen.w], ecx>>1,\
 edx=[screen.h], edx-eax, edx>>1
!end    
3) an object that does something: WHO
Code:
! mouse
title.bar.input
redraw
!end    
you need WHY,WHEN too, and exceptionally HOW.
then some contras now:

a) it is bound to windoze -> OS dependent
b) macros apply to/are meant for both syntax and graphics -> difficoult to learn in one shot
ok, my tipps:
Quote:
1) use a portable graph library, example SDL -> this simplifies/makes stable your work
on what is graphics-concerned. app links against it automatically (dll or lib).
this solves ~40% of your work, granted.

2) improve the structure as in the file GRADIENTS.ASM.
first of all events/methods/object, because as far as i can suppose, graphics has to do
with AI and polymorphism, normally difficoult to be implemented nowadays.
the bare macro syntax then -> where macros expand to code for that platform.
the bare macro syntax should be realized only after having completed an abstract external superior view of the whole
and we call this design. it is something that avoids time-wasting and gives kraft and flexibility to your work.
well, that's not all of course but so schemed i HTH.
but one should have always the chance to fly to Dagobah and complete the Jedi course,
in order to acquire a clear design of the whole, isnt it ? Wink

Cheers,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 05 Feb 2013, 06:12
View user's profile Send private message Visit poster's website Reply with quote
Lucifere



Joined: 30 Apr 2013
Posts: 16
Location: Korea. Republic of
Lucifere
uart777 wrote:

What if the F in FASM meant something else? "Future Assembler"? Start a discussion in Heap: Flat or Future? At one time, humans thought the world was flat.


In music, flat is so important. but future is...
...i'll omit more detail explain than that.

_________________
In Omnibus requiem quaesivi, et nusquam inveni in angulo cum libro.
Post 02 May 2013, 10:22
View user's profile Send private message Yahoo Messenger MSN Messenger Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2914
Location: 0x77760000
typedef
But why did you attack John Found ?
I like his Fresh-lib. Sad

But seriously, why not make an IDE with more focus on code completion and function parameter checks.

I don't see this to be any helpful in any case.
Post 02 May 2013, 21:50
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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-2019, Tomasz Grysztar.

Powered by rwasa.