Il avance tranquillement, quoi donc ? Mon CRPG sur Commodore 64 réalisé avec mon SDK pesonnelle, Happy C64. J'ai commencé à amélioré mes tiles, j'ai utilisé Happy Charset pour créer mes meta tiles. C'est rapidos. J'ai juste à dessiner, et exporter dans le press papier de windows. A partir de la je colle tout le bignouf dans le tableau des tiles de mon fichier data.c, deux trois paramétrage et le tour est joué.

Le plus compliqué c'est l'éditeur de map ! J'utilise 1 octet par tile. Et dans cette octet, je dois encoder l'id du tile compris entre 0 et 15 et l'id de l'action/event à déclancher. (Téléportation, magasin, ...) toujours entre 0 et 15. Tiled et mapwin32 sont de très bon éditeur de map, sauf que pour faire ce que je voudrais, et en toute simplification, c'est un peu bancal. Donc me voila partie dans la création d'un éditeur maison xd. Je vais aussi pouvoir tester l'exportation directe en fichier binaire compatible avec le c64. Des tests sont donc à prévoir ah ah.

Bref, le CRPG avance, je peux afficher une carte, me déplacer, afficher le hud, le moteur se code petit à petit. Ce qui est cool !

Des petites map en mode test du CRPG

Mon petit logiciel de création de tile et de meta tile.

Debut de création de l'éditeur de map.

Un petit billet qui n'a rien a voir avec le retro mais j'ai envie de mémoriser ça et de partager ma joie avec vous.
Le jeudi 12 novembre à 18h37, un petit être vie le jour, mesurant 47cm et 3kg260.
Baptisé du petit doux nom de Noé. La maman va bien. J'en suis fiert, et une nouvelle aventure débute pour moi. J'espère plus grand pouvoir partager cette passion du rétro making avec lui. Merci au personnes qui m'ont soutenue dans ce début d'aventure. Vous avez été nombreux et de beau message à l'arrivé. Merci.

Cette semaine j'ai reçu un Commodore 128 fonctionnel. Je vais pouvoir me pencher aussi sur cette machine et très certainement me créer un SDK à l'image de HappyC64, et du future HappyTed (pour le C16).

Jusque ici, j'avais un soucie avec le Kernal du C64. J'ai vu que nous pouvions écrire sous la rom sans la desactivé. Ce qui me permet de placer la VIC2 en bout de course de la RAM, mais pas la lire ! Car quand je desactivé le kernal, un gros bug se produit !

Hier il y a deux jours, je me suis penché sur la REU soit l'extenssion de mémoire pour Commodore 64 (et 128), Le REU permet de disposer une reserve de RAM suplémentaire pour le C64. C'est même un espace de stockage, car le processeur 8bit ne sait pas adresser plus de 64ko. Et la REU ne fonctionne pas en bank switching comme les 64ko suplémentaire de l'amstrad cpc. La REU propose un espace variable en fonction de l'extenssion (128ko,256ko,256ko et l'ultimate 2+ propose 16Mo). Cette extension est découpé en bank de 64ko (page). L'utilisation du REU est finalement simple. Il y a 4 modes de fonctionnement. (Programmable). Un mode ou on copie un certain nombre d'octet de la RAM du C64 pour la coller dans le REU. Un mode ou on copie un certain nombre d'octet de la REU pour coller ça dans la RAM du C64, un mode pour SWAPER un certain nombre d'octet de la RAM C64 à la REU et vice versa.(Echange de donnée, cela peut être pratique), et un mode pour comparer un certain nombre d'octet de la RAM C64 à la REU. Le déplacement des octets se font par un DMA. C'est supra rapide n'empèche.

Le paramétrage du REU se fait donc simplement,
- On programme l'adresse de départ de la RAM C64.
- On programme l'adresse de départ de la RAM REU avec le numéros de la page.
- On programme la taille du transfère d'octet à réaliser.
- On Lance la commande de transfère.

Alors pourquoi plus haut je parlais du Kernal ? Car dans mon projet de CRPG, j'ai placé mon screen memory dans le Kernal ! Et pour les tests du REU, j'ai repris mon CRPG. Pour copier de la REU => au C64 par de soucie car on ecrit pas dans la ROM mais ça passe automatique en RAM. Ensuite dans mes tests, je me suis dit : Bon pour lire le screen mémory, ça devrait faire comme le vic, c'est intelligent, ça va lire la RAM et non la ROM. Je test la copie C64 => REU. A vrais dire je fais un SWAP. Au premier swap tous se passe bien, j'ai l'écran noire, ce qui est normal vu que je place 1ko de 0 dans la RAM sous le kernal. (Ecriture possible) Ceci dit au 2nd swap, c'est la cata ! Bug à gogo. Ba oui dans le REU c'est 1ko du kernal qui est dans le REU... Donc quand je rétablie mon écran, les DATAS sont pas du screen memory et mais du KERNAL !
Je dois donc palier à ce soucie, alors je cherche de nouveau sur le net des exemples pour désactiver le KERNAL, et je remarque un petit truc dans un livre. Il faut desactivé les interruptions avant de désactivé la ROM, et les réactivés après. Chose que je réalise, et tada ! No soucie !

Il est donc possible maintenant de lire la RAM sous le Kernal ! Et donc avoir à ma dispositions toutes la RAM (ou presque) du C64 pour travailler. Ce qui est cool et une avancé.

53, je crois que c'est le nombre de machine différentes que je possède et fonctionnel. J'ai reçu avant hier un Commodore 128. J'en parlerais quand j'attaquerais cette machine avec le C16 pour HappyC128 et HappyTed

La vache, encore un petit billet sans présenter de matos mais ou je parle d'hardware !!! Oui, montrer que j'ai la plus grosse (ou petite xd) ne sert à rien. Je suis entrée dans la mode ou et regardé j'ai eu ça !!! Et j'ai délaissé sur ce site, les infos techniques dont j'avais envie de parler et de garder une trace. J'aime amistrad ! C'est un peu mon journal de board depuis le début que je suis dans le retro making. Je me dit, je dois refaire un site pour parler info technique mais j'ai la flemme pourtant ce site est bancal, mais j'osef !

Bon revenons un peu au thème du jour sur commodore 64. Le Kernal. Vous savez cette partie de 8ko qui débute en $E000 jusque à la fin de la ram $FFFF. Elle est occupé par le system d'exploitation du commodore 64. Mais c'est de la ROM. ah ah !!! Ce qui veux dire en dessous il y a de la ram. Oh oh ! J'avais tenté de la desactivé mais c'est toujours un echec critique force 100 avec happyC64. Je savais que je pouvais écrire dedans mais pas re lire les informations. 8ko de ram non exploitable donc. Vous dite ?

Il y a deux jours je tombe sur une video. (que je placerais à la fin du billet), Le making off de Planet X2 for Commodore 64, un homebrew réalisé par the 8-bit Guy. Je place les sous titres en Français (rigolot quand il dit Homebrew et que c'est tratuit par bière maison xd), et un moment il parle de gagner de la place, et pour cela switcher la mémoire écran et les patterns des tiles dans la plage mémoire ou se trouve le Kernal ! Que le C64 et surtout le Vic2 est supra intéligent et ne va pas lire la Rom mais la Ram ! Oh oh !!! Alors hier matin, j'ai modifié mes adresse de mon CRPG pour placer tout ça sous le Kernal ! Et croyez moi ça fonctionne !!! Le VicII est capable de lire la RAM et non la ROM du Kernal. J'ai donc un espace de 8ko de mémoire video en ecriture seul ! (Noton que j'ai pas accès pour le moment à la lecture de cette zone, ça déconne en mode lecture) ceci dit comme c'est la mémoire vidéo j'osef un peu.

Ce qui est bien, c'est que je libère de l'espace au milieu de la ram pour mon programme principale et surtout mes DATA par disquette. CE qui est encore bien pour cette technique c'est que pour un "petit jeu" on peu laisser le compilateur c64 gérer cette fois si les variables. Quand on commence à faire un jeu concéquant surtout avec des datas, une maitrise manuel des donnés peut être vitale. En gardant comme je le disais au début, la mémoire vidéo en $8000, ça bloquait le programme principale pour laisser le compilo gérer tout ça.

Voici la routine pour déplacer tout ça dans le kernal ! Avec une paire d'explication. Attention j'explique ça en fonction HappyC64.

La première étape c'est de déplacer le VIC2 à la fin de la ram. Au démarage du C64, il est branché au début de la ram. pour cela un petit set_vic_bank(0); déplace le vic2 dans la 4em et dernière partie du C64. à l'adresse $C000 jusque $FFFF. C'est sa zone adressable.

Le screen mémory va suivre automatiquement. le screen memory est régle de base à l'adresse offset $400, comme de base le vicII est à l'adresse $0, le screen memory se trouve en $400. Mais avec le déplacement du vic, il se trouve en $C400. Ce n'est pas le but rechercher. Nous voulons l'envoyer dans le KERNAL en $E000 par exemple. Début du kernal. Donc en offset $2000. Cela tombe bien offset $2000 c'est 128 pour la fonction que nous allons utiliser. set_adresse_screen_memory(128); La mémoire écran se trouve donc maintenant au début du kernal. De $E000 jusque $E3FF. Bingo

Une troisième manipulation est à faire. Le pointeur de tiles que vous aller redéfinir ! Pareil c'est une offset et se déplace pas pas de 2ko. ($800) dans notre exemple on va le placer en $E800. Pour cela c'est l'offset $2800 de notre mémoire video. Le morceau de code est donc set_location_character(10) Placer un 12 pour placer en $F000, et 14 pour $F800. A vous de voir en fonction de votre organisation de la mémoire video. Note, il est possible aussi d'utiliser 0 pour placer un jeu de 256 tiles en C000. Ceci dit n'utiliser plus du tout les valeurs 2/4/6 car vous aller entrer dans la pile du C et dans les variables I/O. La valeur 0 est utilise en $E000 si vous placez le screen mémory à la fin de la ram. Chose possible. set_adresse_screen_memory(240); Je me pencherais plus tard pour une bonne organisation de la mémoire video !

De la place à gogo ! Oué de la place à gogo pour votre programme. Nous allons revoir tout ça.
$0000 à $03FF : Se sont nos variable system. Et il y a des espaces libres comme le buffer cassette, et d'autre variable. Mais le compilo CC64 ne sait pas y aller. Donc si vous avez besoin d'utiliser une variable, il faut le faire avec la fonction peek et poke de happyc64 par exemple.
$0400 à $07FF : Il y a 1ko de ram libre. Mais encore une fois, le CC65 ne sait pas y aller tout seul, il faut forcer son utilisation à main. 1ko ça peut être utile ! 1024 bloc pour mémoriser des informations... Vous savez quoi, une console commme la colecovision c'est 1ko de Ram pour les "variables", la nes c'est 2ko de ram "pour les variables". Quand je parle de variables c'est pour mémoriser les donnés du jeu pas le code en lui même . Donc en C ça comprend les variables globales, et locales. Les "constante" sur console ça reste si c'est bien fait sur la cartouche... Donc on a déja 1ko de ram de travaille utilisable à la main... Moi je dis ça je dit rien.
$0800 à $C7FF: 48ko pour notre code du programme et les variables global géré par le compilateur ! Quand on lance un prg, le code se place en $800. (Il y a un header au début du $800 en "basic" pour lancer le programme). Les variables globales se place dans cette zone. C'est pas mal ! Une cartouche Coleco et Master System de base c'est 32ko. la master system possède 8ko de Ram de travaille pour les variables. Mais possède un system de bankswitching pour échanger des data de la cartouche. Le C64, possède aussi la meme chose avec les disquettes, et les fichiers de data... je dis ça je dis rien. Bref on a de la marge. Attendez ce n'est pas fini.
$C800 à $CFFF: La nous sommes dans la pile du compilateur CC65. En gros c'est quoi ? Il y a 2ko de mémoire pour gérer les variables locales, les valeurs de retour des fonctions. Bref de quoi bien gérer tout ça. Plus 1 ko en $400.(mais gérable à la main), et ce qui peut être prix dans le programme principale pour les valeurs "global" et tableau de data par exemple, ça gère. J'ai pas réussis mais je pense qu'il est possible de demander au compilateur d'envoyer des const de data ou variable normale à d'autre adresse en modifiant le c64.cfg Pourquoi pas envoyer les "global" en $C000 sur 2ko ! ça peut être sympatique. Cela fait au final 4ko de ram de travaille géré par le compilateur et garder les datas/variables avec le mode constante dans le programme principale... Je dois me pencher sur ça.
$D000 à $DFFF: La c'est les variable I/0. Gestion de la zic, gestion des couleurs de bordure, des sprites bla bla bla. Bref on touche pas pour le jeu en lui même mais pour les effets du C64.
$E000 à $FFFF: Le kernal, et la mémoire video du c64 avec les nouvelles modifications de la ram/card.

Voilou, j'ai pris ma matiné de programmation pour écrire ce billet, et ça me fait plaisir. J'avais envie de garder une trace écrite sur ce blog de mes recherches avant-hier et hier matin. Le c64 est une belle machine. Avec plein de configuration possible et un plaisir de découvrir des petites choses. Maintenant j'ai plus à retravailler la Ram Card pour mon CRPG avec les nouvelles donnés que j'ai !

Lien de la video

Test photoshop du Hud pour le CRPG sur C64 !

J'ai envie d'écrire ce matin sur mon CRPG réalisé sur Commodore 64 avec mon Api HappyC64. Je m'ammuse beaucoup sur ce projet. J'apprend ce que le C64 possède sous sa robe ! Et croyer moi des sacrifices et faire marcher sa caboche, c'est pas du luxe !

Mais revenons à HappyC64, c'est ma librairie pour créer des programmes en langage C avec le compilateur CC65. Un compilateur windows qui cible les processeurs de la famille des 6502. Donc celui du commodore 64, de la nes, de la PCE, Atari 2600 bla bla. La lib me permet d'afficher des charsets à l'écran, gérer les couleurs, manipuler des donnés, et une fonction simple qui me permet de sauvegarder dans un fichier des octets et de les recharger simplement à l'emplacement voulus, et ça c'est vitale !!!

Au debut de la création de la librairie HappyC64, je ne comprenais pas carte mémoire du commodore 64. Je codais mon traditionel Prisonnier sur cette machine, ça marchait bien ! Enfin début ! Car arrivait un moment ou paf, écran noir !!! Plus rien ne fonctionné. Ba oui, avec le recule et un peu plus de connaissances sur la machine, mes déplacements de graphismes empiéte sur le programme en lui même, donc bug à gogo ! J'explique :

CC65 crée un fichier prg, calibré pour être chargé à l'adresse $800. (environs, il y a du code de chargement, bla bla bla.) Le processeur vic ne peux adresse que 16ko de mémoire donc les patterns ne doivent pas aller au dela de l'adresse $4000. Un petit calcule ? Aller admetons que j'utilise les 256 tiles possibles. Ce qui fait 2048 octets à placer au bonne endroit, mais comme ils sont en data, donc dans le programme ça boufe encore 2048octets. Les sprites qui prend 64 octets * 8 . (320 octets) + les paterns dans le programme. Les data maps... Les 14ko environs de diposnible risques d'être mangé à petit feux. J'ai du bien placé mes datas de patern comme il fallait pas. Et paf, ça fais des chocapiques ! Le programme et les datas se mange la geule, game over !!! Ceci dit, il est possible pour le sport de gérer tout ça. Je devrais faire une Ram card simple tien. Voir ou on place les sprites, les 256 tiles et combient il reste pour le programme et data !

Déplacer le VIC ! ZE solution, Le C64 possède des emplacements mémoire libre. Voyons voir un peux tout ça :
- A l'allumage, en $0400-$07FF c'est l'espace pour le Screen Memory (+ pointeur de sprites). Un espace que je récupére en bougant le VIC. Donc pour mémoriser des DATA !!!
- $0800 à $3FFF c'est le chargement du fichier prg crée par CC65.
- On a un bloc libre de 16ko à l'adresse $4000-$7FFF. On peux déplacer le vic ici mais on se limite au 14ko pour le programme principale.
- On a un bloc 3 aussi de 16ko à l'adresse $8000-$BFFF. Perso je déplace le VIC ici. On a même pas besoin des 16ko pour la mémoire video. Les 8 premiers ko me serve pour le screen memory et les paterns des tiles (et j'ai encore de la place je crois 3ko sur 8.) et les 8ko supérieur du bloc, je vais mémoriser ma MAP pour le CRPG. (Faut compter 5ko de data map et j'ai encore 3ko de libres.)
-Le Bloc 4 possède le Kernal (pas touche avec HappyC64) et variable i/o (pareil). Mais 4ko sont de nouveau disponibles en RAM. Enfin les 2 premiers ko de la place $C000-$CFFF car les deux derniers sont reservés pour la PILE des programmes C avec CC65 et HappyC64.
Bref en gros j'ai 28ko pour le programme ! Mais foutre des tonnes de Data ça gonfle vite ! Il faut une solution !!!!

Les Fichiers binaire ! C'est ma solution pour ce genre de jeu ! Cela me permet de cibler et remplire directement les adresses voulu avec les data voulus ! Hihi je charge les tilesets depuis le fichier => Adresse des tileset dans l'espace du vic, basta, ça mange pas d'espace dans le programme principale. Idem avec les cartes du jeu. Ce qui me laisse un bon 24ko (ou moins peut être si il me faut de l'espace), pour du code et pas des datas !

Bref pour programmer sur un micro ordinateur 8 bits, ce n'est pas la même chose que sur une console. La console, en gros code sur la cartouche, data en const pour que ça reste sur la cartouche et que ça file pas en RAM ! Des fois un peu de bank switching,on envois en mémoire vidéo qui est dédiés (VDP, ou autre...) et la RAM pour les variables divers du jeu !!! Souvent les SDK simplifie tout ça. La Non, je dois connaitre la Ram Card de la machine pour pallier au problème...

Il y a 15 jours, je me suis procuré du matos pour le C64. Le Tape Cart, le Kung Fu Flash et l'ultimate II+. Voyons voir un peu mes ressentis sur ses trois extenssions du commodore 64.

Le Tape Cart, au prix de 30 euros avec FDP sur Ebeay. C'est tout simplement un lecteur de fichier .PRG. Le vendeur debbiepaigegav m'a fait parvenir un dossier zip avec des jeux et le firmeware. Cette extenssion demande une micro sd. (et pas une carte SD comme le sd2iec). J'ai réaussis à lancer mes tests de homebrew. A priorie le petit boitier tien la route et un prix tout à fait honorable.
Notons que je me suis rendu compte que mon c64 black edition à des problèmes sur le port K7 en lecture que je n'ai pas corrigé pour le moment.

Le Kung Fu Flash, pareil, faut une carte micro sd. Pas besoin de Firmeware sur le carte ou de logiciel, tu place le tap. ou le D64 et roule ma poule ! Un peu plus cheros que le Tape Cart (Compter une 50en euros avec FDP chez voidabone sur Ebay), le Kung fu flash connait un peu plus de type de fichier.This device will load Crt, D64, D71, D81, Prg, P00 and easyflash files.

La Rolls Royce des cartes flashs pour commodore64. Cette carte sait tout faire. (sauf le café mais bon pour ça il y a madame non ?).
Cette carte émule le 1541 au petit oignon, avec sa vitesse. (ou en accélété), accepte les ficher .tap. Possède deux sids (pas vraiment testé), et bien plus encore. Le prix est bien supérieurs, avec le module TAP et le cordon faut compter 162 euros avec FDP. Ultumate64.com

Avec le SD2IEC qui est bon aussi, cela me fait 4 extenssions différentes pour lire des programmes numeriquement. Ce qui est fort sympathique. Le choix d'une manière de faire dépend donc de votre budget, et de votre excigence. Il existe encore plein d'extenssion sur le marché du commodore 64, mais sur ce que j'ai testé le bon compris reste le Kun fu flash.

Voici la video live ou je présente le matos.

J'ai repris la programmation depuis la semaine dernière de Happy C64. Une petite librairie fonctionnant sous CC65. Cette lib permet de créer des jeux en C pour la machine reine des 8 bits. Le Commodore 64. (Oui, le C64 c'est la reine des 8 bits même si je suis un fan du CPC !!!).

Quand j'ai débuté happy avec le codage d'un Prisonnier, je me suis heurté à plein de bug. Non pas du SDK (enfin si un peu mais pas que) mais surtout de ma comprehenssion de la machine. De l'organisation de sa mémoire.

Le C64 possède une mémoire de 64ko. Le processeur principale est capable de lire d'une traite cette mémoire. (Tout comme le CPC 464 avec son Z80 qui est capable de lire 64ko d'un coup) Enfin que je dis lire d'un coup c'est ce balader en toute simplicité de l'adresse 0 à 65 milles et des broquilles !

Le Commodore 64 possède un co processeur vidéo qui s'appelle le Vic 2. Il se charge de décrypter les informations graphiques avant de les envoyer je ne sais plus ou pour l'affichage sur la TV. Bref c'est la puce vidéo ! Mais le soucie c'est que contrairement au 6510, le processeur de c64, il ne sait lire que 16ko de mémoire d'un seul coup. Ont dit qu'il n'adresse que 16ko ! (C'est un peux plus car il est relié aussi à la table des colors screens mais pour comprendre le petit soucie que j'ai eu on va dire que c'est 16ko

A l'allumage de la machine, le vic est possitioné à l'adresse 0. Ce qui veux dire que tous les datas liés au graphismes doit se trouver entre l'adresse 0 et 16k ! Le screen Memory (la ou on inscrit les datas qui index sur les charsets) se possitione en $400. Les patterns des charsets et de sprite doivent aussi se trouver dans cette plage d'adresse que je nomme Bank_vic !

Le Truc c'est qu'un programme "normale" du Commodore 64 avec CC65 se charge en gros à l'adresse $800. Et on doit pas depasser l'adresse $D000 pour faire simple. Sauf on sort complémente de la bank adressable du vic !(oué copier et coller les patern de charset ou sprite plus loin ça marche plus. Il existe d'autre zone libre du C64 comme à l'adresse $8000 avec 24ko à la suite pour faire simple

Le bug que j'avais avec prisonnier et mes test, c'est que quand je copier/coller mes pattern au endroit voulu, mon programme principale s'effacé et bugé. Oui le commodore 64 n'a pas tout à fait le même fonctionnement qu'une console. L'organisation d'un micri ordinateur 8/16 bits n'est pas la même. Une machine 8 bits a peux de mémoire de travaille en principe. (2 pour la nes, 1 pour la coleco, 8 pour la master system) et les system 16 bits on va dire en 128ko pour le snes et 64ko pour la megadrive. (plus leurs mémoire video...), MAIS les cartouches s'enboite dans la RAM CARD en lecteur seul (ou ecriture pour certaine cartouche...), le Master System c'est des cartouches de 48ko, 32ko pour le nes (+ 8 pour les graphismes qui sont reliés au PPU mais garder à l'esprite que les 32ko). Sur consonle 16 bits c'est je crois 4MO du moins pour le Megadrive. (Je parle pas de bank switchin qui est une autre technique).
Les micros ordinateur ne fonctionnent pas pareil. Souvent la mémoire de masse c'est des disquettes ou des cassets (pour les 8bits). Le Commodore et Asmtrad parte avec 64ko de mémoire. (Le maximum de ram que leurs processeur peuvent voir d'un coup). Vous aller me dire, chouette, c'est plus qu'une console ! En réalité ! Non ce n'est pas du tout le même fonctionnement. Nos 64ko va dégringolé vite fait bien fait ! Deja il faut mémoriser le programme en mémoire qui va bouffer une partie de cette ram ! Un programme de 32ko ba bouffer 32ko de ram ! pan !!!!!!!! reste 32 ko. Puis il faut placer les graphismes au bonne endroite, ça rebouffe la ram, Hors system MSX, La Vram c'est dans la RAM. Il faut garder de la ram pour mémoriser l'affichage de l'écran. Et le bios de l'ordinateur ? Son system exploitation... Bref vous avez compris.

Avec le compilateur je n'arrivais pas à envoyer mon programme en $8000 par exemple par manque de connaissnce du compilo, alors j'ai du réssoudre mon problème d'une autre façon, déplacer le VICII en $8000. Et ça le C64 sait le fait ! Le Vic peut se déplacer à 4 endroits de la ram. 16x4 ? 64k

En déplaçant le vic en $8000, tous les autres pointeurs se déplace avec lui. Le pointeurs du memory screen, le pointeur de charset, et les 8 pointeurs de sprite !

Avec cette nouvelle organisation , ça me laisse en va dire une bonne 20ko pour le programme, des ko pour les variables géré par le compilateur. 16ko pour la gestion de Vram (Screen Memory, pattern de sprite et charset), et j'ai un petit troue de 4ko pour des variables ciblés par mes soins !

Donc voila avec tout ça en Ram de travaille ce n'est pas plus énorme d'une console de jeu vidéo 8 bits. Juste que l'organisation est différentes.

Voilou, un petit texte explicatif sur Amistrad de mes travaux, ça m'avais manqué, c'était le but de ce site à la base. Parler de mon expériance , cela s'est transformé en vitrine de collection qui finalement ne sert à rien. Je vais donc revenir à la base sur ce site ! Et cette article en est un exemple...

Retrouver Happy C64 sur le github Lien

Les vielles consoles de jeu et micro ordinateur Amiga, Atari , et j'en passe n'a pas l'exclusivité de terme old school. Dans le monde du retro, il existe de vieux system informatique très proche de ce que nous utilisons à l'heure actuel pour la majeur partie de gens. Avant notre Windows 10 (ou Seven pour moi...), il existe d'autre system réalisé par la firme de Bill Gate !!! Le Dos , et les autres version de Windows. Personnellement, je me suis lancé sur un Windows 98 vers les années 2000/2001. J'ai découvert le windows Xp bien bugé. (a coté de ça, vista c'était super), et je suis toujours en mode Seven au moment d'écrire ce texte.

Les productions Dos/MS Dos ont toujours la quote. Il existe des pépites de cette époque. Depuis un petit moment, je voulais construire un PC sous DOS. C'était en projet. Et puis soudain, je tombe sur l'article des deux compères Philippe dubois et Laurent de Rammelaere. La réalisation d'un petit pc dos d'une 30en euros. Le HP 5710, une machine (serveur) qui embarque un processeur Transmeta à 800mhz (il "émule un x86 pour faire simple"), un disque dur ssd id de 256 Mo, 256 Mo de ram (DDR1), une carte video radeon et une puce sonor compatible sound blaster. Au niveau conectique, c'est un port parallele, série, 4 usb, ps2 (rien à voir avec la playstation hein), sortie vga, sortie son et entrée micro. Une entrée / sortie RJ45 et Allimentation et un port PCI. Un candidat tout trouvé pour faire du PC rétro... Et ça fonctionne bien. Je me suis achêté trois petites machines sur Ebay ! Mais pas que !

Upgrade de deux machines : 256 MO de Ram et 256 Mo de DD, ceci est très mince. Sur les trois machines, je vais en garder sans modifications, et j'ai modifié une autre machine en remplaçant la Ram par une barrette de 512mo et le SDD id avec un kit de 2Go ! Ce qui ma permis d'installer Windows 98se sur la machine.

Ce que j'aime, c'est programmer les machines, je voulais une machine dos/win98 pour voir comment le mode VGA fonctionne. Depuis 15 jours j'ai le nez dans la programmation en mode Pc 16bits avec Turbo C 2.1. Je n'utilise pas la biblioteque graphiq de TC mais je recherche à apprendre. A l'heure actuel, j'ai compris comment adresse la mémoire video , utiliser une sourie et une manette de jeu (sous windows car si je boot sur dos les drivers ne sont pas installé), gérer une palette, et deux trois truc. Et franchement c'est fort sympathique. Le mode VGA est en mode bitmap. Une plage mémoire de 64k est réservé pour l'affichage graphique. Chaque octet de cette plage affiche un pixel à l'écran. Ce qui est cool, c'est que le pixel 0,0 c'est l'octet 0, le pixel 0,1 c'est l'octet 1... Tout est linéraire. Le mode VGA permet donc d'afficher une résolution de 320x200 points en 256 couleurs. Chaque octets c'est un index dans la pelette de couleur... Fioux que c'est bon. Donc un petit offset = 320*Y+X permet de taper dans la mémoire video et d'afficher le point désiré...

Au niveau de la manette de jeu, c'est un peu plus compliqué, il faut jouer avec des borne de valeur pour detecter la direction de la croix. La gestion des boutons par contre c'est plus facile. Du moins pour une seul manette. Il est possible d'avoir 4 boutons. autant on peux différencier deux manettes de jeu, autant que les boutons sont en communs... Bon, il y a très certainement des tips...

Pour mes test de programmation avec TC, j'ai utilisé pour la première fois, la technique du double buffer. Je prépare mon ecran dans un tableau de 64k qui représente donc une page de la mémoire video et au moment voulu, je copie le tableau, dans la mémoire video ! (Merci Memcopy en C ). Le tour est joué, et je n'ai pas de flash écran...

Pas de jeu au programme, je dois finir mon jeu amiga que je vais reprendre très très bientôt. Et attaquer la création du labyrinthe. Mais cette initiation à la programmation en C du MS dos ma très enrichie. C'est une belle aventure, et personnellement, je conseillerais même au débutant qui veulent apprendre le C de débuter par la. Je pense même faire ça avec ma chérie !

Voici des Liens fort sympathique :
Creer un mini PC MSDOS à moins de 32 euros
Clef usb et changement de disque dur
Installer Windows 98Se
512 Mo de Ram sur Ebay (4 Euros)
2 Go DD flash ide sur Ebay (12 euros avec FDP
La Machine sur Ebay
17 euros la machines, 17 euros de FDP (et si vous en commendé d'autre, vous ajouté que 4 euros par machine suplémentaire pour le FDP !!! Achat groupé c'est mieux donc)
De la documentation de programmation ms/dos
Des programmes pour DOS/Windows 3.1/95/98

J'ai reçu un boitier de protection pour la carte accélératrice classique 520 pour un amiga 500. La carte est un peu beaucoup protégé comme ça.

J'ai reçu aussi gotek que j'ai intégré dans mon amiga 1200. Le voila prèsque complet xd. Me reste à recevoir une nouvelle carte conpacte flash avec une installation réalisé par halifaxe.

Le saint graal !!! J'ai reçu la classic 520. Une extenssion pour un amiga 500 qui permet d'ajouter 8 Mo de Fast Ram, un port IDE 3 pouces et demis, de la ram pour un Kickstart, un lecteur de carte SD pour échanger des données plus facilement avec un autre ordinateur, un lecteur de carte flash pour créer un disque dur et le processeur 68020 (mode eco) à 28 Mhz ! Une belle petite machine quoi pour un amiga 500.

Ce matin j'ai réalisé une petite modification sur l'amiga 500 offert par capitaine caverne. La carte c'est uen 6A, j'ai donc joué un peu de l'éteint pour devier les 512ko d'une carte extenssion qui est concidéré en slow, en 512ko qui est concidéré en Chip. Ce qui me fait 1 Mo de chip ram pour cette amiga...

J'ai reçu cette semaine des pièces informatiques. Une extenssion de mémoire de 1mo chip pour mon amiga 600. Ce qui lui fait passer la machine à 2 Mo de chip.
Le 600 est sympathique pour être transporté. Il est petit, et sympathique avec son port ide qui permet de foutre une compacte flash.
Il est équipé de 1 Mo de chip ram et garde le processeur 68000.

J'ai reçu aussi l'everdrive X7 pour la megadrive. Ce qui va me permettre de tester et de finaliser prisonnier sur cette machine.

16 Mo sur mon amiga 1200. Hier j'ai reçu ma barrette de 16Mo pour la carte blitzzard IV équipé du processeur 68030. Elle était équipé de 8 MO jusque la. J'ai passé la capacité de l'amiga à 16 Mo.
Au niveau des émulateur, (Amiga Forever), je me suis rendu compte que je ne dois utiliser la mémoire Z3 et non Fast Ram. CEci dit cela reste bien de la Fast Ram.
Un truc que je viens de remarquer avec Amiga Amos Pro, le petit curseur en haut à droit pour la Ram n'est pas capable de detecter cette mémoire. Et la barre considère qu'il n'y pas de Fast Ram. Mais un petit print fast free indique bien le contraire.

J'ai des bon souvenirs sur mon Amiga 500. Cela de mon enfance. Offer par mon oncles (Avec la participation de mes parrents je crois) quand j'étais gamin. L'amiga 500 ou le Mig500 comme j'adore l'appeller à une place dans mon coeur. Avant de l'avoir, mon oncle le possédait. J'avais les yeux qui pétillent ! Je me souvient de superbe titre comme Nicky Boom, Sim City, Alien breed, Nord et Sud, et Canon Fodder. Les titres qui me revient en tête quand je jouais sur son mig500, avec les magasines "Amiga dream".
Je me souvient aussi de mon oncle avait ajouter un disque dur. Un Gros pavé qu'on ajoute à gauche de la machine, et qui fait un barroufe du tonnerre. J'ai le souvenir ou il disait : il peut mémoriser une bonne 50en de disquette en gros. Moins 50Mo d'espace disque très certainement. A l'heure actuel on parle en T. le monde informatique change au niveau des capacité mémoire...
Quand il est passé sur l'amiga 1200 (Moi je dit Amiga douze cents !!! na je fais ce que je veux !) ce micro est passé chez son frère. (qui est aussi le frère de ma mère donc mon oncle ! vous suivez ? )
Je me souvient d'avoir continué à joué dessus. Et deçu que ce 2nd oncle n'a pas gardé cette machine. J'aurais aimé récupéré ce hardware.

Quand j'étais gamin, j'ai eu aussi mon Amiga 500 à moi. (Tous comme ma soeur plus tard, et mes deux tantes aussi. Deux soeurs à ma mère. Qui sont aussi deux soeurs de mes 2 oncles. Et j'en est un 3em. Oncles du coté de ma mère.
Bref, je ne serrais pas dire à qu'elle age j'ai eu mon Amiga. Mais je me souvient que ce fut à un anniversaire. Le mig était équipé d'une extenssion de mémoire (que je viens de retirer pour en mettre un neuf) et porter la capacité de la machine à 1Mo. Ce qui était recommandé dans certain jeu. Le lecteur de disquette bouffé les disquettes avec le troue à gauche. Lecteur de disquette PC ou manipulation internet pour éviter de boucher le troue ? Aucune idée. Ceci dit quand je me suis remis au retro vers 2013, le resortir et le lancer fut cool. Mais les lecteurs de disquette fut HS. Tous comme celui de ma soeur. (Le lecteur de disquette heins pas ma soeur ro !)
Un peu plus tard j'équipait le mig d'un lecteur hx mini mais c'étais dégeulasse. Et ce matin j'ai donc remis une nouvelle carte extenssion et un Gotek. Cela fonctionen bien, un peu émus d'avoir touché du joystick sur ce micro. Un petit Nicky boom pour tester ! .

Le Gotek qui équipe l'amiga 500.

La Ram Card qui ajoute 512ko de mémoire slow (fast ram ) pratique pour les jeux. Elle possède aussi un port horloge mais j'osef complètement de ce truc.

Bref ce mig est cool, elle possède une carte maman revision 6. J'ai deux autres amiga 500 à remettre en ordre et voir pour ajouter un bon lecteur hx de chez laktorek plus tard pour mon amiga 1200. J'attend aussi une ram card de chez amédia pour le 600. Bref la remise en route des amigas est lancé !!!

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.