Welcome, Guest |
You have to register before you can post on our site.
|
Online Users |
There are currently 176 online users. » 0 Member(s) | 175 Guest(s) Bing
|
Latest Threads |
.tap file code not execut...
Forum: Help & Support
Last Post: Zoran
04-28-2025, 10:59 AM
» Replies: 4
» Views: 321
|
Exit from more than one l...
Forum: Wishlist
Last Post: Duefectu
04-23-2025, 10:06 PM
» Replies: 3
» Views: 300
|
put small ASM programs li...
Forum: How-To & Tutorials
Last Post: Zoran
04-18-2025, 02:02 PM
» Replies: 6
» Views: 1,600
|
Creating +3 Menus - Loadi...
Forum: Help & Support
Last Post: merlinkv
04-16-2025, 02:08 PM
» Replies: 6
» Views: 555
|
Randomize not very random...
Forum: Help & Support
Last Post: Zoran
04-08-2025, 10:40 AM
» Replies: 4
» Views: 893
|
Scope rules
Forum: Bug Reports
Last Post: Zoran
04-04-2025, 09:46 AM
» Replies: 2
» Views: 330
|
Using constants not allow...
Forum: Bug Reports
Last Post: baltasarq
03-19-2025, 10:00 PM
» Replies: 8
» Views: 1,066
|
404 page not found
Forum: Documentation
Last Post: boriel
03-08-2025, 07:16 PM
» Replies: 5
» Views: 2,887
|
Spectrum keywords codes
Forum: Bug Reports
Last Post: boriel
03-08-2025, 11:00 AM
» Replies: 1
» Views: 419
|
ZXodus][Engine
Forum: ZX Basic Compiler
Last Post: boriel
02-19-2025, 11:43 PM
» Replies: 69
» Views: 213,809
|
|
|
Memory/heap corruption during string manipulation |
Posted by: LTee - 06-26-2017, 10: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 - 06-25-2017, 03: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 - 06-24-2017, 07: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 - 06-22-2017, 09: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 - 06-20-2017, 09: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!
|
|
|
--base-string=1 issue (* solved *) |
Posted by: LTee - 06-19-2017, 07:21 PM - Forum: Bug Reports
- Replies (7)
|
 |
Hi guys,
It's been a while but I recently started trying to convert a program written in 'standard' Sinclair BASIC so that it would compile with ZX Basic. It's going fairly well, but I've come across a problem with the --base-string option in release 1.5.3.
Take a look at this short program, which is supposed to replace 'character 1' in a string:
Code: dim st as string
cls
let st="test"
print st(1)
let st(1)="X"
print st(1)
print st
If I compile this with --base-string=0 then the result is 'e/X/tXst', as I would expect.
However, if I compile with --base-string=1 then the result is 't/t/tXst' rather than 't/X/Xest'. It seems the read of char '1' respects the setting, but the write does not.
I've been having some pretty weird crash errors that look like memory being randomly overwritten - wondering if maybe this might have something to do with it (fingers crossed).
Thanks in advance for anything you can do to help!
|
|
|
Stop vb to open bas file |
Posted by: Odie - 06-09-2017, 09:31 AM - Forum: Help & Support
- Replies (7)
|
 |
I am new to this
1. I have made a file Hello.bas
2. In the folder where the ZXB files are I have but the file hello.bas
3. I open cmd connad file and enter zxb.py hello.bas
Now vb. net is opening the py file, and it does noting.
How can I stop VB to open this files.
|
|
|
|