Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: willrandship on March 10, 2011, 11:40:11 pm
-
The 8000-byte limit in asm-based prgs is a pain, and the only way I've heard so far to get around it is to make an app. However, there are certain things you can't do inside of apps. An easy way to make a program that gets around this would be basic + a hex code to allow Archiving/Unarchiving, but the cool way would be to have your program run inside of another asm program, that copies the code to and from, say, an appvar, as you run it.
Example:
asm(prgmGAME
[Begin Pseudocode]
Copy 1-8000 bytes AppvGAME To an asm PRGM
Run asm prgm
(AsmPrgm throws an interrupt back at line 7999)
Copy lines 7999~15999 over 1-8000
repeat until return statement, when it quits
This would theoretically allow for 1.5 MB apps outside of Apps, just archived, variable size, read/write, anything you want. Of course, the BASIC one is much easier :P but you can't share variables across the prgms unless you copy them to TIOS, which would be slower than just using one asm brick.
What do you think?
-
Why is there an 8000 byte limit? Does it have to do with Axe's capabilites? Or is it a TI-OS thing? If the latter is the case, compile to Ion. MegaMan for 83 Plus is a gigantic 18000 byte program.
But, if the former is the case, it looks like this solution would work. Many BASIC RPGs create XTEMP programs to have giant apps composed of many subprograms. Now, you would have to be able to use HEX assembly to copy the program.
Also, does this 8000-byte limit apply to the executable, or just the source? Eitrix's executable is approaching 8000 bytes, but the source is around 4500 bytes.
-
Back in the days, the TI-83 Plus SDK to create APPs was not free and TI sold apps for money too. TI added a 8 KB limit to prevent people from repackaging apps as 8xp files.
-
@Compynerd255 this limit applies to the executable, not the source.
-
The 8kb limit is a hardware based limit, even if you made a third-party OS you still can't execute code from $C000. You could get around the limit by copying executable code to SafeRAM and executing from there.
-
That's actually not bad. However, copying 8000 bytes of code takes about 1/35 of a second, so there would be lags from time to time
Incidentally, I did not know that the SDK used to cost money, even though I knew that some applications did cost money
-
Yep, but they made it free, along with an app signing key.
-
They should have made it free in the first place. Now we have to go through all of this trouble because TI does not want to update their os to allow unsigned apps. If anyone can make an app, what is the use of all of the safeguards? ???
-
The 8kb limit is a hardware based limit, even if you made a third-party OS you still can't execute code from $C000.
I can. >:3
-
Lol how do you do it Raylin? Do you use a TI-73 running a TI-83+ OS? :P (These have no 8 KB limit)
-
What I would be more interested in is seeing Quigbo break the 1 page app limit.
I know, far-fetched. :P
-
Lol how do you do it Raylin? Do you use a TI-73 running a TI-83+ OS? :P (These have no 8 KB limit)
Great success, sir. Right on the money.
-
Lol nice, although your signature doesn't state anything about how you got a TI-73 running a 83+OS ???
-
@Compynerd255 this limit applies to the executable, not the source.
Then how come 10K programs, such as FireTracks and Megaman, can exist?
-
@Compynerd255 this limit applies to the executable, not the source.
Then how come 10K programs, such as FireTracks and Megaman, can exist?
The only restriction here is that you can't execute code >8811 bytes from the start of the program. You can always have data there, however.
In other words, you can have an 12-KB program that has 8 KB of executable code at the beginning and 4 KB of data at the end, and it'll run fine.
-
Lol nice, although your signature doesn't state anything about how you got a TI-73 running a 83+OS ???
BrandonW isn't finished with it yet. :c
@ralphdspam: What Deep Thought said is correct. You can have a lot of data behind the 8K limit and it will still run fine.
-
What Deep Thought said is correct. You can have a lot of data behind the 8K limit and it will still run fine.
Phew. I still have 2000 or so bytes left then. I should have little trouble keeping under that limit. If needs be, I will dive into the code and optimize it to death.
-
What Deep Thought said is correct. You can have a lot of data behind the 8K limit and it will still run fine.
Phew. I still have 2000 or so bytes left then. I should have little trouble keeping under that limit. If needs be, I will dive into the code and optimize it to death.
However, Axe mixes data with some of its own routines, so you'd still have to keep it under the 8811 byte limit if you're using Axe. Or you could use custom data storage, but it's slower.
-
The trick is to really hard-code as fewer things as possible. For example in a RPG, don't write code for one magic spell, another piece of code for another, etc, and don't hard code NPC movement during cutscenes. Instead, store those in appvars and write a small program that processes the data.
-
Alternatively, to break all these cool ideas, copy all of ram page 0 to ram page 3 and swap it into $C000 to $FFFF. That way, since page 3 is odd, you won't get the ram clear but you will still have the code, and when you're done. Copy everything back onto page 0 and put it back in it's place.
Of course this wouldn't work on a 83+BE, so carry on.
-
Of course this wouldn't work on a 83+BE, so carry on.
Great how nothing works for me :(
-
I'm having trouble with the 8.8k limit and don't have any executable code after this. Running from Mirage works fine, but the homescreen gives me an error ("ERR: INVALID"). The data isn't even used in the program yet. Any ideas?
-
The limit for programs run from the home screen is actually 8,192 bytes (not 8811) because TI decided to play it really safe, losing you another 600-something bytes in the process. This is just a simple check done by the OS before running an assembly program, so all shells will happily ignore the limit.
-
The limit for programs run from the home screen is actually 8,192 bytes (not 8811) because TI decided to play it really safe, losing you another 600-something bytes in the process. This is just a simple check done by the OS before running an assembly program, so all shells will happily ignore the limit.
Agreed
If you want to continue running said program from the homescreen, you'll either need to use DCS's run from home, or zStart's run from home. (The link to zStart is in my sig ;D)
-
Cool, i never knew about that "feature", thanks for the info. I decided to just write a little launcher to not have to load up DCS/Mirage/zStart every time i want to test it out, it doesn't delete the allocated memory afterwards so i guess it's just for emulators, but:
#include "includes/ti83plus.inc"
#include "includes/ion.inc"
.org progstart-2
.db t2ByteTok, tasmCmp
ld hl,debut_routine
ld de,gbuf
ld bc,fin_routine-debut_routine
ldir
jp gbuf
debut_routine:
ld hl,programme_a_executer
rst 20h ;mov9toop1
bcall(_ChkFindSym)
push de ;de = debut du data
ex de,hl
ld a,(hl)
inc hl
ld h,(hl)
ld l,a ;premiers deux octets = taille du programme
ld de,$9D95 ;charger a $9d95
push hl
bcall(_InsertMem)
pop bc ;taille du programme dans bc
pop hl
inc hl
inc hl
inc hl
inc hl ;sauter la taille du programme et deux autres octets que je ne sais pas ce'qu'ils font
ld de,$9D95
ldir ;ldir "bc" fois
call $9D95
ret
programme_a_executer:
.db ProgObj,"PROGRAM",0
fin_routine:
And now everything is (or appears to be) running fine :)
-
Congratulations, you just made your first shell.
-
Yes, congratulation.... errr..... what?? this is a shell ???? ???
-
A shell's job is to run other program (especially ones that can't run themselves) and that is exactly what his program does. Although it only runs one program, it's still technically a shell.
I noticed it more from a code standpoint. "bcall(_insertMem)" and "call $9D95" are dead giveaways of a shell.
-
Yes....
it is a shell... (a little shell) ;D
-
Haha thanks. By the way, this will only let the program use up half the RAM, right?
-
Since you make a copy of the program, yep.
-
If you want to be able to use all of ram without getting into annoying shell stuff, you'll need to keep the main program in flash and use bcall(_flashToRam) (http://wikiti.brandonw.net/index.php?title=83Plus:BCALLs:5017). It's a little trickier to get right, but you could probably figure it out.
Just kidding. Here it is:
ld hl, *name*
rst 20h
bcall(_chkFindSym)
ret c
ld a, b
or a
ret z
ex de, hl
ld de, appBackUpScreen
ld bc, 2+2+*nameLength*+1+3+3+3
push af
bcall(_flashToRam)
pop af
ld bc, 2+2+*nameLength*+1+3+3+3+$4000
or a
sbc hl, bc
add hl, bc
adc a, 0
push af
ex de, hl
dec hl
dec hl
dec hl
ld a, (hl)
dec hl
ld l, (hl)
ld h, a
push hl
push de
ld de, $9D95
bcall(_insertMem)
pop hl
pop bc
pop af
bcall(_flashToRam)
jp $9D95
I realized you didn't know the structure of flash variables, so you wouldn't be able to write this.
-
Wouldn't this fail because the shell code is running from $9D95? It would break at _InsertMem (well actually, maybe not since the data might not be touched, but it would at least fail after _flashToRam)
Edit: Also, I think it would be more optimized to read the program size from the VAT entry copied from flash to appBackUpScreen
-
Cool, thanks! I've never really touched the VAT, archive, or any of this stuff, for now it's just to test out the game more easily (or more lazily) so really it doesn't matter TOO much if i corrupt the RAM during run-time, but this will be nice if/when it gets released :) What exactly are you copying the first time through, just the size of the program? What are the extra 9 bytes at the end (+3+3+3)?
And calc84maniac, i assume you would just load that code to saferam somewhere and run it from there.
-
Flash archive variable format:
[1:status flag] [2:archived variable total size] [1:prog type] [1:T2] [1:version] [1:page] [2:address] [1:chars in name] [name length:name] [2:size of program] [size of program:program data]
So, I have these mentally grouped. In this order, it's 3+3+3+1+nameLength+2 and then the last +2 is for BB 6D. Really, the archive is just a vat entry with those extra three bytes out front.
-
thepenguin77:
I thought maybe we could add the routine you posted here to the wiki, since there are currently no examples. Would that be ok?
-
thepenguin77:
I thought maybe we could add the routine you posted here to the wiki, since there are currently no examples. Would that be ok?
Don't add this one, I'll do it. (There are much better ways)
Wait, I misunderstood what was asked.
Edit:
Ok, I'll make the wikiti page, what do you want?
-
I was just asking if we could add the information/example to the _FlashToRAM wikipage. :)
-
Oh, this has nothing to do with flashToRam, that wouldn't be the right place to put it. This is more suited for general OS documentation.
And looky here, the page already exists http://wikiti.brandonw.net/index.php?title=83Plus:OS:Variable_Storage_in_the_User_Archive (though without that code example)
-
Ah i thought we could add it as an example of how to use _FlashToRAM since currently there isn't any, but thanks for the link, i hadn't seen that before :)
-
Ah i thought we could add it as an example of how to use _FlashToRAM since currently there isn't any, but thanks for the link, i hadn't seen that before :)
Oh, sure, if that's what you're doing, then have fun with it ;D To be completely honest, when I read your first post, I thought you were going to make a wiki page on how to bypass the 8811 limit.
So I'm saying yes, do it.