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 - DrDnar
Pages: 1 ... 4 5 [6] 7 8 ... 38
76
« on: July 09, 2013, 06:32:35 pm »
That also applies to upside-down mode and mirror mode. Heh.
77
« on: July 05, 2013, 03:55:11 am »
This is an excellent demonstration of how thoughtful optimization can give superior performance. (I wonder how the heck TI made their b&w-looking OS go so slow on scrolling menus then.... ?)
Wow, how did you make it run so fast?
I thought scrolling the whole screen (or almost the whole screen) Would be waaaaaay slower due to the slow LCD?
The OS visits every pixel when it scrolls text. He's optimized his program so that it only updates the pixels that actually change each loop iteration. Addendum: I don't mean to overstate the usefulness of this technique. It can only provide an optimization when applied to groups of pixels, not individual pixels. If the squares had sprites instead of solid colors, it would not be able to run so fast. Can you hardware vertical scroll?
No, there is no support for vertical scrolling. The LCD is actually rotated 90 degrees from its intended orientation, so its vertical scrolling feature actually produces horizontal scrolling. (To reduce confusion, the documentation of WikiTI is written to reflect the LCD's actual orientation; thus, the Wiki and the datasheet differ on the meaning of "horizontal" and "vertical".)
78
« on: July 05, 2013, 01:40:57 am »
The problem is that I still don't understand Flash protocol and USB protocol. I am not sure, though, but I think SirCmpwn released a template for an operating system, so I could probably use that.
Raw flash commands are documented on the Wiki. BrandonW is the only documentation for USB.
79
« on: June 27, 2013, 03:02:59 pm »
Clearly, nobody has used this very much or they would have noticed that the last update breaks font loading. (The bug is actually in font saving. If you do happen to have saved a font using the broken version, you can fix it with a hex editor by changing offset 0x31 (49 in decimal) from 04 to 01.)
This update also adds support for the TI-84+CSE's 160x240 mode. ("Double Width" in font properties.)
80
« on: June 26, 2013, 04:47:34 am »
It would be possible, but I'm not going to do so. I will, however, post these two files. You can use them as templates, if you really want. The first is a 5x7 font, and the other is the MicrOS CSE 9x14 font.
81
« on: June 26, 2013, 04:08:01 am »
You asked for a readme, so I've embedded one within the application. Hopefully, it also clarifies the difference between Width and Data Width. Edit: After four downloads, I noticed a serious bug. See this new post for the fix.
82
« on: June 25, 2013, 09:01:51 pm »
I forgot to upload screen shots. Also, here are the basic features: - Edits monochrome fonts up to 64x64 pixels
- Each font has exactly 256 glyphs
- Sports a chart giving an overview of all glyphs
- Has a text previewer which lets you test how the font will appear with any text
- Text previewer uses Unicode
- Each character has an associated Unicode codepoint. The text previewer uses this to select the glyph to display for each character entered. Each font is coded using ASCII by default.
- You can assign any Unicode codepoint to any glyph. Thus, you can make glyph #0 'Q' if you want. And the text previewer will figure that out automatically.
83
« on: June 25, 2013, 08:16:04 pm »
For years I've been generating my own fonts for various projects using a font editor I made as one of my first desktop applications. Recently I decided to rewrite it from scratch, cleaning up its code significantly. This new version lets you generate fonts for zStart and Omnicalc. It can also generate .asm files matching the font format used by MicrOS for the TI-84+CSE, and I threw in three custom formats Zeda uses. It's easy to add new formats, and I'd like to add .FON support sometime. However, because this program is also the final project for a class assignment, the source will not be available until later this summer. Due to .NET reflection abuse, this requires .NET 4.5 or above and therefore Windows Vista or above. EDIT: After 13 downloads, I've created an updated version; see post below.
84
« on: June 24, 2013, 04:43:13 pm »
As to the better sprites, you are right, however, you'd be doubling to tripling the size of my sprite data, which is already massive. I'm sitting at 261KB just in sprite data for those 44 presidents. I'm looking at roughly that much or a hair bit more for the information for all of them.
If I had time, I'd love to offer my services for compression. A lossy image compression algorithm could compress all those images with good quality 32-level gray-scale to less than 64 K, at the expense of decoding speed. Sadly, I probably don't have time to learn, implement, and optimize a DCT + Huffman algorithm, but hopefully somebody else does.
85
« on: June 24, 2013, 04:28:43 pm »
SxS is a Windows feature that allows multiple versions of the same software to be installed without interfering with each other, thereby allowing applications that expect incompatible versions of a library to be installed to co-exist peacefully. It's largely automatically, and works quite well for most applications. Unfortunately, Windows doesn't really provide an end-user GUI for configuring SxS, instead relying on built-in logic and programmer thoughtfulness to make it function. Consequently, if it does make a mistake, cleaning up is not easy.
86
« on: June 24, 2013, 04:22:39 pm »
My two comments are first, that a more advanced assembly library would provide better pictures, although they wouldn't be saved to the graph buffer properly; and, second, that you should consider using two spaces in a row everywhere for better readability. (The 2001 app SDK makes the same recommendation.)
87
« on: June 20, 2013, 03:59:08 pm »
Generally, people who are knowledgeable about this sort of thing won't answer questions unless you've clearly already tried to research it yourself.
Furthermore, WPA and WPA2 are much more difficult to crack than WEP. WPA and WPA2 both have strong authentication which currently can only effectively be attacked via a brute force search of known common passwords. A long password of random ASCII is effectively impossible to crack. (The difference is that WPA has flawed encryption, which ironically allows people to decrypt transmissions yet be unable to connect to the network.)
88
« on: June 19, 2013, 05:06:11 am »
Well, it seems that 3rd party app development is off to a better start than TI's app development! We already have two released apps (BrandonW's Linky beta and my MicrOS), and now a third in development. I suspect that performance issues will push even more BASIC coders to adopt assembly augmentation.
Also, I'd like to suggest possibly using the ExecLib command as your hook for BASIC functions, for it might be faster. Based on what I'm seeing in the USB8X source, you specify using ExecLib by putting the byte sequence 96 E2 00 01 at 40A0 in your app. Then, put a short pointer to a header continuation, which then contains the bytes 01 00 02 00 followed by a pointer to your ExecLib handler. These two extra headers can be sequential. Why TI didn't just make this part of a new app header field I can't image, but maybe BrandonW can.
89
« on: May 30, 2013, 08:36:49 pm »
I posted a WikiTI page about making applications for the TI-84+CSE. Maybe you can turn this into a full library with API?
90
« on: May 25, 2013, 05:06:16 pm »
I'd just create two look-up tables: one for 0<n<1 and another for 1<n<255. Then, branch depending on the MSB of n. Actually, if you compute a reciprocal, you only need one table. Basically, your input really only has 8 significant bits; surely that can be used for an optimization. Your output domain is -5.6<n<5.6.
Edit: Use change-of-base rule: It's trivial to compute n-log-base-2, so just compute that then divide by the hardcoded log-base-2 of e value.
Pages: 1 ... 4 5 [6] 7 8 ... 38
|
Show Posts
