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 ... 13 14 [15] 16 17 ... 38
211
« on: November 28, 2012, 11:01:59 pm »
Well, as I said yesterday, it didn't make my calculator explode.
Also, is the slowness on the sphere and dark-link models just the performance limit of the calculator?
212
« on: November 25, 2012, 08:43:25 pm »
I must admit, that screen doesn't look half-bad. Clean, simple. I just worry that the UI will be awfully slow. I really do hope that TI doesn't actually half-ass this, but I have my doubts. They'll really need to increase the CPU clock speed and add RAM if it's not going to be slow and awkward to program.
213
« on: November 25, 2012, 08:19:54 pm »
TI-89 BASIC is pretty powerful compared to Z80 BASIC. It has much better support for structured programming, and supports comments and whitespace. It's a shame it's so slow. I thought http://tibasicdev.wikidot.com/home had reasonably good documentation. You (all programmers) should really enjoy the ability to use subroutines, local variables, and functions.
214
« on: November 21, 2012, 06:22:25 pm »
It's not particularly impressive, but pretty good for the money. The only potential issue I see is that you've selected a "K" series CPU. The Intel CPUs with a K suffix are unlocked, meaning they can be overclocked. There is no danger with selecting such a CPU if you do not plan on overclocking it, but the same non-K version of that CPU runs $20 cheaper. If you do want to go with the K CPU, you may want to find out if the motherboard supports overclocking.
215
« on: November 20, 2012, 10:29:41 pm »
I was wondering which system TI Connect would use to convert images before sending them to the TI-84+C. It may be true that there are good existing open source solutions, and it's also true that TI will probably never consider using an open source solution, and decide against licensing commercial code.
I want to point (again?) out that using 8-bit color maybe not be so great for games because a back-buffer would require 77 K of RAM. There may not be enough RAM in the system to make a back buffer, and if there is, filling/sending it would require at least 3 page changes, possibly 5. 4-bit color reduces that to 2 or 3 page changes, and if TI adds no RAM, still leaves games with 10 K of RAM, assuming nobody minds RAM resets. And that's just filling, nevermind drawing. But the best option would be selectable color modes. If there's a monochrome mode, a back-buffer would only require 9600 bytes.
And, of course, a non-back-buffered gaming graphics solution would invariably force programmers to continuously consider flickering issues.
216
« on: November 20, 2012, 04:24:41 pm »
I cà̑ͧ̌nͨ ab̡͊͠͝use Unͮ̂҉̯͈͕̹̘̱ic͇̹̺ͅode̘ ͠t̯͍̭o̚o̐. ̸̡̪̯ͨ͊̽̅̾̎F̧̬̩̾͛ͪ̈́̀́͘u̶̧̨̱̹̭̯ͧ̾ͬn̷̙̲̝͖ͭ̏ͥͮ͟kͮ͏̮̪̝͍y̲̖͊̒ͪͩͬ̚̚͜!̴̟̟͙̞̑ͩ͌͝!̨̥̫͎̭ͯ̿̔̀ͅ
✿ ☺ ☻ ☹ ☼ ☂ ☃ ⌇ ⚛ ⌨ ✆ ☎ ⌘ ⌥ ⇧ ↩ ✞ ✡ ☭ ← → ↑ ↓ ➫ ⬇ ⬆ ☜ ☞ ☝ ☟ ✍ ✎ ✌ ☮ ✔ ★ ☆ ♺ ⚑ ⚐ ✉ ✄ ⌲ ✈ ♦ ♣ ♠ ♥ ❤ ♡ ♪ ♩ ♫ ♬ ♯ ♀ ♂ ⚥ ⚢ ⚣ ❑ ❒ ◈ ◐ ◑ ✖ ∞ – — | ⁄ \ § ¶ ¡ ¿ ‽ ⁂ ※ ± × ~ ≈ ÷ ≠ π † ‡ ¥ € $ ¢ £ ß © ® @ ™ ° ‰ … · • ●
217
« on: November 20, 2012, 05:41:09 am »
I've never seen job ad spam before. They must be really a really ****ty company to need to spam for positions. (The giveaway that it's spam is that no specific company is named in the post. Also, the descriptions are excessively generic and vague.)
218
« on: November 20, 2012, 04:44:06 am »
So I quickly made up some sample images showing various ways to downsize an image. I want to point out the nearest neighbor is the most simple way to downsize an image and also produces the worst results, at least for typical photographs. Similarly, if the TI-84+C uses palette-tized color, there are various methods TI could use to reduce the color depth of images. The color reduction image uses 4-bit color (16 colors) to highlight the differences between algorithms, but it's possible the TI-84+C will use 8-bit color (256 colors) or 16-bit color (65536 colors). (16-bit color is good enough for most non-photographic purposes; the primary reason to use 24-bit color in computers is that it's a lot easier for software to work with.) Again, the simplest way to handle color reduction is using a fixed palette with no dithering, which also gives the worst results. I'll let you decide which algorithms TI will use.
EDIT: I screwed up a bit with the fixed palette one. It actually has 74 colors. And still sucks the most.
Edit 2: I just noticed the moiré pattern on the inside of the hat on the bicubic sharper reduction, which I also used for the color reduction image set.
219
« on: November 20, 2012, 12:26:48 am »
Yeah, exactly.
Also, unlike the 128 K of RAM, the 4 MB of flash is advertised. (TI buys flash chips from other companies---at least three are known---and the chips only come in certain sizes. TI can't knock off 128 K of flash unless they custom manufacture the chips.)
220
« on: November 20, 2012, 12:12:14 am »
What do you mean by video buffer in the archive? Streaming a static picture out of the archive would be quite fast, and the assembly community will definitely find a way to do it, what with the severely limited RAM we're bound to deal with. But if you're thinking of dynamically changing the picture in the archive, that would definitely be pretty slow, and wear out the chip faster than any ridiculous thing we've hacked up. Tangentially relevant discussion from #cemetech: (12:02:14 AM) BrandonW: I very much have my doubts about accessing 4MB of Flash with the paging hardware as-is. I think they changed it to support the color LCD, and while they were at it, allowed more Flash. (12:02:22 AM) BrandonW: Or, perhaps the logic was vice versa. (12:02:49 AM) DrDnar: I bet they threw in more flash more as an after thought. (12:03:17 AM) ParkerR: Or maybe once they are trying to be nice... (12:03:20 AM) ParkerR: Naah that cant be it (12:03:25 AM) ParkerR:  (12:03:27 AM) DrDnar: Can't be it. (12:05:22 AM) DrDnar: Since you figure TI will invariable choose the least-efficient method of storing pictures, I bet they realized that 320*240 = 76800 * 4 = 307200 bytes, so 1.5 MB won't hold very many pictures. (Least efficient method = bitmap with 24-bit color and each aligned to 4-byte boundaries, i.e. wasting 8-bits.) (12:06:24 AM) DrDnar: 1.5/0.3 = 5 and 1.5 / 0.08 = 18 (12:11:46 AM) DrDnar: We'll have to take up the slack in TI's penchant for wasting space by making lossy-compressed image decoders ourselves.
221
« on: November 19, 2012, 11:55:26 pm »
You know, it's quite likely that this thing will have more VRAM than CPU RAM, and the VRAM will still be fairly fast. We could write for it a new garbage collector that buffers sectors into VRAM. (Assuming, of course, that we can still read from it, like we currently can.) And unlike buffering into the extra 80 K of RAM we don't have anymore, TI can't remove the VRAM without breaking their own shiny new display. Best of all, it'll make a really cool "busy" animation.
222
« on: November 18, 2012, 10:23:18 pm »
No, ROM8X is moderately old. The thing that makes it great is the simplicity of the idea behind its operation, which gives it platform independence and maintainability.
223
« on: November 16, 2012, 10:47:12 pm »
I'm sure TI had the same thoughts and decided not to use a memory-mapped solution, because who cares if it flickers whenever the screen is updated? Besides, it's a real snub to those awful game coders.
224
« on: November 16, 2012, 10:43:38 pm »
FloppusMaximus is quite the optimist.
225
« on: November 16, 2012, 10:28:56 pm »
Hmm, that could be very useful in sprite routines.
Pages: 1 ... 13 14 [15] 16 17 ... 38
|
Show Posts