Weirdness 3

[britlion]

Code:

FOR i=0 to 7
    LET charASave(i)=PEEK (23675+i)
    BEEP 1,1
NEXT i

This is a snippet of the same program as previously mentioned. I didn't think it was working right with loops. So, I added a beep. It duly beeps once, clears the screen (with NO cls command) and moves on. If I add a print charASave command, it crashes instead. Shouldn't try to catch it out, I guess.

Boriel, a little while ago,[a version or two back] this was far more stable and predictable...what is going on here?

Best clue I have is that when installing it said something about a newer version being there already. So I uninstalled completely and reinstalled. Is my SDK corrupt?? Is there something completely broken about the 'latest version' on the ftp site?

Am I quietly going insane?

[LCD]

How is the variable [i] defined? Have you tried to define it AS BYTE or AS WORD? Maybe there is a problem if you use unsigned types?
Cannot test it at moment here with my version and my IDE because I was at rewriting some parts which forces the compiler to generate a binary file, and broke my leg, before it was finished.

[britlion]

How is the variable [i] defined? Have you tried to define it AS BYTE or AS WORD? Maybe there is a problem if you use unsigned types?
Cannot test it at moment here with my version and my IDE because I was at rewriting some parts which forces the compiler to generate a binary file, and broke my leg, before it was finished.

You broke your leg? Oh my word! I hope you are okay!

I could send you the whole source code to date if you like. I'm most worried that I'm getting odd problems - such as a function that works and is tested, and then later stops working as I add code. I stick some print statements into it to see what it's doing, and voila, it starts working perfectly again.

I've got my eye on -O3 optimizing out variables that it thinks aren't used at the moment. (As soon as I print it, it's used!) I think I'll try NOT leaving -O3 in the default build script.

What I'm working on, since I have a script for it in the original, is a reworking of the old game FOOTBALL MANAGER. This is one reason I need a lot of string handling! It's mostly text based. I'm a little worried that I'm being wasteful on memory too - having LET team$(1)="Arsenal" - puts the name of the team into the code twice. It would be much nicer to have DIM team$(64)=>{"Arsenal","Liverpool",......} since the compiler could hard code those into the variable without actually having the strings in the code and in the variable space at the same time.

That particular snippet I posted here is from a routine that should take a string, and print out a squished string, with 4 bit wide characters. (giving me 64 char printing).

i is defined as a byte right now - DIM i as byte

Code:

SUB Squishprint (characters$ as STRING)
DIM CHARS AS uInteger AT 23606: REM CHARS System VAR
DIM UDG as uInteger AT 23675
DIM n as uInteger
DIM leftChar,righChar as uByte
DIM leftBin,RightBin as String
DIM i as byte

FUNCTION numToBin$ (num as uByte) as String
(code truncated)
END FUNCTION

function binToNum (binNum$ as String) as uByte
(code truncated)
END FUNCTION            
CLS

REM STORE UDG A so we can use it to print to the screen later.
REM We'll recover it before we quit.
DIM charASave (7) as uByte
FOR i=0 to 7
    LET charASave(i)=PEEK (23675+i)
    BEEP 1,1 : REM WHY does this only beep once?
NEXT i

I'm fully aware that there should be more efficient ways of getting binary equivalents of numbers. There's probably a better way of printing a pair of characters than dropping them into the left and right halves of a UDG as well. Advice would be appreciated!

I'm starting to dip into asm mode - as you might have seen - but the SDK isn't documented for how calls are made. Fastcall I've worked out seems to get the one parameter in A if it's a byte. I can handle that. I think a uInteger gets sent in HL. Maybe.

Standard calls...I have no clue, looking at the code, where the parameters are put. I thought they were pushed on the stack, but then Boriel's versions seem to mess with the stack pointer in ways I can't quite work out.

I did have the idea this morning of instead of saving the bytes at USR "A", I should DIM a uByte array, and point the UDG at that temporarily, and fill that with my print data. It also has the advantage that I could put in up to 21 characters at a time before printing, which should make it smoother. [Remembering of course that if we ever go 128 compatible, that will be 19 characters]

[LCD]

How is the variable [i] defined? Have you tried to define it AS BYTE or AS WORD? Maybe there is a problem if you use unsigned types?
Cannot test it at moment here with my version and my IDE because I was at rewriting some parts which forces the compiler to generate a binary file, and broke my leg, before it was finished.

You broke your leg? Oh my word! I hope you are okay!

Well, I'm not that okay, because I have pains. The doctor found also some problems with my heart and liver, which also need urgently a fix

I could send you the whole source code to date if you like. I'm most worried that I'm getting odd problems - such as a function that works and is tested, and then later stops working as I add code. I stick some print statements into it to see what it's doing, and voila, it starts working perfectly again.

I know what you are talking about. maybe a problem with the Peephole optimiser. Larger code can be very unstable.

I've got my eye on -O3 optimizing out variables that it thinks aren't used at the moment. (As soon as I print it, it's used!) I think I'll try NOT leaving -O3 in the default build script.

Yes, try it without any optimisations

What I'm working on, since I have a script for it in the original, is a reworking of the old game FOOTBALL MANAGER. This is one reason I need a lot of string handling! It's mostly text based. I'm a little worried that I'm being wasteful on memory too - having LET team$(1)="Arsenal" - puts the name of the team into the code twice. It would be much nicer to have DIM team$(64)=>{"Arsenal","Liverpool",......} since the compiler could hard code those into the variable without actually having the strings in the code and in the variable space at the same time.

Then why not using memory access? POKE a String to a label adress (@label), and you can import these data from a binary file. Working with memory is also much faster and you can hard-code some additional routines to manipulate these strings as you like

That particular snippet I posted here is from a routine that should take a string, and print out a squished string, with 4 bit wide characters. (giving me 64 char printing).

i is defined as a byte right now - DIM i as byte

Code:

SUB Squishprint (characters$ as STRING)
DIM CHARS AS uInteger AT 23606: REM CHARS System VAR
DIM UDG as uInteger AT 23675
DIM n as uInteger
DIM leftChar,righChar as uByte
DIM leftBin,RightBin as String
DIM i as byte

FUNCTION numToBin$ (num as uByte) as String
(code truncated)
END FUNCTION

function binToNum (binNum$ as String) as uByte
(code truncated)
END FUNCTION            
CLS

REM STORE UDG A so we can use it to print to the screen later.
REM We'll recover it before we quit.
DIM charASave (7) as uByte
FOR i=0 to 7
    LET charASave(i)=PEEK (23675+i)
    BEEP 1,1 : REM WHY does this only beep once?
NEXT i

64 char text is not well readable, but maybe Borial can include such code. z88dk can switch to 64 char/line mode, so this could be put into Wishlist thread.
To store fonts I use:

Code:

font:
asm
defb 0,0,0,0,0,0,0,0
defb 0,127,47,....
end asm
poke word 23606,@font

Or was it @Font-768 ??? I do not remember. Will check this later.
this works well
I do not know why your routine beeps only once, but maybe if you send the source code to Boriel, he can find the problem.

I'm fully aware that there should be more efficient ways of getting binary equivalents of numbers. There's probably a better way of printing a pair of characters than dropping them into the left and right halves of a UDG as well. Advice would be appreciated!

You can check the SHL and SHR commands. They binary shift variables to left or right. This is a more efficient way Preparing one 4x8 Font, and shifting all the bytes by 4 bits will do the job.

I'm starting to dip into asm mode - as you might have seen - but the SDK isn't documented for how calls are made. Fastcall I've worked out seems to get the one parameter in A if it's a byte. I can handle that. I think a uInteger gets sent in HL. Maybe.

Standard calls...I have no clue, looking at the code, where the parameters are put. I thought they were pushed on the stack, but then Boriel's versions seem to mess with the stack pointer in ways I can't quite work out.

The problem is that detailed instructions are not in english language. So I hope, this will be translated.

I did have the idea this morning of instead of saving the bytes at USR "A", I should DIM a uByte array, and point the UDG at that temporarily, and fill that with my print data. It also has the advantage that I could put in up to 21 characters at a time before printing, which should make it smoother. [Remembering of course that if we ever go 128 compatible, that will be 19 characters]

You should use the normal Spectrum Fonts and just switch between them using the System variable 23606 and 23607. This is the smoothest way.

[britlion]

Good to see that I'm not the only person having frustrations with code suddenly not working in strange and unexplained ways that was working perfectly beforehand.

I've got one routine in there that works perfectly the first 12 times it's called - so it does about 1.5 characters, and then locks up.

Baffles me, that.


What I was originally trying to do was algorithmically come up with something that is readable without actually storing a font - that is take the character "A" from the system font (or from a user defined one) and halve it by algorithm.

I'm pretty convinced by now that I should give that up as a bad job. No fixed algorithm seems to come up with a good result in all cases. There's always something that looks bad.

Best so far? Sending in a line of 8 pixels, send out 4 that are the results of a logical or of each pair. [SO the result is (0 OR 1),(2 OR 3),(4 OR 5),(6 OR 7)]. You'd think that would set too many pixels, but it seems to work pretty well for most cases. Most 64 char printing systems use 3 pixel characters, though.

[britlion]

Does this work for you?

It crashes for me.

I seem to have crashes if I use @ anywhere.

I also can't seem to get logical operators to work properly. This code has both (but the crash prevents me testing the AND)

Oh, yes, - the strings. I couldn't seem to find a convenient way of putting in a 0 byte to null terminate them. I didn't really want to put in DEFB "string" and then DEFB 0 each line. So they are 48 [ascii zero] terminated instead

Code:

teams:
asm
DEFB "Arsenal0"
DEFB "Aston V.0"
DEFB "Brighton0"
DEFB "Coventry0"
DEFB "Everton0"
DEFB "Ipswich0"
DEFB "Liverpool0"
DEFB "Luton0"
DEFB "Man.City0"
DEFB "Man.Utd0"
DEFB "Norwich0"
DEFB "Notts.F.0"
DEFB "Swansea0"
DEFB "Spurs0"
DEFB "Watford0"
DEFB "West Ham0"
DEFB "Blackburn0"
DEFB "Bolton0"
DEFB "Cambridge0"
DEFB "Charlton0"
DEFB "Chelsea0"
DEFB "Crystal P.0"
DEFB "Derby Co.0"
DEFB "Fulham0"
DEFB "Grimsby0"
DEFB "Leeds0"
DEFB "Middlesbro0"
DEFB "Newcastle0"
DEFB "Oldham0"
DEFB "Q.P.R.0"
DEFB "Rotherham0"
DEFB "Sheff.Wed0"
DEFB "Bradford0"
DEFB "Brentford0"
DEFB "Bristol R.0"
DEFB "Cardiff0"
DEFB "Doncaster0"
DEFB "Exeter0"
DEFB "Lincoln0"
DEFB "Millwall0"
DEFB "Newport0"
DEFB "Orient0"
DEFB "Oxford0"
DEFB "Plymouth0"
DEFB "Preston0"
DEFB "Reading0"
DEFB "Southend0"
DEFB "Walsall0"
DEFB "Blackpool0"
DEFB "Bury0"
DEFB "Colchester0"
DEFB "Crewe0"
DEFB "Darlington0"
DEFB "Halifax0"
DEFB "Hartlepool0"
DEFB "Hereford0"
DEFB "Hull0"
DEFB "Mansfield0"
DEFB "Port Vale0"
DEFB "Rochdale0"
DEFB "Scunthorpe0"
DEFB "Stockport0"
DEFB "Torquay0"
DEFB "York City0"
end asm
teamsEnd:

PRINT "Hello World"
PRINT @teams

FUNCTION getTeam(teamNum as uInteger) as String
    DIM var as uInteger
        let var=@teams
    DIM loopy, currentChar as uByte
    DIM stringBuild as String

    WHILE (teamNum AND var < @teamsEnd)
        IF PEEK var <>48 THEN:
            LET var=var+1
        ELSE
            LET teamNum=teamNum-1
            LET var=var+1
        END IF
    END WHILE
              
    WHILE peek var <> 48
        LET stringBuild$=Stringbuild$+CHR$(peek var)
        LET var=var+1
    END WHILE
    
    return stringBuild$
END FUNCTION

[LCD]

Please try this:

Code:

goto start
Fontdata:
asm
    DEFB    000,000,000,000,000,000,000,000
    DEFB    024,024,024,024,024,000,024,000
    DEFB    108,108,108,000,000,000,000,000
    DEFB    108,108,254,108,254,108,108,000
    DEFB    024,062,088,060,026,124,024,000
    DEFB    000,198,204,024,048,102,198,000
    DEFB    056,108,056,118,220,204,118,000
    DEFB    024,024,048,000,000,000,000,000
    DEFB    012,024,048,048,048,024,012,000
    DEFB    048,024,012,012,012,024,048,000
    DEFB    000,102,060,255,060,102,000,000
    DEFB    000,024,024,126,024,024,000,000
    DEFB    000,000,000,000,000,024,024,048
    DEFB    000,000,000,126,000,000,000,000
    DEFB    000,000,000,000,000,024,024,000
    DEFB    006,012,024,048,096,192,128,000
    DEFB    124,198,206,214,230,198,124,000
    DEFB    024,056,024,024,024,024,126,000
    DEFB    060,102,006,060,096,102,126,000
    DEFB    060,102,006,028,006,102,060,000
    DEFB    028,060,108,204,254,012,030,000
    DEFB    126,098,096,124,006,102,060,000
    DEFB    060,102,096,124,102,102,060,000
    DEFB    126,102,006,012,024,024,024,000
    DEFB    060,102,102,060,102,102,060,000
    DEFB    060,102,102,062,006,102,060,000
    DEFB    000,000,024,024,000,024,024,000
    DEFB    000,000,024,024,000,024,024,048
    DEFB    012,024,048,096,048,024,012,000
    DEFB    000,000,126,000,000,126,000,000
    DEFB    096,048,024,012,024,048,096,000
    DEFB    060,102,102,012,024,000,024,000
    DEFB    124,198,222,222,222,192,124,000
    DEFB    024,060,102,102,126,102,102,000
    DEFB    252,102,102,124,102,102,252,000
    DEFB    060,102,192,192,192,102,060,000
    DEFB    248,108,102,102,102,108,248,000
    DEFB    254,098,104,120,104,098,254,000
    DEFB    254,098,104,120,104,096,240,000
    DEFB    060,102,192,192,206,102,062,000
    DEFB    102,102,102,126,102,102,102,000
    DEFB    126,024,024,024,024,024,126,000
    DEFB    030,012,012,012,204,204,120,000
    DEFB    230,102,108,120,108,102,230,000
    DEFB    240,096,096,096,098,102,254,000
    DEFB    198,238,254,254,214,198,198,000
    DEFB    198,230,246,222,206,198,198,000
    DEFB    056,108,198,198,198,108,056,000
    DEFB    252,102,102,124,096,096,240,000
    DEFB    056,108,198,198,218,204,118,000
    DEFB    252,102,102,124,108,102,230,000
    DEFB    060,102,096,060,006,102,060,000
    DEFB    126,090,024,024,024,024,060,000
    DEFB    102,102,102,102,102,102,060,000
    DEFB    102,102,102,102,102,060,024,000
    DEFB    198,198,198,214,254,238,198,000
    DEFB    198,108,056,056,108,198,198,000
    DEFB    102,102,102,060,024,024,060,000
    DEFB    254,198,140,024,050,102,254,000
    DEFB    060,048,048,048,048,048,060,000
    DEFB    192,096,048,024,012,006,002,000
    DEFB    060,012,012,012,012,012,060,000
    DEFB    000,024,060,060,024,060,126,126
    DEFB    000,000,000,000,000,000,000,255
    DEFB    024,012,000,000,000,000,000,000
    DEFB    000,000,120,012,124,204,118,000
    DEFB    096,096,124,102,102,102,220,000
    DEFB    000,000,060,102,096,102,060,000
    DEFB    012,012,124,204,204,204,118,000
    DEFB    000,000,060,102,126,096,060,000
    DEFB    028,054,048,120,048,048,120,000
    DEFB    000,000,062,102,102,062,006,124
    DEFB    000,096,108,118,102,102,230,000
    DEFB    024,000,056,024,024,024,060,000
    DEFB    006,000,014,006,006,102,102,060
    DEFB    096,096,102,108,120,108,230,000
    DEFB    056,024,024,024,024,024,060,000
    DEFB    000,000,108,254,214,214,198,000
    DEFB    000,000,220,102,102,102,102,000
    DEFB    000,000,060,102,102,102,060,000
    DEFB    000,000,220,102,102,124,096,240
    DEFB    000,000,118,204,204,124,012,030
    DEFB    000,000,220,118,096,096,240,000
    DEFB    000,000,060,096,060,006,124,000
    DEFB    048,048,124,048,048,054,028,000
    DEFB    000,000,102,102,102,102,062,000
    DEFB    000,000,102,102,102,060,024,000
    DEFB    000,000,198,214,214,254,108,000
    DEFB    000,000,198,108,056,108,198,000
    DEFB    000,000,102,102,102,062,006,124
    DEFB    000,000,126,076,024,050,126,000
    DEFB    014,024,024,112,024,024,014,000
    DEFB    024,024,024,024,024,024,024,000
    DEFB    112,024,024,014,024,024,112,000
    DEFB    118,220,000,000,000,000,000,000
    DEFB    056,068,186,162,186,068,056,000
end asm
UDGs01:
asm
    DEFB    231,129,129,129,129,129,129,255
    DEFB    255,129,129,128,128,129,129,255
    DEFB    255,129,129,129,129,129,129,231
    DEFB    255,129,129,001,001,129,129,255
    DEFB    231,129,129,000,000,129,129,231
    DEFB    016,056,124,254,056,056,056,000
    DEFB    008,012,126,127,126,012,008,000
    DEFB    000,028,028,028,127,062,028,008
    DEFB    000,016,048,126,254,126,048,016
    DEFB    255,128,128,128,128,128,128,128
    DEFB    255,001,001,001,001,001,001,001
    DEFB    128,128,128,128,128,128,128,255
    DEFB    001,001,001,001,001,001,001,255
    DEFB    255,000,000,000,000,000,000,000
    DEFB    000,000,000,000,000,000,000,255
    DEFB    128,128,128,128,128,128,128,128
    DEFB    001,001,001,001,001,001,001,001
    DEFB    231,000,000,000,000,000,000,000
    DEFB    000,000,000,000,000,000,000,231
    DEFB    128,128,128,000,000,128,128,128
    DEFB    001,001,001,000,000,001,001,001
end asm

start:
paper 0:ink 7:border 0:cls
poke uinteger 23606,@Fontdata-256
poke uinteger 23675,@UDGs01

This works here and it shows how to use the Data to define Fonts and UDGs

[britlion]

That works. Nice font, by the way.

My code was bugged - I had stringbuild, StringBuild as variables. Bad me.

One problem with JUST putting them in as defb is that they are hell to edit later on of course :-)
Though it's definitely smaller.

[LCD]

That works. Nice font, by the way.

My code was bugged - I had stringbuild, StringBuild as variables. Bad me.

One problem with JUST putting them in as defb is that they are hell to edit later on of course :-)
Though it's definitely smaller.

Ouch, I did not saw that. Yes, ZXBC is veeeery case sensitive.
I used Retro-X's Font editor to build the DEFB Data structure (It has also thin font build in). Later also other graphic data can be autogenerated too.

[britlion]

That said, I just tried to compile this:

Code:

DIM n as uByte

FOR n=32 to 127: PRINT chr$(n);: NEXT n

It crashes.

Built using zxb -T -B -a test.bas

and then importing the test.tzx.

If I build with zxb test.bas and then

Code:

CLEAR 32767
<import the bin to 32768 file with spectaculator>
PRINT USR 32768

It crashes differently. It was far more spectacular in the first version.

I get this sort of weird behavior all the time. Apparently today, I can't use CHR(uByte) without a crash. It will probably work tomorrow. @label was crashing a few days ago. Before that it was AND giving non true values.

And sometimes those earlier problems come back. It's most frustrating.


If I change the code to CHR$(32) it works perfectly.

I tried renaming the Program folder, and put in an older copy 1.2.4 I had. This one compiled and ran fine. Hmm.

I'll download a new copy and see if it got corrupted.

[britlion]

I tried a reinstall and get

"There was a network error while reading from c:\users\desktop\username\zxbasic-latest-version.msi"

So, my C drive is a network.

Weirdness continues...

Time to reinstall windows from scratch? Time to go to Linux?

[britlion]

Even after successfully reinstalling, I still get:
Test #2

Code:

FOR smallLoopCounter=144 to 159: print chr$(smallLoopCounter); : next smallLoopCounter

to crash on me (after printing out a number of gibberish squares that are NOT the same UDG I get from BASIC)

[boriel]

How is the variable [i] defined? Have you tried to define it AS BYTE or AS WORD? Maybe there is a problem if you use unsigned types?
Cannot test it at moment here with my version and my IDE because I was at rewriting some parts which forces the compiler to generate a binary file, and broke my leg, before it was finished.

You broke your leg? Oh my word! I hope you are okay!

Well, I'm not that okay, because I have pains. The doctor found also some problems with my heart and liver, which also need urgently a fix

I'm sorry to hear that!! :?
I've just read this thread. I really hope you get well soon and your problems be fixed.

I could send you the whole source code to date if you like. I'm most worried that I'm getting odd problems - such as a function that works and is tested, and then later stops working as I add code. I stick some print statements into it to see what it's doing, and voila, it starts working perfectly again.

Thanks to both you for your code snippets. After I've fixed the compiler bugs (or most of them) we can discuss which snippets could be included with the compiler (as libraries), and how, if you like. :roll:

On the other hand, the library keys.bas (#include <keys.bas>) already has the MultiKeys function, which is able to read multiple keys at once without having to enable interrupts.

[boriel]

That said, I just tried to compile this:

Test #1

Code:

DIM n as uByte

FOR n=32 to 127: PRINT chr$(n);: NEXT n

It crashes.

Built using zxb -T -B -a test.bas

and then importing the test.tzx.

If I build with zxb test.bas and then

Code:

CLEAR 32767
<import the bin to 32768 file with spectaculator>
PRINT USR 32768

It crashes differently. It was far more spectacular in the first version.

I've checked both CHR$(uByte) tests, and they work fine for me. :?:
Don't know if these are related to the <= uByte bug (since FOR uses <= :!: , which now is fixed).

I'm going to upload a 1.2.5beta for you to test.
Which file type are you using? .zip or .msi?

[britlion]

I'm using the msi. I can't quite work out how to get the .zip to install. - I expected it to be an over-the-top copy, but it seems to have a different directory structure than the folder in c:\program files.