I doubt if this will help, but Michael_Lee made a routine to do this in Axe: http://ourl.ca/4129/186296

Sadly, I don't understand Asm well and can't help you, but hopefully someone else will stumble over this thread who can help.  Good luck!

Blasphemy!  People spelled my name incorrectly, twice!

I don't know any asm at all, so I'm of even less help, but I can point you to a webpage I found which provided the algorithm I adapted: http://freespace.virgin.net/hugo.elias/graphics/x_bezier.htm

I spelt it wrong because I was copying it from ztrumpet

* Hides *

First off, I love how this is structured, nested loops are so cool and clever. But it's amazing that such a small mistake can cause the entire program to fail.

You had:
ld h, a
ld l, 0
You wanted:
ld h, 0
ld l, a
Down in your problem area. By putting time in l, then reading it from h, you are essentially dividing it by 256. I attached a file with some edits I made to it, it works fine with just that little change, but these are just some things to help you. For instance, I think it just looks better to render from left to right, but that might just be me.

The lines don't come out that pretty because you are getting some serious rounding issues (11 rounds per pixel), so I would suggest making all of your number .256 decimal, but of course that requires a complete rewrite. I'll see if I can give you an example so you can see what it would look like.

And lastly, you can get some serious speed improvements by using a custom GrBufCpy, or even better yet, only plot the current byte in the LCD driver, but that's a bit advanced.

I swear I tried that. I tried putting time in H and L and I tried both multiplying and dividing (which is why I had both Div_HL_D and HL_Times_D there). Oh well, thank you so much! And thanks for all the comments and for that other example (which is obviously 10,000,000,000 times better than mine, and way over my head)!

Can you explain what you mean about making all the numbers .256 decimal? You mean like fixed-point numbers? I was going to try to make it fixed-point, but all the scaling that's involved for the multiplication confused me, so I gave up. I also was going to try to make it write to the LCD, but I figured it's probably best to get one that just WORKS before trying to get too fancy (Well, what an ASM noob like me considers fancy).

Thanks for all your help! I'm really trying to learn to navigate ASM, and this alone has been very enlightening. It's always the small things that get you.

Sorry for the over your head stuff, lately I've been tending to write pretty cryptic code for optimizations. Like using a loop to do x then y, but that's just easier for me I guess.

When I say .256 decimal, I mean fixed point decimal, but in a very specific way. First you take your typical 1 byte value, and place it in the high byte of a two byte number. The lower byte of that two byte is now its decimal place. So just treat it like a two byte number, and when the time comes to see what the value is, only read the upper byte.

As for updating the LCD, that example right there is a clean as it gets (I love DWAIT.) Just make sure that you grab the byte from the buffer, or else you will overwrite the old bits with white.

Well, that's technically a yes. But in all reality, it doesn't matter at all. The only time it matters is when you are sending commands 4-7 which set the way the driver moves after each write (up, down, left, right). But at least on wikiTI it says both the x/y and the vertical/horizontal, so you don't have to worry about it.

Also, it's pretty easy to remember that the columns start at $20 and the rows start at $80. Those are the two numbers you'll need if you write a graphBufferCopy routine.