It's official: the TI-84 Plus CE is coming, and the TI-84 Plus CE's features and technical specifications as well as my chat with Dr. Peter Balyta indicate that ASM programs will need to be overhauled to work with the new calculator. Here's what we know and guess:

• The processor is an ez80 with ez80 and z80 modes available. The OS defaults to running programs in ADL (ez80) mode.
  
• There is now at least a 256KB RAM chip and 4MB of Flash memory. It appears that Apps no longer need to be multiples of 16KB (!!).
  
• The user RAM is ~154KB, indicating that user programs reside in the 24-bit address space.
  
• The LCD is memory-mapped. It is not known whether direct port access is also available, although we believe it is. More importantly, it's not known whether we can still put the LCD into half-resolution mode, which is important for xLIBC. Significantly more RAM would have to be spent on a back buffer (1*120*160=19200 bytes) if the LCD cannot be put into a half-resolution mode.

The upshot of all this is that tr1p1ea and I are going to have to put some work into Doors CSE and xLIBC to port them to the new calculator. We have a lot of decisions to make, including (but very much not limited to) the following:

• Should we keep the Doors CSE and xLIBC names or switch to Doors CE and xLIBCE? I believe we should keep xLIBC's name, because I want us to make the API 1:1 compatible with xLIBC. In other words, I don't want xLIBC BASIC programs to need to be modified at all for the TI-84+CE. I'm less sure about Doors CE vs. Doors CSE. I'm very hesitant to have three different products: Doors CS, Doors CSE, and Doors CE; that seems as confusing as the TI-84 Plus C Silver Edition and the TI-84 Plus Silver Edition and the TI-84 Plus CE. I'd prefer to call this new edition Doors CSE 9 (or Doors CSE 10, if you prefer Windows jokes). Thoughts?
  
• Should Doors CSE/CE include CALCnet? From what we know currently about the available connectivity options, namely just a mini-USB port, it looks like I can't simply connect all the calculators in parallel anymore. I'm inclined to devote my time to features that are used more often.
  
• What other TI-BASIC routines should we offer? At the moment, I'm inclined to keep the existing Celtic II CSE and xLIBC functionality, although of course all of that will need to be modified for the ez80. I also want to add the routines requested by our programmers in the appropriate Doors CSE topic, like listing programs/AppVars with a particular header, copying arbitrary bytes from a program/AppVar to a string or to another program/AppVar, and adjusting the brightness of the screen.
  
• What (other|any) ASM routines should we offer? For the sake of compatibility, I'm inclined to offer the existing sprite routine, hopefully sped up for the new screen.
  
• Should we try to make Doors CSE/CE compatible with both the TI-84 Plus CSE and the TI-84 Plus CE? I'm torn on this one. I'm considering, for now, simply adding the new Hybrid BASIC commands to the TI-84+CSE version, and make the TI-84+CE App be its own entity. In fact, because of signing keys, I might not even have an option here.

What other thoughts do you have? I'm open to all suggestions and comments, although please be aware that I have extremely limited free time to actually work on this at the moment.

If there are still sufficient OS hooks available, I would definitely think that making it possible to use archived variables in a read-only fashion (like in the 68k series) would be amazing, especially for BASIC program execution. It should be theoretically possible, considering the flat address space.

I wonder if anyone remembers Codex or not? There are a few handy tools BASIC users can use to make some cool effects that might not be available in any of DCSE's libraries.

http://www.ticalc.org/archives/files/fileinfo/318/31824.html

There is still much to learn about the CE, particularly surrounding LCD capabilities. As mentioned some form of half-resolution mode would be very welcome and could pave the way for well performing applications and games!

I like the numbering scenario with DCS as well - TI's naming conventions are becoming quite convoluted! .

As far as xLIBC is concerned I second the notion to keep it as compatible with the CSE as possible. There may be some speed differences between the 2 models due to processor differences. At the very least functions and argument layouts should be the same. It does remain however to be seen if the CE has OS hooks like its predecessors.

On the pus side, loving the ez80 and the extra RAM. Just hoping we can find out more information soon .

I like the idea of keeping the Doors CSE and xLIBC names, and hopefully compatibility is possible.

As for CALCnet, I would consider the pros/cons of implementing something like that. Perhaps at a latter date it might be a good thing, but right off the bat it might not be necessary.

As for ASM functions, I agree that sprite routines are a great idea.

Good luck, and hopefully this will become another great staple in the DCS family!

I was looking through it a bit, and I was wondering if any of the functions in particular were especially attractive to you as a TI-BASIC programmer. This goes for all of you. However, do keep in mind that the focus of the first release will be compatibility rather than new functions, so we may not end up implementing a host of new Hybrid BASIC functions.

Agreed: we don't want to have to come up with new Doors CS/CE/CSE/etc for the TI-84 Plus CE-T, the TI-83 Premium CE, and so on, so I think calling our TI-84 Plus CE/TI-83 Premium CE version Doors CSE 9 with xLIBC is logical.

I hope so; I believe TI has made only minimal modifications to support the larger address space and presumably memory-mapped LCD. I wonder if it's at all worthwhile to try to add a compatibility layer for TI-84 Plus C Silver Edition assembly programs? I'm inclined to feel that there were sufficiently few that it's not worthwhile.

Absolutely!

ASM programs will almost definitely need to be re-written; there's a good chance TI-BASIC programs can be compatible.

Agreed. It's always been more of a feature to show everything that these pocket computers are capable of rather than a vital feature used by the majority of the calculator's users, of course.

Excellent! In fact, will you consider making Portal CE a Doors CSE ASM program rather than an App, now that ASM programs can be huge? I'd love to do what I can to entice you, including offering a more expansive set of sprite routines.

Thank you!

*bump* Inspired by a discussion on our staff channel about Mateo's ongoing impressive work, I was thinking about whether it would be worthwhile to add some kind of automated monochrome ASM (and/or TI-BASIC?) translation layer to Doors CSE. For assembly programs, bcalls could be interpreted and translated to the correct address, graph buffer writes could be intercepted, and LCD-related bcalls like _vputs and _puts could be sent to custom versions of those routines. However, on further consideration, I think it would be much saner to simply work together as a group to contact authors of the original programs and publish polished ports of the originals, perhaps with some effort made to replace sprites with color sprites, for example. I certainly would enjoy those sorts of projects.

Basically, it is my opinion that having a parser is impossible. Not only would you need to intercept bcalls, and writes to the LCD, but the locations of safeRAM have changed. So any time a variable is loaded from safeRAM, which tends to happen quite a bit, it isn't going to work correctly.

My project tends to go along the second idea, which is just to be able to easily modify assembly programs in order to have them run on the CSE with minimal effort. A translator would be awesome, but theoretically impossible without creating a monochrome emulator on the CSE.

In addition, monochrome 1 color sprites are implemented, and DCSE routines work just fine. The thing I'm working on is really just a side thing to see how it would work to draw the monochrome buffer on the CSE.... It's not really too neat.


Sure! I'll see what I can do; my sprite routines probably are very different though.

Personally i think keeping the CSE name is a bit confusing, unless the same binary works on the CSE as well (EDIT: and with the lack of paging on the CE, i doubt that will be the case). I imagine a lot of users will see the 9 (or 10) and think that it's an update for the CSE. Also, users with a CE will see that it says CSE and not download it.

As for saferam locations, most games stick to the saferam locations listed in ion.inc, at least up until a few years ago. I'm not sure about "intercepting" calls (i'm not sure how that would work), but on first run of the program perhaps it'd be possible to prompt the user if they want to attempt converting the program over (with a message stating that there's a good possibility it might not work correctly).

But depending on what is actually possible with the new calc, it's probably simpler to port programs individually (and let them use full color/full screen).

Regarding RAM, i imagine programs will still mostly be stored in Archive space, so i don't think having 19kb of free RAM is really an unreasonable thing to expect (and perhaps there will even be a saferam location for this?), i'm just not sure how long copying the data over will take. I'm not really sure how pipelining and stuff would work on an instruction like LDIR (which in the manual's description is called CPDR ). It says it takes 2+3*BC cycles.

Hate to have to be the one to bring this up, but do you think given the somewhat higher specs we could have some eye candy?

The #1 feature I think of when I use Doors would be the ability to run programs for older calcs. I know this may be impossible, but just saying it's what I think of. Or maybe it could have built in support for USB stuff like a flash drive so you can open it in Doors?

I mean those three sound a little fantastic but DCS/E was already solid, there's not so many features to add.

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?

As I have thought more about this, I definitely agree. I don't think it's worth my time to implement a translation layer at this point. Programs could be isolated in a separate z80 address space, which would allow it to use things like safeRAM properly, but it would be hard to give programs access to the VAT and the LCD.

I can imagine, but if they're fast and good, perhaps there's some kind of compromise we could reach, especially if you think your sprite routines could benefit other ASM programmers using Doors CSE. In what way are they different?

So you vote for this version being called Doors CE? I worry that has too many Windows CE connotations, although I definitely understand and agree with your concerns with the "CSE" name.

I suppose so, but I'd rather get the core shell working first and worry about eye candy later.

As you can see from the discussion above, it would be very challenging, and probably not worth the effort.

Thank you!

I'd really like that. I'll ask around to see if I can find out if it has been fixed.

Thank you =)

Disclaimer: I haven't read the thread to see if this has been posted.

I'd really like a routine like ClearLCDFull which allows you to specify the color. Ideally it'd run faster than ColorRectangle, and it'd save me from having to either use ColorRectangle or write/copy-paste my own LCD clear routine every single time I start a new project and don't want a white background.

That can't be too difficult to implement yourself, especially if it's memory mapped and all you need is an LDIR or ld (hl),rr loop.

True, but since some loop unrolling would be a bit faster than a straight ldir, it might still not be a terrible idea to provide such a routine in Doors C[S][E].

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

Now that I have my CE (just arrived 4 hours ago). I can help test. As long as it cant permanently blow up my new toy, Im good to go. lol

Ive also noticed that there are 3 catalog functions that are not available on the CSE:

* FRAC-APPROX Answer
* Get(
* Send(

So not EVERY BASIC program will be cross compatible. Although, with those three new commands, I dont see many people using them. FORWARD compatible from CSE to CE/T should be fine.

Do we really still not know the ez80's clock speed? I was going to take mine apart and check out the part numbers on the processor, unless someone already did that.

Already noted in our First Impressions thread.

According to the Documentation thread "The CPU seems to be clocked at 48MHz".

I always seem to be behind when it comes to calculators. lol On Android though, Im right at the top. lol funny