Ever wanted to grab a quick screenshot of what the homescreen looks like, but couldn't because you were too lazy to start up WabbitEmu or TI-Connect or MS Paint or whatever? Here's Homer, the Homescreen Image Maker, an online tool to make dynamic "screenshots" with homescreen text.



It uses the TI charset, which means you'll need to use [ for theta and Á for [ and so on.
An OS mod that makes a resident interrupt capable of putting screenshots into a pic var at any time would be one of the best things ever. I demand it to be made.
Sir, here's a program that installs a hook that does mostly what you want:
Quote:

I saw this post and decided to write a keyhook that puts the current LCD contents into a pic variable.
You install it by running prgmASAVEPIC and take a screenshot by holding [ON] and pressing a key from 0 to 9.
Currently it has basic functionality and is useful, but be aware of the following limitations (some of which I can fix and will probably get around to fixing):
Although you can start it, there is currently no specific way to get rid of the hook. If you have CalcSys, you can manually reset bit 0 of (iy+$34), but other than that the only way to get rid of it is a RAM reset. (Though it works fine and there's no reason to remove it Razz)
It doesn't chain the current keyhook. It can probably be successfully chained, though, so for apps that have keyhooks and do chain them, you just have to install my hook first.
It overwrites picvars in RAM, and will not take a screenshot if the picvar is in flash. These are both intended.
It will create picture variables as necessary, but will not if there is no free RAM. This is only a problem when free RAM could be gotten, i.e. when the edit buffer is open (e.g. on the home screen). I'll look into making it work when the edit buffer is open.
It saves 768 bytes. If the picvar chosen already exists, but is only 767 bytes (as viewed from the memory menu), it will overwrite 12 bytes of RAM. Make sure they are 779 bytes.
It only works within bcall(_GetKey). This is a result of using the GetCSC hook. You probably won't be able to use it in most of your favorite ASM programs.
In the ASM programs in which it does work, it carries the potential to break them if they expect OP1 to remain intact across a bcall(_GetKey)

Other than that, have fun! (The .8xp is a binary, .8xv is Mimas-format source (yay!), and .z80 is said .8xv converted)
(Note that you can use it on the homescreen or in the program editor, you just need to have a 779-byte picvar in RAM first.)

Files:
ASAVEPIC.8xp
ASAVEPIC.z80
ASAVEPIC.8xv
Can I safely assume that any assembly program that messes with interrupts would make this break? Other than that, awesome!
Any chance that we could get the source code on a different website so I could see it? It wouldn't have to be the .8xp, just the .z80.
KermMartian wrote:
Can I safely assume that any assembly program that messes with interrupts would make this break? Other than that, awesome!

It doesn't use interrupts. It uses the GetCSC hook
_player: http://pastebin.com/JZttz1H4 Note that it's converted directly from Mimas .8xv to .z80, so it will need some editing to assemble in SPASM or Brass.
Also, I'll get around to fixing things eventually. Shouldn't take too much motivation. Smile
Nice! I wouldn't do it with hooks, though - especially because I have no idea where you store the hook code in RAM (easily overwritten?). Interrupts would work great, then hooks to get it started again when any interrupt-dependent programs spoil your fun.
It's stored at smallEditRAM, which no other program uses. Apparently it's the de facto RAM hook location...
Custom interrupts also get killed too frequently to obviate the need for a hook. One update I do will probably be to have it use both.
The low-reliability of in-RAM interrupts is the primary reason for suggesting an OS modification.
While I've never actually seen a program that uses smallEditRAM, I know BuckeyeDude mentioned that he had used it before.
Wow simply wow. That is actually a neat little web app. Great work.
Indeed, that's a nice use of CSS downloadable fonts. Good job!

Does the 83/84+ character set really put the open bracket at a different code point than in ASCII? That's kind of stupid. I see no reason that TI couldn't have put theta in Á's spot instead. Hm, it doesn't seem to have a dollar sign either....
calcdude84se wrote:
KermMartian wrote:
Can I safely assume that any assembly program that messes with interrupts would make this break? Other than that, awesome!

It doesn't use interrupts. It uses the GetCSC hook
_player: http://pastebin.com/JZttz1H4 Note that it's converted directly from Mimas .8xv to .z80, so it will need some editing to assemble in SPASM or Brass.
Also, I'll get around to fixing things eventually. Shouldn't take too much motivation. Smile
Aaaand if I would have read more carefully, I would have seen that it is a GetCSC hook. Smile Thanks for clarifying that despite my failure to read.
As I said in the other thread, nice hook there calcdude84se Smile

christop wrote:
Does the 83/84+ character set really put the open bracket at a different code point than in ASCII? That's kind of stupid. I see no reason that TI couldn't have put theta in Á's spot instead.
Actually, it makes a lot of sense -- the TI-83 Plus line treats theta almost like the 27th letter of the alphabet if you think about it (programs names can start with any "letter" from A-Z or theta, for instance). Putting the theta character right after Z simplifies checking for valid program names and a host of other things.

It just gets annoying for assembly coders who need to remember to replace all their opening bracket characters with Ás Razz

christop wrote:
Hm, it doesn't seem to have a dollar sign either....
Yes there is, near the end. TI moved it from its usual place at $24 (between # and %) to $F3, where ò usually goes, to make room for a 4 character.

Now that I don't understand. TI doesn't even use the 4 character anywhere in its EOS, so why bother confuse everybody by moving $ to some obscure place?
Good work, but one thing sticks out like a sore thumb...
Quote:
Best viewed in the Google Chrome browser.

What is this, 1998?
I usually wouldn't do that, but it really does work better in Google Chrome. Chrome and Safari (since they both use Webkit rendering) are the only ones that wrap text in the textarea correctly, breaking words at every opportunity (like on the calculator, like in the output image) instead of after words if there's a chance. For example, what should display as
Code:
This is a block
of text that sho
uld wrap at ever
y opportunity!
shows up as
Code:
This is a block
of text that
should wrap at
every
opportunity!
in any other browser. (For CSS gurus, the textarea has white-space: pre and word-wrap: break-word.)
Quote:
christop wrote:
Hm, it doesn't seem to have a dollar sign either....
Yes there is, near the end. TI moved it from its usual place at $24 (between # and %) to $F3, where ò usually goes, to make room for a 4 character.

Now that I don't understand. TI doesn't even use the 4 character anywhere in its EOS, so why bother confuse everybody by moving $ to some obscure place?

Oh, I see it now. I wonder why TI also felt like they needed to have two identical up arrows (one at $06 and the other at $F3). They could have put 4 at $F3 and leave the $ at $24. EDIT: I just realized that $ is on the 4 key, so it makes a little bit of sense why they would put a superscript 4 there instead (for ease of typing that character, in case they ever used it).

benryves wrote:
Good work, but one thing sticks out like a sore thumb...
Quote:
Best viewed in the Google Chrome browser.

What is this, 1998?

No, it's 2011, and Chrome is the new (IE|Netscape) (take your pick). I can't believe I would really say something that, but it's kinda sorta true.

At least it doesn't say "at a resolution of 800x600 or higher". My phone's screen is too small for that.
Deep Thought wrote:
(For CSS gurus, the textarea has white-space: pre and word-wrap: break-word.)
Interesting, this seems to be a quirk with the textarea element specifically as it works as you would expect with other elements. I also notice that browsers won't agree on how to interpret the "rows" attribute - Presto and Trident display the textarea eight full lines (according to the font) tall, rather than scaling it down 80% to compensate for the line-height rule.

christop wrote:
No, it's 2011, and Chrome is the new (IE|Netscape) (take your pick).
Heh, that seems a fair assessment. Razz
benryves wrote:
Deep Thought wrote:
(For CSS gurus, the textarea has white-space: pre and word-wrap: break-word.)
Interesting, this seems to be a quirk with the textarea element specifically as it works as you would expect with other elements. I also notice that browsers won't agree on how to interpret the "rows" attribute - Presto and Trident display the textarea eight full lines (according to the font) tall, rather than scaling it down 80% to compensate for the line-height rule.
Noticed that too. How do you test all those layout engines?
benryves wrote:
Good work, but one thing sticks out like a sore thumb...
Quote:
Best viewed in the Google Chrome browser.

What is this, 1998?
Why bother putting in effort to build cross-browser support when you could just force people to use a single browser? Wink
Safari: Perfect
Chrome: Perfect, except for a tiny quirk when selecting text
Firefox: Perfect, except for a minor issue with text wrapping
Opera: Perfect, except for an oversized textarea
IFE9: Perfect, except for a minor issue with text wrapping, not allowing :hover graphics on input elements, and an oversized textarea
IFE5.5,6,7,8: Corners not rounded

Haven't tested any other browsers, but everything (including the javascript charmap) is completely functional in everything I've tried, even in quirks mode. I just threw that message in there so people wouldn't complain about text wrapping after words in the textarea but not in the pic.

EDIT: Redesigned the whole thing because ephan suggested not forcing users to scroll around. It now also accepts subscript numbers (like the 1 in L1) in the form %81.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement