| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 169 online users.
» 0 Member(s) | 167 Guest(s)
Bing, Google
|
| Latest Threads |
Strange Happenings
Forum: Bug Reports
Last Post: zedex82
1 hour ago
» Replies: 2
» Views: 119
|
.tap file code not execut...
Forum: Help & Support
Last Post: Zoran
04-28-2025, 10:59 AM
» Replies: 4
» Views: 516
|
Exit from more than one l...
Forum: Wishlist
Last Post: Duefectu
04-23-2025, 10:06 PM
» Replies: 3
» Views: 398
|
put small ASM programs li...
Forum: How-To & Tutorials
Last Post: Zoran
04-18-2025, 02:02 PM
» Replies: 6
» Views: 1,743
|
Creating +3 Menus - Loadi...
Forum: Help & Support
Last Post: merlinkv
04-16-2025, 02:08 PM
» Replies: 6
» Views: 677
|
Randomize not very random...
Forum: Help & Support
Last Post: Zoran
04-08-2025, 10:40 AM
» Replies: 4
» Views: 1,034
|
Scope rules
Forum: Bug Reports
Last Post: Zoran
04-04-2025, 09:46 AM
» Replies: 2
» Views: 423
|
Using constants not allow...
Forum: Bug Reports
Last Post: baltasarq
03-19-2025, 10:00 PM
» Replies: 8
» Views: 1,198
|
404 page not found
Forum: Documentation
Last Post: boriel
03-08-2025, 07:16 PM
» Replies: 5
» Views: 2,968
|
Spectrum keywords codes
Forum: Bug Reports
Last Post: boriel
03-08-2025, 11:00 AM
» Replies: 1
» Views: 482
|
|
|
| @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 <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb">http://www.boriel.com/files/zxb</a><!-- m --> (as always).
Changes since v.1.2.3
=================================== - ! Detected and fixed potential memory leak when using @operator
- LOAD/SAVE/VERIFY features added!
Download here: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb">http://www.boriel.com/files/zxb</a><!-- m -->
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).
|
|
|
|
| Version 1.2.3 released! |
|
Posted by: boriel - 08-19-2009, 08:26 PM - Forum: ZX Basic Compiler
- No Replies
|
|
Ok, version 1.2.3 has been released. You can download it at <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb">http://www.boriel.com/files/zxb</a><!-- m --> (as always).
Changes since v.1.2.0
=================================== - ! 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!
|
|
|
|
| For loops with type byte (*solved*) |
|
Posted by: britlion - 08-17-2009, 04:58 PM - Forum: Bug Reports
- Replies (2)
|
|
Code: dim c,b as byte
FOR c=1 TO 175
FOR b=1 TO 250
PLOT b,c
NEXT b
NEXT c
Doesn't seem to work as expected. If I make it a uinteger, it works perfectly. At first I thought it was a problem with 0=256 in a byte the original was
Code: FOR c=0 TO 175
FOR b=0 TO 255
Which I could see not terminating, since a byte can never get bigger than 255.
However the problem I have with it as written is it's skipping the loop altogether..
1> Would for/next loops with byte be faster? (I'm following the principle of smaller=faster)
2> Why isn't it running the loop?
|
|
|
|
| CHR / CHR$ issue? (*solved*) |
|
Posted by: britlion - 08-15-2009, 07:51 PM - Forum: Bug Reports
- Replies (2)
|
|
I boiled the issue down to the following code
Code: DIM x,f as integer
CLS
FOR x=1 TO 4
PRINT AT 0,0;
LET f=1
170 print at 0,0;
PRINT (x+64);
IF f<704 THEN
LET f=f+1
GO TO 170
END IF
180 NEXT x
BEEP 1,1
This works perfectly. However, if we ask for the CHR of (x+64):
Code: DIM x,f as integer
CLS
FOR x=1 TO 4
PRINT AT 0,0;
LET f=1
170 print at 0,0;
PRINT CHR(x+64);
IF f<704 THEN
LET f=f+1
GO TO 170
END IF
180 NEXT x
BEEP 1,1
My produced code crashes spectacularly. Has the CHR function come up with a bug?
|
|
|
|
| INK 8 and DIM issues (*solved*) |
|
Posted by: LTee - 07-07-2009, 02:57 PM - Forum: Bug Reports
- Replies (11)
|
|
Hi - I posted these in the blog comments before I realised that this forum existed, so I've reposted them here in case they go unnoticed "out there". :-D
----
Hi Boriel, just been messing around with the compiler a little with an old BASIC game I had lying around and I’m having a little trouble with the INK and PAPER commands.
In ZX Basic you can use INK 8 and PAPER 8 when printing to specify that the character should be printed in ‘whatever colour the screen currently is’, but this doesn’t seem to be supported at the minute by the compiler.
e.g.
Code: PRINT AT 0,0; INK 8; PAPER 8; “X”
… would be red/blue if position 0,0 was already red/blue, green/yellow if position 0,0 was already green/yellow, etc.
The code for setting ink and paper in the compiler appears to do an AND 7; on the passed parameter so it always gets printed as ‘black/black’.
Is there a way around this? I’m using the very latest dev version, btw. :-)
Thanks for all your hard work!
---
Actually, while I’m here… :-)
–array-base=1 seems to be broken in the latest dev build. If you use that parameter it is impossible to set the very first entry in the array (position 1) although subsequent positions are okay. A compiler warning is generated but the code crashes when it runs.
e.g.
Code: 10 DIM p$(2)
20 LET p$(1) = “A”
30 LET p$(2) = “B”
The compiler generates a warning for line 20 (but not line 30) when given –array-base=1. The code works okay if line 20 is removed.
|
|
|
|
| Multiple Entry Points |
|
Posted by: LCD - 06-26-2009, 05:00 PM - Forum: Wishlist
- Replies (2)
|
|
HiSoft Basic offers this: You can define multiple entry points for the code using REM : #OPEN at every line, where a entry point is possible, then at compilation time it displays for every entry point the USR Adress.
|
|
|
|
|
