Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Matrefeytontias

Pages: 1 ... 28 29 [30] 31 32 ... 133
436
TI Z80 / Re: 84+ OS 2.41 Asm Source
« on: May 06, 2014, 07:14:10 pm »
I voted 1, and moreover it would be really awesome if you could apply the same change (the economy of one or two flash pages) on an 1.19 OS to put on my TI-83+. I need every flash page you may have.

437
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: May 06, 2014, 03:32:57 pm »
So epic :D I hope you'll be able to port it to monochrome Nspires as well, or let someone do it for you (yes this is a proposal) ;D

438
Ben fais le alors. :trollface:
Oui non mais bien sûr --' le disassembly c'est pas mon truc hein. Ça requiert un peu plus de skill que ce que j'ai actuellement.

Je ne suis pas bien en français, donc excusez-mois si mes questions auraient déjà des responses, au j'avais mal compris quelque chose.

Donc, il y a une methode pour donner 64KB d'archive extra a la calculatrice ti-83+, resistant contre des garbage collects?
Ce methode marche aussi sur le ti-84+? Et si, et-il encore resistant aux garbage collects (au contraire du programme nyanmem)?
Il y a une méthode oui, plusieurs même, mais aucune n'est résistante durablement contre les GC.
Cette méthode ne marche que sur TI-83+ d'avant 2013.

439
Je dois pouvoir coder ça sans trop de problèmes, car si la méthode consiste bien à supprimer le swap de l'OS, y'a juste un secteur à effacer.
Mais bon, le swap est important pour l'OS, alors bon...

/e : Ca semble plus compliqué que juste effacer le swap semble-t-il...

Ah tiens t'es Français toi ? :P

Et oui, en général effacer un secteur c'est vaaaaachement trop simple pour marcher. Pis il est utilisé par le GC, donc il sera cherché, pas trouvé, puis restauré au moindre GC. Tout ce que ça risque de faire c'est donner 64k d'archive pendant quoi, 20 minutes si on code beaucoup. Je pense pas, mais c'est même possible qu'il soit utilisé pendant les defrags (on sait jamais, avec TI ...).

Je maintiens ce que j'avais dit y'a deux ans : il faudrait dumper une ROM "normale" et une ROM avec les 64k ajoutés et étudier les différences. Qui sait, on pourrait voir ce qui change et trouver une manière plus sûre de faire pareil sur d'autres pages (si c'est bien la page le problème).

440
Calculator C / Re: [Ndless] Multi-arrow keys detection problem
« on: May 04, 2014, 03:31:45 pm »
Yeah well it's not serving me pretty well for instance >_>

441
Calculator C / Re: [Ndless] Multi-arrow keys detection problem
« on: May 04, 2014, 03:24:36 pm »
Yeah that's what I thought, so it's really weird ; morever I never had this problem before switching to Ndless 3.1 r914 (my CAS prototype must stay with OS 3.1).

442
Calculator C / Re: [Ndless] Multi-arrow keys detection problem
« on: May 04, 2014, 03:20:56 pm »
Well I guess it won't work although I can't really test, I'm only left with a TI-Nspire CAS clickpad and a TI-Nspire CX CAS (thus touchpad) ROM, and switching keyboards within nspire_emu will make arrow keys non-working within the emu.

I also tried reading diagonals with KEY_NSPIRE_LEFTUP and such, but that didn't work either.

443
ASM / Re: Learn Hex/NikProgrammer
« on: May 04, 2014, 03:14:55 pm »
Since hex is a less understandable form of ASM, if you can't get around ASM don't expect anything from hex. Hex is really if you don't have a computer but want to do ASM anyway (like Xeda and I did, but I'm definitely stupid compared to Xeda when it comes to hex (and ASM) programming).

444
Calculator C / [Ndless] Multi-arrow keys detection problem
« on: May 04, 2014, 03:12:20 pm »
Hola,

So that one is a first for me. I have one program, and nspire_emu only detects multi-arrow-keys presses if it's emulating a non-CX Nspire. If it's emulating a CX one, the last pressed key overwrites the preceding one (like, if I hold right then press up, it'll only understand up).

At first I thought that was only nspire_emu, but testing on real HW from a TI-Planet member (I only have a Nspire CAS, on which it worked well) told me that that wasn't nspire_emu.

So I finally thought that was because of the touchpad (again, some may say). That's what I currently have :

Code: [Select]
typedef int KeyEvent; // because cleanliness
inline KeyEvent getk(void)
{
    return (((isKeyPressed(KEY_NSPIRE_UP) << 1) + isKeyPressed(KEY_NSPIRE_RIGHT) << 1) + isKeyPressed(KEY_NSPIRE_LEFT) << 1) + isKeyPressed(KEY_NSPIRE_DOWN);
}

I wrote a small debug wrapper for you to test if you wish :

Code: [Select]
typedef int KeyEvent;
KeyEvent getk(void)
{
    int i;
    KeyEvent k;
    while(!isKeyPressed(KEY_NSPIRE_ENTER))
    {
        k = (((isKeyPressed(KEY_NSPIRE_UP) << 1) + isKeyPressed(KEY_NSPIRE_RIGHT) << 1) + isKeyPressed(KEY_NSPIRE_LEFT) << 1) + isKeyPressed(KEY_NSPIRE_DOWN);
        for(i = 3; i >= 0; i--)
            printf("%d", (k >> i) & 1);
        printf("\n");
        SDL_Delay(1000);
    }
    return k;
}
Look at the console while you press keys ; [enter] to quit.

Any idea ?

445
Calculator C / Re: Ndless Hooking Tutorial (especially key-hooks)
« on: May 04, 2014, 02:58:59 pm »
By finding out what interrupts are and everything around it, the only thread was this one:


http://www.omnimaga.org/calculator-c-language/(ndless)-interrupts-newbie-here/


You tried to help him and he seems to understand... I don't
FYI, I didn't.

446
ASM / Re: So I wondered if Aether3D went unnoticed
« on: April 29, 2014, 06:15:44 pm »
What do you mean "all the engines out there" ?
What do you mean 'What do you mean "all the engines out there" ?' ? :P
Even just you have at least 4 engines :P
(like full Axe, full ASM, full vertices and full faces or something)
Hum <_< it's quite a compliment from you to call these "engines" (Vertex3Dlib, ThreeDee, AxeJh3D and AxVectors respectively). They are more like sets of functions (actually like the original Juha3D).

You've just been pwned. :P
Ooooow yeah, dat useful post.

ben_g : what I wondered a lot was : "is detecting occlusion slower than the actual stupid drawing ?" and it appeared to be a good question.

Actually what I was saying is that instead of trying to make a full fledged engine, a per game optimized engine is better because smaller and faster since it only has the features you need and it's part of your code, not a library.
I agree.

447
ASM / Re: So I wondered if Aether3D went unnoticed
« on: April 29, 2014, 02:52:35 pm »
What do you mean "all the engines out there" ?

448
ASM / Re: So I wondered if Aether3D went unnoticed
« on: April 29, 2014, 02:29:26 pm »
Well, in my opinion that's pretty much everything that can achieve decent speed, I mean an engine unusable outside of its particular context. But it can be done.

449
ASM / Re: So I wondered if Aether3D went unnoticed
« on: April 29, 2014, 07:17:32 am »
Hum.



I call that powerful, even if it's Nostromo by benryves and not Aether3D by qarnos.

450
ASM / Re: ASM Optimized routines
« on: April 29, 2014, 06:04:00 am »
If that's of any use to anyone, here is a signed AHL = AHL / DE routine - I think it's pretty optimized (70 bytes) :
Code: [Select]
sDiv2416:
 xor d
 push af
 xor d
 ld b, a
 jp p, divdPos
 xor a
 sub l
 ld l, a
 ld a, 0
 sbc a, h
 ld h, a
 ld a, 0
 sbc a, b
 ld b, a
divdPos:
 bit 7, d
 jr z, divrPos
 xor a
 sub e
 ld e, a
 ld a, 0
 sbc a, d
 ld d, a
 ld a, b
divrPos:

 push hl
 pop ix
 ld hl, 0
 ld b, 24
divLoop:
 add ix, ix
 rla
 adc hl, hl
 sbc hl, de
 jr nc, $ + 4
 add hl, de
 ; jp nc, xxxx
 ; it works because the carry can not be set and "inc ix" is 2 bytes
 .db $D2
 inc ix
 djnz divLoop

 push ix
 pop hl
 ld b, a
 pop af
 ld a, b
 ret p
 xor a
 sub l
 ld l, a
 ld a, 0
 sbc a, h
 ld h, a
 ld a, 0
 sbc a, b
 ret

Pages: 1 ... 28 29 [30] 31 32 ... 133