I have encountered some issues with compiling files, which evidence indicates are code based.
The issue is that all compiled files are utterly invalid, are refused even in loading. The code is successfully compiled by my Compile.Bat document, but upon attempt to load the compiled program into an emulator, the file is rejected.
The calculator is the Ti-84 Plus C Silver Edition, utilizing OS 4.0, and the Shell DoorsCSE 8.2, Build 1603.
I am utilizing the Doors CSE SDK, for sake of convenience. The SDK is a simple implement that served to compile .ASM files using Brass version 1.0.4.11. However, the included compile.bat file in the main folder was nonfunctional. I renamed it oldcompile.bat, dissected the code, and created a simplified and functional compile.bat document within the tasm folder. This document reads;
"@echo off
SET file="clipsprt"
:A
brass ..\source\\%file%.asm ..\exec\\%file%.8xp -l ..\list\\%file%.list.html
Pause
Goto A"
The file uses a variable "file" as the name of the intended compiling target. This is for the ease of my personal use. Referencing the Brass manual at http://benryves.com/bin/brass/, this appears to be the correct usage of the Brass program in batch, and references various source on Batch files, the code should not produce any additional effects or modify the code in any manner. Additionally, the issue transcends versions of Brass. Thus, it is reasonable to conclude that the assembler, and compile file are not at fault here.
The next documents of suspect are the include files, but upon inspection and comparison to copies of both the "dcse8.inc" and "ti84pcse.inc" files, the include documents are neither at fault for this issue.
This leaves either the emulator, ROM file, or code itself at fault. The assembled code has been tested on both the Wabbit Emu and jsTIfied. Both emulators have been tested on multiple occasions, yet neither accepted the file. It is unlikely both independently developed emulators have the same loading bug, so it is reasonable to assume they are neither at fault.
The ROM file has been tested on both emulators with several different apps, and assembly programs. The ROM was compiled using rom8x and my personal TI84+CSE. There is no evidence suggesting the ROM is at fault.
That seems to leave the code as the source of the issues. Additionally, the adding the directive ".binarymode TI8X" to the start of the code changed the error given by Wabbit Emu, indicating that the change in code alleviated some of the problem. However, the program came with the SDK, and was precompiled with the SDK. This version of the program ran perfectly fine on my calculator, with no errors. Additionally, the code is noted as authored by "Kerm Martian". I am not particularly in the mood for heresy on the level of proclaiming that our lord and savior, Kerm Martian, has written invalid code and packaged it with the Doors CSE SDK.
So, if the isn't any reasonable explanation that any individual part of the process of assembly has issues, than the process itself shouldn't have issues, and should work smoothly. But it doesn't.
This is clearly some obvious oversight I have made, as a programmer new to assembly. I may be familiar to programming, but I have only studied assembly for sixteen days.
If you've given your time to read all of this, thank you.
A zip file enclosing the SDK, and the various files used (such as the code, compile.bat document, et cetera) can be found at https://drive.google.com/file/d/1ftKsV_NBRtVDfTZVJizm_PK7j_3dDmcM/view?usp=sharing for those willing to tinker with it.
The issue is that all compiled files are utterly invalid, are refused even in loading. The code is successfully compiled by my Compile.Bat document, but upon attempt to load the compiled program into an emulator, the file is rejected.
The calculator is the Ti-84 Plus C Silver Edition, utilizing OS 4.0, and the Shell DoorsCSE 8.2, Build 1603.
I am utilizing the Doors CSE SDK, for sake of convenience. The SDK is a simple implement that served to compile .ASM files using Brass version 1.0.4.11. However, the included compile.bat file in the main folder was nonfunctional. I renamed it oldcompile.bat, dissected the code, and created a simplified and functional compile.bat document within the tasm folder. This document reads;
"@echo off
SET file="clipsprt"
:A
brass ..\source\\%file%.asm ..\exec\\%file%.8xp -l ..\list\\%file%.list.html
Pause
Goto A"
The file uses a variable "file" as the name of the intended compiling target. This is for the ease of my personal use. Referencing the Brass manual at http://benryves.com/bin/brass/, this appears to be the correct usage of the Brass program in batch, and references various source on Batch files, the code should not produce any additional effects or modify the code in any manner. Additionally, the issue transcends versions of Brass. Thus, it is reasonable to conclude that the assembler, and compile file are not at fault here.
The next documents of suspect are the include files, but upon inspection and comparison to copies of both the "dcse8.inc" and "ti84pcse.inc" files, the include documents are neither at fault for this issue.
This leaves either the emulator, ROM file, or code itself at fault. The assembled code has been tested on both the Wabbit Emu and jsTIfied. Both emulators have been tested on multiple occasions, yet neither accepted the file. It is unlikely both independently developed emulators have the same loading bug, so it is reasonable to assume they are neither at fault.
The ROM file has been tested on both emulators with several different apps, and assembly programs. The ROM was compiled using rom8x and my personal TI84+CSE. There is no evidence suggesting the ROM is at fault.
That seems to leave the code as the source of the issues. Additionally, the adding the directive ".binarymode TI8X" to the start of the code changed the error given by Wabbit Emu, indicating that the change in code alleviated some of the problem. However, the program came with the SDK, and was precompiled with the SDK. This version of the program ran perfectly fine on my calculator, with no errors. Additionally, the code is noted as authored by "Kerm Martian". I am not particularly in the mood for heresy on the level of proclaiming that our lord and savior, Kerm Martian, has written invalid code and packaged it with the Doors CSE SDK.
So, if the isn't any reasonable explanation that any individual part of the process of assembly has issues, than the process itself shouldn't have issues, and should work smoothly. But it doesn't.
This is clearly some obvious oversight I have made, as a programmer new to assembly. I may be familiar to programming, but I have only studied assembly for sixteen days.
If you've given your time to read all of this, thank you.
A zip file enclosing the SDK, and the various files used (such as the code, compile.bat document, et cetera) can be found at https://drive.google.com/file/d/1ftKsV_NBRtVDfTZVJizm_PK7j_3dDmcM/view?usp=sharing for those willing to tinker with it.
