Programmation CPS-1

[Tryphon]

Par curiosité, vous savez où je peux trouver des ressources sur la programmation du CPS-1 (en particulier son chip graphique) ?

[Hpman]

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.

[BULSARA]

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 .

[Tryphon]

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.

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

[upsilandre]

Ca va etre compliqué :)

[drludos]

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.

[Tryphon]

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).

[Invité]

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 :

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.

(il faut prendre les adresses donné par rapport à 0x800100 et 0x800140 je précise au cas où).

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).

[Tryphon]

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)...

[drludos]

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 !