Corrona ou pas, cela ne doit pas arrêter de vivre ! Avant le confinement j'ai récupéré des choses quand même. Voici un petit tour du mois !!!
Mars 2020 fut un beau mois en machine ! Avec un coup de gueule. On m'a envoyer des machines dans un sac pour faire des courses sans protections !!! Snif. Voici donc mes entrées en machine.

Un 2nd Amiga 600 récupéré de Factor juste avant le confinement. J'ai préparé une carte flash sur IDE. J'attend une carte pour gonfler la machine à 2mo de chip Ram pour faire tourner l'amos. La machine fonctionne très bien.

L'oric avec des jeux. A cause de l'envois il doit passer chez kikich pour une révision. La machine ne fonctionne pas. un peu déçu.

Un C64 modèle C qui fonctionne très bien.

Un Zx spectrum 48k qui fonctionne très bien aussi. Je trouve que cette machine à du charme. J'adore. Sortie Composite incorporé.

Un Zx Spectrum plus. Ceci dit celui la n'a pas la sortie composite. Après le confinement, il va partir chez kikich pour une modification composite. La machine fonctionne bien. J'ai testé en RF.

Le ZXplus avec l'adapateur manette. Ceci dit j'ai un lecteur de carte SD avec port Manette.

J'ai aussi reçu l'atari netusb après un bon mois attente !
Ma collection de livre s'aggrandie aussi pour divers machine.






Voilou ce qui fait un beau mois de mars !!!

Ayant récupéré ce week end un nouveau amiga 600, j'ai voulu en en faire une machine de dev transportable. J'ai réintégré le lecteur de carte CF dans la machine. J'ai passé un peu de temps pour refaire une installation du Workbench 2.11 et des partitions. Je suis partie directement d'amiga forever et des outils du workbench.
La machine possède 4 partitions de 1 Go. Cela semble bien fonctionner. (Mais si je fais des partitions plus grande, ça ne marche pas.).

L'installation et la préparation de la carte se fait bien. Je tente donc une installation de l'amos pro. Le lecteur de disquette lui est capricieux. Et fonctionne mal (ou c'est les disquettes...). Je tente donc d'installer les pilotes pour utiliser le port PCMIA et transférer des datas de l'amiga 1200.

La carte flash formaté en un bloc de 4go n'est pas reconnus sur le 600. Tentative de partition sur PC en vain. Merdum. Je tente un formatage directe sur le Mig, cette fois si, cela fonctione avec lecture sur l'amiga 600 et sur pc.(but recherché) Des fois on cherche compliqué... Par contre je n'ai pas testé sur l'amiga 1200... On verra ça plus tard. J'ai commandé un 2nd adaptateur flash pcmia.
Je replace la carte flash sur le pc pour installer l'amos pro et le compilateur. Un Amiga 600 possède un processeur 68000 et 1Mo de mémoire chip. Mon 1200 c'est en 68030 avec 2 Mo de chip et 7.5 de Fast.

La différence pour travailler se fait sentir ! L'amos pro ne s'installe même pas sur l'amiga 600 en mode 1Mo de chip. Merdum. J'avais plus tot fait un copier coller de fichier du 1200 et l'amos pro me chie dans la colle. Pas assès de mémoire, et quand je règle un peu le problème, l'ouvertur des accessoires est catastrophiques. L'éditeur de BOB/ICONE ne sauvegarde pas les bank en mémoire... Lent... Merde pas l'habitude de ça.

Je me balade sur le site Amedia computer, je tombe sur la carte Fura. (ou un truc comme ça) qui ajoute de la vitesse et de la mémoire à gogo. Proco de 1200 de base mais cadancé à 33MHz, 1.5 de Slow Ram (j'avoue que la je sais pas ce que c'est) et 8 mo de fast ram). je procède à la simulation de cette carte dans amiga forever. (Mais le curseur slow ram est bloqué, donc je passe à 2MO de chip.)

Cette fois si l'amos s'installe correctement, et son utilisation est comme sur mon 1200 (avec moins de ram mais bon ce n'est pas génant).
114 euros la carte. Ce mois si je suis sur la corde. Je me suis offert plein de truc en début du mois !. Mais je tombe sur une carte 602 à 47 euros FDP. Elle ajoute 1Mo de chip au 600. Je configure l'émulateur pour avoir 2 Mo de chip. Une près option existe en plus.
Je test l'amos à partir de la nouvelle configuration, et l'amos reste utilisable. Mon choix est fait. J'ai commandé cette carte. (Dernier achat rétro du mois).
Mon 600 sera équipé donc de cette carte mémoire. Restera et restera en 68000 au niveau processeur...

Le mois prochain je lui intégrerais une bonne carte de chez loktarek ! Un HxC mais pas mini comme possède. Ensuite j'attaquerais de remettre sur pied un amiga 500. Très certainement mon amiga 500 quand j'étais gamin.
Un grand plaisir de revenir sur les micros ordinateurs...

Un beau mois signé livre. J'adore les livres de programmations et technique qui sont en rapport avec les vielles machines.
J'ai eu une belle tournée pour le Zx Spectrum avec 7 livres.

J'ai aussi récupéré deux livres sur pour l'atari st !

L'amiga n'est pas oublié avec le livre de l'amigados.

Et 4 jeux super famicom. Les 4 premiers bomberman. (Il manque le dernier pour le full set jap (loose bien sur)

De la transparence dans les sprites ? Yep enfin. J'ai réussis à faire de la transparence. Avec l'aide de Vincent Rivière et Amaury Durand, j'ai réussis.
La marche à suivre est très simple. Je dois dessiner un mask du sprite en deux couleurs. La couleurs 0 sur la zone affichable du sprite, et en couleur 15, la zone invisible du sprite. Pouquoi index de couleur 0 et 15 ? Ba la couleur 0 placer les bits 0 du mask, et la couleurs d'id 15, placera les 4 plans qui corespond au pixel du fond à afficher à 1.


La première étape est dans un buffer (ou pas mais pour mon test j'utiliseu un buffer) de faire l'opération suivante :
Donnée du Tiles ET (and) Donnée du Mask. L'opération logique vas garder à 1 les bits du plan qui correspond au FOND qu'on doit afficher à l'écran. Et à 0 ce qui sera caché par le sprite. (En gros)

2nd opération, Combiner les données du buffer avec le sprite. Pour cela un Buffer ou(or) donnée du sprite. !!!

Plus a afficher les nouvelles donnée du tiles à l'écran avec le beau fond et le beau sprite !!!

J'avance ! Je ne sais pas si cela va être la forme définitive du jeu dans les emplacements de cadre, mais pour le moment ça marche pas trop mal. J'ai ma carte qui s'affiche et se met à jour quand je me déplace. (11 x 7 tuiles. Chaque tuites fait 16x16 points).
A l'heure actuel le déplacement et l'affichage de tuile est opérationel. Je peux mémoriser 64 tuiles provenant d'un fichier externe. Le background est une image pi1 qui possède aussi la palette de couleur du jeu.
Au niveau de la gestion de passabilité, plusieurs méthode me sont donnée. Je viens de tester avec la méthode blocage directement sur un bit de la tilmap. Mais je pense re faire un tableau avec des donnés de tiles. Chaque tile aura son octet. Un bit indique si la case est traversable ou pas. D'autre peuvent permettre de lier un fond de combat, un autre si la case procure des dommages. Et pourquoi pas imaginer un autre bit qui offre la possiblité de passer sur la case avec certaine condition ?
J'aimerais faire un moteur portable. Le corps du moteur doit être facilement transportable sur d'autre machine. Comme le MSX2. Pour cela au niveau du code, je dois bien l'organiser pour séparer les fonctions du moteur en lui même et les routines propre à l'atari St.
A l'heure actuel au niveau de la mémoire des données :
- 4 ko pour la mémorision de la tilmap.
- 4 ko pour mémoriser le tableau des événements.
- 8 ko pour la mémorision de la planche de tilset. (64 x 128 octets)
- 64 octets pour mémoriser les informations de tiles.
Ce qui fait en gros 16ko de donnée pour l'affichage de la map du jeu.
Une bank sur CPC amstrad 6128 par exemple. Cela peut donner des idées.

Je découvre la programmation sur atari ste en langage C. Enfin peux importe le langage, le plus important c'est d'entrer dans les entrailles de la machine. Son OS. Je peux vous dire que son OS est diablement efficace et possède des fonctions à gogo. Autant que "puissance graphique" du ST nous sommes très loin des amiga, (Ce n'est pas le même prix non plus à la sortie des machines), au tant qu'au niveau os et fonctionnalité pour une machine de 85 cela m'impressionne... Le St possède des DOS. La gestion de disquettes il connait très bien... Formatage, copie, création de dossier... Et tout ça qui peux être utilisé en programmation... Ok les machines 8bits savent le faire xd.

La mémoire vidéo est par plan. (Comme l'amiga). Ce qui rend un peu plus difficile le traitement des "images". Ceci dit ce n'est pas la mort non plus.

Je suis en train de créer ou tenter de créer un RPG occidental de type post apo, a l'heure actuel j'arrive à afficher ma carte de jeu(11x7 tiles de 16x16 pixel), et à la déplacer en mode case par case avec le clavier. Mon workflow est simple. J'ai mémorisé en mode linéaire dans un tableau, les tiles. Un tiles fait 128 octets. Ensuite je re décompose ça sur l'écran vidéo mon tiles par 16 lignes de 8 octets. Le ST travaille en mots de 2 octets. Chaque mots encode 8 points à l'écran dans le plan. Donc 2 octets, 16 points. Cela tombe bien, c'est la largeur de mon tiles. commes nous sommes en mode Lowres, il faut 4 plans pour reconstituer nos couleurs. Donc 8 octets pour encoder une ligne de 16 pixel.

A l'heure actuel je n'arrive pas à travaillé avec un sprite avec couleur transparente avec la méthode des "tiles". Le St possède une fonction sprite software. Je pense que je vais fouinner de ce coté la ...

Le retour sur micro se fait, machine, l'atari ST. J'ai réussis à compiler du C pour le ST en Cross Dev avec GCC. A l'heure actuel j'arrive à afficher une image DEGA à l'écran. (Lenna !!!)

L'envie de trifouiller le ST, retourner sur le C64 et le MSX...

Au niveau des entrée de janvier... :

Un petit jeu sur Master System : Alien 3

L'everdrive Pro pour la Famicom

Un livre sur les consoles 8 bits.

Le Tome 1 du livre du developeur, trop bien, j'ai les deux tomes.

Bien débuté avec le ST/Ste. Dispensable mais bon.

Truc et Astuce pour le ST !

Computer Graphics en C, pas encore lu, mais gros pavé pour les graphismes micro ordinateur.

Le micro Yeti pour mes vidéos

Nes, master system, megadrive, super nintendo, game boy,dreamcast... Des petites consoles dont j'ai réussis à mettre la main dedans. Qu'elle plaisir de pouvoir lancer des homebrew sur console. La master system, console de coeur. J'ai réussis à sortir un jeu en cartouche. Prisonnier II. Vendu entre 20 et 30 exemplaires. C'est un petit chiffre si je compare à Twin Dragon, ou micro mage pour ne citer que deux grands homebrews sur la nes, mais un grand plaisir pour moi. Une victoire d'arriver au bout d'un projet... Ma vie de créateur de jeu s'est beaucoup ralentie depuis un certain temps. A vrais dire je ne sors plus de jeu depuis que je n'utilise plus clickteam fusion mise à part le prisonnier de la master system et des version déma de ce meme jeu sur colecovision et amiga...

Es le temps de faire mes adieux au monde du jeu vidéo ? Au monde de la création du jeu vidéo ?

Mais vous êtes fous ? Oh que non. Mais peut être qu'une page va se fermer. La page de la console vidéo pour revenir à mon première amoure. (Ma copine bien sure), mais aussi le micro ordinateur 8 et 16 bits. L'envie de revenir sur ce genre de machine. Ceux pour quoi ce site existe à la base. Amistrad !!! La contraction de Amiga et Amstrad ! Jolie non ?

Je pense donc que l'année 2020 sera l'année du micro ordinateur et le retour au source que j'aime tant. Le CPC, L'amiga, l'atari ST, le C64 dont j'ai promis un SDK en C xd, Et très certainement remettr en place mon park informatique pour notre plus grand plaisir !!!

Bisous

Un peu de technique snes ... Ce matin je me suis penché sur comment certain RPG de la snes utilisait la mise à jour de la tilemap. La Tilemap c'est la zone mémoire qui contient l'index des tiles à afficher sur l'écran pour faire simple...

Sur Master System, l'écran visible permet d'afficher 32 tiles sur 24. Mais possède 4 tiles non visibles en "bas". Un scrol vertical est plus facile sur la MS qu'un scrol horizontal car ce qui est affiché à l'écran c'est la tilmap complet. Ceci dit il existe une option pour cacher à l'affichage la première colonne pour que la mise à jour des tiles soit caché pour un scrolling. (Donc faut injecté des tiles par tiles-8x8 en horizontal et on peux directement faire du 16x16 en vertical. Pas pratique.

Sur NES c'est plus agréable car il est possible de foutre un écran en plus en horizontal et vertical. Si ne dit pas de bétise la nes permet d'avoir trois écran en mémoire. 2 (ou 3 je ne sais plus)virtuel et 1 affiché bien sur. Ce qui permet de facilité le scrolling.

Je me suis penché ce matin sur la snes et certain RPG. La SNES à 4 configurations possibles. - Le 32x32 tiles. Un seul écran. Avec une zone petite zone invisible en verticale. - Le 64x32 tiles. Ce qui permet de facilité le scrooling horizontal car il y a deux écran cote à cote. -L e 32x64 tiles. Même chose que plus haut mais sur la verticalité. -L e 64x64 tiles. 4 écrans.2x2.

FF4, Secret of mana utilises en mode "carte" le 64x32. Ce qui permet de facilité la mise à jour de la map en scrolling.

FF6 à une particularité. Il reste en 32x32 ceci dit comme la master system, il cache les 8 premier pixel à gauche. ET à droite (chose que la MS ne sait pas faire) pour facilité la mise à jour des tiles de 16x16 très certainement. Verticalement il y a de l'espace. Donc la résolution visible de FF6 est plus petit que FF4. (-16 pixel donc un meta tiles en moins. Méta tiles c'est tout simple un regroupement de tiles qui dans la majeur des case c'est 4 tiles de 8*8 pour donner un tiles de 16x16 )

Le Zelda lui fonctionne en 64x64. Sur le peux que j'ai analysé beaucoup de map n'a pas de modification de map à la volé. La carte est chargé entièrement sauf certain passage comme celui du chateau en extérieur. Mais j'ai pas tout regardé. Pour cela qu'il y a des "chargement de map" avec déplace de caméra...

Les "RPG" utilise souvent le Mode 1 de la snes qui offre 3 plans de background. Les deux premiers plan permettes d'utiliser des palettes de 16 couleurs et le dernier est limité à des palettes de 8 couleurs. Souvent utilisé pour le Hud de zelda ou les boites de dialogue. Je pense que c'est le plan Windows. A ce petit jeu la mégadrive possède un plan backgound et après le choix entre un 2em plan background ou un plan windows (qui est fixe et ne scroll pas) si je ne dit pas de bêtise...

Bref ce matin je n'ai pas programmé, mais j'ai appris plein de truc en décortiquant rapidement certain jeu et en discutant avec mon ami Alek Maul.

Alors oui, peut être ce petit rêve de faire un RPG sur console va peut être se réalisé. Mais j'ai du travaille à faire et encore plein de connaissance à prendre... Wait en scie à bois comme les chiens !!!

La Super Nintendo, (ou super famicom au japon), est ma 2em console de coeur après la séga master system.
Qu'elle plaisir de voir un Hello World sur la vrais machine, compilé par ses mains. J'utilise le devkit d'alekmaul, mais je voulais compilé avec mon traditionel.bat.
Pour cela, je devais comprendre qu'elles sont les lignes de commande à utiliser. Et voici une petite explication en reproduisant au plus proche le workflow d'alekmaul :

- il faut passer du fichier C au fichier assembleur mais avec un préfixe ps. Pour cela il faut utiliser le logicil 816-tcc et linker le dossier include de la librairie d'alek.
816-tcc -Wall -I lien\include -c main.c -o main.ps

-Alek passe par une optimisation. 'deux fois'. Avec 816-opt.py (donc python doit être installer), et constify. Voici les deux lignes de commandes.
816-opt.py main.ps >main.asp
constify main.c main.asp main.asm

-Maintenant il faut passerr à l'assembleur et transformer le main.asm, le data.asm et le hdr.asm en fichier obj.
Pour cela on utilise le logiciel wla-65816
wla-65816 -io main.asm main.obj
wla-65816 -io data.asm data.obj
wla-65816 -io hdr.asm hdr.obj

-L'étate ou il faut réunir tout les objets pour créer le fichier binaire utile. Dans notre cas un .sfc pour la super nintendo/famicom.
Cette fois si c'est au tour du linker wlalink entrer en jeu. Il faut linker votre fichier obj de codage , date et hdr et les bibliothques du sdk.
wlalink -dsnov data.obj hdr.obj crt0_snes.obj main.obj libc.obj libm.obj libtcc.obj snes.sfc

-Un petit coup de finalisation avec snestools est utile.
snestools -hi! -ht"snes" snes.sfc

Ceci est un exemple d'utilisation. Il faut bien penser à indiquer ou se trouve les logiciels en question, et le include de librairie, les fichiers.obj de la lib. Mais qu'elle pied quand cela fonctionne comme on le souhaite. Pour moi cela me permet de compiler comme je veux, et sur ce que je veux. Me reste un peu à optimiser mon.bat comme je le fais avec mes .bat du compilateur sdcc, et à entrer dans le secret de la super nintendo.

Retrouver le pvsneslib a cette adresse :https://github.com/alekmaul/pvsneslib

Je vous souhaite une bonne année 2020. L'année 2019 vient d'être archivé. Cela fait 6 ans que j'ai ce site mais cela fait un petit moment que je ne fais pas de compte rendu de mes test snif.
Lien

Coté livre, deux nouveaux livre pour ma collection de livre de développement pour l'atari st.

Livre pour commodore 8bits

Livre pour l'amiga

Un lecteur de carte Microsd pour la dreamcast

J'ai réçu plusieurs jeu de super famicome

Le Homebrew Sydney Hunter sur snes. En cartouche europe/jap et us.

Une petite carte flash pour l'asmtrad GX4000,464 plus et 6128 plus. La C4CPC !

Mon parc de TV accueil un 4em écran "pro". Un petit PVM. 9220

Deux logiciels pour le stos

Je suis aussi sur le codage d'un mini sdk pour la game boy. Happy GB (mais qui devrait changer de nom, un émulateur porte ce nom).
A l'heure actuel les fonctions exsitantes permetent de gérer la gameboy standard avec une cartouche de 32ko. Le Happy permet d'afficher les sprites (40), charger des données brutes en mémoire (non compressé), gérer le scrolling.
Afficher des tiles à l'écran, et gérer les entrées. Il n'y pas de module sonore. Mais la fonction peek et poke est présent pour taper dans la mémoire de la machine facilement.
Une bêta sera délivré bientôt.