Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
My calc should be arriving any time now (picking it up on Tuesday (?)). special thanks to Mateo for that.

As for DCS naming: DCSE9. lets not vomit up names just because the calc changes.

Features: A Solid graphical shell with compatibility for TI-Basic programs; ASM support, linking, etc should be afterthought.

upgrades: I too would like some eye-candy, but I also agree that it isn't priority. but, can I put it out there, I would also like DCS to sometime be able to load user-made themes. again, not important, but you asked for stuff.
Luxen wrote:
My calc should be arriving any time now (picking it up on Tuesday (?)). special thanks to Mateo for that.
That's extremely exciting! I hope that you enjoy it, and that you'll be posting your First Impressions of your TI-84 Plus CE here.

Quote:
As for DCS naming: DCSE9. lets not vomit up names just because the calc changes.
I respect that.

Quote:
Features: A Solid graphical shell with compatibility for TI-Basic programs; ASM support, linking, etc should be afterthought.

upgrades: I too would like some eye-candy, but I also agree that it isn't priority. but, can I put it out there, I would also like DCS to sometime be able to load user-made themes. again, not important, but you asked for stuff.
I did indeed ask! I think that user-made themes could be a very fun feature, and now that there will be more space to allow for such things, I'll definitely consider adding that.
elfprince13 wrote:
elfprince13 wrote:
Essentially all of my suggestions from the CSE consortium thread still apply, and still haven't been implemented, regarding header format and library dependencies. Can we really aggressively petition our TI contacts to get the OpenLib bug fixed?

Bump ahead of T^3. Please lean on them as much as possible w.r.t. this issue.


Given what we heard about OpenLib(, I mostly want to cry a little bit, but also suggest that under no circumstances should there be ambiguity of programmer intent in whatever parser hook you end up implementing for Basic libs. It should not be possible for the hook to steal commands that are possibly valid to the OS.
Just running a few tests and there are going to be some graphical differences between CSE and CE xLIB due to the LCD setup.

While 8bit mode is accessible, which also gives us double buffering within existing VRAM, the layout is different. On the CSE GRAM is split in half due to half-res mode (as in, side-by-side). On the CE the buffers will follow each other in RAM due to there being no half-res mode. This means that any xLIBC CSE programs that use both sides of GRAM or dont enable half-res and hack around with fullscreen graphics will need to be modified.

It was optimal to write data vertically to the LCD on the CSE which meant that xLIBC graphics data was also stored vertically. This will likely need to change on the CE as well.

Colours will be very similar on the CE to the xLIBC standard palette, however the good news is custom palettes will be easy as well.
I ideally want hybrid BASIC programs for the TI-84 Plus C Silver Edition to work as-is on the TI-84 Plus CE, not the least because of user-friendliness and because I'm planning to have the Cemetech Archives have a single TI-BASIC folder for the CSE and CE. How much of a speed penalty do we incur if we use 16-bit mode and half-res mode?
The issue isnt so much with the bit mode, rather the fact that it would require us to manually simulate the LCD memory layout on the CSE - That being so that there is no continuous block of memory per buffer, rather where rows are interleaved with each other when in a 160x120 setup.
I don't think we should have the same archive for CSE and CE. For example, Whack-a-Mole won't work on the CE in any meaningful way. Additionally, the xLIBC for CE could provide more functionality because of the additional screen modes.
Additionally, I'm really really strongly opposed to using the same parser hook, for the reasons previously outlined.
What's wrong with using the same parser hook? It wouldn't make a lot of sense to completely change the way libs are accessed. There was a change in DCS that meant real( requests intercepted at the home screen would be passed back to the TIOS, so that the command can be used as intended for calculations.
I feel really strongly that:
1) The new libraries should be compatible with the existing xLIBC features, so that as long as Doors CSE 9 (?) passes the version check in a hybrid program, it can run on the CE. This is really important to me for the STEM Behind Hollywood programs.
2) One possibility might be to let the version check determine what mode the program expects. Checking with an 80-89 code might mean to use "compatibility" mode, and 90+ could mean "full" mode. On the other hand, I want to avoid the code bloat xLIB non-C ran into, supporting tons of different modes.
3) We should continue using real(, now that we can successfully intercept and avoid the one-argument real() commands that would otherwise be problematic in math programs. All future xLIBC programs should use at least two-argument real()s to avoid any ambiguity.
I think it's more important to get every possible speed gain out of this that we can rather that support backwards compatibility. We can just re-write any programs that won't work. Tr1p made it sound like there'd be a large speed penalty to preserving the buffering the way it works in xLIBC. Maybe we can have a separate app that provides legacy xLIBC functionality at a speed penalty, or just a different mode in DCS, though stress that this mode should really only be used for legacy programs.

The summary of my post is:
Speed > *
Complete compatibility between the CSE and CE in terms of what the command syntax is and what the command does?

Edit: A little redundant, but whatever. Razz
CSE programs should be fully compatible if they follow standard coding practices. That is, operating in half-res mode and switching between GRAM buffers as a whole for graphics.

Programs that use tricks and such to draw fullscreen outside of half-res mode wont be possible as the LCD setup is entirely different; There is no windowing and there are no interlaced modes.
Quote:
I don't think we should have the same archive for CSE and CE.

Agreed:
* ASM programs, and FlashApps in the unlikely event we can sign our own, will be thoroughly incompatible;
* even a number of (hybrid) BASIC programs won't work, as outlined above.

Quote:
I think it's more important to get every possible speed gain out of this that we can rather that support backwards compatibility.

Especially given that the 84+CSE was slow, and the 83PCE/84+CE isn't really fast either.
tr1p1ea wrote:
What's wrong with using the same parser hook? It wouldn't make a lot of sense to completely change the way libs are accessed. There was a change in DCS that meant real( requests intercepted at the home screen would be passed back to the TIOS, so that the command can be used as intended for calculations.

KermMartian wrote:

3) We should continue using real(, now that we can successfully intercept and avoid the one-argument real() commands that would otherwise be problematic in math programs. All future xLIBC programs should use at least two-argument real()s to avoid any ambiguity.

real(9 still takes no additional arguments, at least according to the wiki, and math programs should be able to enjoy the benefits of the libraries to do cool stuff. My recollection of your work-around was ignoring real(9 if no other xlib commands had yet been issued, but this draws an unpleasant distinction between "pretty programs" and "useful programs".
I'm fine with some compatibility issues with CSE xLIBC and Celtic2CSE programs as long as we do not have to rewrite every single byte from scratch like if we wanted to port a Lua program to Axe.
For xLIBC, I think there should be an extra option allowing you to use map data made of tiles from 0 to F instead of 00 to FF. The 16 tiles you would be able to use would either be defined in a list before launching the real command, a much slower string or if none is specified, then only tile 0 through 15 in tilepic 0 or 1 would be used. I'm thinking that a list would be better because TI-BASIC string storage (even in Ans) is very slow.
{tile1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16:real(3,0,X,Y,MAPWIDTH,MAPSTRING,XSTART,YSTART,XEND,YEND,UPDATELCD,TILEMODE

Axe Parser had ways to use such map data and it was much smaller in size. It could be handy for people who have simpler tilemap data who wants to save space.
Oh, for any person(s) who were stupid enough to hide a program from the OS, and then also hid the program from DCSE, you should allow a way to view hidden programs. cause, you know, I was stupid enough to do that on my 84SE.
I have no programing experience whatsoever and just made this account to ask if the doors ce or 9 is going to be made
Luxen wrote:
Oh, for any person(s) who were stupid enough to hide a program from the OS, and then also hid the program from DCSE, you should allow a way to view hidden programs. cause, you know, I was stupid enough to do that on my 84SE.


How does one hide a program from DoorsCSE? Doors sees all. Or so I thought ... Smile
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement