recherche de la génèse de Sorcery et Vampire sur Thomson

Tout ce qui concerne le logiciel original et sa sauvegarde avec entre autre la régénération des disquettes ou autres supports physiques.

Modérateurs : Papy.G, fneck, Carl

nouvelhermes
Messages : 401
Inscription : 22 juil. 2020 20:56

recherche de la génèse de Sorcery et Vampire sur Thomson

Message par nouvelhermes »

Bonjour, cela fait suite à un post qui a été déplacé vers la poubelle. (Dommage, il y a des infos intéressantes dedans, même s'il est mal nommé).

Je sais que je vais avoir des remarques de la part de spécialistes Thomson, mais tout le monde n'est pas expert en Thomson.

La raison du post est de voir comment les éditeurs ont géré à l'époque les différences de comportement entre TO et MO. Il ne s'agit absolument pas de prouver que la conversion est aisée ni même possible (les spécialistes de R-Type vont me tomber dessus).

Donc j'ai commencé le désassemblage de Vampire puis de Sorcery (les deux programmes se ressemblent beaucoup).
t
Les différences entre les deux versions (des programmes cela s'entend) ne sont pas si nombreuses, en voici la liste :
- La MEM utilisateur commence à $6100 pour TO, $2100 pour MO.
- Quelques variables du moniteur (principalement pour le son), et les variables systèmes (pour l'écran et la lecture des manettes)
- Les appels moniteurs au nombre de quatre : PUTC, GETC, KTST, NOTE (les manettes soturent lues directement sans faire appel au moniteur).
- Le plus important (dans ces programmes), mais auquel on pense le moins, la gestion de la partie couleur de la mémoire écran.

Pour le reste, les versions MO et TO se ressemblent beaucoup, il doit peut être y avoir quelques substilités de ci de là (c'est ce que j'appelle la différence entre "en gros" et "dans le détail").

Maintenant quelques remarques :
PUTC n'est utilisé que pour peindre l'écran en noir et l'effacer, mais n'est utilisé pour écrire du texte.
Toutes les écritures à destination de la mémoire écran directement sans passer par un quelconque appel du moniteur.
On remarquera dans les deux programmes, le même système de gestion de tuiles (unicolores pour du 16x16 pixels). On peut considérer que l'on a un véritable moteur de jeux vidéo.

Je fournis le début du désassemblage au cas où cela intéresserait quelqu'un (version ida pro 5.2)

Maintenant quelques questions :
Les deux programmes sont très similaires, est-ce que quelqu'un sait si c'est bien la même équipe qui a écrit les deux programmes, ou l'un des deux été acheté, et dans quel ordre ont été écrit les programmes ?

Les deux programmes sont très similaires, y compris dans le programme objet (de très nombreuses fonctions identiques, et programme principal très similaires), donc l'un des deux est quasi certainement le dérivé de l'autre.
Pièces jointes
des.zip
(258.29 Kio) Téléchargé 37 fois
Dernière modification par nouvelhermes le 29 mars 2023 22:38, modifié 2 fois.
Ythunder
Messages : 928
Inscription : 21 août 2019 10:12

Re: différences entre MO et TO : étude de cas

Message par Ythunder »

Ce qui m'intrigue, c'est que ce ne sont pas les mêmes éditeurs, Virgin Games d'un côté, et Infogrames de l'autre.
Le même moteur de jeu, dans ces années là entre 2 éditeurs n'ayant visiblement pas de liens, je trouve ça bizarre, mais ce n'est qu'un avis.
nouvelhermes
Messages : 401
Inscription : 22 juil. 2020 20:56

Re: différences entre MO et TO : étude de cas

Message par nouvelhermes »

Quand on désassemble les deux programmes, on trouve énormément de similitudes, trop pour que les deux programmes ne soit totalement indépendants.

Par exemple : les deux programmes ont le même point d'entrée ($2143 pour MO, $6143 pour TO).

Attention : il ne s'agit pas de Virgin mais de FIL, mais en fait on retrouve plus des méthodes de Infogrames dans le LOADER (à ma connaissance, FIL a très peu employé le procédé), la page de présentation est beaucoup plus élaborée que le standard FIL (une simple page grise avec le nom du jeu dessus), la définition d'une nouvelle pile (FIL s'est souvent contenté de la pile définie par le BASIC), etc... me font penser FIL a dû récupérer les routines chez Infogrames, mais là il ne s'agit que d'une suposition, je laisse parler les spécialistes.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: différences entre MO et TO : étude de cas

Message par __sam__ »

Pour le reste, les versions MO et TO se ressemblent beaucoup
Oui, le gros du code c'est de l'asm 6809 :)

A noter:
Dernière modification par __sam__ le 29 mars 2023 16:40, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Ythunder
Messages : 928
Inscription : 21 août 2019 10:12

Re: différences entre MO et TO : étude de cas

Message par Ythunder »

Sorcery FIL ?
Pour moi c'était Virgin (boite noire plutot carré, différente comme TNT par exemple)
J'ai regardé avant de poster sur le site DCMOTO : Virgin
Y a -il une subilité qui m'a échappé depuis 1986 ?

On a peut être les auteurs dans Sorcery, mais il faudrait lancer le jeu.
EDIT : Sam a donc répondu juste avant avec d'ailleurs une excellente réponse, Vampire est un jeu original Thomson et Sorcery un portage.
Mais qu'estce qui t'as fait penser que le jeu avait été édité par FIL ? Parce que les boites FIL quand même, ça n'a rien à voir (j'adore ces boites !)
nouvelhermes
Messages : 401
Inscription : 22 juil. 2020 20:56

Re: différences entre MO et TO : étude de cas

Message par nouvelhermes »

On est tout à fait d'accord qu'il s'agit de l'ASM 6809, mais s'il n'y avait aucun lien, tu crois que les "tuiles" seraient dessinées de la même façon, que la gestion du temps se ferait de la même façon (écriture directe en MEM video), que la gestion du score se ferait de la même façon, que la fin serait détectée exactement de la même manière, et en rentrant encore plus dans les dtétails après désassemblage, le moteur du jeu est quasiment identique.

Un exemple parmi d'autres :

Tu pense qui s'il n'y a avait strictement aucun lien en regardant les sous-programmes suivants :

Sorcery MO5

ROM:344E init_lieu: ; CODE XREF: ROM:2235P
ROM:344E ldx #$5AF0
ROM:3451
ROM:3451 loc_3451: ; CODE XREF: init_lieu+8j
ROM:3451 clr ,x+
ROM:3453 cmpx #$5B28
ROM:3456 bcs loc_3451
ROM:3458 jsr sub_3134
ROM:345B ldu #$5AFE
ROM:345E exg x, u
ROM:3460 jsr sub_34CB
ROM:3463 lda 3,u
ROM:3465 sta 9,x
ROM:3467 leau 4,u
ROM:3469 leax $E,x
ROM:346B jsr sub_34CB
ROM:346E lda 3,u
ROM:3470 sta 9,x
ROM:3472 leax $E,x
ROM:3474 lda no_lieu
ROM:3477 ldu #$4AD7
ROM:347A ldb #8
ROM:347C
ROM:347C loc_347C: ; CODE XREF: init_lieu+43j
ROM:347C cmpa ,u
ROM:347E bne loc_348E
ROM:3480 lda #7
ROM:3482 sta ,x
ROM:3484 ldd 1,u
ROM:3486 std 1,x
ROM:3488 lda 3,u
ROM:348A sta 9,x
ROM:348C bra loc_3493
ROM:348E ; ---------------------------------------------------------------------------
ROM:348E
ROM:348E loc_348E: ; CODE XREF: init_lieu+30j
ROM:348E leau 4,u
ROM:3490 decb
ROM:3491 bne loc_347C
ROM:3493
ROM:3493 loc_3493: ; CODE XREF: init_lieu+3Ej
ROM:3493 jsr sub_266B
ROM:3496 ldu adr_ecran
ROM:3499 ldb 3,u
ROM:349B andb #$F
ROM:349D aslb
ROM:349E aslb
ROM:349F abx
ROM:34A0 stx adr_ecran
ROM:34A3 lda ,x
ROM:34A5 cmpa #$C
ROM:34A7 bcc loc_34C0
ROM:34A9 inca
ROM:34AA
ROM:34AA loc_34AA: ; CODE XREF: init_lieu+73j
ROM:34AA asla
ROM:34AB asla
ROM:34AC sta unk_5AF1
ROM:34AF lda 1,x
ROM:34B1 asla
ROM:34B2 asla
ROM:34B3 asla
ROM:34B4 asla
ROM:34B5 suba #8
ROM:34B7 sta no_tuile
ROM:34BA lda #1
ROM:34BC sta en_jeu
ROM:34BF rts
ROM:34C0 ; ---------------------------------------------------------------------------
ROM:34C0
ROM:34C0 loc_34C0: ; CODE XREF: init_lieu+59j
ROM:34C0 deca
ROM:34C1 bra loc_34AA
ROM:34C1 ; End of function init_lieu
ROM:34C1
ROM:34C3 ; ---------------------------------------------------------------------------
ROM:34C3 ldx #$32F8
ROM:34C6 jsr MPRINT
ROM:34C9
ROM:34C9 loc_34C9: ; CODE XREF: ROM:loc_34C9j
ROM:34C9 bra loc_34C9

Vampire TO7

ROM:7207 prepare_salle: ; CODE XREF: ROM:616BP
ROM:7207 ; ROM:639AP
ROM:7207 ldx #$9C5F
ROM:720A
ROM:720A loc_720A: ; CODE XREF: prepare_salle+8j
ROM:720A clr ,x+
ROM:720C cmpx #$9C7A
ROM:720F bcs loc_720A
ROM:7211 jsr determine_adr_salle
ROM:7214 ldu #$9C68
ROM:7217 exg x, u
ROM:7219 jsr recopie_donnes_portes
ROM:721C lda 3,u
ROM:721E sta 8,x
ROM:7220 leau 4,u
ROM:7222 leax 9,x
ROM:7224 jsr recopie_donnes_portes
ROM:7227 lda 3,u
ROM:7229 sta 8,x
ROM:722B ldu #$9596
ROM:722E
ROM:722E loc_722E: ; CODE XREF: prepare_salle+34j
ROM:722E lda 2,u
ROM:7230 cmpa #$FF
ROM:7232 beq loc_727D ; erreur porte
ROM:7234 cmpa byte_9C25
ROM:7237 beq loc_723D
ROM:7239
ROM:7239 loc_7239: ; CODE XREF: prepare_salle+4Ej
ROM:7239 leau 3,u
ROM:723B bra loc_722E
ROM:723D ; ---------------------------------------------------------------------------
ROM:723D
ROM:723D loc_723D: ; CODE XREF: prepare_salle+30j
ROM:723D lda 1,u
ROM:723F ldb #$14
ROM:7241 mul
ROM:7242 addd #$9CFA
ROM:7245 tfr d, x
ROM:7247 ldb ,u
ROM:7249 abx
ROM:724A lda ,x
ROM:724C ldx #$90D4
ROM:724F jsr sub_63E0
ROM:7252 tst compteur2
ROM:7255 beq loc_7239
ROM:7257 lda ,u
ROM:7259 inca
ROM:725A ldb byte_9C25
ROM:725D cmpb #3
ROM:725F bcs loc_7267
ROM:7261 cmpb #5
ROM:7263 bhi loc_7267
ROM:7265 suba #2
ROM:7267
ROM:7267 loc_7267: ; CODE XREF: prepare_salle+58j
ROM:7267 ; prepare_salle+5Cj
ROM:7267 asla
ROM:7268 asla
ROM:7269 sta posx
ROM:726C lda 1,u
ROM:726E asla
ROM:726F asla
ROM:7270 asla
ROM:7271 asla
ROM:7272 suba #8
ROM:7274 sta posy
ROM:7277 lda #1
ROM:7279 sta drapeau_en_vie
ROM:727C rts
ROM:727D ; ---------------------------------------------------------------------------
ROM:727D
ROM:727D loc_727D: ; CODE XREF: prepare_salle+2Bj
ROM:727D ldx #$7359 ; erreur porte
ROM:7280 jsr MPRINT
ROM:7283
ROM:7283 loc_7283: ; CODE XREF: prepare_salle:loc_7283j
ROM:7283 bra loc_7283
ROM:7283 ; End of function prepare_salle

(pour l'instant c'est en cours de désassemblage, les noms n'ont pas forcément de signification)

Il n'y a pas quelque chose qui saute aux yeux ?
nouvelhermes
Messages : 401
Inscription : 22 juil. 2020 20:56

Re: différences entre MO et TO : étude de cas

Message par nouvelhermes »

Ythunder a écrit : 29 mars 2023 16:39 Sorcery FIL ?
Pour moi c'était Virgin (boite noire plutot carré, différente comme TNT par exemple)
J'ai regardé avant de poster sur le site DCMOTO : Virgin
Y a -il une subilité qui m'a échappé depuis 1986 ?

On a peut être les auteurs dans Sorcery, mais il faudrait lancer le jeu.
EDIT : Sam a donc répondu juste avant avec d'ailleurs une excellente réponse, Vampire est un jeu original Thomson et Sorcery un portage.
Mais qu'estce qui t'as fait penser que le jeu avait été édité par FIL ? Parce que les boites FIL quand même, ça n'a rien à voir (j'adore ces boites !)
Ben c'est simple, ils ont laissé leur empreinte sur la version MO5, avec leur traditionnelle page grise.

Effectivement Vampire est un jeu original Thomson, mais clairement avec des règles pompés de Sorcery (en particulier les tableaux fixes et surout le personnage qui vole sujet à la pesanteur et à la noyade, gestion du temps similaire).

Mais quand on regarde le désassemblage, les similitudes sont vraiment visibles.
Ythunder
Messages : 928
Inscription : 21 août 2019 10:12

Re: différences entre MO et TO : étude de cas

Message par Ythunder »

Ah mais c'est parce que moi je tourne sur version TO7-70
il faudra que je lance la version MO5 sous l'émulateur, ça m'intrigue !
nouvelhermes
Messages : 401
Inscription : 22 juil. 2020 20:56

Re: différences entre MO et TO : étude de cas

Message par nouvelhermes »

Il faut regarder le fichier SORCERY.BAS et ENTETESO.BIN (version MO5)
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Vampire et Sorcery : même (moteur de) jeu ?

Message par __sam__ »

nouvelhermes a écrit : 29 mars 2023 17:04 On est tout à fait d'accord qu'il s'agit de l'ASM 6809, mais s'il n'y avait aucun lien, tu crois que les "tuiles" seraient dessinées de la même façon
Ben ya pas 36 façon de dessiner les sprites
que la gestion du temps se ferait de la même façon (écriture directe en MEM video)
Je ne vois pas ce que tu veux dire. Dans sorcery le temps est marqué par l'effacement progressif du grimoire comme dans la version originale. Dans Vampire c'est la lune qui disparait.
que la gestion du score se ferait de la même façon
Ben ya pas 36 façon de faire non plus.
(..) et en rentrant encore plus dans les dtétails après désassemblage, le moteur du jeu est quasiment identique.
Mais comme je n'ai pas IDA je ne peux juger des similarités.
Un exemple parmi d'autres :
(...)
Il n'y a pas quelque chose qui saute aux yeux ?
Avec l'asm sous les yeux oui, ya un air de famille. Dommage qu'on en sache pas plus qui est le porteur de Sorcery (m'est avis que c'est un truc préliminaire vu les traces de couleur qu'il laisse en RAMB).

NOTEs:
  • La version ZX spectrum de 1984 a aussi tendance à mal gérer les couleurs laissées par les sprites précédemment passés par là
    Dans tous les cas, on peut être content que les graphismes aient bien évolués entre la version ZX et la version Thomson.
  • En fait c'est pas tant la version TO ou MO5 qui importe ici que les similarités entre deux jeux. Si je devais me laisser tenter dans les spéculations je dirais que Sorcery a été porté de spectrum et a hérité de sa mauvaise gestion des couleurs (c'est lent, ca clash, ca tache les sprites suivants.). Les graphismes ont aussi été revus sur thomson. Plus tard ces routines on été optimisée, et peut-être réutilisées ailleurs en effet. En tout cas la graphiste de Vampire a mi sa pâte dans quelques jeux Infogrames.
  • Sur logicielsmoto (et la wiki) le jeu est incorrectement attribué à Infogrames...
  • Sur cette photo d'EBay, sur la K7 il est Indiqué ARIOLASOFT (en plus de Virgin).. le mystère s'épaissit
    Image
Dernière modification par __sam__ le 29 mars 2023 18:28, modifié 4 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
nouvelhermes
Messages : 401
Inscription : 22 juil. 2020 20:56

Re: différences entre MO et TO : étude de cas

Message par nouvelhermes »

Pour le score c'est très simple :

Version Vampire TO7

ROM:7C4E augmente_score: ; CODE XREF: ROM:61DBP
ROM:7C4E ; affiche_perso+7AP ...
ROM:7C4E ldd score
ROM:7C51 cmpd #$FDE8
ROM:7C55 bhi locret_7C5E
ROM:7C57 pshs x
ROM:7C59 addd ,s++
ROM:7C5B std score
ROM:7C5E
ROM:7C5E locret_7C5E: ; CODE XREF: augmente_score+7j
ROM:7C5E rts
ROM:7C5E ; End of function augmente_score

Sorcery MO5

ROM:3A7A ajoute_score: ; CODE XREF: ROM:22CFP
ROM:3A7A ; ROM:23D1P ...
ROM:3A7A ldd score
ROM:3A7D cmpd #$FDE8
ROM:3A81 bhi locret_3A8A
ROM:3A83 pshs x
ROM:3A85 addd ,s++
ROM:3A87 std score
ROM:3A8A
ROM:3A8A locret_3A8A: ; CODE XREF: ajoute_score+7j
ROM:3A8A rts
ROM:3A8A ; End of function ajoute_score

Fonctions identiques à l'octet près; même utilisation de la pile

Pour le temps :

Version Vampire TO7
ROM:7285 gere_temps: ; CODE XREF: ROM:loc_61ACP
ROM:7285 lda obj_porte
ROM:7288 cmpa #9 ; réveil?
ROM:728A beq locret_72CD
ROM:728C ldx compteur_temps
ROM:728F leax -1,x
ROM:7291 stx compteur_temps
ROM:7294 bne locret_72CD
ROM:7296 ldx #$258
ROM:7299 stx compteur_temps
ROM:729C ldu position_astre
ROM:729F tst astre
ROM:72A2 bne loc_72A9
ROM:72A4 leau $28,u
ROM:72A7 bra loc_72AC
ROM:72A9 ; ---------------------------------------------------------------------------
ROM:72A9
ROM:72A9 loc_72A9: ; CODE XREF: gere_temps+1Dj
ROM:72A9 leau $FFD8,u
ROM:72AC
ROM:72AC loc_72AC: ; CODE XREF: gere_temps+22j
ROM:72AC stu position_astre
ROM:72AF cmpu #$5DFC
ROM:72B3 bls loc_72C1
ROM:72B5 inc astre
ROM:72B8 ldu position_astre
ROM:72BB leau $FFD8,u
ROM:72BE stu position_astre
ROM:72C1
ROM:72C1 loc_72C1: ; CODE XREF: gere_temps+2Ej
ROM:72C1 lda astre
ROM:72C4 asla
ROM:72C5 ldx #$90E0
ROM:72C8 ldx a,x
ROM:72CA jsr affiche_astre
ROM:72CD
ROM:72CD locret_72CD: ; CODE XREF: gere_temps+5j
ROM:72CD ; gere_temps+Fj
ROM:72CD rts
ROM:72CD ; End of function gere_temps

ROM:3924 gere_temps: ; CODE XREF: ROM:loc_22D8P
ROM:3924 lda compteur_temps
ROM:3927 cmpa #$A0 ; 'á'
ROM:3929 beq loc_3930
ROM:392B inc compteur_temps
ROM:392E bra locret_3955
ROM:3930 ; ---------------------------------------------------------------------------
ROM:3930
ROM:3930 loc_3930: ; CODE XREF: ROM:3929j
ROM:3930 jsr memoire_forme
ROM:3933 clr compteur_temps
ROM:3936 ldx etat_grimoire
ROM:3939 lda no_col_grimoire
ROM:393C cmpa #6
ROM:393E bne loc_3946
ROM:3940 leax $22,x
ROM:3943 clr no_col_grimoire
ROM:3946
ROM:3946 loc_3946: ; CODE XREF: ROM:393Ej
ROM:3946 clr ,x
ROM:3948 jsr memoire_couleur
ROM:394B lda #0
ROM:394D sta ,x+
ROM:394F stx etat_grimoire
ROM:3952 inc no_col_grimoire
ROM:3955
ROM:3955 locret_3955: ; CODE XREF: ROM:392Ej
ROM:3955 rts

On retrouve des similitudes, en particulier le fait qu'on fait appel à un compteur qui sert de pointeur directement sur la mémoire écran.

Pour les tuiles (et les sprites peut-être), on utilise ici directement des registres 16 bits avec une seule couleur (Infogrames dans la plupart de ses jeu a utilisé une autre routine avec des registres sur 8 bits). Très peu de jeu utilise une commande PRINT maison, mais utilisent pour la plupart la routine PUTC standard (même chez Infogrames).
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: différences entre MO et TO : étude de cas

Message par __sam__ »

Pour le score c'est très simple :
../..
Fonctions identiques à l'octet près; même utilisation de la pile
Oui, c'est une addition de la valeur X à une globale avec saturation à 65 000. Il n'y pas 36 façons de faire cela efficacement sur 6809.
Pour le temps :
C'est un décompte à partir de 600. Ca doit être basé sur le timer qui gère le clignotement du curseur (période=100ms), ce qui fait que ce code décompte les minutes.

Note: pour le code essaye d'utiliser les balises "code", ca se lit mieux.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: différences entre MO et TO : étude de cas

Message par Daniel »

https://fr.wikipedia.org/wiki/Sorcery_( ... A9o,_1984)
Sorcery : Le jeu a été porté sur ordinateur Thomson par Infogrames (1986).
https://fr.wikipedia.org/wiki/Vampire_(jeu_vid%C3%A9o)
Vampire est un jeu d'action-aventure développé et édité par Infogrames en 1986 sur Thomson MO5, TO7 et TO9.
Ne croyez vous pas que ça peut expliquer une certaine ressemblance ?
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: différences entre MO et TO : étude de cas

Message par hlide »

Alors sur PC (moderne, pour le travail), j'ai eu droit à des surprises : en tentant de déboguer une routine sous Visual Studio, je me suis retrouvé dans une autre routine avec des noms différents. Un moment WTF jusqu'à ce que je réalise qu'en fait le compilateur avait fait une optimisation globale et fusionné deux routines à la sémantique totalement différente. Ça m'avait scotché. Tout ça pour dire que ce que l'on croit différent en algorithme dans sa forme source ne l'est pas dans sa forme binaire où la sémantique disparaît. Donc comparer du binaire n'implique pas un source identique si le binaire est identique.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: différences entre MO et TO : étude de cas

Message par __sam__ »

Daniel a écrit : 29 mars 2023 18:21 https://fr.wikipedia.org/wiki/Sorcery_( ... A9o,_1984)
Sorcery : Le jeu a été porté sur ordinateur Thomson par Infogrames (1986).
C'est une erreur dans la base de donnée Logicielsmoto. Yoann a corrigé, mais du coup la wiki est invalide. En fait Sorcery a eu 36 sortes d'éditeurs et même parfois plusieurs dans la même année pour un même pays et une même machine (Par exemple, en espagne, distribué par Discovery Informaic en 86, puis Dro Soft en 1989, puis Topsoft (pas de dates) - source trouvée par Yoann).

L'auteur d'origine était un tout jeune de 15ans et a été codé en 4 semaines (info trouvée par Bentoc). Vu le nombre de ports, ce jeu a du avoir rapporté pas mal à l'éditeur d'origine.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Répondre