Author Topic: Jade (Read 21047 times)

Xeda112358 · « **Reply #15 on:** March 02, 2013, 07:47:17 am »

Ooh, maybe I will have time today to continue with the assembly version. It actually reads the code in compressed hex form and parses it that way, so if I do not make an editor, it might be a pain to program. Another neat application of this project that I thought about was to create a different CPU and port system with only 256 bytes to work with in all and an even more simple instruction set. Because it cannot damage the calculator, you can fill the code with random data and see what happens. The ports could be for returning how close the nearest pixel is in a given direction and for incrementing an X and Y coordinate. Because it is 256 bytes, you can fit a good number of CPUs in RAM and you can make them all run in parallel and see if they interact on screen. We could set some conditions for survival, death, and procreation, and see if they create anything semi-intelligent

TIfanx1999 · « **Reply #16 on:** March 02, 2013, 09:19:40 am »

That sounds like a game builderboy was describing once. IIRC he ported it to axe (from PC maybe???). I can't recall the name of it at the moment.

Xeda112358 · « **Reply #17 on:** March 02, 2013, 09:28:23 am »

Haha, that does sound like something he would do o.o It is like a complicated cellular automata. Actually, if I do figure out something that works, I might have to use this for a talk that I should be giving about the subject.

As an update, I am about to run the code through ORG to see how many mistakes I have made with it. If no mistakes have been made, then I have completed the assembly version emulating the instruction set and I will need to add in ports (which should be rather trivial).

TIfanx1999 · « **Reply #18 on:** March 02, 2013, 09:45:44 am »

<a href=http://ourl.ca/15370/288050>Here's</a> Builderboy's game that I was talking about.

Xeda112358 · « **Reply #19 on:** March 02, 2013, 10:33:26 am »

That looks awesome and is definitely pretty close to what I was talking about. I was more going for what genetic algorithms are, I think. So basically, the computer tries out different types of code to achieve a task and the 'organisms' interact with each other using their 'genetic' code. With the idea that the best suited for the task will survive, you should eventually get a fairly well coded routine for your task. I think this process has been proposed for creating quantum algorithms.

Also, finally some content! I haven't added in any of the ports, so you cannot exit Jade yet and you cannot see what is going on with the sprites, but the instructions appear to be working. There could be issues I haven't caught yet, but the source code is below. It is currently pretty ugly and not very optimised, but I will worry about that later. If you use the code from the previous routine, it will do what it is supposed to do, too. (Set up the keymask port and spritemask port and then set up the first two sets of sprite ports, then enter an infinite loop).

As a note, I haven't documented the hex codes for all of the jumps and calls yet.

Spoiler For Source:

#include "ti83plus.inc" #include "Jade.inc" #define progStart $9D95 .org progStart-2 .db $BB,$6D bcall(_RclAns) sub 4 ret nz ex de,hl ld c,(hl) inc hl ld b,(hl) inc hl ld de,OP1 ldir ld (de),a bcall(_ChkFindSym) ret c ld ix,saveSScreen ld bc,0 ld hl,saveSScreen ld (hl),c inc hl djnz $-2 ex de,hl ld b,2 inc hl inc hl ldir ;now all of the ports and RAM are loaded ld ix,saveSScreen+128 MainLoop: ld hl,MainLoop push hl call GetInc ld a,%00100000 and c jp z,CMD0 CMD1: bit 4,c push bc push af call GetInc pop af ld d,0 jr nz,$+8 ld e,c ld hl,saveSScreen add hl,de ld c,(hl) ld e,c pop bc ld a,15 and c jr z,callf+3 ;jrf dec a jr nz,$+6 ;jrf c bit 0,b jr nz,callf+3 dec a jr nz,$+6 ;jrf z bit 1,b jr nz,callf+3 dec a jr z,callb+3 ;jrb dec a jr nz,$+6 ;jrb c bit 0,b jr nz,callb+3 dec a jr nz,$+6 ;jrb 1 bit 1,b jr nz,callb+3 ;calls dec a jr nz,$+8 ;callf callf: call PushPC add hl,de jr SetPC dec a jr nz,$+6 ;callf c bit 0,b jr nz,callf dec a jr nz,$+6 ;callf 1 bit 1,b jr nz,callf dec a jr nz,is_callbc ;callb callb: call PushPC or a sbc hl,de SetPC: ld a,h and 1 ld h,a ld a,(PClow+1) and $FE or h ld h,a ld (PClow),hl ret is_callbc: dec a jr nz,$+6 ;callb c bit 0,b jr nz,callb dec a ret nz ;callb 1 bit 1,b jr nz,callb PushPC: ex de,hl push hl ;DE is the value to push call PushByte ld a,e ld e,d ld d,a call PushByte ld h,e ld l,d pop de ret PushByte: ;E is the value to push ld a,(stackptr) push af and 7Fh ld hl,stackbase add a,l ld l,a jr nz,$+3 inc h ld (hl),e pop af inc a ld (stackptr),a ret ;DE is offset ;HL = PC CMD0: ld a,c cp 12 jr nz,CheckRetC PopPC: call PopByte ld d,e call PopByte ld a,(PClow+1) and $FE or h ld h,a ld (PClow),hl ret PopByte: ld a,(stackptr) dec a and 7Fh ld (stackPtr),a ld hl,stackbase add a,l ld l,a jr nz,$+3 inc h ld e,(hl) ret CheckRetC: cp 13 jr nz,$+7 bit 0,b jr nz,PopPC ret cp 14 jr nz,$+7 bit 1,b jr nz,PopPC ret push af call GetInc ld a,c ld hl,saveSScreen add a,l ld l,a jr nc,$+3 inc h pop af push af push hl and 15 ld hl,MathLUT add a,a add a,l ld l,a jr nc,$+3 inc h ld e,(hl) inc hl ld d,(hl) pop hl ex de,hl pop af ;A has the main instruction ;DE points to the byte that the operation is on ; call JPHL ; jp MainLoop JPHL: jp (hl) instrLD: call GetNumOrAddr ld (hl),a ret instrADD: call GetNumOrAddr add a,(hl) SetFlags: ld (hl),a ld b,0 jr nz,$+4 inc b inc b ret nc inc b ret instrADC: call GetNumOrAddr rrc b rlc b adc a,(hl) jr SetFlags instrSUB: call GetNumOrAddr neg add a,(hl) ccf jr SetFlags instrSBC: call GetNumOrAddr neg rrc b rlc b adc a,(hl) ccf jr SetFlags instrXOR: call GetNumOrAddr xor (hl) jr SetFlags instrOR: call GetNumOrAddr or (hl) jr SetFlags instrAND: call GetNumOrAddr and (hl) jr SetFlags instrCP: call GetNumOrAddr cp (hl) jr SetFlags instrINC: bit 4,a jr z,$+5 dec (hl) jr SetFlags inc (hl) jr SetFlags instrPUSH: ld e,a jp PushByte instrPOP: push de call PopByte pop hl ld (hl),e ret instrRET: instrLDIR: cp 31 jr z,$+5 ld a,(de) jr $+7 ld a,saveSScreen ;LSB->A sub e neg ld l,a ld h,0 dec l push bc push hl call GetInc ;C is the size of the data ld b,c LDIRLoop: call GetInc pop hl inc l push hl ld de,saveSScreen add hl,de ld (hl),c djnz LDIRLoop pop bc pop bc ret ;B always contains the flags GetNumOrAddr: ;HL is what DE was input as ;Returns A as the value push de push af call GetInc pop af pop hl bit 4,a ld a,c ret nz ex de,hl ld hl,saveSScreen add a,l ld l,a jr nc,$+3 inc h ld a,(hl) ex de,hl ret MathLUT: .dw instrLD .dw instrADD .dw instrADC .dw instrSUB .dw instrSBC .dw instrXOR .dw instrOR .dw instrAND .dw instrCP .dw instrINC .dw instrPUSH .dw instrPOP .dw instrRET .dw instrRET .dw instrRET .dw instrLDIR GetInc: ;Outputs: ; C as the next byte ; PC incremented ; HL = PC ld de,(PClow) ld a,d ld c,d and 1 ld d,a ld hl,saveSScreen+256 add hl,de res 0,c inc e jr nz,$+3 inc c ld d,c ld c,(hl) ex de,hl ld (PClow),hl ret

Spoiler For Jade.inc:

Spoiler For Instruction Set:

Currently the program is 522 bytes, but I still need to add in a decent sprite routine (I will probably use some heavy SMC).

Yay, the ports have been added

I made a more complicated program and I changed the port values so now each group of sprite ports is five bytes (the fifth is for the drawing method). The code isn't clean, but it shows that it is working. The code in the screenshot increments the x coordinate of the first sprite until [Clear] is pressed. It doesn't wait to acknowledge if the sprite has been drawn which is why I consider it to not be cleaned up code.

Also, the hex is compressed using BatLib, so if you want to give it a try, you will need to use BatLib or some other method of compressing the code.

chickendude · « **Reply #20 on:** March 02, 2013, 08:24:38 pm »

What's the difference between the two ldir's?

EDIT: And i believe this is the code in "assembly":

Spoiler For jadeDemo.asm:

Btw, i think you accidentally put in an extra sMethod before sUpdate, so some of the equates at the end are one byte off. Here's an include file i've started but haven't tested/finished yet:

Spoiler For jade.inc:

I just compiled and ran this code (typing it in by hand) just fine on my 83+