[Paused] Doors CE 9 (TI-84 Plus CE) Development thread
» >
» Goto page 1, 2, 3 ... 25, 26, 27  Next
» View previous topic :: View next topic  
I can't count how many YouTube comments, emails, and Cemetech topics I've seen asked for a Doors CS/Doors CSE for the new TI-84 Plus CE, and finally, I've gotten around to start creating it. I won't deny that CesiumOS by MateoConLechuga has pushed my competitive side to drop everything else and focus on this, and Epharius' work on PHASM has also motivated me. For about a month, I've been working to build the original Doors CSE source code for the ez80 TI-84 Plus CE, and I've finally gotten it to the state where I can begin debugging the shell. For the unfamiliar, the stages in the process go something like this:
  1. Take the source, make it assemble by finding equivalents for all system calls and memory areas from the TI-84 Plus C Silver Edition on the TI-84 Plus CE.
  2. Debug the shell, module, by module, modifying components to work properly. One needs to take into account things like 3-byte registers, the new memory format, and the fact that Doors CE is now going to be a program rather than a shell.
  3. Reconfigure for the TI-84 Plus CE. Like CesiumOS, Doors CE will divide itself into a RAM component (a launcher) and an Archived component (the shell itself) when it first runs, in order to provide longer-lived hooks and resilience to RAM clears. This architecture will take time
  4. Port libraries. Doors CE will provide ASM, C, and TI-BASIC libraries, but this will take time to get in place


I'm happy to present the first "screenshot" from Doors CE 9:
Geopipe
Great work Kerm! What stage in the porting process are you at now?
https://ivoah.net
My Calcs: TI-86, TI SR-56, TI-Nspire CX CAS, TI-83+ SE
TI-84+ SE, TI-85, TI-73 Explorer VS, TI-84+ CSE, TI-89 Titanium
Ivoah wrote:
Great work Kerm! What stage in the porting process are you at now?
I have just started stage 2, and I expect it to be fairly time-consuming. The fact that we don't yet have a community TI-84 Plus CE emulator, including debugging tools, is a significant barrier to moving fast with this.
Geopipe
So, the earlier request I made in the Cesium thread applies here too.

elfprince13 wrote:
MateoConLechuga wrote:
elfprince13 wrote:
Feature request: a standard argv mechanism (preferably for BASIC too, but definitely for C/Asm)

I would totally love to implement this, but I am not entirely sure what you are getting at. Could you please detail it a little more? Thanks! Smile


Your standard entry point for programs should be akin to:

Code:

int main(int argc, char ** argv) {
    return 0;
}


This allows for reasonable terminal interfaces, file opening mechanisms, and all sorts of goodies, for the same reasons it's a standard everywhere else.

[edit]

Quote:

The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner.

If they are declared, the parameters to the main function shall obey the following constraints:

The value of argc shall be nonnegative.

argv[argc] shall be a null pointer.

If the value of argc is greater than zero, the array members argv[0] through argv[argc-1] inclusive shall contain pointers to strings, which are given implementation-defined values by the host environment prior to program startup. The intent is to supply to the program information determined prior to program startup from elsewhere in the hosted environment. If the host environment is not capable of supplying strings with letters in both uppercase and lowercase, the implementation shall ensure that the strings are received in lowercase.

If the value of argc is greater than zero, the string pointed to by argv[0] represents the program name; argv[0][0] shall be the null character if the program name is not available from the host environment. If the value of argc is greater than one, the strings pointed to by argv[1] through argv[argc-1] represent the program parameters.

The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination.
<- Please Support on Lego Ideas
Yes, I definitely plan to do this (and I'll also be continuing to use the field-based shell program header from Doors CSE). Do you have any particular proposals for passing argc and argv to ASM programs and getting them back from ASM programs? I guess for C programs, the API will be a little more obvious.
Geopipe
C programs and ASM programs should have the same format. ASM programs can handle the stack manipulations manually in the cases where they care, and ignore them in the cases where they don't.
<- Please Support on Lego Ideas
I say celtic 3 this time Razz Cause why not Razz Sure it's longer to port but the way I see it, every extra ASM command that is ported will be an extra tool available for CE programmers which are sure to be plentiful Very Happy These ASM libs basically allow some asm functionality to basic programmers, who don't really want to learn ez80 but still want to "make cool things" which is of course, super precious.
Ps: WOOOOT!!! Doors CSE 9.0!!!
Celtic 2 will be installed to help keep backwards compatibility of programs/games made on the CSE.

This looks great so far Kerm, let me know when there's a testing version to try!
tifreak8x wrote:
Celtic 2 will be installed to help keep backwards compatibility of programs/games made on the CSE.

Although this argument is perfectly logical and valid, I'd like to offer a counter argument Razz
I'm not sure if all of the numbers used in Celtic 2 are also used in Celtic 3 for the same commands and some were added on, or if they were changed up for some reason, but assuming they weren't, then CSE programs would be completely compatible with the CE. Of course the CE's programs wouldn't be compatible on the CSE, but that could be more of a long term fix with an eventual release of a new version. Imagine a few years from now when ti will release a new calculator and the same type of projects will be launched. If these changes don't happen during development times such as these, I don't think they will ever happen and people like Kerm will be porting outdated versions of libs until 2033 simply because they want to keep everything cross-compatible. However, If this "update" is made right now, then of course it would take quite a bit of work, but it would be to everyone's advantage in the long run Razz
Guess I better finish xLIBCE Smile.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

tr1p1ea wrote:
Guess I better finish xLIBCE Smile.
That would be hugely helpful. Did we decided that 8bpp mode + using the two halves of the GRAM as the two buffers would be the right solution, albeit difficult to use to emulate the abuse of xLIBC in full-resolution mode from the TI-84+CSE?

elfprince13 wrote:
C programs and ASM programs should have the same format. ASM programs can handle the stack manipulations manually in the cases where they care, and ignore them in the cases where they don't.
Okay, that's fair. Do we actually have a specific calling convention for C programs that we're using, or are we following whatever Zilog's compiler does? Mateo?
mr womp womp wrote:
tifreak8x wrote:
Celtic 2 will be installed to help keep backwards compatibility of programs/games made on the CSE.

Although this argument is perfectly logical and valid, I'd like to offer a counter argument Razz
I'm not sure if all of the numbers used in Celtic 2 are also used in Celtic 3 for the same commands and some were added on, or if they were changed up for some reason, but assuming they weren't, then CSE programs would be completely compatible with the CE. Of course the CE's programs wouldn't be compatible on the CSE, but that could be more of a long term fix with an eventual release of a new version. Imagine a few years from now when ti will release a new calculator and the same type of projects will be launched. If these changes don't happen during development times such as these, I don't think they will ever happen and people like Kerm will be porting outdated versions of libs until 2033 simply because they want to keep everything cross-compatible. However, If this "update" is made right now, then of course it would take quite a bit of work, but it would be to everyone's advantage in the long run Razz
Let's look at this another way: what Celtic III functions that aren't in Celtic 2 that you think are important? xLIBC and parts of Celtic 2 CSE cover all kinds of graphics functions, plus everything that most people need to manipulate programs and AppVars. If there are specific functions that you think are important, I'd be more than happy to explore including them.
Geopipe
KermMartian wrote:
Okay, that's fair. Do we actually have a specific calling convention for C programs that we're using, or are we following whatever Zilog's compiler does? Mateo?

That's not the job of the compiler, that's the job of the startup routines, which also initialize the BSS and setup the vectors. These are written in assembly; here is the relevant standard C startup portion, of which I have modified to support other things, and the relocation of errno. (I'm still working on the details, so the code below is the standard implementation). Implementing an input of the standard arguments of main() is up to you.

The calling convention for C functions is pushing all arguments onto the stack in order of argument number, regardless of type. All items int and lower are passed as 24 bits, even though they aren't. Return values are documented in the ZDS docs.


Code:
;*          Copyright (c) 2007-2008 Zilog, Inc.
;*****************************************************************************
;*  cstartup.asm
;*
;*  ZDS II C Runtime Startup for the eZ80 and eZ80Acclaim! C Compiler
;*****************************************************************************

        xdef _errno
        xdef __c_startup
        xdef __cstartup
        xref _main

        xref __low_bss       ; Low address of bss segment
        xref __len_bss       ; Length of bss segment

   xdef _abort

        __cstartup equ %1

;*****************************************************************************
;* Startup code. Reset entry point.
;*
        define  .STARTUP, space = RAM

        segment .STARTUP       ; This should be placed properly
        .assume ADL=1

__c_startup:
_c_int0:
;--------------------------------------------------
;  Initialize the .BSS section to zero

    ld  hl, __len_bss          ; Check for non-zero length
    ld  bc, 0                  ; *
    or  a, a                   ;  clears carry bit
    sbc hl, bc                 ; *
    jr  z, _c_bss_done         ; .BSS is zero-length ...
$$:
    ld  hl, __low_bss          ; [hl]=.bss
    ld  bc, __len_bss
    ld  (hl), 0
    dec bc                     ; 1st byte's taken care of
    ld  hl, 0
    sbc hl, bc
    jr  z, _c_bss_done         ; Just 1 byte ...
    ld  hl, __low_bss          ; reset hl
    ld  de, __low_bss+1        ; [de]=.bss+1
    ldir                       ; Load Increment with Repeat
_c_bss_done:

;---------------------------------------------
; prepare to go to the main system rountine
    ld hl, 0                   ; hl = NULL
    push hl                    ; argv[0] = NULL
    ld ix, 0
    add ix, sp                 ; ix = &argv[0]
    push ix                    ; &argv[0]
    pop hl
    ld de, 0                   ; argc = 0
    call _main                 ; int main( int argc, char *argv[]) )
    pop de                 ; clean the stack
__exit:
_abort:
    jr $                  ; if we return from main loop forever here

;*****************************************************************************
;* Define global system var _errno. Used by floating point libraries
;*
        segment DATA
_errno:
        ds 3                       ; extern int _errno


In addition, it is probably better if the shell initializes the BSS section in order to limit repeated code. C programs that run without a shell technically shouldn't be allowed. in my opinion, mainly because of the requirements. There basically needs to be an overlaying layer. I haven't officially decided on a location for the BSS section, because it needs to be set statically by programs. I imagine it will be at least 20kb though. I've also tried looking into the #nobss pragma, but it doesn't appear to function as desired.
Thanks, Mateo. Smile I'll wait until you figure out a good solution for the BSS for intercompatibility between your shell and Doors CE to add code to initialize the BSS myself (plus, I have much to do before I get to making C program execution work anyway). I've been getting various components to work; here are some "screenshots" for your collective edification. Note that the weird display of the clock/battery icon/taskbar in the first screenshot are due to debug prints, not a graphical error. The weird display of the program name is a bug, however.

Geopipe
Very nice work Kerm! As for names not displaying correctly, are you sure that you are looking at the name length byte when you display? You shouldn't be getting that many characters. Razz
MateoConLechuga wrote:
As for names not displaying correctly, are you sure that you are looking at the name length byte when you display? You shouldn't be getting that many characters. Razz
Haha, thanks for the suggestion. Razz Tracing showed that the stack level is getting disturbed: somewhere there's one too many pops. This would be a bit easier with an TI-84+CE jsTIfied. Wink
Geopipe
KermMartian wrote:
Let's look at this another way: what Celtic III functions that aren't in Celtic 2 that you think are important? xLIBC and parts of Celtic 2 CSE cover all kinds of graphics functions, plus everything that most people need to manipulate programs and AppVars. If there are specific functions that you think are important, I'd be more than happy to explore including them.

The particular commands I was looking at were:
NumToString, ExecHex, UngroupFile and MatToStr
mr womp womp wrote:
The particular commands I was looking at were:
NumToString, ExecHex, UngroupFile and MatToStr
The former two seem extremely useful, and I'll add them. Please remind me to do so. I think UngroupFile never really worked properly, from Iambian's notes, and I think MatToStr is too narrow (and can be done with a combination of NumToString and simple TI-BASIC code) to include.

I've been working very hard, now that I have a fire lit under me, and here's what's new, judging from my commits:
  • Repaired problems restoring folders from FLDSV AppVar after a crash
  • Repaired 16->24 bit issues with PrevVATArray, the VFAT, routines like ldhlind, and so on.
  • Fixed display of program icons, names, and property icons on the desktop
  • Repaired the InfoPop box that appears when you hover over a program
  • Made icons for TI-BASIC programs with :DCS-style headers display properly
  • Attempted repairs for APD inside Doors CE
  • Made the scrollbar work properly (by also fixing DivHLC and similar z80 Bits routines)
  • Repaired initial display of Properties menu when you click on something
  • Made creating new folders (and backing up those folders) work properly
  • Repaired the string routine used for getting the name of new programs and folders


Geopipe
Looks like most (?) of the easier GUI part, and some of the VAT part, are done.

Have you given a close look to Mateo's work on the library and loader ?

BTW:
Quote:
I've been working very hard, now that I have a fire lit under me

This may be slightly off-topic (but hey, you brought the topic first yourself): what are you so afraid of ? Smile
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
KermMartian wrote:
mr womp womp wrote:
The particular commands I was looking at were:
NumToString, ExecHex, UngroupFile and MatToStr
The former two seem extremely useful, and I'll add them. Please remind me to do so. I think UngroupFile never really worked properly, from Iambian's notes, and I think MatToStr is too narrow (and can be done with a combination of NumToString and simple TI-BASIC code) to include.

This seems very reasonable and wonderful Razz and with ExecHex, programmers could really do soo much more. I don't know exactly how this is done, but could such a command be used to run loops slightly faster? Anyways, Tysm Kerms, I can't wait :3
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.
<- Please Support on Lego Ideas
  
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
[Paused] Doors CE 9 (TI-84 Plus CE) Development thread
» Goto page 1, 2, 3 ... 25, 26, 27  Next
» View previous topic :: View next topic  
Page 1 of 27
» All times are UTC - 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