02-08-2020, 07:29 PM
(This post was last modified: 02-08-2020, 07:34 PM by maeloterkim.)
Hi
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
SUB newPrintat64 (y as uByte, x as uByte)
POKE @p64coords+7,x
POKE @p64coords+8,y
END sub
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
SUB newPrintat64 (y as uByte, x as uByte)
POKE @p64coords+7,x
POKE @p64coords+8,y
END sub