Hello, add here.
I've had a project in mind which needs (if it's going to be good/nice looking) to be made in asm, and it is going to be made for the TI-84+.
For this I'm using
Doors CS SDK 7 and as reference I'm using
the bitbucket version of 83pa28d.
The questions/remarks I have so far is:
1)
The 83PA28D example 1:
Code:
.nolist
#include "ti83plus.inc"
#define ProgStart $9D95
.list
.org ProgStart - 2
.db t2ByteTok, tAsmCmp
b_call(_ClrLCDFull)
b_call(_homeup) ; add: Kerm told me to add (no pun intended).
ld hl, 0
ld (PenCol), hl ; add: and that this should be CurCol
ld hl, msg
b_call(_PutS) ; Display the text
b_call(_NewLine)
ret
msg:
.db "Hello world!", 0
.end
.end
2)
and how Doors CS SDK behaves when creating the binary file:
Say I assemble that code and the file is called "hello.z80" it'll show up as ZZTEMP on the calculator in the prgm menu.
That was all for now. Will probably be more later on.
add wrote:
1)
The 83PA28D example 1:
This doesn't look like a question. I'm assuming it's just context for the actual question below.
add wrote:
2)
and how Doors CS SDK behaves when creating the binary file:
Say I assemble that code and the file is called "hello.z80" it'll show up as ZZTEMP on the calculator in the prgm menu.
According to the Brass documentation: Quote:
.variablename name
For binary modes that support a variable name, such as the TI output formats, you can use this directive to specify the variable name. It defaults to the filename (minus extension) of the source file.
I know from past experience that the DCS SDK build script (for some reason) copies your source to zztemp.asm before building it, so that behavior is reasonable given the strange things the build script does.
The simple workaround is to explicitly specify .variablename in your source.Code: .variablename "MYPROG"
.nolist
...
1)
Ah, I should have made it clear that the first thing wasn't a question (instead of saying it was, oops), but the things that is commented by me is things needed to be fixed in the guide.
2)
Ah, ok, that does... kinda make sense.
Thanks!
I'll be back.
It copies it to zztemp.asm for the fact that most people don't have a .variabletype ti8x in there source and kermM copies then pipes it in as well as brass's generation used to be a bit wonky and it would rely on binpack8x.py to handle generating the 8xp file instead of brass.
As for it showing up as zztemp what is the command line args you are passing the build script?
geekboy1011 wrote:
As for it showing up as zztemp what is the command line args you are passing the build script?
Not quite sure I understand your question, but I think you meant what I write into the terminal..
Code:
sh compile.sh hello
That's all.
And that's also what Kerm told me was enough..
I just want to mention that I found the missing .variablename line in the compile.sh script, and with that plus new documentation that unknownln pointed out to me on Have Calc, Will Program (HCWP) tonight, I will try to release a new version of the Doors CS SDK tomorrow.
KermMartian wrote:
I just want to mention that I found the missing .variablename line in the compile.sh script, and with that plus new documentation that unknownln pointed out to me on Have Calc, Will Program (HCWP) tonight, I will try to release a new version of the Doors CS SDK tomorrow.
Ah, that sound great! Now to find more bugs 
, although I will of course report them if I do find any. 
Btw, i believe that should be CurRow, not CurCol. One of those is redundant, though, since _HomeUp should just set CurRow and CurCol to 0.
Yeah, but it doesn't make sense to update the code in the opening post since it shows off an error in the guide.
Now, I should make a plan for how to go about making this demo/effect (might as well tell you since I'm probably gonna have to ask for help again sooner or later anyway).
Your comment says " and that this should be CurCol ", it should be CurRow, not CurCol.
And what effect are you trying to make? How far into 28 days are you, btw?
chickendude wrote:
Your comment says " and that this should be CurCol ", it should be CurRow, not CurCol.
And what effect are you trying to make? How far into 28 days are you, btw?
Yeah, Kerm figured it out after I wrote the post.
And I'm in "Day 13".
Also reading a book about general z80/6502 asm programming.
EDIT:
What effect: I'm gonna try making two "circles" that "eat" each other, as in one gets bigger and goes around the smaller one and then the next one does the same. Like in a infinity route.
Oh, that might require some complicated math if you're trying to actually draw circles, but by changing the X and Y velocities gradually you can achieve something pretty nice. Unless you mean actual circles and not something moving in a circle. You could use TI's routines, but those're probably pretty slow. There are a couple circle routines available online, though.
Yeah, making a circle isn't that bad though but making the whole thing look good is.. harder.
I'd like to do a 3D maths effect in the end, but that is gonna take some brain power to think up first
I just want to let you know that I've uploaded a new Doors CS 7 SDK to the Cemetech Archives (http://www.cemetech.net/programs/index.php?mode=file&id=470) and to ticalc.org, whenever it gets accepted. Please let me know if the new compile.sh script works correctly for you.
I just tested it, (sorry for lagging behind) and I do the normal thing:
Code: sh compile.sh hello
----------------------------------
Doors CS Assembler/Compiler
Version 2.0L
Written by Kerm Martian
http://www.Cemetech.net
----------------------------------
----- Assembling hello.asm for the TI-83/84 Plus...
compile.sh: 17: compile.sh: Bad substitution
but that's what I get.
Looks like it's this line (17) in the "compile.sh" file:
Code: varname=${a^^}
That's a bashism. Run it under bash, as instructed by the shebang.
Code: #!/bin/bash
Tari wrote:
That's a bashism. Run it under bash, as instructed by the shebang.
Code: #!/bin/bash
I take it your assuming that I don't run it under bash, but lo and behold!
I am.
Next suggestion?
add wrote:
Code: sh compile.sh hello
add wrote:
I take it your assuming that I don't run it under bash, but lo and behold!
I am.
You entirely sure about that? Because sh isn't bash.
I realized you were right, I needed to write
Code: bash compile.sh hello
now, instead of sh, which worked just fine before.
Problem solved, thanks Tari.
You can also just do ./compile.sh, assuming you chmod it +x first.
I should probably consider zipping the folder on a Linux machine so the +x will be stored in there. Anyway, does this also mean that it generated a file with the correct on-calculator name even if you omit a .variablename line from your source code?
