Author Topic: NexGenGS (Read 16819 times)

Insanity · « **Reply #60 on:** April 01, 2007, 03:06:00 pm »

Damn. That was freakin' good.
MarrigeOS has competition.

Jon · « **Reply #61 on:** April 01, 2007, 03:16:00 pm »

Hey now, don't diss MOS just cuz' your calc is stuffed to the rafters

bfr · « **Reply #62 on:** April 01, 2007, 03:19:00 pm »

Great joke! :lol:

Halifax · « **Reply #63 on:** April 02, 2007, 06:30:00 am »

Haha thanks guys, but I am definetly not doing anymore jokes like that anymore. Its too much freakin work.

Halifax · « **Reply #64 on:** April 09, 2007, 11:03:00 am »

Ok new idea I am just throwing it out there. But everybody knows after release that people don't just go and update their programs at the drop of a dime. So what if you could expand NexGenGS libraries with your own code that other people could use to?!?! Basically im thinking of it like this. NexGenGS has an expansion handler. It will allocate the libraries accordingly and keep a table of where they are. Then people wanting to develop libraries would make their code and then make a jump table and an include file that holds offsets to the routines. Then the program using these libaries would have a table that has the offset. The program would then query NexGenGS for an offset to the given libraries and the program would add that to all the offsets so then they could call the routines. So what do you think I haven't written/ironed out these plans but I plan on it. Oh and the libraries would be in appvars.

bfr · « **Reply #65 on:** April 09, 2007, 11:07:00 am »

At the moment, it doesn't really seem like a bad idea

, although there may be complications I haven't thought of yet....

Halifax · « **Reply #66 on:** April 09, 2007, 01:19:00 pm »

Yeah same here bfr I am trying to get this all down on paper how I am going to do it. But I know there are going to be complications with it.

Liazon · « **Reply #67 on:** April 10, 2007, 10:49:00 am »

An interesting idea, but be sure to include some kind of development documentation for dlls compatible with NextGenGS. SDK, template, docs, something to inform people about any format issues that could exist in the implementation of this system

Halifax · « **Reply #68 on:** April 10, 2007, 11:25:00 am »

Liazon: NexGenGS*

Yes it will be all documented out in nice pretty html and very descriptive. Liazon why don't you help me develop this? It would make it go a hell of a lot quicker.

Liazon · « **Reply #69 on:** April 11, 2007, 10:17:00 am »

I'll probably be really busy until about January '08

so I probably can't off much more than advice. I'm sure you'll be fine though

Halifax · « **Reply #70 on:** April 11, 2007, 12:09:00 pm »

Yeah I'll be fine with it I just wanted it to go quicker. I actually want to finish this soon so I can get it on my calculator. Actually no part of NexGenGS has touched my calculator yet

Fallen Ghost · « **Reply #71 on:** April 15, 2007, 11:15:00 am »

Can you guys tell me what's the use of a one-program only library? (like adding your new library for your own program)

Because you will have to: 1.transfer the library with the program, as you don't know if user has it
2. Having the library or inside the program takes the same place
3. Allows less modification of code.

If you had 3500 programs that were going to use the same and exact routine you have, then put it already in the shell, it'll be less trouble. If you have specific routine, put it in your program, you will customize it even more, it'll go faster and take less space.

Please tell me why.

Halifax · « **Reply #72 on:** April 15, 2007, 11:31:00 am »

Who said it was a one program only library. It would be like a DLL. Say NexGenGS dies somewhere down the road and people are still using but a new shell comes out with some great libraries so someone builds it into ONE dll that can be sent to the calc and then every programmer for NexGenGS would have access to the routines of the other shell without having to program for the other one. That was kind of the point. I didn't really understand what the hell you were talking about?

And its not for one program every programmer would be able to use it if they had knowledge of how to use the DLL. That's the point so every programmer doesn't have to include 10 libraries into their program instead of having ONE dll with all 10 libraries that each of those programmers could use so then they have more space in their program. As I said no one updates their stuff at the drop of a dime.

KermMartian · « **Reply #73 on:** April 25, 2007, 02:10:00 am »

The concept of external libraries was first implemented in SOS for the TI-83 line of calculators. I included support for them in Doors CS (I call them ALEs, Appended Library Extensions), but I no one has used them so far and I'm pretty sure the idea is mostly useless. You can take a look at how it handles ALEs here:
http://dcs.cemetech.net/index.php?title=ASM_Header_%28Doors_CS_6%29

Halifax · « **Reply #74 on:** April 28, 2007, 07:38:00 pm »

Here is a NexGenGS mockup of what it will look like and function like. As you can see I have taken what bfr has asked and implemented it in this mockup.

user posted image

The Mockup Explained:

The program icon and name that is inverted is the program attributes that are displayed in the top bar. It's Archive status,lock status, and size. You move the cursor around over the programs and folders with the arrow buttons. The X and the bottom of the screen means you can't scroll down anymore. The arrow at the top of screen means that you can scroll up more. Oh and that dropdown button with the NexGenGS logo is a secret. Ssshhhhh... More info on that later...

Author Topic: NexGenGS (Read 16819 times)

Insanity

Liazon

Liazon

Fallen Ghost