i don't know if this is a bug, or if i'm defining variable kind wrongly ('j' is not stopping at '0') - thanks in advance!

Hi Boriel. I just adapted a ASM routine for key-redefining from WOS Forum to ZXBC for my next game, and noticed following:
EQU is not supported?
DEFM supports only Strings, but not mixed bytes+strings in one line like: DEFM 14,10,5,"Down",255
I adapted the lines by lacerating them to DEFB,DEFM and DEFB again, but maybe it would be a good idea to support bytes and Strings with DEFM, like other assemblers do.

any chance of OO programming features?

the compiler doesnt like it when #include statements are not the first thing in a line
so this will work:
#include
but this will not:
<space> #include
the error message complains about a period or full stop being in the wrong place which is not the right issue.

This may turn someone off the language if they cant solve the problem

not unregretting that awesome Fourspriter, what about that technique used on MojonTwin's Trabajo Basura? <!-- m --><a class="postlink" href="http://www.mojontwins.com/juegos_mojonos/trabajo-basura-dire-job/">http://www.mojontwins.com/juegos_mojono ... -dire-job/</a><!-- m -->
it seems to be very similar to most of the sprites used on zx-spectrum games - how would we use this kind of sprites from a zxbasic-compiler library?

finally i coded some snipets - two of them are about drawing bezier and cubic curves - btw, if someone can help them being faster, or part of the library, be welcome!

beziercurve.bas

To unearth an aside I hadn't ever responded to in an old topic...I got playing.

boriel Wrote:There's already such a function in attr.asm library, but this one uses a different approach:

Code:

__ATTR_ADDR: ; calc start address in DE (as (32 * d) + e) ; Contributed by Santiago Romero at http://www.speccy.org ld h, 0 ld l, d add hl, hl ; HL = HL*2 add hl, hl ; HL = HL*4 add hl, hl ; HL = HL*8 add hl, hl ; HL = HL*16 add hl, hl ; HL = HL*32 ;; Note: *THIS IS WRONG* ; the addition of 6144 could be optimized to ; ld a, 18h ; add a, h ; ld h, a ; this saves 3 T-States (The above calculation misses E register) ;; adds 6144 for attribute start ld d, 18h ; DE = 6144 + E. Note: 6144 is the screen size (before attr zone) add hl, de ld de, (SCREEN_ADDR) ; Adds the screen address add hl, de ; Return current screen address in HL ret

Please check which one is faster (I'm not sure): This function takes 102 T-States (RET Included), your takes 67 (RET Included). With the commented optimization it will take 99 T-States.

The problem here is __ATTR_ADDR is taking into account a configurable SCREEN_ADDRESS variable (previously discussed here). So if you want your program to work in a variable screen address, you should work considering 0 offset an adding (SCREEN_ADDRESS) at the end, so should change it this way:

Code:

FUNCTION FASTCALL attrAddress(x as uByte, y as uByte) as Uinteger : REM Will issue a Warning asm ; This function returns the address into HL of the screen address ; x,y in character grid notation. ; Original code was extracted by BloodBaz - Adapted for ZX BASiC by Britlion from Na_TH_AN's fourspriter ld e, a ; X comes in A register (fastcall). Saves X in E register pop hl ; ret Address pop af ; Get Y in A [F not used] ld d, a ; Saves Y in D register, So DE register stores YX coords. push hl ; Put RET address back in the Stack ;; 39 T-States up to here, but we don't count this to be fair with the above ;; So 0 T-States. Start counting them from here ;; At this point, A already has Y coord rrca rrca rrca ; Multiply by 32 ld l,a ; Pass to L and 3 ; Mask with 00000011 ;; 23 T-States up to here ;; The following must be changed, start form 0 and add (SCREEN_ADDRESS) later ; add a,88 ; 88 * 256 = 22528 - start of attributes. add a,24 ; 24 * 256 = 6144 - start of attributes from address 0x0000h ld h,a ; Put it in the High Byte ld a,l ; We get y value *32 and 224 ; Mask with 11100000 ;; The following can be optimized ??? ; ld l,a ; Put it in L ; ld a,d ; xpos ; add a,l ; Add it to the Low byte add a, e ; add xpos ld l,a ; Put it back in L, and we're done. HL=Address. ;; 53 T-States up to here ld de, (SCREEN_ADDRESS) add hl, de ;; Total T-States = 84 T-States ;; (implicit RET) + 10 T-States = 94 T-States end asm END FUNCTION

So this function, adapted for a configurable screen address is 8 T-states faster than the original in ZX Basic (only 5 if the commented optimization is done) :?:

i think would be great if, regularly (like once or twice per year), we can have some kind of contest for divulgate (and specific about) Boriel's zxbasic-compiler, and to have more people testing and contributing to this awesome project - what do you all think, and what can help making this contest popular in the zx-spectrum retro-development scene?

interesting would be a kind of command for playing samples, just like this type-in example found at wos repository:
http://www.worldofspectrum.org/infoseeki...id=0024188
ftp://ftp.worldofspectrum.org/pub/sincla...ampler.txt

since i knew from some magazine snippets from 80's, it seems to be not that hard to be implemented
the idea would be, somehow, we could convert a kind of .wav (or .flac, .aiff, .ogg, .mp3, .raw, etc., like from SoX or Audacity) into a kind of 8khz/1bit sound sample raw binary to be added as defb values, and play it from some zxbasiccompiler library

what do you all think? thanks!