How about a way to send a byte directly to the LCD?

<-----noob here.

Can someone explain to me what an Axiom is?

Thanks!
-Zippy Dee

I don't really even understand how the signing works, so I don't really get what would have to be done to sign an app on calc. Why would anything ever need to use 512 bit numbers except for high decimal precision?

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 :\

No problem! You can use the GetPixel routine for drawing vertical lines pretty easily, too.

Vertical lines:
   ; Inputs:
    ;     D is the x-coordinate, L is the starting y-coordinate and E is the ending y-coordinate
    ;        make sure L is less than E, otherwise it'll go KABLOOIE!! or something...

    ld a, e
    sub l    ; get the length of the line by subtracting L from E
    ret z    ; if the length is zero, we don't need to draw it, so just return
    push af    ; save the length of the line into the stack so we don't lose it

    ld a, d    ; put the x-coordinate in A
    call GetPixel    ; now A is the mask that we'll just use for all the rows and HL is the address of the starting byte for the line

    pop BC    ; we pushed AF before, so now we pop to BC, so now B is the line length
    ld de, 12
    ld c, a    ; save the bitmask to C so we don't lose it
_vloop:
    ld a, c    ; restore the mask
    or (hl)    ; turn the pixel on
    ld (hl), a
    add hl, de    ; each row is 12 bytes, so to go to the next row we can just add 12 (which we stored in DE) to HL
    djnz _vloop
    ret
You could potentially just loop GetPixel for each point in horizontal lines, too, but because the bytes group pixels horizontally, there are more efficient ways to do it.
Unfortunately, I don't have a tested horizontal line routine, and I don't know that I'm good enough to really write an efficient one myself yet without doing tests first.

Anyway, hope this helped even more!
-Zippy Dee


EDIT: I wrote out this routine just now, haven't tested it, but it should work. Maybe someone else can confirm. I'm not guaranteeing 100% efficiency, but it should be fine for almost all cases.

    ; Inputs:
    ;     L =is the y-coordinate, D is the starting x-coordinate and E is the ending x-coordinate
    ;         again, make sure D is less than E

    ld a, e    ; get length, return if 0
    sub d
    ret z

    srl a    ; divide line length by 8 to find the number of bytes this line will span across (minus 1)
    srl a
    srl a
    push af    ; save it for later

    ld h, 0    ; get the address of the byte containing the first pixel of the line
    ld b, h    ; same code as in GetPixel, just using BC instead of DE because DE is currently occupied by our precious x-coordinates
    ld c, l
    add hl, hl
    add hl, bc
    add hl, hl
    add hl, hl
    ld c, d
    srl c
    srl c
    srl c
    add hl, bc
    ld bc, PlotSScreen
    add hl, bc    ; now hl is the starting byte of the line
   
    call GetMask    ;get the mask for the left end of the line
    pop bc    ; length of the line goes into b
    ld c, a    ; save the mask to c
    ld a, b
    or a    ; if b is 0, mask the end of the line as well
    jr z, _lastbyte
    ld a, c

_hloop:
    or (hl)    ; apply the mask
    ld (hl), a
    inc hl
    ld a, $FF    ; after the first byte, the other bytes (except the last) will be masked with $FF so all pixels are turned on
    djnz _hloop

_lastbyte:
    ld d, e
    dec d
    call GetMask    ; get the mask for the right end of the line
    srl a    ; because GetMask gives us the mask for the left end, we shift it one to the left and invert it to get the mask for the right end
    cpl
    and c    ; get the similar bits between the previous mask and the current one (remember that if the length is less than 8, the masks for both the left and right ends have to be applied to the same byte)
    or (hl)    ; now we apply the mask
    ld (hl), a
    ret    ; and we're done!
   
GetMask:
    ; this is also the same idea as getting the mask in GetPixel, only instead of rotating $80 we do a logical shift right on $FF to retrieve the mask for the ends of the line
    ld a, d
    and 7
    ld b, a
    ld a, $FF
    ret z
_maskloop:
    sra a
    djnz _maskloop:
    ret

I'm assuming you mean without using the built in ROM calls? Manipulating pixels is fairly straightforward. Drawing lines, however, is not. In order to draw lines without the use of b_calls you'll have to write an algorithm in assembly to do that yourself. I'd suggest Bresenham's line algorithm for that. I'm fairly new to ASM myself, so I don't think I could easily do or explain how to do that. Pixels, on the other hand, I can do.

Here's an explanation for manipulating pixels for the graph buffer (not directly plotting to the LCD):


Because of the nature of monochrome graphics, instead of representing each pixel with one or more bytes, each byte represents 8 pixels: one pixel for each bit. So in order to manipulate a specific pixel, you have to first find two things: The byte that contains the pixel, and which bit in that byte represents the pixel.

Getting the pixel:
GetPixel:
    ; Inputs:
    ;   A = x-coordinate, L = y-coordinate
    ; Outputs:
    ;   A = a bitmask for the pixel, HL = the address of the byte containing the pixel

    ld h, 0
    ld d, h
    ld e, l
    add hl, hl    ; the graph screen is arranged as an array of 12 x 64 bytes (12 bytes per row, 64 rows)
    add hl, de   ; so in order to find the correct byte we first multiply the y coordinate by 12...
    add hl, hl
    add hl, hl

    ld e, a    ; ...then add the x-coordinate/8 (because there are 8 pixels per byte)
    srl e
    srl e
    srl e
    add hl, de

    ld de, PlotSScreen
    add hl, de    ; now hl contains the address of the byte

    and 7    ; this is the tricky part: finding the bit. Because there are 8 bits in each byte, we can do x-coordinate modulo 8
    ld b, a    ; and that will return a number (0-7). That number tells us which bit to use (where "7" represents bit 0, and "0" represents bit 7)

    ld a, $80    ; here we load the initial bitmask into A
    ret z    ; if the "and 7" command returned 0, then the mask doesn't need to be rotated, so we can just return now.

_loop:
    rrca    ; otherwise, rotate the bitmask B times (remember we loaded the result of "and 7" into B earlier)
    djnz _loop
    ret

Turning a pixel on:
   call GetPixel
    or (hl)    ; HL holds the byte, and A holds the mask, so we simply use or to turn on the masked pixel...
    ld (hl), a ;...then load it into the buffer
Inverting a pixel:
   call GetPixel
    xor (hl)    ; Same idea as before only using xor to invert
    ld (hl), a
Turning a pixel off:
   call GetPixel
    cpl    ; because AND clears any pixels that are already set, you have to invert the mask first
    and (hl)
    ld (hl), a
NOTE: These only plot pixels in the graph buffer. You have to update the display before they will actually show up. Easiest way is just with B_CALL(_GrBufCpy), or you could write a custom routine, but that's a bit harder.


Hope this helped!
-Zippy Dee

EDIT: Bresenham's line algorithm: http://en.wikipedia.org/wiki/Bresenham's_line_algorithm

Yeah, that's a fairly straightforward compression technique, but if you have more than 15 of the same tile in a row, you have to break it up into multiple bytes, but that's still better than it would be without compression. Even so, how do you store the data as an appvar without it adding to the size of your program? Or does axe write to appvars when compiling?