That's really neat!  Great job calc84!

Um well first question, (even though i'm not going to end up writing this routine ) what should the output be in since we don't have floating point?

Does anyone know any good sin/cos routines that are under 128 bytes?  The entire circle should be 256 brads (binary radians) so each quadrant is 64.  It doesn't need to be 100% accurate, but it should be pretty close.  It doesn't need to be that fast either, but I would prefer using a method that doesn't need multiplication such as a look up table or CORDIC.

I think yes. It was made by Will West but I couldn't find the original post in Revsoft so I add as attach.

see: "Sin_A   parabolic approximation of sin(a) a is in units of pi/256"

Your 4-level grayscale routine is pretty unoptimized, and it doesn't even use the right dither pattern (1/3 and 2/3). I figured I could help out here. This is about as fast as it gets (with your double-buffer layout). The small size cost is worth it in this case, I think.
DispGraphRR:
di
ld a,$80
out ($10),a
ld (save_sp),sp
ld l,plotSScreen&$ff - 1
ld de,appbackupscreen - plotSScreen
ld sp,plotSScreen - appbackupscreen + 12
ld c,$1f
dec (iy+asmflags2)
jr nz,gray4skip
ld (iy+asmflags2),3
jr gray4entry3
gray4skip:
ld a,(flags+asmflags2)
dec a
jr z,gray4entry2

gray4entry1:
ld h,plotSScreen >> 8
inc l
ld b,64
inc c
ld a,c
cp $2c
jr z,gray4end
out ($10),a

gray4loop1:
ld a,(hl)
add hl,de
xor (hl)
and %11011011
xor (hl)
add hl,sp
out ($11),a
djnz gray4loop2

gray4entry2:
ld h,plotSScreen >> 8
inc l
ld b,64
inc c
ld a,c
cp $2c
jr z,gray4end
out ($10),a

gray4loop2:
ld a,(hl)
add hl,de
xor (hl)
and %01101101
xor (hl)
add hl,sp
out ($11),a
djnz gray4loop3

gray4entry3:
ld h,plotSScreen >> 8
inc l
ld b,64
inc c
ld a,c
cp $2c
jr z,gray4end
out ($10),a

gray4loop3:
ld a,(hl)
add hl,de
xor (hl)
and %10110110
xor (hl)
add hl,sp
out ($11),a
djnz gray4loop1
jr gray4entry1

gray4end:
ld sp,(save_sp)
ei
ret
Edit: Some misnamed/missing labels

Thanks!  Although that looks much larger than my current routine, I'll have to see if the improvement in speed/quality is significant enough to justify the size increase.  I'll do some more testing this week.

Yeah, I think it will be worth the size increase.  Its a 46 byte increase, but it has the added bonus that it doesn't need to be initialized with a separate command (after I modify this routine).  Also, I think there are a few places I can optimize to save on memory, but still not hinder the speed.

EDIT: Actually that code is pretty rock solid optimized, there were only a couple places I made improvements.

In the entry points, its better if the instructions are in this order:
ld a,c
cp $2c
jr z,__Disp4LvlDone
ld h,plotSScreen >> 8
inc l
ld b,64
inc c
out ($10),a
Because this way, it jumps out of the loop sooner when it gets to the end of the routine.  Not that big of a deal, but it saves several clock cycles each render.

Also, the jump table I changed to this:
inc (iy+asm_flag2)
jr z,__Disp4Lvlentry3
ld a,(flags+asm_flag2)
inc a
jr z,__Disp4Lvlentry2
ld (iy+asm_flag2),-2So that you don't need to initialize the byte that keeps track of gray layer since it falls through if the number was uninitialized.

Thanks again!  This does look a lot better  

Actually, I just tried this on hardware, and its too fast for even 6MHz.  But not to worry, I can group some of it into a subroutine to both add the needed delay and reduce the size of the code at the same time.