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

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 259
» Latest member: DonaldDeade
» Forum threads: 1,074
» Forum posts: 6,434

Full Statistics

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

 
  Syntax highlighter for Notepad++ ?
Posted by: ivanb303 - 07-10-2017, 12:05 PM - Forum: How-To & Tutorials - Replies (1)

Does anyone have a syntax highlighter to use with Notepad++ ?? What do you guys use for writing Boriel ZX Basic ?

Print this item

  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. Smile

Print this item

  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. Smile

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! Sad

Print this item

  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. Smile

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!

Print this item

  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!

Print this item

  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. Smile

Thanks for any help!

Print this item

  --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! Smile

Print this item

  First game in Radastan Mode
Posted by: symbolshift - 06-18-2017, 07:09 PM - Forum: Gallery - No Replies

Hi!

This is a very simple (and with some bugs) breakout clone game my friend Pooky and I did just to try out the Radastan Mode with Boriel Basic. Thank you LCD and Boriel for your help. It's quite odd to display graphics on the Spectrum without taking care of the color clash... :wink:

https://www.dropbox.com/s/txi22502tryidv...2.tap?dl=0

Print this item

  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.

Print this item

  I wrote this for the countdown of the ZX Next Kickstarter
Posted by: emook - 06-07-2017, 07:59 PM - Forum: Gallery - Replies (2)

Music is 6 channel dual AY music, a cover of Madonna's Hung Up by Factor6.

It uses Putchars by Britlion, then everything else is written in ZXB (the vumeters are done with inline ASM)

https://www.youtube.com/watch?v=_oVgRtlZ4Cc&

Print this item