well with programming its either you have quicker programs but longer code or slower but easier to code programs but slower (little ironic in a way huh?). but i mean assembly definitely gives you more flexibility and if you are good with it and almost productive as a person in say c good for you! i on the other hand have to program in c i dabble in assembly but i dont have the patience. so i respect that and that sort of work and dedication.

Generally speaking. Of course, some people (like me) are freaks of nature and can't understand high level computer languages like C.* I'm not nearly as fast as thePenguin at ASM though. I don't think I've ever written 1000 lines in four hours in any language.

I've actually had to slow down more programs than I've had to speed up, though. Not sure if too many languages other than Hex and ASM have the problem :p

I don't think I've ever written 1000 lines in four hours in any language.

I think I've only ever wrote more than 1000 lines of code once, on Exodus (and to get that I had to add the lines of Exodus with the lines from its level editor).  

I never had the time to read this until now, but it's an incredible tutorial.  Thanks, Brian!

Quote from: ztrumpet on March 13, 2011, 12:09:15 pm

Quote from: Qwerty.55 on March 10, 2011, 07:38:34 pm

I don't think I've ever written 1000 lines in four hours in any language.

I think I've only ever wrote more than 1000 lines of code once, on Exodus (and to get that I had to add the lines of Exodus with the lines from its level editor).   

Back when I had time to kill I made >2000-line programs in a single sitting, deleted them immediately, and recoded them again. If only I had that kind of time right now

....................That's just insane. I have a BASIC program I wrote a few years ago that's 5k+ bytes, but I'm not sure how many lines. It was a calculator version of the game Sim Cinema, a surprisingly awesome game that only ever came out for Mac...even worse, for OS9X so the newer Macs can't even run it :\

This is an excellent tutorial, and it certainly helped me make MY grayscale flickerless

This is for Asm coders, and would be next to impossible to implement properly with Axe, even as an axiom.

Tho afaict the general theory is this:
Basically to get rid of the flickering you write to the screen (in Axe that's what DispGraph does) at the same rate that the physical screen displays what's written to it.  It's around 60 times a second, but it varies from calc to calc.
You can kind of do this in Axe by putting a Pause 40 or something like that if there's nothing else but DispGraph^* in the loop, but don't expect it to be perfect

How would I use interrupts to make greyscale more flickerless in Axe?

What does Dispgraph^*

What needs to be changed that it works on a TI83Plus? There's no fast mode and I'm not sure about the $83 ram page, could you explain that?

You'll have a great deal of trouble get perfect grayscale on an 83+BE in the true sense with this method because there are several things at work against you.
1. Without fast mode, you're going to have to make a very optimized routine, this is totally possible
2. You don't need the extra ram page, it just makes things much cleaner for my grayscale routine. Writing your own routine would allow you to use whatever ram you want, (probably two $300 byte buffers) but if you insist on using mine, you can clear out the first $600 bytes of ram through some hackery (though, TI-OS won't work in this state.)
3. Finally, probably the one that really strikes down this method, is the fact that the 83+ does not have crystal timers. The best you could do on it (if you plan to do things besides display pictures) is to use the regular interrupts which default run at 118Hz. For very specific cases, you could use every other interrupt for grayscale, but this will only work at a screen refresh of exactly 59Hz. Most likely, you're going to want to go with the interrupts running at 560Hz. Using this method, you'd have to use variable skips and delays to ensure the grayscale draws occur at the proper time. This is possible with enough thought, but it would be very difficult.
(4). Combining problems 1 and 3, anything that runs with perfect grayscale is going to run very slow. The step 3 delay design is going to burn a lot of t-states waiting for the proper time to go. Then, since it's only running in 6Mhz mode, you can get way less done when the actual program is running.

So, verdict. Possible - in theory. Difficulty - high. To give you an idea, this ranks up there with calc84's sound routines in ti-boy.