Oula... Bon, bein la j'en ai pour un moment !!! ^^
C'est ma machine (ou presque). Je code sur cette machine depuis des années et continue de le faire (en ce moment je bosse sur une adaptation de Jim Power).
Je me permet de corriger quelques erreurs et d'ajouter quelques détails...
Vais faire cela a coup de citation sinon je ne vais pas m'en sortir ^^
Pixel a écrit :
-Processeur principal : Zilog Z80A à 4 MHz
-Mémoire vive (RAM) : 64 ko
-Résolution : 160x200 et jusqu'à 640x200
-Couleurs : palette de 4096 (16 niveaux de Rouge, de Vert et de --Bleu) et jusqu'à 32 couleurs à l'écran
Premier point, 32 couleurs c'est a demi vrai... En fait c'est le minimum !!! En effet rien n’empêche d'utiliser une technique appelée "Raster" et qui consiste à changer la couleur d'une encre en court de balayage écran... Dans ce cas, on peut sans soucis monter à 4096 couleurs à l'écran... Bon ca bouffe du CPU quand même...
Pixel a écrit :
-Nombre de sprites affichables : 16
La encore, 16 minimum, on peut les déplacer en court de balayage. Dans l'une de mes demo, j'ai 32 sprites hard par ligne. Il faut différencier sprites hard et sprite soft car rien n'empèche d'afficher soit même un sprite sans passer par le hardware
Pixel a écrit :
-Nombre de couleurs affichables pour les sprites : 16
Pour les sprites Hard c'est 15 couleurs+ une encre transparente. De même, on peut tout aussi bien rastériser les sprites hard.
Pixel a écrit :
-Son : 3 voies DMA, 8 octaves
DMA ou pas DMA... En fait c'est assez mal foutu. Sur CPC (et CPC+ et GX4000), le son est généré par un AY. Sur CPC old (464,664,6128), pour accéder à l'AY il fallait passer par un autre composant: le PPI (il permet de gérer les port I/O), ce qui coûtait pas mal de CPU et surtout était assez chiant à gérer.
Sur CPC+/GX4000 l'idée d'ajouter un DMA était plutôt intéressante car cela permettait de ne pas avoir à envoyer les données à L'ay et donc d'économiser du CPU puisque justement le DMA permettait que tout cela se fasse tout seul. Le CPC+ gère son DMA avec un vrai language propre ce qui n'est pas une mauvaise chose. La ou le problème se pose c'est que la DMAlist (les données à envoyer) doit forcément être en RAM centrale... Sur GX4000 on s'en fout car il n'y a pas de RAM supplémentaire (64Ko). Sur 6128+ en revanche c'est complètement con car justement on a 64Ko en plus mais on ne peut y stocker la musique (sauf en la recopiant petit a petit en RAM centrale bien entendu mais on pert tout l'interet d'avoir un DMA puisqu'on utilise du CPU pour la copie).
Pixel a écrit :
-Mémoire de masse (cartouches de jeux) : de 128 Ko à 512 Ko
Concrètement toutes les cartouches de la GX4000 font 128Ko... Aucune cartouche n'est sortie avec une taille supérieure...
Pixel a écrit :
Les jeux incontournable du support
on commence avec Burnin' Rubber jeu livré avec la console jeu est vraiment sympa
Navy Seals tiré du film un titre pas évident mais génial
Pang est une excelllente conversion le jeu est convoité tant il est rare
Switchblade pour moi le meilleur jeu de la console
C'est la version CPC a défaut d'avoir la version Gx 4000 qui est un poil plus joli
Dans les bons jeux ont peut citer aussi Tennis Cup II,Panza Kick Boxing et Opération Thunderbolt bien que le pistolet prévu ne soit pas sorti
Ne pas oublier non plus Robocop 2 qui est l'un des meilleurs jeux de la machine
C'est gentil de faire de la pub pour ce site
Surtout que je m'occupe d'une des parties ^^
stefdeg a écrit :sur la pub on y vois la photo de double dragon
il n'est jamais sorti sur gx4000???
Typique Amstrad... C'est une photo de la version Amiga ^^
Pixel a écrit :
Sinon des titres comme Out run et Toki sont bien sorti sur micro y compris sur la gamme CPC Amstrad mais bon les versions GX 4000 devait être bien supérieur
Toki n'est jamais sorti sur CPC.
Pixel a écrit :A ma connaissance toute les cartouches GX 4000 fonctionne sur la gamme CPC 464+ et 6128+ c'est 100% compatible
Tout a fait, c'est la même machine quasiment... Les ordis ont la même carte mère avec juste le controleur D7 en plus (et de la RAM pour le 6128+)
Pixel a écrit :
La GX 4000 a d'autres atouts que ne possède pas la 8 bits de Nec comme la gestion de transparence ou de rupture (en fait ce sont 2 écrans distincts affichés par intermittence) ce qui augmente la taille d'affichage sur la gamme CPC+ et GX 4000 c'est réalisé en hard et la même un Atari ST panique à faire cela
c'est bien visible sur le jeu Robocop 2 ou l'écran du bas gère le Hud et celui du haut le jeu
Désolé de te contredire mais c'est faux ^^ (te vexe pas un, pour une fois que je peux étaler ma science ^^)
La rupture est un concept simple:
-Ce qui apparait sur le moniteur est une partie de la RAM.
-Pour choisir la partie de RAM affichée au moniteur on décide d'une adresse.
-La rupture permet d'avoir plusieurs zones de RAM à l'écran (mais toujours de la RAM centrale). Donc au lieu d'avoir une image provenant d'un seul endroit de la RAM, on peut choisir plusieurs adresses à afficher successivement.
La technique était déjà utilisée sur CPC old mais était un peut plus complexe à utiliser (mais pas plus compliqué que cela). Sur CPC+ ca a juste été simplifié: On choisi à quelle ligne écran on veut telle adresse de la RAM.
La rupture ne permet en aucun cas d'augmenter la taille de l'écran !!! C'est la programmation du CRTC (processeur gérant l'écran) qui permet cela. Rien de nouveau la dedans on pouvait le faire sur un CPC old même en basic (la ou sur Atari ST c'est une vrai merde à faire).
Alcazar a écrit :j'ai fait quelques recherches, et voici le comparatif avec la NES
processeur :
NES : 16khz
GX4000 : 4 mhz
résolution :
NES : 256x240
GX4000 : mode 0 : 160x200, mode 1 : 320x200, mode 2 : 640x200
background :
NES : background tilé
256 tiles de 8x8 pixels et 3 couleurs + transparence.
background 32x30 (256x240), 64x30 (512x240) ou 32x60 (256x480) index de tiles avec scrolling x et y (certaines cartouches ajoutent de la RAM et permettent d'avoir 64x60 tiles). Le background se répète si on affiche en dehors de la résolution (d'où certains artefacts de scrolling).
4 palettes pour sélectionner les 3 couleurs à utiliser pour les index de tile (par paquet de 2x2 indexes)
GX4000 : background bitmap (chaque pixel est directement coloré)
16 couleurs en mode 0 (4 bits par pixel, 2 pixel par octet)
4 couleurs en mode 1 (2 bits par pixel, 4 pixel par octet)
2 couleurs en mode 2 (1 bit par pixel, 8 pixel par octet)
sprites :
NES :
256 tiles de 8x8 ou 8x16, 3 couleurs + transparence.
64 sprites (8 max par ligne) obtenues en sélectionnant une tile, et une palette parmi 4
GX4000 :
16 sprites de 16x16 pixels, 15 couleurs + transparence
chaque sprite utilise les même couleurs
couleurs:
NES :
1 couleur backdrop (pour les pixels transparents),
3x4 couleurs pour les backgrounds,
3x4 couleurs pour les sprites,
total : 25 couleurs, choisies parmi 54
GX4000 :
16, 4 ou 2 couleurs background
15 couleurs sprites
total : 31, 19 ou 17 couleurs, choisies parmi 4096
Attention cependant, car les programmeurs peuvent faire des tricks entre les affichages de ligne :
- changer les couleurs de/des palettes
- changer les tiles en mémoire par blocs (via bankswitching sur NES)
- changer la position des sprites (ce qui permet de dupliquer les sprites sur plusieurs lignes (différentes))
- changer le scrolling (pour avoir un menu fixe, et un décor scrollant par exemple, ou plusieurs écrans les uns en dessous des autres)
Cependant, le processeur de la NES ne permet pas de faire grand chose entre les lignes, et la détection du changement de scanline nécessite une puce dans la cartouche (qui le plus souvent, n'arrête le programme qu'à une ligne spécifique)
En résumé, le GX4000 possède un très puissant processeur (plus puissant que celui de la SNES !) qui permet donc aux développeurs de faire un rendu en software, le programmeur indiquant manuellement la couleur de chaque pixel.
La NES quand à elle à un fonctionnement par tile qui permet de stoker 256 tiles, et d'indiquer la tile à utiliser pour chaque carré de 8x8 sur l'écran. Le PPU (picture process unit) s'occupe d'assembler le tout, et stream l'image vers la télé (la couleur finale de chaque pixel étant calculée juste avant son affichage, et n'est pas stockée dans un buffer)
En fait on ne peut pas comparer...
Chaque machine a son avantage (mais la nes est tout de même bien en dessous de la GX4000... Pareil pour la master system)
Parler de tile ne veut strictement rien dire dans le sens ou tu peux très bien gérer des tiles en soft et les stocker/compresser comme tu veux en ROM.
En revanche la Nes a un petit avantage la dessus puisqu'il n'y a pas à gérer l'affichage du décors, donc gain de CPU à ce moment la... Mais bon ce n'est vraiment pas grand chose puisque de toute façon dans le cas d'un scrolling on ne s'amuse pas à tout ré-afficher, on n'affiche que les nouveaux tiles visibles...
Le gros avantage de la Nes se trouve du coté des sprites hard. Sur CPC+ le nombre est tellement limité que c'est limite impossible de les utiliser pour faire de grandes choses... On doit donc passer souvent par le soft et bouffer du CPU. Changer le contenu d'un sprite hard prend un temps pas possible et on perd tout l'interet de les utiliser... Gros point noir donc la dessus... Mais bon, avec un peu d'astuces on peut quand même faire pas mal de choses ^^
"le programmeur indiquant manuellement la couleur de chaque pixel.": Heu non ^^ Heureusement car la on n'aurait pas fini... Le codage des octets permet simplement de dire quelle encre est utilisée par un pixel, c'est juste de l'encodage
.png "Snes(cartmod)")
bon je pense que c'est pas trop grave 
Voyons un peu de quoi il s'agit 
Par contre le prix m'a l'air assez bas, à leur sortie la MD et la SNES coûtait plutôt vers 2000 F non ?
