PpHd
a écrit :
Mais il faudra recompiler le programme.
Et où est le problème? On ne fait pas du Java ici!
Ils l'ont deja fait. Cf passage TI-92 I (Adr screen $4400) a Ti-92 II (Adr screen $4C00).
Mais là, ça fait des ans qu'ils ne l'ont pas fait, et la V200 a toujours LCD_MEM en 0x4c00.
Et l'adresse est même documentée dans la documentation du SDK officiel de TI!
Je cite (j'ai reformaté parce que c'était du PDF, mais c'est exactement ce qu'il y a écrit):
[b]3.2. Memory Map[/b]
[...]
TI-89 Contents TI-92 Plus
[...]
0x004C00 LCD Buffer 0x004C00
0x005AFF 0x005AFF
[...]
Et je bosse aussi pour l'emulation des progs kernels sur Dioxygene.
Je ne programme pas pour du matériel bricolé, et je ne pense pas être le seul.
Ceux qui veulent utiliser des programmes pour une calculatrice n'ont qu'à acheter une calculatrice, pas faire du bricolage. Ou alors ils portent les programmes eux-mêmes. (Si ton système de
RAM_CALLs marche, c'est parce qu'il n'y a que 2 ou 3 constantes qui changent, et que donc sans ce système, il suffirait de réassembler en changeant 2 ou 3
equates - où est le problème?)
Grace a la redirection des ports, ca sera simple a emuler. Et ca ne ralentit rien du tout dans le programme !
Si tu émules les ports, ça ralentit forcément. (Bon d'accord, la Dioxygène aurait un processeur plus rapide... si elle existait...)
Et ça ralentit aussi sur une vraie TI-89/92+, lors du lancement!
C'est bien ce que je dis. Tu ne comprends pas.
Mais si. Je comprends très bien que tu as appris par cœur certaines assertions de manuels scolaires/universitaires de programmation sans t'interroger si elles ont un sens.
Parce que le cahier des charges d'un middle ware
Le vocabulaire employé confirme bien ce que je dis ci-dessus...
doit exclure le bas niveau d'une architecture.
Pourquoi? Parce que ton manuel le dit?
En exportant ces RAM_CALL,, j'offre au systeme d'exploitation la possibilite d'avoir a emuler seulement une partie des Ti, et ca marchera quand meme.
Y en a marre! On programme pour TI-89/92+. Après, si les gens utilisent des émulateurs, OK, mais si l'émulateur n'émule pas tout le matériel, ce n'est pas le problème du programmeurs pour TI-89/92+. C'est simple: soit on émule le vrai matériel (comme le font les émulateurs TI-xx sur PC, ou
TeZXas sur TI-89/92+), soit on porte le programme. Je ne comprends pas pourquoi tu veux nous forcer à faire des programmes facilement émulables par une émulation partielle, de laquelle on n'a rien à fichtre. Fais une vraie émulation TI-89/92+ sur Dioxygène - vu le rapport de vitesse des processeurs, ça doit être faisable (cf.
TeZXas).
Il peut placer l'ecran ou il veut (Il s'occupera de convertir les formats), la table des vecteurs peut etre toucher indirectement,
Cf. mon paragraphe ci-dessus.
les ports IO peuvent etre emuler (Suffit de faire une adresse erreur en mettant les IO_PORT a une adresse impaire, puis traduire l'instruction precedente).
Ça ne marchera pas. Beaucoup de programmes accèdent aux ports I/O en
.b.
Et il me semble (me trompe-je) qu'il n'y a pas de
Address Error sur 683xx (Dioxygène).
Il pourra tester si les rom-calls ont bien ete tous redefinis (et pas d'utilisation de la rom officielle de texas),
Là encore, n'émuler qu'une partie des
ROM_CALLs n'est pas une solution satisfaisante. Il y a pas mal de programmes qui en utilisent beaucoup.
de meme que les ram_calls (on peut par exemple interdire si MainFolder n'est pas emule).
Ce n'est qu'un argument contre
MainFolder. Les
ROM_CALLs de
vat.h sont beaucoup moins dépendants du format interne de la VAT.
Bref j'offre une couche d'abstraction supplementaire pour faire tourner les progs kernels dans des environnements qui pourront etre differents -Atari, amiga, o2, mac, ... - (mais a base de 68k) sans a avoir a emuler le processeur, et le mapping memoire.
Et c'est une très mauvaise idée à mon avis. Il faut programmer pour utiliser au mieux le vrai matériel, pas pour faciliter son émulation.
PpHd a écrit :
Tout a fait !
mais la le kernel pourra essayer de faire une emulation de l'ancien materiel (Difficile mais pa s impossible).
Impossible si le programme désactive tous les auto-ints (l'idée de l'
Address Error ne marche pas - beaucoup d'accès sont en
.b).
Ce n'est pas que pour ca. C'est pour aussi eviter qu'ils ne touchent directement aux interruptions si necessaire (sur un autre systeme).
Autre système -> recompilation!
Ça devrait être logique pour un programmeur en C ou assembleur. Et en assembleur, en principe, autre plateforme -> portage à la main. S'il suffit de réassembler, c'est déjà bien, et ce n'est garanti en aucun cas (cf. TIGCCLIB 2.5 - on n'avait jamais promis que l'ABI ne changera pas, et elle a changé - heureusement que c'est une librairie statique; avec une librairie dynamique, on aurait été obligés de soit garder l'ancienne ABI, soit changer le nom de la librairie et ainsi obliger les utilisateurs à avoir 2 copies de la même librairie, soit forcer tout le monde à recompiler leurs programmes; et grâce au linkage statique, si vraiment vous avez des programmes en assembleur qui utilisent TIGCCLIB et que vous ne voulez pas porter, il suffit de les linker avec un ancien
tigcc.a - mais bon, retour au sujet...
).
Thibaut
a écrit :
Cher Kevin Ô Dieu tout puissant qui lui seul a le droit d'imposer ses idées, sachez que les quelques octets pris en plus par la technique de PpHd sont certainement rien à côté des 50.000 patches que vous nous foutez en têtes des programmes compilés par TIGCC, qui en plus sont recopiés dans chaque programme.
La différence est que nos patches sont utiles, alors que ce que fait PpHd revient à:
void *LCD_MEM;
void _main(void)
{
LCD_MEM = (void *)0x4c00;
...
}
Programmerais-tu vraiment comme ça en C?
Ben, ses
RAM_CALLs fonctionnent exactement de cette manière: on traîte une constante comme une variable, alors que ça ne sert strictement à rien.
.
