Yeah for Nostub the limit I think is 8100 bytes about including data.  Silly TI

Actually that's not entirely correct. You can have approx. 8100 bytes of executed code, but your data can extend beyond that limit. As long as you don't execute across the 8100 line ($C000), you're fine, so reorganizing data sometimes pays off. (i.e. putting it all at the end of the program binary)

EDIT for the nitpickers: This holds in the standard memory mapping. If you swap in an uneven-numbered RAM page in the $C000 bank, you'll be safe to execute code, but that's not really the best way to deal with the problem (cue OS freakout on every interrupt => CRASSHHHH)

Offtopic edit: this semi-useful post is my #400. I'm still the staff member with the lowest postcount, though.

You can't use bcalls for text/sprites in an app. You have to write your own routines, or store all text in RAM.

This is because, if you call cross-page, the pointer is messed up: it points to the same address, but on a different page. So basically, you can't access data in your app during a bcall. (or an external page call, in general)

EDIT: if you want all the technical details about why this is, you can read up on wikiti.brandonw.net

I have 256 MB RAM and only 991.0 MHz clockspeed. I win. j/k


("Margin"-edit: I have to say I run a very outdated linux, so speed is not a concern. I haven't updated anything in some time. The computer is almost 10y old and not connected to the internet, so nothing fancy, but it also means I hardly need/want any bloatware like antivirus )

Sigma (or sgm) is Sean McLaughlin's nickname on UTI. He is the author of the 83pa28d tutorial I was referencing.

Certificate is 16KB, like an app.

It's worth a try, but it hasn't been done to my knowledge.

Cool idea, but won't it be a PITA to implement? I can imagine that it requires a lot of really versatile code at the higher levels of your application... But of course I haven't read any of your source lately.

No, no. The program is copied, but the labels need the correct values, or otherwise the program goes havoc.

Say I call label1 in 2 different situations:

.org 0 ;just for clarity
blablablabla
call label1
blablabla
label1: ;say this is the 250th byte of the program
blabla
ret


The code would resolve to call 250.

Situation 2:
.org $9d95
bla
blablablabla
call label1
blablabla
label1: ;say this is the 250th byte of the program
blabla
ret
The call instruction would now become call 250+$9d95 (too lazy to convert the hex ), but it would still be at the same position relative to the beginning of the program.

Is this clear enough? It's really much simpler in concept than it is in words...


EDIT: seeing player's post: I'll summarize: The label resolution is always relative to the program origin. The absolute position therefore is the position relative to the origin+the value of the origin. (that's where .org stands for, btw)