Weirdness 3

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