CEMETECH
Leading The Way To The Future
Login [Register]
Username:
Password:
Autologin:

Don't have an account? Register now to chat, post, use our tools, and much more.
Latest Headlines
Online Users
There are 158 users online: 9 members, 137 guests and 12 bots.
Members: APotato, Botboy3000, joshie75, ldstudios, MrDew25, Nemhardy.
Bots: MSN/Bing (1), Spinn3r (2), Magpie Crawler (3), Googlebot (6).
RSS & Social Media
SAX
You must log in to view the SAX chat widget
Author Message
GinDiamond


Power User


Joined: 10 Sep 2012
Posts: 337
Location: Waitsfield, VT

Posted: 20 Feb 2013 11:24:15 am    Post subject:

so if I took out a CSE LCD/driver hardware and swapped it with a standard 84+SE, it could do color?
_________________
Do not muddle in the affairs of dragons, for thou art crunchy and taste good with ketchup!
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 11:27:50 am    Post subject:

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.
_________________


Back to top
GinDiamond


Power User


Joined: 10 Sep 2012
Posts: 337
Location: Waitsfield, VT

Posted: 20 Feb 2013 11:43:10 am    Post subject:

Does the CSE OS use different file extentions than those of the 2.55MP OS? Are the apps formatted the same way?
_________________
Do not muddle in the affairs of dragons, for thou art crunchy and taste good with ketchup!
Back to top
olav_nordmann


Member


Joined: 27 Apr 2007
Posts: 121

Posted: 20 Feb 2013 12:18:50 pm    Post subject:

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?
_________________


Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 12:28:22 pm    Post subject:

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.
_________________


Back to top
Dapianokid


Advanced Member


Joined: 05 Nov 2011
Posts: 195
Location: Right... Here.

Posted: 20 Feb 2013 12:53:28 pm    Post subject:

We need calcsys for this thing STAT.
_________________
What if we all got together and did something ridiculous?
Well?
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 12:56:57 pm    Post subject:

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.
_________________


Back to top
Dapianokid


Advanced Member


Joined: 05 Nov 2011
Posts: 195
Location: Right... Here.

Posted: 20 Feb 2013 01:00:55 pm    Post subject:

Well I think that an oncalc tool like calcsys would be super helpful. Helps me learn about, debug, and manipulate my calculator.
_________________
What if we all got together and did something ridiculous?
Well?
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 01:07:35 pm    Post subject:

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
_________________


Back to top
Dapianokid


Advanced Member


Joined: 05 Nov 2011
Posts: 195
Location: Right... Here.

Posted: 20 Feb 2013 01:18:05 pm    Post subject:

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.
_________________
What if we all got together and did something ridiculous?
Well?
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 01:22:56 pm    Post subject:

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.
_________________


Back to top
Dapianokid


Advanced Member


Joined: 05 Nov 2011
Posts: 195
Location: Right... Here.

Posted: 20 Feb 2013 01:24:22 pm    Post subject:

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?
_________________
What if we all got together and did something ridiculous?
Well?
Back to top
Luxen


Expert


Joined: 12 Sep 2012
Posts: 591

Posted: 20 Feb 2013 01:29:05 pm    Post subject:

wait, did you say the graph screen doesnt need a buffer? ^.-
_________________
Ephesians 1:7, What are you rich in?

Want to give me an Internet? Click here!

My Current Projects
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 01:59:50 pm    Post subject:

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.
_________________


Back to top
DJ_O


Former Omnimaga admin


Joined: 18 Mar 2005
Posts: 1828
Location: Quebec (Canada)

Posted: 20 Feb 2013 02:00:08 pm    Post subject:

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.
_________________
Retired Omnimaga/TIMGUL founder ►PM Omni issues to Omni admins not me, else I won't reply◄

Bandcamp|FB|Youtube|Twitter
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 02:01:49 pm    Post subject:

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.
_________________


Back to top
DJ_O


Former Omnimaga admin


Joined: 18 Mar 2005
Posts: 1828
Location: Quebec (Canada)

Posted: 20 Feb 2013 02:05:29 pm    Post subject:

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
_________________
Retired Omnimaga/TIMGUL founder ►PM Omni issues to Omni admins not me, else I won't reply◄

Bandcamp|FB|Youtube|Twitter


Last edited by DJ_O on 20 Feb 2013 02:06:57 pm; edited 1 time in total
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 59242

Posted: 20 Feb 2013 02:06:43 pm    Post subject:

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.
_________________


Back to top
DJ_O


Former Omnimaga admin


Joined: 18 Mar 2005
Posts: 1828
Location: Quebec (Canada)

Posted: 20 Feb 2013 02:09:05 pm    Post subject:

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.
_________________
Retired Omnimaga/TIMGUL founder ►PM Omni issues to Omni admins not me, else I won't reply◄

Bandcamp|FB|Youtube|Twitter
Back to top
DrDnar


Advanced Member


Joined: 05 Jan 2010
Posts: 186

Posted: 20 Feb 2013 02:30:09 pm    Post subject:

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.
Back to top
Display posts from previous:   
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
    Goto page Previous  1, 2, 3, 4, 5, 6  Next
View previous topic :: View next topic  
Page 2 of 6 All times are GMT - 5 Hours

 
Jump to:  
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

© Copyright 2000-2014 Cemetech & Kerm Martian :: Page Execution Time: 0.049679 seconds.