INK 8 and DIM issues (*solved*)

[LTee]

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.

[boriel]

Thanks, LT.
I was anwering you in the blog to report the bugs here :!:

The INK 8 bug is true. It should be supported (PRINT ROUTINES are ready for them), but the color code is ANDed with 7 (masked) so this value is lost.
The DIM issue is a bit odd, and will take me some time to fix it up.
I will fix them ASAP.

Again, thanks!

[LTee]

Thanks for the fast reply, boriel!

The DIM issue isn't such a big deal, actually - it would be fairly easy for me to alter the source to begin arrays from zero, but it was even more trivial to make each array "1 bigger" (if a little wasteful on memory). :-)

A question, if I may:
One of the things that tripped my listing up was that the compiler doesn't distinguish between a variable called 'a' and a variable called 'a$'. The listing I was trying to compile used 'a' to store an integer and 'a$' to store a String, but the compiler treated both as the same variable, declared it as an Integer and then ran into errors trying to assign it a String value. Easy to fix from my point of view with a little search and replace, but is that expected behaviour?

I've been very surprised at how quickly I managed to get the listing (almost) working - an hour's worth of fiddling and it was compiling and mostly running, which is definitely the best experience I've ever had with a Spectrum BASIC compiler. Many thanks for your excellent work!

[boriel]

It's already been fixed. If you're used to SVN, you can obtain always tha lattest build by typing:

Code:

svn co https://boriel.homeip.net/svn/zxbasic zxbasic

or you can also apply this patch:

Code:

--- zxbparser.py        (revisión: 1454)
+++ zxbparser.py        (copia de trabajo)
@@ -1738,7 +1738,7 @@
         i.next[0] = make_binary(lineno, 'MINUS', make_typecast('u16', i.next[0]), lower_bound, lambda x, y: x - y, _type = 'u16')

         if is_number(i.next[0]):
-            val = i.next[0].value - b.symbol.lower
+            val = i.next[0].value
             if val < 0 or val > (b.symbol.upper - b.symbol.lower):
                 warning(lineno, "Array '%s' subscript out of range" % id)

If you have the windows .MSI version, please wait until next version (tomorrow), so I can also include the INK/PAPER 8 fix. :roll:

[boriel]

A question, if I may:
One of the things that tripped my listing up was that the compiler doesn't distinguish between a variable called 'a' and a variable called 'a$'. The listing I was trying to compile used 'a' to store an integer and 'a$' to store a String, but the compiler treated both as the same variable, declared it as an Integer and then ran into errors trying to assign it a String value. Easy to fix from my point of view with a little search and replace, but is that expected behaviour?

Yes, it is: BASICally I follow the FreeBasic convention, which states just that, but trying to maintain the original Sinclair BASIC compatibility as much as possible.

I agree it might be confusing at first. But trying to include sigils ($ symbols) into the namespace might be a little difficult at this stage. I'll see what I could do: probably another compilation flag, or just add it to the --sinclair flag.

I've been very surprised at how quickly I managed to get the listing (almost) working - an hour's worth of fiddling and it was compiling and mostly running, which is definitely the best experience I've ever had with a Spectrum BASIC compiler. Many thanks for your excellent work!

Thanks a lot. I've been somewhat busy with my PhD, but I hope to make some improvements from now on.
To convert a listing I use BASIN editor. I load the original BASIC into BASIN an then export it as ASCII. This saves me a lot of time. But there's some improvements suggested by LCD and britlion I would also like to include.

[LTee]

I applied the patch to the version I have and it works fine now - cheers!

Looking through the compiler code is very interesting too - I'm a Java programmer by trade but have been trying to learn Python in my spare time. :-)

[boriel]

I applied the patch to the version I have and it works fine now - cheers!

Looking through the compiler code is very interesting too - I'm a Java programmer by trade but have been trying to learn Python in my spare time. :-)

There's still a lot of code refactoring to do (mainly at the zxbparser and the zxbtrad) modules. I started with a traditional Lex/Yacc approach (no OOP at all), but since this is python and PLY is also OOP oriented itself, I started to change the code too, but some parts are a bit critical so I left them for the last.

I hope to do a deep code refactoring for version 2.0 (probably started as a SVN branch).

[boriel]

Version 1.2.2 is out and fixed the DIM bug and adds INK 8 & PAPER 8 capabilities.
Please, download and test them!

[LTee]

Looking good - my listing is producing a much better display now! It's still not quite working, but that must be something else not related to the graphics - I'll get back to hacking around with it when I have ten minutes. :-)

Many thanks for the fast fix, boriel!

[LTee]

Holy crap! I figured out what the problem was and got the game up and running and it's so much faster than the version I had compiled with Hisoft's compiler it's unbelievable! I'm going to have to slow it down, it's just unplayable! :-D

Amazing work!

My problem was a simple syntax misunderstanding with the positioning of END IF on lines which have multiple IF statements - I didn't realise IFs could be nested so I'd put one of the END IFs in the wrong place. This meant that the second IF statement on the line was running even if the first IF statement didn't, and that was messing up the game logic.

I initially did this:

Code:

2320 IF dead=1 THEN PRINT INK 8; PAPER 8;AT y,x;" ": LET x=newx: LET y=newy: GO SUB 4900: END IF: IF dead=0 THEN GO TO 2000: END IF

But what I should have done was this:

Code:

2320 IF dead=1 THEN PRINT INK 8; PAPER 8;AT y,x;" ": LET x=newx: LET y=newy: GO SUB 4900: IF dead=0 THEN GO TO 2000: END IF: END IF

... so that the second IF statement only runs if the first IF statement is true.

So... back to the trying to figure out how to slow this thing down. :mrgreen:

[boriel]

Holy crap! I figured out what the problem was and got the game up and running and it's so much faster than the version I had compiled with Hisoft's compiler it's unbelievable! I'm going to have to slow it down, it's just unplayable! :-D

Amazing work!

My problem was a simple syntax misunderstanding with the positioning of END IF on lines which have multiple IF statements - I didn't realise IFs could be nested so I'd put one of the END IFs in the wrong place. This meant that the second IF statement on the line was running even if the first IF statement didn't, and that was messing up the game logic.

I initially did this:

Code:

2320 IF dead=1 THEN PRINT INK 8; PAPER 8;AT y,x;" ": LET x=newx: LET y=newy: GO SUB 4900: END IF: IF dead=0 THEN GO TO 2000: END IF

But what I should have done was this:

Code:

2320 IF dead=1 THEN PRINT INK 8; PAPER 8;AT y,x;" ": LET x=newx: LET y=newy: GO SUB 4900: IF dead=0 THEN GO TO 2000: END IF: END IF

... so that the second IF statement only runs if the first IF statement is true.

So... back to the trying to figure out how to slow this thing down. :mrgreen:

Wow! Nice to hear that. Believe or not, these things are what motivates me a lot!! :!: :wink:

To slow down things I was preparing the Sleep(Frames) function, which is exactly like PAUSE but won't return on a keypress.

For better legibility, you can write that line this way:

Code:

2320 IF dead=1 THEN
       PRINT INK 8; PAPER 8;AT y,x;" "
       LET x=newx: LET y=newy
       GO SUB 4900
       IF dead=0 THEN GO TO 2000: END IF
     END IF

[LTee]

A sleep function would be ideal, I think.

The legibility of this piece of code does leave rather a lot to be desired! It's an export of an existing Spectrum BASIC listing so it looks pretty much like it would on a real Spectrum at the minute. If I do actually get around to finishing it at some point (it's only 3/4 of a game) it might also be a good opportunity to make it actually readable. :-D

Incidentally, the interpreted Spectrum BASIC version really is unplayable - it's ridiculously slow.