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:

;-----> 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.
I got it to work... kind of. I removed Nspire support completely. I removed all of the code that waited for the LCD to be ready, replaced it with a 100 cycle wait. Before and after every out instruction, I put the 100 cycle wait. Now, DCS runs, but at the speed of a basic game. I will try to remove all of the waits that I can to make it faster. But for now, it runs. I will edit this post when I figure out more.
At this point I am frustrated with DCS. I have a more or less working version, but the DCS libs never activate. I think this might be because I made page 2 slightly larger with my wait routine. At this point I need a professional to help me: I have other programs that run just fine and use ionFastCopy. Could one of you people help me?
MateoC: TWHG runs just fine. Could you send me the ionFastCopy routine you used?
Runner112: Do you know what ionFastCopy routine is used in Axe?
Does anyone know the ionFastCopy routine that Portal Prelude uses?

Anyway, if you can help, I will greatly appreciate it.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement