elfprince13 wrote:
I don't know how ExecHex is currently structured, but it seems it would be extremely useful to have an argument that specifies the address from which to copy + execute it.
*to which to copy and execute it, I assume? In the past, this has been a safeRAM location chosen by the shell, in order to provide maximal forward-compatibility with new safeRAM addresses. However, I could probably be swayed about the value of an optional address argument (although don't forget that the OS limits numeric fields to 0-9999 the way we parse them, so we'd need two arguments (or a string) for the address).
Ah sorry, bad wording. "To which to copy it, and from which to then execute it". A hex string seems like the easiest option.
That seems like a reasonable feature request to me, although I definitely would want to provide sane defaults and strongly warn people against playing with those extra arguments if they don't understand what they do.
New things in Doors CE since I last posted, focusing on the Properties menu:
- Got folders working properly: you can now enter and exit folders
- Fixed cut-and-paste
- Fixed copying archived and unarchived programs
- Fixed renaming archived and unarchived programs
- Tested hiding programs, found functional
- Fixed locking and unlocking programs
- Fixed archiving and unarchiving programs
That just leaves editing and creating programs as the final two missing pieces of the Properties menu. I also need to solve the fact that _GetBatteryLevel takes a long time and that APD is squiffy, then I can start to attack executing programs.
Edit: Got the editor to launch correctly when you try to edit a program or create a new program. However, now I need to implement a special type of hook installer that looks for an archived copy of Doors CE at which to point hooks, and because of that, I guess I need to implement Doors CE's launcher, which (like Cesium) will copy a launcher stub to RAM, hand over control, and then let itself be archived. I need to develop the exact mechanism for that, in fact. Mateo chose to have the shell and/or its launcher be put into an AppVar, I believe; I should research what he did and take some lessons from it.
Any idea when it'll be done?
TennIsLife912 wrote:
Any idea when it'll be done?
Nope, not a clue. Whenever I have time to finish it.
I've been working on the launcher/stub/main program scheme, as required by the impossibility of creating an App: Code: To create the launcher:
- On MAIN prgmDOORSCE execute:
-) Check if DCEMAIN AppVar exists
-) If it exists, delete it
-) Make sure prgmA contains required content or does not exist
-) Warn if exists and wrong content, offer option to abort
-) Delete prgmDOORSCE in memory
-) Create DCEMAIN and archive it
-) Create DOORSCE in memory
-) (Delete and ) create prgmA that contains Asm(prgmDOORSCE
-) Copy launcher code into safeRAM, jump to portion that
deletes original-sized DOORSCE -> set de and jump
- on LAUNCHER prgmDOORSCE execute:
-) Check that AppVar exists
-) If not, display message and quit
-) If it exists, copy self into safeRAM, then jump to portion
that deletes launcher from UserMem -> set de and jump
- SafeRAM portion of launcher:
Unload_and_Launch:
-) Use de and delete that much memory at usermem
Shell_Load:
-) Find appvar DCEMAIN, abort if it's missing
-) Insertmem and copy DCEMAIN in
Shell_Unload:
-) Delete shell-sized memory at usermem
- Test archiving prgmA
- Test unarchiving appvar DCEMAIN
- Need to add enough RAM check
Edit: All done! Now I'm on to trying to get BASIC program execution working properly, then I'll look into ASM programs, and then BASIC libraries. I'll worry about stable hooks after that before I start worrying about C programs that use libaries; at the very least, I want tifreak8x to be able to start using the Celtic 2 CSE libraries in Doors CE!
Looks awesome! Can't wait to have so much more compatibility with the 84 Plus CE! Any ETA on the release yet?
o355 wrote:
Looks awesome! Can't wait to have so much more compatibility with the 84 Plus CE! Any ETA on the release yet?
As he literally just said in the last post:
KermMartian wrote:
TennIsLife912 wrote:
Any idea when it'll be done?
Nope, not a clue. Whenever I have time to finish it.
Executing both unarchived and archived TI-BASIC programs now works correctly. TI-BASIC errors are even viewable in the enhanced TI-BASIC editor now. Errors don't have proper titles (because I didn't find the equate to get TI-BASIC error names yet), but it's coming together.
Edit: I made a lot of progress with the in-shell TI-BASIC editor. Goto after errors in TI-BASIC programs works properly, and editing archived and unarchived TI-BASIC programs from the desktop works properly. A few issues I need to handle:
[ ] Restoring folders after a crash appears to crash. Replicate with a single MATH folder with no contents.
[ ] Error messages are missing titles (and scroll when they're displayed)
[ ] Editor crashes after editing Archived program
This looks great! Will the libraries maintain DCSE compatibility?
Eightx84 wrote:
This looks great! Will the libraries maintain DCSE compatibility?
Going along with this, will DCSE programs run on this shell (I am referring to those programs that require Doors CSE to run), or will they require a port?
Caleb_Hill wrote:
Eightx84 wrote:
This looks great! Will the libraries maintain DCSE compatibility?
Going along with this, will DCSE programs run on this shell (I am referring to those programs that require Doors CSE to run), or will they require a port?
That's the same question :') and yes I believe Kerm said he would implement the same libs (xlibc and Celtic II), he might have changed his mind but I don't think so since the libs are (if you ask me) a big part of DCS/DCSE
mr womp womp wrote:
Caleb_Hill wrote:
Eightx84 wrote:
This looks great! Will the libraries maintain DCSE compatibility?
Going along with this, will DCSE programs run on this shell (I am referring to those programs that require Doors CSE to run), or will they require a port?
That's the same question :') and yes I believe Kerm said he would implement the same libs (xlibc and Celtic II), he might have changed his mind but I don't think so since the libs are (if you ask me) a big part of DCS/DCSE Yes, xLIBC[E] and Celtic 2 CSE will be a part of Doors CE 9. Programs and games for the TI-84 Plus C Silver Edition that use xLIBC as intended, in half-resolution mode, will likely work correctly on the TI-84 Plus CE with Doors CE 9. Programs that abuse the half-resolution tools in full-resolution mode (including my STEM Behind Hollywood activities) will likely need to be modified to work properly with Doors CE 9 and xLIBCE, due to differences in how half-resolution mode works on the CSE and CE LCDs.
Progress: I got APD working correctly within Doors CE, which is more of a feat than it sounds. In order to use the OS to APD, Doors CE must install a hook that points at its Archived copy of itself, unload itself, then ask the OS to power the calculator off. When the calculator turns back on, the OS has control, so a GetCSC/GetKey hook previously installed fires, reloads Doors CE into UserMem, then jumps to it. There's an odd bug where Doors CE will crash after a few seconds back on the desktop after the calculator is turned back on, and it still happens if I press a few buttons before the crash happens. I suspect it might be related to having the calculator plugged into my computer and TI Connect CE running.
I also got the enhanced TI-BASIC editor working properly with archived programs. The crash turned out to be an exciting one: the hourglass drawn on the screen when Doors CE is archiving or unarchiving a program stores a copy of what was beneath it on the LCD in safeRAM, and that safeRAM happened to overlap where Doors CE was storing various state for the editor. Making sure that those two safeRAM areas did not overlap fixed the problems. Next up is exploring executing assembly programs.
Edit: The safeRAM area where I put the RAM stub that bootstraps Doors CE into (UserMem) is only 256 bytes, so I had to shrink my ~450-byte stub. I created a new class of routines called stub2 or "large stub" routines that the original stub is responsible for copying into a larger (but more volatile) safeRAM location. Examples of stub2 routines include the warning that there's not enough RAM to launch Doors CE and the routine that copies and executes assembly programs into RAM and performs writeback before re-launching Doors CE.
Edit #2: I've been working on re-arranging plenty of stuff in preparation for all of the code that will need to run from SafeRAM to swap ASM programs in, run them, and then writeback and/or delete them. As I've been doing so, I've experimented with a few of Doors C[S]E's existing features, and I think that the "Always launch Doors CE" feature should be removed. This feature launches Doors CE every time you turn the calculator on, and I'd imagine that not a lot of people use it. Opinions?
I use it myself, but was always clearing out so I could use the calculator for math related things anyways. Would it save you a bit of space to remove it from the shell?
I dont use the always run feature, because, like tifreak, I mostly use my calculator for math related things, and If I want to use doors, it is just On + PRGM. Very simple.
I'll second that, for the same reasons, I don't use it myself and I doubt many people use it at all so if there are advantages to removing it (size or speed wise) I say it isn't necessary
tifreak8x wrote:
I use it myself, but was always clearing out so I could use the calculator for math related things anyways. Would it save you a bit of space to remove it from the shell?
It would indeed save me space, and now that shells must be ASM programs again, it's once again necessary to be aware of how large Doors CE is. The other reason is that it will take additional development effort to get the OFFSCRIPT right on the TI-84+CE, time I'd rather spend on other features.
Thanks for the opinions, guys!
Wonder when the DCE badges will come out
Eightx84 wrote:
Wonder when the DCE badges will come out
An excellent idea; one day when I'm stuck on a bug I can't track down, I'll make new signature bars for Doors CE.
Anyway, new progress is below. I'm finding that a lot of the features require a lot of annoying debugging, due to the new interactions with the OS made necessary by terrible memory layout hacks: - Removed "Always launch Doors CE" option, and underlying hook and enable/disable code.
- Fixed the ON-PRGM hook. The ON-XT0n hook remains obstinately missing, despite a few efforts to make it work. Unfortunately, the OS launches after Doors CE gets to _JForceCmdChar, when Doors CE was launched with ON-PRGM from a RawKey hook.
- Worked hard on implementing ASM program execution. For an issue possibly related to the previous bullet, _DelMem crashes when I try to move data from an ASM program in RAM to UserMem, and I can't figure out why. Based on examining what exactly _DelMem does, it looks like walking the VAT is what's breaking, or else (FPS) is somehow wrong. I'm really confused about this, and I really wish we had an emulator.
Work goes on.
KermMartian wrote:
Eightx84 wrote:
Wonder when the DCE badges will come out
An excellent idea;
What exactly are DCE badges?