Logicielsmoto.com

Bonjour a tous,

Suivant une idee de Gilles de combiner son nouvel emulateur JTEO ainsi que le catalogue d'archives de Logicielsmoto, une nouvelle fonction voit le jour (experimental pour l'instant).

Vous trouverez certains jeux ou, en plus du traditionnel lien "Telecharger" apparait un autre lien : "JTEO (Beta)"

Ce lien permet d'ouvrir une fenetre popup et de charger JTEO et le logiciel en question et de l'auto demarrer.

Les titres qui ont cette fonction pour l'instant sont :

* HCL mega demo
* Chinese Stack
* Aigle d'or
* Turbo Cup
* Sapiens
* Captain Blood
* Bobo
* Lemmings
* Tetris
* Bivouac
* Iznogoud

Ceci est encore experimental, et l'emulateur JTEO est toujours en developpement. Gilles a cependant acces en FTP a Logicielsmoto ce qui lui permettra d'uploader les dernieres mises a jour de son emulateur JAVA.

Voila pour les news, d'autres viendront par la suite.

Le news concernant JTEO seront affichees dans la section "Emulateurs".

A+

Yoann

Cette version est effectivement encore en Beta.
La touche F12 permet de basculer clavier/joystick.
Le pavé numérique n'est pas mappé.
Sous linux, les touches numériques du haut ne sont pas correctement mappées (ce qui est plus gênant...).
Les temps de chargement sont parfois un peu longs, il est possible de suivre l'avancement avec la console java

_________________
http://www.alternative-system.com

Tout d'abord, mes félicitations à Gilles pour cet émulateur. Je n'ai pu m'empêcher d'en tester le fonctionnement.

Je ne m'acharnerai pas sur une version expérimentale, mais quelques remarques toutefois, dont certaines n'ont pas forcément de rapport avec l'état d'avancement du programme (testé avec Chinese Stack):

- L'émulateur est très lent, autant pour le chargement que l'exécution des programmes
- Synchro raster pour Colors of China pas encore au point (mais c'est peut-être normal)
- Pas de son (mais c'est peut-être normal)
- Freeze sur une image dans l'animation Mongolian Stunt

Testé sur :
Ubuntu 9.10 "Karmic Koala"
CPU Pentium III 1.266 GHz

Un P/// 1.2G est un peu limite pour le moment.
Je peux accélérer la mise à jour de l'écran (pour le moment tout est intégralement retracé à chaque trame) mais le problème reviendra dès qu'un raster sera utilisé...

Il y a moyen de gagner sur la gestion de la mémoire.
Pour le chargement disquette il y a sans doute moyen de faire plus rapide (par utilisation des classes de buffer, actuellement chaque octet est lu individuellement).

J'ai aussi observé le freeze sur cette animation, je n'ai pour le moment pas intégré certaines subtilité de TEO 1.7 (comme l'ajout d'un cycle sur les lignes impaires...), je dois retravailler la structure de la boucle principale pour coller à la génération des trames de son (qui est donc absent pour le moment).
Egalement c'est plus rapide en compilant avec 1.6 mais je suis resté en 1.4 pour des raisons de compatibilité (test à faire avec 1.6 en mode de compatibilité...).

_________________
http://www.alternative-system.com

Pas de nouveauté pour le moment, la nouvelle version est plus stricte sur les timings... mais cela bloque avec les demos PULS (alors que la version théoriquement incorrecte tournait mieux).
Cela devrait tourner plus vite dans la prochaine version, l'écran était retracé 2x à chaque trame...

_________________
http://www.alternative-system.com

mise à jour de l'applet:
_ affichage plus rapide
_ son 6bits.
_ gestion du pourtour
_ correction du timing

Il reste un bug subtil dans le 6809 qui pose un problème au basic lors du recalcul float -> int

Une partie des optimisations provient de la collaboration avec devilMarkus de CPC wiki.


nouvel exemple:
http://www.alternative-system.com/specific/emu/jteo/space.htm

_________________
http://www.alternative-system.com

J'ai l'impression que l'affichage est saccadé, pas fluide.. comme si on affichait une image sur 4, ou 6-8 imgs/secs. Ca fait des effets stroboscopique pas top parfois. Par exemple pendant la partie worm-hole avec le tunnel et la musique. Normalement la charge CPU sur le TO8 doit être hyper faible à ce moment là, et pourtant c'est pas fluide. C'est normal ou ces ma VM/carteGFX qui est à la traine?

Au passage, je suis surpris par la ligne 2056 de
C'est bizzare ce décalage: tu peux écrire delta = ~0xFFFF directement. Mais perso j'ecrirais cette methode ainsi: C'est pareil que pour signedChar(): moins d'opcodes.

sam.

le passage du canvas au jpanel semble accelerer le rendu, j'ai l'impression que java drop de lui même quelques images si on essaye d'en afficher trop sans double buffer.
ok pour le ~FFFF ca marche aussi, ca va gagner un peu en vitesse.

_________________
http://www.alternative-system.com

Oui, le canvas.repaint() ne redessine pas immédiatement.. il bufferise. Perso quand j'ai bricolé des portages java des vieux progs basic/c que j'avais dans les cartons (ici, ou là, ou encore là(*)), j'avais constaté qu'avecil vaut mieux appeler canvas.repaint() une fois pour l'ensemble d'une image plutot que plusieurs fois canvas.repaint(x,y,w,h) pour l'ensemble des points (cf DEM.jar). La gestion de fusion des demandes de repaint() consécutives m'a semblé couteuse.
___
(*) que j'espère porter sur thomson avec des minifloats

Avec (short)value, ca irait encore un peu plus vite (les petits ruisseaux font des grandes rivières).

après test:
v | (~0xFFFF)
me semble pas mal
(short)v ne me plait pas trop, je me demande si le short n'est pas comme le short du C, c'est à dire au bon vouloir de l'implémentation. (le short est un 32bit comme l'int sur pas mal de processeurs RISC en C, la norme C dit que le short est inférieur ou égal à la taille de l'int).
Je vais merger les modifs de markus, l'animation devient parfaitement fluide avec (du moins sur mon Atom 450)

_________________
http://www.alternative-system.com

En java l'implémentation de short est nécessairement 16bits. C'est dans le livre blanc de la JVM. C'est l'un des gros avantage de java sur du C (à mon avis), c'est qu'il n'y a aucun pb de savoir si un int vaut 16, 32 ou 64 bits: il vaut 32 toujours. Short c'est 16, byte c'est 8 et long 64 partout et toujours. De plus ils sont tous signés ce qui évite pas mal de soucis avec les règles de promotion/conversion implicite du C (unsigned <-> signed étant dépendant du nombre de bits de l'entité sous jacente, donc dépendant du compilo et de l'architecture matérielle et OS, etc). C'est le point fort: sémantique unique permettant qu'une seule compile marche partout pareil et qu'on peut faire des JIT portables efficaces.

Cool! On pourra faire tourner JTEO sur le browser web de la Freebox(*) V6 alors? et voir un TO8 sur son ecran TV comme dans le bon vieux temps? Whaaa
__
(*) Sam: il a free mais il ne comprends plus rien à leur tarifs.

les modifs sont dans le svn, et seront en ligne un peu plus tard apres test de l'applet en ligne.
Ca tourne tres rapidement, 50fps sans pb sur atom

_________________
http://www.alternative-system.com

Note: en C99 il exite les types int8_t, int16_t et int32_t qui ont une taille fixe, lorsque c'est nécessaire.

Les int short et long sont les types 'natifs' du processeur, donc par exemple sur un processeur 36 bits ou un atre truc extraterrestre du genre, on aura un int à cette taille native. short et long peuvent avoir une taille différente si c'est intéressant, par exemple sur 6809 on aurait normalement int=8bit et long=16bit, et sur 6309 il faudrait en plus un long long=32 bit. Le but de tout ceci est de permettre au C d'être compilé en code natif dans tous les cas.

Lorsqu'on veut garantir une taille minimale, les types int_least*_t permettent aussi de le faire. Enfin, il existe des types int_fast*_t qui permettent de toujours prendre la solution la plus rapide (ça peut être 32 bit pour int_fast8_t sur un processeur RISC 32 bits par exemple).

Que demander de plus ?

il faut que je pense à héberger ailleurs... mon petit hébergement ovh est à ses limites, le lancement de l'applet est donc tres lent...

_________________
http://www.alternative-system.com

Oui ne pas oublier .
En tout cas pour java, il ne vaut pas se compliquer la vie. les tailles sont fixes et on peut coder efficacement avec ce qu'il y a comme types de base (je n'ai pas encore été gêné avec le "tout signed"). Parfois, pour voir la qualité du code source, j'utilise "javap -c" pour décompiler et inspecter le bytecode et voir s'il n'y a pas trop de trucs inutilement calculés.

Pour info la conversion int->short n'est qu'un seul opcode "i2s" dans la JVM. Et avec l'inline du JIT, il y a fort à parier que les appels à signed16bits() sont remplacés par la version native du i2s. Pour le vérifier il faudrait utiliser les options magiques utilisées ici (on peut afficher le code X86 générés par la JVM lors du JIT).

sam (iconst_0; ireturn;)