Some little topic on the new TI-Nspire CX CR4 hardware.
(hardware revision W+ manufactured since November 2015)
New screen, with a new buffer geometry.
The new buffer is 90° rotated making it 240x320 instead of 320x240, and mirrored.
To give you an idea, if you run on a CR4 some code which does not support the new screen it looks like this :
(https://i.imgur.com/OTPGF7O.png)
Therefore, TI just completely broke the compatibility with all existing Ndless programs - diabolically brilliant. :P
So either we will have to rebuild all existing Ndless programs, most authors having moved on, and for some of which the source code is not available...
Either a future CR4 Ndless could have some kind of a compatibility layer...
But even in the latter case, it would imply writing the screen buffer two times (normal writing of the original program + fix writing), and so it would have a high performance cost for programs constantly refreshing the screen (nDoom, nQuake, emulators...) - we can expect a halving of the fps if there is no CR4 update.
As a result, natural antidowngrade protection: OS / Boot2 / Diags versions 4.0.0 and earlier will not work properly.
Versions 4.0.1 or newer are mandatory.
The CR4 therefore obviously comes with a new Diags, the CR CX IV DVT (2015/06/08) Diag in Version 4.0.1.45 built on August 18 , 2015.
(https://i.imgur.com/K9lqs1P.png)
New boot1 as already stated, version 4.0.1.43 built on July 20, 2015.
Here the bootlog:
Boot Loader Stage 1 (4.0.1.43)
Build: 2015/7/20, 14:47:25
Copyright (c) 2006-2015 Texas Instruments Incorporated
Using production keys
Last boot progress: 0
Available system memory: 28072
Checking for NAND: NAND Flash ID: Generic 1 GBit (0xA1)
SDRAM size: 64 MB
Wakeup Event: ON.
SDRAM memory test: Pass
Clearing SDRAM...Done.
Clocks: CPU = 156MHz AHB = 78MHz APB = 39MHz
Clearing SDRAM...Done.
Boot option: Normal
Loading from BOOT2 partition...
100%
BOOT1: loading complete (168 ticks), launching <BOOT2> image..
According to the new Boot1 log, the new TI-Nspire CX CR4 are faster as slightly overclocked:
156MHz instead of 132MHz - and therefore a 18% speed increase !
Boot1 also has a new boot combo : [doc][enter][1] allowing to reflash the Manuf partition with an RS232 sent image.
Perhaps finally a way to repair TI-Nspire CX calculators whose Manuf has been damaged.
Interesting, especially the screen. Does it mean that the calc uses the same screen as the TI-84 Plus C Silver Edition, but larger? On the CSE, you can notice vertical scanlines if you stare at the screen, which are normally horizontal on other calcs.
This sucks for all Ndless programs, though. I hope that TI did that mainly to improve performances, to save on production costs or to replace a no-longer-produced part, and not as another attempt to block Ndless programs. A compatibility layer will definitively have to be written, even if it means that all programs run much slower (in which case, people might as well switch to Lua or HP PPL). Casio did that with the SH4 calcs, which broke compatibility with many ASM programs.
I wonder if the new screen could have touchscreen capabilities in future Nspire updates? I also hope that the new Boot1 is indeed safer against calculator bricking.
Quote from: critor on February 24, 2016, 08:57:44 PM
New screen, with a new buffer geometry.
The new buffer is 90° rotated making it 240x320 instead of 320x240, and mirrored.
To give you an idea, if you run on a CR4 some code which does not support the new screen it looks like this :
(https://i.imgur.com/OTPGF7O.png)
Therefore, TI just completely broke the compatibility with all existing Ndless programs - diabolically brilliant. :P
So either we will have to rebuild all existing Ndless programs, most authors having moved on, and for some of which the source code is not available...
Either a future CR4 Ndless could have some kind of a compatibility layer...
But even in the latter case, it would imply writing the screen buffer two times (normal writing of the original program + fix writing), and so it would have a high performance cost for programs constantly refreshing the screen (nDoom, nQuake, emulators...) - we can expect a halving of the fps if there is no CR4 update.
Oh goodness. That's horrible. Is there any other reason they might have made the switch, or is it solely to screw Ndless?
Quote from: DJ Omnimaga on February 24, 2016, 09:04:26 PM
Interesting, especially the screen. Does it mean that the calc uses the same screen as the TI-84 Plus C Silver Edition, but larger? On the CSE, you can notice vertical scanlines if you stare at the screen, which are normally horizontal on other calcs.
It's likely the exact same model, which makes sense, economically.
QuoteThis sucks for all Ndless programs, though. I hope that TI did that mainly to improve performances, to save on production costs or to replace a no-longer-produced part, and not as another attempt to block Ndless programs. A compatibility layer will definitively have to be written, even if it means that all programs run much slower (in which case, people might as well switch to Lua or HP PPL). Casio did that with the SH4 calcs, which broke compatibility with many ASM programs.
As can be seen in the boot log:
Clocks: CPU = 156MHz AHB = 78MHz APB = 39MHzSo it's overclocked (or a higher default clock) by default O.O
TI had to embed a compatibility layer for the new LCD themselves, a new OS task "DispCpy" converts the framebuffer in a fixed interval,
which is exactly how the ndless compatibility layer is going to work. (Together with some MMU, timer and FIQ trickery...)
What was the default clock speeds in hardware J? I forgot. Wasn't it 132 or 120 MHz CPU speed?
And wow, if even the OS uses a compatibility layer, then does that mean that the new calc will actually run slower despite the overclocking? O.O
Quote from: Ivoah on February 24, 2016, 09:21:04 PMOh goodness. That's horrible. Is there any other reason they might have made the switch, or is it solely to screw Ndless?
It pretty much doesn't have anything to do with Ndless (although I'm sure TI is happy about this side-effect :P). Remember that "CR4" stands for "Cost Reduction" (phase 4).
So, one way or the other, this LCD was probably cheaper than the old one, the only actual downside being some software tricks to compensate for the orientation/mirror/rotation.
Quote from: DJ Omnimaga on February 24, 2016, 09:35:21 PMAnd wow, if even the OS uses a compatibility layer, then does that mean that the new calc will actually run slower despite the overclocking? O.O
My guess is that they overclocked it as fast as they needed to in order to have the calc behave the same way as older HW. So, there will probably be no visible difference for users.
We may wonder about battery usage, though, but since they've been also messing with power-related stuff in CR revisions, maybe they've improved that to make up for the loss
Quote from: DJ Omnimaga on February 24, 2016, 09:35:21 PM
What was the default clock speeds in hardware J? I forgot. Wasn't it 132 or 120 MHz CPU speed?
132MHz for all CX up to hardware V.
120MHz was on older TouchPad/ClickPad.
Isn't the first of april still like a month away?
Quote from: critor on February 24, 2016, 09:47:40 PM
Quote from: DJ Omnimaga on February 24, 2016, 09:35:21 PM
What was the default clock speeds in hardware J? I forgot. Wasn't it 132 or 120 MHz CPU speed?
132MHz for all CX up to hardware V.
120MHz was on older TouchPad/ClickPad.
I thought that ClickPad calcs were 90 MHz? Or was it just for OS 1.1 through 1.7?
Quote from: Cumred_Snektron on February 24, 2016, 09:52:00 PM
Isn't the first of april still like a month away?
Sadly, this is not an early april fools joke D:
Quote from: DJ Omnimaga on February 24, 2016, 10:08:04 PM
Quote from: critor on February 24, 2016, 09:47:40 PM
Quote from: DJ Omnimaga on February 24, 2016, 09:35:21 PM
What was the default clock speeds in hardware J? I forgot. Wasn't it 132 or 120 MHz CPU speed?
132MHz for all CX up to hardware V.
120MHz was on older TouchPad/ClickPad.
I thought that ClickPad calcs were 90 MHz? Or was it just for OS 1.1 through 1.7?
Yes. Starting with 2.0 they're overclocked to 120MHz.
QuoteRemember that "CR4" stands for "Cost Reduction" (phase 4).
I'm sure this doesn't imply a cheaper cost for end users :P
But yeah, that sucks balls man. 50% speed loss... That's the end for most games :(
50% speed loss for some games, only if they don't get updated with CR4 screen support.
Ah, I see. That makes it a bit less bad, but still bad, mainly because gbc4nspire's source code was lost. At least gpsp-nspire can be updated.
This really sucks :( I love TI for making the calculators, but I really hate them for the way they treat the community...
Quote from: critor on February 25, 2016, 10:22:29 AM
50% speed loss for some games, only if they don't get updated with CR4 screen support.
What if the compatibility layer has frame skipping?
Quote from: DJ Omnimaga on February 25, 2016, 05:32:47 PM
Quote from: critor on February 25, 2016, 10:22:29 AM
50% speed loss for some games, only if they don't get updated with CR4 screen support.
What if the compatibility layer has frame skipping?
It runs with a fixed frequency of 30 Hz for now.
Doing some calculations, it's a speed loss of roughly 15% ((240*320px/frame * 30 frames/s * 10 cycles/px) / 156000000 cycles/s) + some overhead (MMU, data aborts, exception handling).
Ah, that's not bad, then. In any case, I hope that a compatibility layer won't be too much hassle to write.
Also while at it, it would be nice if there was a compatibility layer for Ndless 1.0 and 2.0 programs as well, because there were some cool games back in the days like Block Dude that we can no longer play.
QuoteAlso while at it, it would be nice if there was a compatibility layer for Ndless 1.0 and 2.0 programs as well, because there were some cool games back in the days like Block Dude that we can no longer play.
Looks like that just needs a recompile and minor modifications to run.
That is a problem if the game is closed-source and the author left years ago, though (such as apcalc). Hence why I was suggesting a compatibility layer
New ndless 4.2 r2004 with full support for HW-W (including a compatibility layer that works most of the time): https://github.com/ndless-nspire/Ndless/releases/tag/v4.2
Awesome. How's the speed, so far?
I can't say how the difference is as I do not have a HW-W calc, but gbc4nspire is definitely usable: https://github.com/ndless-nspire/Ndless/issues/26
I'm trying to compile Jetpack Impossible (to then make it compatible with the CR4 models) but I see this when I try.
make
nspire-gcc -Wall -W -marm -Os -c Jetpack.c -o Jetpack.o
mkdir -p .
nspire-ld Jetpack.o -o JetpackImpossible.elf
arm-none-eabi-ld: cannot find -lnspireio
arm-none-eabi-ld: cannot find -lndls
arm-none-eabi-ld: cannot find -lsyscalls
collect2: erreur: ld a retourné 1 code d'état d'exécution
Makefile:39 : la recette pour la cible « JetpackImpossible.elf » a échouée
make: *** [JetpackImpossible.elf] Erreur 1
No idea what I have to do.
Plus, I already had to change something in os.h to get to this point. It was looking for syscall-decl.h but it doesn't exist, so I replaced it with syscall-list.h. Not sure if I was supposed to do that.
I didn't have to change anything in os.h in order to rebuild Jetpack impossible.
Something seems wrong with your SDK...
Well I installed it today ((2016.03.13 - 01:52:37) Hayleia: (et lol le SDK qui s'installe toujours)) using the script here (https://github.com/ndless-nspire/Ndless/wiki/Ndless-SDK:-C-and-assembly-development-introduction) on an Arch Linux I installed on Wednesday, so I guess I can't have dirty things that prevent things to go well :P
As you have to build it yourself on your own hardware, many things may interfere...
Wow. Damn it was fast
@Vogtinator :P
Quote from: Vogtinator on March 13, 2016, 11:06:55 AM
I can't say how the difference is as I do not have a HW-W calc, but gbc4nspire is definitely usable: https://github.com/ndless-nspire/Ndless/issues/26
What about nDoom, Crafti and gp-SP?
Quote from: Hayleia on March 13, 2016, 12:23:48 PM
I'm trying to compile Jetpack Impossible (to then make it compatible with the CR4 models) but I see this when I try.
make
nspire-gcc -Wall -W -marm -Os -c Jetpack.c -o Jetpack.o
mkdir -p .
nspire-ld Jetpack.o -o JetpackImpossible.elf
arm-none-eabi-ld: cannot find -lnspireio
arm-none-eabi-ld: cannot find -lndls
arm-none-eabi-ld: cannot find -lsyscalls
collect2: erreur: ld a retourné 1 code d'état d'exécution
Makefile:39 : la recette pour la cible « JetpackImpossible.elf » a échouée
make: *** [JetpackImpossible.elf] Erreur 1
No idea what I have to do.
Plus, I already had to change something in os.h to get to this point. It was looking for syscall-decl.h but it doesn't exist, so I replaced it with syscall-list.h. Not sure if I was supposed to do that.
That header file is generated by a PHP script during "make" in ndless-sdk/libsyscalls.
Quote from: DJ Omnimaga on March 13, 2016, 10:09:03 PM
Quote from: Vogtinator on March 13, 2016, 11:06:55 AM
I can't say how the difference is as I do not have a HW-W calc, but gbc4nspire is definitely usable: https://github.com/ndless-nspire/Ndless/issues/26
What about nDoom, Crafti and gp-SP?
nDoom is not supported by lcd_compat due to using 8bpp. Critor is currently porting it.
Crafti (nGL) works fine so far, but I'll port it soon as well.
gpSP seems to work fine in lcd_compat, but it can be ported as well if necessary.
Ok thanks for the info. I wonder what display modes are supported on those new calcs... The 84+CSE supported 160*240 and 320*240, at 3 or 16 bits, while the 84+CE supports 320*240 at 1, 2, 4, 8 or 16 bits colors.
Quote from: Vogtinator on March 14, 2016, 01:59:51 PM
Quote from: Hayleia on March 13, 2016, 12:23:48 PM
I'm trying to compile Jetpack Impossible (to then make it compatible with the CR4 models) but I see this when I try.
arm-none-eabi-ld: cannot find -lnspireio
arm-none-eabi-ld: cannot find -lndls
arm-none-eabi-ld: cannot find -lsyscalls
No idea what I have to do.
Plus, I already had to change something in os.h to get to this point. It was looking for syscall-decl.h but it doesn't exist, so I replaced it with syscall-list.h. Not sure if I was supposed to do that.
That header file is generated by a PHP script during "make" in ndless-sdk/libsyscalls.
Thanks, I got rid of the last "cannot find". Two more to go :P
No, actually, only one. The -lnspireio one was fixed too with a make in the ndless-sdk/thirdparty folder.
But for the -lndls, I thought I'd have to do make in the ndless-sdk/libndls but I get errors then -.-
make
nspire-gcc -Os -nostdlib -Wall -Werror -Wextra -ffunction-sections -fdata-sections -c usbd_set_idle.c
usbd_set_idle.c: Dans la fonction 'usbd_set_idle':
usbd_set_idle.c:46:36: erreur: implicit declaration of function 'usbd_get_interface_descriptor' [-Werror=implicit-function-declaration]
usb_interface_descriptor_t *ifd = usbd_get_interface_descriptor(iface);
^
usbd_set_idle.c:46:36: erreur: initialization makes pointer from integer without a cast [-Werror=int-conversion]
usbd_set_idle.c:49:2: erreur: implicit declaration of function 'usbd_interface2device_handle' [-Werror=implicit-function-declaration]
usbd_interface2device_handle(iface, &dev);
^
usbd_set_idle.c:55:10: erreur: implicit declaration of function 'usbd_do_request' [-Werror=implicit-function-declaration]
return (usbd_do_request(dev, &req, 0));
^
cc1 : les avertissements sont traités comme des erreurs
Makefile:18 : la recette pour la cible « usbd_set_idle.o » a échouée
make: *** [usbd_set_idle.o] Erreur 1
QuoteThanks, I got rid of the last "cannot find". Two more to go :P
No, actually, only one. The -lnspireio one was fixed too with a make in the ndless-sdk/thirdparty folder.
Run "git reset --hard; git pull" and then "make clean; make" in the repository.
Only running make in the folders that you need is not enough, you have to build everything.
the usbd_* functions are part of libsyscalls and the generated syscall-list.h header.
Quote from: Vogtinator on March 15, 2016, 08:38:55 AM
QuoteThanks, I got rid of the last "cannot find". Two more to go :P
No, actually, only one. The -lnspireio one was fixed too with a make in the ndless-sdk/thirdparty folder.
Run "git reset --hard; git pull" and then "make clean; make" in the repository.
Only running make in the folders that you need is not enough, you have to build everything.
the usbd_* functions are part of libsyscalls and the generated syscall-list.h header.
Well I didn't only run what I wanted. I used the script described here (https://github.com/ndless-nspire/Ndless/wiki/Ndless-SDK:-C-and-assembly-development-introduction#building-and-installing-the-toolchain-and-the-sdk) and it seems like it didn't do everything.
Anyways, doing what you said (didn't work last week, pulling said "already up to date" and makeing still gave errors but today it) worked, I was able to compile and get a tns for Jetpack Impossible, thanks :)