Most useful/needed stuff which should be added

Most useful/needed stuff which should be added - Printable Version

+- Forum (https://www.boriel.com/forum)
+-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11)
+---- Forum: Wishlist (https://www.boriel.com/forum/forumdisplay.php?fid=14)
+---- Thread: Most useful/needed stuff which should be added (/showthread.php?tid=225)

Pages: 1 2

Most useful/needed stuff which should be added - na_th_an - 05-28-2010

This is somewhat a wish list to which I may contribute (coding my second suggestion).

1.- Types. I'm a nightmare, I keep repeating this, but types are most needed. They would make every coding chore way easier, specially when you have to pass parameters or create arrays of structured data. Game coding can be pretty messing without the ability to create proper data structures.

2.- A nice, fast, simple, hassle-less Putchar (x, y, attr, ascii) function which draws character ascii with attributes attr at coordinates (x, y).

3.- Less important, but may come handy, the ability use Attr as a modifier for Print which combines Ink, Bright, Paper, and Flash in a single command:

Code:
Print At 2, 2; Attr 71; "Bright white text on black"

4.- A fill routine which allows you to use patterns (for example, a 8x8 pattern defined by a character bitmap).

5.- Allow comments in broken lines, such as this:

Code:
Dim myLevel(2) as uByte => { _

   0, _     ' Number of exists

   10, _    ' Baddies life gauge

   7 _      ' Water level

}

Currently, the compiler refuses to compile such snippets. Comments aren't allowed after compiler directives, either, for example:

Code:
#include once "fsp2.1.bas"    ' The sprite library

Fails to compile due to the inline comment.

As I said, I will probably code a ROM-independent version of "2" and I hope someone makes it properly faster 'cause my ASM is dire. My main problem is that I don't know how to properly interface BASIC/ASM, so it may look cheesy. I'll take a glance at the examples, to see if I can work out how to do it so it's fast and not very ugly. Suggestions?

Re: Most useful/needed stuff which should be added - boriel - 05-28-2010

na_th_an Wrote:This is somewhat a wish list to which I may contribute (coding my second suggestion).

1.- Types. I'm a nightmare, I keep repeating this, but types are most needed. They would make every coding chore way easier, specially when you have to pass parameters or create arrays of structured data. Game coding can be pretty messing without the ability to create proper data structures.

By Types you mean used defined types, don't you? ZX BASIC have types (UByte, Byte, Float....), but user-defined types are not allowed (yet).

na_th_an Wrote:2.- A nice, fast, simple, hassle-less Putchar (x, y, attr, ascii) function which draws character ascii with attributes attr at coordinates (x, y).

Why don't you use PRINT AT x,y; a$?

na_th_an Wrote:3.- Less important, but may come handy, the ability use Attr as a modifier for Print which combines Ink, Bright, Paper, and Flash in a single command:

You can get this with a simple POKE 23695,t (ATTR_T <a class="postlink" href="http://www.wearmouth.demon.co.uk/sys/attr_t.htm">http://www.wearmouth.demon.co.uk/sys/attr_t.htm</a>). ZX BASIC could in the future optimize this, if numeric values are given in a sequence of attributes. E.g. PAPER 7; INK 1; BRIGHT 1; FLASH 0.... could be compiled in a single poke. There's also a funcion defined in attr.bas library, called SetATTR(x, y, ATTR) which you might find useful.

na_th_an Wrote:4.- A fill routine which allows you to use patterns (for example, a 8x8 pattern defined by a character bitmap).

A fill routine would be nice. If you can pass me a nice one I could add it to ZX BASIC library/ (.bas) directory

na_th_an Wrote:5.- Allow comments in broken lines, such as this:

Code:
Dim myLevel(2) as uByte => { _ 0, _ ' Number of exists 10, _ ' Baddies life gauge 7 _ ' Water level }

I definitely agree with this. I was thinking in using the C commenting scheme /* ... */, but FreeBasic uses /' ... '/ scheme instead. So better stick to it for the sake of compatibility. If everybody agrees, I could enable just this evening :!:

Re: Most useful/needed stuff which should be added - LCD - 05-28-2010

boriel Wrote:
na_th_an Wrote:2.- A nice, fast, simple, hassle-less Putchar (x, y, attr, ascii) function which draws character ascii with attributes attr at coordinates (x, y).
Why don't you use PRINT AT x,y; a$?

I guess, he wants to use 1 char tiles for games, so a Fast routine without any extras like OVER or other print modifier, and direct attribute access could be helpfull for faster screen draw in games. A nice include can do this job too. Just a simple poke of 9 values, and @Na_th_an: I want to add: Forget the char, use just a memory pointer: PutChar (x,y,adress) where adress is the memory adress of 9 byte (8 byte adress data and 1 Byte Attr Data). This allows to use more than 96 Characters for tiles!

boriel Wrote:
na_th_an Wrote:5.- Allow comments in broken lines, such as this:

Code:
Dim myLevel(2) as uByte => { _ 0, _ ' Number of exists 10, _ ' Baddies life gauge 7 _ ' Water level }
I definitely agree with this. I was thinking in using the C commenting scheme /* ... */, but FreeBasic uses /' ... '/ scheme instead. So better stick to it for the sake of compatibility. If everybody agrees, I could enable just this evening :!:

I think, he does not mean Multiline comments, but to allow comments after a line Break using underline-sign.

Re: Most useful/needed stuff which should be added - boriel - 05-28-2010

LCD Wrote:
boriel Wrote:
na_th_an Wrote:5.- Allow comments in broken lines, such as this:

Code:
Dim myLevel(2) as uByte => { _ 0, _ ' Number of exists 10, _ ' Baddies life gauge 7 _ ' Water level }
I definitely agree with this. I was thinking in using the C commenting scheme /* ... */, but FreeBasic uses /' ... '/ scheme instead. So better stick to it for the sake of compatibility. If everybody agrees, I could enable just this evening :!:
I think, he does not mean Multiline comments, but to allow comments after a line Break using underline-sign.

I was referring to Multiline comments, indeed. Freebasic uses /' .... '/ comments for that.

Re: Most useful/needed stuff which should be added - LCD - 05-28-2010

@Na_th_an:
Until a proper assembler version is available, I coded a sub which shows what I mean. It is maybe a little bit faster than PRINT, and puts a attribute too.
Found a problem:
a=peek(@linebuffer+y)<<5+16384+x displayed a wrong result, so I was forced to split it up.
scr=a<<5+x+16384 was not working correctly too. Usualy binary operation should have the highest priority, like multiplication, but only if I use braces, it calculates correctly.

Code:
sub putchar(x as Uinteger,y as Uinteger,adr as Uinteger)

    dim scr as Uinteger

    dim a as Uinteger

    a=peek(@linebuffer+y)

    scr=(a<<5)+x+16384

    poke ubyte scr,peek(adr)

    poke ubyte scr+256,peek(adr+1)

    poke ubyte scr+512,peek(adr+2)

    poke ubyte scr+768,peek(adr+3)

    poke ubyte scr+1024,peek(adr+4)

    poke ubyte scr+1280,peek(adr+5)

    poke ubyte scr+1536,peek(adr+6)

    poke ubyte scr+1792,peek(adr+7)

    poke ubyte 22528+x+(y<<5),peek (adr+8)

End sub

start:

dim x,y as ubyte

dim adr as Uinteger

adr=9

for y=0 to 23

    for x=0 to 31

        putchar(x,y,adr)

        adr=adr+9

    next x

next y

end

linebuffer:

asm

    defb 0,1,2,3,4,5,6,7,64,65,66,67,68,69,70,71,128,129,130,131,132,133,134,135

end asm

Another problem:
ASM
works
ASM ' Comment
does not work. (I know, this is because after ASM Command only ASM REM ( Wink

is accepted).

Re: Most useful/needed stuff which should be added - na_th_an - 05-31-2010

boriel Wrote:
na_th_an Wrote:This is somewhat a wish list to which I may contribute (coding my second suggestion).

1.- Types. I'm a nightmare, I keep repeating this, but types are most needed. They would make every coding chore way easier, specially when you have to pass parameters or create arrays of structured data. Game coding can be pretty messing without the ability to create proper data structures.
By Types you mean used defined types, don't you? ZX BASIC have types (UByte, Byte, Float....), but user-defined types are not allowed (yet).

Of course, I meant user defined types. I used just "types" to name them 'cause I'm so used to my old times when I was pretty active at QB/fB forums, and people used "types" to name user defined types (structures) 'cause you sed the keyword Type to define them:

Code:
Type myType

   x As Integer

   y As Integer

End Type

boriel Wrote:
na_th_an Wrote:2.- A nice, fast, simple, hassle-less Putchar (x, y, attr, ascii) function which draws character ascii with attributes attr at coordinates (x, y).
Why don't you use PRINT AT x,y; a$?

Because it's slow and means too much of a hassle when I just want to print a coloured char. I don't need everything "Print" has. I just want, as LCD suggested, to write 9 bytes to the screen RAM.

boriel Wrote:
na_th_an Wrote:3.- Less important, but may come handy, the ability use Attr as a modifier for Print which combines Ink, Bright, Paper, and Flash in a single command:
You can get this with a simple POKE 23695,t (ATTR_T <a class="postlink" href="http://www.wearmouth.demon.co.uk/sys/attr_t.htm">http://www.wearmouth.demon.co.uk/sys/attr_t.htm</a>). ZX BASIC could in the future optimize this, if numeric values are given in a sequence of attributes. E.g. PAPER 7; INK 1; BRIGHT 1; FLASH 0.... could be compiled in a single poke. There's also a funcion defined in attr.bas library, called SetATTR(x, y, ATTR) which you might find useful.

That's what I'm using (I reinvented the wheel creating my own SetATTR). I didn't know about the systems var thing. But still, it requires two commands to do such a simple task. The "SetATTR" solution also makes noticeable the separation between the printing and the colour setting.

boriel Wrote:
na_th_an Wrote:5.- Allow comments in broken lines, such as this:

Code:
Dim myLevel(2) as uByte => { _ 0, _ ' Number of exists 10, _ ' Baddies life gauge 7 _ ' Water level }
I definitely agree with this. I was thinking in using the C commenting scheme /* ... */, but FreeBasic uses /' ... '/ scheme instead. So better stick to it for the sake of compatibility. If everybody agrees, I could enable just this evening :!:

As LCD pointed out, It's not /'...'/, but the ability of use single comments in broken lines.

@LCD: thanks, that's what I meant. My plan is writing my own in assembly for extra speed, but my problem is that I don't know how to interface BASIC and ASM using ZXBasic, and using pokes to transfer BASIC variables into ASM variables kills the purpose of writing such a routine. Anyway, your routine is indeed faster than the Print At + Poke combination, so I'll be using it. Thanks :-)

I'm writing all this 'cause I'm currently writing my second game using this compiler, and such features (specially the user defined types and a fast putchar) will make the games writing chores to be quite a walk in the park Smile

Re: Most useful/needed stuff which should be added - boriel - 05-31-2010

FreeBasic Types (like your syntax) will be supported in the future. But there several things to keep in mind. E.g. How to implement them in asm, and how to change the compiler to allow them (many changes). So this won't be available in the short term.

na_th_an Wrote:
boriel Wrote:
na_th_an Wrote:3.- Less important, but may come handy, the ability use Attr as a modifier for Print which combines Ink, Bright, Paper, and Flash in a single command:
You can get this with a simple POKE 23695,t (ATTR_T <a class="postlink" href="http://www.wearmouth.demon.co.uk/sys/attr_t.htm">http://www.wearmouth.demon.co.uk/sys/attr_t.htm</a>). ZX BASIC could in the future optimize this, if numeric values are given in a sequence of attributes. E.g. PAPER 7; INK 1; BRIGHT 1; FLASH 0.... could be compiled in a single poke. There's also a function defined in attr.bas library, called SetATTR(x, y, ATTR) which you might find useful.

That's what I'm using (I reinvented the wheel creating my own SetATTR). I didn't know about the systems var thing. But still, it requires two commands to do such a simple task. The "SetATTR" solution also makes noticeable the separation between the printing and the colour setting.

Then I guess you my manage your self with SetATTR, don't you? So lets try a simple putchar:

Code:
Sub FASTCALL PutChar(x as Ubyte, y as Ubyte, c as uByte)

     Asm

     ; x comes in A register (FastCall)

     ; y and charCode

     pop hl ; Return Address

     pop de ; get Y in D register

     ex (sp), hl ;  => get c in H register and push return address back

     ; At this point you have X in a; Y in D; an C in H. Now proceed as you want.

     ; This routine is fascalled => you can simply RET at any point.

     End Asm

End SuB

Also, I would like you to time against print. PRINT is slow because it relays on strings which are a little slower.
You might want to call internal __PRINT_CHAR routine (at the internal PRINT routine). The difference in time shouldn't be too much.
If you wan't your routine to draw at a different screen location, use the global internal label (SCREEN_ADDRESS), which defaults to 16384 as expected.

na_th_an Wrote:5.- Allow comments in broken lines, such as this:

Code:
Dim myLevel(2) as uByte => { _ 0, _ ' Number of exists 10, _ ' Baddies life gauge 7 _ ' Water level }
As LCD pointed out, It's not /'...'/, but the ability of use single comments in broken lines.

Then I misunderstood you. Anyway, this feature will be available soon too (along with the block comment), since it's a standard one.

Quote:I'm writing all this 'cause I'm currently writing my second game using this compiler, and such features (specially the user defined types and a fast putchar) will make the games writing chores to be quite a walk in the park

Then try LCD's routine which uses a similar aproximation. You can also use my template SUB function to put the inline assembler there.

Re: Most useful/needed stuff which should be added - boriel - 05-31-2010

Ok, a simple PUTCHAR, with no ATTR which uses x, y position and c ASCII code. Click on the right <|> symbol to expand the view.

Code:
Sub FASTCALL PutChar(x as Ubyte, y as Ubyte, c as uByte)

     Asm

        ; x comes in A register (FastCall)

        ; y and charCode

        pop hl ; Return Address

        pop de ; get Y in D register

        ex (sp), hl ;  => get c in H register and push return address back

        ; At this point you have X in a; Y in D; an C in H. Now proceed as you want.

        ; This routine is fascalled => you can simply RET at any point.

        ld e, a ; D, E = Y, X

        ld b, h ; Saves C char code in B register

        ; This is a very standard routine. Also used in PRINT

        ld hl, (SCREEN_ADDR) ; This will make the routine SCREEN-Relocatable

        ld a, d

        ld b, a     ; Saves it for later 

        and 0F8h    ; Masks 3 lower bit ; zy

        ld d, a

        ld a, b     ; Recovers it

        and 07h     ; MOD 7 ; y1

        rrca

        rrca

        rrca

        or e

        ld e, a

        add hl, de  ; HL = Screen address + DE

        ;; At this point, we have the SCREEN ADDRESS

        ex de, hl ; DE => Screen address (saves it temporarily)

        ld a, b ; char ASCII code

        ld bc, (CHARS) ; CHARS Variable, pointing to our charset

        add a, a    ; A = a * 2 (since a < 80h) ; Thanks to Metalbrain at http://foro.speccy.org

        ld l, a

        ld h, 0     ; HL = a * 2 (accumulator)

        add hl, hl

        add hl, hl ; HL = a * 8

        add hl, bc ; HL = CHARS address

        ld b, 8

LOOP:

        ld a, (hl)

        ld (de), a

        inc hl

        inc d

        djnz LOOP

     End Asm

End SuB

Haven't tried this sub, but it should work. Also, if you are going to use 16384 screen address everytime, you can forget about the SCREEN ADDRESS and use the classic scheme (Already used by LCD, Britlion, ROM, etc...). And Finally, it's much faster to use the @address directly instead of ASCII code (as LCD suggested). So your routine could be really fast (I wonder what are you planning... Confused

hock: )

Re: Most useful/needed stuff which should be added - na_th_an - 06-01-2010

Nothing very fancy, but drawing a whole tiled map to screen is just too slow using PRINT Wink

Anyways, thanks for the pointers. I'll study how this fastcall scheme works now that I have that piece of code and will make my own (handling ATTRs as well). The bad news is that, unless it's included in the language default set of libraries, I won't be able to use it for the Bytemaniacos compo. :mrgreen:

Thanks again, now I'll wait patiently for the implementation of user defined types Big Grin

Btw, I remember having implemented type structures in our compilers project at college in a very simple fashion. You had to calculate where to read/write data by adding the "sizeof"s of all members before the one being accessed. Note that this can be always calculated in compile time, so, at the end, they are just normal variables in the compiled code. I mean, you had for example the variable coordinates which had two integer members, x and y. Once compiled, you in fact had two variables coordinates.x and coordinates.y of type integer in the generated code. That way, adding support to user defined types to our compiler didn't need us to change the expresion handling. I don't know if this makes sense, but that's what I recall from memory. We did this project 8 years ago.

I have assembly code to draw a tiled map to screen and it's somewhat fast. Maybe you are interested on it to be included as well. (As long as you all don't make fun of it again claiming it's automaticly generated code by a compiler Tongue

Re: Most useful/needed stuff which should be added - boriel - 06-01-2010

na_th_an Wrote:Nothing very fancy, but drawing a whole tiled map to screen is just too slow using PRINT
Anyways, thanks for the pointers. I'll study how this fastcall scheme works now that I have that piece of code and will make my own (handling ATTRs as well). The bad news is that, unless it's included in the language default set of libraries, I won't be able to use it for the Bytemaniacos compo. :mrgreen:

The problem is you (and I mean Britlion, LCD, na_th_an) are trying to put very specific things in a rather generic tools. The compiler is supposed to be reusable. I'm reluctant to put functions and libraries almost nobody is likely to use. If so, it's better to public them on the wiki so anybody interested could just copy & paste them. PutChar might be useful, by the way, but I need to get a PRINT_CHAR and others (there's a lot of work to do, I'm still revamping the Wiki...)

na_th_an Wrote:I have assembly code to draw a tiled map to screen and it's somewhat fast. Maybe you are interested on it to be included as well. (As long as you all don't make fun of it again claiming it's automaticly generated code by a compiler ).

Nice idea! I was thinking in using an indirection (IY + n), but IY is reserved form timing interrupts. There's a simple way to do struct typing anyway, which is even easier than yours: using name mangling. The compiler already uses that for local variables, functions and so on. So, for example:

Code:
Type Person

   Age as uInteger;

   Weight as Fixed;

End Type

Dim A as Person;

Will create the following:

Code:
_A

_A_Age:

    DB 00, 00 ; Age as Uinteger

_A_Weight:

    DB 00, 00, 00, 00 ; Age as Fixed

So A.Age becames _A_Age. Even better, recent versions of ZXBasm supports dot (.) in the name (to allow namespaces), so _A.Age and _A.Weight name schemes should also be valid. Finally, using Types with string fields will be somewhat complicated... but... I think it could be done.

Update: Please, put a "Types wanted" message in the wishlist sub-folder, since I'm using that forum as a task-list :wink:

Re: Most useful/needed stuff which should be added - britlion - 06-01-2010

Boriel Wrote:The problem is you (and I mean Britlion, LCD, na_th_an) are trying to put very specific things in a rather generic tools.

I really don't think there's anything wrong with that, Boriel. Right now, the only target IS a 48K zx spectrum. I know you want to expand, and when there are other targets, we just sweep up library functions that are specific to the speccy and label them as such. No muss and no fuss there, I think. In fact, if we put in some kind of #define, we could even have the compiler throw up an error if someone tried to use them when it's in a mode for a different computer.

I assume that other z80 based machines will be relatively easy to target; but screen handling stuff is pretty much required for anything to really work; so I don't think it's a bad idea to make libraries like fourspriter and putchar that assume a spectrum. Right now that assumption is 100% correct, anyway - and we want to use the compiler to make stuff for the speccy! When it isn't we tweak them to allow the compiler to detect that they are for a different computer, and move them into separate sections in the wiki.

Seems pretty simple to me!

Re: Most useful/needed stuff which should be added - LCD - 06-01-2010

I will add a code library to BorIDE, and it will be splited into compilation targets like Spectrum, SAM Coupé, C64 and so on. I think, this will be the ideal solution for all of us, if Bytemaniacos allow to use the functions from code library.

Re: Most useful/needed stuff which should be added - britlion - 06-01-2010

LCD Wrote:I will add a code library to BorIDE, and it will be splited into compilation targets like Spectrum, SAM Coupé, C64 and so on. I think, this will be the ideal solution for all of us, if Bytemaniacos allow to use the functions from code library.

I am SO glad there are native spanish speakers in this project :-) So much awesome software for the spectrum came out of Spain; though sadly, much of it was inaccessible to we British because of the language barrier.

Re: Most useful/needed stuff which should be added - LCD - 06-01-2010

britlion Wrote:
LCD Wrote:I will add a code library to BorIDE, and it will be splited into compilation targets like Spectrum, SAM Coupé, C64 and so on. I think, this will be the ideal solution for all of us, if Bytemaniacos allow to use the functions from code library.

I am SO glad there are native spanish speakers in this project :-) So much awesome software for the spectrum came out of Spain; though sadly, much of it was inaccessible to we British because of the language barrier.

I'm from Austria, but born in Poland so not a native spanish speaker (I know only very few spanish words), and there is a lot of great software from Poland too, but I agree that spanish coders are better. BorIDE will be english to solve the problem with language Barrier.

Re: Most useful/needed stuff which should be added - boriel - 06-02-2010

na_th_an Wrote:5.- Allow comments in broken lines, such as this:

Code:
Dim myLevel(2) as uByte => { _ 0, _ ' Number of exists 10, _ ' Baddies life gauge 7 _ ' Water level }

Okay, multiline comments /' ... '/ and comments in broken lines are now allowed. Will upload new version this evening.
Check FreeBasic Comments syntax page, as ZX BASIC now completely (I think) follows these commenting syntax.

This version also corrects # preprocessor directives within ASM blocks son

Code:
...

ASM

#include "external_library.asm"

#line 433

END ASM

Should now work again.

na_th_an Wrote:Currently, the compiler refuses to compile such snippets. Comments aren't allowed after compiler directives, either, for example:

Code:
#include once "fsp2.1.bas" ' The sprite library
Fails to compile due to the inline comment.

# preprocessor line directives are a complete different thing from BASIC source code and do not allow comments in the same line.