I wanted to start learing assembly, and i have already a problem: a simple "Hello World" program doesn't work. It just simpily prints a "H" instead of "Hello World".
Code:

Code:

You may need to start by setting the cursor column and row variables to 0 so that you can be sure you are printing the string on the display rather than off it (which tends to result in weird bugs):


Code:


Depending on how up-to-date your ti83plus.inc is, you may be able to replace the three added lines with bcall(_HomeUp), which does the same thing. TI's official ti83plus.inc does not define HomeUp, though.

Code:
Gives an error while assembling...

Indent the bcall(_HomeUp).

what assembler are you using?

and isn't there supposed to be a .end or .END (depending on assembler)?

What does that mean?

DCS SDK assembler

My code was not intended to be complete - you simply need to reset the cursor position before outputting the string. You don't need to use HomeUp, either - if your include file provides it, it saves a bit of typing, that's all:


Code:


or, if possible


Code:

Put a space before the bcall.

bouth work, thanks. Which methode is better to use?

I think the method without the bcall is better, because it is faster. However, if you are concerned about size using the bcall would be better.

The _HomeUp version is smaller, so I'd go for that. It's not defined in TI's official ti83plus.inc for some reason, which is why I provided the other version first.

Ok, thanks for youre help!

This happend to me aswell at first. It only happens at OS 2.53 or higher.
It's just because the program terminates right after it's done with displaying the text. Then, the OS takes over, creating a new layer in MathPrint. This erases everything that was there first, so it deletes the whole Hello world. A way to solve this is putting a b_call(_getKey) at the end, downgrading your calculator, or setting it to CLASSIC in the mode menu temporarly.

Thanks very much for explaining that; I don't think I would have been able to figure that out otherwise. OS 2.53 is such a travesty. I should really make Doors CS automatically turn on CLASSIC mode before executing ASM programs, come to think of it.

I tried it on other calcs around the classroom, some of which still had 2.30. It all worked, exept for the ones with 2.53MP... (2.55 didn't exist yet). So I though about how this could happen, came to the theory above, and tried it... it worked!
What else is wrong with the 2.53MP than this? I don't see why this is such a travesty, it's just... kinda... normal behaviour after all...

There is a lot wrong with 2.53MP. It breaks how parser hooks work with Op1 and flags; Doors CS contains a hackish workaround that deals with this. It has quite a few crashing glitches and bugs as well.

I had issues with dumping the ROM of my calc running 2.53MP using TiLP. Turning it to classic mode fixed it, along with other asm programs.

Whoa, how could that affect ROM dumping? More and more I'm thinking that Doors CS needs to automatically turn on Classic mode unless specifically instructed not to do so. My main constraint preventing that is lack of space in the Options menu. Maybe I could make it a Display option...?