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

Pages: 1 ... 56 57 [58] 59 60 ... 108
856
TI Z80 / Re: zStart - an app that runs on ram clears
« on: June 07, 2011, 07:20:39 pm »
I tried compiling a file as an app using the hotkey, and it compiled but then it started scrolling garbage across the screen. I got worried then and turned it off, and then I had to hard reset it (hold del, restore OS) to get it back to normal ><

Yeah, that's probably caused because right now it thinks all OS's are non-mathprint. So it never disable's mathprint, which is probably the cause of the error. I knew about this, I just didn't want to post back to back updates.

Edit:
     Updated:
  • Fixed mathprint glitch, (Never actually disabled it)

857
ASM / Re: an other assembly question
« on: June 06, 2011, 03:05:13 pm »
0A18 is part of the OS, you want to try to figure out where execution leaves your code. Your code will be in the $9D95 - ~$B000 range depending on program size.

I put together everything you have posted so far and it ran fine. So I'm really not sure what isn't working right. It might not even be related to the code you posted.

858
ASM / Re: Macosx Spasm n00b question
« on: June 05, 2011, 08:02:50 pm »
But remember that spasm only assembles .asm source files to .bin files. You then need to pack it into a .8xp file, which can be done with bin2var for Mac.After that it's just an ordinary 8xp program that you can send in TI Connect or WabbitEmu.

Actually, spasm can go straight to .8xp (or even 8xk for that matter)

859
ASM / Re: ASM SMC in shells
« on: June 05, 2011, 07:58:56 pm »
Correction: DoorsCS is the only shell I know of with smart writeback. In any shell changes are permanent when you run from RAM (since nobody worries about wearing RAM :P); for running from archive, Mirage writes back if and only if it's enabled in Options, while Doors writes back automatically if anything changed inthe program.

Mirage actually runs an 8 bit checksum to see if there is a change and only copies it back if there is. I would assume Doors uses a 16 bit one though.

860
ASM / Re: ASM SMC in shells
« on: June 05, 2011, 07:05:52 pm »
Yes, smc will be permanent in shells.

There is a way to get around writeback if the program is in the Archive. But it's not worth talking about it because a program in ram will always be copied back.

861
ASM / Re: an other assembly question
« on: June 05, 2011, 07:02:21 pm »
Ok, the problem is definitely in NegBC, NegDE, or NegHL. So make sure that each of those looks the same, except for the actual register you are negating, and post those, because everything you have posted so far won't crash.

And for debugging, you typically want to use F8. So just keep pressing F8 until it crashes, it will crash when you skip over a routine. Then when you go through it again, step into that routine with F7, then repeat. Eventually, in this case, you will probably find a push without a pop.

862
Lua / Re: Will Lua erase the need for Ndless?
« on: June 05, 2011, 12:17:42 pm »
Of course I'm not an Nspire dev. But since Lua is sand boxed, I would compare Lua to this situation.

Imagine that TI-Basic suddenly became as fast as asm. (Yeah right) That would mean that you would be able to write basic games that roughly equal the power of asm games. So as far as the game world goes, no, there would be no need for asm.

But now, try to write a shell in TI-Basic. One that can list all the programs on the calculator and execute them at random. You also want your shell to install a hook that allows programs to be run from the homescreen and setup some more hooks just to make the calculator generally easier to use. (Think zStart). Through TI-Basic alone, you cannot write Utility programs, so you must then fall back on asm even though Basic is crazy fast.

So, assuming that Lua is similar to TI-Basic as far as being sand boxed, my analogy should work.

863
ASM / Re: Getting Total and Current Archive
« on: June 05, 2011, 11:50:39 am »
Runer112, that was really helpful, thanks.

SirCmpwn told me about a BCall that returns Free Archive, _ChkFreeArc.

However, yours is more precise as it returns the same free archive listed in MEMORY, and the BCall is not so accurate.

Well, runer actually uses a bcall too.
Code: [Select]
B_CALL($5014) ;ArcChk

And since this bcall isn't officially or unofficially named, and doesn't even appear in wikiTi or TI's routines, there's a good chance that SirCmpwn and Runer are actually talking about the same bcall ;)

864
ASM / Re: an other assembly question
« on: June 04, 2011, 07:41:39 pm »
Does that have a ret on it? And if so, what does mulFP look like?

One thing I would definitely recommend for you is stepping through your code in a debugger. I feel that this would allow you to see exactly where your code is going wrong. It's much nicer to actually watch the crash take place rather than try to search through all of your code to find the small error.

So, assuming you are using wabbitEmu. Press F11. Press G. Type 9D95 (assuming you are running it from the homescreen). Press F3. Quit the window. Then run your program. What you did was you placed a breakpoint at $9D95, which is where your code starts. Then just press F7 to scroll through the code line by line to see what is going wrong. Pressing F8 will also scroll, but it will jump over stuff like calls.

865
Normally, I'd come in here and say, "Well obviously the OS isn't setting ... flag." But this time, we are dealing with some really nasty stuff. I'm sure the problem is that a flag is incorrectly set, but the question is, which one? Stuff like this starts to fall into the category of editBuffers, and those are full of so many undocumented things that working with them is almost impossible.

This problem probably isn't worth fixing, but I'll probably still try to figure it out for educational reasons.

866
TI Z80 / Re: Chess
« on: June 02, 2011, 03:14:32 pm »
has there been any progress on this, such as fixing the checkmate bug?

Checkmate bug? I thought I fixed that back here. If there's a new problem I'll fix it though.

867
TI Z80 / Re: zStart - an app that runs on ram clears
« on: June 01, 2011, 11:05:33 pm »
Is there a way to view a list of what's assigned to what on+num shortcut?  Like, calcutil has a program it reads from, which can be edited through the TIOS editor.  If not, there's another feature request for ya ;D

That's not a bad idea to show a list of the shortcuts. I don't know how feasible editing with TIOS is though because right now I keep the shortcuts locked in the zStart appVar which is always archived.

Quote
Also, might it be possible to ON+ENTER compile from the homescreen?

Sure!! But what would it do? You press ON+ENTER, now what happens?

868
TI Z80 / Re: zStart - an app that runs on ram clears
« on: June 01, 2011, 08:47:22 pm »
Axe Update!!!!!!!!!!!!!!!!!!!

Updates:
  • ON + [ENTER] in Edit menu - Compile the current program
  • ON + number in edit menu - Set compile as a shortcut
  • ON + [/] - Toggle between the headers for Axe
  • Option to enable Axe token hooks
  • ON + [^] - Kill all hooks (this is old, I just keep forgetting to mention it)
  • Mathprint is not enabled on OS's < 2.53
  • Iodine's molar mass changed from 126.90 to 126.91 (random right?)


I can see some serious improvements in developing speed once people one shortcut to compile their program and another to run it. It will get even faster once I implement the editing archived programs. (Which I just figured out how to do (App Change Hook :D))

And yes, I see the other requests up there, I'll get to them, don't worry.


Edit:
    Nope, didn't attach it.

Edit2:
    I used Mission Copter because it was the first Axe source I could find.

869
TI Z80 / Re: zStart - an app that runs on ram clears
« on: June 01, 2011, 05:22:47 pm »
Oh, shoot, sorry. I saw the update, I just didn't see that it was added. I'll get on that right away.

870
TI Z80 / Re: zStart - an app that runs on ram clears
« on: June 01, 2011, 05:19:23 pm »
1) That's odd... for a program that I'm working on, APD seems to screw up program data. It doesn't crash, but the Axe variables are messed up. (RAM modification likely?)

Yep, APD stores the screen to SaveSScreen. Maybe someone should tell Quigibo to add in a bcall(_disableAPD) command.

Quote
2) Of course it doesn't. ;) But I think the way you display those black messages (like "Molar mass", "Confirm?", etc.) changes with setting. If you have zStart loaded, hit [On] + [-] (subtract) on 2.43 with MathPrint enabled. The message will flicker away instead of staying for a second or two. The best place to reproduce this bug is in the program menu. Assign a shortcut or startup/ram clear load program. The bug will be really apparent there.

I see exactly what you are talking about. I'll replace all of my flag checks for Mathprint with calls that will say it's not set if the current version is <2.53.

Quote
By the way, I'm a big fan of that molar mass calc! :D AP chemistry calculations feel much better with that turned on. ;)

Great! Just watch Iodine, I believe it's molar mass is .01 too high because on the old table I got them from, that's what it rounded too. So I'll have to change that. You would look a little silly if you got the molar mass of something wrong :P

Oh. That's why that area contains the flag for whether or not ON was pressed!

There's a good chance you went past the end of saveSScreen. End of saveSScreen = $89EB. System flags = $89F0.

Pages: 1 ... 56 57 [58] 59 60 ... 108