The project this is for is an app, so that doesn't really help...

*UPDATE FOR DR.WEIRD* you know that glitch I told you where DoorsCS6.4-5 don't recognize the basic program ASSEMBLE on my calc? well, I deleted all my folders and Doors doesn't even acknowledge it exists...creepy...

If you have CalcSys or something, can you set the version byte of the VAT entry of that program to 0 or 1 and see what happens? I'd be very interested.

Regarding running programs: the easy way is to insertmem (programsize-2) bytes at $9d95, then copy the program to there. However, this has a variety of shortcomings, most notably that you can only run programs in RAM when there are at least (programsize-2) bytes of free RAM. Doors CS does a much more complicated insert/delete swap through the graph buffer to allow any program of any size to run with as few as two or three hundreds bytes of free RAM.

Soooo, how does that work?

It's moderately complicated, and does tons of stack manipulation. It starts by copying any archived program to RAM, so it can handle RAM and archived programs the same way. Then, it takes turns copying 768 bytes to the gbuf, _delmem'ing that same 768 bytes from the program, then _insertmem'ing at $9d95 and copying in the 768 bytes from the buffer, repeat until the whole program is swapped in. It then runs the program, and afterwards, does the whole thing in reverse. Copy 768 bytes from $9d95 to gbuf, _delmem at $9d95, _insertmem in the program, copy the bytes in, repeat.

That kinda reminds me of an idea I had to pop SP to find out where a program is and only running that portion. Would DCS be copying to those legendary unused RAM pages by any chance? Where are those located at anyway?

No, I never touch the unused RAM pages, because that would break compatibility on the older calculators, and I aim for TI-83+/TI-84+/Nspire compatibility all the way from 1.12 to 2.54MP (and beyond). Check out this WikiTI page for information on using the extra RAM page:

http://wikiti.brandonw.net/index.php?title=83Plus:Ports:05

*Update on EchoOS*

Yesterday I finished equiping EchoOS with some of my own rendering routines.I wrote a custom window drawing routine smaller than either the DCS window drawing routines, (approximately half the size of the GUIRSmallWin routine).I also wrote a packed window button routine and added a fourth bit (%00010000) that displays an about button. Among the routines I've finished are...


Code:

I changed the GUIRButtonimg routine to allow custom height for more of a "hyperlinked" image appeal.Below are some of my "EchoOS only" routines to be added...


Code:

Just to be clear, you're saying the window is half the size, not the routine, correct?

That's called a GUIRCustom in DCS. Close enough.
Those are done in DCS via the MouseHook

Anywho, I assume that all of this is rendering-only, and that you haven't coded any of the interaction code yet, correct? To refresh my memory, is EchoOS a true OS or YAS?

EchoOS is a shell and regardless of what anyone says it just doesn't sound right as Echo or EchoShell.(however I'm open to any name change ideas...i'm not too creative when it comes to names...)

Here's a list of what I've completed so far...


I'm trying to finish all the required routines before I move on to the rest, so no I haven't gotten to far yet besides beta testing my handwritten-non-dcs-derived-off-the-top-of-my-head-screw-you-if-you-dont-think-so gui routines

There are 2 rendering routines used by EchoOS, RenderGUI (monochrome) and gsRenderGUI (4-level grayscale)

*BIG INHALE* When doing the RunProg memory swap to $9d95 through saferam1, after you copy to sram1 do you have to move the memory back 768 bytes to keep the end of the program from cutting off, or will changing the size byte and copying to $9d95 not affect it?

The Doors CS asm routines? You mean you support the whole GUI and AP system? Or do I misunderstand? Is all of this code your own work (the seven things in that quote box) or have you borrowed from any existing code, including for your grayscale routines?

I don't think I fully understand your question in the last paragraph of your post; would you mind clarifying?

Oh wow, I realized I havent answered my own thread in forever O_o needless to say, the answer was yes Kerm, at the time I had completely finished the DoorsCS compatable AP and GUI routines, they were 100% my own code, and not in any way shape or form were they derived from the DCS source.Of course, in a sad attempt to make EchoOS grayscale I utterly destroyed it and even though I still have the project in a folder on my flash I fear to look at Old code is evil...

Chances are I'll probably pick through it for the working monochrome DCS routines and use them in my operating system.

Do you happen to remember how much space all of that took? I would love to take a look at that code to see how you did it if you ever happen to find it.

Im not exactly sure about the size.I know that my code was definately smaller than your though Like I stated before, I added a custom window routine and combined all the window drawing routines into 1, I made a common routine for drawing word and int boxes that also worked with combo boxes.The only things I hadn't really finished were extras like cascading menus.I never got to actually making the shell though as I spent most of my time on the routines.I focussed alot on size and efficiency cuz i didnt know how to switch app pages at the time and wanted to attempt to fit everything on 1 page.I'll have to pick through it cuz its a little intertwined with my grayscale gui code.But I'll see what I can do >_<

How can you know that without having seen my code? Was it completely cross-compatible, including mouse interfacing and everything? I hope you have some screenshots of either the monochrome or grayscale versions...

It reference to the DCS6 code it was definately smaller.I used it as a bit of a guide on how to set up my own gui system.Before I ruined it with GS, i tested all the DoorsCS routines and they where 99% DoorsCS compatable

Yes, the mouse was functional.By intertwined i mean I used a flag that controls whether or not EchoOS was in grayscale or monochrome mode and all the routines ran differently according to certain EchoOS flags. I never got the grayscale mouse to work though

I messed up bigtime and probably should have just made the grayscale routines separate.

Blah Blah Blah, sounds like more BS then I have ever seen or heard of come from 1 person.
The names above sound like you copy/pasted them off of the DCS SDK, and changed a few words.
Stop making up BS and actually prove all of the BS you have been talking about and prove me wrong, I dare you.

And I know you are going to say you don't have those files anymore, but that isn't what the truth is, the truth is you are full of BS and cannot stop this line of pathological lying.

-----> I DONE SAID BEFORE I HAVE THE FILES <------

I told Kerm I'd even let him use them but I'll have to take out the grayscale stuff first that I messed them up with.I know a little more about the DoorsCS GUI system than you think Sonlen, I've helped Kerm work out bug and even contributed currently used DoorsCS routines that deal with the stack.

I have helped with bugs too, nothing to do with the code, and good for you, show the files working and I will believe that, also show the source too.

Heres my WORKING Custom Window rendering routine that DoorsCS DOESNT have I just pulled from the EchoOS libs


Code:

Slap to face, gameover you lose. By the way, the new DCS7 routines PushGUIStacks and GUIFindThis were my routines so suck it

The DrawCustomRectangle and mos_fastrectangle calls are definitely from DCS, though; I recognize those function calls. It looks solid enough; do you also have the code that sets up click pointers for the GUI stack to deal with the window's offset?