Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Aichi on October 31, 2010, 06:32:48 am
-
I thought I could learn Asm by disassembling single Axe Parser compiled commands,
but this idea was fail. :-\ I read some tutorials and source codes, but there are still some issues:
1) How let I run my prog under 15Mhz processor speed?
2) How to randomize a word, like Axe Parser's rand^x?
3) I want to include Joe Wingbermuehles's fastcopy routine (http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:Fastcopy) into my code, but I'm not sure what 'gbuf' has to be. I think it must be a constant pointed to the start of the Buffer, if yes, which adress is it on a TI84+? I dont use ion.inc, since this means to be unable to use ti83plus.inc at the same time.
Thats all for now. Thanks in advance!
Regards,
Aichi
-
1) Programs run at 6 MHz by default, and to start executing at 15 MHz, load 1 to A (it's 1 for 15 MHz and 0 for 6 MHz) and do a b_call(setExSpeed). The b_call doesn't exist on OS versions before 1.13, so you should check for that first:
b_call(getBaseVer) ; OS version in A and B
cp 2 ; test A for OS version > v2.00
jr nc,fast ; it's > v2.00, so it's good
cp 1 ; test A for OS version > v1.00
jr nz,slow ; if not, quit
ld A,B ; test decimal in OS version
cp 13 ; test if it's v1.13 or above
jr c,slow ; it's > v1.13, so it's good
fast:
ld A,1
b_call(setExSpeed)
... ; continue with the program at 15 MHz
slow:
... ; continue with the program at 6 MHz
TI's official guide is at https://docs.google.com/viewer?url=http://education.ti.com/downloads/guidebooks/sdk/83p/ti83pseadn.pdf (https://docs.google.com/viewer?url=http://education.ti.com/downloads/guidebooks/sdk/83p/ti83pseadn.pdf).
2) Well, there's no built-in rand thing, but you can use the memory refresh register R, which basically goes up every time "something happens", so it's pretty much random. It's a byte between 0 and 255.
I think Ion has a random integer function. Not sure how it works, though.
-
1) Thank you! :)
2) Ok, I found a nice routine by Joe Wingbermuehle.
3) Perhaps gbuf is the same as the system pointer 'plotsscreen'.
4) http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:put8x8sprite I tried to copy the first routine into Mimas, but it seems like Mimas cannot handle the line LD D, (IX) ôo. Does anyone know what the problem is?
-
Oh, by the way:
3) Yes, they're the same. In ion.inc there's a line that says
gbuf =plotsscreen
-
Easier than calling SetExSpeed, you can set the speed yourself:
in a, (2)
add a, a ; check if on a TI-83+ BE
jr nc, is_a_ti83p
ld a, 1
out (20h), a
is_a_ti83p:
or use MichaelV's method, which works because port 20h is the same as 0 on the 83+ BE (so this also resets the link port):
in a, (2)
rlca
and 1
out (20h), a
But if you're writing an Ion/MirageOS program, you need to be sure to set the speed back to 6 MHz (write zero to port 20h) before exiting, since otherwise the shell and other programs won't work correctly. In particular, depending on the shell, the ionFastCopy routine may not work correctly at 15 MHz.
Oh, and:
4) http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:put8x8sprite I tried to copy the first routine into Mimas, but it seems like Mimas cannot handle the line LD D, (IX) ôo. Does anyone know what the problem is?
Yeah, that's a known issue with Mimas. You have to write "LD D, (IX+0)" instead.
-
The second one's the one Axe uses. Don't know how it works, though :(
-
Well, bit 7 of port 2 is zero on an 83+ BE, whereas it's one on an SE or 84+. So after the 'and', A is 0 on an 83+ BE, or 1 on a newer model. As I said, port 20h on an 83+ BE is the same as port 0, so writing 0 to port 20h resets the link port. Whereas on an SE, writing 1 to port 20h sets 15 MHz mode.
-
Oh, I see, thanks.
-
Yeah, that's a known issue with Mimas. You have to write "LD D, (IX+0)" instead.
Ah, thanks. I should develope on PC while Mimas' early Alpha phase.
5) How compare I the HL register by using something like CP?
-
Yeah, that's a known issue with Mimas. You have to write "LD D, (IX+0)" instead.
Ah, thanks. I should develope on PC while Mimas' early Alpha phase.
5) How compare I the HL register by using something like CP?
This seems like the logical method to me:
or a
push hl
sbc hl,reg16
pop hl
EDIT: Don't do that, do this (http://ourl.ca/7688/135345)
-
And here is the best one: (I think by calc84?)
or a
sbc hl, de
add hl, de
The flags are affected exactly the same way as cp.
-
That is indeed the method reported by WikiTI ;D
Sometimes the "logical" method isn't the best :P
-
And here is the best one: (I think by calc84?)
or a
sbc hl, de
add hl, de
The flags are affected exactly the same way as cp.
I debated posting that, but that addition will leave some flags (s, z, and n) with incorrect values.
-
n is unimportant, and I'm not sure it's affected by 16-bit additions/subtractions.
As for s and z, I do agree that they are changed, but that's unimportant if you're dealing with c (and p, I believe)
It's better in some cases, I guess. ;D
-
Straight from the zilog manual for add hl, <register>:
Condition Bits Affected:
S is not affected
Z is not affected
H is set if carry out of bit 11; reset otherwise
P/V is not affected
N is reset
C is set if carry from bit 15; reset otherwise
To be honest, I actually forgot that S and Z were ignored. I bet somewhere in one of my programs I did that wrong.
-
Yeah, that's a somewhat surprising behavior for 16-bit adds, which has tripped me up more than once (and heck, I've written a Z80 emulator.) So yeah, a 16-bit 'sbc' (with carry flag clear) followed by an 'add' really is, in essence, a 16-bit compare. (Notice that the add will carry if and only if the sbc did.) 8080 compatibility for... the win, in this case.
-
Straight from the zilog manual for add hl, <register>:
Condition Bits Affected:
S is not affected
Z is not affected
H is set if carry out of bit 11; reset otherwise
P/V is not affected
N is reset
C is set if carry from bit 15; reset otherwise
To be honest, I actually forgot that S and Z were ignored. I bet somewhere in one of my programs I did that wrong.
Wait, what!? :o Sean McLaughlin, you lied to me!
-
Did he? I doubt it, he's a pretty smart guy. :) Note that this is only the 16-bit ADD instruction; the 8-bit ADD affects the flags as you would expect.
-
6) I have some trouble with the Tasm Compiler (from the 28 days tutorial). I want to store the program data byte (CursY) into the L register, but Tasm outputs a strange issue on this line, which I cant explain me. Source and Screenshot attached.
-
That code will not do what you want. You can't load an 8-bit value from memory directly into a register, except for the A register. TASM interprets "ld l, (foo)" as "ld l, foo"; i.e., a request to store the value "foo" in L, not to store the contents of memory location "foo" in L; the Z80 doesn't have an instruction to do the latter. TASM is then complaining because you're trying to store a 16-bit value in an 8-bit register.
What you want to do is either "ld hl, (foo)" or "ld a, (foo) / ld l, a". Obviously the former will destroy the contents of H, while the latter will destroy the contents of A.
-
Thank you very much, Floppus!
-
7) I have to add the value of register a into register c.
add c, aor
ex bc, af
add a, c
ex bc, afdoesnt work, so I use this:
ld b, a
Bloop:
inc c
djnz Bloop
dec c
My question is if this is the most efficient way for the solution.
-
add a, c
Ld c, a
Destroys A but i believe its a lot faster than incrementing C up to 255 times just for a single loop O.O
EDIT: Did the math and this performs about 200 times faster than your loop on average D:
-
My question is if this is the most efficient way for the solution.
Definitely not :o
And seeing as you're destroying B anyway, you can use that to temporarily store A while you use Builderboy's code.
-
Another thing... I know this isn't really related to the discussion but it matches the title...
I am a fresh beginner and there are some things I still don't know... what's the difference between "BCALL" and "B_CALL"?
-
There are none. It's simply a different code formatting accross different ASM IDE/compilers.
-
Oh... I had an idea why... again thanks.
-
Yep, same with the underscore in _GetKey and all those other b_calls. Each assembler assembles differently (but tiDE is going to take any, I think).