Routines 'système' de Ndless

[Noury]

Effectivement, j'ai eu au lancement la fenêtre qu'on voit parfois, me disant que le programme allait s'exécuter en mode compatibilité.
Ce serait ça la raison de l'écran noir également ?
Je suis un peu perdu.

[Noury]

Je ne vois pas ce qui dans ce code provoque le mode de compatibilité.
Est-ce une option d'assemblage ?

L'effacement d'écran semble bien se passer (écran noir)
La boucle d'attente se passe bien aussi
C'est ce qui est au milieu qui semble poser problème. En fait le disp_str n'a pas l'air de se faire. Ou alors il a lieu ailleurs.
C'est très curieux.

[Vogtinator]

lcd_blit draws into the OS's framebuffer, so won't work in compatibility mode.

The compatibility mode is automatically enabled for all .tns files which do not explicitly support HW-W+.
Instead of adding the PRG header yourself, you should build an ELF as usual and conver it to a .tns with

Code: Select all

genzehn --input input.elf --output output.tns --240x320-support true

.

[Noury]

@Vogtinator thanks, it's better, but not yet correctly running.
I've added "--240x320-support true" to ZEHNFLAGS

At make time, I have the following output:

Code: Select all

nspire-as -c HelloWorld.S -o HelloWorld.o
mkdir -p .
nspire-ld HelloWorld.o -o HelloWorld.elf
genzehn --input HelloWorld.elf --output HelloWorld.tns.zehn --name "HelloWorld" --240x320-support true
Warning: Using neither old (SCREEN_BASE_ADDRESS) nor new (lcd_blit) API!
Assuming '--uses-lcd-blit false'!
make-prg HelloWorld.tns.zehn HelloWorld.tns
rm HelloWorld.tns.zehn

And at run time the screen is "reversed".



I've naively added "--uses-lcd-blit true", but it's the same.

I'm pretty sure we're not far from success.

[Noury]

In fact I have:
one execution with black screen, one with vertical garbage, one with black screen, one with vertical garbage...

[critor]

Without the compatibility mode on CX hardware revisions W+, you have to write to the screen buffer in 240x320, not 320x240.

[Noury]

Yes, you are right.
I'm writing at coordinates x=8 and y=16. As they are within the authorized values there should be no problem.
x seems ok, but the writing is up down and not left to right.
Maybe some declarations are missing.

One thing is good now, when exiting the program, screen is correctly displayed.

Do you know if some assembly source code is available somewhere, that uses recent Nspire ?

[Vogtinator]

Hm, that would mean lcd_blit does not support the rotated LCD, at least not if invoked this way.

I suggest to implement text drawing in assembly yourself, that sounds like a nice exercise.

[Noury]

I suggest to implement text drawing in assembly yourself, that sounds like a nice exercise.

You mean drawing characters in a matrix of let's say horizontal 10 and vertical 16, and then put these matrix in a buffer, and finally copying this one in the frame buffer?
If this is what you mean, yes it could be a nice exercice.
After all, my goal wasn't to use necessarily disp_str.

[grosged]

Je n'ai pas de TI-nspire modèle W en ma possession, et je me suis toujours demandé : dans ce mode 240x320, d'où démarre le buffer-écran, je veux dire, de quel coin de l'écran ?
J'ai aussi pensé à écrire une routine d'affichage en mode texte, et compatible sur tous les modèles.
Et je pense à un moyen basique de deviner le type d'écran : au moment de lancer un programme, il suffirait de consulter 1 ou 2 octets bien précis de la mémoire-écran (par exemple parmi les tous premiers octets de la jauge d'état de la batterie )

(je vais faire 1 capture-écran de ma TI-nspire CX CAS, puis de ma TI-nspire CAS)