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!

This version is (IMHO) tested enough, and so, released as Stable.
You can download it here

NOTE: This is revision 1.2.8 s758
If you already have it, you don't need to download it again.

Changelog since 1.2.7:
* Code rearranged and reestructured for future refactorizations.
*! Complete rewritten backend (or almost!) to fix a bug in code
:generation which was being suboptimal. Now generated code is
:much faster and take less memory than before!
*+ Added support for Bitwise syntax (|, &, ~)
*! Fixed some bugs in ASM
*! Fixed some bugs in the peephole optimizer (-O3)
*! Fixed a bug with line continuation comments /' ...
*! Fixed bugs in ASM parser regarding to comments
*+ Added ATTRADDR function in <attrib.bas>
*! Many more bugs fixed related to STRING memory leak
*! Fixed a bug related to parameters.
* Some optimizations for code size and speed for FLOAT types
* Optimization for STRING parameters
* Optimization for 32 bit values
*! Fixed a bug for Uinteger/Integer arrays assignation
*! Fixed 2 bugs in CAST operation and type conversion
*! Fixed a bug in OVER attribute during PRINT
* Added PONG game example
*! Fixed a bug in POKE
*! PRINT optimized and slighty faster. Now fully compatible with
:SINCLAIR BASIC (no Out of Screen error on program exit)
*! CSRLN and POS optimized to this new PRINT SCHEME!
... and much much more

i forgot how to read simultaneous keys pressed on zx-spectrum - is it from port 254? and only port 254? and how?
and how can we read them in a zxbasic-compiler snippet?
thanks!

i tried this code

i were trying to make some experiences with display memory byte sequence references from coco2 (pmode 4) and msx1 (screen 2)
first i tried these:

coco2-pmode4 with sub/endsub (around 49 seconds):