For your other question, I can't help you except that this won't work in Wabbit (for reasons I don't know (maybe flash unlock doesn't work on it (nested parentheses FTW))), so you'll have to take an actual pic.
TI-Boy works perfectly fine in Wabbitemu. However, it does rely on real boot code, so it does not work with roms made with bootfree (that is what you get if you choose to "Create a ROM image using open source software").
Since 8.8 numbers are stored the same way as 16-bit integers, let x be the first value interpreted as an integer and y be the second value interpreted as an integer. Then x/256 is the first value interpreted as 8.8 and y/256 is the second value as 8.8. Additionally if z/256 is the result interpreted as an 8.8 value, then z mod 65536 is the result as a 16-bit integer.
z/256=x/256+y/256 z/256=(x+y)/256 z=x+y (Addition is exactly the same)
Spoiler For Example:
add hl,de
z/256=x/256-y/256 z/256=(x-y)/256 z=x-y (Subtraction is exactly the same)
Spoiler For Example:
or a sbc hl,de
z/256=(x/256)*(y/256) z/256=xy/65536 z=xy/256 (Multiplication result must be divided by 256)
Spoiler For Example:
ld a,l ld c,h ld hl,0 ld b,16 Loop: add hl,hl rla rl c jr nc,Skip add hl,de adc a,0 Skip: djnz Loop ld l,h ld h,a ret
z/256=(x/256)/(y/256) z/256=x/y z=256x/y (First operand must be multiplied by 256)
Spoiler For Example:
ld bc,16*256 ld a,l ld l,h ld h,c Loop: scf rl c rla adc hl,hl sbc hl,de jr nc,Skip add hl,de dec c Skip: djnz Loop ret
z/256=√(x/256) z=√x/√256*256 z=√x/16 (Square Root result must be divided by 16)
Spoiler For Example:
ld b,12 ld a,h ld c,l ld de,0 ld h,d ld l,e Loop: sub $40 sbc hl,de jr nc,Skip add a,$40 adc hl,de Skip: ccf rl e rl d sla c rla adc hl,hl sla c rla adc hl,hl djnz Loop ex de,hl ret
Of course, these are all unsigned. Changing to signed is almost identical to changing integer math to signed.
Edit: Mixed up h and l at the beginning of the multiply routine.
I haven't looked too closely, but one thing I do notice is that you pass {A+Str1} into the routine, which is a number from 0-255. Then you do {r₁}, which tries to load a value from an address in the range 0-255. Such an address cannot be in ram (and is highly unlikely to be an address at all). I'm guessing you just have too many {}.
Did you have a JavaScript version of this somewhere? For some reason I remember using it in my browser at some point. But I might have gotten it confused with the other emulators.
I have wanted to do this for a while, but the programs produced by Axe Emulator were meant to run continuously, and browsers don't like javascript code that doesn't return. I had a proof of concept showing that it was theoretically possible here, but it wasn't feasible at the time because I had to modify the javascript by hand in order to make it work.
After rewriting the parser in Axe Emulator, I was able to change the behavior of the produced programs to run in stages instead of continuously. This means that I am now able to compile Axe source code to working javascript in an easily automated fashion. Some examples of this can be seen at http://axe.jacob.heliohost.org/. Hopefully, I will be able to finish both the parser rewrite and the javascript port of the Axe routines soon, so that I can release an update.
Show Posts
