Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: Raylin on June 09, 2010, 06:26:08 pm
-
Hello.
In your YouTube video "Hands-On with the TI-Presenter", you helped me stumble upon the reason why my Presentation Link gives me problems. In your video around 1:36, you stated the reason why these "wavy lines" occur. I am in a Science Olympiad called ACT-SO and we go to Nationals on the week of July 7th. My project for ACT-SO is "Can you create a video game on a calculator?" (Silly, I know. But not everyone is as savvy about these things as we are.) I need the Presentation Link to work before Nationals and I'm afraid my project will be all for naught if I can't fix it.
My game, Lemonade Tycoon, is made in xLib and BASIC. How would I fix that problem?
-
BASIC games don't have this problem. Assembly programs with their own LCD delay routines are the problem. Those can be modified to use the LCD delay routine at 000Bh instead, which is designed to work with the Presentation Link adapter.
xLIB may be (and probably is) one of said assembly programs/Flash applications that has its own LCD delay routine, surely out of necessity. You/me/somebody could try modifying xLIB to increase the LCD delay or use the one at 000Bh to see if that helps, but it'll cause you to see slowdown on a real calculator as well that might be unacceptable. Only way to know is to try it.
On the 83+SE and up, it may be possible to use the LCD delay hardware ports (in the 0x2x range, if memory serves) to do this without modifying xLIB. I haven't messed with these ports a lot so I couldn't say for sure, but hopefully that gives you some direction.
-
Thank you very much.
And, slowdown wouldn't matter. They only want the application of.
If it works, it works.
-
ports $29 and $2A are the important ones. (I think xLib only runs at 6MHz, so only $29 is the important one)
BrandonW can supply what the appropriate delay is. Note that all you'll have to do is use calcsys's port monitor or a very small (<20 bytes) asm program before you demonstrate your game.
-
I would say just experiment with the values of those ports, but there's absolutely no guarantee that the maximum setting will be enough for the Presentation Link. You'd think that if it were, the TI-OS would just modify that instead of wasting more CPU cycles. But then again, this is TI we're talking about.
I don't think it would be too hard to modify xLIB to do this if it comes to that.
-
Would it be too hard to make a program that would search for common screen update routines and replace calls to them with a call to 000Bh?
-
Not so much hard, but there are far too many possible routines to search for to make it worth it. Some games require that useful work be done while waiting for the LCD to become ready, and that's not easily patchable. So basically, it wouldn't be worth it.
-
Moved to Calc help and support, as it was in the wrong section.
Does your game works in Door CS 7 and Celtic III btw? xLIB Source is not available.
-
The game works.
It's just the wavy lines on the TI Presentation Link that I want to disappear.
@calcdude84se: You said something about CalcSys's port monitor. Could you explain this process?
How would you edit the values of the port and make it work?
-
Well I was mentionning Celtic/DCS because since source is still available, then they could be modified to work fine on the presenter maybe, something impossible with xLIB
-
It's not exactly impossible to modify xLIB to do this. Just because the source isn't available doesn't mean it can't be disassembled and patched, much like the TI-OS itself. I think it would be relatively trivial to modify a Flash application to include this extra delay, but then again I haven't looked at an xLIB disassembly in quite some time.
-
With respect to modifying, wouldn't just replacing the call to fastCopy with the romcall to copy the graph buffer work all the same for that purpose?
-
Yes, but I'm not sure how well that would work with the rest of the xLIB code. Using the BCALL, as you know, is a lot slower -- maybe too slow. It's certainly worth a shot, it just may be a little more involved.
-
Anyway. If Celtic III could work in place of xLIB for this particular game, I've already reworked my version to use the romcall instead of the fastcopy routine. This one's a pre-release of version 3.09t, so as always, back up the contents of your calculator before using it. Let me know how it works.
(Seems to work just fine for NES Says. And the slowdown isn't that noticeable.)
-
WIll the slow down occur when storing stuff to the screen only or when storing stuff to the graph buffer and screen? If it's the former and Raylin won't update the screen that often, I guess it should be fine.
-
The mentioned slowdown should only occur each time the contents of the screen buffer is displayed.
EDIT: Link to post containing something that could be of help (http://ourl.ca/6048/94374) provided for your convenience.
-
Ok thanks for the info and I hope that program works well for Raylin needs :)
-
How would I use Celtic III for my needs...?
Wouldn't it screw up my xLIB commands?
-
How would I use Celtic III for my needs...?
Wouldn't it screw up my xLIB commands?
If Celtic III works as it should, it's as simple as replace, install, and forget. I would, however, encourage you to find out whether or not Celtic III will actually work for your needs, as xLIB compatibility isn't perfect.
-
It didn't help. D:
-
@calcdude84se: You said something about CalcSys's port monitor. Could you explain this process?
How would you edit the values of the port and make it work?
I'll repeat WikiTI. Port 29h will add a delay of so many clock cycles to any instructions involving the LCD, which is the port value divided by 4 (i.e. ignoring bits 0 and 1). See if it works when the port has different values (make sure bits 0 and 1 are 0 on an 83+SE, 1 on an 84+(SE)). So, start with 0F, then try 13, which you get by adding 4, then 17, 1B, 1F, 23, 27, 2B... And so on. What Brandon fears is that even when the port contains FF the delay (63 clock cycles) won't be enough. It's worth a try, though
-
@calcdude84se: You said something about CalcSys's port monitor. Could you explain this process?
How would you edit the values of the port and make it work?
I'll repeat WikiTI. Port 29h will add a delay of so many clock cycles to any instructions involving the LCD, which is the port value divided by 4 (i.e. ignoring bits 0 and 1). See if it works when the port has different values (make sure bits 0 and 1 are 0 on an 83+SE, 1 on an 84+(SE)). So, start with 0F, then try 13, which you get by adding 4, then 17, 1B, 1F, 23, 27, 2B... And so on. What Brandon fears is that even when the port contains FF the delay (63 clock cycles) won't be enough. It's worth a try, though
I don't think he actually knows how to change the value in the ports.
To change the ports, download Calcsys (http://www.ticalc.org/archives/files/fileinfo/97/9781.html). Send it to your calculator and run it. Then go to port moniter (3), and scroll until you find port 29h. Then press enter to change the value and do what calcdude84se said. The values are in hexadecimal.
-
Oh, that's what he wanted to know. Oops. Yeah, thepenguin77 is right. Btw, you can scroll 5 (I think that's about right) ports at a time by pressing left and right rather than up and down.
-
Thank you so much, guys!
-
Tell us if it works out well :)
-
It did!
WOOO!
THANKS AGAIN!
-
wow great to hear!
-
Nice to hear that it works. Glad to help! Though it might not be useful, what's the smallest value for port 29h that worked?