10-09-2022, 08:27 PM
(10-09-2022, 06:30 PM)boriel Wrote: That's weird: the "system variable" core.SCREEN_ADDR is initialized with 16384, and core.SCREEN_ATTR_ADDR with 22528 respectively, and they are not modified anymore (in other words, all the instructions using these variables are read-only).
Are you sure that it's the PRINT routine? couldn't it be that a third party is corrupting that variable in some way?
The only other time that SCREEN_ATTR_ADDR is used is in this routine and that is read only:
Code:
Sub SetAttrs (ByVal Row as ubyte, ByVal Column as ubyte, ByVal NumberOfCells as uinteger)
Asm
ld e, (ix+7)
ld d, (ix+5)
ld h, 0 ; 7 T-States
ld a, d ; 4 T-States
add a, a ; a * 2 ; 4 T-States
add a, a ; a * 4 ; 4 T-States
ld l, a ; HL = A * 4 ; 4 T-States
add hl, hl ; HL = A * 8 ; 15 T-States
add hl, hl ; HL = A * 16 ; 15 T-States
add hl, hl ; HL = A * 32 ; 15 T-States
ld d, 18h ; DE = 6144 + E. Note: 6144 is the screen size (before attr zone)
add hl, de
ld de, (.core.SCREEN_ADDR) ; Adds the screen address
;ld de, (SCREEN_ADDR) ; Adds the screen address
add hl, de
ld b, (ix+8)
ld a, (23693)
SetAttrCopy:
ld (hl), a
inc hl
djnz SetAttrCopy
End asm
End sub
The output from this routine is always right regardless if the workaround is employed or not which means it is not dependent on the attr address and it does not modify it. However that output from the print routine is in the wrong color. The screen is set to black paper and white ink and then the screen is switched to another place in memory and then a print command in blue paper and yellow ink but the blue and yellow does not take. It is printed in the original colors of black and white. Then the screen is copied to another screen where it is printed on some more and then it is copied to screen 16384 or screen0. The only way to get the right colors is to employ the workaround.
My routine above always works and the print routine does not and not other routines in my program mess with my screen other than the routine that sets the screen that I have posted before.
So this is a bug in the compiler, read only or not. It is like it does not update the attr address when it is supposed to, that's the closest I can figure.