MaxCoderz

Timendus; why use $FF as a hard return? We already have \n, and it seems silly to have to remap our assembler to substitute $FF for \n..?

Two very good questions indeed

tr1p1ea wrote:What happens if you need $FF in your matrix? Perhaps you could have <width>,<height> at the start?

Good idea, I'll change it to that!

benryves wrote:Timendus; why use $FF as a hard return? We already have \n, and it seems silly to have to remap our assembler to substitute $FF for \n..?

I tried using \n, but Brass wouldn't do ld a,'\n' and I was too lazy to figure out what value you used for it. Also, how would TASM handle it? Would that compile \n to the same value?

Timendus wrote:

benryves wrote:Timendus; why use $FF as a hard return? We already have \n, and it seems silly to have to remap our assembler to substitute $FF for \n..?

I tried using \n, but Brass wouldn't do ld a,'\n' and I was too lazy to figure out what value you used for it. Also, how would TASM handle it? Would that compile \n to the same value?

That's a bug in Brass. Whoops. In all cases, it should assemble to $0A. I'll look into that, well spotted.

EDIT: Yep, you're right. .db '\n' doesn't work, but .db "\n" does (but "..." only works for .db-esque directives, and is a special extension of the expression parser). I've noted it as a required fix.

Even the TIOS uses the character $0A as a newline; if you display it it draws a ":" then moves the cursor down a row.

benryves wrote:Even the TIOS uses the character $0A as a newline; if you display it it draws a ":" then moves the cursor down a row.

Really? That's interesting. I'll take a look at it, wait for the bugfix, and change $FF to \n
By the way, I use $FE as a soft return. They can't be the same value. Any good suggestions on what value I should use for that? Not that it really matters much

\n (Line Feed) doesn't mean "return" anyway, it just means "move the cursor down one line". To move it back to column 1 as well, you need \r (Carriage Return) - which is why on Windows you should use CRLF (\r\n), not just \n...

I'm not entirely sure what a "soft return" versus a "hard return" is..?

So, does \r also do something on a calc? Can TASM/Brass compile that to something useful too?

I use two types of returns in my routines, because there's a difference between a newline that a user wishes to have in a string ($FF or the future \n) and newlines that are inserted by the word wrap routine before displaying ($FE). The wrap routine doesn't copy the string, because that would require some safe ram that I don't want to spoil on this. So it changes the given string and adds "soft returns". The next time the wrap routine is called those soft returns are removed first, and then added again (possibly at different locations). If I used the same byte for both hard and soft returns, that step would remove all newlines.

http://home.comcast.net/~tasm/tasmman.htm -- TASM supports \r, as should Brass (Brass supports all of those escape sequences apart from \000, ignoring the aforementioned bug that '\n' no longer works).

I added about 20 new routines to the API, including some new keyboard routines, draw.square and draw.horizLine (though these still have a bug), string.makeWrap and most of the GUI routines. I didn't do this because they are finished, or because I wanted to show them to anyone, but because I couldn't keep track of them on my harddrive in different files with different notations. So I organized them in the website.

If you find any bugs in the API as a whole, please let me know as soon as possible (the rest of the API shouldn't suffer under my tests), if you find bugs in the new routines I'm probably working on it, but let me know anyway

The API currently has 93 routines and a little under 8000 lines of code in an include file of 144kb

Small update:

I made a new stable snapshot of the API (now with 66 routines) and added two nifty things to the Latenite Tools package. The first being a project template that makes it even easier to get started with the API and the second being an XML file for the MC AutoUpdater. If I'm not mistaken that makes the API the first project to actually use that thing

cool. So is the API more like a compatible include with Latenite now?

In a way, yes But it's probably the most complex and the largest include the Ti scene has ever seen, and you don't NEED Latenite to use it. It's just that I prefer to develop with/for Latenite because it finally gives us a stable, dependable compile environment.

If I'm not mistaken that makes the API the first project to actually use that thing

Yeah, you've beaten me apparently. But my next release will use it too

God damn spambots are filling up my idea box I guess I'll filter messages with [ib-tags] out...

Edit: There, that should keep them out for a while...

For some reason when I originally tried to use it by itself, and then w/ Latenite, it generated a lot of errors. I hope this succeeds.

Then you probably didn't include it properly
The template should fix that for you though, because the include statements are already in it.