DCMOTO - Emulateur universel Thomson 8 bits : Forum - Programmation - How did they program games for PC128?
Retour : Accueil » Programmation
Pages : 1 - 2
Auteur Message
Giovanni
Visiteur
Date : 11/04/2005 à 15h35
Hi
I know this is a french speaking forum, but I am not so good on french, sorry.
I had a pc128 when I was very young and I liked to program some simple text games (or so) in BASIC.

But .. how did they do to program the games we all played? Where they programmed on a DCMO (Pc128) computer or .. what?
I Used to do "Skip" and see all those .BIN files .. how they do? Used some kind of "Program" or other computers ?

Bye!!
en haut - en bas
Fool-DupleX
Visiteur
Date : 11/04/2005 à 16h25
Hi Giovanni

Most of the pieces of software on these machines have been developped in plain BASIC. This is also the main reason for their arguable quality.

The best software of course was developped in assembly language. There are a few native assemblers out there (like Microsoft's) which are perfectly usable for the task. Of course you needed some tools to import/export/create graphics and music. Most of the times, the programmers had their own, because nothing was provided by Thomson at the time.

Other programming languages were not widely used on Thomson.

For some very specific programs - for example the monitor (basic set of functionalities) or drivers (floppy, network), there was another way : cross-assemblers, i.e. assemblers for these machines but on some other platform. For example, the driver for the nanoreseau network was developped using AVOCET on a Vax machine. (incredibly enough, Avocet still exists: http://www.avocetsystems.com )

The process of developping software for those machines was very tedious : you would often end up with a crash and part or all of your data lost. You would use floppies or audio tapes to save your work, and they were not very reliable at the time.

Still, a few virtuoses managed to produce some nice software

Fool
en haut - en bas
Yoann
Visiteur
Date : 11/04/2005 à 16h56
This reminds me what the Guillon brothers said in an interview (I believe it is on Christophe's Lair website) that they needed to do absolutely everything to create their games, from the music editors to the graphic editors as there was indeed no development kit. On top of that, they managed to create their own tape format to protect their softwares ... amazing what they could have done with probably just a simple MO5 ;)

Now a days, it could be easier as there are other plateforms out there such as PC that helps in the development of softwares on Thomson, graphic wise or even while assembling a software (assembling is way much faster on PC than it is on Thomson ).

But some create softwares were programmed in BASIC. If I recall well, Imperialism is 100% BASIC. Island, a simple game on which I spent hours is also BASIC only. And to finish, Aigle d'Or although there is some little assembly program to animate the character is almost 100% BASIC (almost, huh ! )

Cheers
en haut - en bas
Yoann
Visiteur
Date : 11/04/2005 à 17h15
To give you a better idea :

Recently, I had to prepare a data file for a assembly software that I am writing. This data file would contain coordinates of various objects. I prepared the coordinates on paper, and organized them into BASIC DATA

For example :

10 DATA 0,0,1

This would mean coordinate (0,0) , piece 1 should be displayed

Very straight forward.

Then once my lines of data were created, I had to transfer them into memory. Still in BASIC, I read all these data and POKEd them into memory. For example :

999 MEM = &HA000
1000 FOR I=1 TO 100
1010 READ X,Y,N
1020 POKE MEM,X:POKE MEM+1,Y:POKE MEM+2,N
1030 MEM=MEM+3
1040 NEXT

And finally, I saved this into a binary file

1050 SAVEM"MYDATA.BIN",&HA000,MEM,&HA000

And my MYDATA.BIN could then be exploited with my assembly software, reading the memory starting at $A000 to use the data I previously saved.

That's why many softwares would usually have data files loaded as well as the "executable" itself. Some like most FIL software are usually a whole executable that contains the whole program (apart from the introduction screen of course).
en haut - en bas
Daniel
Visiteur
Date : 12/04/2005 à 08h53
Yoann example is true, .BIN files are not only machine code executables. Any amateur Basic programmer can produce .BIN files with SAVEM command, to store data or pictures.

In addition, commercial tapes are often copy-protected with non-standard files. They need machine code loaders in .BIN files. This explains the great number of .BIN files for a single game : loader, introduction screen, main program, pictures, sound, data, etc.

Daniel
en haut - en bas
Yoann
Visiteur
Date : 12/04/2005 à 09h17
Quick questions as this topic is very interresting :

1) How to you create a loader like the Loriciels ones (such as 3D Fight) were you just load by LOADM without specifying the ,R (to execute and not only load in memory). My guess is the execution address messes up with something in the system so it is automatically executed. Any idea ?

2) How could people, at that time, create such sophisticated protections and weird loaders and other format with basically just a MO5 and a tape recorder as their only plateform ? For example, for that kind of special Loriciels headers, did they use any other kind of recorders to reencode tapes (They would surely not be able to save this from standard BASIC commands for sure ! )
en haut - en bas
Yoann
Visiteur
Date : 12/04/2005 à 09h24
Citation :
Any amateur Basic programmer can produce .BIN files with SAVEM command, to store data or pictures.


This is very true. I am testing an application, written in BASIC that displays things on the screen (can't say much, it is secret right now ). However, real-time calculation is very slow, so I have created a program to do all the precalculation - and store this into arrays. But precalculation in order to run the app is also slow (Several minutes), so I managed to save this array into a . BIN file (all values can be contained in a single byte - which makes everything easy to manage). My BASIC app loads into memory this binary file, and uses it as a table of numbers (reading by PEEK after some very simple calculation of memory addresses) ... saving minutes of calculation, and therefore processing the whole thing much faster.

Therefore, BINARY files are surely not reserved for Assembly language experts, anybody can organize his own data in such files and reuse them with anything, BASIC for example.

Finally, you may already use BINARY files without knowing it. In BASIC 128 or 512, you can save ports or entire screen using GET command, display them anywhere you want using PUT and save them using SAVEP command, loading them using LOADP command. These files are pure binary file, having the same kind of header ( Start address, length of file, and the trailing $FF and execution address) and can be loaded into the memory using LOADM ...
en haut - en bas
Daniel
Visiteur
Date : 12/04/2005 à 09h44
Yoann a écrit :
How to you create a loader like the Loriciels ones (such as 3D Fight) were you just load by LOADM without specifying the ,R (to execute and not only load in memory). My guess is the execution address messes up with something in the system so it is automatically executed. Any idea ?

Just have a look at MySilicium
(French only. Sorry, no english translation available).

Edit(10:15) En relisant la discussion sur la protection des jeux, je vois que j'ai abandonné avant d'avoir expliqué l'exécution automatique par LOADM. C'est très simple : le fichier binaire, en se chargeant, modifie l'octet d'exécution automatique qui se trouve dans un vecteur du Basic (dans la zone de travail réservée au Basic en ram).

Daniel
en haut - en bas
Yoann
Visiteur
Date : 12/04/2005 à 10h03
Bon continuons en francais alors :D

Citation :
Les fichiers cassette sont terminés par un bloc de fin de fichier (voir http://dcmo5.free.fr ).
Ce bloc a normalement une longueur 2, et contient le type de bloc (FF) et la checksum (00).
Rien n'interdit de créer un bloc FF plus long, dans la limite des 256 octets autorisés.
Il joue toujours son rôle d'indicateur de fin de fichier, mais peut contenir jusqu'à 254 octets de code. A la lecture, il est stocké dans le buffer de lecture du magnétophone, qui se trouve à une adresse fixe. Il suffit alors de se brancher à cette adresse pour lancer le programme


Je suppose que ca repond a ma question precedente Y'a t-il un moyen facile (en utilisant simplement un MO5 et un magnetophone) pour generer un tel bloc ? Ou il faut ruser d'une astuce assembleur pour l'ecrire soit meme (octet par octet je suppose) ? Le moniteur possede-t-il des fonctions cassettes au fait (je n'utilise que les fonctions disquettes - qui au passage me permettent de creer des fichiers binaires illisibles par BASIC en omettant les headers binaires par exemple (et les marques de fin)
en haut - en bas
Fool-DupleX
Visiteur
Date : 12/04/2005 à 10h26
I've got the answers to all your questions, yoann.

A .bin file is not just a plain binary file. It is structured in blocks (not the K7 blocks, but logical blocks), which means, you can patch different memory areas, not just a contiguous one. To execute a .bin file at loading, you just have to add one last block which will patch the return address in the BASIC registry (this register is normally loaded by the ,,R parameter). Therefore, when LOAD returns, it jumps to your program. quick, easy, cosy and looks magical to many people.

As for the K7 blocks, if you stick to standard blocks in terms of encoding (MFM 1200 bits/s), you can use the functions provided by the monitor to create your special blocks. In opposition to the TO7, the MO5 monitor provides everything needed to produce headers, data and tails, but you have to provide a few parameters, set to "expected" values. If you messes up with these values, you can create special blocks.

If you change the encoding (like in Guillon Bros.' creations), you need to have your own routines.

Fool
en haut - en bas
Daniel
Visiteur
Date : 12/04/2005 à 10h40
Pour compléter la réponse à la question de Yoann : en théorie, c'est possible de développer des outils sur Thomson pour écrire les fichiers de format non standard utilisés par les protections.

Les loaders du 5eme axe, Sapiens, 3DFight (Loriciels), et ceux de la plupart des jeux Infogrames, contiennent des routines "lecture d'un bit", "lecture d'un octet", "lecture d'un bloc". En général, elles s'inspirent fortement des routines standard du moniteur, avec quelques modifications plus ou moins compliquées.

On peut aussi écrire, sur le même principe, des routines d'écriture permettant de créer les fichiers protégés.

A ta question (les fichiers spéciaux ont-ils été créés sur Thomson ou sur d'autres systèmes), je suppose qu'il y a les deux réponses. Les professionnels, comme Infogrames, ont certainement utilisé des mini-ordinateurs de l'époque. Je crois qu'ils avaient un micro-vax à Lyon. Par contre les amateurs, comme les frères Guillion et Jean-Christophe Bandini, ont probablement tout développé sur Thomson.

Daniel
en haut - en bas
Yoann
Visiteur
Date : 12/04/2005 à 15h36
Citation :
A .bin file is not just a plain binary file. It is structured in blocks (not the K7 blocks, but logical blocks), which means, you can patch different memory areas, not just a contiguous one. To execute a .bin file at loading, you just have to add one last block which will patch the return address in the BASIC registry (this register is normally loaded by the ,,R parameter). Therefore, when LOAD returns, it jumps to your program. quick, easy, cosy and looks magical to many people.


Is this valid for K7 or on disks as well I haven't studied at the sector level how a binary file is saved, but I would be very surprised that it is following the same structure as you are mentionning above.

Also based on the above, would it be possible for example to have a unique binary file that :

1. Changes the video memory (one of the 2 banks)
2. Loads the program in user memory

So therefore, the same binary file would touch to very distinct places of the memory ?

(Of course, a binary file during loading would not be able to switch the video banks ... )

And for my curiosity : How would you explain the nice color effect on the border while 3D Fight was loading ? Not sure how this can be touched on MO5 since the palette can not be changed (only way, for me, using the raster technique to touch the border) ?

Nice topic, I love it !
en haut - en bas
Fool-DupleX
Visiteur
Date : 12/04/2005 à 17h00
It is not a matter of sectors. This is an internal file format like when you say that a Microsoft Word .DOC has its own format. Therefore, this is valid on tapes as well as on disks. Each logical block starts with an implantation address, the number of bytes and a run address.

Maybe I did not make myself clear : yes, this format allows to touch very distinct places in the memory while loading. This is how the autorun is done : after loading the software, the BASIC registry return address is modified (that's somewhere between $2100 and $21FF on a MO5, I can't remind exactly where).

And yes, you could switch banks provided the fact that you agree to destroy other information in the same byte, because you can only write something, not use a bit mask (on a MO5, that's the border color and the K7 write bit, which is not used during reading anyway, so yes it may be done).

I will be able to provide you with a sample when I get back home.

I do not know nothing about the nice color effect while loading 3D Fight ; you are right however when you say that the only way to do such things is to use a raster technique of some kind (as a proof : the 16 color levels are programmed in a PROM on the MO5, which means it is not editable).

Fool
en haut - en bas
Daniel
Visiteur
Date : 12/04/2005 à 17h14
The "colored blinking border" effect is achieved by the customized "read byte" routine.
Border color is changed each time this subroutine is called. This occurs several times per frame, and the result is a multicolor blinking border.

Daniel
en haut - en bas
FoolDupleX
Visiteur
Date : 12/04/2005 à 20h05
Voici le format des fichiers binaires standard (il y a aussi un format etendu, utilise dans le nanoreseau):

Un fichier .BIN est constitue d'une suite d'enregistrement. Il existe deux types d'enregistrements.

Enregistrement contenant du code :

+0 [1] $00 = type de l'enregistrement
+1 [2] Longueur du code, soit n octets
+3 [2] Adresse de chargement de ce morceau de code (nous y voila)
+5 [n] bloc binaire a charger

Enregistrement contenant une adresse d'execution

+0 [1] $FF = type de l'enregistrement
+1 [2] Deux octets nuls
+3 [2] Adresse d'exécution

Il n'y a en general qu'un seul enregistrement contenant une adresse d'execution, alors qu'il peut y avoir autant d'enregistrement de code qu'on le desire. On peut ainsi patcher plusieurs zones en memoire d'un coup, y compris par exemple la zone des peripheriques et donc le bank switching.

L'enregistrement contenant l'adresse d'execution est celui qui est pris en compte lorsqu'on specifie le parametre ,,R. Pour faire un autorun, on utilise une autre technique, celle que j'ai mentionnee plus haut.

Fool
en haut - en bas
Daniel
Visiteur
Date : 12/04/2005 à 22h19
Ca ressemble beaucoup à ce qui est déjà écrit à la section FAQ sur la structure des fichiers

Daniel
en haut - en bas
Yoann
Visiteur
Date : 13/04/2005 à 01h35
[quote]+0 [1] $00 = type de l'enregistrement
+1 [2] Longueur du code, soit n octets
+3 [2] Adresse de chargement de ce morceau de code (nous y voila)
+5 [n] bloc binaire a charger

Enregistrement contenant une adresse d'execution

+0 [1] $FF = type de l'enregistrement
+1 [2] Deux octets nuls
+3 [2] Adresse d'exécution[/quote]

Je suis parfaitement au courant de ca

Mais comment peut tu mettres plusieurs blocks, chacun ayant une adresse d'implementation differente ? et tout ca dans le meme fichier ? tu peux me le refaire en me donnant une structure similaire mais avec plus d'un bloc ?
en haut - en bas
Daniel
Visiteur
Date : 13/04/2005 à 07h35
Ca me parait pourtant très clair dans l'explication de Fool-Duplex. Je l'ai formulé d'une autre façon dans les FAQ (Fiches techniques / Lecteur Enregistreur de Programmes et cassette MO5-MO6).

Daniel
en haut - en bas
Fool-DupleX
Visiteur
Date : 13/04/2005 à 10h43
Bon pour Yoann qui joue au bete, voici un example qui affiche une image en couleur (donc avec bank switching)

00 00 01 A7 C0 00 00 1F 40 00 00 [1f40 bytes d'image] 00 00 01 A7 C0 01 00 1F 40 00 00 [1f40 bytes d'image]

Le premier bloc va ecrire un octet (00) en a7c0, le deuxieme bloc va ecrire 1f40 octets en 0, le troisieme bloc va ecrire un octet (01) en a7c0, le 4eme bloc va ecrire 1f40 octets en 0.

le fait d'ecrire 0 en a7c0 influe sur les autres bits du registres, donc le pourtour de l'ecran va devenir noir et le bit ecriture k7 va passer a 0, mais on s'en balance. on peut meme piloter le bord de l'ecran, il suffirait de mettre la bonne valeur a la place de 0.

sur une k7, l'ensemble de ces donnees est ensuite decoupe en blocs de 253 bytes, sur une disquette en secteurs, mais ceci n'a rien n'a voir avec la logique du fichier et n'a aucune influence.

La commande LOADM interprete ces fichiers. La commande SAVEM ne permet de sauver que des fichiers contenant 1 unique bloc de donnees (+ un bloc facultatif d'execution). Il faut donc fabriquer les fichiers a la main.

Ca y est c'est clair ?

Fool
en haut - en bas
Yoann
Visiteur
Date : 13/04/2005 à 11h02
Aye ! j'ai compris ;)

Petite question a nouveau :

Est-ce possible d'executer quelque chose pendant le chargement. Tu disais avant que il suffit de mettre un petit programme a un endroit specific pour que ca s'auto execute.

Puis-je donc charger
1) Mon programme
2) La petite particule qui va declencher l'auto execution
3) Un autre programme
4) La petite particuler qui va declencher l'auto execution
....

Tout ca dans un meme et unique fichier binaire ? (c'est par curiosite, je ne sais pas a quoi ca pourrait servir, mais ca pourrait charger une suite de programme, le tout dans le meme fichier unique) ?

Si c'est possible, mon programme doit-il se finir par un RTS ou un SWI pour rendre la main a la partie qui charge le fichier ?
en haut - en bas
Pages : 1 - 2