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 ... 39 40 [41] 42 43 ... 108
601
« on: September 12, 2011, 05:29:08 pm »
That should be possible. Here's how the groups are stored: {standard flash header}
bytes descriptions
1 [Valid flag == FC]
2 [size of entire flash variable]
{standard program header}
1 [group == 17h]
5 [garbage (for you)]
1 [size of program name]
1-8 [program name]
2 [size of group data]
And now the fun part. You have a whole bunch of programs right after each other: {standard program header}
1 [type, 5 = prog, 6 = prot prog, = 15h = appvar]
5 [garbage again]
1 [size of program name]
1-8 [program name]
2 [program size]
0-big [program data]
So, what you'd do is make your way though the group header, figure out what type the first program is, make a program of that type in ram, then copy the data into it. Just repeat that until you reach the end of the group. That simple 
602
« on: September 12, 2011, 05:12:55 pm »
Ungrouping stuff is really easy. The group is just a whole bunch of programs stored back to back.
However, creating a group is messy. You have to make a group in ram then call bcall(_archiveVar), which is the only bcall out of them all that can corrupt your flash. And most likely, you'll corrupt your archive several times during development.
So I say, it's possible, but you should definitely do it in assembly instead.
603
« on: September 11, 2011, 06:00:32 pm »
Just a random note from personal experience. If you want your flash drives to continue to work, don't touch the pins on the micro processor (this includes with another object.) The reason I say this is because your own personal static might short out the processor.
(As stupid and unrealistic as that sounds, I've done it when I was counting the pins.)
604
« on: September 10, 2011, 03:14:29 pm »
EDIT: You were the one who told me that O.o
 Ok, so StatVars is free to destroy, however, what you leave there can have negative effects. The only one I've ever found was leaving a 01 at $8A4A. I think writing 00's to the whole thing should be safe though.
605
« on: September 10, 2011, 12:45:48 pm »
if something potentially went wrong when I put 2.43 back on, which seems to be the case here. (Might be from me being on a Win7 computer but I don't know if those issues got fixed.) Anyways, thank you guys so much for answering and helping 
Again, that's definitely not possible. If there was an error in transmission, the OS signature wouldn't match and the calculator would have rejected it. First of all, one important thing to note is that 2.53 and higher will always display Done, Error, or whatever. Due to the way that the entries menu works, any operation has to return a result. So even if you try your hardest not to display Done on one of those OS's, it's still going to be there. Here's my list of things that could be causing this: - Your program is returning a result in Ans
- When your program quits, the last operation to the homescreen was an output
- Your program is quitting with the graphscreen displayed
- The program is being run in a strange way which is causing the specific flag to be reset
606
« on: September 10, 2011, 12:34:36 pm »
I think using Copy() from an archived file would also destroy stuff in that area, because that uses bcall(_FlashToRam). Also, isn't the base page table only required if you're running a multi-page app with the custom bcall system?
Yeah, really, anything related flash will destroy $8100. If you destroy the base page table, most likely, you'll never notice. The only time it matters is when you run something before the base page table is built, for instance: a hook to a multipage application (CtlgHelp). So to be safe, just call the bcall. Remember that if you want it to be compatible with MirageOS, don't use statVars at all.
That's only if you want it to be compatible with the MirageOS interrupt system. Do an IM 1 and you can trash statVars.
607
« on: September 09, 2011, 10:32:51 pm »
Runer and I talked about using statVars as a fourth buffer. It looks like it should be clear to use. Starting at statVars, you have about 830 bytes to work with that really shouldn't cause any problems unless you do stat operations or graph something. To see the complete list of what you are destroying head over here and look at everything between 8A3Ah and 8D3A. Edit: $8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.
608
« on: September 09, 2011, 03:50:52 pm »
Lucky for you, that routine has already been made. With just a little tweaking you can have it do exactly what you want.
609
« on: September 09, 2011, 03:47:41 pm »
Just to clarify, it's not the boot code . Boot code 1.03 is identical to 1.02 in everything but a few security measures.
610
« on: September 08, 2011, 05:36:18 pm »
Problem fixed, Nyan Cat for 84+BE and Nyan Cat for 84+SE. I still have that stupid NyanMem thing, but now it's way simpler to use. Best of all, it only erases pages 08 and 0C, which means a mem clear will put it back to normal. And while I'm at it, here's the fixed TruVid setup.
611
« on: September 08, 2011, 03:18:44 pm »
After some more testing, it seems like the amount of free memory decreased by about 2 KB every time NyanCat is run and then exited by pressing CLEAR. For example, starting at 14 KB free RAM and running NyanCat three times makes the amount of free RAM be 8 KB.
Oh, dang, that's such a silly mistake by me. I actually run the TruVid thing as a program, even though it's an app. I just forgot to delete the program when I was done I'll see about making a full set of NyanCat's with proper instructions on how to use them and fixing the main program. lol? I will not use this program until all bugs are fixed...
I don't want to kill my TI again...
Nothing against your TruVid, but I'm now more careful with my stuff...
Thanks. Also, it's impossible to actually damage your calculator unless you intentionally try to do so.
612
« on: September 07, 2011, 03:59:35 pm »
I've also noticed that if I recall a string into a program, and open the label menu and jump to another label and try to scroll to another part of the program, the cursor moves off-screen and my calculator ensuingly crashes.
Probably related to the previous problem. Something strange must happen to the edit buffer. Feature Request:
A catche of older versions of the program you're currently editing in the archive. This would be cleared every time you GarbageCollect, but it'd still be nice in case you completely screw up the program you're editing and would like to go back to a previous version of it.
That's not that hard to do, though, it will have to wait for me to go multi page. Ooooh, i'd like that. I've done that loads of times. Could there be an option to have them stored as appvars?
I don't think you quite understood exactly why zTrumpet's was possible. Every time you unarchive something, it isn't actually deleted from flash, the deleted program just sits there. zTrumpet wants a program that shows you all of those deleted programs. What you are asking would quickly fill up your archive with appvars and not only would you garbage collect twice as fast as usual, after each garbage collect, you'd only have 1/2 the memory you had the previous time. This would continue until you are out of space, then you'd have to do some major deleting.
613
« on: September 06, 2011, 07:34:46 pm »
In the program edit list, if you press a number key to edit an archived program, it gives err:archived. You have to select with enter to edit archived programs. Don't know if this is a bug or not.
I know about that, it's fixable, I just might not have the space. The reason why it doesn't work though is absolutely not a glitch, it's just a feature not supported that you would assume is I'm still having troubles with the label menu...only things installed are Axe, omnicalc thru zStart, and zStart itself.
Running archived source program from homescreen then opening up the label menu starts it, then when you go to scroll around it does fun stuff 
(noting that opening it from the edit menu does not glitch)
Hmm... This is probably an indirect glitch caused by not opening the program editor properly. I'm not exactly sure what causes it yet, but I'll try to figure it out.
614
« on: September 03, 2011, 09:15:27 pm »
(I tried disassembling zStart 1.1 and it did it in less than a second) I may have originally missed this post but  Sometimes I even code differently based on how a disassembler would see my code. But that's just a weird thing I do.
615
« on: September 02, 2011, 11:12:14 am »
Here's what I came up with, you'll have to number your colors a little funky, but that's expected when you do 7 colors in 3 bits. 010101 dark
100010 med
001000 light
6/6 111
5/6 110
4/6 101
3/6 100 ;|discrepancy
2/6 010 ;|
1/6 001
0/6 000
Then you'd just have to rotate it properly, but I'm sure you already know that
Pages: 1 ... 39 40 [41] 42 43 ... 108
|
Show Posts