Okay, so some of you that I got a brand new TI84+. The LCD driver is horrible. ALCDFIX set it to the max delay, DCS has a "guaranteed to work" version of ionFastCopy, and yet it still manages to not print right. I tried clearing everything, reinstalling the OS, full mem clear, but it did nothing. (I was not expecting it to.)
At this point I decided to see what was inside DCS that could make it mess up. I got the source from GitHub, got an environment that could assemble it, and tested a version on Wabbitemu. It worked. It ran on the calculator too, but the screen was still messed up.
Next, I looked at the Ion Libs that DCS ships with. There are three .asm files, one for each ROM page that can be banked for DCS. They all have the FastCopy routine. The routine for page 0 has label iFastCopy. Page 1 has imFastCopy. Page 2 has immFastCopy. All of them have this line:
.addinstr IN F,(C) 70ED 2 NOP 1
This new instruction does not seem to be called in any of the files. The routines are the same accross them all, except the indentation for some reason. Here it the routine from page 0 with the comments that it came with and my comments:
Code:
At this point, I kind of understand the routine better. I have no idea how the calculator could mess up with this routine. That is, under one circumstance: if "in a,($10) \ rla \ conditional jump" actually test to see if the screen is ready. I am wondering if the screen is so cheap that it does not set the "ready bit".
What my question to all of you Asm experts out there is: could you write me a routine that sees if that bit is actually getting set? I know it is not the easiest thing to do because you do not have a calc that is as bad as mine, but I would really appreciate anything you guys could help me with. Thanks in advance.
At this point I decided to see what was inside DCS that could make it mess up. I got the source from GitHub, got an environment that could assemble it, and tested a version on Wabbitemu. It worked. It ran on the calculator too, but the screen was still messed up.
Next, I looked at the Ion Libs that DCS ships with. There are three .asm files, one for each ROM page that can be banked for DCS. They all have the FastCopy routine. The routine for page 0 has label iFastCopy. Page 1 has imFastCopy. Page 2 has immFastCopy. All of them have this line:
.addinstr IN F,(C) 70ED 2 NOP 1
This new instruction does not seem to be called in any of the files. The routines are the same accross them all, except the indentation for some reason. Here it the routine from page 0 with the comments that it came with and my comments:
Code:
;-----> Copy the gbuf to the screen, guaranteed
;Courtesy of Jim E.
;Input: nothing
;Output:graph buffer is copied to the screen, no matter the speed settings
;
;in f,(c) is an unofficial instruction.
;It must be noted that you cannot specify any other register. Only f works.
;You may have to add it in order for the routine to work.
.addinstr IN F,(C) 70ED 2 NOP 1
;; My comments will have two ;;
;; The original will only have one ;
iFastCopy:
call iCheckInts0
push af ;; There is a comment lower down that says that "the push and pop are wasted clocks". The only things that are pushed or popped are "af". I am going to assume that all of these just waste clock cycles. Correct me if I am wrong.
di
ld c,$10 ;; c is never modified again. It is used to save bytes at every ready check
xor a ;; Begin Nspire Checking
ld r,a
ld a,r
cp 2 ;Nspire check
jr nz,iFastCopyNspire
bit 3,(iy+41h) ;PresentationLink
jr nz,iFastCopyNspire ;; End Nspire Checking
setrow: ;; I really do not know how the screen interprets the data, but setrow is only run once when the screen is ready.
in a,(c) ;; Begin screen wait
rla ;test 7th bit
jr c,setrow ;; End screen wait
ld a,$80 ;; Screen is ready, send some data
out ($10),a
ld hl,gbuf
ld de,12
ld a,$20
col:
push af ;the push and pop are wasted clocks
colwait: ;but this only occurs 12 times
in a,(c) ;; Another screen Wait
rla
jr c,colwait ;; Wait end
pop af ;; Another data send
out ($10),a
push af
ld b,64
row:
in a,(c) ;; Screen wait
rla
jr c,row ;; Wait end
ld a,(hl) ;; Another data send
out ($11),a
add hl,de
djnz row
pop af
dec h
dec h
dec h
inc hl
inc a
cp $2c
jr nz,col
iFastCopyAllFinish:
pop af
ret po
;#ifdef enablecn2eis
ei
;#endif
ret
At this point, I kind of understand the routine better. I have no idea how the calculator could mess up with this routine. That is, under one circumstance: if "in a,($10) \ rla \ conditional jump" actually test to see if the screen is ready. I am wondering if the screen is so cheap that it does not set the "ready bit".
What my question to all of you Asm experts out there is: could you write me a routine that sees if that bit is actually getting set? I know it is not the easiest thing to do because you do not have a calc that is as bad as mine, but I would really appreciate anything you guys could help me with. Thanks in advance.