Yes, I have tried pausing before restoring the original mode. It still displays the text as though in MATHPRINT mode. When I move the bcall(_GetKey) before the bcall(_ClrScrnFull), it has the same result.
Then are we sure that the flag is in the same place on the 84+CSE as on the 83+ series? I don't have a CSE to search/test it out with.
Try doing something like:
Code:
...before and after turning MathPrint off yourself in the Mode menu. If that's the correct address, then it should print "32" when MathPrint is on and "0" when it's off.
EDIT: Also, at ticalc someone mentioned calling _ClrScrn after resetting the flag. I'm not sure if that's really necessary or not, though, just tossing out more ideas.
Try doing something like:
Code:
ld a,(iy+44h)
and %00100000
ld l,a
ld h,0
bcall(_DispHL)EDIT: Also, at ticalc someone mentioned calling _ClrScrn after resetting the flag. I'm not sure if that's really necessary or not, though, just tossing out more ideas.
I tried the program you mentioned, chickendude. It worked: it displayed 32 when in MATHPRINT, and 0 when in CLASSIC. Thus, we do know that, unfortunately, the flag address is not the problem.
My current code is this:
Code:
What you mentioned about _ClrScrn is, I believe, encompassed by _ClrScrnFull.
Can anyone think of any other reason why this program might not work?
On a side note, I believe I know why WabbitEmu does not work for me: WabbitEmu does not support OS 4.2 of the color edition.
I am most frustrated about my lack of progress in this simple program because it is halting my progress in the rest of Z80 Assembly. I want to program major apps, eventually become such an expert that I can do hex code. However, how can I do that if I cannot even program a Hello World program?
My current code is this:
Code:
.nolist
#include "ti84pcse.inc"
.list
.org UserMem-2
.db tExtTok,tAsm84CCmp
ld a,(iy+$44)
push af
res 5,(iy+$44)
bcall(_ClrScrnFull)
bcall(_HomeUp)
ld hl,str1
bcall(_PutS)
pop af
ld (iy+$44),a
ret
str1:
.db "Hello, world!",0What you mentioned about _ClrScrn is, I believe, encompassed by _ClrScrnFull.
Can anyone think of any other reason why this program might not work?
On a side note, I believe I know why WabbitEmu does not work for me: WabbitEmu does not support OS 4.2 of the color edition.
I am most frustrated about my lack of progress in this simple program because it is halting my progress in the rest of Z80 Assembly. I want to program major apps, eventually become such an expert that I can do hex code. However, how can I do that if I cannot even program a Hello World program?
I have discovered something. Examine the following code, which is different from the Hello World code.
Code:
Rather than displaying the dotted line and "Done" below the second line (Good-bye, world!), the calculator still displays it below the first line, as in the Hello World program. This means that something about MATHPRINT causes the dotted line and "Done" to always be displayed below the first line, no matter how many lines have been displayed.
EDIT: Here is a screenshot.
Code:
.nolist
#include "ti84pcse.inc"
.list
.org UserMem-2
.db tExtTok,tAsm84CCmp
ld a,(iy+$44)
push af
res 5,(iy+$44)
bcall(_ClrScrnFull)
bcall(_HomeUp)
ld hl,str1
bcall(_PutS)
bcall(_NewLine)
ld hl,str2
bcall(_PutS)
pop af
ld (iy+$44),a
ret
str1:
.db "Hello, world!",0
str2:
.db "Good-bye, world!",0Rather than displaying the dotted line and "Done" below the second line (Good-bye, world!), the calculator still displays it below the first line, as in the Hello World program. This means that something about MATHPRINT causes the dotted line and "Done" to always be displayed below the first line, no matter how many lines have been displayed.
EDIT: Here is a screenshot.
That makes sense i suppose since the two leave CurRow with the same value (pointing to the second row).
Honestly, i would just move on to something else now. It's not a huge issue and MathPrint seems to be (in)famous for causing incompatibilities with programs. I'd say just turn it off and be happy
What other sorts of things are you interested in making?
Honestly, i would just move on to something else now. It's not a huge issue and MathPrint seems to be (in)famous for causing incompatibilities with programs. I'd say just turn it off and be happy
What other sorts of things are you interested in making?
I shall take your advice, chickendude, and move on from the Hello World program. Sometimes I feel that I am too nice to users of my programs: maybe it is time that they deal with their settings being changed.
From here, I shall move on to programming some utilities, in addition to a Chess App with full color (and, in a few years, an AI), and some multi-player games for multiple calculators connected by port. There is only one command for the latter in TI-BASIC, which is GetCalc(; and games programmed using GetCalc( have, I have found, extreme shortcomings.
I do not think that I shall use Doors CSE or its SDK; while these are truly amazing pieces of programming, I do not like piggybacking on others' programming.
From here, I shall move on to programming some utilities, in addition to a Chess App with full color (and, in a few years, an AI), and some multi-player games for multiple calculators connected by port. There is only one command for the latter in TI-BASIC, which is GetCalc(; and games programmed using GetCalc( have, I have found, extreme shortcomings.
I do not think that I shall use Doors CSE or its SDK; while these are truly amazing pieces of programming, I do not like piggybacking on others' programming.
To start with at least i'd recommend at least taking a look at their sprite commands, those have been highly optimized and are probably worth using at least to start with. If you were on the black and white calcs i'd say to check out fastcopy routines, too, but "luckily" you don't have to worry about that on the CSE since there's really no reason to buffer the LCD there.
Also, keep in mind that you will probably never leave a program with text on the home screen, most of your programs will exit the program from a game menu or during the actual game. I look forward to seeing your next projects
Also, keep in mind that you will probably never leave a program with text on the home screen, most of your programs will exit the program from a game menu or during the actual game. I look forward to seeing your next projects
As chickendude says, I spent a great deal of time optimizing the sprite routines in Doors CSE, and while I understand your wish to not take undue advantage of other people's efforts, I encourage you to use Doors CSE for its icon, sprite routines, and any other math functionality that may be helpful to your programs. The routines currently available to assembly programmers are listed here on the Doors CS[E] wiki, and the performance of the sprite routines is documented here.
KermMartian wrote:
- 1-Bit: 32x32 drawn 288 times in 2.7 seconds. 0.009 sec per sprite, or (on average) 9μs per pixel. Full-screen tile of 32x32 1-bit sprites in 0.7 seconds. ~135 clocks per pixel.
- 2-Bit: 72x72 drawn 248 times in 12.3 seconds. 0.05 sec per sprite, or (on average) 9.57μs per pixel. Full-screen tile of 72x72 2-bit sprites in 0.73 seconds. ~144 clocks per pixel.
- 4-Bit: 30x64 drawn 290 times in 5.6 seconds. 0.019 sec per sprite,or (on average) 10.05μs per pixel. Full-screen tile of 30x64 4-bit sprites in 0.77 seconds. ~151 clocks per pixel.
- 4-Bit with 2x magnification: 30x64 (real size 60x128) drawn 260 times in 12.9 seconds. 0.050 sec per sprite, or (on average) 6.46μs per pixel. Full-screen tile of 30x64 4-bit sprites with 2x magnification in 0.50 seconds. ~97 clocks per pixel.
- 2-Bit: 72x72 drawn 248 times in 12.3 seconds. 0.05 sec per sprite, or (on average) 9.57μs per pixel. Full-screen tile of 72x72 2-bit sprites in 0.73 seconds. ~144 clocks per pixel.
- 4-Bit: 30x64 drawn 290 times in 5.6 seconds. 0.019 sec per sprite,or (on average) 10.05μs per pixel. Full-screen tile of 30x64 4-bit sprites in 0.77 seconds. ~151 clocks per pixel.
- 4-Bit with 2x magnification: 30x64 (real size 60x128) drawn 260 times in 12.9 seconds. 0.050 sec per sprite, or (on average) 6.46μs per pixel. Full-screen tile of 30x64 4-bit sprites with 2x magnification in 0.50 seconds. ~97 clocks per pixel.
This time, I have a different problem with a different program.
I wanted to output text in multicolor, so I wrote the following program to display "Hello, world!" on the homescreen in dark green. I had to use hexadecimal in some places, because there was no name in ti84pcse.inc.
Yes, I am taking a small break from writing the fake memory reset program.
Code:
Resetting 5, (iy+$44) is turning off MATHPRINT. $A015 is the location in which the color is stored. $03E0 is the 16-bit code for dark green, according to wikiti.brandonw.net. Setting 4, (iy+$4a) is enabling colored text output.
When I run the program on jsTIfied, it displays many blank lines, then the dotted line and "Done", and then the letter H at the cursor. Upon pressing a key, the calculator crashes and resets.
What is wrong with the program?
I wanted to output text in multicolor, so I wrote the following program to display "Hello, world!" on the homescreen in dark green. I had to use hexadecimal in some places, because there was no name in ti84pcse.inc.
Yes, I am taking a small break from writing the fake memory reset program.
Code:
.nolist
#include "ti84pcse.inc"
.list
.org UserMem-2
.db tExtTok,tAsm84CCmp
bcall(_ClrLCDFull)
res 5,(iy+$44)
ld hl,$A015
ld (hl),$03
inc hl
ld (hl),$E0
set 4,(iy+$4a)
ld hl,msg
bcall(_PutS)
res 4,(iy+$4a)
bcall(_NewLine)
ret
msg:
.db "Hello, world!",0Resetting 5, (iy+$44) is turning off MATHPRINT. $A015 is the location in which the color is stored. $03E0 is the 16-bit code for dark green, according to wikiti.brandonw.net. Setting 4, (iy+$4a) is enabling colored text output.
When I run the program on jsTIfied, it displays many blank lines, then the dotted line and "Done", and then the letter H at the cursor. Upon pressing a key, the calculator crashes and resets.
What is wrong with the program?
One thing i notice is that you're writing $03E0 backwards. The z80 is "little-endian", meaning that the first byte in a two byte number is the least significant byte (LSB), aka the small part. So to store $03E0 in memory, you would store it as:
.db $E0,$03
Notice that the $E0 comes first.
If you do:
ld hl,$03E0
Then L holds the $E0 (LSB) and H holds the $03 (MSB: most significant byte).
Another alternative would be:
Code:
I'm not sure if that's the problem though.
Also, for others and for yourself (when you look back on your code in the future) you might want to define your own equates at the top of your program, making up your own name for now until an "official" one is decided upon/added to ti84pcse.inc.
.db $E0,$03
Notice that the $E0 comes first.
If you do:
ld hl,$03E0
Then L holds the $E0 (LSB) and H holds the $03 (MSB: most significant byte).
Another alternative would be:
Code:
ld hl,$03E0
ld ($A015),hlI'm not sure if that's the problem though.
Also, for others and for yourself (when you look back on your code in the future) you might want to define your own equates at the top of your program, making up your own name for now until an "official" one is decided upon/added to ti84pcse.inc.
- 27 Dec 2014 01:17:12 pm
- Last edited by scAFwATLxpKzRCmVaHv on 27 Dec 2014 01:43:58 pm; edited 2 times in total
Here is the updated version of my program:
Code:
You were right, chickendude: the little-endianness is not the problem. In fact, it wouldn't have really mattered; it would just have shown another color, not crashed the calculator.
Code:
.nolist
#include "ti84pcse.inc"
#define MathPrint $44
#define MathPrintOn 5
#define PutMapFlags $4a
#define PutMapUseColor 4
.list
.org UserMem-2
.db tExtTok,tAsm84CCmp
bcall(_ClrLCDFull)
res MathPrintOn,(iy+MathPrint)
ld hl,$03E0
ld (textFGColor),hl
set PutMapUseColor,(iy+PutMapFlags)
ld hl,msg
bcall(_PutS)
res PutMapUseColor,(iy+PutMapFlags)
bcall(_NewLine)
ret
msg:
.db "Hello, world!",0You were right, chickendude: the little-endianness is not the problem. In fact, it wouldn't have really mattered; it would just have shown another color, not crashed the calculator.
No, I used a random string generator that I programmed on my calculator. Try it yourself: if you set the seed to 0 on a TI calculator, and randomly generate a number from 1 to 20 or something like that for the number of times to execute the following code, and then randomly generate a number from 1 to 52, and put it through a series of if loops that go like this:
Code:
then you get my username.
Code:
If X=1
Str1+"A->Str1
...
If X=26
Str1+"Z->Str1
If X=27
Str1+"a->Str1
...
If X=52
Str1+"z->Str1then you get my username.
- 27 Dec 2014 04:43:39 pm
- Last edited by scAFwATLxpKzRCmVaHv on 28 Dec 2014 05:53:47 pm; edited 2 times in total
I have discovered what is wrong with my program. It does not contain bcall(_HomeUp). That was quite an easy solution: the program works now.
I have also made two more changes: I replaced bcall(_ClrLCDFull) with bcall(_ClrScrnFull), because that fixes a minor bug that I will not mention here. I have also taken away the flag restore at the end: that was a waste of memory and time, since the OS anyway restored the flag.
EDIT: I also wanted to experiment with highlighting, so I added a light blue background color.
In conclusion, this is my final code, for those who want colored normal-size text:
Code:
I have also made two more changes: I replaced bcall(_ClrLCDFull) with bcall(_ClrScrnFull), because that fixes a minor bug that I will not mention here. I have also taken away the flag restore at the end: that was a waste of memory and time, since the OS anyway restored the flag.
EDIT: I also wanted to experiment with highlighting, so I added a light blue background color.
In conclusion, this is my final code, for those who want colored normal-size text:
Code:
.nolist
#include "ti84pcse.inc"
#define MathPrintFlags1 $44
#define MathPrintActive 5
#define PutMapFlags $4a
#define PutMapUseColor 4
.list
.org UserMem-2
.db tExtTok,tAsm84CCmp
bcall(_ClrScrnFull)
res MathPrintActive,(iy+MathPrintFlags1)
ld hl,$3E0 ;dark green
ld (textFGColor),hl
ld hl,$49F ;light blue
ld (textBGColor),hl
set PutMapUseColor,(iy+PutMapFlags)
bcall(_HomeUp)
ld hl,msg
bcall(_PutS)
bcall(_NewLine)
ret
msg:
.db "Hello, world!",0Register to Join the Conversation
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
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