I started the documentation and I am not sure if I have forgotten anything. About the header stuff, I thought that I would add an on-calc utility for adding a header to a file. I had issues with trying to get an assembler to work properly (because you need to do '.org 0' after the header). I still haven't added anything to Jade since the last update except code to let you press ON to turn Jade off.
A few other things that I was thinking about adding: For the sprites, if you add 4 to the sprite method, then the first byte of the sprite data indicates the height of the sprite. In the Pong example, I currently use the same sprite twice for each paddle to make it 16 units long (so the same sprite is drawn 4 times to different locations). As well, the ball only needs to be 4 bytes instead of 8 (though it could be compressed to 2 bytes).
Type 8 can instead draw a string as opposed to a sprite. It feels like cheating, but haven't other systems done this? Type 9 can draw a 16-bit signed number Type 10 can draw an inverted rectangle Type 11 can draw a filled rectangle Type 12 can draw a white rectangle
Yay, double posting. I found two bugs in Jade. The first made several commands work incorrectly: cpa() cpc() suba() subc() sbca() sbcc()
And the second one prevented the c flag from being set (I used rlc instead of rl). So I have those fixed, and I started Pong. Click the screenie for the download The code for that is precisely 200 bytes and the code is:
Start: ldirc(sLSB0,25) .dw $100+ball \ .db 3,3,2 ;load the sprite data for Sprite0. The 2 is for XOR logic. .dw $100+paddle \ .db 0,24,2 ;load the sprite data for Sprite1. The 2 is for XOR logic. .dw $100+paddle \ .db 0,32,2 ;load the sprite data for Sprite2. The 2 is for XOR logic. .dw $100+paddle \ .db 94,24,2 ;load the sprite data for Sprite3. The 2 is for XOR logic. .dw $100+paddle \ .db 94,32,2 ;load the sprite data for Sprite4. The 2 is for XOR logic. ldirc(keyMask,2) .db %00010110,31 ;the second byte is for sMask (the sprite mask) ldc(ballxinc,1) ldc(ballyinc,1) Loop: orc(status,2) ;tell the status port to draw the sprites orc(status,3) ;tell the status port to update the LCD, then draw the sprites KeyLoop: bits(key1,40h) ;check for the Clear key being pressed orcz(status,80h) ;sets bit 7 of the status port if the z flag is set. This turns off Jade. bits(key2,2) ;check if player 2 down key is being pressed togz() jrfz(TestP2Up) cpc(sY3,48) jrfz(TestP2Up) addc(sY3,2) addc(sY4,2) TestP2Up: bits(key2,8) ;check if player 2 down key is being pressed togz() jrfz(TestP1Down) cpc(sY3,0) jrfz(TestP1Down) subc(sY3,2) subc(sY4,2) TestP1Down: bits(key4,2) ;check if player 2 down key is being pressed togz() jrfz(TestP1Up) cpc(sY1,48) jrfz(TestP1Up) addc(sY1,2) addc(sY2,2) TestP1Up: bits(key4,8) ;check if player 2 down key is being pressed togz() jrfz(MoveBall) cpc(sY1,0) jrfz(MoveBall) subc(sY1,2) subc(sY2,2) MoveBall: adda(sX0,ballxinc) callfz(TestP1Collision) cpc(sX0,89) callfz(TestP2Collision) adda(sY0,ballyinc) jrfz(NegYinc) cpc(sY0,60) togz() jrbz(Loop) NegYinc: inv(ballyinc) inc(ballyinc) jrb(loop)
ball: .db 18h .db 24h .db 24h .db 18h .db 0,0,0,0 paddle: .db $C0 .db $C0 .db $C0 .db $C0 .db $C0 .db $C0 .db $C0 .db $C0 Use [3] and [9] to move the paddle of player 2 and [1] and [7] for Player 1. [Clear] exits. EDIT: I was trying to write an oncalc compiler thing for Jade earlier when I remembered about this project: ASMDREAM So after an hour of working on a compiler I decided to instead incorporate ASMDream's system using macros and it works! All of the instructions and equates have been made except for one area-- the header. What sort of header should I use for Jade files? I was thinking there could be several types of files: ROMs ROM packs (multiple ROMs in one file) Save states So I thought headers might consist of:
1 byte for the file info and type bit 0:1 for the type bit 2 for the save state size (128 bytes or 256) bit 3 set if there is a description bit 4 set if there is an icon 1 bytes for the name length n bytes for the name 2 bytes for the miscellaneous data size n bytes for miscellaneous data such as description and icon 2 bytes for the ROM size n bytes for ROM data
Hopefully this is will make it easier for people to code for Jade
I totally rewrote the sprite drawing routine and now there are only three methods of drawing sprites On the other hand, I fixed clipping and made it faster. Currently Jade has the instruction set working (or it appears to be working), but I cannot figure out why the LCD is being updated when it shouldn't be, so I am probably going to make Jade update all sprites at once, if bit 1 of the status port is set. That will just make it easier and smaller to code with sprites. As it is, here is a current screenshot
EDIT: Well that was quick o.o I have it working now the way it was supposed to. Compare the first screenshot to the second And now here is a download. The code in the new screenshot is:
#include 'Jade.inc' .org $00 jrf(start) sprite: .db %00111100 .db %01100110 .db %11000011 .db %11100111 .db $FF .db $FF .db $FF .db $FF start: ldirc(sLSB0,5) .dw $100+sprite \ .db 0,0,2 ldirc(keyMask,2) .db 3,1 ; Loop: orc(status,2) ;set bit 1 of the status port to draw the sprites orc(status,3) ;set bit 0 and 1 of the status port to update the LCD, then redraw the sprites KeyLoop: cpc(key1,jkClear) ;Check if clear is pressed ldcz(status,$80) ;Turn off Jade if the z flag is set by writing 80h to the status port cpc(key0,-1) ;test if no keys are being pressed jrbz(KeyLoop)
cpc(key0,jkDown) incz(sY0) cpc(key0,jkUp) decz(sY0) cpc(key0,jkLeft) incz(sX0) cpc(key0,jkRight) decz(sX0) jrb(Loop) Now I need to try to document everything .__.
I only worked my way up to 194 digis. On the other hand, I can commit strings of numbers to memory in a few minutes. I haven't reached my limit yet, but when I was trying to memorise more digits of pi, it took me a few minutes (about 5) to commit a 48 digit chunk to memory and then I went to the next chunk If you do the math, you will see that that amounts to 4 chunks plus a few digits. Only the first three chunks have stuck, though, and it has been a few months since I have tried to memorise it. My goal was to have 10000 memorised by now, but school got in the way .__. I made a program to quiz me and it has 1000 digits
It is fine Also, be careful as a TI-83 Program is a little different from a TI-83 Plus program. The former is stored as .83p and the latter as .8xp. If it was programmed on a TI-83, then you want .83p and if it was programmed on a TI-83+ or 84+, you will want it saved as .8xp.
SourceCoder lets you edit programs and whatnot on the computer and then save them as .8xp files, among other things. You don't need to download anything to use it.
Also, we encourage editing posts as opposed to double posting (unless of course it has been a while since the last post).
I am not sure if there will be a problem with it. I don't think Source Coder will be able to open it. If it could, I would say you could open it with Source Coder and then resave it as .8xp. I don't know if simply changing the extension will work.
EDIT3: (continued below) Smaller, faster version below. I wanted to optimise an old routine in Grammer to compute the GCD of two 16-bit numbers. I came up with this:
GCDDE_HL: ;Inputs: ; HL,DE are the two values ;Outputs: ; B is 0 ; DE is 0 ; HL is the GCD ; C is not changed ;Destroys: ; A xor a ;AF 4 ld b,a ;47 4 CheckMax: ; sbc hl,de ;ED52 15n jr z,AdjustGCD ;28** 12n-5 jr nc,ParityCheck ;30** 12n-5 xor a ;AF 4(n-a) sub l ;95 4(n-a) ld l,a ;6F 4(n-a) sbc a,a ;9F 4(n-a) sub h ;94 4(n-a) ld h,a ;67 4(n-a) ex de,hl jp CheckMax ;C3**** 10(n-a) ParityCheck: ; bit 0,e ;CB** 8a jr nz,DE_Odd ;20** 12a-5b bit 0,l ;CB** 8b jr z,BothEven ;28** 12b-5c rr d ;CB** 8(n-a-b-c) rr e ;CB** 8(n-a-b-c) jp CheckMax ;C3**** 10(n-a-b-c) BothEven: ; inc b ;04 4c rr d \ rr e ; 16c rr h \ rr l ; 16c jp CheckMax ; 10c DE_Odd: ; bit 0,l ; 8b jr nz,BothOdd ; 12b-5d rr h \ rr l ; 16(n-a-b-d) jp CheckMax ; 10(n-a-b-d) BothOdd: ; sbc hl,de ; 15d rr h \ rr l ; 16d jp CheckMax ; 10d AdjustGCD: ; ex de,hl ; 4 inc b ; 4 dec b ; 4 ret z ; 11+4(k>0) add hl,hl ; 11k djnz $-1 ; 13k-5 ret ; -- It is a lot faster than my other version which used division to compute the mod of two 16-bit numbers The JP instructions can be changed to JR for better portability and to save a byte each time.
EDIT: And if I didn't make a mistake, the 8-bit version:
GCD_A_C: ;Outputs: ; A is the GCD ; C should be the smallest odd number that divides both inputs ; B is 0 ;Destroys: ; D ld b,1 CheckMax: sub c jr z,AdjustGCD jr nc,ParityCheck neg ld d,a ld a,c ld c,a jr CheckMax ParityCheck: rrc c jr c,c_Odd inc b rrca jr nc,CheckMax rlca djnz CheckMax c_Odd: rlc c rrca jr nc,CheckMax rlca jr CheckMax AdjustGCD: ld a,c dec b ret z add a,a djnz $-1 ret EDIT2: I think I computed a massive overestimate of the slowest speed of the first routine to be a little over 4000 cycles. My old routine used about 1500 cycles at the fastest for a non-trivial result. 1500 is likely close to the slowest that the new routine will run at EDIT3: 14 bytes saved, runs faster?
GCDDE_HL: ;Inputs: ; HL,DE are the two values ;Outputs: ; B is 0 ; DE is 0 ; HL is the GCD ; C is not changed ; A is not changed ld b,1 or a CheckMax: ; sbc hl,de ;ED52 15n jr z,AdjustGCD ;28** 12n-5 jr nc,ParityCheck ;30** 12n-5 add hl,de or a ex de,hl ParityCheck: ; bit 0,e ;CB** 8a jr nz,DE_Odd ;20** 12a-5b bit 0,l ;CB** 8b jr z,BothEven ;28** 12b-5c rr d ;CB** 8(n-a-b-c) rr e ;CB** 8(n-a-b-c) jp CheckMax ;C3**** 10(n-a-b-c) BothEven: ; inc b ;04 4c rr d \ rr e ; 16c HL_Even: rr h \ rr l ; 16c jp CheckMax ; 10c DE_Odd: ; bit 0,l ; 8b jr z,HL_Even ; 12b-5d sbc hl,de ; 15d rr h \ rr l ; 16d jp nz,CheckMax ; 10d AdjustGCD: ; ex de,hl ; 4 dec b ; 4 ret z ; 11+4(k>0) add hl,hl ; 11k djnz $-1 ; 13k-5 ret ; --
Wow, this seems awesome o.o I have a question because I think i misunderstood something. Is there an issue with pressing multiple keypresses at once? I have made programs that could take >4 simultaneous keypresses, so that could be a problem. This also made me wonder if your macros were able to support multiple key presses at once, because that could be useful.
Show Posts
On the other hand, I fixed clipping and made it faster. Currently Jade has the instruction set working (or it appears to be working), but I cannot figure out why the LCD is being updated when it shouldn't be, so I am probably going to make Jade update all sprites at once, if bit 1 of the status port is set. That will just make it easier and smaller to code with sprites. As it is, here is a current screenshot 
And now here is a download. The code in the new screenshot is:
If you do the math, you will see that that amounts to 4 chunks plus a few digits. Only the first three chunks have stuck, though, and it has been a few months since I have tried to memorise it. My goal was to have 10000 memorised by now, but school got in the way .__. I made a program to quiz me and it has 1000 digits 
Also, be careful as a TI-83 Program is a little different from a TI-83 Plus program. The former is stored as .83p and the latter as .8xp. If it was programmed on a TI-83, then you want .83p and if it was programmed on a TI-83+ or 84+, you will want it saved as .8xp.
The JP instructions can be changed to JR for better portability and to save a byte each time.