xLIBC is part of Doors CSE 8 along with Celtic 2 CSE. xLIBC/Celtic2CSE are both designed to enhance the capabilities of the TI-BASIC calculator programming language (basically, they let you do stuff that is normally impossible in TI-BASIC, without forcing you to learn Z80 assembly). However, it can be tricky to use and you really need to practice and read the doc on the DCS wiki. It requires you to have some will to learn how to program, though, because other people who also have limited free time are definitively not gonna want to do the job for you.

Quote from: dreamdragon on January 16, 2014, 05:02:11 pm

okay FINE.
no emulate! 
my original question was this:
can i run a ti84 os on a ti84 +c se directly?

[can someone please scratch my back?!?!?]

Quote from: Xeda112358 on January 16, 2014, 10:58:02 pm

That would require a modified OS updating all of the graphics of the OS. This is essentially what the CSE OSes are

Added to that: Once you have a modded 84+ OS that works on the CSE, It will only be able to run BASIC programs correctly, and it will still run slower than the 84+ because it has to send more data to the screen. Assembly, axe, hybrid basic and probably also grammmar programs will still display garbage because they use their own routines to display stuff.

Actually it depends. If you make the calculator in 160x240 mode and only display stuff every two line without stretching anything horizontally, the speed drop might not be that bad. However, the very small display might be annoying and since the CSE LCD only supports 16-bit data, there would still be the issue about every pixel containing 16 times more data than their 83+/84+ counterpart.



Also, in addition to drawing pixels being 16 times slower, the emulator would need to emulate motion blur as well (for grayscale), adding even more strain on CPU resources. EDIT: Nvm, it seems to be three times slower, since there's no more LCD delay.

EDIT: Not sure how this ended up as double-post, but I guess I forgot I already replied to something else then clicked post instead of edit . Fixed.

From what I remember, the bottleneck is really the LCD itself. The CPU is only capable of updating 4 LCDs worth of data every second because there's just too much data to update. Of course the LCD driver might be at cause too, but since the CPU is too slow for the large LCD itself to begin with, it barely makes a difference. On the older models, there is barely any data to send to the LCD so yes the slow LCD driver can make a noticeable difference. It's possible that the CSE has no LCD driver delay, though.

I think DrDnar once posted the t-states calculations showing the max possible frame rate on the CSE. Kerm's ball program also demonstrates how slow it can be by changing the entire LCD color before the ball animation starts.

EDIT: Ok I found it: http://ourl.ca/18368/338852

More technically, the controller only accepts 16- or 18-bit color, meaning 2 to 3 writes per pixel. Outputting a single pixel takes at least 29 clock cycles (for filling the screen with a single color). By contrast, the old controller needed about 100 clock cycles per write, but each write could send 8 pixels, so each pixel only averaged 12 clock cycles. So it takes three times as long to write a single pixel (if you want actual graphics), and the screen has 12.5 times as many pixels. The old controller can accept 120 96x64 frames per second (but it only displays at 60 fps); the new one, displaying only a shrunken 96x64 subsection, can only manage 60 fps. So, the maximum frame rate for full-screen display is 7 fps (0.15 sec/frame), and that's only possible if you're filling the screen with a single color. In practice, 5-6 fps (about 0.2 s/f) is the best you can possibly get for full screen graphics.

Actually, didn't some RAM/Flash memory areas like BCalls location move around a little bit too?

From what I remember, the bottleneck is really the LCD itself. The CPU is only capable of updating 4 LCDs worth of data every second because there's just too much data to update. Of course the LCD driver might be at cause too, but since the CPU is too slow for the large LCD itself to begin with, it barely makes a difference. On the older models, there is barely any data to send to the LCD so yes the slow LCD driver can make a noticeable difference. It's possible that the CSE has no LCD driver delay, though.

I think DrDnar once posted the t-states calculations showing the max possible frame rate on the CSE. Kerm's ball program also demonstrates how slow it can be by changing the entire LCD color before the ball animation starts.

EDIT: Ok I found it: http://ourl.ca/18368/338852

Quote from: DrDnar

More technically, the controller only accepts 16- or 18-bit color, meaning 2 to 3 writes per pixel. Outputting a single pixel takes at least 29 clock cycles (for filling the screen with a single color). By contrast, the old controller needed about 100 clock cycles per write, but each write could send 8 pixels, so each pixel only averaged 12 clock cycles. So it takes three times as long to write a single pixel (if you want actual graphics), and the screen has 12.5 times as many pixels. The old controller can accept 120 96x64 frames per second (but it only displays at 60 fps); the new one, displaying only a shrunken 96x64 subsection, can only manage 60 fps. So, the maximum frame rate for full-screen display is 7 fps (0.15 sec/frame), and that's only possible if you're filling the screen with a single color. In practice, 5-6 fps (about 0.2 s/f) is the best you can possibly get for full screen graphics.

woah woah.
why would they put a slow cpu to run a bigger screen?

Because TI-CARES^TM.

They care??

Quote from: DJ Omnimaga on January 17, 2014, 12:07:21 pm

From what I remember, the bottleneck is really the LCD itself. The CPU is only capable of updating 4 LCDs worth of data every second because there's just too much data to update. Of course the LCD driver might be at cause too, but since the CPU is too slow for the large LCD itself to begin with, it barely makes a difference. On the older models, there is barely any data to send to the LCD so yes the slow LCD driver can make a noticeable difference. It's possible that the CSE has no LCD driver delay, though.

I think DrDnar once posted the t-states calculations showing the max possible frame rate on the CSE. Kerm's ball program also demonstrates how slow it can be by changing the entire LCD color before the ball animation starts.

EDIT: Ok I found it: http://ourl.ca/18368/338852

Quote from: DrDnar

More technically, the controller only accepts 16- or 18-bit color, meaning 2 to 3 writes per pixel. Outputting a single pixel takes at least 29 clock cycles (for filling the screen with a single color). By contrast, the old controller needed about 100 clock cycles per write, but each write could send 8 pixels, so each pixel only averaged 12 clock cycles. So it takes three times as long to write a single pixel (if you want actual graphics), and the screen has 12.5 times as many pixels. The old controller can accept 120 96x64 frames per second (but it only displays at 60 fps); the new one, displaying only a shrunken 96x64 subsection, can only manage 60 fps. So, the maximum frame rate for full-screen display is 7 fps (0.15 sec/frame), and that's only possible if you're filling the screen with a single color. In practice, 5-6 fps (about 0.2 s/f) is the best you can possibly get for full screen graphics.

woah woah.
why would they put a slow cpu to run a bigger screen?

The color screen was added as a gimmick to attract customers. Today, most kids are attracted by color screens, not monochrome screens that are hard to read. However, they decided to stick with the same hardware because they're greedy enough to save $0.05, as ordelore says.

If they replaced the Z80 CPU with an EZ80, I bet they would use this as an excuse to increase the price by $30-40. Just remember how the TI-83+SE costed $30-40 higher than the 83+ even though it only had an extra 1.3 MB of archive and a twice faster CPU.

Because TI-CARES^TM.
Anyway, as anyone who has seen a TI calculator at full retail price can attest to, TI wants to squeeze as much of our money as they can while also increasing their own profits. Look at the TI-84+, it used to come with extra Flash but then TI cut it to save ~$0.05. Still confused?
[xkcd=768]Explained[/xkcd]

Actually, it's RAM that was cut down (from 128 KB to 48). Flash remained intact. However, in the color model, RAM went back to 128 KB (for now).

Is it possible to run TI-84 CSE on the Nspire?

Yeah the screen will most likely need to be implemented via HLE for speed. The Nspire is able to emulate the ASIC accurately enough at full speed though.

I know this topic is SO old, but do you think anyone could assist pulling together a TI 83+ emu for nspire?

Sounds like you should start your own topic instead of using this one.