Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
so if I took out a CSE LCD/driver hardware and swapped it with a standard 84+SE, it could do color?
GinDiamond wrote:
so if I took out a CSE LCD/driver hardware and swapped it with a standard 84+SE, it could do color?
No. You could write programs that could use color, because the port 10/11 accesses would be sane, but the OS would just make gibberish appear on the screen and probably even crash while trying to do LCD reads.
Does the CSE OS use different file extentions than those of the 2.55MP OS? Are the apps formatted the same way?
KermMartian wrote:
olav_nordmann wrote:
Since you mention the exact same ASIC as the recent TI-84+SE variants, I would guess the TI-84+CSE limited to only the same 48KB of RAM which those have.
It's actually the slightly-less-recent TI-84+SE variants, i.e., 128 KB of RAM.

Quote:
More flash ROM is always great, but more RAM and a faster CPU would have been really nice to have too.
I'm more sad about the CPU capabilities than the RAM, personally.
128KB of RAM is a relief, but yeah, the CPU is still aged.

Do we know anything about how the framebuffer works? Is there some kind of DAC controll system? Can all of that be accessed directly or do we have to rely on BCalls?
We know all about the LCD:
1) The LCD has an internal buffer (of course)
2) The OS uses two RAM pages to back the 4-bit, 265x165-pixel graphscreen foreground
3) The OS uses two RAM pages to back the 16-bit, 133x83-pixel graphscreen background (used for Image files)

Most new ASM programs will either be directly manipulating the LCD or getting libraries to do it for them.
We need calcsys for this thing STAT.
Dapianokid wrote:
We need calcsys for this thing STAT.
Why? There's not a whole lot that Calcsys can tell us that we can't already figure out from looking at emulators' states and existing TI-84+SE documentation. Remember, this isn't a radical departure in hardware other than the new LCD and the new battery.
Well I think that an oncalc tool like calcsys would be super helpful. Helps me learn about, debug, and manipulate my calculator.
Dapianokid wrote:
Well I think that an oncalc tool like calcsys would be super helpful. Helps me learn about, debug, and manipulate my calculator.
Sure, it's something we need eventually, but I don't know if it's among the first thing the new calculator needs. I can think of a few applications we might want first. Smile
Your work with the 3d graphing on the Prizm was tremendous, so I guess it's your choice.
I can't wait to see what people come up with, it looks like the LCD is much more independent of it's CPU so it may be easier to write graphics intense games, like 3D or porting old gameboy games.
It's a rather confusing screen, it isn't as straightforward as the old monochrome... Golly I can't wait to get one of these.
Dapianokid wrote:
Your work with the 3d graphing on the Prizm was tremendous, so I guess it's your choice.
Thanks! That's actually one of the first things I am hoping to port to the new calculator
Quote:
I can't wait to see what people come up with, it looks like the LCD is much more independent of it's CPU so it may be easier to write graphics intense games, like 3D or porting old gameboy games.
It's a rather confusing screen, it isn't as straightforward as the old monochrome... Golly I can't wait to get one of these.
No, that's not exactly right. The LCD is actually more CPU-intensive, because we don't have an LCD buffer to speak of (at least for the full screen) and a full-screen update is no longer a trivial percentage of the 6 million CPU cycles per second.
KermMartian wrote:
Dapianokid wrote:
Your work with the 3d graphing on the Prizm was tremendous, so I guess it's your choice.
Thanks! That's actually one of the first things I am hoping to port to the new calculator
Quote:
I can't wait to see what people come up with, it looks like the LCD is much more independent of it's CPU so it may be easier to write graphics intense games, like 3D or porting old gameboy games.
It's a rather confusing screen, it isn't as straightforward as the old monochrome... Golly I can't wait to get one of these.
No, that's not exactly right. The LCD is actually more CPU-intensive, because we don't have an LCD buffer to speak of (at least for the full screen) and a full-screen update is no longer a trivial percentage of the 6 million CPU cycles per second.


Darned TI is making me angrehh... Mad They can't simply upgrade our CPU to match?
wait, did you say the graph screen doesnt need a buffer? ^.-
LuxenD wrote:
wait, did you say the graph screen doesnt need a buffer? ^.-
The graphscreen has two buffers, each taking two pages of RAM. One is for the background image (which can be a photo); the other is for the foreground image (which is the axes, drawings, graphs, etc). You cannot buffer the entire LCD, because 320*240*2 (16-bit color) is 150KB, larger than the entire 128KB of RAM available.
Tari wrote:
DJ_O wrote:
Since Pxl-test() doesn't detect colors (they all return 1), here is an idea of what I meant:

Congratulations, you just invented arithmetic coding?
The most efficient full-range encoding of values here would of course be binary (maximum representable value: 255). What you've specified there has giant 'holes' of values that can't be represented.


That was just a quick rough example of data storage and not meant to be used as-is. In fact, after posting this elsewhere a few days ago I realized that the 1st pixel isn't even needed anyway if it's for things such as RPG monsters HP storage, in which case the big holes wouldn't be a problem since most enemy hit points in such games have pretty strange values.

In this scenario enemies can have over 40000 HP max, which is very decent for a final boss.

As for binary, the max value being 255 might be fine as well, although for certain data I would need to multiply it I guess.
I was about to say the exact same thing; you can just use it as a standard byte and multiply it by some coefficient. Or you could use a 16-bit value stored in 16 pixels to give you integers from 0 to 65535. I still think, though, that hybrid BASIC libraries would be a faster and cleaner way to store and recall bulk data than exploiting Pic variables.
True. This method would mostly be for people who wants to do the challenge of writing massive games without using a single ASM lib or for people who don't want to wait months before the first ASM libs come out.

Also, if only pxl-test detected colors, this would have made data even smaller and allowed for greater freedom for tilemap storage (16 different possible tiles per map, unlike 2 in Illusiat 6), but sadly, TI didn't think much about us programmers it seems Sad
DJ_O wrote:
True. This method would mostly be for people who wants to do the challenge of writing massive games without using a single ASM lib or for people who don't want to wait months before the first ASM libs come out.
Agreed, that seems like a reasonable target audience. By the way, it occurred to me that it will be interesting to see if anyone tries to exploit text sprites for color sprites, which would be quite a challenge to do correctly. Especially if you want different colors in the same row of the sprite.
Text sprites will depend of how fast displaying small strings of text is. If it's as slow as Line(), for example, then it definitively won't be viable.

For multi-color sprites, I think a set of colors will have to be assigned to each possible sprite as well as the set of characters. Probably via a list or something.
I actually get the impression that Zilog does not license the eZ80 design for incorporation into 3rd party chips. Nevertheless, assuming TI could work out a deal with Zilong, TI can switch to the eZ80 without changing much else in the ASIC, without changing the pinout of the ASIC, and without modifying any of their software, because the eZ80 is binary compatible with the Z80. Keeping the CPU speed still at 15 MHz, the eZ80 would make everything 4 times faster. If they made it 25 MHz, everything would be 6-10 times faster. And the eZ80 can be clocked up to at least 50 MHz.

Of course, there is one reason TI is highly unlikely to do this: If it costs them an extra two dollars a calculator to switch to the eZ80, and they make half a million calculators in a year, that's a million dollars a year of lost profits. TI seems to have wanted to push the TI-84+CSE out the door with minimal investment---as evidenced by the apparent lack of changes to the ASIC---, so they seem unlikely to go through the trouble of licensing a new CPU design just so that the device can have a nice, snappy UI. And face it TI, graphing has never been fast. An eZ80 upgrade would allow you to take fuller advantage of the new screen (e.g. full-resolution pictures, more graph colors, anti-aliased fonts), making everything prettier while still making the calculator much more responsive. You might even throw in 3D graphing.
  
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 2 of 6
» All times are GMT - 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