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 - Sue Doenim
1
« on: January 15, 2021, 12:17:00 am »
 Holy cow, that's awesome! That flag is perfect, and that temporary hook thing is crazy! That's definitely the best way to go. I'll for sure use that. I won't be able to use the flag on pre-MathPrint OSes/calculators, but those weren't ever an issue, so I'll just be able to fall back to the older checks. Once again, thanks so much for helping me along with the program! This is the first programming project that I've taken the time to fully work through and publish online, and it's so cool for me to experience the open-source ideology first-hand with you helping me out.
2
« on: January 14, 2021, 01:46:20 pm »
Great news, i managed to adapt my code.
Note that it's designed to work for a homescreen hook with a=2, i haven't fully tested it with the other contexts.
Also, though it works as expected (everything properly displayed after a _clrlcdfull), it might not solve your problem, cause i believe it's not a display issue, more like the fact that the Ans you add should also be added to the list of mp home entries on RAM page 3.
Anyway, that will be a good way to tell if i'm right about that.
Looks like you're right. I totally forgot to mention that there was crashing that I couldn't explain with my new version. I assumed that it was because of some mistake I made, but it looks like it was from issues with the entry buffer/RAM page/MathPrint. Using the code that you wrote doesn't change the behavior, as far as I can tell. Ans still doesn't show up, and it still crashes after a few entries. It helps a ton to know that it's an issue with the buffer. That explains why bcall _BufReplace only writes Ans to the screen when MathPrint is on. After seeing what a nightmare retroactively dealing with the entry buffer would be, I think it would be easier to go back to listening for enter and just find a way to check if it's going back through entries.
3
« on: January 14, 2021, 12:53:05 am »
I ran across a pretty significant bug where Caboose is still active when using the up arrow to go through previous entries, so an extra Ans sometimes gets inserted when you press enter to recall one. To fix this, I tried switching to using the homescreen hook condition where A = 2 (waiting for an expression to be entered) instead of listening for the enter key. My plan was to go in and add Ans to the end of prgm# before it gets evaluated, but the problem is that Ans is never written to the screen. Is there any kind of "update homescreen" bcall that I can use to make sure it does get displayed? I don't think dealing with it manually using PutS is viable, since MathPrint potentially screws it all up. Are there any other ways around it? Would reopening the edit buffer then adding Ans work? Or should I go back to the older way of listening for enter and find some way to tell whether something is being recalled from previous entries?
4
« on: January 10, 2021, 01:36:33 pm »
You're welcome.
Switching to max CPU speed could be significant, at the very beginning of the app & hook codes.
Don't forget to backup af before that if needed, of course :
in a,(2)
rlca
and 1
out (32),a
Disabling interrupts is also a thing, and i would even recommend it after each bcall aswell.
Cheers.
There are for sure a lot of optimizations (especially hackish ones) I could make. Probably the easiest thing to do for a pretty good speedup would be to check the tokens in order of most common to least common, instead of just from lowest to highest value. Since it's a flash app, size isn't much of a concern, so if I really wanted to, I could replace `CPIR` with an unholy chain of `CP XX \ JR Z, appendAns`. I couldn't tell that there was any noticable lag as it is though, so I decided to prioritize readability over raw speed. I might decide to change that. I think the more pressing issue is the lack of any sort of UI, so I think I'll tackle that first.
5
« on: January 04, 2021, 10:51:58 pm »
Useful indeed =]
I might have a fix for you, tVarStrng ($AA) appears to be missing from the list of word tokens.
Cheers.
Awesome, thanks! And nice catch! It's fixed now.
6
« on: January 04, 2021, 11:10:09 am »
Here's an app that I made that sets a hook to check every entry and to add "Ans" whenever it makes sense, such as when it ends in "-", "sin(", or an empty entry box. It's a pretty simple program, but it's a pretty solid time saver. https://github.com/joeldemars/cabooseEDIT: Changed link to reflect updated username.
7
« on: October 18, 2019, 11:08:21 am »
Doesn't RST $00 trigger a reset?
8
« on: July 29, 2019, 01:04:25 am »
The LCD delay is long, and sometimes there's nothing to do while it's delaying, so you have to use a routine that waits until the LCD is ready. In LCD-heavy programs, like a grayscale game, tons of time is wasted in such routines. The most common routine that I learned from @thepenguin77 is: label: ;T-states
IN A,($10) ;11
AND %10010000 ;7
JR NZ,label ;7/12
;6 bytes, destroys A
This routine is okay, but it might be improvable. If you can use only bit 7 instead of both bit 7 and 4 (which is what I'm not sure about), these would work: label:
IN A,($10) ;11
RLA ;4
JR C,label ;7/12
;5 bytes, destroys A
That one is a bit better, but if you want to optimize for speed: LD C,$10 ;7
label:
IN (C),A ;12
JP M,label ;10
;7 bytes, destroys A/C
;If C is already equal to $10, you can skip the
;load instruction and save 2 bytes/7 T-states.
;If you are okay with using undocumented
;instructions, IN (C) would preserve A
These look like they're really helpful routines to help save a bit of space and to save a few T-states, which will really add up when you're writing to the screen 768+ times in a row. The second one in particular might work really well with a grayscale program. If you move around some instructions, then you only need to load $10 into C once, and then you can go through your whole screen-writing routine without having to do so for every delay.
9
« on: April 28, 2019, 01:46:20 pm »
I was planning on using a finance variable to hold the value, since unlike statistic variables, they are borderline useless. The problem I was running into was that the TIOS doesn't seem to allow writing to variables from a hook. Whenever I copy a float into the RAM area from a hook, the OS sets the variable to 0, and when I use OS routines (stoSysTok), all kinds of junk happens. I can write to the variables from a normal program, but not from the hook. Is there any way to bypass this?
10
« on: April 22, 2019, 09:31:44 pm »
You wouldn't be able to modify the function of the tau token using the other modes of the parser hook, would you? That seems like it would be a cleaner, if more difficult solution.
11
« on: April 20, 2019, 11:23:59 pm »
I got the Raw Key Hook to work, so now pi keypresses put a tau token. I'm not sure about the Parser hook. I think I understand it pretty well. Replacing all of the tau tokens with 2pi wouldn't always work, though, would it? If you have 3tau, wouldn't that become 32pi?
12
« on: April 19, 2019, 11:53:00 am »
I don't think I'll keep trying to make that program. I like the idea, but there are just some logistical issues. Things like "sin(arcsin(" would get messed up a bunch, and I don't see a nice way to fix that problem. I decided to work on another similar but probably simpler thing. My friend is a tau enthusiast, and he would like the pi keypress to be replaced with a functional tau keypress. (In case you don't know, τ=2π.) I was thinking I would set a raw key hook, and whenever pi is pressed, I would add tau to prgm!. Then I'd install a homescreen hook to allow the tau token to signify its value. What I'm not sure about is what prgm# is. Wikiti says "To retreive the expression to be evaluated use prgm#," but does that mean I edit prgm# to change the answer? Does prgm# hold a copy of prgm!, or what? My plan was to insert "(6.28[etc.])" Where ever a tau was.
13
« on: April 04, 2019, 10:35:47 pm »
What do you mean by the edit buffer? Edit buffers can be fairly complicated to work with. I don't mean the text shadow, but the place the tokens that you type in are stored. I want to work with hooks to change things. My current plan is to make an app that supports double-clicking of certain keys to access the [2nd] function of that key (e.g. double clicking [^] puts the pi token).
14
« on: April 04, 2019, 09:09:31 pm »
Where is the edit buffer for the homescreen stored? What general guidelines should I follow when editing it?
15
« on: March 25, 2019, 11:26:00 pm »
Actually, jp points to a fixed location whereas jr is relative. So in this case, jr $F1 (18F1) just states that it will jump back 15 bytes from the end of the instruction.
Yeah, I meant the opcode itself, not the address it jumps to. In hindsight, that wasn't the best way to put it, but my point about writing in hex still stands.
|
Show Posts