Hey. How much more do you think will the development for Doors 9.0 take?

About the time it'll take Valve to make Portal 3.

Seriously though, I'd say maybe a couple more months, Kerm or tr1p1ea could give you a much better estimate. (programmers have lives beyond the PC!)

EDIT:

Hey guys ! Could we have a little update on the dev ? Keep up the work you're awesome

[/quote]



Noooooooooooooooooooooooooooooooooooo!

Great work, Kerm, good stuff. A lot of my buddies at school constantly request me to put games on their calculators, and I can't wait to be able to give the ones who have 84+CE's Doors instead of Cesium. Not that Cesium is bad, it's actually quite nice, I just prefer the GUI and style of Doors.
Anyway, keep up the good work.

Whoa, Caleb_J, I just realized that you have 'Doors CE 9 user' as one of your signature photos! How did you get that? Are you a closed-beta tester? Or have you just had that for a while and I never noticed?

EDIT:
Hmm... Kerm hasn't given us an update in a while, the Wikipedia page says that Doors will come out in late 2016. So I'm betting that Doors 9 is actually finished and Kerm and tr1p1ea are going to release it on Dec 31st at 11:59pm. At least that's what I'm hoping.

EDIT 2:
Well shoot, the wiki page now says Doors 9 is coming out in 2017. *sigh* oh well, keep it up guys!

I have a new ti 84 plus CE from Best Buy, excited to hear about your progress on this! good luck!!!

Anyone can take any image and put it in their sig. It isnt special, just the banner image that Kerm made for DCE9. You, too, can put it in your signature!

I've seen a few comments mentioning that basic programs can take advantage of some asm routines built into Doors. Could I get some more info on what kinds of routines there will be and how to access them?

Yes, DoorsCE will feature some asm libraries which will make things a lot easier and faster for basic programmers. As far as I know, tr1p1ea (the man who makes these libs) will be porting the same libs as the ones found in DoorsCSE. Information on those commands can be found here. The way to use them should be the same, basically the way its been done in the past is by changing the way a specific token works, for example, something like
Code:
would normally cause an error because the real() command only takes one argument, but with xLIBC installed, it will turn on half-res mode and set the background to a nice soothing pistachio color.

Hey I was thinking, with all that Doors can do, would there be a way to implement a nightshift feature for people who use their calculators late at night? Or would you need to modify the OS to do that? It's (probably) a complicated feature, but I think it could have a great impact on the experience with Doors.

It would be relatively easy (if I understand correctly) to have part of a program merely invert the pixels (thus all that harmful white would become a less harmful black), but it would only affect the program that uses it (in this case, doors CE). I dont know what would be involved in flipping the OS's colors, and I doubt that it would play nice with other programs.

But I could be passing gas here, too.

There are two ways you can go about this:

1) Like Luxen suggested, invert the colors to make the mostly white layout turn black, and actually, I think this might be incredibly easy to do for the entire calculator (not just doors) because on the ti-84 plus CSE, if you ran the real(3,2,...?) command to invert the screen, it would remain inverted until you turned the calculator off or you reinverted it.

2) Simply set the brightness to a low level if it is night time, and high if it is daytime.

Either way, it would have to be dependent of the internal time of the calculator (obviously), which is unlikely to be correct based off my experience with frequently crashing calcs, but it could definitely be done.
In fact, since Doors already has to deal with hooks that are triggered when the calculator turns on, I think it would be really easy to add a little piece of code that checks the time and inverts or sets the brightness accordingly while the calculator is turning on.
On the monochrome calcs, there was an opcode to set the contrast to any level you wanted:
Code:

And such a method could be used to make a ti-basic version that would run on startup (with some help from an asm program)
Side note though, that is Z80 asm and will surely crash your ti-84 plus CE if you try to run it.

EDIT: Runer112 was so kind as to port the code to ez80 asm. Here is the opcode he came up with. I tested it and it works, in fact it can go lower than the OS.

Code:

And on the topic of crashing calcs and time, could we maybe get a feature for saving the time? So like each time you open doors and run a program, it saves the time, and then if you crash, it says: "You just crashed at this time: Would you like to keep that time or change it?" It would probably help with keeping the time all set.

Although I'm sure the time of the calc of 99% of the people here are not the right time, at least not if you are debugging things and your RAM resets every minute, then it's useless to modify the time each time, and is such feature useless as well.

Yeah, i pretty much ignore the time feature ;P

However not everyone debugs ASM programs on their calculators , I actually use my calculator clock quite often to see the time in class, so personally I like the idea of restoring the time.

Great work Kerm! There's only one feature that I've always wanted in a shell... can you stick a digital clock in the status bar at all times?

Now that would probably be a lot harder than just one operation on startup. The thing with having a digital clock displayed up there is that first of all, the status bar gets updated, which means that you need to redraw it sometimes. On top of that, it has to update every time the minutes change. What you end up with when you do that is a glitchy thing that disappears every now and then.
Have a look at nclock for the ti-nspire which does just that, it works as intended, although with ndless, things become more complicated, but you will notice that every now and then it flashes and flickers. I'm led to believe that unless implementation was really good, this is what a digital clock on the homescreen would look like.

Doors CE adds a clock in its own "taskbar" (see the screenshot below), but doesn't add it to the OS's status bar.



Also, just as a reminder to myself, because this got lost way down in this thread:

• Resolve problems with implementing poweroff to ensure that OS will not crash after quitting DCE after poweroff/APD.
  
• Ensure that memory leak when DCE ran itself via HomeRun is resolved.
  
• Test C/ASM library loading from Mateo within DCE
  
• Make hook chainer work properly, at least with GetKeyHook and AppChangeHook.
  
• Make shell functions called via ExecArcHook put their cleanup routines in safeRAM instead of assuming the layout of Archive hasn't changed. Done for AppChangeHook, not yet for ParserHook.
  
• Make editing both archived and Unarchived programs from the home screen work. Sorted and tested, other than implementing the previous item.
  
• Debug crash when loading new DCE version over old on emulator. -> Probably caused by HomeRun pointing to the wrong place because the stub is not loaded. Yep, caused by stub not holding proper contents. Need to detect this and let the OS handle running the program instead. Possibly (untested) fixed. Relies on following item.
  
• HomeRun ParserHook uses absolute calls to ParserHookChkPrgm, getHomescreenToken, and getHomescreenByte. This makes it crash it many circumstances.
  
• Consider label/home/end menu
  
• Create small core ASM library for DCE programs?
  
• Graphical artifacts on homescreen as reported by tr1p1ea
  
• xLIBCE! Very much underway.