Show Posts

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 - E37

Pages: [1] 2 3 ... 24
TI Z80 / Re: Accurate Subsecond Timing
« on: March 09, 2024, 05:18:07 pm »
According to wikiti, TI-OS uses all but 1 timer for its own purposes.

This is the code that Axe uses to input and output to Ans:
Code: [Select]
p_StoreAns: ;sets ans to hl

p_RecalAns: ;reads ans into hl
ex de,hl

Axe / Re: MExp: A Monster's Expedition in Axe
« on: January 11, 2024, 08:32:16 pm »
You could use an interrupt to run it at a consistent rate which will give you smooth greyscale. Axe has commands to let you create one. The library GreyLib will let you get almost perfect greyscale without any flickering at all. It does use a lot of processing time to get that quality though so your program will run noticeably slower.

The Axe Parser Project / Re: Snake: What’s wrong?
« on: December 07, 2023, 03:22:48 pm »
Ans in Axe is TI-Basic's Ans. That means that changing it lets you communicate with TI-Basic but it is also as slow as using Basic. Speed isn't a problem for your code but you should avoid it in the future. I usually use the letter variables for scratch space.

ASM / Re: Stable offscript for TI-83+
« on: October 19, 2023, 01:27:41 pm »
what failsafe did you end up adding, it made it work now without any issues.
I added ld iy, flags. No idea why that fixed it. The hex for it is now FD21F089FDCB33CEC9
Code: [Select]
#include ""

.db $BB, $6D
ld iy, flags
set 1, (iy+33h)

is there a way to decompile compiled asm programs?
Yes, but only to the text based assembly instructions like I have been posting. Unless you understand them, you won't gain much from decompiling. There are probably tools to do it but I'll cover the manual way since it is good enough for most situations.
First you need to get the code you want to disassemble into hex. Writing an Axe program to do that is pretty trivial.
Once you have it in hex, you just need the opcode table. I use this one. Then you look up the hex in the table.
To cover the hex I gave you earlier:
FD21F089 translates into ld, iy, 0x89F0. If you check in, you will see that the value of 'flags' is 0x89F0. The first byte of that instruction 'FD' is a prefix that tells you to go to the IY section. The second is '21' which is ld iy, nn which loads the next two bytes into iy. The next two are F089. Since the z80 is little endian, the byte order is reversed which gives 0x89F0 as the value for the instruction.
FDCB33CE translates to set 1, (iy + 0x33). (0x33 and 33h are different ways of writing the same thing) It again uses the IY section and then another to go to the IY bits. Its 3rd byte is actually the offset so the 4th one is the instruction set 1, (iy + n)
C9 is a single byte and translates to ret.
Following those steps will let you translate any assembly program to readable instructions and let you go the other way and convert instructions to hex.

what does mov9ToOP1 do?
i tried googling it but cant find anything, that and the .db i cant find
I've been reading the manuals both for Z80 and Ti-83+ system routines, and the system routines manual uses it to but neither explain what it do.

(i've never used C before either which definitely doesn't help here, i only know python and Basic, so some of these might be common things i just never learned about. if they are what other things can i look up to get more info bc every search with ti-83 and z80 dont give me anything)
Here is a good tutorial on the basics of asm. Learning assembly when you are only familiar with high level languages like Basic and Python will be a huge jump.
Here is the best documentation on the OS. It assumes you are very familiar with assembly and is generally lacking in specifics but is still the best resource out there. It answers your question on this page.
Unless you are trying to exploit something specific in the OS (like offscript) you are probably better off using Axe to do anything fancy. Since you can inline assembly in Axe, it is still generally better to write your program in Axe and only inline asm when needed.

ASM / Re: Stable offscript for TI-83+
« on: October 18, 2023, 07:47:27 am »
It looks like I made a copy-paste error for the command to compile the iy program. It should compile to SETIY.8xp not SETIY.8xv. So just change the extension in the compile command.

I tried the programs in a ti83 emulator and they worked fine. However I added a safeguard to set_iy. (see attached) If that works, I'll give you the hex for it.

ASM / Re: Stable offscript for TI-83+
« on: October 16, 2023, 05:42:42 pm »
but isn't that already compiled?
Yes, the programs I attached are compiled and ready to use.

if so than how can i change A to W and recompile it, ect
To change A to W, see the second to last line in the offscript.asm from my last post.
There are two seperate programs, offscript.asm and set_iy.asm. You just make the files like a normal text document on your pc and paste in the code for each. My commands assume you created the files in the same directiry as spasm.exe. Then open command prompt in that directory and run the commands to compile each one. The compiled programs will appear in the same folder as the source code. I attached an changed version of offscript that deletes W instead.

also it seems your commands for spasm are different than the commands listed by spasm, is there multiple versions of spasm?
I don't know what you mean by different commands. I used this to compile the programs. I used a fresh download so I am sure that the binaries there work. I did use the linux version so your use for windows may vary slightly. Your spasm installation should have a 'inc' folder where is. (it comes with that - but checking for it is a good way to know you have the right folder).

but uhh, your assembly code causes an immediate crash, unless it requires the offscript to be there i think theres a mistake in it
SETIY did? I did test using a ti84 emulator but I can't imagine why it crashed. It doesn't require offscript and should always be safe to use. (Of course if offscript is buggy, you might crash when you turn your calc off but running SETIY on its own should never crash) Offscript won't work if it is archived but I don't think that is what you are doing.

ASM / Re: Stable offscript for TI-83+
« on: October 15, 2023, 05:09:45 pm »
This time I actually did my homework.
I tried modifying Str0 and got it to work as a program but couldn't get it to work as offscript.
So how about deleting a letter variable? Those can be read when deleted. You could set the variable to a special value to mean the login was still valid and if it is 0 then discard it.
I actually tested this and it works for me. You need to run the program SETIY in order for offscript to work. (It is safe to run it multple times) If you have a way to run asm in Basic, you could run FDCB33CE instead.

Code: [Select]
;compile with ./spasm -I inc -T offscript.asm OFFSCRPT.8xv
;or spasm.exe -I inc -T offscript.asm OFFSCRPT.8xv if you are on windows
;This deletes the letter variable 'A' but all you have to do is change the letter below and compile if you want a different one
#include ""

.org $8001
ld hl, name
RST rMov9ToOP1
B_CALL _ChkFindSym
ret c
B_CALL _DelVar

.db RealObj, 'A', 0, 0 ;you can change 'A' to any other letter you want (make sure it is uppercase) to delete that letter instead
.db 0

Code: [Select]
;compile with ./spasm -T set_iy.asm SETIY.8xv //You are free to rename this program to whatever you want either here or on calc
;or spasm.exe -I inc -T set_iy.asm SETIY.8xv if you are on windows
;All this does is set a single bit to true. If that bit is false, the OS won't run offscript even if it exists
.db $BB, $6D
set 1, (iy+33h) ;sets bit 1 of iy+33h to indicate that there is an offscript installed

ASM / Re: Stable offscript for TI-83+
« on: October 14, 2023, 09:06:48 am »
You would use a compiler like spasm-ng to compile the asm code. You can put asm code anywhere as long as it is set up correctly to run. To sidestep the problem, can't you just have a prompt on exiting the program that asks the user if they want to log off? I don't remember exactly how to mess with TI-Basic strings. I think they work just like programs. I usually use Axe for stuff like that so I will have to look up how to do it in asm.

ASM / Re: Stable offscript for TI-83+
« on: October 07, 2023, 05:26:30 pm »
Warning: Asm can and will crash your calc and reset your ram. Archive anything you care about and ideally back up everything to your PC.

I can't exactly picture how your system works but I'll take that Str0 stuff and run with it. Would deleting Str0 on Offscript work? The assembly for that is very simple. I haven't tested this but it *should* work. It has been a long time since I have messed with TI-Basic strings so I might have messed up the name. Also this won't work if Str0 is archived.
Code: [Select]
;Put the (binary) contents of this in appvOFFSCRPT
.org $8001
    ld  hl, name
    RST rMov9ToOP1
    B_CALL ChkFindSym
    ret c
    B_CALL DelVar

    db StrngObj, tVarStrng, tStr0, 0, 0

ASM / Re: Stable offscript for TI-83+
« on: October 04, 2023, 07:54:25 pm »
I believe zStart is only one app page. Since app sizes must be a multiple of 16384, it can't be any smaller. (If it is two pages, ignore that) I have used it extensively on the 84+ and not had any issues. What part is crashing?

I get that you are on a 83+ and flash space is tight but you pretty much have to use an App (and pay the full 16k for it) or do it the hard way in asm. Here is the WikiTi page that covers Onscript/Offscript. Note that the code for them is limited to 255 bytes and needs to have its origin at appData+1. That means you can't use Axe since it doesn't let you change the origin from 0x9D95. (Very basic Axe programs would work as long as the compiler doesn't use any position dependent instructions) You will also need to restore the appvar every RAM clear (which zStart does by modifying the OS itself).

There are other features in the OS. If you tell me what your goal is, I may be able to suggest some other feature to do what you are trying to do.

ASM / Re: Stable offscript for TI-83+
« on: October 04, 2023, 05:43:11 pm »
@Cholsrea I'm not sure what you are trying to do. Are you trying to run a program on startup? zStart is a really awesome tool that lets you run programs on startup (among other things). The download has two different apps, one for the 84 and one for the 83 so make sure you install the right one. If that isn't what you are looking for, a lot more details would be helpful.

The Axe Parser Project / Re: Buff() Command Help
« on: October 02, 2023, 08:41:44 am »
And if it just returns normal data, does that mean that the following hexadecimal, when stored to a pointer, can be drawn as a buffer with a line on the left side of the screen?

[800000000000000000000000 (repeat shown hexadecimal for 63 additional rows, total of 64 rows)…]
Yes. DispGraph(ptr to that data) would display a blank screen with a line on the left side.

In general, unless you are really hurting for speed, you can get away with redrawing everything each frame. Axe's drawing routines (except for text) are very fast.

The Axe Parser Project / Re: Buff() Command Help
« on: October 01, 2023, 08:16:56 pm »
Axe's documentation uses 'buffer' to mean 'a pointer to some data'. Any command that takes a buffer is really asking for a pointer. As long as the data you are pointing to is big enough for whatever operation the command is doing, it is happy.

Buff() makes a buffer by adding bytes to your program. If you make one with a size of 1000, it adds 1000 bytes to your program's size. The lines :Data(0, 0, 0, 0, 0)->X and Buff(5, 0)->X both do the same thing. Buff() is just a convenience if you want a lot of space.
It is a way to get more scratch memory if you run out of space in L1-L6 and don't want to use GetCalc() to create a temporary file to store data in. For example, if you want to store a screenshot (which is 768 bytes) and you are using L3 and L6 for something else, you could use Buff(768)->oScreenshotStorage to have a place to store your data. Since DispGraph can take a pointer, DispGraph(oScreenshotStorage) would display the contents of the buffer. (Of course you would probably want to put something there first)

I can give more detailed help or suggestions if you tell me what you are trying to do.

Super Smash Bros. Open / Re: Featured in a video
« on: September 18, 2023, 03:37:20 pm »
Thats pretty neat. Super Smash Bros Open is definately one of the coolest Axe projects. The camera zooming always realy impressed me.

Axe / Re: Does the Link Port Work in Axe?
« on: July 03, 2023, 11:18:07 am »
Just as a bit of background I just finished my A Levels studying Computer Science which was all in Python, so I don't really have much experience with low-level coding or coding in general, but I have dabbled in C# and (very little) C++, and I've made some basic websites from scratch.
I'm not a fan of Python (whitespace as syntax seems insane to me) but from what I can tell without a Googling spree, your project looks really impressive for school. It looks like you understand how to deal with logic which is most of the challenge in learning to program. I have no idea how experinced you are with programming in general. Unless you correct me, I am going to assume that you are experienced enough to be able to code (with Googling as needed) anything you want in high level languages like Python and understand the concept of pointers but haven't worked too much with them.

I am planning on learning ASM using the Sean McLaughlin Z80 in 28 Days website.
That's a good tutorial. But, before you jump into asm, you should make sure that you are very comfortable dealing with pointers and memory. A good way to do so is to make a doubly linked list in Axe. It doesn't need to be efficient but it will force you to work a lot with pointers. The hardest part will probably be allocating memory. A simple way to do that is to allocate a large block of data with GetCalc() and put your list entrys in there, keeping track of free space as you allocate and deallocate list entries. If you can do that, you are ready for asm.

E37 Can I ask how you learned assembly? Just curious how you got to be so proficient at it. I do think dedicating my time to creating some USB Axiom would be a worthwhile thing, especially as it would benefit future developers whatwith the link cable being so iffy, but I obviously need to learn some asm first  ;D
A USB axiom would be less about learning asm and more about figuring out how the USB port works. All you should need is a couple asm snippets that let you read and write to the various ports. Once you have it all figured out (which will almost certainly be very difficult - I counted 31 USB related ports!) there will be time to figure out how to turn it into an Axiom. Here: ':X:Asm(7DD3(123))' writes the lower 8 bits of X to port 123. And ':Asm(DB(123)6F2600)->X' sets X to the 8 bit value read from port 123. In both, the port number can't be a variable. The little documentation that exists for the USB ports is is here. You could also look at USB related BCALLS (and disassemble them) to see how Ti-OS does communication but that would involve learning assembly and trying to figure what Ti was doing when they wrote the OS is not very high on my list of fun activities.

I learned by writing short Asm snippits, converting them to hex and sticking them in my Axe projects. One of the most important tools I had was a little Axe program that took any program and converted its bytes into hex. It is pretty simple to write, just loop over every byte in order, convert it into hex and dump that hex into an output program. I used that program a lot when I was learning asm. Any time I wanted to know how Axe did something, I would make the shortest possible Axe program that did the thing, compile it and then turn that compiled program into hex. I then used this to (manually) decode the hex to actually readable asm. It was very useful for figuring out all the basics. The compiled code that Axe produces is a lot worse than what an experienced asm programmer could make but it also happens to be alot easier to follow the flow of logic since it doesn't do any super advanced tricks. An important thing to remember is that Axe puts all of its built in functions like Pt-On() at the very end of the program (right before data like strings and sprites). Since Axe's built in functions are written in asm and very heavily hand optimized, they are very diffuclt to follow. If you want to see all of Axe's built in functions check out the Developers/ file in the Axe Parser download. (shortcut) Some have comments but unless you are looking for something very specific or very general, you probably won't learn much.

When you are debugging, it is super helpful to see register values. If you are programming on the computer, Wabbitemu has some super helpful tools for just that. If not, you can set the value of one of Axe's variables to the value of the register and use Disp to print it out. Just remember that Disp modifies the contents of all the registers so you need to push all the ones you care about before calling Disp and pop them after.

Axe puts the results of its calculations in the HL register. So the line 'X+5' would put the result of X+5 in HL. the line '->X' would store the value currently in HL to X. This is useful as you can do Asm(<some hex>)->X and it would put whatever the final value of HL was in X. The line 'X:Asm(23)->X' Is the same as doing 'X++'. A nice way to verify this is to make an Axe program that is just the line X++ and then disassembling its compiled output. Knowing how to interface with Axe isn't needed when learning but it can make your life a lot easier, especially if you want to skip writing boring calculations in asm or use one of Axe's built in funcitons. Playing around with push hl and pop hl to save variables is a fun starting task and one feature that I think Axe is missing. For example ':X:Asm(E5):SomeFuncitonThatModifiesX():Asm(E1)->X' would let you preserve the value of X. I use that so often in my own Axe code that I made a basic axiom to do just that.

When you are ready to write more complex asm code, Mimas is the best on-calc tool I have found. I did notice that it corrupts the program rarely if you leave it alone for long enough to shut down so make sure to save and quit before leaving your calc. It also comes with handy utilities for converting to and from its internal format and text based asm files you can read and modify on your pc. Of course, there are quite a few PC based tools. I use spasm-ng. (for no other reason than that is what Axe was written in - I didn't do a comprehensive study) Different assemblers may use slightly different syntax for things like macros so if your assembler refuses to compile a some code you found on the internet, that could be why.

Learning asm is not an easy task. Luckily, z80 asm is (in my opinion) one of the easiest ways to learn asm. It has a fairly good suite of instructions without any of the complexities that come with a modern architecture like i386. Schools seem to usually teach RISC based instruction sets which can be easier to learn but are (again, my opinion) much more work to use as they only support a couple very simple instructions. Plus z80 doesn't make you deal with relative addressing that many architectures have. It is important to remember that different architectures have their own quirks and tricks from one may not carry over to another. It was a huge shock going from low level calc programming to low level pc programming. Things like cache and speculative execution take the nice optimization strategy of just counting instruction cycles and throw it out the window and SIMD is there to offer great performance at the cost of learning way more instructions. I have been programming for 8 years and the only constant has always been that me from 6 months ago had no idea what they were doing.

@Xeda112358 is way better at asm than me and might have some suggestions for stuff that I missed.

Pages: [1] 2 3 ... 24