I've further optimized that grayscale command and its basically the same size as my original now except way faster which is excellent.

Cool to hear I can't wait to see the difference

Now I wonder how easy it would be to make a grayscale version of the 3D racing game that comes with Axe

calc83manic

You downgraded calc84maniac to 6 MHz hardware

Quote from: DJ Omnimaga on June 09, 2010, 11:41:29 pm

Quote from: Quigibo on June 09, 2010, 09:59:04 pm

calc83manic

You downgraded calc84maniac to 6 MHz hardware

He also downgraded him to having a mood disorder.

oh crap I didn't notice . I hope he still finishes all his projects including the 8 level grayscale raycaster *runs*

Maybe you could use ixl/ixh to avoid the shadow reg? It is 9 clocks for ld iirc tho :S.

LOL you guys.

Quote from: tr1p1ea on June 10, 2010, 08:41:26 am

Maybe you could use ixl/ixh to avoid the shadow reg? It is 9 clocks for ld iirc tho :S.

Aren't those incompatible with the Nspire, though? Or am I confusing them?

I'm pretty sure they're not compatible, since they are undocumented.

*bump* (excuse the double post, I didn't really read this before)

Quote from: calc84maniac on June 09, 2010, 01:16:54 am

Hmm, remember when I suggested you could use IX as a pointer to the variables for easier access when doing 8-bit operations? That would be too much of a hassle, we agreed. But what if you moved the variables to the END of savesscreen? Then they would be within the range of the IY register (which points 4 bytes after the end of savesscreen). Just something to consider

Hmm... interesting proposition.  Although it would optimize some operations like addition and subtraction, there is still one key advantage to using the existing variable slots.  By using only the least significant bytes of those variables, you never need to do "conversions" when you switch from word to byte mode.  You have to get input and output somehow otherwise there's not much advantage to the new mode.  By being able to skip the conversions, I think that will save more memory in the long run than by using the iy or ix registers.

What are these "conversions" you are talking about, and why are they affected by using the IY register? You can keep using normal memory loads/stores as much as you want, IY is just a bonus optimization (especially once you add 8-bit math mode). I'd imagine being able to directly add, subtract, and, or, xor variables in only 3 bytes is worth moving the variables to the end of the buffer.

Here is a speed optimization for the length() command (the size turned out to be the same):
xor a
ld b,a
ld c,a
cpir
ld hl,-1
sbc hl,bc

Oh, how I love to bump this thread!

I'm thinking it would be neat for the commands that return booleans to not always have to calculate the 0 or 1 value directly. I was thinking instead that the command will set an internal compiler variable that tells which condition code to use. Then, the following command can either optimize according to the condition or otherwise generate a 0 or 1 as usual.

The most common application for this is the If statement. Take, for example, If A=5:
  ld hl,(var_a)
  ld de,5
  or a
  sbc hl,de
  ;The Z condition code is set to correspond to 1
  jp nz,end
Or how about B<10+A->A:
  ld hl,(var_b)
  ld de,-10
  add hl,de
  ;The NC condition code is set to correspond to 1
  ld hl,(var_a)
  jp c,no_inc
  inc hl
no_inc:
I imagine the "=0" command, when applied while condition code is active, will invert the condition variable and generate no code.

And... I guess that is all for now. Good day!

A≠5 and (B≠6) would be something like:
  ld hl,(var_a)
  ld de,5
  or a
  sbc hl,de
  ;The NZ condition code is set to correspond to 1
  ld hl,1
  jp nz,_
  ld hl,(var_b)
  ld de,6
  or a
  sbc hl,de
  ;The NZ condition code is set to correspond to 1
  ld hl,1
  jr nz,_
  dec hl
_