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: Yesterday at 11:45:55 pm »
As an update and backup to Omni, I have been working on some of the extended precision routines. At this moment, I've rewritten multiplication and square roots, and I am about to work on division. The square root routine is now averaging 9183.443cc, a full three times faster than the previous implementation ! (and over 9 times faster than the TI-OS float algorithm). The multiplication routine is now averaging 9925.527cc, a more humble 8.5% improvement. (still ~3.5 times faster than the TI-OS float multiplication). A good chunk of the speed improvement comes from a slightly faster 16-bit multiply routine from Runer112, which also has much nicer/more useful output registers. I had an issue with the new square root algorithm, so for now I have patched it up so that it works, but it's about 1000cc slower than necessary. In the process of implementing this new algorithm, I rewrote some faster division routines and I might be able to get division down below 13000cc, a 30+% speed improvement (3 times faster than the OS routine).
2
« on: December 04, 2018, 01:42:56 pm »
Okay, added screenshots, thanks!
3
« on: December 04, 2018, 11:37:42 am »
TICalc.org's Program Of The Year polls are open! For the TI-83+/84+ category, it looks like a bunch of older projects split between two authors-- myself and squidgetx ( ticalc profile). Up for the vote are the following programs (in the order listed on ticalc.org). Batlib ( ticalc link) Batlib is a huge library for BASIC programmers. It has 120+ functions mostly for graphics and string and data manipulation, list and matrix manipulation, compression, and much more.  CopyProg ( ticalc link) This is a small program that allows users to copy variables from RAM or Archive to another variable. CopyProg2 has a few other features as well (like line reading and reading the names of the variables on your calc). It allows you to do things like copy an archived appvar to a temp program for execution   Embers ( ticalc link) Embers is an ARPG that won Omnimaga Contest 2012. This was a really well put together game. It features good graphics, good AI, and storyline. -embersphoenix/?action=dlattach;attach=13111) FloatLib ( ticalc link) Floatlib is an app that holds many single-precision float routines from addition to hyperbolic tangent. It comes with a built-in reference manual and there are some examples like computing the Mandelbrot Set.  Gravity Guy ( ticalc link) Gravity Guy is "a port/variation of the popular iphone/flash game" of the same name. You basically get to flip the direction of gravity to help navigate obstacles.  LblRW ( ticalc link) LblRW is a small utility for BASIC programmers that lets you read or modify data within the BASIC program, using a label offset. That's a mouthful. Basically, "Hey, I want to store player data in my RPG, let's store it after Lbl PD." Or you can store monster data for quick access for example (no screenshot, sorry  ) StickNinja ( ticalc link) StickNinja was an Omnimaga Contest 2011 entry that earned 3 rd place. It's basically a platformer with awesome Stick Figure and Ninja graphics. Collect coins, destroy enemies; It's got it all. /?action=dlattach;attach=8632)
4
« on: November 30, 2018, 12:52:54 pm »
If you are a masochist, then technically no, as you can type in the hexadecimal opcodes directly on your calc. For everyone else, you can use a program that compiles a text file to a binary. The calculators have two main compilers -- Mimas and asmdream (I'm on mobile, otherwise I would look for the links). On a computer, I prefer spasm-ng, but there is Brass as well.
Personally, I jusy use a text editor, save my file with the .asm or .z80 extension (not really important) and then compile that to a .8xp
5
« on: November 24, 2018, 07:49:01 pm »
Oh, I'm glad you figured it out! That was the first mistake I had to fix in my first implementation 
6
« on: November 23, 2018, 12:50:37 am »
I'm too tired for a full report, but I'll use this as a backup.
I fixed a few bugs introduced in the last version, optimized and cleaned up some more code, and most importantly, I totally overhauled the module system. I renamed the token to just '$'. By storing to it, you can basically register a module to be searched after the default one is searched. At the moment, up to 5 additional modules can be used, which could greatly extend the functionality of Grammer. They can be archived now, and I moved the Menu routine to an external module (appv Grampkg). I still need to do a lot of documentation, but not tonight. Attached is a screenshot of what the code looks like (with the token hook). Good night y'all.
7
« on: November 19, 2018, 03:44:40 pm »
13 Nov. 2018
- Cleaning up code, removing (at least temporarily)
routines that aren't vital, or useful.
- Fire graphics code. **Probably temporary.
- Factoring code. **Probably permanent.
- Optimized CopyHex
- ConvHexStr is reorganized to be smaller
14 Nov. 2018
- Optimized ConvOP1 to be smaller, updated performance
analysis
- Optimized GetPixelLoc 3 bytes smaller, 10cc faster
- Optimized ReadArc routine. 3 bytes smaller, 18cc
faster for archived data, 3cc slower for data in RAM.
- Removed LoadTSA as the only internal usage was to load
the ReadArc routine. Instead it is a specialized routine
that no longer destroys IX. Next savings of 11 bytes,
even after extended the mov9 LDI chain to a mov13. Saves
172cc overall (186cc, actually, since no more ld ix,**)
- Error also takes advantage of mov13, saving 2 bytes.
- Added a few more fixed-size moves, including mov768.
Total cost was 6 bytes.
- ClrHome uses the faster SetSmallMem, saves a byte.
Makes it 901cc faster, roughly 21% faster
- I removed the unknown routine I labeled "lbl000", as it
isn't used anywhere (or shouldn't be!) It looks like an
attempt at making an off-page call, probably when the
low mem scared me.
- Optimized and fixed IsHexTok. It used to accept the
' and ' token as equivalent to 9. Saved a byte and 2cc
when the token was 0~9.
- Optimized DE_Times_BC. No change in size, 120cc faster
in the average case. No longer leaves A=0.
- optimized HL_Div_BC to be 264cc faster on average, with
a net cost of five bytes. DE_Div_BC is now the
subroutine, though, and is 272cc faster than if you had
called it previously. Nearly 18% speed up
- Fixed SearchString at a cost of 8 bytes, but should
perform roughly 4 times faster. Also, there is now no
risk of it entering an infinite loop, an issue the
previous routine had.
- SqrtHL is optimized. Actually replaced with SqrtDE.
Saved 2 bytes, on average 261cc faster (20.17% faster).
Worst case is still 165cc faster (12.75% faster).
15 Nov. 2018
- I replaced the Sqrt routine with Runer112's from Axe.
It is 221cc faster with the small modifications on my
part to fit the output registers, and 2 bytes smaller.
That's roughly 21.5% faster.
- Removed ConvNumBase and HL_Div_C. HL_Div_C was only
used by ConvNumBase, and ConvNumBase wasn't used
anywhere in the code.
- Changed Is_2_Byte. It's no faster or slower, just
a little more sensible and readable.
- Removed HexTok and GetHexAtDE.
- Moved CompatCall so it didn't have to JP to
IsOP1GrammerProg, saving 3 bytes and 10cc
- Removed EndHook2 as it appears unused?
- Optimized ONErr to be 1 byte less, 2cc faster.
- Optimized TileMap1. 21cc faster, 2 bytes smaller.
- Removed HL_SDiv_BC replacing the only use of it
with a wrapper around a call to HL_Div_BC.
Net 21 bytes smaller. Signed division command now
averages about 47cc faster.
- Removed PutIM, ParseFullArgI, CallI, CopyZStr,
CreateZVar, FindVar.
- Renamed memory addresses in the Menu command.
May have messed something up.
- vPutscr is 1 byte smaller, 3cc faster.
- Optimized DrawRectToGraphI since it didn't need
to preserve registers. Saved 9 bytes.
19 Nov. 2011
- Did some testing and fixed some new bugs.
- Fixed LoadReadArc. Needed 6 more bytes, saves
another 76cc.
- Opted to use interrupts for the Pause routine. It
isn't as close to 1/100 seconds, but it is more
energy efficient, smaller, and more reliable.
No screenshots as it's just behind-the-scenes code modifications.
8
« on: November 17, 2018, 10:35:44 pm »
Oh, nice work! I wish I knew the HP Prime better so that I could offer some real input
9
« on: November 12, 2018, 09:56:38 pm »
After only 7 years, a real menu!:  Scrolling up is noticeably slower than scrolling down.
10
« on: November 09, 2018, 09:39:43 am »
Pretty much the only difference in the BASIC language is no real graphics functions on the nspire. The rest is pretty much the same.
11
« on: November 08, 2018, 09:53:07 pm »
Thanks for weighing in, Stefan, you are probably one of the most knowledgeable 68k/nSpire BASIC programmers here, so you'd really know what was feasible ^_^ And the link looks pretty useful.
12
« on: November 08, 2018, 09:49:11 am »
I have been cleaning up code and doing some optimizations and modifications. I probably broke something, but I wanted a backup. Updates:- I cleaned up the source a bit.
- Going with the previous update, without the jumptable I had so e unused routines (intended for Grammer Assembly programs) that I removed
- I implemented some custom VAT traversal routines. The OS routines were incredibly slow and I needed an excuse to use my VAT sort code
- Added in code to throw an error if a Grammer Assembly program is run.
- Version number is going to be sensible now, starting at 2.50.0.0
- Minor optimizations.
Features I want: - with a sorted VAT, I can speed up the look-up of OS variables.
- I want a scrollable start menu
13
« on: November 04, 2018, 01:36:27 pm »
Then the next part is to train a neural network to generate an image based on those attributes !
Ijust recently started playing Pathfinder and my first thought was how useful a calc program could be for this.
14
« on: November 04, 2018, 10:56:56 am »
So, fun fact: floating point numbers can be changed to a variable reference instead, kind of like a shortcut on your computer, and the OS doesn't verify it. In assembly, when you are looking for a variable, you put a name in OP1 and use FindSym or ChkFindSym. Those names are 9 bytes, which is also the size of a float (not a coincidence-- it's part of why names are limited to 8 bytes). You can actually change the contents of a Real variable to such a name, and when you try to read it's value, it will instead return the value of the variable it points to. For example, change the bytes of the Real variable, A, from 008000000000000000 (the number 0) to 015D01000000000000 and when you read A, it will return the contents of L2. Or, since lists are just stored as a bunch of Real (or Complex) numbers, you can modify elements of the list to be pointers. In this way, you could read Str1, Str2, Str3,..., Str0 by reading an element of L1, which could be useful, occasionally Some things to note: You can't modify the contents of the original variable in this way. If A points to Str2, then "33"+A→A does not modify Str2. However, "33"+A will work like "33"+Str2. Storing the names of programs and appvars and whatnot isn't useful.
Attached is a program that turns L1 into a 4-element list {L2,[A],Str1,L1}. Here is the source. You need to delete L1 first, my code wasn't reliably deleting it. #define bcall(x) rst 28h \ .dw x
rMOV9TOOP1 = 20h
_ChkFindSym = 42F1h
_CreateRList= 4315h
.db $BB,$6D
.org $9D95
ld hl,name
rst rMOV9TOOP1
bcall(_ChkFindSym)
ret c
ld hl,name
rst rMOV9TOOP1
ld hl,4
bcall(_CreateRList)
inc de
inc de
ld hl,data
ld bc,31
ldir
ret
data:
.db 1,$5D,1,0,0,0,0,0,0
.db 2,$5C,0,0,0,0,0,0,0
.db 4,$AA,0,0,0,0,0,0,0
name:
.db 1,$5D,0,0
15
« on: November 02, 2018, 01:30:43 am »
Probably, though it would take some effort. Most instruction can use literal replacements, but labels and macros need some more advanced treatment.
|
Show Posts