Ben a écrit : ↑11 juil. 2019 13:55
[…] Pour remplir l'écran de points, il suffit d'un fichier de 944 blocks. […]
Ben
Intéressant, 944 blocks cela fait presque 72% d'une disquette. Et encore, d'une disquette double face formatée sur un C=1571.
Parce qu'en mode C=1541, la limite c'est seulement 664 blocks par disquette.
Bon, c'est vrai qu'en utilisant un fichier séquentiel de type "texte" où les nombres sont écris avec PRINT#1, x:PRINT #1,y le DOS Commodore perd beaucoup d'espace disque en insérant pas mal d'espaces et autres séparateurs entre les nombres écrits chiffre par chiffre.
Il doit y avoir moyen de compresser cela en convertissant les nombre en chaine de caractères ( style PRINT#1,MID$(STR$(x),2)+CHR$(44)+MID$(STR$(y),2)+CHR£(13); ), en chaine de caractères codées hexadécimale, ou tout autre astuce qui devrai permettre de diviser significativement la taille du fichier séquentiel.
Le plus courts aurait été de directement enregistrer les valeurs binaires (sous forme de code ASCii) mais cela n'est pas possible à cause des zéros et autres caractères de contrôle (type CR LF, EOF, etc) qui vont nécessairement faire planter la relecture même avec un GET#1.
Pour compresser, j'aurai bien utilisé ici les instructions DEC() et HEX$() qui permettent d'enregistrer chaque couple de coordonnées (x,y) sur seulement cinq caractères :
* Pour y qui varie de 0 à 199, il suffirai d'enregistrer RIGHT$(HEX$(y),2) soit deux caractères ( "00" à "C7")
* Pour x qui varie de 0 à 319, il faut un petit peu plus d'espace disque en utilisant RIGHT$(HEX$(x),3) soit trois caractères ("000" à "13F")
L'enregistrement se fera alors avec une instruction PRINT #1,RIGHT$(HEX$(x),3)+RIGHT$(HEX$(y),2);
Il ne faut pas oublier le ; sinon, l'on va perdre un caractère par couple de coordonnées (x,y) et surtout rendre impossible la lecture avec un GET :
GET#1,x1$,x2$,x3$,y1$,y2$ : x=DEC(x1$+x2$+x3$) : y=DEC(y1$+y2$)
Sans le ; on insère un retour de ligne entre chaque codon. La relecture pourra alors se faire avec INPUT#1,xy$ : x=DEC(LEFT$(xy$,3)) : y=DEC(RIGHT$(xy$,2))
En enregistrant la petite balle de cette façon:
Code : Tout sélectionner
10 dopen#1,"data bal,s",w : if ds then stop
20 graphic 1,1:x=1:y=1:dx=1:dy=1
30 do
40 :draw 1,x,y
50 :print#1,right$(hex$(x),3)+right$(hex$(y),2);
60 :x=x+dx:if x=0 or x=319 then dx=-dx
70 :y=y+dy:if y=0 or y=199 then dy=-dy
80 loop while x or y
90 dclose#1:if ds then stop
J'obtiens un fichier de 1250 block (94% d'une disquette double face sur un C=1571 ):
Code : Tout sélectionner
diR "*=seq"
0 "cret2 " 2b 2a
1250 "data bal" seq
56 blocks free.
ready.
Ainsi qu'un écran HD moitié-allumé:
- GR1 Full Half Dot.gif (211.91 Kio) Vu 17440 fois
Qui peut être redessiné à l'aide du programme suivant :
Code : Tout sélectionner
10 dopen#1,"data bal" : if ds then stop
20 graphic 1,1
30 do
40 :get#1,x1$,x2$,x3$,y1$,y2$
50 :draw 1,dec(x1$+x2$+x3$) , dec(y1$+y2$)
60 loop until st and 64
70 dclose#1
Mais c'est bien moins rapide qu'un simple BLOAD.
Quand au second programme, je suis heureux de voir que
ben rejoint ma façon de dessiner d'un bord à l'autre au lieu de pixels par pixels.
Par contre, je ne suis pas sûr que les variables x,y , sx et sy soient nécessaires. Ni d'ailleurs le fichier séquentiel.
Les valeurs des coordonnées (x,y) aux bords de l'écran sont directement déductibles à l'aide du "reste à parcourir" car on incrémente ou décrémente à chaque fois ensemble les deux coordonnées de la même valeur.
En utilisant le principe d'une machine à état on obtient le code le plus concis et le plus rapide suivant :
Code : Tout sélectionner
0 graphic 1,1 : w=319 : h=199 : d=w-h : locate 1,1:goto 4
1 r=w-rdot(0) : draw 1 to +r,-r
2 r= rdot(1) : draw 1 to -r,-r : if rdot(0)>h goto 8
3 r= rdot(0) : draw 1 to -r,+r
4 r=h-rdot(1) : draw 1 to +r,+r : if rdot(0)<d goto 6:else 1
5 r= rdot(0) : draw 1 to -r,-r
6 r= rdot(1) : draw 1 to +r,-r : if rdot(0)<d goto 4
7 r=w-rdot(0) : draw 1 to +r,+r
8 r=h-rdot(1) : draw 1 to -r,+r : if rdot(0)>h goto 2:else 5
Qui permet de dessiner de la même façon l'écran HD half-dot ci-dessus mais en moins de 2 min (au lieu des presque 3 heures nécessaires à l'enregistrement et à la relecture du fichier séquentiel).
Un BLOAD étant toujours plus rapide.
P.S.: Je tiens à rassurer la Communauté, aucun Commodore C128 ou C=1571 réel n'a été maltraité pour réaliser cet article. Ni aucune archéo-technologie C-MOS. Tout a été émulé sur de l'Intel contemporain.