Calculator Community > TI Calculators
Is it possible to run a TI-84+ OS on a TI-84+CSE?
DJ Omnimaga:
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: ben_g on January 17, 2014, 11:00:20 am ---
--- Quote from: dreamdragon on January 16, 2014, 05:02:11 pm ---okay FINE. x.x
no emulate! <_<
my original question was this:
can i run a ti84 os on a ti84 +c se directly? :hyper:
[can someone please scratch my back?!?!?]
--- End quote ---
--- 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 ;)
--- End quote ---
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.
--- End quote ---
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 x.x. Fixed.
Lunar Fire:
Correct me if I'm wrong, but it seems that the bottleneck here is the serial communication interface with the LCD display, over which we have no control. If we want the CSE to run an OS that would be fully compatible with games from the TI-84+, we would need to replace the screen with another one.
In this regard, it would be impossible to install an OS on the CSE that would fully support the TI-84+ and all of its programs.
DJ Omnimaga:
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.
--- End quote ---
Xeda112358:
Well, yeah, but that's not what you asked. Literally, here are the differences:
-There is more Flash
-The LCD is changed
-The OS code was changed accordingly
Nothing else has changed. In fact, the LCD uses the same two ports as before. The processor didn't change, and the memory map didn't change, so you can definitely put any monochrome OS on the color calc. It would still read keys, work with flash, the USB and I/O port would work (you could still send stuff to it or get stuff off of it with TI-Connect or TILP). You could even send an assembly program that does work properly with the LCD.
But otherwise, yes, it would be impossible to use an unmodified monochrome OS and fully support monochrome programs or apps. They have to be manually ported.
DJ Omnimaga:
Actually, didn't some RAM/Flash memory areas like BCalls location move around a little bit too?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version