Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug report with print64 routine
#1
Hi  Smile 

I tried the print64 routine but has a bug 

If you try this program in red

#include <print64.bas>

'printat64(10,10)  'This will not work because de poke is incorrect You can try
print64("Hello world!")

print at 15,0;"@p64coords "; @p64coords
;


and then you look at the dissasembly attached image

where after the RET with red color in the image, is supposed that is the @p64coords address (when you run the program writes the @p64coords address to check where is)


in this @p64coords address is where is supposed to poke de X and Y values of the new coordinates with the printat64 routine that is included in print64.bas

but the coordinates are in the green lines addresses with the value 12 and 0 

you can check this if you look at the same time at the image with colors ( or your own dissasembly) and the print64.bas file

There is some bytes in between that are moving down the useful poke for the coodinates that  printat64 routine does


ANOTHER THING
----------------------------------


This bug was found because i was trying to change the print64 font to another one

I did this subroutine for this

' Changes character set of the print64 routine
' this does a poke where is the assembly instruction :      ld de, p64_charset
SUB change64Charset (new64CharSet as uinteger)

       poke uinteger ( @p64coords - 123 ), new64CharSet

END sub


Maybe you can solve the bug AND  at the same time include this subroutine in the print64.bas file

this way the people can change the print64 x,y  and the character set of the print64

i named the subroutine change64Charset but you change the name accordly to the print64 routine

i don't know for example  print64ChangeCharset or something

you can only must be sure that the poke is always made in the correct positions for both routines

i don't know if is posible to include some constant label inside the routine that makes some positions of memory fixed to be poked

Now we must calculate by hand until fixed someway, where are the addresses to poke

if you try this subroutine adding 7 to the original subroutine it works Smile 

SUB newPrintat64 (y as uByte, x as uByte)
    POKE @p64coords+7,x
    POKE @p64coords+8,y
END sub





Reply
#2
I will check this. BTW which program version are you using?
If you don't have 1.9.9 please download it an use it (or the 1.10.0 beta I post in the other topic). In the directory tests/runtime (only available in the git repository) there's a print64 test which include printat64 and it works ok.

https://github.com/boriel/zxbasic/blob/m...rint64.bas

I don't understand why +7 and +8 are needed. I tried your example in red (with the printat64 uncommented) and it worked as expected. Compiled example attached to this message.


Attached Files
.tap   p64.tap (Size: 2.25 KB / Downloads: 1)
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)