| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 95 online users.
» 0 Member(s) | 94 Guest(s)
Bing
|
| Latest Threads |
New video Couse / Nuevo c...
Forum: News
Last Post: Duefectu
2026-04-29, 11:02 PM
» Replies: 0
» Views: 211
|
location of heap manageme...
Forum: Help & Support
Last Post: boriel
2026-03-07, 12:13 AM
» Replies: 1
» Views: 483
|
non-paged supervisor code...
Forum: Help & Support
Last Post: sdo303
2026-02-20, 06:38 PM
» Replies: 8
» Views: 1,295
|
How to open fuse as an ex...
Forum: How-To & Tutorials
Last Post: Duefectu
2026-02-09, 01:52 PM
» Replies: 3
» Views: 1,389
|
Old zxbasic game errors
Forum: Help & Support
Last Post: boriel
2025-11-09, 11:52 AM
» Replies: 7
» Views: 2,075
|
Error: Undefined GLOBAL l...
Forum: Help & Support
Last Post: ardentcrest
2025-11-04, 05:46 PM
» Replies: 3
» Views: 1,080
|
A Fast(er) Plot Routine f...
Forum: How-To & Tutorials
Last Post: tubz74
2025-10-30, 03:16 PM
» Replies: 2
» Views: 1,179
|
Hall of Fame - Include fo...
Forum: How-To & Tutorials
Last Post: tubz74
2025-10-28, 03:48 PM
» Replies: 0
» Views: 630
|
[SOLVED] Array layout bug...
Forum: Bug Reports
Last Post: Zoran
2025-10-25, 05:48 PM
» Replies: 2
» Views: 1,217
|
3DOS Commands?
Forum: Help & Support
Last Post: boriel
2025-10-06, 02:54 PM
» Replies: 3
» Views: 1,380
|
|
|
| errors upon compilation |
|
Posted by: slenkar - 2017-07-28, 07:43 PM - Forum: Bug Reports
- Replies (2)
|
 |
when using the stable version:
/root/Downloads/zxbasic/zxb.py -t -a -B /root/Downloads/zxbasic/examples/colors.bas (in directory: /root/Downloads/zxbasic/examples)
Traceback (most recent call last):
File "/root/Downloads/zxbasic/zxb.py", line 12, in <module>
from six import StringIO
ImportError: No module named six
Compilation failed.
the most recent version of ZXBASIC:
python /root/Downloads/zxbasic/zxb.py -t -a -B /root/Downloads/zxbasic/examples/colors.bas (in directory: /root/Downloads/zxbasic/examples)
Traceback (most recent call last):
File "/root/Downloads/zxbasic/zxb.py", line 14, in <module>
import api.debug
File "/root/Downloads/zxbasic/api/debug.py", line 10, in <module>
from .config import OPTIONS
File "/root/Downloads/zxbasic/api/config.py", line 20, in <module>
from . import global_
File "/root/Downloads/zxbasic/api/global_.py", line 21, in <module>
from .constants import TYPE
File "/root/Downloads/zxbasic/api/constants.py", line 175
NAME_TYPES = {cls.TYPE_NAMES[x]: x for x in cls.TYPE_NAMES}
^
SyntaxError: invalid syntax
Compilation failed.
is it because my version of python is incompatible? its 2.6.4
EDIT -
using python3 works:
python3 /root/Downloads/zxbasic/zxb.py -t -a -B /root/Downloads/zxbasic/examples/colors.bas (in directory: /root/Downloads/zxbasic/examples)
Compilation finished successfully.
|
|
|
| Iterate through characters of a string? |
|
Posted by: slenkar - 2017-07-28, 07:21 PM - Forum: Help & Support
- Replies (1)
|
|
How does someone get each character of a string?
(im trying to do wordwrap for a large string)
oh I got the word wrap working now:
Code: dim printwidth=28
Let a$="PART 1 Bruce Hall, a slightly built youth 16 years of age, fair haired and blue eyed, stood 4' 8 in shoes and despite that slight assistance still could not see over the brick wall behind which he believed stood a flying machine. At least that was what he'd overheard two delivery boys discussing outside the local butchers shop."
REM pRINT a(1 to 10)
dim stringpos as integer
stringpos=0
dim lines as integer
dim sentenceEnd as integer
while stringpos<len(a)
sentenceEnd=stringpos+printwidth
if sentenceEnd<len(a) then
FOR stringposIter=sentenceEnd TO stringpos STEP -1
if code(a(stringposIter to stringposIter))=code(" ") then
print at lines,0;a(stringpos to stringposIter)
stringpos=stringposIter
exit for
end if
next
end if
if sentenceEnd>len(a) then
print at lines,0;a(stringpos to sentenceEnd)
exit while
end if
lines=lines+1
wend
|
|
|
|
| Where does Boriel assemble to? |
|
Posted by: ivanb303 - 2017-07-17, 02:57 AM - Forum: Help & Support
- Replies (3)
|
|
So this is like an etch-o-sketch but It doesn't like the screen grabbing part. This all works fine in Sinclair BASIC. I'm guessing the picture data collides with Boriel's compiled code. I'm also guessing that Boriel decides where to inline ASM sections. Can you explicitly tell Boriel where to assemble to ?
Code: #include <fastPlot.bas>
DIM cx,cy,x,y,cl AS UINTEGER
10 REM The variables
20 LET cx=128: LET cy=80: LET x=cx: LET y=cy:LET cl=0: INK 0
30 INK cl: fastPlot(x,y)
100 IF INKEY$="a" AND x>=0 THEN LET x=x-1: END IF
120 IF INKEY$="s" AND x<=255 THEN LET x=x+1: END IF
130 IF INKEY$="o" AND y<=175 THEN LET y=y+1: END IF
150 IF INKEY$="k" AND y>=0 THEN LET y=y-1: END IF
160 IF INKEY$="f" THEN PRINT AT 0,0;"Frame grabbed!": grabScreen(): END IF
170 IF INKEY$="g" THEN PRINT AT 0,0;"Frame pasted!": CLS : dumpScreen() : END IF
180 IF INKEY$="n" AND cl>=0 THEN LET cl=cl-1: END IF
190 IF INKEY$="m" AND cl<=7 THEN LET cl=cl+1: END IF
200 GO TO 30
SUB grabScreen()
ASM
LD HL,16384
LD DE,51200
LD BC,6912
LDIR
RET
END ASM
END SUB
SUB dumpScreen()
ASM
LD HL,51200
LD DE,16384
LD BC,6912
LDIR
RET
END ASM
END SUB
What i found strange also was that sometimes it seems to work fine, and sometimes it doesn't. Pressing f button does the frame grab
but FUSE freezes, the border goes blue and you might get garbled stuff at bottom of screen.
|
|
|
|
| Memory/heap corruption during string manipulation |
|
Posted by: LTee - 2017-06-26, 11:06 PM - Forum: Bug Reports
- Replies (1)
|
|
This one's a bit long, sorry in advance!
As mentioned in the support forum, I've been having problems with my program growing unstable and crashing after a while. With your help (thanks!) I've narrowed the issue down to a single routine (and possibly a single line, but we'll get to that in a minute) which seems to be causing something bad to happen to the heap and/or memory.
I've extracted the offending routine out into the following program:
Code: #include <alloc.bas>
DIM i,q,n as ubyte
DIM st$, k$ as string
DIM pee$(20) as string
DIM name$(6) as string
test()
sub printmem(num as ubyte)
dim f, m as uinteger
f = memavail
m = maxavail
print at 22,0; ink 6; paper 2; flash 1;str$(f);" ";at 22,15;str$(m);" "
print at 23,0;str$(num)
go sub 9500
end sub
sub initarrays()
pee$(1)="nok"
pee$(2)="fra"
pee$(3)="gog"
pee$(4)="frak"
pee$(5)="tut"
pee$(6)="zex"
pee$(7)="gal"
pee$(8)="shun"
pee$(9)="ren"
pee$(10)="kal"
pee$(11)="sun"
pee$(12)="xox"
pee$(13)="yen"
pee$(14)="soo"
pee$(15)="arc"
pee$(16)="qir"
pee$(17)="oon"
pee$(18)="tak"
pee$(19)="raak"
pee$(20)="wyk"
end sub
sub test()
initarrays()
do
cls
go sub 8500
loop
end sub
8499 REM alien names
8500 printmem(1): LET i=1: printmem(2)
8510 FOR n=1 TO 6: LET st$=pee$(i): printmem(3)
8520 LET q=INT (RND*9)+1
8530 IF q<=3 THEN LET st$=st$+"'": GO TO 8540: END IF
8535 IF q>=7 THEN LET st$=st$+"-": END IF
8540 printmem(4): LET i=i+1: LET st$=st$+pee$(i): LET i=i+1: printmem(5)
8545 IF CODE (st$(1))>96 THEN LET st$(1)=CHR$ ( CODE (st$(1))-32): END IF
8550 printmem(6): LET name$(n)=st$: printmem(7): print at n,0;name$(n): printmem(8): NEXT n
8560 printmem(9): RETURN
9499 REM get keypress
9500 IF INKEY$<>"" THEN GO TO 9500: END IF
9510 LET k$=INKEY$: IF k$="" THEN GO TO 9510: END IF
9520 RETURN
I'm compiling with:
-t -B -a --array-base=1 --string-base=1 --strict-bool --explicit
Apologies for the untidy appearance of the code, part of it's ripped straight from my game and the rest I wrote to support this test. The subroutine at line 8500 is supposed to generate six random alien names by taking a base array of 20 partial strings, then randomly choosing 12 of them and joining them together in pairs (perhaps also including a hyphen or apostrophe).
I've removed the random elements because they don't seem to affect the result, so in this test the same names will be generated each time. I've also introduced a lot of calls to a routine that prints the available memory and waits for you to press a key - the number displayed on the bottom line of the display shows you where you are in the code at any moment.
If you run the program and keep pressing a key, you will see that the numbers change as the names are generated but you're never really short of heap space. However, it's unlikely you'll make it through to the end of all six names without either the heap display going crazy and displaying huge numbers (usually between steps 6 and 7) or screen corruption appearing and the program crashing (usually but not always between steps 3 and 4).
I've tried altering the heap size and it doesn't seem to make any difference - even using a 10k+ heap it crashes in the same way.
What *does* make a difference (and I have no idea why) is removing line 8545. This is supposed to capitalise the first letter of the name (done in the Sinclair BASIC way). With that line in, the program fails almost every time. REM that line out and it works perfectly, but I don't know why. I've tried taking that single line and writing another test program around that alone, but I can't make it fail outside of this specific context.
Knowing that, I could probably work around the issue but I'm a bit worried I'd be leaving a potential bug unfixed if I did. It's also possible I've done something crazy and illegal here, in which case I'd love to know what it is so that I don't do it again! Let me know if anything doesn't make sense or you need anything else! And thanks, as always. 
|
|
|
|
| Strange behaviour with memory pointer calculation (*solved*) |
|
Posted by: LTee - 2017-06-25, 04:33 PM - Forum: Bug Reports
- Replies (7)
|
|
Splitting this out from the other thread, sorry.
In 1.6.2 there seems to be something weird going on when I perform calculations on memory pointers. My program switches between various banks of UDGs by POKEing 23675/23676 to point to different addresses. When I compiled with the 1.6.2 I noticed that none of my UDGs were working properly. After some experimentation I discovered that the maths I was using to calculate the high and low byte values was giving the wrong values for some reason.
Take a look at this program, which I adapted from my main program (hence it looking a bit weird, sorry):
Code: dim n, b as ubyte
declare sub start()
start()
UDGS:
asm
defb 255,255,255,255,255,255,255,255
end asm
sub start()
cls
print "@UDGS = ";@UDGS
print "@UDGS/256 = ";(@UDGS/256)
print "int(@UDGS/256) = ";int(@UDGS/256)
b=int(@UDGS/256)
print "b = ";b
end sub
When I run this the address of the UDGS bank is 32793. The first two calculations that I print directly (without assigning to a variable) work as I would expect - the value is 128. But when I do the same calculation and assign it to ubyte 'b', the value suddenly becomes 254. This same program produces '128' in all PRINT statements using version 1.5.3 of ZX Basic.
I've no idea what's going on there, unfortunately. Sorry! 
|
|
|
|
| Heap help |
|
Posted by: LTee - 2017-06-24, 08:11 PM - Forum: Help & Support
- Replies (5)
|
|
Hi boriel,
I wondered if you could help me understand the heap a little better? Reading the forum I've determined that the heap is mainly used for string handling and by default is just over 4k in length (but may take up the rest of memory - is that right?)
My program is fairly large (just over 30K when compiled with -O2, I am compiling from address 24576 to give me extra space). When running it does quite a lot of string manipulation and I've noticed that it becomes steadily more unstable over time until it finally crashes, either with an 'out of memory' (I'm using --debug-memory) or screen corruption appears and the Spectrum crashes. I'm thinking that either I don't have enough heap or something is quietly writing over areas of memory that it shouldn't and after a while that brings the whole thing crashing down. I've tried increasing (and decreasing!) the heap space with the -H command, but it doesn't seem to make any difference.
How can I tell where the heap is located in memory, and how big it is? Is there any way to get the running program to output how much heap space it thinks is left? The heap should always be located after the compiled code in memory, right? And all string data should be in the heap? I tried compiling with the -d option but this generates tons of output, most of which I don't really understand.
Does anyone have any advice on things to look for that might be causing problems like this? The program I'm working with was originally a Sinclair BASIC listing so it relies quite heavily on GO SUB/RETURN, too, so I guess it's possible that it might be nothing to do with the heap and maybe something stack-related? Grasping at straws really, I'm really just looking for a bit of advice on what I could investigate next.
Thanks!
|
|
|
|
| Best replacement for 'READ/DATA' |
|
Posted by: LTee - 2017-06-22, 10:14 PM - Forum: Help & Support
- Replies (3)
|
|
I have a scenario in a program I'm converting from Spectrum BASIC to ZX Basic where I need to replace a READ/DATA setup. The code prints messages something like this:
10 restore x: read a, b
20 for n = 1 to b: read i, m$: print ink i; at a+n, 0; m$: next n: return
30 data 10, 3, 6, "test", 7, "test 2", 5, "test 3"
So the code sets 'x' to the DATA row containing the message you want to print (in this case x=30), then you call the subroutine at line 10 which reads the position and number of rows, then loops through 'b' rows reading the ink colour and the message and printing them to the screen.
I need to replace this in ZX Basic with something different. At the minute I've just shoved everything into arrays, but this is very inefficient because I'm effectively storing the data twice so the message bank takes up a lot more memory than it needs to.
What's the 'best' way to do this? I was thinking of maybe having a bunch of DEFB statements to directly replace the DATA lines, terminating each string with a 0 marker. That way I can read the bytes for 'a', 'b' and 'i' easily with PEEKs, and build the messages up by reading until I reach the '0'. I'm not sure how performant that would be, though - is there a faster way to copy a chunk of memory into a string?
Interested to hear any ideas!
|
|
|
|
| Possible issue with < and > (* solved *) |
|
Posted by: LTee - 2017-06-20, 10:12 PM - Forum: Bug Reports
- Replies (9)
|
|
I'm struggling a bit with the behaviour of the < and > operators compared to Spectrum BASIC and I'm not sure if what I'm seeing is a bug or expected behaviour.
Check out this program:
Code: dim t,t2 as byte
let t=1
let t2=0
print 1>0
print 1<0
print t>0
print t<0
print t>t2
print t<t2
If I run the equivalent of this in Sinclair BASIC then the output is:
1
0
1
0
1
0
But compiled in ZX Basic I get:
1
0
255
0
255
0
With just numbers the result is the same as Spectrum BASIC, but as soon as I start using typed variables in ZX Basic the 'true' value switches from 1 to 255. Is that expected behaviour? It seems a bit odd, but I realise there might be a really good reason for it.
The program I'm trying to compile relies on the result of similar clauses to perform calculations, so if the answer could be something other than 0 or 1 I'll have to rewrite it a bit. That's not a problem, but I didn't want to do that if this is actually a bug that might get fixed later.
Thanks for any help!
|
|
|
|
|
