Author Topic: Ndless 2.0 for TI-Nspire Clickpad/Touchpad (Read 181946 times)

codeslicer · « **Reply #195 on:** December 30, 2010, 06:40:45 pm »

Great! Take your time... I myself am burdened with assignments.

No hw for AP Calc though!

codeslicer · « **Reply #196 on:** December 30, 2010, 10:23:25 pm »

BTW: In the meantime, can I suggest to map the down arrow to 5 (instead of to 2), and the Click to something else? It's just that for the current apps like Block Dude/GBC/NES, you need to use the "arrow" keys to walk, and the click in the middle makes it hard to control the joystick with just one hand.

DJ Omnimaga · « **Reply #197 on:** December 31, 2010, 04:45:02 pm »

I hate Christmas assignments. When I went to college we practically had no Christmas break. X.x

Nice work Apcalc by the way.

Levak · « **Reply #198 on:** January 01, 2011, 09:27:00 am »

I took some advance for OS 2.1 support
bootStrapper.S install.c stage2.c utils.c NONCAS 2.0.1 101EB1D8 101EB2DC 10008BCC 10013F6C 101EAC68 10266030 1088F164 NONCAS 2.1 101FEF18 101FF01C 10008D94 100145A0 101FE9CC /!\ 10279D70 109A2B74 CAS 2.1 101FF7E0 101FF8E4 10008D64 100144E4 101FF294 /!\ 1027A640 10966B74

The /!\ addresses have been modified under OS 2.1, I found an equivalent, please take some time to verify them.

EDIT : added syscalls_light

syscalls-light_ncas-2.1.c

Code: [Select]

/* Each entry matches a symbol in syscalls.h. This file is generated by mksyscalls.sh. */
unsigned syscalls_light_ncas_2_1[] = {
	  0X102F75C0
	, 0X102F77B4
	, 0X102F78F0
	, 0X102F6EAC
	, 0X102F508C
	, 0X102FDAE0
	, 0X102F7DC8
	, 0X102F37D0
};

syscalls-light_cas-2.1.c

Code: [Select]

/* Each entry matches a symbol in syscalls.h. This file is generated by mksyscalls.sh. */
unsigned syscalls_light_cas_2_1[] = {
	  0X102F7E90
	, 0X102F8084
	, 0X102F81C0
	, 0X102F777C
	, 0X102F595C
	, 0X102FE3B0
	, 0X102F8698
	, 0X102F40A0
};

EDIT : When I modify Ndless sources to support OS 2.1, it fails, one or more adresses should be wrong.
The fail is : nspire-emu enter in debugger-mode with backtrace, the clock made 1/2 turn, no pixels on the top of the screen, where is the mistake ?
Are the syscalls_[ncas/cas]-2.1.c files important for a simple ndless install ?

Levak · « **Reply #199 on:** January 01, 2011, 06:47:54 pm »

Here are the syscalls_[ncas/cas]-2.1.c

The bug is still there ...
I have double check hard coded and syscalls-lights adresses.

The only supposed issues are :
- the changed subroutine make Ndless bug
- one error in syscalls_[ncas/cas]-2.1.c

For those how know better the Nspire than me, here is the backtrace from the nspire-emu when I want to install Ndless 2.1 on an emulated 2.1 CAS :

Code: [Select]

Error at PC=0000032C: Cannot shift memory offset by register
        Backtrace:
Frame     PrvFrame Self     Return   Start
1800E06C: 1800E0DC 1800E070 102086F0 1020BC24
1800E0DC: 1800E14C 1800E0E0 101FF880 102071C4
1800E14C: 1800E194 1800E150 101FF294 101FF7E0
1800E194: 1800E8B4 1800E198 10041A1C 101FF1F4
1800E8B4: 1800E93C 1800E8B8 1002B32C 100419C8
1800E93C: 1800EA6C 1800E940 1000A684 1002B2E8
1800EA6C: 1800ECB4 1800EA70 101D5684 1000A620
1800ECB4: 1800ECF4 1800ECB8 101D3F00 101D51C0
1800ECF4: 1800FA54 1800ECF8 1000E1F0 101D3D48
1800FA54: 1800FAA4 1800FA58 1000EAA8 1000E180
1800FAA4: 1800FABC 1800FAA8 1025B22C 1000E8F0
1800FABC: 1800FB0C 1800FAC0 101C701C 1025B164
1800FB0C: 1800FCB4 1800FB10 101C7364 101C6EEC
1800FCB4: 1800FCD4 1800FCB8 101C73EC 101C723C
1800FCD4: 1800FD34 1800FCD8 1000F16C 101C73BC
1800FD34: 1800FD9C 1800FD38 100012A4 1000EF5C
1800FD9C: 1800FDD4 1800FDA0 102F2640 10000FE8
1800FDD4: 1800FDF4 1800FDD8 10279F40 102F25F4
1800FDF4: 1800FDF8 1800FDF8 00000000 10279F28
debug>

EDIT :
I noticed, that randomly, i had some pixels on the top of the screen :

ExtendeD · « **Reply #200 on:** January 02, 2011, 07:26:11 am »

Levak: I'll have a look, but I would prefer to fix the other issues before the port to OS 2.1.

calcforth, calc84maniac: thank you so much, cleaning the cache is the solution!
I would like to clean the cache everywhere code is loaded dynamically, including in bootstrapper.S. But GNU AS keeps failing with the following error:

bootstrapper.S:89: Error: selected processor does not support `mrc p15,0,r15,c7,c10,3 bootstrapper.S:89: Error: selected processor does not support `mcr p15,0,r0,c7,c7,0

I have tried different -mcpu and -march options for GCC without success...

ExtendeD · « **Reply #201 on:** January 02, 2011, 07:38:28 am »

My mistake, these instructions cannot be used in Thumb state.

ExtendeD · « **Reply #202 on:** January 02, 2011, 10:52:26 am »

The following issues are now fixed, they were caused by conflicts with the CPU cache. Thanks again, I wouldn't have figured this out alone.
Anyone who still finds one of those with his own calculator can please post a bug report.

Installation message replaced by a document format warning on real harware:
The program loader is called before it is installed, earlier than on OS 1.7. The issue doesn't appear on nspire_emu.
Random crashes when running programs:
black screen with frozen clock, frozen home screen after running a program, or just a reboot. Only appears on real hardware. Even a program with an empty main() and an empty crt0.S can crash.

ExtendeD · « **Reply #203 on:** January 02, 2011, 11:47:30 am »

Yet another bug fix:

Garbage on screen after program execution:
The documents screen is not refreshed as it was on OS 1.7. Sometimes the screen is even shifted to the left.
Workaround: turn the calculator off and on.

For the shifted screen, my tests tell me that:
- It is only caused by read then write from and to the screen buffer (for example the fading loop at the beginning of the particles demo)
- Once shifted, it remains as it is in the program and the OS
- The problem will only appear at certain read/write frequencies (shortening the delay it the fading loop of the demo solves the problem)

I don't really understand how it disturbs the LCD controller, but I recommend not to use byte-size read+write operations on the screen buffer - use instead a copy of the whole screen to read from.

Goplat · « **Reply #204 on:** January 02, 2011, 03:37:02 pm »

Quote from: calc84maniac on December 28, 2010, 07:49:32 pm

Ah yes, caches could be a big issue. In the Ndless program loader, after loading a program try running this: (info taken from the arm926ej-s manual)
Code: [Select]
tc_loop: MRC p15, 0, r15, c7, c10, 3 @test and clean DCache BNE tc_loop mov r0,#0 MCR p15, 0, r0, c7, c7, 0 @invalidate ICache and DCache

I tried adding this, the frequent random crashes I was getting when starting a program are gone

Definitely the right idea, but I have a couple of quibbles:

Should we drain the write buffer too? (Although for Ndless it probably doesn't matter in practice - it'll be drained by itself by the time fread returns - but it would be nice to set a proper example for other programs)
I don't think it's necessary to invalidate the DCache, only the ICache. (MCR p15, 0, <Rd>, c7, c5, 0) If interrupts are enabled, and an interrupt happens to occur between cleaning DCache and invalidating it, it could make memory writes made by the interrupt handler disappear.

ExtendeD · « **Reply #205 on:** January 02, 2011, 04:24:41 pm »

Levak: the skip offset in s2_tizip_hook has changed, maybe this is why it crashes on your side.
I have commited a version that installs on OS 2.1.0 but crashes in ndless_tests, there's probably a wrong address for one of the syscalls.

shrear · « **Reply #206 on:** January 02, 2011, 05:07:33 pm »

Quote from: ExtendeD on January 02, 2011, 04:24:41 pm

I have commited a version that installs on OS 2.1.0 but crashes in ndless_tests, there's probably a wrong address for one of the syscalls.

After ten reboots I downgraded back to 2.0 (with the emu I get three bars then reboot; on hw it's to fast to see the bars)

But it's nice to see ndless making progress direction 2.1

ExtendeD · « **Reply #207 on:** January 02, 2011, 07:22:07 pm »

All the tests now pass on OS 2.1.0 CAS and non-CAS.
The particles demo works on my own Clickpad.
Thanks to Levak for providing some of the addresses.

show_dialog_box2() requires on OS 2.1.0 the interrupts to be enabled else the keyboard won't work. I will provide a wrapper function to make this transparent. Until then some programs such as Block Dude will hang when showing popups.

shrear, that's strange. Could you please try this update which brings full support, at least on nspire_emu?

Goplat: I think I will change clear_cache() with your suggestions that make sense, if it is still stable on real hardware.

Now I feel there are still two main features to be added before moving to the beta-testing phase:

Compatibility with the Touchpad arrows: According to Goplat the hardware interface is not simple, I'm not sure how to add this. Should a function that implement the protocol be added to libndls? Could it have the same signature as isKeyPressed() for the migration of existing program to be transparent? Or should we move instead to OS functions, if they exist?
A simple console: it would integrate with programs through stdin and stdout/stderr (replacing the default RS232 interface), to make ports of non-TI-Nspire programs easier. There would be a prompt, the keyboard would be used to type in strings, echo-ed on the screen. stdout/stderr would be displayed on the scrolling screen.
I may also create a simple shell with history and auto-completion of file names to make possible the execution of command-line tools with arguments.

ExtendeD · « **Reply #208 on:** January 02, 2011, 07:35:43 pm »

I have also fixed the addresses of realloc() for OS 2.0.1 which were wrong.
This should hopefully fix the crash in the cleanup code of nDOOM.

calc84maniac · « **Reply #209 on:** January 02, 2011, 07:48:22 pm »

Quote from: ExtendeD on January 02, 2011, 07:22:07 pm

Compatibility with the Touchpad arrows: According to Goplat the hardware interface is not simple, I'm not sure how to add this. Should a function that implement the protocol be added to libndls? Could it have the same signature as isKeyPressed() for the migration of existing program to be transparent? Or should we move instead to OS functions, if they exist?
A simple console: it would integrate with programs through stdin and stdout/stderr (replacing the default RS232 interface), to make ports of non-TI-Nspire programs easier. There would be a prompt, the keyboard would be used to type in strings, echo-ed on the screen. stdout/stderr would be displayed on the scrolling screen.
I may also create a simple shell with history and auto-completion of file names to make possible the execution of command-line tools with arguments.

I say that the OS functions should not be used, as they certainly do not exist for OS versions less than 2.0. libndls functions to interface with the touchpad might be a good idea. Also, that console idea sounds terrific.

Author Topic: Ndless 2.0 for TI-Nspire Clickpad/Touchpad (Read 181946 times)

codeslicer

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

codeslicer

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

DJ Omnimaga

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

Levak

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

Levak

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

ExtendeD

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

ExtendeD

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

ExtendeD

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

ExtendeD

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

Goplat

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

ExtendeD

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

shrear

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

ExtendeD

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

ExtendeD

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad

calc84maniac

Re: Ndless 2.0 for TI-Nspire Clickpad/Touchpad