Forum

Welcome, Guest

You have to register before you can post on our site.

Search Forums

(Advanced Search)

Forum Statistics

» Members: 385
» Latest member: DayanaAmoni
» Forum threads: 1,028
» Forum posts: 6,212

Full Statistics

Online Users

There are currently 610 online users.
» 0 Member(s) | 609 Guest(s)
Bing

Latest Threads

Includes in ASM
Forum: How-To & Tutorials
Last Post: bracckets
04-04-2024, 12:17 AM
» Replies: 2
» Views: 549

Intermittent errors
Forum: Help & Support
Last Post: zarsoft
03-12-2024, 12:39 PM
» Replies: 0
» Views: 310

Store array information i...
Forum: Help & Support
Last Post: rbiondi
03-10-2024, 09:42 PM
» Replies: 0
» Views: 398

ScrollLeft function scrol...
Forum: Bug Reports
Last Post: rbiondi
03-07-2024, 03:57 PM
» Replies: 2
» Views: 798

string.bas errors when co...
Forum: Bug Reports
Last Post: rbiondi
03-01-2024, 10:10 AM
» Replies: 2
» Views: 712

Using Beepola with ZX BAS...
Forum: How-To & Tutorials
Last Post: edtoo
02-29-2024, 09:47 AM
» Replies: 15
» Views: 32,664

Johnny Bravo
Forum: Gallery
Last Post: zarsoft
02-11-2024, 11:20 PM
» Replies: 0
» Views: 469

Compiling +D G+DOS progra...
Forum: ZX Basic Compiler
Last Post: boriel
01-22-2024, 08:32 AM
» Replies: 4
» Views: 8,649

VAL = ? (solved)
Forum: Bug Reports
Last Post: zarsoft
01-03-2024, 11:44 PM
» Replies: 8
» Views: 3,188

Wrong math (solved)
Forum: Bug Reports
Last Post: zarsoft
01-03-2024, 11:38 PM
» Replies: 4
» Views: 1,745

Weirdness MK II

Posted by: britlion - 01-28-2010, 07:39 AM - Forum: Bug Reports - Replies (1)

I seem to be just posting stuff that baffles me. I might work it out, but here we go:

The code is actually sent "AA" as a string right here. It comes back as "nn" apparently. Which is odd.

Code:
CLS

FOR i=0 to 1 step 2: REM Just grab the first two temporarily. Change this for the whole input later!

   LET leftChar = CODE characters$ (i to i)

   LET rightChar = CODE characters$ (i+1 to i+1)

   print leftChar, rightChar

   print CHR$(leftChar), CHR$(rightChar)

   print CHR$(110), CHR$(110)

next i

The really weird thing is the result:

Code:
110     110

q       n

n       n

And a line of corrupted screen a little further down.

That screen corruption has me worried. But the results table implies that CHR$(110) comes out sometimes as "q" and sometimes as "n". I think.

Oh, incidentally, string slicing using string(i) doesn't work again. Have to use string(i TO i); otherwise it insists it's not an array and sulks.

However, string(3) [As a number, not a variable] seems to work just fine.

toUpper and toLower functions

Posted by: britlion - 01-27-2010, 06:09 AM - Forum: How-To & Tutorials - No Replies

Hey all. I'm not anything like a good Z80 programmer, but I'm learning snippets. I wanted a fast way to flip between lower and upper case characters. This can of course be done by +/- 32 to the ascii code. This is of course, the same as setting or resetting bit 5 of the character, which assembly is better at (you could also perhaps use the bAND function listed in How-To). Anyway, I found these two to work. I wasn't sure if resetting the carry flag was necessary or not in all cases, so cleared it to be on the safe side.

Edit:
It is also with wry amusement that I note that Boriel has LCase and UCase functions in his library as well that I hadn't noticed. #include <lcase.bas> (and/or ucase) would let you use them. They lower/upper a whole string. His functions also use OR and AND instead of set and res. Irritatingly, though I was sure that bit set and bit reset instructions ought to be faster...they aren't. According to the documentation I have, OR and AND take 7 T states when run on the accumulator. SET and RES take 8. Even though that's pretty baffling, since OR can be used as a set of many bits, and AND can be used as a reset of many bits in one go - the documentation says they are faster. Boriel's code almost always is going to be better than mine - unless you happen to have a single character as an ascii code instead of a string. I'll leave these here then as potentially useful for dealing with things like Y/N? responses for a single letter.

Code:
REM Change a single character code to lower case

REM Anything except an UPPERCASE letter is returned unchanged.

FUNCTION FASTCALL toLower (letter as uByte) as uByte

    asm

    ;AND A ; clear carry flag (unnecessary)

    CP 65

    RET C

    CP 90

    RET NC

    ; set 5,a (slow)

        OR 32 ; faster

    end asm

END FUNCTION

Code:
REM Change a single character code to Upper Case

REM Anything except a lowercase letter is returned unchanged.

FUNCTION FASTCALL toUpper (letter as uByte) as uByte

    asm

       ; AND A ; Clear carry flag (unnecessary)

    CP 97

    RET C

    CP 122

    RET NC

        ; res 5,a (slow)

        AND 224 ; faster

    end asm    

END FUNCTION

Logical operators bugged? (*solved*)

Posted by: britlion - 01-27-2010, 04:36 AM - Forum: Bug Reports - Replies (3)

I can't see why this doesn't work:

Code:
dim a as uByte

FUNCTION get (capitalise as byte) as uByte

    DIM lastK AS uByte AT 23560: REM LAST_K System VAR

    lastK=0

    DO LOOP until lastK <> 0 : REM Wait for a keypress

    IF capitalise >0 AND lastK >= 97 AND lastK <= 122 THEN:

            LET lastK = lastK - 32

    END IF

    IF capitalise <0 AND lastK >=65 AND lastK <= 90 THEN:

        LET lastK=lastK + 32          

    END IF     

    RETURN lastK

END FUNCTION

let a=get(1)

print a,chr$(a)

Without fail this doesn't capitalise the key I pressed. get(-1) should only produce lower case (a-z), get(0) should produce what's pressed (a-Z) and get(1) should produce UPPER case (A-Z). It doesn't seem to be changing it. I've proved the IF works - I think the AND is failing.

I tried

Code:
IF ((capitalise >0 AND lastK >= 97) AND lastK <= 122) THEN:

in order to see if' it's something in the multiple AND options. Any one of the three conditions, without the AND seems to come out true.

Are logical functions misbehaving?

BOLD and ITALIC - Taken out? (*solved*)

Posted by: britlion - 01-26-2010, 09:51 PM - Forum: Bug Reports - Replies (1)

Are BOLD and ITALIC no longer supported?

Code:
PRINT BOLD 1; "TEST"

Doesn't seem to compile as a program:

File "zxb.py", line 243, in <module>
File "zxb.py", line 196, in main
File "ply\yacc.pyc", line 263, in parse
File "ply\yacc.pyc", line 710, in parseopt
File "zxbparser.pyc", line 2921, in p_print_list_elem
File "zxbparser.pyc", line 1558, in make_sentence
File "ast.pyc", line 64, in makenode
ast.NotAnAstError: Object 'BOLD' is not an Ast instance
Build Failed!

Same problem with ITALIC. Are they gone?

@array broken? (*solved*)

Posted by: britlion - 01-23-2010, 05:12 AM - Forum: Bug Reports - Replies (3)

I think something broke in the Array code. (Perhaps in asm function _ARRAY ?)

Code:
DIM udg(7) AS uByte => {24,88,126,26,120,72,206,2}

POKE UINTEGER 23675,@udg(0): REM udg(0) is the 1st array element 

PRINT @udg(0)

STOP

This code crashes the spectrum - without any reference to @udg, it runs perfectly; so it seems to be the @udg calculation that is breaking.

ZXB 1.2.4.

128K SPECTRUM COMPATIBILITY...

Posted by: kgmcneil - 10-29-2009, 06:52 AM - Forum: Wishlist - Replies (26)

Forgive me if Iv missed something here, but is your ZX compiler 48k compatible only?....

I would very much like to use your wonderful tool to compile some programs that make use of the PLAY command from 128k Basic...

I don't see any referrence to the PLAY command in any of the online documentation... I was wondering whether this might be a feature that you'd be interestd in adding in the future?...

Since this IS a wishlist, might I also suggest adding the ability to use the PLAY command in the background, using some sort of interrupt driven sound routine?...

Will this project later include 128k BASIC instructions (eg: load!, cat!, for silicon disk, PLAY for sound, etc), or was it always meant to be 48k BASIC only that is represented?...

Version 1.2.4 released!

Posted by: boriel - 10-12-2009, 08:47 PM - Forum: ZX Basic Compiler - Replies (1)

Ok, version 1.2.3 has been released. You can download it at <a class="postlink" href="http://www.boriel.com/files/zxb">http://www.boriel.com/files/zxb</a> (as always).

Changes since v.1.2.3
===================================

! Detected and fixed potential memory leak when using @operator
LOAD/SAVE/VERIFY features added!

Download here: <a class="postlink" href="http://www.boriel.com/files/zxb">http://www.boriel.com/files/zxb</a>

Notes:

SAVE "xxx" CODE ... and SAVE "xxx" SCREEN$ work as in the original Sinclair BASIC. The same applies for LOAD & VERIFY.
For LOAD & VERIFY, when a R-Tape Loading error occurs, the program doesn't stop. You have to check PEEK 23610 (ERR_NR) for value 26. If that value exists, then the LOAD/VERIFY operation failed.
At this moment, LOAD/SAVE/VERIFY can be interrupted by the user by pressing BREAK/Space, which exits the program and returns to the ROM BASIC. This can be changed in the future to behave like the previous point (signaling the break in ERR_NR and returning).
SAVE "xxx" DATA <varname>( ) behaves like the original Sinclair BASIC, but here you can save/load/verify not only arrays, but single variables. Parenthesis can be ommited (in Sinclair BASIC they were mondatory). You can also use LOAD/VERIFY with this.
SAVE "xxx" DATA with no varname saves ALL the entire user variable variable área plus the HEAP memory zone. That is, it saves all the program state. You can also use LOAD/VERIFY with this.
When using LOAD "xxx" DATA... you won't see the message neither "Number array:" nor "Char array:", but "Bytes: " instead. This is because ZX BASIC use always bytes (LOAD/SAVE ... CODE) for storing user variables (ZX BASIC is machine code, so BASIC variables are nonsense).

SAVE & LOAD

Posted by: Darth_Cotsos - 09-10-2009, 09:57 AM - Forum: Wishlist - Replies (3)

	Hi!!!! You done a great job making this compiler !!!! You have greetings and thanks from the Greeks Spectrum users Can I ask you if it possible to save and load data from the ZX Basic??? Thanks again!!!!

Version 1.2.3 released!

Posted by: boriel - 08-19-2009, 08:26 PM - Forum: ZX Basic Compiler - No Replies

! CHR$ and STR$ might use the HEAP without initializing
it first, leading to memory corruption. Fixed. Thanks to britilion.
* HEAP size can now be set with a command line parameter.
! DIM with array base was buggy. Fixed.
! INK 8 and PAPER 8 were being ignored. Now they work.

Faster Draw

Posted by: britlion - 08-17-2009, 05:39 PM - Forum: Wishlist - Replies (5)

Code:
DIM a as uinteger   

    FOR a=0 to 175

    PLOT 0,0 

    DRAW 255,a

    NEXT a

My timings on this code suggest it's possible to make the DRAW command quite a lot faster. It takes about 9.2 seconds after ZX Basic compiles it and run on a 48K spectrum.

Running exactly the same code on a spectrum 128 with Beta Basic 4.0 added (find at: http://www.worldofspectrum.org/infoseeki...id=0007956 ) completes in 5.9 seconds. (56% faster execution) Remember, this is running in an extended variant of basic. In the beta basic newsletter 12 he describes a method of queuing up plot and draw commands into a string variable (as if it was an array), and using a very fast draw method to draw the whole array. I haven't tried that yet, but I get the impression it will be far faster (for anything we'd need to draw on screen more than once, anyway - creating the 'array' is still quite slow)

I think Andrew wright's draw code must be pretty staggeringly fast to make that much difference in an interpreted language, though beta basic is generally faster. He has stated in material that his draw code is 2.5 to 3 times as fast as the Sinclair ROM code.

Boriel, your circle routine is incredibly fast (beta basic has, I think, something very similar) - and you've said that the draw routine is faster than basic. I'm not sure I can see the difference in speed with yours over sinclair. Here's a source you might want to look at for a much faster algorithm.

Just something you might want to look at some time!

Pages (95): « Previous 1 … 87 88 89 90 91 … 95 Next »

Login
Username:
Password:	Lost Password?
	Remember me