quels effets faisables sur pce/sgx ???

[pckid]

Merci ,

tu arrives à quelque chose ?
- tu comprends comment contruire une map ?

Car j'arrive à faire bouger mon sprite , mais je n'arrive pas à faire de decor.

merci
@ très bientot

[touko]

Pour construire une map tu utilises une image au format .pcx ..

Il faut qu'elle soit multiple de 16 pixels en hauteur/largeur ..
tu peux te servir de ces exemples :
http://www.zeograd.com/download_present ... =en&id=160

http://www.zeograd.com/download_present ... =en&id=219

http://www.zeograd.com/download_present ... =en&id=220

[xav]

C'est vrai que la zone morte d'un écran CRT permet de masqué un tas de défaut.

De ce que je comprend après relecture des patents et des docs de Mc Donald: Tout les bugs qui ce produisent quand on s'attaque a la hirq viens du fait même que le VDP et le VCE sont deux puce distincte.

En fait lors de la génération de l'image à l'écran les 2 chips et le CPU peuvent théoriquement accéder à la vram SIMULTANEMENT, d'où crash visuel.
Les technicos de chez nec on partiellement résolu le problème en pompant la méthode de commodore pour le C64, les fameuse ligne morte.

C'est pratiquement invisible pour le programmeur mais pour un certain nombre de ligne affiché le CPU "skipe" une ligne imaginaire afin d'assurer la synchro...

Malin, sauf que ca parasite certain effet et c'est vraiment difficile a debugger.

Solution bête et méchante, ne toucher au registres du VPD ou du VCE UNIQUEMENT que quand on est sur que:

1- Il n'y a pas d'accès a la vram
2- on est hors génération d'image
3- Les bestiaux ne dialogues pas entre eux

[touko]

Merci pour les précisions ..

Mais je suis quasiment sur que j'ai résolu le problème pour l'effet copper, seulement je pensais que non du fait que je faisais mes test sur un lcd et non un crt ..
une chose est sure, c'est qu'il est impossible à faire avec huc sans refaire totalement l'irq1 .

A noter que sur le test de cet effet que je t'ai envoyé, il y a 0 bugs .

[xav]

A noter que sur le test de cet effet que je t'ai envoyé, il y a 0 bugs .

En effet, mais dés que l'on commence a faire quelque chose de compliquer avec, tout s'effondre, l'overlay plante, les maps crashes etc...

une chose est sure, c'est qu'il est impossible à faire avec huc sans refaire totalement l'irq1 .

Puisqu'on en parle ailleurs j'ai eu l'occasion de comparer le code asm produit par Huc par rapport a celui de CC65.
Sans surprise le code CC65 parait plus propre et plus compact, maintenant il faudrait arrivé a compiler un exemple sur CC65 pour le 6280 qui doit normalement accepter un code 6502 sans trop de modif.
Quitte a tout réécrire, il est tentant de repartir sur un compilateur plus robuste et plus suivis ( les struct j'en rêve )

[touko]

En effet, mais dés que l'on commence a faire quelque chose de compliquer avec, tout s'effondre, l'overlay plante, les maps crashes etc...

, euh à quel niveau ça plante ????
Après si tu l'utilises tel quel c'est normal, le code pour l'effet copper est uniquement mkit, donc il marche pas directement sous huc ..
Sous HUC tu pourras difficilement (voire jamais) utiliser des effets de couleurs sur les int h_sync sans refondre l'irq1, donc te passer des fonctions scroll, etc ...
Sans oublier que pour le scd, c'est pire faut faire avec l'irq1 du bios, sinon faut se passer de certaines fonctions qui marchent plus (ou arriver à lui rendre la main).

Puisqu'on en parle ailleurs j'ai eu l'occasion de comparer le code asm produit par Huc par rapport a celui de CC65.
Sans surprise le code CC65 parait plus propre et plus compact, maintenant il faudrait arrivé a compiler un exemple sur CC65 pour le 6280 qui doit normalement accepter un code 6502 sans trop de modif.
Quitte a tout réécrire, il est tentant de repartir sur un compilateur plus robuste et plus suivis ( les struct j'en rêve )

Oui, mais perso j'ai pas les compétences et le temps pour faire ça .

[xav]

Mais justement, j'ai écrit un loader pour l"hirq custom, quelque fonction scroll qui ne passe pas par les int et enfin une petite bidouille pour rechargé proprement la gestion hirq d'origine pour utiliser les fonctions CD.
Mais comme je suis une buse en asm ça marche une fois sur 10

Oui, mais perso j'ai pas les compétences et le temps pour faire ça .

Eeeeeetttttt moi non plus!

[touko]

Ouai, perso j'ai customisé tout le startup.asm et inclu mon gestionnaire perso dedans ..
Supprimé tout un tas de fonctions lourdes et inutiles (pour moi) .
Je reloge des fonctions dans les banques 0 et 1 ou des données dans la 2 etc ..

J'utilise plus rien des routines de tom, ça me permet de gagner bcp de cycles, j'ai même un petit fade du menu SCD à la orion_ ..
En fait je me sert de huc, plus pour la gestion des banques, encore un peu obscure pour moi ..

Quand tu arrives à by-passer HUC, tu fais des choses bien plus intéressante,style pouvoir jouer des samples en DDA via le timer par exemple ..
Sans parler du gain de place .

Pour tes fonctions, si tu veux je peux essayer de t'aider

Pour la fonction d'update de la sat tu peux la remplacer par celle là :

Code : Tout sélectionner

update_sat()
{
	#asm				
		st0 #0						; // Parametrage du VDC en ecriture
		st1 #$00					; // Adresse de la SAT par defaut 0x7F00
		st2 #$7F
		st0 #2		
		tia _satb,$0002,$200			
	#endasm	
}

En comparaison celle de HUC :

Code : Tout sélectionner

; satb_update()
; ----

_satb_update:
	  lda	<__spr_flag
	  beq	.l1
	  stz	<__spr_flag
	  ldx	#64
	  bra	.l3
	  ; --
.l1:	  cpy	#1
	  beq	.l2
	  ldx	<__spr_max
.l2:	  cpx	#0
	  beq	.l4
	  ; --
.l3:	  stx	<_al	; number of sprites
	  txa
	  dec	A	; round up to the next group of 4 sprites
	  lsr	A
	  lsr	A
	  inc	A
	  sta	<_cl

; Use TIA, but BLiT 16 words at a time (32 bytes)
; Because interrupt must not deferred too much
;
	  stw	#32, _ram_hdwr_tia_size
	  stw	#video_data, _ram_hdwr_tia_dest
	  stw	#_satb, <_si

	  stw	#$7F00, <_di
	  jsr	set_write

.l3a:	  stw	<_si, _ram_hdwr_tia_src
	  jsr	_ram_hdwr_tia
	  addw	#32,<_si
	  dec	<_cl
	  bne	.l3a
	  
;.l3:	  stx	<_al
;	  stw	#_satb,<_si
;	  stb	#BANK(_satb),<_bl
;	  stw	#$7F00,<_di
;	  txa
;	  stz	<_ch
;	  asl	A
;	  asl	A
;	  rol	<_ch
;	  sta	<_cl
;	  jsr	load_vram

	  ; --
	  ldx	<_al
.l4:	  cla
	  rts

[MooZ]

Vous allez rire. Je viens de regarder le code de cc65 et il semblerait qu'il supporte déjà le HuC6280 (src\da65\opchuc6280.c). Apparemment il manque juste le code asm de startup et la description de la memory map.

[touko]

Vous allez rire. Je viens de regarder le code de cc65 et il semblerait qu'il supporte déjà le HuC6280 (src\da65\opchuc6280.c). Apparemment il manque juste le code asm de startup et la description de la memory map.

Ca pourrai être pas mal ça

[xav]

Vous allez rire. Je viens de regarder le code de cc65 et il semblerait qu'il supporte déjà le HuC6280

BING..... Oh un bouton de braguette qui saute

[pckid]

un compilateur autre que Huc ? peut on confirmer cette news ?

[xav]

Je viens de regarder les sources, le type CPU_HUC6280 existe bien, mais target.c et target.h ne le prennent pas en compte dans les cible possibles, et comme la justement fait remarquer Mooz il n'y a ni bootstrap ni gestion mémoire (Ouille les Banks) prévus pour ce CPU.
Il en faudrait d'ailleurs 3, le modèle mem hucard ,le modèle CD et le SCD.

Donc c'est encouragent mais loin d’être utilisable pour l'instant

[glutamatedealer]

Compilateur de huc', si c'est du verlan c'est un peu vulgaire...!

[touko]

Lol, faut toujours qu'il y ai un qui vienne casser l'ambiance