This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Xeda112358
1
« on: Today at 10:40:14 am »
Since I'm using the z80float library, addition and subtraction are slightly slower on average (about 350cc, which translates to 20%), multiplication and division are about three times faster. The real bottleneck is in converting to and from strings which is significantly slower than the TI-OS since they use a BCD format.
Eventually, I want to make a fairly simple programming language and my plan is to tokenize/precompile so that the bottleneck is only in displaying strings (converting from a string to an integer or a float will be done once). Since I had this idea in mind as I worked on this, evaluation from plaintext first compiles to a bytecode and then runs it through a parser. If I wanted it to be a non-programmable calculator I could combine both into one step that uses less memory (and slightly less CPU time).
2
« on: Yesterday at 01:05:18 am »
I have been working on a side project for a little while that will revolutionize the 83+/84+ monochrome series: A basic calculator program. That's right, your TI-83+ is no longer just for games. If you want to add or subtract-- or even multiply and divide-- this program can do that for you! Be warned, some of the math is a little buggy still. You'll need the Floatlib app located here, but otherwise just run it as an assembly program. I made a custom input routine, so it might feel a little clunky, but it should be pretty straight-forward (except [DEL] actually acts as a backspace). Exit with [ON].
3
« on: Yesterday at 12:55:54 am »
Some more routines were finally added in, especially the string -> float extended-precision routine. I still need to implement some if the trig routines, but I only have 565 bytes of space left :| I might need to look into ways to reduce the size of the built-in documentation. Here is the compiled app, the source is up on GitHub.
4
« on: February 16, 2019, 09:33:05 pm »
Yes, bcall(_fillAppBaseTable) should be sufficient.
5
« on: February 16, 2019, 06:44:13 pm »
1) What RAM pages can I use within programs without having any bad consequences? Even numbered pages are execution protected by default, so executing code here will crash your calc. That said, you can definitely store data. On the calcs with USBs, page 83h has some data that should be preserved or restored in the first 128 bytes. Just remember that any OS routines that interact with memory or variables expect the right pages to be there. Ram Pages (WikiTI) 2) When an appvar is less than 16kb and is archived, will it all be on the same ROM page? No, you can't expect this. Variables won't cross sector boundaries (groups of four RAM pages), but they may cross pages. 3) Can you interface with headphones beyond simply sending them signals with the ring and the tip? If so, how?
I don't know what you mean by this, sorry :| If you want to use headphones, you have to interact directly with port 0.
6
« on: February 14, 2019, 11:43:54 am »
Out of curiosity, how big is the ROM? I know many ROMs are just too big or require too much RAM.
7
« on: February 04, 2019, 02:45:11 pm »
Thanks for posting the answer for future reference!
8
« on: February 01, 2019, 10:59:01 am »
That is pretty impressive. And that's basically how I got into calc programming. It was super portable and relatively easy to use and didn't have a computer at home.
9
« on: February 01, 2019, 12:18:42 am »
Requires Grammer 2.50.1.1 and up.
This program gives you the zeros of a quadratic function! Inputs must include a decimal point so that Grammer knows it is a float. Hopefully that can be fixed in the future. Also it looks like Grammer has some float issues, so it gives weird answers when the result is complex.
10
« on: January 31, 2019, 11:59:06 pm »
I made the readme a little easier to read, splitting it up into different files and using tables. I also added in support for automatic conversion of a number to a float if there is a decimal point in there. For example, 3.0 is now converted to a float and its pointer is returned (where it is stored in temp memory). See the readme for a slightly more detailed look at how Grammer handles floats. Finally, a really minor modification was that I found a size and speed optimization in pixel plotting, so you will now be able to get in an extra pixel or two per minute! 
11
« on: January 30, 2019, 08:59:46 pm »
Here is my take on it (not the whole code):
ld c,(hl);grab string size
inc hl
ld b,(hl)
inc hl
loop:
ld a,(hl) ;Need to check if it is a two-byte token, later
push af ;Save A for later
push hl
push bc
bcall(_Get_Tok_Strng)
ld hl,op3-1 ;point to the byte *before* the output characters.
tokenloop:
push hl ;save HL
push bc ;and BC
call CheckXPos
pop bc
pop hl
inc hl ;Need to increment first to get to the character since we started one byte behind
ld a,(hl)
bcall(_VPutMap)
dec c
jr nz,tokenloop
pop bc
pop hl
pop af
bcall(_IsA2ByteTok) ;Check if it was a 2 byte token
jr nz,+_
inc hl ;increment hl for next calc since token was 2 bytes
dec bc ;decrement bc since token was 2 bytes
_:
cpi
jp pe,loop ; pe is used to test if BC reached 0.
bcall(_getKey)
ret
CheckXPos:
ld (hl),1 ;Just want a 1-byte string. HL points to an already drawn char, so no need to save it
bcall(_SStringLength) ;Returns length in A and B
ld a,(penCol)
add a,b ; Grab the future penCol position
ld b,a
dec b
dec b
ld a,(mX)
cp b ; call Resetcur if pencol > mX
ret nc
Resetcur:
ld a,(cX)
inc a ;if pencol > mX, change the cursor position
inc a ;to next line before writing
ld (penCol),a
ld a,(penRow)
add a,6
ld (penRow),a
ret
12
« on: January 30, 2019, 09:40:54 am »
It looks like you are only displaying the first ASCII character of the token, btw. When you use Get_Tok_Strng, it returns how many characters there are in BC (alternatively, you can use C, since B=0 always). If vPutMap preserves HL and C, you can loop through like this:
puttokloop:
ld a,(hl)
inc hl
bcall(_VPutMap)
dec c
jr nz,puttokloop
13
« on: January 29, 2019, 10:45:58 pm »
You can use the _Get_Tok_Str bcall to convert a token to it's characters. Another routine that might be useful to you later is _SStringLength which calculates how many pixels wide a string is in the variable-width (small) font.
14
« on: January 29, 2019, 09:53:54 am »
Haha, yeah, VAT manipulation is a pain. I saw your Axe program and it looks pretty low level; have you ever done any assembly work?
15
« on: January 29, 2019, 09:47:32 am »
Necroposting is generally frowned upon (the last post was over 5 years ago); ideally you should create a new topic. That said, cool! I don't see how it sorts or anything :| To me it looks like it just filters out programs
|
Show Posts