Re: IntyBASIC, le topic officiel

[Invité]

Sympa, c'est en intybasic ? M'enfin ça va la version 2600 n'a pas de mouron à se faire

Je sais pas du tout.


Quelques exemples de jeux/démos développés en IntyBASIC:

[Invité]

L'Intellivision étant malgré tout une machine un peu limitée, je me pose des questions bizarres...  

Savez-vous s'il y a une différence entre une boucle "FOR" qui fait 10 "PRINT" à l'écran, et 10 "PRINT" écrits manuellement ? Ou alors est-ce la même chose en terme de performance/espace occupé ?

[upsilandre]

Le principe d'une boucle FOR c'est que ca prend moins de place mais plus de ressource CPU

[Invité]

C'est logique. Merci beaucoup !

[F.L]

Si je comprends bien, il ne vaut mieux pas trop optimiser son code alors
Et pensez vous que l'inty basic et la machine arrive à faire tourner un listing de 5000 lignes?

[Tryphon]

La question est de savoir quelle est la taille maximale d'une ROM ?

[upsilandre]

t'as des cartouches a 32 kilodecles (mais tu peux monter jusqu'a 42 kilodecles sans mapper). C'est de toute facon un peu plus que la Colecovision.
Ce qui est bien c'est que le port cartouche est cablé en 16bit donc tu peux metter des ROM 16bit (ou 2 ROM 8bit) soit 64Ko voir 84Ko

[Invité]

Edit: j'ai essayé de compiler une rom de plus de 16Ko avec IntyBASIC, et ça n'a pas marché. Si j'ai bien compris ce que j'ai lu sur Atari Age, il va falloir ajouter un peu de code en assembleur pour pouvoir dépasser 16Ko.

Edit #2: j'ai testé la solution proposée sur cette page: http://atariage.com/forums/topic/229830-gosub-for-intv/page-9
Ces deux petits c/c m'ont permis de compiler une rom qui dépasse les 16Ko.

[drfloyd]

16ko c'est deja bien

La solution qui permet de depasser 16ko, est ce que ca peut etre un probleme cependant pour produire ensuite une cartouche ?

[Invité]

Si j'ai bien compris les explications d'Upsilandre, une rom qui affiche 16Ko fait en réalité 8 kilodecles. Je sais pas si la solution à c/c marcherait pour une réaliser une vraie cartouche; il me semble qu'elle ne permette pas de faire de très grosses roms non plus... De toute façon, le vrai hardware m'a l'air incontournable; ça m'est arrivé d'obtenir une rom qui fonctionnait sur un émulateur et pas sur un autre (le problème fut réglé en ajoutant un WAIT )... va savoir lequel dit la vérité

[upsilandre]

Si le fichier sur ton HDD fait 16Ko c'est effectivement que la ROM doit etre de 8 Kilodecles.
Le mapping mémoire de l'intellivision est assez fragmenté notamment pour la compatibilité avec le module ECS pour transformer la console en micro. T'as effectivement une zone de 8 Kilo a l'adresse 5000$ qui sert de base pour la cartouche et si on veut aller au delà ca se complique, faut aller pioché dans divers espace mémoire éparpillé donc je comprend pourquoi il risque d'etre compliqué dans le SDK intyBasic d'utiliser plus de 8 kilo. Le fait que ca ne soit pas contigu ca revient a devoir gérer ca comme des bank (et ca complique aussi la PCB de la cartouche). Donc oui se brider a 8 Kilo semble etre préférable pour commencer.

[Invité]

8KD, ça risque d'être compliqué pour ce que j'ai en tête.  
Et j'ai du mal à imaginer Barbarian tenir dans cet espace sans faire d'énormes concessions. (même dans 17KD, ça parait difficile)

A really quick and dirty way to avoid the 8K-word (16K byte) limit is to add this to the very end of your intybasic_prologue.asm, I think:

B compiled_code_start
prologue_code_end:
ORG $C040
compiled_code_start:

and then in your intybasic_epilogue.asm, put this at the very beginning:

ORG prologue_code_end

That accomplishes two things:

1. All of the code in the prolog / epilog will get assembled in the $5xxx range.
   
2. All of your code will get assembled from $C040 - $FFFF, a 16K word (32K byte) range.
   

That gives you about 17K words (34K bytes) to work with, of which ~1K-word is the prolog/epilog code and the other 16K-words are entirely your IntyBASIC program code and data.
 
The Intellicart, CC3, JLP, LTO Flash, Bee3, Hive, and I think even Harvey's designs all will handle that map, as will jzIntv and likely most (all?) other emulators.  All that without having to put ORG directives in your .BAS file anywhere.
 
EDIT:  I tried this just now and compiled one of the demos, and it had the desired effect.  The ~1K of code that comes from the prolog/epilog remained in the $5xxx range, and the demo code got moved out to $C040 and beyond. 
 
Note:  This means you will need to provide your .CFG alongside your .BIN, or start assembling to .ROM format instead of .BIN.  That's because when you provide a .BIN without a .CFG, it has an implied memory map of $5000 - $6FFF, $D000 - $DFFF, and $F000 - $FFFF.  Anything else that isn't an exact subset requires a .CFG file.  The .ROM format includes the memory map information directly in the .ROM file itself.  (The .BIN memory map convention comes from the defacto standard, Carl Mueller Jr's INTVPC.EXE on the original Intellivision Lives! CD-ROM.)

La limite passe de 8KD à 17KD, soit "34Ko" avec cette méthode "à l'arrache". C'est plutôt simple et il y a pas de raison pour que ça pose des problèmes, n'est-ce pas ? (je t'en supplie: dis oui  )

[jthbev]

Hello !
Voilà un sujet intéressant ! Merci pour cette information !
Je vais tâcher de regarder ça de plus près...

[Invité]

J'essaye de créer un petit jeu consistant à explorer un donjon. A priori, il ne sera pas passionnant à jouer, mais je m'amuse à le programmer.
Il y a des chances que je stoppe lorsque je serai confronté à mon plafond de 17KD (pour l'instant, j'en suis à 9KD). Ou alors, ça sera peut-être l'occasion de chercher à comprendre comment faire un jeu plus gros.

Une vidéo qui montre où j'en suis:



Un jeu au tour par tour où on se déplace case par case, ça me rappelle quelque chose.  
Pas grand chose fonctionne pour l'instant... mais ça prend forme petit à petit.

jthbev: tu comptes programmer quelque chose en IntyBASIC ?

[Shaoth]

Trop bien !
Explorer un donjon n'est jamais "pas passionnant".
Continue et indiques nous quel émulateur utilisé quand tu nous proposeras la ROM 

[Invité]

Mais c'est excellent !!!
N'hésite pas à partager le code source.

[Urbinou]

impressionnant déjà !

[Invité]

Merci.

A priori, ça sera assez simpliste, d'où le "pas passionnant", mais on sait jamais... parfois, ça peut arriver de créer un truc qui fonctionne sans qu'on s'y attende !

J'ai mis la rom en pièce jointe (c'est la même chose que la vidéo, avec des bugs peut-être ). L'émulateur que j'utilise, c'est jzIntv qui est présent dans le SDK IntyBASIC, mais ça tourne correctement aussi avec Nostalgia qui est plus user friendly. Juste au cas où, il y a deux fichiers à télécharger séparément et à copier dans le dossier de l'émulateur: exec.bin et grom.bin, sinon ça ne fonctionnera pas.

Mon code est brouillon, pire que ce qu'F.L appelle le "code manouche".    
En lisant un peu le forum Atari Age, je découvre que je fais des choses à éviter (genre utiliser l'opérateur "OR"). Mais le SDK d'IntyBASIC est fourni avec des exemples de code sources parfaits pour commencer, et même pour aller plus loin. D'ailleurs, je m'y réfère régulièrement.

Fichiers joints

test.zip (6 Ko) Téléchargé 6 fois

[upsilandre]

ah oui exacte j'avais oublié cette curiosité que j'avais pourtant noté. Le CPU n'a pas d'instruction OR (mais y un XOR). Du coup faut le faire en combinant des AND et NOT. Ca doit prendre 4 opérations au lieu d'une si je ne m'abuse?
Je me demande si il existe d'autres CPU sans OR.

en tout cas tu semble tres bien partie

[Invité]

Ah oui, il y a un XOR, je vais essayer de l'utiliser.

Ca doit prendre 4 opérations au lieu d'une si je ne m'abuse?

Je crois que c'est toi qui en sait le plus ici, donc je te fais confiance.

J'avais lu cette histoire d'optimisation du code IntyBASIC dans ces deux topics:
http://atariage.com/forums/topic/281912-intybasic-question/
http://atariage.com/forums/topic/232968-intybasic-then-if-vs-and-and-performance/
Ça oblige un peu à écrire des trucs pas très lisibles...

[jthbev]

Génial Ithus !
Bonne continuation !
Pour ma part, la dernière fois que j'ai programmé c'était en assembleur à l'époque des dinosaures, mais c'est sur que je vais y jeter un œil, des fois que...

[drfloyd]

excellent ce premier essai.

la difficulté c'est de reussir a faire tenir un jeu complet/interessant dans 16 ou 17ko

[Invité]

Merci. :3

A côté du langage assembleur, IntyBASIC passerait pour un concurrent de Scratch.

Doc, je pense que tu serais capable de faire un super jeu dans 17 kilodecles, voire même dans moins d'espace, car tu sais trouver des concepts simples et qui fonctionnent !
Mais ça serait quand même chouette de pouvoir disposer d'au moins 34K... Le côté positif, c'est que c'est possible. Il faudrait que je commence à regarder ça d'un peu plus près, car je vois ma rom prendre du poids et ça commence à me faire peur.

[Shaoth]

J'avais jamais fait gaffe qu'il n'y a pas d'Asteroid sur Intellivision...
C'est maintenant le cas :


Le Doc a raison (encore, comme toujours, pléonasme, pour une fois... (rayer les mentions inutiles)), il y a plein de titre 2600 à adapter !

[vingazole]

Le CPU n'a pas d'instruction OR (mais y un XOR). Du coup faut le faire en combinant des AND et NOT. Ca doit prendre 4 opérations au lieu d'une si je ne m'abuse?

Je dirais 4 opérations en combinant des AND et des NOT et "seulement" 3 en combinant AND et XOR :

A OR B = NOT [(NOT A) AND (NOT B)]

A OR B = (A XOR B) XOR (A AND B)

Je me demande si il existe d'autres CPU sans OR.

Moi aussi, ça me semble vraiment bizarre… 

[Invité]

On dirait que la plupart des homebrews commercialisés sont des adaptations de jeux existants sur Atari 2600; ça doit répondre à une certaine demande.

A propos des opérateurs logiques voici une citation de Nanochess, qui va sans doute me servir de référence:

Currently IntyBASIC doesn't support short-circuit evaluations, so using AND and OR is heavy processor-wise.

For example, in an imaginary game:

IF enemy_x > 50 AND enemy_attack > 80 AND enemy_active THEN
END IF

Would be faster this way:

IF enemy_active THEN
   IF enemy_attack > 80 THEN
       IF enemy_x > 50 THEN
       END IF
   END IF
END IF

A part ça, je me suis aperçu qu'il y avait un exemple de rom de 42 kilodecles avec son code source dans les dossier du SDK IntyBASIC... et qu'il était simple.

[upsilandre]

Le CPU n'a pas d'instruction OR (mais y un XOR). Du coup faut le faire en combinant des AND et NOT. Ca doit prendre 4 opérations au lieu d'une si je ne m'abuse?

Je dirais 4 opérations en combinant des AND et des NOT et "seulement" 3 en combinant AND et XOR :

A OR B = NOT [(NOT A) AND (NOT B)]

A OR B = (A XOR B) XOR (A AND B)

Bien joué! C'est vrai qu'en terme de nombre d'operateur avec les XOR c'est la meilleur solution mais ca demande plus de manipulation mémoire et registre du coup a priori c'est plus couteux, passer par les AND et NOT est sans doute plus efficace.
En gros sur Intellivision une opération entre un registre et la mémoire (que ce soit arithmétique, logique ou juste un move) c'est 10 cycles, et une opération entre registre (arithmétique, logique ou move) c'est 6 cycles. Donc ca devrait etre plus couteux avec les XOR (surtout si A et B sont deja dans les registres et encore plus si on ne veut pas utiliser d'autres registres que ces 2 la).

Mais ce qui est rigolo c'est plutot de calculer a quelle point un OR serait plus lent que sur le Z80 d'une coleco ou le 6502 d'une NES. Si A et B sont dans les registres alors un OR sur Coleco est 24x plus rapide que sur Intellivision   Si A et B sont en RAM (cas beaucoup moins intéressant pour le Z80) alors le OR sur NES sera 15x plus rapide que sur l'intellivision.
Par contre sur Intellivision ca sera un OR 16bit évidement.

Je me demande si il existe d'autres CPU sans OR.

Moi aussi, ça me semble vraiment bizarre… 

Je doute qu'il y en ait d'autre, ca me parait peu probable.

A propos des opérateurs logiques voici une citation de Nanochess, qui va sans doute me servir de référence:

Currently IntyBASIC doesn't support short-circuit evaluations, so using AND and OR is heavy processor-wise.

For example, in an imaginary game:

IF enemy_x > 50 AND enemy_attack > 80 AND enemy_active THEN
END IF

Would be faster this way:

IF enemy_active THEN
   IF enemy_attack > 80 THEN
       IF enemy_x > 50 THEN
       END IF
   END IF
END IF

Les branchements conditionnels sont pas tres couteux sur les vieilles machines donc faut pas hésiter a en abuser en priorité, l'inverse de ce qu'on ferait aujourd'hui.

A part ça, je me suis aperçu qu'il y avait un exemple de rom de 42 kilodecles avec son code source dans les dossier du SDK IntyBASIC... et qu'il était simple.

A priori y a pas de raison, faut sans doute juste bien déclarer les différente zone du mapping mémoire qui sont autorisé, c'est a dire les zone qui ne se superpose pas a des adresses mémoires déjà utilisé par la machine (et ensuite ne pas dépasser ces bornes avec ton code ce qui peut être le plus chiant si c'est divisé en plusieurs banks et que le SDK ne t'avertie pas)

[Tryphon]

Y'a deux choses différentes :

* le fait que le CPU n'ait pas de OR (ou arithmétique)
* le fait que le basic compile "A or B" (ou logique) en évaluant A et B, puis en faisant le "or", alors que s'il évalue juste A et que A est vrai, c'est pas la peine de faire le B ; ça c'est assez étonnant (les compilateurs C ne font pas ça par exemple) et j'ose espérer que le dev du Basic va modifier ce comportement

Concernant les processeurs sans OR, il me semblait avoir lu que les premiers CPU n'implémentaient que le NAND ("A nand B" = "not(A) and B") parce qu'on peut récupérer tous les autres opérateurs logiques à partie de celui-ci, mais c'est des souvenirs, ça ne concernait peut-être que les portes logiques à l'intérieur du CPU...

[upsilandre]

Concernant les processeurs sans OR, il me semblait avoir lu que les premiers CPU n'implémentaient que le NAND ("A nand B" = "not(A) and B") parce qu'on peut récupérer tous les autres opérateurs logiques à partie de celui-ci, mais c'est des souvenirs, ça ne concernait peut-être que les portes logiques à l'intérieur du CPU...

Effectivement je pense que tu fais plutot allusion aux portes logiques qui composent les microprocesseurs.
Les premiers CPU y en a pas 36 non plus de toute facon et en terme d'instruction des OR j'en trouve partout, y en a dans le 8008 et le 6502 qui sont un peu ce qu'on fait de plus rudimentaire comme CPU. Y en a dans le 6800 de Motorola et le Z80. Y en a meme dans le F8 tres exotique de la Channel F (première console) ou dans le RCA 1802 de la Studio II qui est la pire machine que je connaisse.
En fait y a que dans le tout premier CPU de l'histoire, le 4004, ou je vois pas d'operateur logique a part le NOT (ce qui me parait un peu bisarre   ) mais c'est un CPU qui a été peu utilisé, remplacé rapidement par le 8008 bien plus intéressant.

[upsilandre]

Bon apparemment y a vraiment pas d'operateur logique sur le 4004 (a part le complement).
Pour faire un OR sur seulement 1bit ca donne ca

Code:

LABEL CODE OPERAND
OR, FIM IP 11 I REG 2 :::: 0, REG 3 :::: 11
Ll, LDM 0 I GET BIT OF REG 0; SET ACC = 0
XCH 0 I REG 0 DATA TO ACC; REG 0 :::: 0
RAL lIst 'OR' BIT TO CARRY
XCH 0 I SAVE SHIFTED DATA IN REG 0; ACC::::O
INC ~ I DONE IF REG 3 :::: 0
XCH 3 / REG 3 TO ACC
JCN 4 L2 I RETURN IF ACe :::: 0
XCH 3 I OTHERWISE RESTORE ACC ANDREG3
RAR I BIT OF REG .() IS ALONE IN ACC
XCH 2 I SAVE 1st 'OR' BIT IN REG 2
LDM 0 I GET BIT IN REG 1; SET ACC :::: 0
XCH 1
RAL I LEFT BIT TO GARRY
XCH 1 I SAVE SHIFTED DATA IN REG 1
RAR I 2ND 'OR' 'BIT TO ACC
ADD 2 I PRODUCE THE OR OF THE BITS.
TCN 2 L1 I JUMP IF CARRY = 1 BECAUSE 'ORi
::::l
RAL I OTHERvVISE 'OR' = LEFT BIT OF
TUN Ll I ACCUMULATOR
L2, BBL 0 I TRANSMIT TO CARRY BY RAL

[Tryphon]

Ça dure 14 minutes !