After being directed to this topic a few days ago, I decided I should try my hand at writing some sort of installer to simplify the installation of large BASIC projects.

As a user, you'd send the compressed file(s) to your calculator, followed by a relatively lightweight installer. From there, you run it as an ASM program and it'll give you options of installing, uninstalling, or repairing some large BASIC game. Planned is the ability to install to DCS file folders, either pre-existing or newly-created.

As a developer, you create the compressed archive files using a tool which consists of a batch file (the thing you actually run), some custom-built C program, an pucrunch. All of it will be included whenever I finish up this project and test it for bugs. For creating the archive, you have three folders, each named "RAM", "FLASH", and "MAIN". You put files that go into FlashROM (Archive) in the FLASH folder, subprograms that go in user RAM in the RAM folder, and the file the user ought to run into MAIN. The MAIN folder must contain one program. The other folders in any combination may remain empty, but they must exist. Any file ready to be sent to the TI-83 Plus (i.e. .8xp, .8xs) can be included in the archive. EDIT: Don't try to include group files, though. That kinda defeats the purpose of the installer, and ... well. It might complicate things if you somehow tried to place a group file in RAM.

I've written down the planned specs for these archive files, and the methods I'd be using to put them all together. It won't be pretty, but I'll get it to work. The only thing that would really rack my mind would be trying to understand the pucrunch decompressor well enough to modify for ... special purposes...

Oh, and as far as a GUI goes... there won't be much of one. Gotta go with the "retro" ASCII look. Homescreen ftw

You could always play around with the DCS GUI while you're at it. But I respect your decision to go with a simpler homescreen ASCII GUI. I definitely will be following this project with keen interest, and I hope you'll ask me for any help that you need with DCS-specific stuff, coding, testing, or optimization. Do you think you might consider allowing on-calc creation of these as well for those who don't mind having non-compressed archives and would prefer not to get their computer involved? I look forward to seeing your ideas and progress.

May I suggest using libti for to automate the sending of the files to the calc and even in the file creation/compression. For the sending look at tiput.c in Ben Moody's TiTools as it is a very simple implementation of doing just that.

If you have questions about libti* both me and Lionel would love to help.

Good luck with this it sounds like a cool project.

Mmm, I think that would be a very interesting collaboration indeed. Also, Iambian, please don't hesitate either to post C questions in this thread, or to start a separate thread for C questions.

So I'm having a problem with the following code. It's supposed to grab information out of a file which contains filenames. They're in a directory which I put before the filename, and the string is constructed. It displays on the prompt correctly, but it does not want to open the file. I verified that the filepath/filename combo works with a static variable, but not this.

Sorry if my verbiage isn't right. I am still learning the basics with the whole C thing.

EDIT: All the variables were declared appropriately earlier in the program.

EDIT2: Please disregard this post. I changed fileread[i-1]='\0'; to fileread[i-2]='\0'; and it solved it wonderfully. Something about leftover nonprintable characters, I think.

Code:

Sorry I was so slow to catch up on this post. In the few examples of your coding that I've seen so far, you've written some of the most creative and unorthodox for() loops that I've seen in a very long time; I'm curious what your inspiration is. I believe you need the extra -1 because you increment once again even after getting the \n? If you're testing on Windows, you should be aware that the newline is \r\n, so the "\r" is the other thing you're throwing out.

Thanks for that little tip regarding how newlines are stored in Windows.

I got my inspiration from the following document: http://www.iu.hio.no/~mark/CTutorial/CTutorial.html
It's where the line starts with: for (ch = '*'; ch != '\n'; ch = getchar())
I took that and flew with it

Gotcha, very nice. For the sake of cross platformedness, if you decide that you want to try to achieve such a goal, I suggest being able to recognize \n, \r, and \r\n as valid newlines, for *nix, Mac OS, and Windows respectively.

I may eventually go cross-platform, but right now, I'm just writing stuff that'll work happily with my Vista, which is probably a good reason to have other people test it on other Windows systems. Not entirely sure what differences the versions might have, but they might affect something.

So far, I can get my batch file/C program/pucrunch set to generate one compressed .bin file. Gotta write more code in to have it be able to generate multiple files, and then I've gotta pack it into the .8xp file format, which I will write into mah C program.

Would you guys rather have appvars instead of programs?

Yes Appvars would be much preferred to programs assuming the program to install/unpack them is included. Though from the original post I had the impression that the files were gonna include the code to unpack themselves.

I guess I did not make it too clear. When the install gets to the calculator, there are at least two files. Maybe at least 3 if I choose to write a loader for Athena.

- The huge as hell data files will contain all the information needed for an install. There may be more than one depending on how large the install is.
- Some ASM program (Athena) between 1-2KB will be the installer program.
- Some really lightweight loader program to load Athena to safeRAM so we can have as much RAM as possible available for the install.

I ask for the option about appvars because this is the stage of the project in which I can easily do it.

Wouldn't be a matter of one byte/line in both your C code or ASM program to switch between them, I mean I don't see why you couldn't just support both?

It's too bad that Doors CS' AP system needs to keep the program and its file in RAM, otherwise you could use that. Ah well, keep up the good work.

I could write up a small, lightweight program that loads the actual installer into some stretch of saferam. Maybe then I could use some of the facilities that are included with DCS. Otherwise, I plan on writing something that'll function as a standalone installer. If I make both, the choice will be with the game developer. It would benefit them greatly if they were using the DCS libs if they got an installer that would work well with DCS too

I mentioned this on IRC, but I guess I should mention it here too. I got the PC side of the installer nearly done. Well, it's still a small way to go. It'll output a number of compressed files given every 64KB chunk of data input into it, instead of just one file and simply refuse to process the information after 64KB (since the compressor will only process up to 64KB at a time). The end result? I am able to cram Illusiat 13 (130KB) into three files which collectively total 42KB. Still... what needs to be done is to pack these compressed binary files into the .8xp format. I'm not gonna use something like devpac8x since it'll only work on 24KB files. This is a concern because these files (especially if they don't compress well) can reach up to around 64KB. The size itself isn't really a problem since the calc will (believe it or not. I tested this...) accept files up to that large into FlashROM. You'll never be able to unarchive them, but that's the point! Stuff like that should stay in FlashROM.

Aaaanyway. Enough rambling on. If that was too long to read, I just need to finish up the packager, then write the installer (which shouldn't be too hard). Something that works. Then I'll start putting some of the good stuff in. I'll keep ya posted on it.

Have you tried using my BinPac8x? I don't think I coded it with a limit lower than 65535 bytes in files. I'm very happy to hear that this continues to progress; keep up the good work.

Thanks for the offer, but I think I'm good at this point.

I have reason to believe that the Athena packer is done (enough). More could be added to it as I get more suggestions, or add more features, but I think it's time to work on the Z80 ASM side of things.

EDIT: Scratch the doneness part. Just experienced a major oversight in the file formatting. I didn't have a way to uniquely identify install files nor did I have a field that one could input a project description. Whoops.

May I strongly recommend that for the case of future compatibility with something DCS based you choose a header format that coincides with the AP file header? For some reason I don't seem to have that in the SDK. O_O No wait, there it is:


Code:

You could easily make the first field in the file a description. Of course, you're equally welcome to decide against this.

I'm seriously thinking about making this thing DCS-compatible through the AP system, but as the project stands, that's impossible. As it stands, of course. The files that are associated with the Athena project can be far too large to cram into RAM, and besides that, RAM needs to be rather empty for this to work. So, I'm thinking of a slightly different way of doing it. Not just because I'm planning to make it work for DCS, but because I believe that this will make the project better and easier to work with.

I'm going to split the "main header" off from the first huge data file and put it in its own, rather small file (40-100 bytes). Instead of real names, the data files will get some name that's generated from something like its checksum or hash. Something that won't likely collide with some other file (though in any given project, this will be checked for). These names are stored in the small file so Athena can have a reasonable way to look them up. This will be the file you'll open up in DCS, and if you run a standalone version of Athena, these are the files that are read to determine how many projects there are.

Not exactly sure what you're supposed to call that little file. I'm sure there's a name for it, but I don't know it. Contains information about the install and that sort.

Perhaps "metadata" is the word that you're looking for? It's not 100% accurate, but it's the closest that I can think of. At any rate, I think this would be a great way to handle things, and I obviously love the idea of making it work with DCS/

I believe I have the Athena packer generating files correctly, so I guess it's largely a success?

For anyone interested, here's some documentation about the files themselves.

Code: