If you have pieces, I'd love to see them. Although they need to fit in 8x8 squares.

Hey, there should be an update for this coming pretty soon. I just got finished adding in the ability for AI to see if a piece is unprotected.

After I put some check checks in castling and fix the new problems created by ^^ (putting king in check is now the greatest move ever), you'll have a new version.

Nobody's given a diagonal line routine yet This one comes from Missile.

You need to define (increment) somewhere. I believe you also need a getpixel that takes de = xy for input and doesn't destroy anything.


;###############################
;input: de = xy
; hl = xy

line:
push hl
push de
ld b, 2
fastLinePreLoop:
ld a, d
call xClipCheck
ld d, a
ld a, e
call yClipCheck
ld e, a
ex de, hl
djnz fastLinePreLoop

or a
sbc hl, de
add hl, de
jr nc, noSwitch
ex de, hl
noSwitch:

ld a, h
sub d
ld b, a
ld a, l
sub e
ld c, 0
jp p, positivoz
neg
ld c, 1
positivoz:
cp b
jr nc, yMajor

xMajor:
inc b
ld h, a
ld a, b

call setUpForLoop
bit 0, c
jr z, notNeggaz
inc h
notNeggaz:
ld c, d



xMajorLoop:
push bc
ld de, (increment)
add hl, de
push hl
ld d, c
ld e, h
call getPixel

ld a, c
call middlePartOfLoop

pop hl
pop bc
inc c
djnz xMajorLoop

pop de
pop hl
ret




yMajor:
bit 0, c
jr z, alreadySetUp
ex de, hl
alreadySetUp:

inc a
ld h, b
ld b, a

call setUpForLoop

bit 0, c
jr z, notNegga
inc d
notNegga:
ld c, h
ld h, d

yMajorLoop:
push bc
ld de, (increment)
add hl, de
push hl
ld e, c
ld d, h
ld b, h
call getPixel

ld a, b
call middlePartOfLoop

pop hl
pop bc
inc c
djnz yMajorLoop

pop de
pop hl
ret









middlePartOfLoop:
ld c, 128
and %00000111
jr z, alreadyDone
ld b, a
byteLoop:
srl c
djnz byteLoop
alreadyDone:
ld a, c
or (hl)
ld (hl), a
ret


setUpForLoop:
ld l, $FF
push de
push bc
call divHLbyA
pop bc
bit 0, c
call nz, negHL
ld (increment), hl
pop hl
ld d, h
ld h, l
ld l, 0
ret


yClipCheck: ;super efficient, no rets
call isANeg
cp 64
ret c
ld a, 63
xClipCheck:
call isANeg
cp 96
ret c
ld a, 95
isANeg:
or a
ret p
xor a
ret



Just as a small spot of randomness, I have been working on a .TAB thing for TASM in case I ever get around to manually converting my programs to mnemonics... is it bad practice if I do things like making ld hl,bc or if I change FE00 to B7 and whatnot? I've always thought it would make source codes much easier to read with things like:

ld hl,a   (loads a into l and h=0)
ld hl,bc
cp hl,bc
ld bc,(hl)

And other random things like that I just define them in the actual .TAB file...

Xeda, I wouldn't do that. It makes things slightly easier, but it causes way more problems than it fixes. For one, while those look like 1 or 2 byte instructions, ld bc, (hl) is 4 bytes long. Sometimes you will have optimized ways to do those routines, for instance if h is already 0. And the main problem with this is that it will make your code incompatible with other people.

Plus, it's not much harder to just write ld h, 0 \ ld l, a and that way you know what is really going on.

I was bored, so here is that demo I talked about. It uses 256 point decimal, which is great for physics applications.

It is also commented for clarity.

Here it is. This will turn the calculator off properly with no memory leaks, the only downside is it's a little big.

Asm(21 E1 E5 22 72 98 3E C9 32 74 98 CD 72 98 11 0F 00 19 11 72 98 01 10 00 ED B0 C3 72 98 EF F1 42 EB 5E 23 56 21 95 9D EF 57 43 EF 08 50)

Put the name of your program in OP1 and run this, it deallocates your program and turns the calculator off. Needless to say, you should not run this from within Mirage.

ld hl, $E5E1 ;pop hl, push hl
ld (appBackUpScreen), hl
ld a, $C9
ld (appBackUpScreen+2), a
call appBackUpScreen ;we have to get a pointer to the runner
sizeToAdd:
ld de, sizeToAddEnd-sizeToAdd
add hl, de
ld de, appBackUpScreen
ld bc, runnerEnd-runnerStart
ldir
jp appBackUpScreen
sizeToAddEnd:

runnerStart:
bcall(_chkFindSym)
ex de, hl
ld e, (hl) ;grab its size
inc hl
ld d, (hl)
ld hl, $9D95
bcall(_delMem)

bcall(_powerOff) ;that's pretty nifty, I just found this

runnerEnd:

Edit:
    I don't know much about axe, but if you can get a pointer to the start of this routine, I can make it substantially smaller.

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.

Great website. So much easier than using photobucket or the like.