Programmation CPS-1
5 participants
Page 1 sur 1
Programmation CPS-1
Par curiosité, vous savez où je peux trouver des ressources sur la programmation du CPS-1 (en particulier son chip graphique) ?
Tryphon- Docteur *
- Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Programmation CPS-1
J'ai pas de solution clef en main mais tu devrais trouver un grand nombre d'infos dans le fichier source video/cps1.c de mame.
Hpman- Patient contaminé
- Nombre de messages : 679
Age : 47
Localisation : Lille
Date d'inscription : 22/08/2014
Re: Programmation CPS-1
Ma reflexion va etre 1 peu idiote mais il ne sera pas plus simple de programmé sur X68000 puis de convertir sur cps1 vu que c est tres proche niveau hardware?
niveau doc ca doit plus facile de trouver .
niveau doc ca doit plus facile de trouver .
BULSARA- Guéri miraculeux
- Nombre de messages : 2298
Age : 41
Localisation : perpignan
Date d'inscription : 05/07/2014
Re: Programmation CPS-1
Hpman a écrit:J'ai pas de solution clef en main mais tu devrais trouver un grand nombre d'infos dans le fichier source video/cps1.c de mame.
C'est par ça que j'ai commencé, et en effet y'a pas mal de choses, mais tout est décrit de façon très succincte.
J'ai trouvé ça aussi : https://patpend.net/technical/arcade/cps1.html
C'est succinct aussi mais ça précise certains trucs et permet d'en extrapoler d'autres. Ça reste une base.
BULSARA a écrit:Ma reflexion va etre 1 peu idiote mais il ne sera pas plus simple de programmé sur X68000 puis de convertir sur cps1 vu que c est tres proche niveau hardware?
niveau doc ca doit plus facile de trouver .
Alors :
1) c'est principalement une légende urbaine que le X68K est proche du CPS-1. Par contre, des jeux Capcom ont été prorotypés sur 68K.
2) de toutes façons, c'est pas plus facile à trouver
Tryphon- Docteur *
- Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Programmation CPS-1
Ca va etre compliqué :)
upsilandre- Interne
- Nombre de messages : 5134
Age : 49
Localisation : val de marne 94
Date d'inscription : 31/05/2015
Re: Programmation CPS-1
Pour avoir regardé un peu aussi, je te confirme que c'est compliqué et qu'il y a peu de ressources (ceci dit, je suis loin d'avoir ton niveau en prog).
Le seul homebrew existant sur CPS1 dont le source est public est FrogFeast, dispo ici :
http://frogfeast.rastersoft.net/CPS1Src.html
C'est un homebrew assez ancien (le SDK proposé te compile des roms pour une très veille version de mame, voire pour Callus), mais l'avantage c'est que c'est codé en C. C'est basé sur le kit de dev NeoGeo de NeoBitz (pour compiler du code 68000) avec des outils custom pour convertir les images et les sons au format CPS-1.
Le code source n'est pas commenté, mais reste bien lisible car les fonctions ont des noms clairs et le code est bien structuré. En gros, il s'est construit un framework pour gérer la base (vecteur d'initialisation (startup.s), gestion des sprites (sprites.c), interfaces avec le hardware (routines.h)), et le code du jeu en lui-même est dans un fichier séparé du framework (Game.c et le reste).
Ca peut donc te permettre de repartir de son framework je pense pour faire ton propre jeu je pense !
P.S. : Qu'est-ce qui différencie tant que ça le X68000 et le CPS-1 alors ?
Moi aussi je pensais que les hardwares étaient proches, juste que le VDP était boosté sur CPS-1 pour passer de 128 à 256 sprites comparé au X68000.
Le seul homebrew existant sur CPS1 dont le source est public est FrogFeast, dispo ici :
http://frogfeast.rastersoft.net/CPS1Src.html
C'est un homebrew assez ancien (le SDK proposé te compile des roms pour une très veille version de mame, voire pour Callus), mais l'avantage c'est que c'est codé en C. C'est basé sur le kit de dev NeoGeo de NeoBitz (pour compiler du code 68000) avec des outils custom pour convertir les images et les sons au format CPS-1.
Le code source n'est pas commenté, mais reste bien lisible car les fonctions ont des noms clairs et le code est bien structuré. En gros, il s'est construit un framework pour gérer la base (vecteur d'initialisation (startup.s), gestion des sprites (sprites.c), interfaces avec le hardware (routines.h)), et le code du jeu en lui-même est dans un fichier séparé du framework (Game.c et le reste).
Ca peut donc te permettre de repartir de son framework je pense pour faire ton propre jeu je pense !
P.S. : Qu'est-ce qui différencie tant que ça le X68000 et le CPS-1 alors ?
Moi aussi je pensais que les hardwares étaient proches, juste que le VDP était boosté sur CPS-1 pour passer de 128 à 256 sprites comparé au X68000.
drludos- Patient contaminé
- Nombre de messages : 247
Age : 44
Localisation : 34
Date d'inscription : 12/10/2017
Re: Programmation CPS-1
Merci, j'ai jeté un œil et en effet, y'a des trucs à repêcher dedans.
Pour les différences CPS-1 / X68000, je laisse upsi répondre
D'ailleurs, si quelqu'un a de la doc sur la programmation X68000, je suis partant aussi (pour la peine, le code de Mame est plus difficile à exploiter là-dessus).
Pour les différences CPS-1 / X68000, je laisse upsi répondre
D'ailleurs, si quelqu'un a de la doc sur la programmation X68000, je suis partant aussi (pour la peine, le code de Mame est plus difficile à exploiter là-dessus).
Tryphon- Docteur *
- Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Programmation CPS-1
Je me permet de dire les différence entre CPS1/X68000 déjà en terme de memory map , les deux machines sont assez différente !
Sur CPS1 par exemple l'adresse 0x000000-0x3fffff c'est la ROM , par contre sur X68000 cela représente la RAM , de même que le 'GPU' pour le CPS1 le CPS1 register A et B (qui est un genre de VDP) sont aux adresses :
0x800100 -0x80013f et 0x800140 - 0x80017f
Sur x68000 c'est pour le CRTC (donc sûrement le contrôle de l'affichage et pas forcément pour une accélération matériel).
Et inversement sur CPS1 l'adresse de 0xff0000 - 0xffffff c'est la RAM alors que sur X68000 c'est la ROM...
Pour revenir sur le 'VDP' du CPS1 voilà ce que Mame dit :
Donc je te conseille plus d'y aller en assembleur dans un premier temps, sur le 68000 les 0x100 premiers octets de la ROM sont pour la table des interruptions (et aussi qui indique ou commence ton code) , ensuite tu peux coder directement pour la suite , et tester toutes les I/O.
Par contre les ROM sont 'divisé par deux' comme sur Neo Geo , donc faudra le prendre en compte (soit en faisant un outil qui le fait , soit en prenant un outils sur GitHub), quand je parle de diviser par deux (ou par 4 ça dépend) , c'est que si tu as 2 ROM (le plus courant), le premier octet se trouve dans la ROM 1 et le deuxième octet dans la ROM 2 , le 3 eme dans la ROM 1 ainsi de suite !
Je rajouterai que tu devra te baser sur une ROM existante vu que MAME par exemple (mais c'est le cas des nombreux autre émulateur enfaite) ne charge que des ROM de taille et de nombre fixe (de plus la memory map peut légèrement varié entre les jeux sur CPS1).
Sur CPS1 par exemple l'adresse 0x000000-0x3fffff c'est la ROM , par contre sur X68000 cela représente la RAM , de même que le 'GPU' pour le CPS1 le CPS1 register A et B (qui est un genre de VDP) sont aux adresses :
0x800100 -0x80013f et 0x800140 - 0x80017f
Sur x68000 c'est pour le CRTC (donc sûrement le contrôle de l'affichage et pas forcément pour une accélération matériel).
Et inversement sur CPS1 l'adresse de 0xff0000 - 0xffffff c'est la RAM alors que sur X68000 c'est la ROM...
Pour revenir sur le 'VDP' du CPS1 voilà ce que Mame dit :
- Code:
CPS-A Registers
---------------
0x00-0x01 OBJ RAM base (/256)
0x02-0x03 Scroll1 (8x8) RAM base (/256)
0x04-0x05 Scroll2 (16x16) RAM base (/256)
0x06-0x07 Scroll3 (32x32) RAM base (/256)
0x08-0x09 rowscroll RAM base (/256)
0x0a-0x0b Palette base (/256) after this register is written to, the palette
is copied from gfxram to the dedicated ram. The palette control
register (see below) determines how the copy should happen.
Tests on a msword pcb show that the minimum alignment for the palette
is 0x400 bytes. The hardware seems to ignore bit 1, while when bit 0
is set the palette doesn't seem to be copied. However, some games set
bit 0 during boot (ghouls, strider, 1941) so it still isn't clear
what bit 0 should actually do.
0x0c-0x0d Scroll 1 X
0x0e-0x0f Scroll 1 Y
0x10-0x11 Scroll 2 X
0x12-0x13 Scroll 2 Y
0x14-0x15 Scroll 3 X
0x16-0x17 Scroll 3 Y
0x18-0x19 Starfield 1 X
0x1a-0x1b Starfield 1 Y
0x1c-0x1d Starfield 2 X
0x1e-0x1f Starfield 2 Y
0x20-0x21 start offset for the rowscroll matrix
0x22-0x23 video control. Usually 0x0e.
bit 0 enables rowscroll on layer 2.
bit 15 is flip screen.
ghouls sets bit 14. Purpose unknown.
1941 uses bits 1-3 by setting them to 0 on screen transitions,
however it also uses the normal layer control register so there
doesn't seem to be an obvious effect.
Games known to use rowscroll:
SF2
Mega Twins (underwater, cave)
Carrier Air Wing (hazy background at beginning of mission 8, put 07 at ff8501 to jump there)
Magic Sword (fire on floor 3; screen distort after continue)
Varth (title screen, end of stage 4)
Captain Commando (end game sequence)
Tests done on msword at the beginning of gameplay (many thanks to Corrado Tomaselli for these):
3e is the default value set by the game (not 0e like most games)
3c the last two rows of scroll1 are repeated on the whole screen
3a scroll2 is disabled
36 scroll3 is disabled
2e no visible differences
1e no visible differences
one might suspect that bits 4&5 should disable the star layers, but
Strider sets this register to 0x0e so that's not possible.
TODO:
the scroll2/scroll3 disable bits are supported by the emulation,
while the scroll1 weird effect is not (it doesn't seem to make a
difference in any game).
CPS-B Registers
---------------
Unlike CPS-A registers, which are at fixed addresses, CPS-B registers move from game to game.
Following example strider
0x66-0x67 Layer control register
bits 14-15 seem to be unused
ghouls sets bits 15 in service mode when you press button 2 in
the input test, with no apparent effect on the pcb.
qtono2j sets them both at the game over screen.
bits 6-13 (4 groups of 2 bits) select layer draw order
bits 1-5 enable the three tilemap layers and the two starfield
layers (the bit order changes from game to game).
Only Forgotten Worlds and Strider use the starfield.
bit 0 could be rowscroll related. It is set by captain commando,
varth, mtwins, mssword, cawing while rowscroll is active. However
kodj and sf2 do NOT set this bit while they are using rowscroll.
Tests on the msword pcb show that even if this bit is not set,
rowscroll still works. Therefore, the purpose of this bit is unclear.
0x68-0x69 Priority mask \ Tiles in the layer just below sprites can have
0x6a-0x6b Priority mask | four priority levels, each one associated with one
0x6c-0x6d Priority mask | of these masks. The masks indicate pens in the tile
0x6e-0x6f Priority mask / that have priority over sprites.
0x70-0x71 Palette control register. This indicates which palette
pages to copy when the palette base register is written to.
There is one CPS2 game (Slammasters II) setting this to 0x2f; all the other
games normally set it to 0x3f, though in some cases different values are
used during boot:
ghouls 0x02 (and palette base is set to 9105; palette base is 9100 normally)
strider 0x02 (and palette base is set to 9145; palette base is 9140 normally)
1941 0x02 (and palette base is set to 9145; palette base is 9140 normally)
unsquad 0x0f
kod 0x0f
mtwins 0x0f
bit 0: copy page 0 (sprites)
bit 1: copy page 1 (scroll1)
bit 2: copy page 2 (scroll2)
bit 3: copy page 3 (scroll3)
bit 4: copy page 4 (stars1)
bit 5: copy page 5 (stars2)
An important quirk is that if the first bits are not set, page 0 in
gfxram is not skipped but instead is copied to the first enabled page.
For the other pages, if the bit is not set the gfxram page is skipped.
Example: 0x0a
bit 0 is not set so palette page 0 (sprites) is not updated
bit 1 is set so palette page 1 (scroll1) is updated; since bit 0 was
not set, it is taken from gfxram page 0
bit 2 is not set so palette page 2 (scroll2) is not updated; gfxram
page 1 is skipped
bit 3 is set so palette page 3 (scroll3) is updated; it is taken from
gfxram page 2
bits 0-3 have been verified on a msword pcb, while bits 4-5 are only
supposed.
Donc je te conseille plus d'y aller en assembleur dans un premier temps, sur le 68000 les 0x100 premiers octets de la ROM sont pour la table des interruptions (et aussi qui indique ou commence ton code) , ensuite tu peux coder directement pour la suite , et tester toutes les I/O.
Par contre les ROM sont 'divisé par deux' comme sur Neo Geo , donc faudra le prendre en compte (soit en faisant un outil qui le fait , soit en prenant un outils sur GitHub), quand je parle de diviser par deux (ou par 4 ça dépend) , c'est que si tu as 2 ROM (le plus courant), le premier octet se trouve dans la ROM 1 et le deuxième octet dans la ROM 2 , le 3 eme dans la ROM 1 ainsi de suite !
Je rajouterai que tu devra te baser sur une ROM existante vu que MAME par exemple (mais c'est le cas des nombreux autre émulateur enfaite) ne charge que des ROM de taille et de nombre fixe (de plus la memory map peut légèrement varié entre les jeux sur CPS1).
Invité- Invité
Re: Programmation CPS-1
Kannagi a écrit:Donc je te conseille plus d'y aller en assembleur dans un premier temps, sur le 68000 les 0x100 premiers octets de la ROM sont pour la table des interruptions (et aussi qui indique ou commence ton code) , ensuite tu peux coder directement pour la suite , et tester toutes les I/O.
Par contre les ROM sont 'divisé par deux' comme sur Neo Geo , donc faudra le prendre en compte (soit en faisant un outil qui le fait , soit en prenant un outils sur GitHub), quand je parle de diviser par deux (ou par 4 ça dépend) , c'est que si tu as 2 ROM (le plus courant), le premier octet se trouve dans la ROM 1 et le deuxième octet dans la ROM 2 , le 3 eme dans la ROM 1 ainsi de suite !
Je rajouterai que tu devra te baser sur une ROM existante vu que MAME par exemple (mais c'est le cas des nombreux autre émulateur enfaite) ne charge que des ROM de taille et de nombre fixe (de plus la memory map peut légèrement varié entre les jeux sur CPS1).
Merci, c'est bon à savoir.
En fait, mon projet est plus proche de l'écriture d'un émulateur CPS-1 (même si ce n'est pas exactement ça)...
Tryphon- Docteur *
- Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Programmation CPS-1
Merci pour les infos, c'est super intéressant !
Pour le "split" de rom en deux fichiers (octet A dans fichier 1, octet B dans fichier 2, etc.), Romwak marche très bien :
https://github.com/freem/romwak
(là aussi, c'est un outil issu du SDK Neo Geo !
Tu piques ma curiosité Tryphon, c'est quoi ton projet alors ?
Moi je pensais à une version CPS1 de Shinobi, mais visiblement c'est pas du tout ça !
Pour le "split" de rom en deux fichiers (octet A dans fichier 1, octet B dans fichier 2, etc.), Romwak marche très bien :
https://github.com/freem/romwak
(là aussi, c'est un outil issu du SDK Neo Geo !
Tu piques ma curiosité Tryphon, c'est quoi ton projet alors ?
Moi je pensais à une version CPS1 de Shinobi, mais visiblement c'est pas du tout ça !
drludos- Patient contaminé
- Nombre de messages : 247
Age : 44
Localisation : 34
Date d'inscription : 12/10/2017
Sujets similaires
» Programmation sur Saturn
» La programmation Megadrive
» Programmation sous Unity3D ?
» Mr ToutLeMonde et la programmation NES...
» Mr ToutLeMonde et la programmation NES...
» La programmation Megadrive
» Programmation sous Unity3D ?
» Mr ToutLeMonde et la programmation NES...
» Mr ToutLeMonde et la programmation NES...
Page 1 sur 1
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum