First and foremost, I need an introduction into how OpenLib/ExecLib work, especially if I'm going to use them as part of a polyglot header for Doors CS ASM programs. I definitely would appreciate his and your help, of course; perhaps you two can work together in a topic here on Cemetech to understand what Hybrid BASIC programmers like Merth and TIFreak8x and DJ_O (and others) want from a TI-84+CSE hybrid graphics library?

I don't think a GUI API is something to throw out entirely. It might be nice to simplify it, so that it's less flexible but faster and easier to use. For example, you could probably remove native support for modal dialogs and just leave in some flexibility so people could hack it in themselves if they really needed it. It would also be great to add more callbacks for GUI elements. Also, a PC-side GUI designer would be super helpful.

A good feature for the GUI API would be support for primary GUI structure definitions to be able to be kept in flash. Each item might have a reference number into a list with a pointer to the GUI element's volatile data. Thus, a flatter, less recursive model could be used, allowing one to move the volatile data list into scrap RAM. That, in turn, would make initializing the GUI easier, so programmers could pull it up quickly for, say, name entry, and then dismiss it again.

Also, the OS only seems to use RAM pages 6 and 7 for scrap in various places (right?). DCS should have some support for that RAM. . . . let's call it XRAM (eXtended/eXtra/eXternal/idontcarewhatXstandsfor RAM). We should really brainstorms ways to maximize use of that extra RAM, because it adds possibilities.

DrDnar, I agree. The GUI API sets DCS7 apart from its competition. It would be a great shame to omit such functionality. What do you want to create? A shell, or the best shell?



Since you mentioned that, shaun has added such functionality to TokenIDE for DCS7 GUIs. It does however, only give you TI-BASIC code rather than ASM. Nonetheless, very useful.

First I want to create a shell; by definition is will be the best (since it will be the only) shell. Then I'll worry about spending time writing fancy features for it, once the core list-and-run-programs bit is working.

DrDnar: While I have you, I had a few technical questions for you. First of all, I used to use gbuf as a 768-byte area to swap programs into and out of UserMem. Can you recommend any same-sized replacement, or should I use the smaller 531-byte stats RAM (and call whatever I have to call to mark it invalid somewhere)? Also, I think we're missing equates for a few OS features I need, but I'll double-check what those are. Obviously I can also look for some of them myself.

That's cool. I think if you get there first, and make continual updates, DCS8 will be a shell that appeals to the nonprogrammer student sector of the userbase AND the programmer sector.

Code:

Are savesScreen and plotsScreen still 768 bytes?

Thanks, I saw those but wasn't clear about what the savesscreen and plotsscreen entail. Does this mean they kept them as two 768-byte storage areas even though they don't correspond to real LCD things anymore?

Edit: tr1p1ea barely ninja'd me to the same question.

That's my understanding. MicrOS, in particular, uses most of plotSScreen for the IVT and other stuff.

One thing I'd love to see in a shell is the custom menu that Omnicalc added. It let you, from the catalog, press On+<a number> and it would add that command to a custom menu. This menu was found by pressing [VARS] twice. I think having at least 10 entries (On+0-9) would be great. Especially with how slow it can be to go through the catalog on the Color, this would be incredibly useful.

Also, of course, enabling lowercase letters

As I'm still not sure how slow (or rather how fast) the CSEs' Basic programming language will be compared to the painfully slow Prizm Basic, I am hoping that Doors for this calculator will give some commands (more so for the graph screen) speed boosts. That is my problem with the Prizm as of now.
Good luck!

That's a superb idea, although I'm not sure that Doors CS would be the best to offer it. If I have space for it, I can certainly consider it.

Yup, that goes without saying.

Zelda: It's pretty fast (or, I should say, no slower); the only thing that's slower is working with the screen, so scrolling the homescreen, drawing on the graphscreen, and so on. With the help of whatever form xLIB is in by the time Doors CS is ready for a first release, we hope to ameliorate that.

*bump*
- I found that progToEdit is at $8511
- Where are _GetBytePaged, _EnableAppChangeHook, _fillBasePageTable, _OffPageJump, _chk_batt_low, and _cleanall?
- I dread writing my code to interface with the editor context. Soooo many bcalls and RAM areas.

*bump bump* DrDnar helpfully explained that _GetBatteryLevel was what I wanted, and that it returns 0-4 for the battery level, where 4 is full and 0 is ZOMG NO BATTERY. I still need equates for the following:
- _GetBytePaged
- _EnableAppChangeHook
- _fillBasePageTable (I'm using _maybe_fillBasePageTable atm)
- _OffPageJump
- _cleanall
Thanks in advance if anyone can provide insight.

This is what allows you to edit a program in DCS then quit back to DCS, right?

Unrelatedly, I suggest we look back at DCS1 and work on porting that. Maybe DCS3 or before it gets too complex. I currently think calling this iteration of DCS "DCS 8" to be misleading as you don't typically take many features away in the next release. Perhaps calling DCS 8 "DCSC" then proceeding with DCSC2, 3 4 etc.

_GetBytePaged and _OffPageJump are for chaining raw key hooks for things like the ON-APPS feature. _EnableAppChangeHook is for catching 2nd-QUIT from Prompt and Input. _chk_batt_low is to keep your Flash un-corrupted during Flash writes. _cleanall is to wipe out temporary programs (the OS kind). I have found all of these on my own now and completely built the first version of DCS8.

I hear your point about Doors CS C, but I think for clarity (and since I'm going to stick with starting from the Doors CS 7 codebase), I should make the next version 8. I'm willing to consider more dissenting opinions, of course, especially if many of you agree with Alex.

[quote="KermMartian"].... completely built the first version of DCS8./quote]

Release a beta

Built != Functional. All that means is that I pulled over source from Doors CS 7 and found all of the BCALL equates that I needed. It doesn't mean that it is functional or even has all the routines it needs (the sprite routines and sprites are all dummies, for example).

*bump* Presented without comment:

That looks pretty awesome.