You could also do it with inline ASM, but I guess that would defeat the purpose of using Axe. I remember being very confused when I tried to read the documentation on them; perhaps I need to re-read them. Otherwise he would indeed be the one to whom to speak. I pinged Quigibo about another Axe issue; if I hear back from him, I'll see what he has to say about Axioms. Yeah, I'm quite sad about United-TI these days. 
[23:02:02] <Iambian> I did the ROL3 thing just to figure out how well CIII could be used for such a purpose. I didn't find the prospect very appealing and I've since wanted to change the way of how these things worked.
[23:03:25] <Iambian> For what it was, it worked quite well. I was also thinking of writing one that involved pucrunch.
[23:04:19] <Iambian> Ah, yeah. The GETGROUP/EXTGROUP pair is absolutely HORRIBLE for something like this. I never intended it to be that way, but it complicated the program.
[23:04:59] <Iambian> Maybe I should've added another function that extracts just a name given some sort of offset.
[23:06:44] <Iambian> What I really wanted to do was to build some sort of on-computer utility that would cram a project into pucrunch-compressed files, then run a lightweight installer on-calc to do the installation.
[23:07:21] <Iambian> I've a roundabout way with what I know so far. These variables can close to 64KB long.
[23:07:45] <Iambian> And a lot of stuff can be crammed into 64KB.
[23:08:20] <Iambian> I think I should try it some time.
[23:11:00] <Iambian> Thanks for telling me about this. I never knew someone else was interested in doing something like that.
[23:12:50] <Iambian> Eh. I'm going back to work on my 2D Cellular Automata program thinger.
[23:13:06] <+KermM> Iambian, sounds good
[23:13:22] <+KermM> Iambian, I hope you'll share your thoughts and progress with us at some point, then; good luck with the 2D CA
[23:13:42] <Iambian> The assembling part would have to be done on a PC
[23:17:57] <Iambian> I was thinking of having two folders in the directory in which this program is run. one called "Flash" and the other "RAM". It's rather obvious in the context of installers what this would mean.
[23:18:43] <Iambian> This scheme would rely on a combination of batch files, a C program, and pucrunch
[23:19:59] <Iambian> And some general purpose ASM program. In order to keep as much RAM available as possible (because I do have to account for things like variables taking up 23KB or something like that), I'd stuff the program into saferam, free up the copy at $9D95, then go from there.
[23:20:47] <@saxjax> (C) [KermMartian] definitely, that would be good
[23:21:51] <Iambian> On the computer side, prior to compression, I'd have a structure that's a little simpler than a VAT entry preceding the actual data entry. One byte for data type, a 1 byte size field, the name (of variable length), size of the data field, then the data itself.
[23:22:02] <Iambian> It would be good enough to represent any possible data type the calculator can hold.
[23:22:34] <Iambian> And would provide just enough information to use a romcall to create the variable oncalc.
[23:23:34] <Iambian> Also prior to compression, the header should include information as to how much memory this archive will actually take up, so the installer can somewhat determine if the install will fit on-calc.
[23:24:08] <Iambian> It'll be somewhat off for oddities like available space in FlashROM and how much can fit on a single sector.
[23:24:31] <Iambian> So low memory conditions aren't gonna be handled well.
[23:25:27] <Iambian> I'd also modify the pucrunch decompressor so it'll output only one byte at a time, and then let the program interpret the information that is passed through.
[23:25:56] <@saxjax> (C) [KermMartian] for sure, those would be excellent ideas
[23:26:19] <Iambian> That's the sort of decompressor I'll be needing for E:SoR anyway, so I'll be killing two birds with one stone :)
[23:27:28] <Iambian> Oh. And the header should contain a file count so I can have a reasonable way to show more detailed information. Like a progress bar or something. That would be a nice addition.
[23:28:31] <Iambian> Some of these games can take quite a while to deal with, especially with the tons of subprograms that a few large BASIC games tend to have.
[23:30:25] <Iambian> The header also needs to contain the number of files in the actual project. In the event that the stream spans larger than 64KB. In that case, once it runs out on one program, it'll pick up on the next.
[23:31:33] <Iambian> I could imagine that some projects would, even in a compressed state, be larger than 64KB.
[23:32:17] <Iambian> Gotta take that into account too.
[23:33:22] <+KermM> Quite a few projects, I'd think
[23:33:30] <Iambian> This sort of scheme might not be desireable for the regular TI-83 Plus, because some games might take up ALL the calculator's memory. Which wouldn't be good if you had to fit the installer itself in memory.
[23:33:48] <Iambian> And the installation file(s)
[23:33:57] <Iambian> But it would be perfect for the newer calcs.
[23:33:58] <@saxjax> (C) *MufinMcFlufin has entered the room.
[23:34:25] <Iambian> Also, if you really wanted to... you could extend the idea further.
[23:35:28] <Iambian> If you included a checksum or hashing algorithm and embedded it into the modified VAT entries within each file, you could then determine things like whether or not the project is already installed, whether or not the install needs to be repaired...
[23:36:23] <Iambian> ... or if you really wanted to have some serious control, whether or not the project needs to be uninstalled. Cleanly, of course. So what if you wanted to play Contra one day in FFTOM the next?
[23:37:29] <Iambian> This, and a simple ASCII text interface to make it really look retro. These are my thoughts on installers for the graphing calculator.
-------------------------------------------------------------------------------
Documentation regarding the package file format for the data
portion of the TI-83/84+(SE) installer software.
All files that are unpacked and reside in RAM *MUST* be placed last in the
list. Otherwise, the install may fail.
The following is for the initial file.
+00 1b: number of installer files (64KB chunks)
+01 2b: number of files to be installed (can be quite a few!)
+03 3b: number of bytes of FlashROM the installation will take up
+06 2b: number of bytes of RAM the installation will take up
+08 1b: Install type flag (I=install only,U=allow uninstall,R=repair,A=all)
+09 3b: RESERVED
+12 --: SOF
File after this is a single pucrunch-compressed stream of up to 64KB. The
installer will FAIL horribly if you try to compress a file that's larger than
65505 bytes, but then again, such a file won't properly decompress into RAM :)
+00 1b: filetype + flags. Matches TI-OS file types, except bit 7: 0=In RAM
+01 2b: checksum. Used for comparing installed files with this one.
+03 2b: file size
+05 1b: filename length
+06 nb: filename
+07+n : data stream
Further files that come after this will lack the specific header at the top of this spec but the installer will know to start a new decompression session.
10: Set Output = ""
20: Get A<-input number
30: Set LoopCounter = 8
40: If A>2^(LoopCounter-1)
50: Then
60: Output = Output + "1"
70: A = A - 2^(LoopCounter-1)
80: Else
90: Output = Output + "0"
100: End
110: LoopCounter = LoopCount - 1
120: If LoopCounter <> 0 Then Goto 40Advertisement