On top of minor issue of the doc still use docde7.z80 but the source come with clipsprt.asm, one thing bug me is the location of the .inc files. For dcs7sdk, the compile work. For dcse8sdk, the compile require one to move the files to asm as it cannot find it.


Code:


All goods; just in case anyone who start find it puzzling. Perhaps one day the doc will be updated. As said it is minor and all great.

You can change the inc file in the source using instead "./tasm/...inc" to avoid copy files. In fact you can also create a lib directory under asm so when you are in asm you can use ./lib/std-header.inc etc. to avoid the longer header file for all .asm files.

I still trying to figure out how to use a proper name for the program when download instead of ZZTEMP

I'm concerned that you may be using the script incorrectly: my experience has been that all of this (finding the relevant includes, converting from ZZTEMP to the correct output name, etc.) happens with the current setup as-is. To make sure I'm understanding your bug report correctly, the Doors CS 7 SDK works correctly to compile TI-83 Plus/TI-84 Plus programs, but you're finding that the compile.sh script in the Doors CSE 8 SDK does not work correctly to compile TI-84 Plus C Silver Edition programs? And I believe you mentioned that you're running within the bash shell, but on Mac OS X?

I checked using my dcse7sdk generated program. H4OK.asm generated H4OK.8xp (and in fact dcse8sdk can do the same, just change header it will generate ok). However, my dcse7sdk H4OK.8xp can prompt the TiConnect to use H4OK, but the dcse8sdk generated proper name files xxxx.8xp but will use ZZTEMP. Somehow there is info needed for the TiConnect to know the name is xxxx.8xp and somehow it does not, and use ZZTEMP under dcse8sdk.

BTW, on top of this issue, it seems the dcse8sdk like to clear the screen afterwards and displayed DONE ..... for both H4OK.8xp generated under dcse7 and xxxx.8xp generated under dcse8. I do notice that issue under dcse8sdk (or just both resident there) and if I do not run it under the prgm button but use ASM(prgmH4OK, it does not refresh the screen, I can see the output. But you cannot do ASM(prgmZZTEMP and hence has to run via the prgm button, then the ZZTEMP will refresh screen and you cannot see any output except DONE ..... (unless you add loop etc.) I think it is something dcse8 did as I run H4OK from 7 under prgm button. The screen refresh and hence still need a loop; unlike if it run under ASM(H4OK.

--- longer answer plus new issues ---

I used zsh under MacOS, but I changed to bash based on your kind advice.

The error message is still the same though.

I still need to adjust the shell *.inc. It worked now with this adjustment. Plus move the standard header to my ./lib directory to simplify any .asm file.

Just in case I reset the whole calculator (back button) and I can copy the DoorsCSE.8ck and run there. As all compile, the program did generate the proper name e.g. H4OK.asm to H4OK.8xp. But when I copy (even the default clipsprt.8xp) I just no longer use the name but ZZTEMP. Capitalise it still not help.

Is there any info the TiConnect needed but the new sdk does not provide in the 8xp files I wonder. Seems ok in dcse7sdk.



For the new issue of dcse8 no ASM(prgm option and refresh screen, not a good avoidance tactic is to add a loop:

I currently add a loop on top of any program I did so it repeat itself and let me see the message like hello world etc. I guess if I have an input at least it stop for me to enter (but after that it would be a big problem as it still clear the screen.)

This is an adoption of day 1 from the learning course and it will display an H (part of the "Hello World"). I changed it to add a loop and then add another loop to show some ASCII characters. Not sure why the program clear the screen here after all these were done?!


Code: