2012-07-26, 01:14 PM
Ok, I'm testing some stuff and I've noticed that:
1.- Using the aplib depacker makes subsequent PRINTs to print the text BOLD. A simple Print Bold 0; At y, x; "o"; At cy, cx; " "; solves this issue.
2.- When I fiddle with paging (i.e. run this code)
The PRINT output gets completely corrupted, as shown in the previous screenshot. So it's not the IM2 code, it's a joint effort between aplib and paging stuff :lol:
The SUB above just pages in RAM 5 to write to screen 0, then pages in RAM 7 to write to screen 1, then pages in RAM 0 so everything is back to normal. How could that mess the PRINT routine so badly?
EDIT: Not just paging, but writing any value to port $7ffd messes up everything (for example, showing screen 1 writing a 1 to bit 3 also messes up things).
1.- Using the aplib depacker makes subsequent PRINTs to print the text BOLD. A simple Print Bold 0; At y, x; "o"; At cy, cx; " "; solves this issue.
2.- When I fiddle with paging (i.e. run this code)
Code:
Sub mt64x32ShowBuffers ()
Asm
di
ld a, 5
ld bc, $7ffd
out (c), a
ld hl, mt64x32_buffer
ld de, $d800
ld bc, 512
ldir
ld a, 7
ld bc, $7ffd
out (c), a
ld hl, mt64x32_buffer + 512
ld de, $d800
ld bc, 512
ldir
xor a
ld bc, $7ffd
out (c), a
ld ($5b5c), a
ei
End Asm
End SubThe PRINT output gets completely corrupted, as shown in the previous screenshot. So it's not the IM2 code, it's a joint effort between aplib and paging stuff :lol:
The SUB above just pages in RAM 5 to write to screen 0, then pages in RAM 7 to write to screen 1, then pages in RAM 0 so everything is back to normal. How could that mess the PRINT routine so badly?
EDIT: Not just paging, but writing any value to port $7ffd messes up everything (for example, showing screen 1 writing a 1 to bit 3 also messes up things).