Page 1 sur 3

Précision technique sur la Programmation PCE/CD

Publié : sam. 14 juil. 2007 00:12
par Orion_
Voila, je me lance dans la programmation sur PC Engine,
j'ai commencer à  regarder HuC, la doc du magic kit,
et y'a un truc qui me frappe...
tout a l'air simplifié a mort pour le développeur, si bien qu'il y a certain truc qui m'échappe..
y'a plein de fonctions inclus dans le compilateur lui même pour convertir les sprites à  la volée, les charger dans la vram (mais a des adresse mis en dur dans les exemples, alors pourquoi 0x1000 et pas une autre ??), etc...
et personnellement ça me pose un gros problème de compréhension.
même si on code en C, c'est quand même une machine 8bits donc limité, et j'aimerais vraiment savoir comment est organisée la mémoire, combien on a de ram dispo dans HuC, la taille max des programme overlay sur CD, comment accéder à  la ram du system card 3 pour y stocker plus de chose...
existe il des outils de conversion d'image externe au compilateur ? (sinon comment faire pour charger des graph à  partir du cd ? :? )
comment fonctionne la vram et pourquoi SATB est a tel adresse, a quel addresse ce trouve la BAT ? comment on peu changer cette adresse ?

bref, le kit m'a l'air super pour faire des mini jeux ou des démo rapide car y'a pas mal de boulot prémaché, mais ça manque vraiment de doc précis je trouve, ou alors on retrousse ces manches et on décortique les sources qu'on trouve un peu partout en testant afin de mieux comprendre comment la bête fonctionne :D

si vous des doc plus précise a ce sujet ou des réponses a mes questions ça m'intéresse beaucoup :)

Merci d'avance.

*EDIT*

apres avoir fouiller un peu sur pas mal de topic ici, je me répond partiellement avec cette adresse:
http://emu-docs.org/PC%20Engine/pce_doc/

edit: et celle la !
http://www.emulatronia.com/doctec/conso ... vdcdox.txt

Publié : sam. 14 juil. 2007 12:26
par dudule
regardes la : froezn utopia
et ici : zeograd'slair

Publié : sam. 14 juil. 2007 12:55
par peperocket
Dudule t'a passé deux adresses essentiels, n'hesite pas à  poser des questions sur le forum de frozen utopia qui est tres reactif.

Pour ce qui est de la prog en c et de la doc technique regarde sur cette page, tu trouveras les docs techniques de mcdonald sur la pc engine ainsi que quelques descriptions de fonctions de HUC :

Hucdoc

Pour ce qui est de l'adressage memoire tout est la :

Adressage memoire PCE

Sinon fouille un peu le forum dans sa section technique, mooz et moi meme avions ouvert un topic sur l'adressage memoire.

Publié : sam. 14 juil. 2007 14:05
par Orion_
merci :)
je viens de lire la doc de Charles MacDonald, y'a vraiment tout dedans c'est super !
d'ailleurs plus j'apprend sur le hardware, et plus je me demande si je vais pas plutôt programmer en asm. quand je vois le code généré par HuC et les tonnes de macro utilisé ça deviens super lourd a la fin :/
un truc que je pige pas trop non plus, apparemment y'a une sorte de DMA super rapide intégré au processeur pour copier des donnée en mémoire et en VRAM, mais dans le library.asm la fonction load_vram fait la copie a la main et pas en utilisant le dma, je trouve ça bizarre :?

en tout cas je trouve génial que les concepteurs du processeur ai intégré des fonctions du genre tia ou st0/1/2, complètement dédié aux spécificité du hard pc engine.
si j'ai bien compris par exemple pour transférer 0x100 octets de la RAM (0x2000) vers la VRAM en 0x1000 il faut faire:

Code : Tout sélectionner

	st0	#0	; Select VDC Memory Address Register
	st1	#$00
	st2	#$10	; Select VRAM at 0x1000

	st0	#2	; VRAM Write Command

	; DMA Transfer from RAM (0x2000, incremental) to VRAM (alternate high/low byte transfer) of 0x100 bytes
	tia	$2000,$0002,$100
j'ai bon ? ou j'ai rien compris ? :D

*EDIT*
j'ai trouvé ça aussi qui est pas mal :)
http://pcedev.fobby.net/lick/Special:Allpages

Publié : sam. 14 juil. 2007 16:47
par xav
Tiens on vas etre copain :D

Ne t'inquiéte pas pour Huc, méme s'il a tendance a user et abuser des macros (la gestion des tableaus est particulierement inneficace), le resultat final est tres honnéte point de vue perf.
Tu a d'ailleur la possibilité de mixer l'asm et le C.

Pour la DMA, j'ai moi méme eu du mal à  comprendre l'astuce, en fait il n'y a pas de registre ou de hardware réellement accessible, c'est l'instruction TIA qui le gerer.
C'est donc totallement transparent pour le programmeur.
Simple est efficace.

Comme le le coup des ST0/1/2 il fallait y penser :shock:
st0 #0 ; Select VDC Memory Address Register
st1 #$00
st2 #$10 ; Select VRAM at 0x1000

st0 #2 ; VRAM Write Command

; DMA Transfer from RAM (0x2000, incremental) to VRAM (alternate high/low byte transfer) of 0x100 bytes
tia $2000,$0002,$100
Euh de téte c'est bon, mais nooz te dirait mieux...

J'ai poster plein de trucs sympa, ils doivent étre encore dans des posts...

Publié : sam. 14 juil. 2007 16:59
par MooZ
Il y a toujours #utopiasoft sur efnet. Tu pourras y trouver les types de mindrec, frozen machin, Chris Covell, Charles Mac Donald et euh... moi :)
Sinon, il n'y a pas de DMA RAM vers VRAM. Si tu regardes la doc du vdc tu verras qu'il y a un DMA interne (VRAM=>VRAM et VRAM=>SAT. Ce qui permet faire des effets sympa comme du parallax vertical). Les instructions tia,tai,tii,tia,tin,... sont l'equivalent de otir et co sur z80. Ce sont juste des instructions de tranfert de blocs mémoire. Quand tu utilises ces instructions pour copier des données dans la vram, tu n'accedes par directement à  cette dernière mais tu passes par les ports $0002 et $0003. Donc pour copier des données de la RAM vers la VRAM, tu dois utiliser l'instruction tia (transfert increment alternate). L'adresse source est incrementée et l'adresse de destination alterne entre dest et dest+1 (ex: tia data,$0002,#$00ff)

Et pour la peine une petite doc:
http://cgfm2.emuviews.com/txt/pcetech.txt

Si tu es courageux, tu peux toujours lire les patents de la pce :D

Publié : sam. 14 juil. 2007 17:05
par xav
C'est vrai que je ne devrais pas appelais ça de la DMA, l'habitude :arrow:

Cela dit ça reste trés rapide.

Publié : sam. 14 juil. 2007 18:34
par Orion_
ah ok je croyais que c'etait un dma intégré dans le processeur, autant pour moi ^^
enfin ça reste plus rapide que de le faire a la main.
dans la lib de magic, le code de load_vram fait ça a la main, alors que le code utilisant tia est écrit mais commenté :/
a mon avis je vais utiliser HuC quand même parceque ça sera plus pratique, et optimiser certain transfer de donnée avec de l'inline asm.
J'ai enfin trouvé dans les doc ou était mappé la ram CD Rom \o/
par contre pour la mapper dans l'espace logique, apparament HuC utilise quasiment tout les segments, et je sais pas trop lequel je peu écraser pour mapper cette ram, une suggestion ?

*EDIT*:
apparemment y'a des "farptr" dans HuC qui tienne compte d'un offset et d'une bank, donc si je met une adresse physique en dur il va s'occuper de la mapper tout seul ?


ah et sinon, vu que je n'ai pas trouvé d'équivalent sur internet, j'ai commencer par me faire la main avec un convertisseur d'image BMP 16 couleurs vers le format de tile BG et Sprite de la PC Engine (+ création de palette)
lancez le programme pour voir l'usage.
http://onori.free.fr/pce/bmp2pce.zip

comme ça déjà  ça sera plus pratique si on veut charger des données a partir d'un cd ^^

Publié : sam. 14 juil. 2007 18:56
par xav
comme ça déjà  ça sera plus pratique si on veut charger des données a partir d'un cd ^^
Oui ça serais trés pratique pour l'overlay!

NB: Voici un jeux et des demos 100% C que j'ai ecrit il y a quelque temps, certains ne marche que sur yame (mode SGX).

http://rapidshare.com/files/42907094/Manta.rar.html

Publié : sam. 14 juil. 2007 19:14
par Orion_
sympa comme jeu :)
comment est-ce que c'est possible le scrolling parallaxe ?
je croyais que y'avais qu'un seul BG ?


j'ai tester les farptr mais ça marche pas tip top... et HuC me génère vraiment du code a s'arracher les cheveux, y'a même pas de préprocesseur pour quelque chose du genre a = 2 * 256; il me sort un jsr mul pour le faire sur la machine -_-'

Publié : sam. 14 juil. 2007 19:31
par MooZ
Il y a 2 BG sur sgx.

Apparemment les banks 5,6 et 7 ne sont pas utilisées par mkit (startup.asm ligne 23 et suivantes).

Il faut plus voir HuC comme une surcouche à  l'asm plutot que comme un vrai compilateur C. Il n'y a aucune (ou presque pas) d'optimisations. C'est utile pour tester rapidement mais rien ne vaut de l'asm fait main. Sinon j'ai remarqué que les noms des variables et des fonctions ainsi que le mappage mémoire d'HuC/mkit ressemblaient beaucoup à  celui du develo kit.

Publié : sam. 14 juil. 2007 20:14
par xav
comment est-ce que c'est possible le scrolling parallaxe ?
je croyais que y'avais qu'un seul BG ?
HAHA!!!! Pour Manta, qui tourne sur une nec classique à  1 bg, le secret du parallaxe avec des effet d'ombrage sympa c'est....... une illusion d'optique :wink: , c'est une technique que j'ai decouvert sur les jeux C64 et que quelque jeux PCE exploite (dracula X, magical chase).

Regarde les source et les fichier d'image, en fait là  ou il y a le fond en damier je joue une simple animation en 8 étapes, avec des couleurs différente pour l'ombre, l'illusion est parfaite.

Cette effet utilise a fond load_vram et comme tu peux le voir, ça ne ralentis en rien l'animation :wink:
Sinon j'ai remarqué que les noms des variables et des fonctions ainsi que le mappage mémoire d'HuC/mkit ressemblaient beaucoup à  celui du develo kit.
Je crois bien avoir lue que D.Michel a utiliser les noms officiels pour le mkit.

Publié : sam. 14 juil. 2007 20:15
par Orion_
ah ouais, sympa la technique :D

et sinon, qu'est ce que le develo kit ?

Publié : dim. 15 juil. 2007 14:37
par Orion_
mmh, je viens de tester la programmation en asm un peu (déja le startup.asm de huc ne fonctionne pas en mode asm pure, j'ai du prendre celui du magic kit)
j'ai essayer d'afficher une image, et ça fonctionne sur ootake, sur yame, mais pas sur magic engine :?
j'ai peut être oublier un truc mais quoi ? :D
si quelqu'un pouvais m'eclairer, merci d'avance.

voici mon code source:

Code : Tout sélectionner

_xres	.equ 256

	.include "startup.asm"

DATA_BANK	.equ	MAIN_BANK+1

	.zp
;pic:	.rs  1

;MMR0	$0000-$1FFF	$FF	Hardware I/O
;MMR1	$2000-$3FFF	$F8	PC Engine RAM
;MMR2	$4000-$5FFF
;MMR3	$6000-$7FFF
;MMR4	$8000-$9FFF
;MMR5	$A000-$BFFF
;MMR6	$C000-$DFFF	$01	Main Code
;MMR7	$E000-$FFFF	$00	HuCard ROM (Code)

	.code
	.bank	MAIN_BANK
	.org	$C000
main:
	lda	#DATA_BANK	; Map Data to Bank 2/3/4/5, result in 32K of linear data from $4000
	tam	#2
	inc	a
	tam	#3
	inc	a
	tam	#4
	inc	a
	tam	#5

	st0	#9	; BAT Size
	st1	#0	; 32x32

	st0	#0	; Tiles Adrs
	st1	#$00
	st2	#$10	; $1000

	st0	#2	; Tiles Copy
	tia	ryoko_gfx,$0002,28*1024

	st0	#0	; BAT Adrs
	st1	#0
	st2	#0

	st0	#2	; BAT Copy
	tia	ryoko_bat,$0002,32*28*2

	lda	#0
	sta	$0402	; Pal Color 0
	sta	$0403

	ldx	#0	; Set Pal
	ldy	#16
.loop:	lda	ryoko_pal,x
	sta	$0404
	inx
	lda	ryoko_pal,x
	sta	$0405
	inx
	dey
	bne	.loop

re:
	vsync			; synchro
	jmp   re


	.data

	.bank	DATA_BANK
	.org	$4000
ryoko_gfx:	.incbin	"ryoko.gfx"
	.org	$B000
ryoko_pal:	.incbin	"ryoko.pal"
ryoko_bat:	.incbin	"ryoko.map"
et la rom si quelqu'un a de quoi tester sur le hard (mais je doute que ça marche aussi..)
http://onori.free.fr/pce/test.zip

j'ai aussi updater mon outil bmp2pce pour generer un fichier BAT lineaire de 32x28 avec les tiles commençant a 0x1000

petite question, y a t'il un moyen (sur un emulateur par exemple) d'accéder a un debugger asm ?

Publié : dim. 15 juil. 2007 15:08
par MooZ
Bizarre... sous mednafen ca passe aussi ...
Peut etre que l'affichage est desactivé par défaut sous magicengine.

Essayes ça :

Code : Tout sélectionner

    ; Desactive les interruptions (hsync,vsync), l'affichage du bg et des sprites
    ; et mets l'increment d'écriture dans la VRAM à  1
    st0    #$05
    st1    #$00
    st2    #$00

    st0   #9   ; BAT Size
    st1   #0   ; 32x32 

    ; etc....
    bne    .loop
    
    ; On active l'affichage du bg, des sprites et les interruptions
    st0    #$05
    st1    #%1100_1100
    st2    #$00