LCD Wrote: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 Wrote:

LCD Wrote: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!

britlion Wrote: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.

britlion Wrote: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.

britlion Wrote: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.

britlion Wrote: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

britlion Wrote: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!

britlion Wrote: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.

britlion Wrote: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]

britlion Wrote: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 Wrote:

britlion Wrote:

LCD Wrote: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

britlion Wrote: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.

britlion Wrote: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.