| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 394 online users.
» 0 Member(s) | 391 Guest(s)
Baidu, Bing, Google
|
| Latest Threads |
.tap file code not execut...
Forum: Help & Support
Last Post: Zoran
04-28-2025, 10:59 AM
» Replies: 4
» Views: 184
|
Exit from more than one l...
Forum: Wishlist
Last Post: Duefectu
04-23-2025, 10:06 PM
» Replies: 3
» Views: 258
|
put small ASM programs li...
Forum: How-To & Tutorials
Last Post: Zoran
04-18-2025, 02:02 PM
» Replies: 6
» Views: 1,520
|
Creating +3 Menus - Loadi...
Forum: Help & Support
Last Post: merlinkv
04-16-2025, 02:08 PM
» Replies: 6
» Views: 512
|
Randomize not very random...
Forum: Help & Support
Last Post: Zoran
04-08-2025, 10:40 AM
» Replies: 4
» Views: 414
|
Scope rules
Forum: Bug Reports
Last Post: Zoran
04-04-2025, 09:46 AM
» Replies: 2
» Views: 286
|
Using constants not allow...
Forum: Bug Reports
Last Post: baltasarq
03-19-2025, 10:00 PM
» Replies: 8
» Views: 1,012
|
404 page not found
Forum: Documentation
Last Post: boriel
03-08-2025, 07:16 PM
» Replies: 5
» Views: 2,849
|
Spectrum keywords codes
Forum: Bug Reports
Last Post: boriel
03-08-2025, 11:00 AM
» Replies: 1
» Views: 394
|
ZXodus][Engine
Forum: ZX Basic Compiler
Last Post: boriel
02-19-2025, 11:43 PM
» Replies: 69
» Views: 213,422
|
|
|
| 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.
|
|
|
|
| Efficiency Optimizations |
|
Posted by: britlion - 05-21-2009, 02:27 PM - Forum: Wishlist
- Replies (1)
|
|
I know, I know - I'm always harping on about this.
1> Does setting array and string indexes to start at 1 - to make it like basic - make for less efficient code?
(that is using the new default for --sinclair that Boriel is presumably putting into the next version)
2> Boriel once mentioned that the default behavior for code like:
Was
Code: ld a, 10 ;Init
ld (_A), a ;Load
inc a ;Inc
ld (_A), a ; Store <<<<< Not needed
sla a ; Multiply
ld (_A), a ; Store
And that -O3 should remove that extra code. I actually can't tell the difference in the above with or without -O3.
What does -O3 do? My code seems to be remarkably similar. In fact, the runtime routines for almost everything are included still - most of the print system (AT, COLOR, BOLD, ITALIC) even if never used).
Is -O3 doing what it's supposed to? I find most short code seems to be just about the same size, suggesting it isn't cutting down on runtime routines at all.
Actual program used:
Code: DIM A as byte
LET A=5
LET A=A+1
LET A=A*2
PRINT A
Actual -O3 Result:
Code: E:\ZX\ZXBwork>zxb Test2.bas -A -O3
INFO: __PRINTI8 is not defined. No optimization is done.
INFO: PRINT_EOL is not defined. No optimization is done.
E:\ZX\ZXBwork>notepad Test2.asm
The produced code was 1134 bytes without -O3 and 1132 bytes with -O3.
The difference is the end of the program. Optimized it does
Unoptimized it closes out with
Code: ld hl, 0
ld b, h
ld c, l
That's the only difference.
These error messages seem a little odd. Am I misusing the -O3 option, somehow? I was expecting it to cut out all the runtimes that wouldn't be needed.
Admittedly in a larger project, most of the runtimes would likely end up being used. I was a little spoiled by the tiny code that the hisoft compiler made, I think :-)
|
|
|
|
|
