This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Iambian
Pages: 1 ... 19 20 [21] 22 23 ... 52
301
« on: December 16, 2010, 04:34:18 pm »
Spent all day yesterday working on the Z80 ASM side of Athena. It will now correctly detect metadata files and their associated data files, and I can have the program print out statistics written directly into the metadata file. Attached to this post is an image of what I'm seeing in the statistics view.
What I've got left to do is to edit the decompression routine to get it working for Athena, then start writing out the data that's in there. I can imagine that the hardest parts would be getting the decompression routine to work for me, and creating the appropriate files from the data that is read out. After that, it's rather trivial to print the progress to the screen and archive the files as necessary.
After looking for bugs, I'll then put this thing up for people to test. DJ Omnimaga's probably gonna be the first to get it because he's got the resources and the knowledge to fully test this Athena. I pretty much need all the large BASIC games I can find so this thing can be tested out.
302
« on: December 15, 2010, 02:01:35 am »
I believe I have the Athena packer generating files correctly, so I guess it's largely a success?
The only difference is that the data files start with a "Z" instead of a theta. Doesn't make that much of a difference, since you can pack to appvars instead of programs.
For anyone interested, here's some documentation about the files themselves.
-------------------------------------------------------------------------------
Documentation regarding the package file format for the data
portion of the TI-83/84+(SE) installer software. All instances of multibyte
numeric variables are stored little-endian.
Installations using the Athena packager/installer will contain at least two
files in addition to the installer: (1) Metadate file (2) Data files.
Metadata files contain information about the install. This includes, in no
particular order, the number of data files there are, their filenames, the
number of files that are archived inside the package, the estimated amount of
FlashROM the install will use, the amount of RAM it will use, and a slightly
longer (14 character) description field.
Metadata file structure:
Ofs Siz Desc
+00 08: header. $BB,$6D,$C9,$31,$80,$00,$01,$09
+08 01: number of installer files (64KB chunks)
+09 02: number of files to be installed (can be quite a few!)
+11 03: number of bytes of FlashROM the installation will take up
+14 02: number of bytes of RAM the installation will take up
+16 01: Install type flag (not used yet)
+17 14: 14 bytes ASCII text project project name
+31 01: RESERVED
+32 --: Names of installer files (all 8 char long). This is sized
as number of installer files times eight.
The data files that come after the metadata file contains a number of streams
formatted in the following way:
+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 (includes possible filesize field that comes with file)
+05 1b: filename length
+06 nb: filename
+06+n : data stream
The number of these streams will not be known until EOF is encountered. The
amount of data in this file can be up to about 65500 bytes. None of the data
streams are split for the purpose of extracting data from the file. These data
streams are pucrunch-compressed as a solid archive, so it will be up to the
reader to decompress only bytes at a time and then read the information for
its formatting and its EOF.
The name of these data files is derived from the name of the project and the
uncompressed contents of the file. Every file name will be of the form:
Zfffnnnn
Z is just the letter Z
fff are 3 characters from 0-9 A-V. Hashed from name, so will remain constant.
nnnn are 4 characters from 0-9 A-V, hashed from data, so will likey vary.
Examples: These are true examples from an experiment done on packaging
Keven Oullet's (DJ Omnimaga) somewhat incomplete Illusiat 13.
On entering into the command line:
athena -a I13 "Illusiat 13"
I get the following files out:
I13.8xp Size (bytes) : 132
ZNG0H7DI.8xv Size (bytes) : 24716
ZNG0LK35.8xv Size (bytes) : 4846
ZNGOLRSF.8xv Size (bytes) : 11936
The input was sized collectively at 138327 bytes, so this is also a great
compression ratio. Understand that the actual filesizes on-calc are going to
be a slight bit smaller since calculator files on the computer contain
additional information that is useful for the computer to calculator linking
program.
-------------------------------------------------------------------------------
Documentation regarding the creation of DCS folders
Not created yet.
303
« on: December 14, 2010, 09:09:44 pm »
Still reworking the packer part to Athena. Got a newer idea of generating these files. The initial file will instead have its metadata and data sections split so the metadata will be in its own file.
The data files are going to have names that are generated. The first character will be a theta, the next three are hex digits generated from the project name, and the last four are generated from the checksum of each file. In the event of a collision, the last four digits will just be incremented until there's no longer a problem.
EDIT: As for the windows problem, just look for the .8xp entry in the registry and delete that. It should solve your problem. Make sure you delete *all* entries, too. Some may be more obscure than others, and there may be more than one that's trying to associate your .8xp files with notepad.
304
« on: December 13, 2010, 08:15:40 pm »
This RAM area (or around this RAM area) is used for archiving, as well. Anything that has to deal with unlocking Flash and dealing with it in some strange manner. Not sure what else this area is used for.
It might've been $8100...
305
« on: December 10, 2010, 10:42:03 pm »
Ah ok, I just remember seeing it somewhere before while compression was talked about so that's why I asked. But ah ok, thanks  It'll be a long time before I incorporate any of that into anything I do though 
It's not that big of a deal, though. They've already got a ready-made decompressor for the purpose of sticking it in your (Z80 ASM) program so you can use it to mess with chunks of data fitting of some really huge FlashAPP. On a note related to the project, I have just enough to start working on the Z80 ASM side of things.
306
« on: December 10, 2010, 10:06:21 pm »
This sounds really cool, good luck on it Can't wait to see how this turns out.
Just out of curiosity, isn't pucrunch a compression method?
Thanks for the support! Oh, and pucrunch is a compressor, not a method. pucrunch uses some LZ77/RLE hybrid, as explained in (way too much) detail here: http://www.cs.tut.fi/~albert/Dev/pucrunch/If you can fully understand that, then you'll be all ready to implement it in Axe
307
« on: December 10, 2010, 11:37:50 am »
Just FYI, you can un-group hacked pics once they are on the PC with the WinRAR utility (if you were thinking that that's an issue). I'm not sure how the file names would show up on PC though.
If it can do that, you should probably be able to rename them to whatever you want. The variable's name (when it is sent to the calc) is actually dependent on some name field somewhere near the start of the file. On another note, I've got Athena generating valid .8xp files now, so I guess I can start working on the Z80 side of things pretty soon.
308
« on: December 08, 2010, 11:41:42 pm »
Wow thats some impressive stats right there  Why does it compress into 3 files instead of just one large 42K out of curiosity?
The version of pucrunch that I'm using can only compress up to 64KB at a time. Since I13 is around 130KB and each file is reasonably sized, so it'll create three archives. As far as hacked pics are concerned, if you can get them to the computer, it'll pack just fine. If it really becomes an issue (because I hear that hacked pics can only sent to the compy by group), I might add support for automatic group extraction so it can be included into the project. Maybe. I just want something that works at the moment.
309
« on: December 08, 2010, 10:07:45 pm »
Got in some early results. While I haven't coded everything yet, I am able to get .bin files that contain all the compressed data. I tried to pack Illusiat 13, which weighs in at over 130KB. The end result? Three files that collectively take up around 42KB. (12KB, 25KB, 5KB)
Now, to verify that it's all good and start writing the .8xp packager into the C program. After that, the Z80 part of Athena can start up.
310
« on: December 08, 2010, 05:10:46 pm »
Does it check to make sure there's enough space to decompress?
In short, yes. Your RAM has got to be pretty much empty, though. There are checks in the data stream that tells the installer a rough estimate as to how much space the install will take, and then compare that to the calc's memory. I intend on modifying the pucrunch decompressor so that it'll extract on a file basis. It'll then move stuff to FlashROM as necessary. As such, all files that go into FlashROM will be extracted first, then files that need to reside in RAM will go there.
311
« on: December 08, 2010, 05:05:40 pm »
Yup. People can build archives using this project and then distribute them as their game. It won't take up a whole lot of space since each archive is compressed. The only real limitation is the memory on the calculator. What could end up happening is that some large BASIC game that takes up some 130KB of memory can be archived in like 60KB or something like that.
The limitation with respect to the individual archives is that each archive can decompress up to 64KB. The archive itself may be quite small, but each one will expand to up to 64KB, which means that I can't have some huge as hell single archive, each 64KB (yes, they *will* send to the calc if they were that large. You just can't unarchive them).
312
« on: December 08, 2010, 04:16:49 pm »
Originally started on Cemetech (since there's a load of C coders there who are pretty willing to help), but I'm bringing the idea here too.
As stated in the title, "Athena" is a project to help simplify the installation of large BASIC games. It started when I was reading some thread on Cemetech and DJ Omnimaga mentioned something about me building a RoL3 installer in TI-Basic/CIII. So I figured I would try my hand at building something better. Something that could possibly be used by just about anyone. The project is targeted for the TI-83+SE/TI-84+(SE) users, since they've got crazy-insane archive space for which this is possible.
For users who will be installing these games, you will only need prgmATHENA and some number of data files that are distributed. These data files act as compressed group files. Once you get all that stuff to your graphing calculator (at least read the ReadME.txt that the developer will most likely have put in), run Asm(prgmATHENA) and it will guide you through the installation process. Once it starts, no further user interaction will be needed unless you have to do stuff like garbage collect. No longer do you have to sit in front of a computer and have to send each and every individual file and possibly have to manually archive them. No longer will you have to send group files just to extract then archive the variables. Athena will perform much of this management for you!
If you accidentally delete a few of the files used by the game and if you still have both prgmATHENA and its data files, you may repair the installation by running prgmATHENA again.
Planned is the ability to install files to work with DCS. Which is to say, it will be folder-aware and let you install files in any folder of your choosing (or create your own right then and there if you don't have the folder).
Since the data files are compressed, you'll be able to have multiple large BASIC games on your calculator at the same time. Just uninstall one and install the other if you really want to.
More information will be made available for developers interested in using Athena for their projects. So... tell me what you think.
313
« on: December 01, 2010, 12:33:17 am »
It works on a pixel-by-pixel basis. The method I use accelerates that process so I can test two pixels at the same time.
I suppose this means I'll be revamping my program and doing something with an upload to ticalc or something. I suppose I have enough menu experience to make it work out well. I just don't want to detract too much from the original topic. Perhaps I should make a new topic whenever I get around to rebuilding this old project?
314
« on: November 30, 2010, 10:29:48 pm »
The download is somewhere on UTI. I don't believe I've ever uploaded it to ticalc.org. I gave up on this version because the menu system didn't want to work right. It caused crashes that I couldn't pinpoint.
If I want to take it up again, there will be some improvements needed.
315
« on: November 29, 2010, 10:14:15 pm »
A screenshot of mah little program. Well, not exactly "little". It eats up 4762 bytes oncalc.
Pages: 1 ... 19 20 [21] 22 23 ... 52
|
Show Posts