Re: MEGADRIVE vs SUPER NINTENDO : Fight !

par Invité Ven 3 Juil 2015 - 16:22

bah maintenant c'est ça :

MEGADRIVE vs SUPER NINTENDO : Fight ! - Page 26 Sagemcom-sixty-telephone-cadran-design-540x301

par upsilandre Ven 3 Juil 2015 - 20:53

Je me souviens que sur les toutes premières emission j'etais assez impressionné pas l'aspect technique de Hugo délire (Graphiquement et le fait de jouer avec le téléphone)
Si ca tournait sur un A500 c'etait pas une version boosté quand meme? (il me semble que sur Amiga y avait aussi des carte accélératrice pour des applications pro?) parce que ca me parait pas facile a faire sur un A500 (je vois pas trop comment en fait).

Sinon j'ai encore de nouveaux questionnements sur ces 3 consoles, apres avoir fait le tour de la VRAM MD je me suis rendu compte d'autre truc mais j'ai pas eu le temps cette semaine.

par Nextome Ven 3 Juil 2015 - 21:05

J'y avais joué sur mon Amiga 1200 c'était quand même très proche de la version du jeux télévisé... l'Amiga était une sacrée bécane même le 500 et techniquement bien supérieur à une Nec ou une Megadrive. Mais bon on retombe dans le débat classique. LAmiga avait une technologie très en avance mais des jeux en retrait par rapport aux productions japonaises.

par upsilandre Ven 3 Juil 2015 - 21:39

J'ai comparé, ca ressemble pas mal mais c'est pas equivalent. Tu prend la scene du train quand il arrive en pleine face sur la version TV ca zoom beaucoup plus, la derniere frame est au moins 10x plus grosse que sur la version amiga et en plus le framerate est superieur sur la version original.
Y a des scenes de zoom qui manque. Sur la version original ils semblent y avoir un hardware cablé de zoom de sprite dont ils usent un peu partout meme dans des cutscene alors que sur la version amiga il semble y avoir pas mal de précompute.
Donc non clairement la version original qu'on voyait a la TV ne tournait pas sur un Amiga 500 (en tout cas pas un simple amiga ordinaire).

par Stef Ven 3 Juil 2015 - 22:13

Nextome a écrit:J'y avais joué sur mon Amiga 1200 c'était quand même très proche de la version du jeux télévisé... l'Amiga était une sacrée bécane même le 500 et techniquement bien supérieur à une Nec ou une Megadrive. Mais bon on retombe dans le débat classique. LAmiga avait une technologie très en avance mais des jeux en retrait par rapport aux productions japonaises.

Techniquement bien supérieur ? Pour faire des jeux certainement pas..
L'Amiga peut avoir certains avantages sur certains points technique très spécifiques mais en règle général quand il s'agit de jeux 2D classiques la MD a largement l'avantage. Ça reste une machine dédiée à ça alors que l'Amiga est un ordinateur ( certes très orienté vers le ludique).

par upsilandre Ven 3 Juil 2015 - 22:47

C'est sur que c'est difficile a comparer tellement c'est different. Une megadrive c'est fait avant tout pour faire des jeux d'action 2D a 60fps qui bouge bien.

par ace76 Ven 3 Juil 2015 - 23:20

bon,j'ai fouillé un peu,et il apparait que c'est plutot un Amiga 2000 qui fut utilisé
pour hugo delire.

par upsilandre Ven 3 Juil 2015 - 23:26

ace76 a écrit:bon,j'ai fouillé un peu,et il apparait que c'est plutot un Amiga 2000 qui fut utilisé
pour hugo delire.

Oui ca doit etre une version pro complètement upgrader CPU, RAM voir peut etre carte accélératrice.

par airdream Sam 4 Juil 2015 - 10:16

a ceux qui veulent tester des jeux sans avoir les emulateurs installés sur sa bécane, jouable via votre navigateur internet
SNES, MD, PCE, NES et SMS

http://www.open-consoles-search.com/oc-bestsets/

pratique pour jouer au boulot ou sur n'importe quel PC Rolling Eyes

par upsilandre Dim 5 Juil 2015 - 10:24

Je cherche un emulateur PC-Engine avec un debug qui affiche tous les registres du VDC?

par Invité Dim 5 Juil 2015 - 10:52

Le seul que je connaisse c'est mednafen.

par upsilandre Dim 5 Juil 2015 - 11:22

ok merci, je me posais la question sur la selection du dot clock sur PCE.
A priori on ne peut pas choisir directement le dot clock, je vois pas de registre pour ca?
Par contre la PCE offre un controle CRT avancé donc j'imagine que le VDC choisie lui meme le dot clock en fonction des tailles de blanking et d'affichage que l'on défini?

par Invité Dim 5 Juil 2015 - 12:09

Va falloir un topic à part, décidément. ^^

par Invité Dim 5 Juil 2015 - 12:14

ok merci, je me posais la question sur la selection du dot clock sur PCE.
A priori on ne peut pas choisir directement le dot clock, je vois pas de registre pour ca?

Normal c'est le registre $400 du VCE qui le permet, et non le VDC .
Le VDC permet juste de définir ton écran qui est indépendant du dotclock.
Bien sur un écran de 344 pixels horizontaux avec un dot clock de 5 mhz ça va pas le faire, mais c'est possible .

Par contre tu peux définir sans problèmes un écran 280x240 avec le dotclock 10mhz par exemple.

tu as des infos sur les registres du VDC ici :
http://www.archaicpixels.com/HuC6270

par upsilandre Dim 5 Juil 2015 - 19:36

Forcement si c'est dans le VCE je risquais pas de trouver. rambo

J'avais encore pas mal de chose a dire sur les comparaisons de VRAM entre les 3 machines mais je sais plus si faut faire un autre topic dédié ou pas (je serais meme tenté d'ajouter la GBA dans le lot. un topic de comparaison hardware console dans la section programmation? mais il sagit pas vraiment de programmer)

par Invité Dim 5 Juil 2015 - 20:28

Mettre la gba n'est peut être pas une bonne idée dans le sens où elle n'appartient pas à la même génération .
Après un topic hardware pour parler des 3 machines pk pas .
Il faut aussi savoir que le VDC possède 2 pointeurs indépendant en lecture et ecriture,je crois pas que la md et la snes ont la même chose .

par upsilandre Mar 7 Juil 2015 - 13:42

L'analyse du hardware ca ne fonctionne effectivement que par comparaison entre les machines, c'est la qu'on comprend l'identité de chacune aussi bien que le processus d'evolution, parler d'une machine isolé sans cette démarche par comparaison c'est pas intéressant donc ca demande effectivement un topic assez ouvert mais je sais pas ou exactement.

En tout cas je voulais revenir sur les VRAM de ces consoles 16bit car j'ai ete induit en erreur sur leur nature.
Je m'en suis rendu compte apres avoir fait le tour de la VRAM de la MD dont ont a bien cerné le fonctionnement jusqu'a l'utilisation de chaque slot grace au schéma de steph. La MD etait une affaire classé du coup je me dit tiens je vais calculé vite fait combien la SNES a besoin de bande passante par scanline juste pour voir a quelle point y a peu de marge sur SNES.

A priori c'est assez simple car sur SNES y a pas d'OAM en VRAM et du coté du background malgres le grand choix de mode video qui peut paraître complexe en réalité ca se résume juste a proposer toutes les facons de répartir un budget de 16bpp (sachant que pour chaque bg tu ajoutes 2bpp pour la tilemap).
Le budget de la SNES est de 680 octets par scanline (340 dot cycle * 2 octets ou 340 slots 16bit) et quand je fais mon calcule rien a faire ca ne rentre pas, y a toujours quelques octets de trop. Y a qu'avec le scénarios le plus faible (33 tiles bg au lieu de 34 comme c'est le cas sur MD et PCE et 32 ou 33x8 pixels sprite au lieu de 34 comme est censé le faire la SNES) que ca passe mais ca correspond pas a ce que fetch la SNES (apres recherche elle fetch bien 34 tile bg comme les autres et 34x8 sprites pixels, y a meme un registre de statut qui flag a a partir du 35eme)

Puis finalement c'est en enlevant les 10 slots (20 octets) bouffé par le refresh que le calcule tombe pile sur 680! C'est a ce moment la que je viens de comprendre qu'il y a pas de refresh sur la VRAM de la SNES. Les truc que j'avais lu sur le refresh de la SNES concernait finalement la WRAM dont le refresh interrompt le CPU et le DMA et qui est responsable des quelques octets perdu du DMA vers la VRAM, ce n'est pas a cause du refresh de la VRAM. D'autant plus induit en erreur que le refresh de la WRAM est synchrone avec les scanlines et donc le PPU.

Bref apres verification je me rend compte en faite que la VRAM de la SNES n'est pas de la simple DRAM mais de la PSRAM (pseudo static ram) qui est quand meme une DRAM mais avec une gestion avancé du refresh qui se fait en interne dans le chip de DRAM et de facon a priori transparente (au moins dans ce contexte).
Et pire que ca, je vais au bout de la demarche et me rend compte que la PCE utilise exactement le meme type de de RAM pour sa VRAM (ainsi que que pour l'audio de la SNES et pour la WRAM de la MD). Au final seul la VRAM de la MD a besoin d'un refresh (mais sans consequence alors que sur SNES ca aurait posé probleme pour le 3eme bg). Sur PCE l'interet de la PSRAM plutot que de la simple DRAM semble plus obscure car les slots libre ne manque pas pour le refresh, probablement juste pour simplifier l'architecture.

Donc moi qui croyait (je ne sais meme plus pourquoi et ou j'ai pu lire ca) que du coté VRAM la PCE avait de la SRAM et la SNES de la DRAM, soit 2 mémoires diamétralement opposées, au final me rend compte que c'est juste la meme mémoire pour les 2.
Quelque part ca fait sense car sur la PCE on voyait bien deja que c'etait compliqué de mettre plus de 8Ko de SRAM pour la WRAM du coup on comprenait pas comment ils auraient pu en mettre 64ko de plus pour la VRAM (et puis ca renforce l'exploit d'avoir mis 32Ko de SRAM dans la supergrafX, ca doit etre un record).

Mais du coup ca interroge aussi car si on se fie au type de référence des composants de PSRAM utilisé sur PCE et SNES on remarque que sur SNES ils utilisent une version plus performante (ce qui est donc l'inverse de ce que je pensais jusqu'a maintenant) alors que la PCE peut potentiellement la sollicité de facon 2x plus intensive. On pourrait se dire que sur SNES a cette epoque (3 ans apres) il n'y avait peut etre pas d'interet économique a mettre une mémoire moins performante mais pourtant il le font sur l'audio RAM qui d'apres les réferences semble mieux correspondre a ce qu'on trouve pour la VRAM de la PCE donc pourquoi ne pas s'etre contenté de ca aussi pour la VRAM? a priori ca passe largement.

Pour la question PCE qui utilise de haut dot clock avec une VRAM finalement pas spécialement performante (si on oublie le contexte) j'avais aussi pensé a une autre idée notamment pour le mode 10.74mhz de la PCE qui pose le plus de probleme. Apres réflexion j'etais convaincu que pour ce mode la PCE n'utilisait la VRAM qu'a 5.37mhz car le VDC propose justement de pouvoir parametrer le timing d'acces a la VRAM avec notamment un mode ou y a seulement 4 slot d'acces pour 8 pixels au lieu de 8 et dans se mode ca collait parfaitement. Ca suffisait a tout fetcher meme le background en 512 et il reste 66 slots CPU (alors que le CPU peut en remplir que 65 sans trick) donc je me suis dit banco le dot clock 10.74mhz ne stress en rien la VRAM (mais restait quand meme le mode 7.16mhz) puis j'ai vérifié sur le jeux CD Sherlock Holmes (le seul en 512) et non meme pas, ils utilisent toujours le mode full acces a 8 slot par 8 pixels (vérifié aussi sur Ninja spirit en 352).
Donc non a priori ils en ont rien a carré de stresser la VRAM au dela de ses capacités sauf que sur PCE ca reste quand meme un peu particulier car entre chaque slot VDC y a un slot CPU donc si tu n'utilises pas les slots CPU (que tu ne peux pas tous utilisé de toute facon) alors la VRAM est finalement peut stressé pendant l'affichage (et probable que Sherlock ne fasse pas d'acces cpu), le stress c'est surtout pendant le Hblank ou le fetch des sprites se fait en full acces mais la aussi Sherlock semble avoir peu usage des sprites, faudrait verifier sur une vrai console si y a des sprites qui glitch parfois sur Sherlock.

Bref c'est compliqué de comprendre finalement comment se fait le choix de performance des RAM et sur quelle critère, c'est pas forcement intuitif.
Je remarque aussi que les WRAM sont en général plus performante que les VRAM (au moins du coté PCE et MD) alors que j'aurais pensé l'inverse vu que les VRAM sont potentiellement sollicité a des fréquences plus élevées (sur MD c'est kif kif) mais ca au moins ca peut s'expliquer par le faite que une erreur d'acces sur la VRAM ca va juste générer un glitch d'une frame invisible (D'ailleurs certain s'amuse a faire du circuit blending en court-circuitant massivement les VRAM MD, PCE... juste pour produire des glitch visuel ingame et tu peux toujours jouer en meme temps), alors qu'une erreur sur la WRAM ca plante la machine donc clairement ils faut une marge superieur sur la WRAM. Ca explique peut etre aussi pourquoi sur PCE ils hesitent pas a stresser exagérément la VRAM (mais sur SNES ils auraient pu se contenter d'une VRAM moins performante).

par Invité Mar 7 Juil 2015 - 13:58

Ouhahou, sacrés analyses thumleft

Je sais que la WRAM de la snes et une merde à bas coût qui bride le CPU, il aurait mieux valu mettre moins de RAM, style 32/64 ko, mais plus rapide .

Et pire que ca, je vais au bout de la demarche et me rend compte que la PCE utilise exactement le meme type de de RAM pour sa VRAM

Pour la simple raison que le VDC était prévu pour avoir un second bckgnd .

Je remarque aussi que les WRAM sont en général plus performante que les VRAM

Non la WRAM de la PCE est une 140ns, donc moins performante que la VRAM qui est à 100ns .
Et tu n'as aucune erreur ou glish sur PCE en 10.74 mhz, encore heureux, la VRAM fonctionne juste à 93 ns alors qu'elle est certifiée à 100, comme quand tu overclockes un PC .

Sur Md la contradiction vient du DMA, le 68k peut lui se contenter de RAM/ROM lentes, mais pas le DMA .

par Invité Mar 7 Juil 2015 - 14:01

Sérieux, vous voulez pas un topic genre [Analyses] ?
Pour conserver les aspects techniques à part, à l'abri, et en discuter peinard.

par Stef Mar 7 Juil 2015 - 14:08

Je sais que la WRAM de la snes et une merde à bas coût qui bride le CPU, il aurait mieux valu mettre moins de RAM, style 32/64 ko, mais plus rapide .

Encore une fois, ce n'est pas que la WRAM de la SNES est particulièrement lente, c'est le CPU qui est très exigeant dessus... y'a une bonne raison à la très faible quantité de WRAM sur la PCE (qui est de la SRAM).
Et je pense que côté marketing, il était impossible de proposer une machine 16 bits qui sort 2 ans après la MD avec moins de mémoire centrale (il en fallait au moins 64 Ko), elle se serait fait lyncher par tout les magasines...

Pour la simple raison que le VDC était prévu pour avoir un second bckgnd .

D'où tient tu cette info ? Et dans ce cas pourquoi avoir permis une modification du dot clock et tout les réglages d'accés mémoire ?

Je remarque aussi que les WRAM sont en général plus performante que les VRAM

Non la WRAM de la PCE est une 140ns, donc moins performante que la VRAM qui est à 100ns .

Je dirais que les VRAM sont bien plus performantes et couteuse que les WRAM... sauf sur PCE justement ! Où tu as besoin d'une SRAM à 140 ns (donc accés en 1 cycle quoiqu'il arrive) à cause du CPU.

Et tu n'as aucune erreur ou glish sur PCE en 10.74 mhz, encore heureux, la VRAM fonctionne juste à 93 ns alors qu'elle est certifiée à 100, comme quand tu overclockes un PC .

Ouais et comme tu overclockes un PC, ça ne fonctionne pas dans 100% des cas, je suis certain que certaines PCE ont quelques glitch (mais probablement à peine visible) lorsque tu utilises à VRAM au delà de sa certification.

Sur Md la contradiction vient du DMA, le 68k peut lui se contenter de RAM/ROM lentes, mais pas le DMA .

Le 68000 a besoin d'un RAM à 1.92 Mhz, le DMA a besoin d'environ 3.24 Mhz mais uniquement pour un transfert vers la CRAM ou VSRAM, ce qui est carrément secondaire. Si on se contente du DMA en VRAM, c'est encore moins exigeant que le CPU.

par Stef Mar 7 Juil 2015 - 14:10

onels4 a écrit:Sérieux, vous voulez pas un topic genre [Analyses] ?
Pour conserver les aspects techniques à part, à l'abri, et en discuter peinard.

Franchement je te comprends pas, l'aspect technique est le seul truc intéressant dans ce genre de topic...
Mais effectivement vu que le topic est rempli de pipi / caca il serait peut être bon de faire un gros tri des informations pertinentes et les regrouper dans un topic à part :) Le truc c'est que le topic doit bien faire 1000 pages, y'a un amateur pour cette lourde tâche ? Mr. Green

par upsilandre Mar 7 Juil 2015 - 14:16

onels4 a écrit:Sérieux, vous voulez pas un topic genre [Analyses] ?
Pour conserver les aspects techniques à part, à l'abri, et en discuter peinard.

je viens de penser que ca pourrait etre sur la section "maladies généralisées" comme ca se sera plus ouvert en terme de plateforme (deja que la PCE n'est pas censé etre ici).
Mais je sais pas trop comment débuter un topic comme ca alors que c'est une sorte de conversation continu et qui va forcement faire réference en grande partie a tout ce qui a deja ete dit sur ce topic la. Peut etre mettre le lien de ce topic en premier post? deplacer quelques posts?

par Invité Mar 7 Juil 2015 - 14:18

Ce que vous voulez, perso l'idée c'est de préserver des données intéressantes et leur donner plus de visibilité. Very Happy

par airdream Mar 7 Juil 2015 - 14:23

moi j'aurai prefere que ca reste ici, m'enfin bon meme si ca doit "demenager" je suivrai quand meme!!

par upsilandre Mar 7 Juil 2015 - 14:34

TOUKO a écrit:
Je remarque aussi que les WRAM sont en général plus performante que les VRAM
Non la WRAM de la PCE est une 140ns, donc moins performante que la VRAM qui est à 100ns .
Et tu n'as aucune erreur ou glish sur PCE en 10.74 mhz, encore heureux, la VRAM fonctionne juste à 93 ns alors qu'elle est certifiée à 100, comme quand tu overclockes un PC .

Sauf que justement ca correspond pas a mes recherches.
Référence WRAM PCE: HSRM2264LM10 (22 pour SRAM, 64 pour 64Kbit, 10 pour 100ns acces time)
Référence VRAM PCE: HSRM20256LM12 (20 pour PSRAM, 256 pour 256Kbit, 12 pour 120ns acces time)

Sans parlé du fait que la SNES utilise de la VRAM 100ns (HY62256ALJ-10, LH52A256N-10LL, MS62256CL-10FC) alors qu'elle en a pas du tout besoin a priori si on reduit la question a ce type de calcule.
Sur MD la WRAM c'est de la 10 (100ns) a part dans une seconde révision ou c'est de la 12 et la VRAM c'est de la 12 (120ns) mais comme on a expliqué elle est sollicité a max 3.35mhz donc c'est cohérent avec la SNES et ses 5.37mhz mais placer la PCE la dedans avec ses 10.74mhz c'est plus compliqué (un peu moins si on prend en compte les choses que j'ai evoqué). Faut dire aussi que les chiffres d'acces time sont toujours des chiffres max en général.
Apres faudrait peut etre regarder plus en details les autres caractéristiques de ces RAM (ou des GPU) mais trouver des datasheet c'est presque impossible et je ne saurais pas bien les analyser. On est au limite de ce qu'on peut en dire je pense. A priori c'est juste que la PCE stresse au max la VRAM meme audela de ce qui est conseillé (au moins pour le 10.74mhz mais au final pas utilisé de toute facon et il existe une solution en paramétrant differement le timing des acces VRAM avec le registre 09) alors que sur les autres y a une grosse marge. Et puis aussi lié aussi au fait je pense qu'il y a peut etre pas tant de choix de référence et de performance de RAM que ca et que donc tu prend ce qu'il y a meme si c'est sensiblement au dessus des perfs que tu as besoin.

par upsilandre Mar 7 Juil 2015 - 14:49

Stef a écrit:
Je dirais que les VRAM sont bien plus performantes et couteuse que les WRAM... sauf sur PCE justement ! Où tu as besoin d'une SRAM à 140 ns (donc accés en 1 cycle quoiqu'il arrive) à cause du CPU.

C'est ce que je me disais aussi mais finalement j'ai l'impression qu'il y a plutot un equilibre entre WRAM et VRAM mais pour des raisons differentes.
WRAM sollicité a des frequences plus basses (sauf sur PCE) mais bien plus sensible aux erreurs qui sont critique.
VRAM sollicité a des frequences plus elevées mais tres peu sensible aux erreurs qui sont inconséquentes.
Du coup au final les choix de performance ont l'aire un peu kif kif entre WRAM et VRAM.

par Invité Mar 7 Juil 2015 - 15:08

D'où tient tu cette info ? Et dans ce cas pourquoi avoir permis une modification du dot clock et tout les réglages d'accés mémoire ?

Et le rapport là dedans ??
quand tu passes de H32 en H40 sur Md, tu modifies pas le dot clock peut être ??
Et a part le dotclock je comprends pas ce que tu entends par "modifier tout les accès mémoires" .

Je dirais que les VRAM sont bien plus performantes et couteuse que les WRAM... sauf sur PCE justement ! Où tu as besoin d'une SRAM à 140 ns (donc accés en 1 cycle quoiqu'il arrive) à cause du CPU.

Pour toi une mémoire à 140 ns et plus chère et plus performante que la même en 100ns ??
Le VDC fait ses accès à la VRAM en 1 VDC cycle , et à 10.74 mhz tu as donc besoin d'une mémoire à 93 ns .

Voire même un word /cycle d'après charles mc donalds:

During the active display period of a scanline, the VDC can do one 16-bit access to VRAM on each cycle of the dot clock.

Ouais et comme tu overclockes un PC, ça ne fonctionne pas dans 100% des cas, je suis certain que certaines PCE ont quelques glitch (mais probablement à peine visible) lorsque tu utilises à VRAM au delà de sa certification.

Tu pense bien qu'ils allaient pas proposer un mode 10.74mhz sachant que ça poserait des problèmes à la VRAM non ..
C'est comme la backup ram, tu es censé y accéder en mode 1.79 mhz via le CPU, et bien ça pose aucun soucis de la faire en 7.16 .

Le 68000 a besoin d'un RAM à 1.92 Mhz, le DMA a besoin d'environ 3.24 Mhz mais uniquement pour un transfert vers la CRAM ou VSRAM, ce qui est carrément secondaire. Si on se contente du DMA en VRAM, c'est encore moins exigeant que le CPU.

Quand tu prévoit un transfert vers des mémoire rapide tu es obligé d'avoir de la mémoire qui tient la route des 2 côtés, l'utilisation de rom lentes t'oblige à ne pas utiliser ton DMA pour certains transferts .
Bien sur tu peux aussi mettre de la ROM ultra lente et ne pas utiliser de DMA du tout, mais si tu veux utiliser la console entièrement t'as pas le choix .

Sauf que justement ca correspond pas a mes recherches.

Sauf que si tu calcules bien il te faut de la mémoire à 140ns pour le cpu @7.16mhz .

The fundamental unit of time observed by the VDC is the duration of one pixel clock cycle. The pixel clock is output by the VCE and can be any of the following:

5.3693175 MHz - ~186 ns per pixel

7.15909 MHz - ~140 ns per pixel

10.738635 MHz - ~93 ns per pixel

The PCE uses 100ns SRAM chips as it's video RAM, so the only situation that is problematic is using a 1-cycle pixel width along with the 10.738635 MHz pixel clock. In this case each cycle is ~93 ns which violates the minimum access time requirements of the SRAM. In practice this does not cause any problems, however it does mean operating the memory 7% faster than it's guaranteed to work.

par upsilandre Mar 7 Juil 2015 - 15:19

TOUKO a écrit:Tu pense bien qu'ils allaient pas proposer un mode 10.74mhz sachant que ça poserait des problèmes à la VRAM non ..

En meme temps un glitch visible pendant seulement 16ms y a peu de chance de le voir (d'autant qu'au final les jeux n'utilisent pas ce mode donc on peut pas en dire grand chose).
Le fait est que acceder a la VRAM a 10.74mhz est de toute facon hors des limites conseillés (120ns pour la VRAM, meme si c'etait 100ns).
Mais de toute facon comme j'ai dis le VDC a prevu le coup puisque y a un mode qui permet d'acceder a la VRAM a 5.37mhz avec un dot clock a 10.74mhz et qui suffit tres bien pour le mode 512 pixels (mais personne ne l'a utilisé).

par upsilandre Mar 7 Juil 2015 - 15:26

TOUKO a écrit:Sauf que si tu calcules bien il te faut de la mémoire à 140ns pour le cpu @7.16mhz .

Je sais pas ce que tu as voulu dire
oui faut 140ns et a priori la WRAM PCE c'est de la 100ns donc oui ca va y a une marge raisonnable (meme si c'est moins de marge que sur MD par exemple).

The fundamental unit of time observed by the VDC is the duration of one pixel clock cycle. The pixel clock is output by the VCE and can be any of the following:

5.3693175 MHz - ~186 ns per pixel

7.15909 MHz - ~140 ns per pixel

10.738635 MHz - ~93 ns per pixel

The PCE uses 100ns SRAM chips as it's video RAM, so the only situation that is problematic is using a 1-cycle pixel width along with the 10.738635 MHz pixel clock. In this case each cycle is ~93 ns which violates the minimum access time requirements of the SRAM. In practice this does not cause any problems, however it does mean operating the memory 7% faster than it's guaranteed to work.

Ce document je l'ai lu des tonnes de fois sauf que justement ca colle pas avec la reference inscrites sur des chips de la console, la VRAM de la PCE n'est ni de la SRAM ni du 100ns (je viens de réalisé du coup que c'est ce document qui m'a induit en erreur depuis le debut), c'est des chip de PSRAM a 120ns. Il peut y avoir eu quelques approximations dans ce document c'est possible.

par Invité Mar 7 Juil 2015 - 15:28

En meme temps un glitch visible pendant seulement 16ms y a peu de chance de le voir (d'autant qu'au final les jeux n'utilisent pas ce mode donc on peut pas en dire grand chose).

J'ai fait une adaptation de flappy bird sur SGX en 512x224, elle vaut se qu'elle vaut, mais ne pose aucun problème sur le vrai hard .

Le fait est que acceder a la VRAM a 10.74mhz est de toute facon hors des limites conseillés (120ns pour la VRAM, meme si c'etait 100ns).

Si c'était le cas on serrait bien au dessus des 7% de plus avec de la vram seulement à 120ns réel comme tu le pense ,et ça serrait surement pas exploitable, trop de problèmes .

Mais de toute facon comme j'ai dis le VDC a prevu le coup puisque y a un mode qui permet d'acceder a la VRAM a 5.37mhz avec un dot clock a 10.74mhz et qui suffit tres bien pour le mode 512 pixels (mais personne ne l'a utilisé).

Non le VDC est prévu pour utiliser des mémoires plus lentes si besoin, donc tu as un accès en 2bp, ou la possibilité d'avoir un refresh avec l'utilisation de DRAM .
C'est pas utilisé, car ça sert à rien tout simplement .

c'est des chip de PSRAM a 120ns. Il peut y avoir eu quelques approximations dans ce document c'est possible.

Je poserai la question, mais pour moi ça n'a aucun intérêt tant la marge d'erreur devient alors grande .

par upsilandre Mar 7 Juil 2015 - 15:54

TOUKO a écrit:
Si c'était le cas on serrait bien au dessus des 7% de plus avec de la vram seulement à 120ns réel comme tu le pense

C'est pas ce que je "pense" c'est juste ce qu'il y a ecrit sur le chip, j'y peux rien, j'ai l'impression que tu fais une confiance aveugle a ce document (moi aussi je serais tenté car le document est tres bon mais le fait est que ca colle pas bien ici, et pourquoi il ecrit aussi que c'est de la SRAM? en fait c'est comme si il avait confondu avec la WRAM qui est comme par hasard de la SRAM 100ns justement).

Non le VDC est prévu pour utiliser des mémoires plus lentes si besoin, donc tu as un accès en 2bp, ou la possibilité d'avoir un refresh avec l'utilisation de DRAM .C'est pas utilisé, car ça sert à rien tout simplement .

Ca aussi c'est mot pour mot ce qui a ecrit dans le document mais on peut tenter quand meme d'y faire un peu abstraction, chaque document a ses approximations. Moi je vois ce parametrage supplémentaire aussi comme un mode parfaitement pensé pour le dot clock 10.745mhz

Si t'as fait un flappy bird en 512 c'est génial ca veut dire que tu peux tester ca facilement. j'imagine que dans ton registre 09 (VDC) les 4 premiers bit sont donc a 0 , si tu pouvais modifier et mettre 5 et voir ce que ca donne ca serait cool. Normalement (si tu utilises pas de trick farfelu pendant l'affichage) ca devrait toujours fonctionner aussi bien sauf que la VRAM est alors sollicité a 5.37mhz au lieu de 10.74mhz (meme si comme tu dis ca passe quand meme en 10.74mhz ca me paraîtrait plus judicieux d'utiliser ce mode en 10.74mhz si ca marche, ca serait intéressant de savoir par curiosité).