[SHARP MZ-700] BRICK BUSTER

[hlide]

Après m'être essayé à convertir un petit casse-brique écrit en BASIC limité à 10 lignes, j'ai décidé de voir plus grand surtout quand j'ai vu ce qui se pouvait se faire avec un ZX81.

Entièrement écrit en assembleur, ce jeu représente une variante de casse-brique dont mon objectif est d'aller aussi loin que possible dans sa réalisation. J'ai plein d'idée mais je ne vais pas les présenter pour le moment. Ce poste fera part de la progression.

Sachez que j'ai quand même prévu d'améliorer la gestion de la balle avec 16 directions au lieu des 4 diagonales et des briques en 1x3 caractères plutôt qu'un qui seront plus variés en dessin et en effet.

Les contraintes de cette machine font que l'on ne peut accéder à la VRAM (caractère et couleur) que lors du signal /HBNK = 0 (soit une période de 62 µs) pour chaque ligne. Sinon le CPU est mis en attente jusqu'au prochain HSYNC= 0. Il faut donc exécuter des petits bouts de code de dessin entre des bouts de code de logique du jeu pour permettre au CPU de travailler au maximum.

En attendant, voici quelques images (attention GIF à 25 FPS au lieu de 50 FPS d'origine) :

bb-intro.gif (143.5 Kio) Consulté 4713 fois

Une introduction expliquant les touches : curseur gauche/droit pour déplacer la raquette; F1, F2 et F3 pour changer le type de raquette; SPACE pour tirer la balle ou un missile pour certaines raquettes; BREAK pour faire pause.

bb-ready.gif (337.21 Kio) Consulté 4713 fois

A vos marques... prêts... partez !

bb-game.gif (1.16 Mio) Consulté 4713 fois

Balle trop rapide pour la raquette, il faudra la ralentir et améliorer son déplacement au demi-caractère. Le design et les fonctions des briques sont toujours en réflexion surtout qu'il est prévu pour la suite d'avoir jusqu'à 100 niveaux donc 100 arrangements de briques sur une surface de de 10x10 (une brique fera 3 caractères) ou plus en nombre de ligne.

Note : j'ai ajouté un effet de "glow" sur la raquette pour voir ce que ça donne. Le GIF rend très mal justice car on peut obtenir des couleurs pâles pas trop mal avec certaines combinaisons de couleurs. Cependant je pense utiliser ces effets lors des rebonds.

[Papy.G]

Tu ne peux pas accéder à la VRam pendant VBNK?

[Markerror]

Jolie page de présentation ! Par contre, les briques à casser méritent effectivement d'être moins basiques pour qu'on que chacune soit distinguable.
Ca pourrait faire aussi l'objet d'une adaptation VG5000, qui sait .

Bon courage pour ce projet prometteur !

[hlide]

@Papy.G

Je ne pense pas. Le LSI (l'ASIC qui est responsable du décodage des adresse et de la génération vidéo) émet un signal BLNK qui est à quelque chose près le signal inversé de /HBLNK et ce signal BLNK est attaché au signal /WAIT du CPU. D'autre part, ce signal BLNK alimente également le port CLK1 du 8253 et le OUT1 alimente le CLK2. L'OUT2 est connecté au /INT pour générer une interruption par seconde par défaut. De fait, j'imagine assez mal comment le /VBLNK peut intervenir ici - en tout cas la doc ne fait pas mention d'usage du /VBLNK dans ce signal.

@Markerror

Quand j'aurais avancé un peu, le source sera disponible. Cependant, il faut comprendre que je fais en sorte de me plier aux contraintes du MZ-700 qui n'auront certainement pas lieux avec le VG5000 et puis j'appréhende l'aspect vidéo de ce dernier.

[Papy.G]

HBlnk ne doit normalement pas avoir lieu pendant le balnking vertical, et le générateur vidéo ne devrait pas avoir besoin d'accéder à la VRam pendant ce temps.
Il y a peut-être un autre moyen de définir qu'on est en VBLANK, dès l'absence de HBLNK pendant un certain temps? Ou en comptant les lignes.

[hlide]

Le LSU génère BLNK, /HBLNK et /VBLNK indépendemment. Je pense plus probable que BLNK est une pulsation périodique calée sur /HSYNC, sinon je ne vois pas comment ce signal peut être utilisé pour générer une interruption par seconde. Il n'y a pas d'autre moyen : LSI.BLNK -> Z80./WAIT. Donc il faut dessiner jusqu'à 11 caractères par ligne (ligne pixel, pas caractère) pour pouvoir exécuter du code logique entre les BLNK.

[hlide]

Après je serais heureux que /VBLNK = 0 puisse influencer sur BLNK mais j'ai des gros doutes à cause du timer 1 qui se fournit avec ce même signal. Il faudra que je capture ces signaux un de ces jours.

[hlide]

Je peux savoir si /HBLNK et /VBLNK sont actifs. Je le fais d'ailleurs avec /VBLNK pour me caler sur les frames. Pour le /HBLNK, pas besoin : le premier accès à la VRAM va se synchroniser sur BLNK (soit indirectement sur /HSYNC).

[Markerror]

Quand j'aurais avancé un peu, le source sera disponible. Cependant, il faut comprendre que je fais en sorte de me plier aux contraintes du MZ-700 qui n'auront certainement pas lieux avec le VG5000 et puis j'appréhende l'aspect vidéo de ce dernier.

Il me semble qu'il y a un Z80 dans les MZ non ? La seule vrai différence, ça sera effectivement la partie graphique, mais comme la machine semble avoir un mode vidéo "caractères", l'adaptation ne doit pas être très complexe. Bref, commente bien ton source, si tu n'es pas partant pour faire une version VG5000, ça pourrait peut-être m'intéresser .

[hlide]

Oui c'est du Z80. D'autre part, j'adorerais intégrer le player MZ-700 du Arkos Tracker 2 (https://www.julien-nevo.com/arkostracker/) pour ajouter de la musique ou du son bien que je ne sois pas du tout un spécialiste en matière de son et de la musique : une option improbable mais géniale si c'était faisable. Donc il y aura sans doute beaucoup de boulot mais pas de soucis si quelqu'un veut le porter sur un autre Z80, je serais là pour apporter des explications voire y participer sous forme collégiale.

[Markerror]

Arkos tracker 2, je connais un peu, j'ai bricolé le player principal sur le VG5000 pour Soundsheep 1 . S'il y a un portage MZ qui existe déjà, ça doit pas être super compliqué de jouer des musiques et des bruitages avec. Il bouffe un peu de place mémoire, mais ça reste raisonnable et apparemment, il y a 64ko de ram sur le MZ-700, ça devrait gentiment tenir .

[hlide]

Plutôt 48 Ko accessibles immédiatement, 4 Ko à la place de la ROM monitor qui ne serait pas impossible de prendre en DRAM car en dehors de la routine du clavier (usage temporaire je pense car perfectible) je n'en ai pas un usage et 12 Ko non accessibles en permanence car en conflit avec la VRAM et les adresses mémoire E/S (clavier, VBL, son, etc.). Ça semble quand même assez confortable en dehors du besoin de l'Arkos Tracker 2.

[hlide]

Bon je me tourne vers la balle : j'aimerais fluidifier son mouvement au niveau du demi-caractère. Normalement le mouvement de la raquette est double de la balle, ce qui veut que j'ai quelque chose de ce genre actuellement : attendre VBLK, bouger raquette, dessiner raquette, bouger balle, dessiner balle, attendre VBLK, bouger raquette, dessiner raquette, reboucler. Si je peux dessiner la balle à la demi-caractère avec, disons, un déplacement de 0,5 au lieu de 1, je devrais pouvoir avoir une boucle qui bouge et dessine à la fois raquette et la balle mais conserver la vitesse de la balle diminuée de moitié par rapport à la raquette (dessinée et bougée à un caractère près) et qui sait, rendre plus fluide le mouvement de la balle à l'écran.

Voici une image pour illustrer mon propos :

BB-BALL.jpg (159.72 Kio) Consulté 4797 fois

Les couleurs des balles dans chaque carré vert de 3x3 caractères (avec grille en bleu) désignent le nombre de caractère qu'il faut pour dessiner la balle.
- Lorsque les positions X et Y de la balle sont entières, on n'a qu'un seul caractère pour représenter la balle que l'on peut avoir pleine ou creuse (creuse dans l'image).
- Lorsqu'une et seulement une des positions X ou Y est entière, alors on a deux caractères pour représenter la balle qui ne peut être que pleine.
- Lorsque aucune des positions X et Y n'est entière, alors on a quatre caractères pour représenter la balle qui ne peut être que creuse.

Initialement je ne prévoyais pas les quatre caractères mais je me suis dit que si je faisais en sorte que la balle à un caractère pourrait être pleine ou creuse en fonction de sa direction de façon à pouvoir alterner à chaque mouvement quelque soit la direction : les axes x et y ou diagonales 22° ou 67° à l'un des axes, balle mono-caractère creuse à cause de la suivante sur deux caractères toujours pleine; diagonales 45° à l'un des axes, balle mono-caractère pleine à cause de la suivante sur quatre caractères toujours creuses. Aucune idée si ça rendra bien, ce devrait être le prochain développement pour le weekend à venir.

Notez que le trait vert d'une grille en direction d'une autre grille indique le déplacement pour obtenir la nouvelle position.

[hlide]

Concernant cette histoire de ne pouvoir dessiner que durant le BLNK à 1, j'ai regardé les temps donnés par la documentation pour du PAL je crois. Une période /HBLNK est de 64,05603 µs. Sa durée active est : 64,05603 µs - 36,088 µs, soit 27,96803 µs. Purée on est pas loin de la moitié là... La durée du BLNK est celle de /HBLNK auquel il faut retrancher 2,16508µs, ce qui donne 25,80295 µs quand il est actif et 38,25308 µs quand il n'est pas actif. Donc je dois revoir une partie de mon code.

Nombre maximum de cycles pour le dessin sans bloquer le CPU (3,546875 MHz): 91 cycles sur 227 cycles par ligne. Il reste donc 136 cycles hors dessin. Ce n'est pas beaucoup en effet donc il faudrait surtout l'utiliser pour préparer le dessin suivant, pas pour de la logique. Le maximum de caractères (contigus) par ligne serait de 14 via cette séquence de 85 cycles :

Code : Tout sélectionner

PUSH HL
PUSH DE
PUSH BC
PUSH IX
EXX
PUSH HL
PUSH DE
PUSH BC

Le signal /VBLNK a une durée de 19.985 ms, ça donne logiquement 311 lignes, soit 4354 caractères (il en faut 1000 pour l'écran) donc théoriquement il serait possible d'afficher un écran complet (1000 caractères, 1000 couleurs) par frame.

[hlide]

L'émulateur EmuZ-700 que j'utilise pour mettre au point le jeu est une version japonaise qui affiche du NTSC, donc du 60 Hz (60 FPS en titre) et non du 50 Hz (50 FPS en titre). Il émule bien le signal BLANK mais avec les timings du NTSC. Fort heureusement, le source est commun avec l'émulation des machines MZ-800 (PAL) et MZ-1500 (NTSC). J'ai donc pu vérifier que les cycles que j'avais calculés sont bons et faire une version EmuZ-700 PAL.

Avantage PAL : 92 cycles maximum en continue sur 228 cycles (par ligne) peuvent accéder à la VRAM. Le NTSC n'en permet que 60 cycles.
Avantage NTSC : le cycle CPU est plus rapide et le nombre de frames par secondes permet un jeu plus (trop) rapide tant que l'on peut encore écrire dans la VRAM en un seul frame.

Ceci dit, le jeu a besoin d'une CGROM européenne, donc je ne vais pas trop me préoccuper pour la version NTSC.