One thing I never liked about programming in the OS's BASIC program editor is that programs have to be in one piece and can't easily be spread among separate files. It's especially a problem because the screen is so small and it takes so long to scroll down a large program (up to three minutes in the longest). That's what this little script is for -- it takes however many programs you split your project in and combines them so you can run it all at once. Here's an example of it in action:



It's in Axe, and inputs are hard-coded, so you must have the compiler on your calculator to use it. Before compiling, you must modify the pieces listed below, or the script will error. It shouldn't crash your calculator in any case, so if it does, accept my apologies, take a cookie, and please report the bug.



These are the programs to be concatenated. You can have as many entries as you like (greater than zero). Each entry is composed of a string containing the program's name followed by however many null bytes are needed to pad it to eight bytes total. For a one-byte string, that's Zeros(7), for two bytes Zeros(6), and so on. No padding is needed if the program's name is already eight characters. (Zeros() is Buff() in Axe 1.0.5.)



This is the output program's name with prgm in front. No padding needed here. (The Zeros(8) instruction that follows is for a different purpose.)



That 1 should be changed to however many programs there are you want to concatenate (the number of entries in that program list above), minus one.

EDIT: Whoops, forgot to post the download link.

Possible solutions:

1) Doors CS for fast Goto
2) 2nd-rcl prgmNAME in prgmMAIN to paste and concatenate
3) SourceCoder / Tokens!

Perhaps I misunderstand the purpose of this?

My thoughts, actually. To tell the truth, can't this all be obtained in well under 500 bytes of code? Wouldn't all you would have to do is input for amount of programs to be concatenated, the names in order, and add up their sizes and copy sequentially to a new program of the sum size?

I maintain that there's no point in having a program to do it at all, when you can just recall subsequent programs into a main program.

Kerm: The advantage here is that you don't have to wait and watch the TI-OS recall your programs token by token; it's faster.
As for 1) and 3):
1) That only works when the program errors, unless something has changed.
3) If one is working mainly on a calculator, without enough computer time, that doesn't work.

The point is to be able to code in fragments and run the program as if it were all in one piece. Taking however many minutes it takes to 2nd+[RCL] all the individual programs every time you want to test something new gets annoying after a while.

And yeah, ^ what calcdude said was why I made this. DoorsCS's Instant Goto is nice, but that still means you'd have to get to that point in the program somehow to use it, and when you jump around a lot that can get annoying too.

Calcdude, true on both points.

Deep Thought, you know you can use prgmBLAH inside prgmMAIN to "call" prgmBLAH, right......?

But this doesn't make you have to wait on the OS to find the program in the VAT. Although, you could use calling programs in the test versions, and then [2nd][RCL] it on the final version, but even that is kind-of annoying.

DThought, cool program Would it be possible to make it take a string in Ans as an argument and then use that to load programs? I think that would be a lot better in terms of usability, because you won't have to re-compile it, especially if you don't already have Axe on your calculator.

That's what I'm thinking of doing, that and converting the whole thing to raw assembly.

That sounds like a good plan. Keep us informed I don't remember, does Axe allow you to recall Ans as a string? From my "vast" knowledge of version 0.3ish, there was only a command to get a number from Ans.

I'm not seeing the annoyance in the extra 30 seconds (if that) that that second suggestion takes, but I'm probably just too much of an old fogie.

I'm not sure, and that's why I'm going to rewrite it in ASM first Three minutes for a 20 KB program. I've done that so many times in the past that I find scrolling/copying by far the most frustrating part of coding TI-BASIC.

Yeesh, three minutes? That's insanity. I'm confuzzled how you've run across this so frequently and I never have; maybe it's something with coding Axe programs?

It was more a problem before I went into Axe at all, back when I made BASIC games that always, always were packaged into a single program. (I had a phobia of subprograms.) And TI-83 Pluses scroll at a bit more than half the speed of TI-84 Plus calculators.

Not once MathPrint was introduced on the TI-84+/SE calculators, I'd wager.

Really? Are the MP OSes slower even with no MathPrint in the program editor? That sucks :/