While we're on the subject of new directories, why not create separate directories for Doors/kernel programs and NOSTUB programs? That would be a good idea and would allow for easier navigation. Just an idea (but originally Link512's-see TICT TIGCC Message Board).

-Scott

I second the motion. NOSTUB programs should get their own dirctory for many reasons. (1)Currently NOSTUBs are in the ASM directory. They're not ASM; they're C and having them in the ASM directory implies you need an annoying shell to run the darn thing, which is why many newbies stick so vehemently to Basic progs. (2) As stated NOSTUBs aren't ASM, so they shouldn't be in the ASM directory. However, this does not imply that they should be delegated to the Basic directories. NOSTUBs appear to offer the best of both world, the speed of ASM and the ease of Basic, yet are still seperate from either of the two. Because of these reasons NOSTUBS should recieve their own directory.

As a side note I think you should be able to search, at least for games by genre. The genres could include action, shooter, RPG, etc. (To speed this up you could have the authors themselves specify the genre.)

I strictly disagree with your statement that NOSTUB programs are C, not ASM. They ARE asm, but the other fact is that they are usually written in C and translated to ASM by the compiler. For example, Kevin Kofler write his programs in pure ASM, and they are NOSTUB programs. And, you can code in C programs which are _not_ NOSTUB_ programs. The fact whether the program is NOSTUB or not is independent of used programming language. This is only a matter of coding stile. Yes, currently it is usually easier to code NOSTUB program in C, but this is not a rule.

I third the motion, but would like to point a few things out.

Whether a program is nostub or requires a kernel is completely language-independent. The difference: whether doorsos.h or nostub.h is included. A perfect example is version 7.x of Patrick Davidson's "Phoenix" for the 89. It is assembly, but nostub. C programs are written for Doors as well as nostub, btw. I know there are some, but can't think of any now, because don't like shells (they crash too much and have a long delay on compatibility with new amses, since TI prefers backwards-combatability over backwards-compatability, at least for compiled programs). The binaries of C programs are translated into assembly anyways by the compiler, and then appended to the appropriate libraries in the linker (these are libraries included in the binaries, not the ones used by shells such as Doors). Assembly

disclaimers: I know there are other shells out there, but used to use doors before I found it to be too unstable and waited months for it to become compatible with ams2.05. I am completely inexperienced at programming anything beyond TI-basic and very simple c programs for my computer, so I may have inaccuracies in the previous paragraph.

Going further into NOSTUB/Kernel separation, it would not be hard to find out which programs currently in the archives are NOSTUB. In appr. 20 minutes I went through the 89 asm games archive, letters a-c, and was able to find 13 programs that I am sure are nostub and about 11 that did not clearly say in their readme or description. The ones that do not say would be easy to go through with VTI: just get 10 or 20 people to test 5 or 10 per day. In this way, the whole 89 and 92+ archives could be gone through in not much time. After that, people could just upload their program to the designated nostub directory.

-Scott

Great! Now do the same for ARPGCS games!!!

this whole eBook idea is awesome,but one thing,i still cant get the damned thing to work,can someone help me?

I know this might be a bit off topic but, i figured i'd ask it anyways. Is there any way that a e-book program fcould be created for the TI-86? Because, I'd really like to be playing games and learning PHP in math class :)

Jim

It would be possible, as long as it was a very short book.

Why not just make books in Chapters for the calcs with smaller memory?

I am working on one for the 83+/83+SE (it isn't done, and unless there is some uber-guru out there, it will not be compatible with that of the 89/92+), and of the z80 calcs, only the 73 and 86 would be possible for it to be used on (after ported), because they are the only ones with sufficient ram or archive. (unless you wanted to cram it into 27 or 28K, 82/83/85)

I had written a very inefficient one in ti-basic for 83/83+ (eg 150% of the text's size), and will send the format, and ideas to you if you email me.

So why are two folders needed? The same ebooks will work on an 89 or 92+ equally well. Of course maybe the ebook documentation would have to be updated to tell one group where to find ebooks in the folder of the other group.

This would simplify things for the archivers.

I think it would be great if they would make E-books for the 83+ but it hard considering that the 83+ does not have a lot of mem.

But with the TI-83+ Silver edition... Since it has 10x the memory of the 83+.

Not in the RAM area just in the Flash so it does not matter much.

You mean the 83+ doesn't have an archive?

Sucks to be you, especially with the SE.

Yes it does, flash is the archive

Yeah, but to be able to run anything, you have to copy it from the archive to the RAM, so your program size is pretty much limited by the amount of RAM you've got left, which on the 83(|+|++), isn't much. There are some assembly tricks to increase the amount of RAM you can have, but the amount gained isn't very substantial.

Ummm...no...
You can stream the information from another program without actually RUNNING the program. Games that use external levels do this.

That is true, but you can use other programs, appvars, etc in archive to store data. It (83+ book reader) will get finished sometime, I have it searching through the symbol table now, only the chosing of the book left to do (which I am working on when I am not browsing the internet).

How my program handles it is to load the current page the person wants into a text buffer and then display them (this is slower than direct coping, but buffered allows for archive/flash access)
I will put up a web page when I have time, or get tired of z80 asm :)

Just for the record: There will need to be an 83+ directory soon enough.

Now if I can just finish the search through the symbol table, create the selection menu, and finish the (very poor) compression :)

Anyone know how to do good compression on a z80?

i'll work on it, but just in theory...