Sympa l'animation ! Tu pourrais rajouter l'eau qui monte et descend ça rendrai bien
Le plus rapide pour tester le clavier/joystick reste l'assembleur,il y a un cours dans le fanzine disk demoniak 7 qui m'a beaucoup servis.On ne peu pas accéder au clavier directement,il faut passer par le PPI et faire differentes manipulations.
Vais voir ça ;D Bon c'est surtout l'anim de l'oiseau qu'il faudrait améliorer lol. Le graphisme c'est pas trop mon truc.
Nouvelle version qui teste la manette avec le firmware. C'est assez rapide finalement. je vais ajouter des fonctions "JoyUp" "JoyDown" etc. Je verrai plus tard pour accélérer. Là c'est déjà bien. C'est pas 'prohibition" mais on se rapproche J'étais pas du tout parti pour faire ça au départ mais c'est cool. Et puis développer directement sur le CPC (enfin l'émulateur),c'est marrant.
Edit : J'ai ajouté la fonction 'FIRE' et ça marche très bien quasiment sans ralentissement (*)... Mais comme je n'aime pas tuer les oiseaux, pas de vidéo ;D Je finis par me demander où est la limite! C'est certes forcément plus lent que de l'assembleur mais tellement plus facile et suffisamment rapide pour la majorité des applications. Je vais réserver les 16ko de &4000 à &8000 pour les sprites compressés (accessibles quand l'asic est off), reste 45ko linéaires pour le code Pascal (et ASM) et sans doute pas mal de mémoire dispo dans d'autres banks mémoire (sans certitude car il faut un peu violenter le CPM, voir le reconfigurer)
(*) le seul truc gênant c'est "l'auto repeat", mais ça doit être facile à supprimer.
Les commandes SetBigSpr, MovAbsBigSpr et MovRelBigSpr permettent gérer des sprites hard ax16 par bx16 pixels en 16 couleurs parmi 4096. Par exemple on peut avoir sur le même écran :
Dans la video ci-après il y un seul sprite de 64x64 pixels. Remarquer qu'il ne représente rien puisqu'on le dessin représente la RAM. Ca pemet d'estimer la vitesse de rafraichissement. (qd même 4ko à déplacer à chaque fois...). Je publierai quand se sera stabilisé.
Je pensais avoir une manette de PS3 (en USB) mais mon fils l'a embarquée ;D Je me demande si elle est reconnue par WinAPE y compris pour la partie analogique? Ce serait top.
J'arrive bien à 'découper' mon écran en 2 à la ligne demandée, mais ce qui s'affiche en bas est de la bouillie. En fait je ne comprends pas ce qu'il faut mettre dans "screen adress of split". C'est cette partie du code que je ne comprends pas:
Code :
(...) ;; set screen address of split: ;; this address corresponds to start of &4000 ld hl,&1000
ld a,h ld (&6802),a ld a,l ld (&6803),a
Il est bien précisé que les octets sont inversés mais comment &1000 donne &4000 ? J'ai beau retourner l'adresse dans tous les sens je ne vois pas En fait ce que je voudrais c'est : dans la même plage d'adresse mémoire video (le 16 ko de &4000 à &8000 en CP/M) avoir une partie de l'écran dans un mode différent de l'autre. Par exmple si je splitte à la ligne 180, que mettre comme adresse?
Au passage si j'ai bien tout compris l'overscan doit être très simple en TP puisque la page mémoire de &4000 à &C000 est libre d'usage (quand l'ASIC est fermé). Je suis bluffé par toute la doc de qualité qu'on trouve en ligne : bravo à tous les contributeurs !
Pour le CPC+,il faut commencer par envoyer au CRTC les adresses pour la 1ere rupture,puis se servir des registres 6802&6803 pour les ruptures suivantes
Les manettes USB sont reconnues par Winape,les pads analogiques de la manette playstation sont utilisables
Merci pour vos idées... Pour les ruptures, je me suis lancé un peu trop vite dans le code avant de me documenter assez;D Je commence à comprendre un peu mieux. Je n'avais pas pris le problème dans le bon sens en confondant multi-mode et rupture... Mais c'est essayant qu'on comprend.
Là je me lance dans le fonctionnement des interruptions avec les entrées du firmware et .... pour le moment c'est la Allez, on s'accroche et on lâche rien lol. Je veux mes AFTER, ON SQ, et EVERY en Pascal ! Pour le moment j'ai ouvert ma nouvelle unité UKernel avec une première fonction GetTim (ce qu'Amstrad appelle KL_TIME_PLEASE). Mon CPC va me donner l'heure précise pendant 166 jours, soit 3977 heures ou encore 14.316.558 secondes d'après le firmware guide et au 1/300ieme de seconde svp.... Le plus dur est fait
Begin Every(200,1,Addr(FaitQuelqueChose_1)); { Toutes les secondes, lance ce pgm ASM en priorité 1} After(1000,1,Addr(FaitQuelqueChose_2)); { Au bout de 5 sec, lance ce pgm ASM en priorité 1}
Delay(1000); { Ne fait rien pendant 10 sec... et pourtant! }
KL_SyncReset; { Indispensable sinon plantage assure à terme du programme puisque le Kernel va essayer d'executer un programme qui peut ne plus être en mémoire }
End.
L'unité contient d'autres procédures que les Every et After qui sont la face immergée de l'iceberg. Les possibilités sont bien plus vastes. Le coté intéressant c'est que c'est le Kernel qui gère la mécanique des interruptions et que c'est donc transparent pour le développeur. Le firmware guide insiste sur le le fait que les "blocks" de datas qui gèrent ça doivent être dans les 32ko au centre de la RAM. Cette limitation ne semble pas exister en CP/M au moins dans 16ko en haut de la RAM.
A ce stade je ne sais pas appeler des routines en Pascal mais uniquement du code machine (external). C'est déjà très intéressant ;D. La doc semble dire que ce serait possible en Pascal mais c'est très mal documenté pour le CPM (mieux pour le MS/DOS mais çà n'aide pas). je vais regarder ça mais j'ai des doutes sur la faisabilité puisque ça revient à pouvoir appeler proprement une procédure en Pascal depuis une routine assembleur. Un simple CALL ne suffit pas, le compilateur inclut du code & data en entrée et sortie de la procédure.
Dans tous les cas, il y a des limitations facilement compréhensibles pour les programmes "non réentrants"... Par exemple si le Pascal est en train de tracer des lignes et est interrompu par un autre programme qui trace aussi des lignes, c'est le bazar assuré si on passe par le Kernel (la position du curseur graphique est unique)! Pour tout ce qui est entrée-sorti c'est même un plantage direct. Le gros intérêt du firmware c'est que les événement peuvent être gérés dans des "queues" (file d'attentes), ce qui permet de gérer (en partie) le problème de la "réentrance". En gros il faut juste s'assurer pour les programmes non réentrants qu'il n'y a pas de conflit entre programme principal et les "événements". Le système de Queue (que le firmware définit comme 'synchrone', ce que je trouve un peu bizarre, c'est plutot asynchrone dans ma façon de voir, un peu comme des "batchs" ) permet d'éviter qu'un programme non réeentrant soit "auto-interrompu" et ceci sans avoir besoin de bloquer les interruptions.
Feuille de route pour la suite avant de faire un .DSK v0.2 : - Toiletter les unités, finaliser les noms de commandes - USprite devient UAsic avec l'ajout d'autres fonctionnalités de l'ASIC CPC+ - UKernel, finaliser la gestion des événements via des externals... Gérer les "blocks" d'événement via des pointeurs plutôt qu'en mémoire statique, "stresser" tout ça pour cerner les limites...
Pour la suite et la cible v1.0 : - USprite pour la gestion des sprites hors ASIC - UKernel : Gestion des événements par procedures Pascal interne (si faisable facilement) - Routines graphiques rapides sans passer par le firmware (plot, line ...) et optimisation d'une police vectorielle (trop lent avec le firmware).
Puis, j'ai quelques idées de de dev jeu (plutôt jeux de réflexion graphique, le TP s'y prête très bien) avec des anim. Pour le jeu d'aventure, ma vague idée de scénario se précise un peu mais c'est pas pour tout de suite.
Concernant les bugs, je n'en ai repéré qu'un seul à ce stade mais un peu gênant : Le scrolling ne se fait pas correctement avec "Write" dans les fenêtres de textes (les "windows" du Basic CPC). Il semble y avoir un conflit entre le firmware et Pascal/Cpm dans ce cas. Visiblement la commande write force un saut de ligne au bout de 80 caractères avec un GOTOXY à la ligne du dessous. Dans une fenêtre de moins de 80col, ça donne des scrolls et mouvements de curseurs intempestifs. Ca doit pouvoir se résoudre via le vecteur d'affichage Turbo Pascal (permet de rerouter la commande write)...
Plus j'utilise Turbo Pascal 3, plus j'aime cet environnement! Même l'éditeur en mode accéléré sur WinAPE se révèle excellent. Je me suis aperçu en plus que toutes les séquences de touches sont reprogrammables (il y en a 45!) ... Copie de bloc, recherche, remplacement, avance par mot, par ligne, début, fin etc ...
Par contre sur certain aspects le TP3 affiche bien ses 35 ans! En particulier il n'a pas d'ASM intégré comme les versions suivantes mais simplement une commande "inline" qui a le mérite d'exister mais coder en hexadécimal euh... même si j'aime bien les vieux trucs là il y a des limites ;D
L'utilitaire suivant règle le problème et rend tout très simple. Il génère automatiquement les séquences InLine(.....) avec WinApe (ou un autre émulateur, ou même sous CPM si l'envie vous prend). Mais avec WinAPE c'est top : assembler votre code avec WinApe , tester l'articulation avec le Turbo Pascal et quand tout çà fonctionne bien, intégrer l'ASM comme suit :
1. Vous êtes dans l'éditeur du Turbo Pascal pour finaliser votre programme super génial... et votre code ASM coté WInAPE 2. Faire Ctrl K D pour sortir du source (j'ai changé par Ctr Q pour ma part et tout le reste d'ailleurs) 3. Taper X (lancer une commande eXterne dans TP), puis INLINE $AdresseDébut, $AdresseFin (ou en décimal si vous préférez). Ca génère la séquence Inline (de 10ko ou même plus si vous voulez) dans le fichier ASM.PAS 4. Taper E pour revenir dans l'éditeur et placez-vous à l'endroit où voulez insérer la séquence Inline 5. Ctrl K R (read block from disk) puis taper Asm
et le tour est joué. C'est plus long à expliquer qu'à faire. Vous pouvez désormais intégrer des fichiers ASM même de plusieurs Ko en Pascal en qqes secondes.
Le source :
Code :
Program Asm2Hex;
Type Str80=String[80];
Var i,Debut,Fin,Err:Integer; Asm,Hex:Str80; VFile:Text;
Function Int2Hex(i:Byte): Str80; Begin Hex:='0123456789abcdef'; Int2Hex:=Concat('$',Hex[i div 16+1],Hex[i mod 16+1],'/'); End;
Procedure DoErr; Begin WriteLn('Inline genere le code InLine dans le fichier asm.pas'); WriteLn('Usage : INLINE $AdrMemDebut $AdrMemFin'); Halt; End;
Begin Val(ParamStr(1),Debut,Err); If Err<>0 Then DoErr; Val(ParamStr(2),Fin,Err); If Err<>0 Then DoErr; Assign(VFile,'b:asm.pas'); Rewrite(VFile); Asm:='Inline('; For i:=Debut To Fin Do Begin Asm:=Concat(Asm,Int2Hex(Mem[i])); If Length(Asm)>60 Then Begin WriteLn(VFile,Asm); Asm:=' '; End; End; Asm:=Concat(Asm,');');WriteLn(VFile,Asm); Close(VFile); WriteLn('OK! Inline cree :',Debut,'->',Fin); End.
Finalement j'ai du mal à suivre ma feuille de route tellement les possibilités sont grandes avec le combo TP/CPC/CPM ;D Jusque maintenant j'ai été très surpris des possibilités/rapidité/facilité d'usage. Je ne pensais pas que ce serait aussi fertile. J'ai trouvé un nom pour mon projet d'unités : TP-TOOLS. Clin d'oeil que certains reconnaitront ;D Vais essayé de publier un TP-TOOLS v0.2 ce we de confinement...
Par contre ma première déception, il fallait bien que ça arrive : J'ai démarré une unité UCrt pour gérer le 6845 (je l'avais oublié celui-là). C'est très facile et l'utilitaire InLine aide bien. J'étais très optimiste sur une gestion simple de l'overscan car le code généré par TP peut utiliser 61Ko en ligne et que les adresse entre &4000 et &C000 sont dispo. Voilà 32ko parfait pour l'Overscan !! Oui mais mais je tombe sur un problème qui m'avait échappé : "It is not possible to locate the screen in blocks 4..7 "... Et la zone intéressante en CP/M est sur les blocks 5 et 6. Bref ma méthode qui aurait été tellement simple ne fonctionne pas :/
Il y a peut-être une autre solution mais plus complexe : c'est d'utiliser les blocks 1 et 2 ou 2 et 3 placé de &4000 à &c000 (organisation mémoire 1 ou 3) . Ca ne fonctionne pas nativement car ça rentre en conflit avec la configuration CP/M Plus du CPC. Je suis quasiment persuadé qu'il est possible de générer un configuration de CP/M qui libère ces emplacements mémoire mais je n'ai pas trouvé de documentation précise sur le net. Faudrait trouver un expert CPM ;D D'après la doc, le CP/M le v3 dans sa version "banked" peut tenir dans 16ko soit 12 Ko en bas de la Bank 0 + 2.25Ko en bank "common" (tout en haut de la bank 7 sur CPC)... le reste semble être des buffers que le CPM+ s'approprie pour booster les perfs et la "directory hash table", gestion des disques jusque 512Mo (!)... Mais cela ne serait pas obligatoire en sacrifiant les perfs des accès disque (on est loin des 512Mo avec 2 drive 3" lol) . Ca explique que les acces disques me semblent plus rapide en CPM3 qu'en AMSDOS et la performance des acces sequentiel indexé (lire l'enregistrement xxx d'une bdd). Mais la doc dit qu'il est possible de changer çà avec l'utilitaire GENCPM. Il suffirait alrs de générer une version "minimaliste" de CPM3...
Si ça marche ca permettrait d'avoir une config CPM avec 112Ko dispos : = 61Ko de mémoire linéaire accessible directement (TPA) + 16 Ko Video + 35ko de ram banked libre ou = 61ko mémoire user (TPA) + 32ko pour la vidéo à partir &4000 + 19ko de ram banked libre
Dans les 61Ko de TPA (terminologie du CPM pour dire mémoire utilisateur ou on fait ce qu'on veut), ca peut être du Turbo Pascal, de l'ASM ou du C compilé... Le CPM gérerait lui le switch des banks mémoire, les vecteur, les accès aux firmware etc...
Beaucoup d'hypothèse ici, mais vais essayer de trouver un peu de temps pour ça... Même si il n'y a que 10% de chance que ca marche ça veut le coup je trouve.
Non, mais j'aime beaucoup ;D Avec un 464 en plus... Mais là j'arrête pas au boulot et les nuits sont trop courtes... Vais jeter un oeil sur l'outil de dev. Et bizarrement le fait de dév directement avec un outil de l'époque me plait assez, même si l'émulateur facilite bien les choses pour la vitesse de compil.
Du CPC, du CP/M+ et du Turbo Pascal commenté... Surtout du CP/M+ d'ailleurs, un OS que je ne connaissais pas en fait et finalement très sympa pour l'époque. Cet environnement Amstrad CPC/CPM/Pascal me plait de plus en plus ;D Manque juste du temps ! Quoique... la vidéo fait quand même une heure comme quoi le temps c'est relatif
J'ai finalisé un DSK de la v0.2 de TPTools. Elle contient les sources de toutes les unités (*.inc), des sources exemples (*.pas) et des executables (.com). C'est une version encore partielle mais qui fonctionne. Une v1 suivra un jour ou l'autre ;D je ne sais pas où publier ça. ce serait bien dans la rubrique "★ CODING ★ CP/M ★" non ?
Voilà la description intégrée dans le fichier READ-ME.TXT de la disquette :
Code :
TP-TOOLS v0.2 By Nemo (2020) ============================
1. Introduction ---------------
Cette version 0.2 et sa documentation associee sont provisoires. L'objectif est une v1.0 qui sera completee avec d'autres procedures et unites.
TP-Tools (Turbo Pascal Tools) est une bibliotheque d'unites thematiques pour developper en Turbo Pascal v3 (Borland) sous CPM+ (Digital Research) avec les ordinateurs Amstrad CPC6128 et CPC6128+.
TP-Tools v0.2 est organise en 4 unites :
- UGraph.inc : Gestion des graphismes - USound.inc : Gestion du son - UKBoard.inc: Gestion clavier/Joystick - UAsic.inc : Gestion de l'Asic du CPC+
D'autres unites seront ajoutes en v1 (UCrt, USprite ...)
2. Convention de nommage ------------------------
Les procedures et fonctions sont generalement nommees par groupe de 3 lettres representant des mots anglais comme suit :
a/ Les trois premieres lettres correspondent a un verbe :
Set : Get : Dsp : Display (Affiche) Hid : Hide (cache) Ini : Initialize Drw : Draw (Trace) Mov : Move (Deplace) Rmv : Remove (Enleve) Enc : Encode Tst : Test Dlk : Delock Opn : Open Clo : Close Spl : Split
b/ Les groupes de trois lettres suivantes correspondent a des mots :
Txt : Text Cur : Cursor Pap : Paper Pen : Pen (Stylo) Gra : Graphic Ink : Ink (encre) Bdr : Border Scr : Screen Ver : Vertical Hor : Horizontal Adr : Address (Adresse) Abs : Absolute Scr : Screen Org : Origin Rel : Relative Pnt : Point Msk : Mask Lin : Line Rec : Rectangle Mod : Mode Pal : Palette Win : Windows Env : Enveloppe Vol : Volume Ton : Tone Chn : Channel Snd : Sound Chr : Char Key : Hlt : Halt JoyA: JoystickA JoyB: JoyStickB Asic: Spr : Sprite Evr : Every Aft : After
Par exemple, HidTxtCur : Hide Text Cursor
3. Description rapide des unites --------------------------------
Attention : le TP3 ne gere pas les unites (UNIT / USE) au sens des versions ulterieures de Turbo Pascal. Ce qu'on appelle ici "unites" sont en fait des bibliotheques de type "include" qui sont recompiles a chaque fois qu'elles sont utilisees (voir la doc de TP3 facilement trouvable en ligne)
a/ UGraph.inc
Cette unite reprend essentiellement les fonctions du firmware des Amstrad CPC. Tout cela est tres bien documente dans le "Firmware guide...
Contrairement C l'AMSDOS, la memoire video sous CPM+ est placee a l'adresse &4000. De plus elle se trouve dans la configuration memoire c1, alors que le TPA (la zone ou le Turbo Pascal fonctionne) est en configuration memoire c2. Noter que dans le CPM+ la configuration memoire c1 est appelle Bank 0 et la la configuration memoire c2 est appelee Bank 1.
Il n'y pas grand chose a ajouter. Soyez cependant vigilant sur un point : certaines procedures ou fonctions utilisent les coordonnees graphique de type (600x400), d'autre des coordonnees physique qui dependent de mode graphique en cours. Cf Firmware
Cette unite integre aussi une prodecure permettant de copier des blocs memoire entre les "banks memoire" du CPM+
b/ Usound.inc
Cette unite aussi reprend les fonctions du firmware. Elles sont tres puissantes (voir les exemples) mais egalement un peu compliquees a comprendre et utiliser. Un utilitaire devrait etre prochainement disponible pour creer des sons et produire le code Pascal associe
c/ UKBoard.inc
Le firmware toujours et encore ...
d/ UAsic.inc
ATTENTION : Cette unite ne fonctionne qu'avec un CPC+ ! L'utiliser sur un CPC "old" entrainera un plantage direct. Cette unite permet de gerer tres facilement les specificite du CPC+ et en particulier la gestion des sprites Hard. Elle sera completee ulterieurement pour la gestion des scrolls horizontaux et verticaux.
Quand vous utilisez cette unite gardez bien en tete que entre les instructions OpnAsic (open Asic) et CloAsic (CloAsic), la memoire entre les adresses &4000 et &7fff est celle de l'ASIC et qu'elle remplace la memoire de la Bank 1... Cela peut poser des probemes. La facon la plus simple de les contourner de compiler le code Pascal au dessus l'adresse &8000 (Touche "S" dans les options de compilation), ou en dessous de &4000 (Touche "E" dans les options de compilation) Il y a d'autres facon plus subtiles de faire pour mieux utiliser la memoire mais elles sont plus complexes. Vous pouvez par exemple utiliser cette zone pour stocker des datas avec la commande ABSOLUTE du TP mais charge a vous de n'y acceder que quand cette zone memoire est "visible". Il n'est pas non plus impossible d'y stocker du code Pascal mais il faut verifier l'adresse des procedures et fonctions (Addr(procedure)), et ne pas y acceder si elles sont pour tout ou partie entre &4000 et &8000 quand l'Asic est "ouvert".
4. Utilitaire -------------
Le programme Inline (ecrit Pascal), permet de generer un fichier pour integrer des structures inline dans un source Pascal. Taper Inline en CP/M pour aficher la syntaxe.
Un utilitaire pour "dessiner" et combiner des sons devrait être dispo par la suite
Un utilitaire pour optimiser et réduire la taille du code doit suivre aussi. En effet contrairement au TP4 et suivant le TP3 n'a pas d'optimiseur integre. Une procedure décrite dans une bibliotheque sera dans le .com final même si elle n'est pas utilisee. On peu gerer ca a la main, mais autant l'automatiser. Soyons intelligemment faineant ;D
5. Tutoriel video -----------------
Vous pouvez trouver des tutoriels video sur YouTube et des explications dans le forum de https://CPCRulez.fr
Voila voila en attendant la v1 ;D
Dernière édition par Nemo59 le 21 Déc 2020, 19:34, édité 6 fois.
Inscription : 20 Août 2007, 18:21 Message(s) : 4998
Nemo59 a écrit :
Hello!
J'ai finalisé un DSK de la v0.2 de TPTools. Elle contient les sources de toutes les unités (*.inc), des sources exemples (*.pas) et des executables (.com). C'est une version encore partielle mais qui fonctionne. Une v1 suivra un jour ou l'autre ;D je ne sais pas où publier ça. ce serait bien dans la rubrique "★ CODING ★ CP/M ★" non ?
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 3 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum