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 ... 28 29 [30] 31 32 ... 108
436
« on: December 19, 2011, 03:28:09 pm »
(I was gone) Oh, thepenguin, earlier today I had a random-ish RAM Clear when trying to edit a program in archive after triggering a regular RAM Clear and then trying to edit an archived program (by pressing a number, if that matters). I ran zStart after the second RAM clear, toggled zStart Off, then On again, and then tried editing the same program. That worked just fine.
Not to burst your bubble (bug-ble?) or anything...
So, to clarify. You cleared ram, then when you went to edit a program, it crashed again? If that's true, then...
Yup. The first RAM Clear was from 2nd / Mem / Clear RAM, while the second one was not voluntary. Let me try to reproduce it right now.
Edit: I can reproduce it on my calc by doing the exact same thing as before.
Edit 2: It looks like all I have to do to fix it is run zStart - I don't even have to toggle it on/off like I did earlier.
If you can get me a savestate that crashes, I can fix the glitch in 5 minutes. I had a quick question about editing programs in archive. I assume that what it does is make a copy in RAM and then copy it back if changes were made. But what happens if there's not enough room in RAM to hold the copy? Are other programs temporarily archived to make space or will it not let you edit the program?
You mentioned you had an entry point in zStart so Axe errors could be shown in archived programs, but the routine sounds like it could be small enough to just include it in the app since I still have a lot of space. But I don't know how you're implementing it so maybe I'm wrong or there are other advantages to calling it through zStart that I'm forgetting.
If it's oversized, I believe it will Err:Memory since I just use bcall(_createProg). The code is rather large, but you can probably duplicate some of it with your own code. In any case, here's everything you need to make it work:
;############################
editProgram:
ld hl, 0
ld (errOffset), hl
editProgramCustomOffset:
bcall(_chkFindSym)
ret c
ld a, b
or a
jr nz, itIsArchived
ld hl, op1
call getLastLetter
bit 7, (hl)
jr z, doTheEdit
jr setTheHook ;idiot
itIsArchived:
call findStartInRom
bcall(_loadDEIndPaged)
inc hl
call fast_bhl
push hl
ld a, e
or d
ld a, b
push af
push de
ld a, 3
out ($20), a
ld hl, op1
call getLastLetter
set 7, (hl)
call pushOp1
bcall(_chkFindSym)
jr c, notThisFoundz
bcall(_delVarArc)
notThisFoundz:
call popOp1
pop hl
push hl
call pushOp1
bcall(_createProg)
call popOp1
inc de
inc de
pop bc
pop af
pop hl
jr z, zeroSizes
bcall(_flashToRam)
zeroSizes:
setTheHook:
ld hl, appChangeHook
in a, (06)
bcall(_enableAppChangeHook)
doTheEdit:
ld hl, op1
ld de, varType
push hl
bcall(_mov9B)
ld a, 3
ld (menuCurrent), a
ld a, 1
ld ($85DF), a
ld a, kEnter
bcall(_pullDownChk)
bcall(_clrTR)
pop hl
ld de, progToEdit-1
bcall(_mov9B)
push af
ld a, kError
ld (cxCurApp), a
pop af
bcall(_newContext0)
bcall(_mon)
;###########################################
appChangeHook:
add a, e
cp kPrgmEd ;these are all part of editing
ret z
cp kMode
ret z
cp kTblSet
ret z
cp kFormat
ret z
finishEditing:
push af
push bc
push hl
ld a, b
cp $46
jr nz, killAppChangeHook ;this is in case a weird switch happens
ld hl, varType
call getLastLetter
bit 7, (hl)
jr z, killAppChangeHook
ld a, 3
out ($20), a
bcall(_runIndicOn)
ld hl, varType
rst 20h
call pushOP1
ld hl, op1
call getLastLetter
res 7, (hl)
bcall(_chkFindSym)
jr c, cantFindProga ;these things never seem possible until it crashes
bcall(_delVarArc)
cantFindProga:
call popOp1
ld hl, op1
call getLastLetter
ld de, -op1-1+7
add hl, de
push hl
bcall(_chkFindSym) ;if this is gone, we let it crash
pop de
or a
sbc hl, de
res 7, (hl)
ld hl, op1
call getLastLetter
res 7, (hl)
call pushOp1
bcall(_chkFindSym)
bcall(_arc_unarc)
call popOp1 ;this is for ON + STO
killAppChangeHook:
bcall(_disableAppChangeHook)
pop hl
pop bc
pop af
ret
;#######################################
;input: hl = start of op1, or similar
getLastLetter:
push af
push bc
ld bc, 10
xor a
cpir
dec hl
dec hl
pop bc
pop af
ret
;#########################################
pushOP1:
push af
push bc
push de
push hl
ld hl, -12
add hl, sp
ld sp, hl
ex de, hl
ld hl, 12
add hl, sp
ld bc, 10
ldir
ld hl, op1
ld bc, 12
ldir
pop hl
pop de
pop bc
pop af
ret
;##########################################
popOP1:
push af
push bc
push de
push hl
ld hl, 10
add hl, sp
ld de, op1
ld bc, 12
ldir
ld hl, 10+12-1
add hl, sp
ex de, hl
ld hl, 10-1
add hl, sp
ld bc, 10
lddr
inc de
ex de, hl
ld sp, hl
pop hl
pop de
pop bc
pop af
ret
;##################################
;Move to start of data in Rom
;Input: Output of _ChkFindSym
;Output: HL = start
; B = rom page
;Destroys: C DE
FindStartInRom:
ex de, hl
LD de, 9
add hl, de
call fast_bhl
bcall(_LoadCIndPaged)
inc c
ld e, c
add hl, de
call fast_bhl
ret
;########################################
;faster bhl
;only checks for going over
fast_bhl:
ld a, h
res 7, h
set 6, h
cp h
ret z
inc b
ret
Iirc I've gotten an ERR:MEMORY trying to edit an archived program from home (well, I run it from the homescreen and take advantage of the ERR:SYNTAX  ). Hasn't happened lately tho, either because I keep a lot of ram free or it's been fixed somehow.
If nothing else, I read your post 
437
« on: December 19, 2011, 03:17:28 pm »
thepenguin, a great job. However, one issue of convenience.
I lose the game (or win). I then get the cursor, but am unable to move. The game should automatically quit and return you to the main menu. At current, you need to exit manually, then it asks you if you are sure you want to exit a game that is already over.
(I was gone) I did this on purpose. In fact, you can even save the game at this point. The reason I did it this way is so you can show people the final situation. This especially applies in a two player game because when checkmate occurs, most likely the other person will be like "WTF?!" and they would want to study the board. The winner might also go run around the room with the calculator
438
« on: December 13, 2011, 06:42:13 pm »
So I got chess off of ticalc it was version 1.1. I have an 83+BE, but my friend wanted it. So I tried to run it on my calculator, just for the heck of it, using mirage. It told me a BE wouldn't cut it and then exited out of the program and then mirage wouldn't load program names. Trying to run chess again while in this state causes a ram clear. And trying to exit mirage causes the calc to start displaying the ti os memory screen at 0 ram over the program less mirage image and then freezes there. I had to pull a battery.
Well, I fixed it This is the same problem that caused version 1.1. Oh well, maybe this way it will scare people.
439
« on: December 12, 2011, 10:16:42 pm »
Edit: Feature Request:
Can you add a screen somewhere that says what is in all of the On + number hooks? I sometimes am hesitant to use them because I don't want to accidentally think that I'm pushing the wrong thing. If zStart's out of space you could even make it a standalone program; I'd just find it quite useful. Thanks!
Yeah, like I said, eventually I'll get that out, it's really not that much trouble. Oh, thepenguin, earlier today I had a random-ish RAM Clear when trying to edit a program in archive after triggering a regular RAM Clear and then trying to edit an archived program (by pressing a number, if that matters). I ran zStart after the second RAM clear, toggled zStart Off, then On again, and then tried editing the same program. That worked just fine.
Not to burst your bubble (bug-ble?) or anything...
So, to clarify. You cleared ram, then when you went to edit a program, it crashed again? If that's true, then...
440
« on: December 08, 2011, 07:40:32 pm »
Edit2: Dang, I need to read closer. Oh well, at least mine is way bigger than jacobly's. These things actually aren't that difficult to write if you understand the principle by which they work.
multBCDbyEHL:
ld a, b
ld b, c
ld c, d
ld d, a
multDBCbyEHL:
push de
push hl
ld ix, $8000
ld (ix), l
xor a
ld h, a
ld l, a
call do8Bits
ld (ix+1), a
pop af
ld (ix), a
push de
ld a, (ix+1)
call do8Bits
ld (ix+1), a
pop af ;least sig number
ex de, hl
ex (sp), hl ;D and 2nd least sig in for new number
ld (ix), l
pop hl ;D and 2nd least sig
push af ;least sig number
push hl ;2nd least sig number
ex de, hl
ld a, (ix+1)
call do8Bits
ld b, a
ld c, h
ld d, l
pop hl
ld a, l
pop hl
ld h, a
ret
;####
;input: DBC = 1 number
; AHL = running number
; (ix) = to multiply by
;output: AHLE = output
; E is done
; DBC = 1 number
do8Bits:
ld (ix+1), 8
loop:
srl (ix)
jr nc, skip
add hl, bc
adc a, d
skip:
rra
rr h
rr l
rr e
dec (ix+1)
jr nz, loop
ret
I had to use 2 bytes of memory, so sorry about that. If you don't like it, you could just replace (ix) with ixl and (ix+1) with ixh and it would be ram independent, but then it wouldn't run on the Nspire. Also, to my extreme delight, this thing worked on the first try (The result is in BCDEHL) Edit: Added to wikiti so people will forever be able to multiply large numbers.
441
« on: December 06, 2011, 11:17:35 pm »
Yeah, that's a trick we use a lot in calculus. It really comes in handy when you are graphing 2nd derivatives. I didn't have you do that, but that's the only time I usually change Xres to 2. The only downside is that it doesn't check for discontinuity.
Also, if you have skills, you can change Xres to > 8 with calcsys. Setting it to 31 is entertaining for instance.
442
« on: December 06, 2011, 10:49:47 pm »
I've got a feeling that I would have to either rewrite the code for graphing or patch the OS on that one. Though, I'm not sure since I've never looked into it. To be honest, I don't think updating the screen slows it down that much.
For instance, graph this:
nDeriv(.1x^3,x,x
Then flip Xres on 2 and graph it again.
That's about the best you can do for fast graphing.
443
« on: December 06, 2011, 10:36:25 pm »
It's not really that simple. The problem with mathprint is that the OS uses what's called an edit buffer at the homescreen. The way this works in classic mode is relatively well understood and can be replicated by us. The way it works in mathprint is entirely foreign and has not even been slightly looked at. (Part of the reason is because TI just hacked it together) In order to perform an operation from a keyhook, I usually have to close the edit buffer. Then, when the hook is done, I reopen the edit buffer and let the calculator get back to what it was doing. However, for mathprint, like I said, we don't know how to properly reopen the edit buffer. My fix for this was to jump back to the homescreen which will open the edit buffer correctly. If I don't reopen it, bad things happen But, I never thought about the shortcuts, maybe I can hack something in to make those work.
444
« on: December 06, 2011, 10:29:27 pm »
Also, if you are a normal person, your first attempt at learning assembly probably won't go well. Most likely in 28 days, you'll look at day 3 and freak, but you'll think you understand it so after you read it, you'll move on. Then when you start getting up around day 6, you'll realize you have no idea what you're doing and you'll take a break. But, when you come back from this break, that is when you will finally succeed and begin to write assembly programs. (I don't think there are many outliers to this formula either, unless they just give up  For some reason that's just how assembly goes. Probably because it is an entirely different mode of thinking.)
445
« on: December 05, 2011, 04:35:57 pm »
If you have all 5 batteries out at the same time you will get a ram clear.
My suggestion would be to archive everything, take the calculator apart, and go from there. Once you get it apart, there's a chance you will see pretty quickly what is wrong, and in that case you can decide what to do.
If you don't know what's wrong, the best way to figure it out would be to plug something into your link port and strip the wire. Then use some kind of circuit tester (multimeter or a battery, some wires, and a light) to figure out where the break is. After you figure that out, then you'll know what to do.
So, I'd try to figure out what's wrong before you buy a new one. But if you do buy a new one, you should get an 84+ and save yourself some disappointment when programs don't work.
446
« on: December 04, 2011, 09:54:31 pm »
That's a new one. But thanks, I didn't look through the whole thing, I only changed the list of shortcuts and the changelog.
447
« on: December 04, 2011, 04:00:23 pm »
In any case, 8090h in zStart will edit OP1.
Set (errOffset) to the correct offset (or 0), check to make sure 8090h is $C3 in zStart, then jump there. Simple as that.
448
« on: December 04, 2011, 02:47:50 pm »
Here's the new readme.
449
« on: December 04, 2011, 01:43:16 pm »
Nice! Cant try this until later, but i will.
A bug from the last version (maybe?) is that when im on the prog exec menu, any on command that i do exits the menu. I.E.: ON + - to archive a prog, and all of the ON +
- shortcuts. Plus, on prog edit menu, ON + [Enter] still crashes.
Sorry about that, those both still exist. The first one is going to stay that way because mathprint sucks. The second one I'll fix because it shouldn't crash.
450
« on: December 04, 2011, 02:03:39 am »
Update- ON + [Apps] - run MirageOS
- ON + [Prgm] - run DoorsCS(9-5) (higher versions have higher priority)
- ON + [Sto] in program editor - compile the current program with axe
- ON + [ +] - copy (was [Prgm])
- Max copy size now 2900 bytes
- You can now edit archived programs by pressing their number
- 2nd + Format and 2nd + TblSet no longer screw up the program editor
- ONSCRPT works again
- 408Ah - Install all hooks
- 408Dh - RunOp1 (more details on these three later)
- 4090h - EditOp1
There's the update, I forgot about 2nd + Quitting from a basic program, but I'll take care of that later. Most of these updates are thanks to DrDnar allowing me to free up 79 bytes, so be sure to thank him.
Pages: 1 ... 28 29 [30] 31 32 ... 108
|
Show Posts