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

Axe / Re: Does the Link Port Work in Axe?
« on: June 30, 2023, 06:05:36 pm »
I don't know for a fact that the link port can transfer files. But the Ti-83 has a link menu and no USB port so I assume it can send files over the link port. Looking at some BCALLs, it looks like you can send variables over the link port. Again, I'm not 100% positive, but I can't imagine why a Ti-84+ to Ti-84+ SE link wouldn't work. From the documentation, it seems like the link cable is just 2 lines that either calc can pull low. Since you can put the same OS on a Ti-84+ and a Ti-84+ SE the communication code would be the same. With such basic hardware and identical software, I think it is pretty safe to say that isn't the issue. (And I can't imagine why TI would put a link port on a Ti-84+ if it wasn't compatible with a Ti-83+ too)

Since you have a USB cable, you might be able to do your communications over that. WikiTi is the best documentation you can get for low level stuff like that. There is a lot of ports related to USB and they are poorly documented so unless you really feel like digging, you should probably stick to the link port. If you decide to go for it, I can help you with asm <-> Axe conversions and some guesswork but it will likely be very difficult. But, if you succeed, you could make a super cool Axiom for USB linking for future Axe programmers.

Axe / Re: Does the Link Port Work in Axe?
« on: June 30, 2023, 12:27:56 pm »
The first question is how sure are you that your link cable is good? I wouldn't be surprised if a cable not designed for linking doesn't work. I had a generic cable years ago (and lost it) but was never able to get it to work. A good way to verify this is using the built-in linking tools. Ti-OS has functions like GetCalc( which lets you send variables from one calc to another over a link cable. Or you could use 2nd-X to open the link menu on both calcs and use that to transfer something. If you can send a variable from one calc to another, the cable and link ports are good. If you can't, then there isn't any point in continuing further.

If you are familiar with assembly, you can use Port 0 and try setting a line low on one calc and see if it is pulled low on the other calc. If you aren't, I can write you some simple hex to use it in Axe once you verify the cable can actually transfer data with Ti-OS.

Axe / Re: Converting from Prgm to App
« on: April 13, 2023, 07:37:48 am »
Alright, so I took a look. I just put a bunch of Disp #>Dec statements everywhere so I could see how far execution got. That showed me that it quit right at the line 'Goto UPDATEEND' in your update program. I tracked the problem down to a specific line elsewhere but I will get to that in a minute.
Luckily, there is an easy solution. I moved all your include programs to the end. Since Axe executes in order, putting all your includes at the end means that you don't need Goto statements at the beginning of them anymore. Unlike C, Axe doesn't care about definition order so putting all your includes at the end doesn't hurt anything. If you look at the source for the RTS I sent you, you will notice that that is how I do it for all my code.

When I moved all your includes to the very bottom of your program, it worked fine. The problem? The line 'Pause 16' is the source of all your troubles. From what I can tell that is a compiler bug. That's impressively bad luck, I have only seen 4 compiler bugs in all my time working with Axe and only one like this one where it wasn't just the fault of a function. (For example, Copy()r is a broken function, don't ever use it) Messing around with it some more, I wasn't able to get it to break in a simple test program so there might be more going on. I have used pause many times (although not really with a goto statement jumping over it) so pause isn't just broken. The workaround of moving all your includes to the bottom should fix your problem and make your code a little cleaner. And congratulations on breaking Axe.  ;)

The trick to debugging things like this is to put Disp statements or some other way of showing information all over the place. You will see what is being executed and what parts it didn't get to. Printing out variables also can help for some tricky logic. With that, it only took me a couple minutes to find the problem Goto statement and by moving around the UPDATEEND label, 10 minutes more to find the Pause statement problem.

Axe / Re: Converting from Prgm to App
« on: April 11, 2023, 08:37:49 pm »

The game runs at 15MHz but that is mostly because of graphics. Without drawing, the game could easily run at 3MHz. If I wrote everything in assembly, I could probably get it in its current state to run at 6MHz but it relies on other hardware features of the TI-84+ so it will never run on an 83. Compiled, it is over 100k of executable code. Does the 83 even have that much flash? I guess I could compile the game as an OS but that is way too much work.

The font is my text axiom. You can do the same thing with the built in Text command but that requires a font hook which requires some Asm work. Axe normally just calls TI-OS's text drawing command which is why mine is so much faster.

Axe / Re: Converting from Prgm to App
« on: April 11, 2023, 06:43:06 pm »
State machines are efficient and there is nothing technically wrong with your implementation. They just get complex very quickly and unless very small or very carefully documented are very difficult for your future self to come back and debug. If you can deal with that, there is no reason not to use them.
I wouldn't worry at all about optimization. Heavily optimized Axe code is very difficult to read and that is the last thing you need when you are still learning. Besides, heavy optimization is usually only worth at the most a 20% speedup unless the code is especially inefficient. You will usually get much more significant gains from reorganizing logic - which is easiest if you have clean code.

When I was learning how to program I messed around a lot like you. I have thrown away far more code than I have kept but learned a lot from it - hence the signature below my avatar! Also, re-implementing concepts in Axe is a really good way to understand them. If you can write it in Axe, you can do it any language.

If you are interested, I can send you the source for a real-time strategy game I programmed in Axe. Here is some screenshots. You will need an 84+ SE to hold all the source and the compiled code and I use several custom axioms. It will be quite difficult to follow the flow of execution (although individual features shouldn't be awful)

Axe / Re: Converting from Prgm to App
« on: April 11, 2023, 08:40:43 am »
You are making this way harder than it needs to be. All you need is an if-else chain like this:
Code: [Select]
If getKey(1)

ElseIf getKey(2)

ElseIf getKey(3)

ElseIf getKey(4)


To answer you original question, I don't see anything wrong with your logic. The UpdateState isn't initialized when you code first starts but it isn't initialized in your original code either. Beyond that, I don't know. I don't think I have ever actually used sign{} in serious code so it is possible but very unlikely that there is a bug there. The full source would be useful in troubleshooting because I don't see any problems with what you have. I'm not sure what you are doing with UpdateState in general. Are you are trying to make some kind of state machine? I would avoid that if possible as state machines like that can be way harder to debug than Goto spaghetti. (Source: I do that for a living)
I did notice the line 'PlayerX+sign{I-1+°DirY}→PlayerY' That PlayerX is either a typo or a bug.

A quick code critique:
In both this snippit and the code on GitHub, I noticed that you tend to over complicate logic and rely heavily on indexing into arrays. Both are great ways to spend 80% of your time debugging. Here is how I would write movement code. I have a bit more code than your example but I am doing more checks.
Code: [Select]

1→°KDown+1→°KLeft+1→°KRight+1→°KUp .add some constants for the arrow keys. In my code I define every key like this. Now, I don't have to remember that 2 is left, I just type °KLeft

Lbl UpdatePlayer

getKey(°KClear) or Quit→Quit .getKey returns either 1 or 0. I use 'or' so as not to set Quit to 0 if it was 1 when we got here. This should be moved to the main loop since it isn't player related code.

If ScrollXOffset
If >>0
.-4??PlayerX++ .If you want to make PlayerX change on the boundary of tiles instead of when movement starts, you can uncomment this and remove the PlayerX++ from the getKey block below
Return .Don't let the player push keys during scrolling
ElseIf ScrollYOffset .Doesn't need to be an else-if (because of the Return in the line above) but it doesn't hurt anything and makes the intent clearer
If >>0
.If execution makes it here, both ScrollXOffset and ScrollYOffset are 0. The screen isn't moving so it is safe to pick a new direction

.getKey(num) commands are very quick. Don't be afraid to check the same key multiple times if it makes your code cleaner. It *is* possible that the key state changes between checks but unlikely. As long as you keep that in mind, it is totally fine to do.
If getKey(°KDown) ? getKey(°KUp)-1 .getKey(°KUp)-1 is the same as getKey(°KUp)=0. Checking both keys makes the player not move if up and down are both held. It is a preference thing and not needed if you don't like it
If Walkable(PlayerX, PlayerY+1) .Or whatever check you use to see if the player is allowed to walk into a given tile. I check this inside the if-else chain so that the walkable status of a tile doesn't impact what direction the player is moving.
Goto UpdatePlayer .This is optional. Without it, the player will spend one tick standing still for each tile they move, making movement seem slightly jerky on an actual calc
ElseIf getKey(°KUp) ? getKey(°KDown)-1
If Walkable(PlayerX, PlayerY-1) .You don't check for collision in your code. I assume that will be added later? If it doesn't apply, just remove the 'If Walkable' statements
Goto UpdatePlayer
ElseIf getKey(°KRight) ? getKey(°KLeft)-1
If Walkable(PlayerX+1, PlayerY)
Goto UpdatePlayer
ElseIf getKey(°KLeft) ? getKey(°KRight)-1
If Walkable(PlayerX-1, PlayerY)
Goto UpdatePlayer
.I only did a couple minor optimizations in this example since my goal was readable code. There is quite a bit that can be done with this code but that is left as an exercise to the reader.


Axe / Re: Converting from Prgm to App
« on: April 04, 2023, 07:57:01 am »
Alright, a rewrite often helps eliminate nasty bugs. And there is no difference at all between built in variables and custom ones. Anything you can do with one, you can do with the other.

Since you are rewriting, I have a couple suggestions:

You make two appvars but both are a fixed size. You could combine them into one big appvar. Additionally, you only need to call GetCalc after creating new appvars or resizing existing ones. Once you have created all of them, they won't move.

Free RAM areas:
0x966E is 128 bytes of free memory like L5. It normally holds the contents of the homescreen. (So Disp will overwrite data like L5) When you quit, call Fill(0x966E, 128, ' '). That is just filling it with the space character so it appears blank. I use this one a bunch so I am super positive it is very safe.
0x8000 is 256 bytes of free memory. The end of it overlaps with L4-512 (not a problem if you don't use L4-512 as a 756 byte buffer) But even if you do, it is still 165 bytes of memory. You don't need to clear it or anything when you quit. This also means that if you combine 0x8000 and L4, you get a 933 byte long block of memory. Just remember that it will be corrupted on flash operations (which you aren't doing)
0x8E2C is 400 bytes of free memory. Just fill it with 0's when you quit.
0x85E7 is 158 bytes of free memory. I don't think you even need to fill it with 0's when you quit but you might as well to be safe.
L2 can be used as a 768 byte buffer if you fill it with 0's when you quit. (Hint: you can use ClrDraw(L2) instead of Fill(L2, 768, 0). Its faster and smaller (assuming you have used ClrDraw(buffer) somewhere else)
I think that is all the juicy free memory areas. There is quite a bit of smaller ones but they aren't really worth it unless you are really hurting. Omnimaga's free ram page is a very good tool (Ignore anything it says about Axe - it is very outdated) When using it, make sure to double check that you aren't overlapping any of Axe's variables. To do that, you should do 'Print oA>Hex' Repeat for A-theta, r1-r6, Y1-Y10 (Y variables take up 3 bytes each), X1T-Y6T (the parametric variables - yes, those are built in Axe variables!) and L1-L6. Compare the printed addresses to the free ram are you are looking at.

When dealing with the AI of a bunch of different mobs, it is really awkward (and super slow) to keep having to call {CurrentMob + 5}r and the like to access its variables.
Compare these two pieces of code:
Code: (Hard to read) [Select]

Lbl MobAI .r1 is the pointer to the mob's data
r1->X .save R1 so function calls don't clobber it

.IsWall and similar functions are just made up psuedocode for the example
!If IsWall({X + oMobX}r + 1, {X + oMobY}r) .Simple, but it will get messy quickly
{X + oMobX}r++

!If IsWall({X + oMobX}r, {X + oMobY}r + 1)
{X + oMobY}r++

!If {X + oMobHP}r


Code: (Easy to read) [Select]
L1+0->MobX .Put your Mob data at a predetermined spot. I usually use 0x966E (described above in the free ram section) but you can put it wherever you want.

Lbl MobAI .r1 is the pointer to the mob's data
r1->X .save the value of r1
Copy(X, oMobX, SizeOfMob) .Copies the mob's data to a predetermined spot. Fill in SizeOfMob with however big your mobs are, in bytes.

!If IsWall(MobX + 1, MobY) .This is so much easier to read and type than the above example. And it is way faster and uses less space!

!If IsWall(MobX, MobY + 1)

!If MobHP

Copy(oMobX, X, SizeOfMob) .Copy the data back now that we are done

Asm(E5) pushes HL (which is Axe's version of TI-BASIC's Ans) onto the stack and Asm(E1) pops it. That lets you write code like:
Code: [Select]
Lbl XMagic
X:Asm(E5) .Set X as Axe 'Ans' variable and then push it onto the stack

5->X .Modify and use X however you want
Disp X>Dec

Asm(E1)->X .Pop the last entry from the stack and set X to it

This is super useful as it lets you create local variables.
I don't know how familiar you are with assembly and registers, so I'll explain in more detail what that code does. If you understand what 'push hl' and 'pop hl' means, you can ignore all of this.

Code: [Select]
.Like TI-BASIC, Axe has a variable which is the result of the previous calculation. However, Axe's version doesn't have a name.
X+5 .Add 5 to X but don't do anything with the result. The value is stored in HL which is what Axe's 'Ans' is called.
->Y .Store HL to Y. Since the result hasn't changed, we can use HL again
+2->Z .Add 2 to HL and then store HL to Z
X .Sets HL to the value of X
Asm(E5) .Pushes the value of HL onto the stack. You can push and pop whenever you want as long as you know what you are doing
+5 .Adds 5 to HL
SomeFunction() .Call some function that possibly modifies X. At the start of the function, HL will hold X+5. (so the first line of the function could be '->X' for instance)
Asm(E1) .Pops HL from the stack. Now HL holds the same value it did when the most recent Asm(E5) was called
->X .And save that value to X, effectively protecting it from any modifications that might happen in SomeFunction. (Called functions can push and pop if they want too)

.You can push multiple things to the stack at the same time

For(x, 0, 5)
Disp X>Dec

Asm(E1)->MyVariable .Notice that the order of pops is inverted from the order of pushes

There are some restrictions on when you can push and pop from the stack. Well, you can do it at any time, but if you don't know what you are doing, all you will get is a crash
You must make sure that you call pop the same amount of times you call push before you call 'return'. (This is easy, all it means is that you can't call push a bunch at the start of a function and then call Return without popping everything. You don't need to do anything with the popped results if you don't want to)
The stack is used when calling functions. All that means is that you can't push a variable in one function, call another and pop that variable in the function you just called
The stack is also used for single argument For loops. (3 argument for loops don't have this problem - they use a much less efficient method of looping that doesn't use the stack) That means you can't push a variable outside a For(10) loop and pop it inside the loop. (it is still safe to push and pop inside the loop, just make sure your pushes and pops are balanced inside the loop body.
If you just push some variables at the start of a function and pop them at the end, you will always be safe. It also works well inside complex loops.

All this is mostly useful for pushing some variables at the start of a function and then popping them at the end so you don't need to worry about clobbering a variable used elsewhere. Its also super fast, a push or pop is almost twice as fast as addition! (*comparing 'push hl' [11cc] and 'pop hl' [10cc] against 'add hl, de' [19cc]) I would recommend spending 15-20 minutes trying out different uses for this before putting it any serious code. Its no fun debugging code you don't fully understand.
I use this so frequently in my code that I wrote a personal axiom that adds commands 'Push' and 'Pop' that just do Asm(E5) and Asm(E1) respectively.

Axe / Re: Converting from Prgm to App
« on: April 03, 2023, 08:58:19 am »
@Ki1o Sorry I took so long, I forgot.
I sent your code to my calc and gave it a look. The code in its original state worked fine as a program and an app. As a program, it leaves garbage all over the homescreen on quit. Adding a 'ClrHome' in Exit will fix that. The total compiled program is only 8k bytes total. Since probably 1k of that is data, you still have some space to play with before you hit the execution limit.

When I uncommented all of your AI code, it consistantly corrupted regardless of whether it was a program or app. I also noticed that the slimes always ignored walls - even before corrupted garbage showed up on screen. I am still digging around but my guess is that bu the time the character walks around that big loop, the slimes move so far out of bounds that they corrupt some area of memory. Regardless of what the cause is, as far as I can tell, it has to do with the mob AI and not compiling as an app.

Axe / Re: Converting from Prgm to App
« on: March 27, 2023, 08:00:50 pm »
I'll take a look. I'm kinda busy at the moment so it may be a couple days until I find an hour or two to sit down and hunt through it. If you just want to have over 8811 bytes of executable code, fullrene is probably a better choice over an app (just because it compiles faster) Since the inversion didn't change anything, I think compiling as an app just brings an already existing problem to the surface. None of your code does anything that would matter if it was compiled as app.

You shouldn't try optimizing until you get your code working or have a real need for it. Also, you don't have very much code in total. Are you really running into the execution limit? You are limited to 8811 bytes of code, not data. Your data can go above that limit. I guess I will see when I actually sit down and compile it ;)

Axe / Re: Converting from Prgm to App
« on: March 24, 2023, 03:56:29 pm »
I don't see any overflow protection for A* pathfinding although I could have missed it in the complex logic. Right now you create appvFLOOR before appvDISTMAP. Try creating appvDISTMAP first (Just invert the order of the two GetCalc lines in main) If you are overflowing, that should change the overflow behavior. If you aren't then nothing should change. I noticed you used sign{ in quite a few places. I don't know what that is supposed to be, my best guess is the signed{} command. If it is nib{} then that would be the source of your problems. But, based on how you are using it, it looks like signed{} which is fine. The line 'Fill(^^oTargetX,400,0)' seems a little strange but it should be safe. I don't have any other suggestions, I took a hard look at it for over an hour and didn't see any red flags. Do you reset ram after every time you quit normally?

Also that is some beautifully optimized tile drawing code.

General Calculator Help / Re: ti connect can't find my ti 83 plus
« on: March 21, 2023, 03:17:35 pm »
still won't work
Then you are out of luck. If you write out a detailed list of what you have done, what software and hardware you have, I might be able to find something you have missed. But so far all you have told me is that you have a TI83 and it won't work.

General Calculator Help / Re: ti connect can't find my ti 83 plus
« on: March 19, 2023, 02:36:40 pm »
Alright, I double checked TI Connect CE's supported calcs and it doesn't support the TI-83. So that's unfortunate. I guess you are stuck using TI Connect. You will need to reset your calc's ram before and after doing pretty much anything when dealing with TI Connect. I haven't actually dealt with connecting an 83 to a PC as I just work with 84s. Try resetting your ram, plugging it back in and if that doesn't work, try a couple more times. Sometimes it just doesn't feel like working. Restarting TI Connect or even you PC might help too.

There are other linking programs out there. TILP is pretty good. You can download it here. You have to pay attention while installing it because it requires GTK2+. It will run the GTK2+ installer after its installer by default. When going through the GTK2+ installer you MUST enable the 'compatibility dlls' checkbox or TILP won't work. I just installed it on my Windows 10 partition and it works fine for me (at least it launches, I haven't tried sending files with it) so if it doesn't work for you, chances are you missed a step while installing. If that doesn't work even after a couple ram resets, you might try looking around on the internet for other linking software. Its possible that your link cable or other hardware is bad.

If you just want to send things to your calc, resetting all memory might fix things. But that will wipe anything in flash.

General Calculator Help / Re: ti connect can't find my ti 83 plus
« on: March 18, 2023, 07:25:57 pm »
@burro_ciao TI Connect is pretty hit or miss for connectivity. (and mostly miss) You should use TI Connect CE which actually works most of the time. If TI Connect CE can't find your calc, archive everything you care about and then reset your ram. That usually fixes connectivity problems.

Pages: [1] 2 3 ... 24