Posted: Tue May 07, 2013 6:02 am
It is one of those chinese decap copies that are equivalent to real part in every way. I am using the clone here because of the infinitely better PCB layout.
Sega Megadrive/Genesis development
http://gendev.spritesmind.net/forum/
http://gendev.spritesmind.net/forum/viewtopic.php?f=22&t=1368
Why ? Or how ?Charles MacDonald wrote:And if they had brought out the digital video bus to a connector we could have gotten a palette upgrade too.
The VDP has a set of signals that carry information about the pixels as they are displayed, before their colors are looked up in color RAM. These signals are available on some VDP pins which are left unconnected in the Genesis.Why ? Or how ?
And, also, could it be implemented in an emulator ?
That is what i first believed because you are kindy doubling the data bus by using extra memory chip but talking with a techy guy he told me it would not have improved the VRAM dma speed after all, because the dual port memory is already used to its max, where serial port is used to fetch data from VRAM and the random port is used for write operation, this one limits the maximum write speed to 205 bytes / line.TmEE co.(TM) wrote:The main thing about the 128KB mode is that all VRAM access has twice the bandwidth, including DMA
Mega CD games, Virtua Racing and 3D games could easily reach 50/60Hz speeds...
thenJe regardais aussi les schéma et je pense avoir enfin compris comment fonctionne la VRAM sur MDStef a écrit:
Pour la VRAM sur MD, elle est déjà dual port en fait. Quand Sega a désigné sa MD le choix de la VRAM était vraiment crucial et ils ont choisi un type de mémoire qui était tout nouveau à l'époque (dual port dynamic ram). Sauf erreur il me semble qu'en fait tu as un port série 4 bits (très rapide) ainsi qu'un port parallèle 4 bits (plus lent mais adapté pour le random access) et toute la logique du VDP de la MD a été pensé pour maximiser l'utilisation de ces 2 bus. En regardant le schéma de connexion de la VRAM au VDP, j'ai l'impression qu'en doublant la quantité de VRAM (128 KB) tu doubles directement la largeur du BUS de celui-ci (4+4 bits à 8+8 bits) et donc tu multiplies par 2 les débits, le tout sans rien changer côté VDP (pas de pin supplémentaires) si ce n'est le clock. Le design du VDP a été fait de tel manière à pouvoir gérer 128 KB de mémoire mais je pense que Sega est resté sur 64 KB pour des raisons de cout.
Sur chacun des chip memoire y a pas un seul bus de donnée 4bit (x2) mais effectivement 2 port 4bit (et un bus d'adressage 8bit). Un port "random" 4bit (x2 car y a 2 chip) pour des acces aléatoire classique en lecture et ecriture.
Et un second port 4bit (x2) "serial" (mais faut l'entendre dans le sens "streaming", c'est un port pour lire une serie de donnée 4bit contigu) qui ne peut etre utilisé qu'en lecture. il passe par un buffer interne de 1024bit (un registre) qui est automatiquement chargé en interne dès que possible.
Par contre le bus d'adressage est seulement 8bit, il est multiplexé, faut donc 2 cycle pour l'adressage du coup sur le port "random" la frequence de lecture ou d'ecriture est divisé par 2. A l'inverse sur le port "serial" on utilise effectivement 2 cycles au depart (un pour selectionner la page de 1024bit qui va etre chargé dans le registre et un second pour placer un pointeur sur ce registre) mais ensuite y a plus besoin du bus d'adressage, on lit en streaming la page et les suivantes se charge automatiquement du coup la on peut lire a plein debit.
Maintenant quand on regarde comment c'est cablé sur la MD on voit que le port "random" n'est pas cablé au bus de donnée 8bit du VDC mais uniquement sur le bus d'adressage 8bit du VDC (qui lui meme est évidement aussi cablé sur le bus d'adressage 8bit du chip mémoire) et donc le bus d'adressage du VDC est apparemment utilisé ici pas seulement pour multiplexé l'adressage du chip memoire mais multiplexe aussi les data destinées au port random. Du coup faut 2 cycle pour l'adressage + un cycle pour ecrire sur le port random (et peut etre donc un 4eme cycle a vide).
Alors pourquoi ils ont pas cablé le port random sur le bus de donnée du VDC et eviter un multiplexage suplementaire? je sais pas si le port "random" est utilisé uniquement en ecriture ou aussi en lecture (toujours par le bus d'adressage du VDC) mais dans ce second cas ca voudrait dire que le VDC pourrait en lecture cumuler le debit des 2 ports (dans cas ca serait plus vraiment une VRAM 8bit mais 2x8bit).
A coté le port "serial" lui est bien directement connecté au bus de donné 8bit du VDC et par definition il ne peut etre utiliser qu'en lecture (et donc le bus de donnée du VDC du coté VRAM est utilisé uniquement en lecture) mais ce port peut vraiment etre lu a la frequence du bus dans le cas ideal (sauf au moment d'initialiser la page a streamer) donc environ 4x plus vite que pour l'ecriture dans ce contexte du cablage MD.
Et la du coup tout s'explique! y a plus aucun mystere. Si le DMA ne peut ecrire que 205o/s alors que pendant l'affichage le VDC s'alimente bien plus vite c'est pas une histoire de bus de donnée 8bit mais bien parce que l'ecriture est effectivement bien plus lente que la lecture (a cause du multiplexage) et ces 205o/s c'est simplement le max que permet ces chips memoires et ce cablage. Et pareille pour le VRAM > VRAM a 102o/s (qui correspond donc a un debit 102+102) qui est bridé par l'ecriture.
En fait c'est vraiment une configuration de buffer video avec des memoires dédié a cela (la ou sur les autres consoles c'est des mémoires standard) qui donc mise a fond sur la lecture et délaisse l'ecriture qui n'est pas determinant dans ce contexte (juste ce qu'il faut pour faire deja mieux que la concurrence en DMA, pas besoin de plus en ecriture).
Donc au final c'est plutot un choix bien equilibré et efficace car il sagit pas juste de reduire le bus de donnée a 8bit mais aussi le bus d'adressage qui est 8bit. Et puis au final y a donc pas de gachie au niveau du DMA, c'est juste la consequence du choix au niveau VRAM.
Je me sent un peu mieux car je comprenais pas la logique autour de ce DMA MD, la c'est plus claire (mais y aurait sans doute d'autre truc intéressant a creuser)
La franchement je vois pas trop comment.Je vois que tu as bien creusé la chose, j'avoue ne pas avoir autant regardé en détail. Mais du coup, est-il vraiment possible de doubler le débit en utilisant 128 KB de VRAM (et donc en doublant le nombre de chip) ?
Je suis presque sur que les 2 ports sont deja utilisé sur MD (et au mieux) sinon je vois pas l’intérêt d'avoir cablé le port "random" sur le bus d'adressage du VDC plutot que sur le bus de donnée si ce n'est pour simuler un second bus de donnée (en multiplexage) et donc pouvoir l'utiliser en simultané.
Et puis quand on dit simultané c'est un bien grand mot, le port random est effectivement dispo tant que tu fait vraiment du streaming sur le buffer du port "serial", dès que le port "serial" a besoin d'acceder a une nouvelle donnée ailleurs (donc de facon random) il bloque l'autre port et finalement dans le cas de la MD y a pas trop d'occasion de vraiment streamer sur de gros bloc.
Tout ca pour dire que le second port peut etre un soutient mais il est pas la pour doubler le debit pour repondre a ta question (et de toute facon certainement deja utilisé sur MD)
Je suis d'ailleurs presque sure que pour les acces manuel a la VRAM par le CPU ou les acces DMA tout passe par le port "random" (et donc par la aussi que passe les 18 octets qu'on peut insérer pendant l'affichage). Le port "serial" limité a la lecture est l'exclusivité du VDC je pense.
le port "serial" a vraiment un cycle tres court quand il est en streaming (puisqu'il tape dans un registre) c'est apparemment 40ns, alors que le port "random" (qui est le port DRAM en quelque sorte) lui est au moins 3x plus lent (et de toute facon imposé par le multiplexage qui nécessite 3 cycles par acces, la question c'est plutot de savoir si ils en utilisent aussi un 4eme mais je pense pas).
Du coup je commence a me demander si la frequence de la mémoire est pas plutot 3x le dot clock (20mhz). Ca serait vraiment intéressant de connaitre la clock entre le VDC et la VRAM parce que sans ca on restera dans le flou. (y a une master clock a 20mhz quelque part?)
Le truc a retenir au moins c'est que la lecture se fait dans tout les cas bien plus rapidement que l'ecriture. C'est pas du tout symetrique, je dirais que c'est la principale caractéristique a retenir sur la VRAM de la MD. (et qu'il est peut etre galvauder de parler de VRAM 8bit, c'est plus complexe que ca, y a probablement un second bus de donnée 8bit caché dans le multiplexage du bus d'adresse. Donc on le voit pas sur le cablage mais il est la)
DMA always starts out reading values from the cartridge at the maximum speed and only slows down for the VRAM case when the FIFO gets full. If a cartridge isn't fast enough for 16-bit wide DMA targets it's not fast enough for DMA at all except for the special case in which the FIFO is already full.Stef wrote:How about ROM speed then ? i guess earlier ROM were not fast enough to maintain the 16 bit VRAM DMA rate then, that may explain why Sega chosen to stuck with 64 KB.
This is perhaps a bit pedantic, but the effective speed is roughly doubled for 16-bit wide DMA targets as the FIFO gets emptied as fast as it is filled (slightly faster actually since a refresh cycle causes two reads to get skipped, but only one write IIRC). The duration of individual memory requests is identical though which is probably what you meant.TmEE co.(TM) wrote:Speed remains same, just every cycle transfers both bytes not just one of them. DMA is always same speed, but VRAM only uses one byte of the two per access cycle while CRAM and VSRAM use both bytes.
Indeed that point always bothered me as i'm almost certain older rom were to slow just to maintain ROM to CRAM DMA... I wonder why the first 5/6 words are correctly read up from ROM during ROM to VRAM DMA as they are indeed read at full speed.Mask of Destiny wrote: DMA always starts out reading values from the cartridge at the maximum speed and only slows down for the VRAM case when the FIFO gets full. If a cartridge isn't fast enough for 16-bit wide DMA targets it's not fast enough for DMA at all except for the special case in which the FIFO is already full.
Too bad they modified the whole design just for that then abandoned the idea, still i think having more CRAM would have be a lot more useful than more VRAMI'm going to guess the reason for not going with 128KB was that memory was expensive then (and I imagine fancy dual ported VRAMs even more so) and the benefit was considered too small for the cost. The extra bandwidth is obviously very welcome for things like video and software rendering, but I'm guessing for the games they had in mind (i.e. the kind of stuff on Sega's arcade hardware at the time of development), it didn't make a big enough difference.
I wonder how much die area the support for the extra RAM chip consumes and if they would have had space for either more CRAM entries or more bits per channel in the existing entries if the extra RAM support had been omitted.
Yes, that's what I meant. Memory access speed. It remains same, but bandwidth doubles.Mask of Destiny wrote:The duration of individual memory requests is identical though which is probably what you meant.
Access speed remains same so there will not be any problems compared to the 64KB mode. In 64KB mode DMA only uses one by of each access and it doesn't cache the second byte so it could skip an access or have longer accesses. In 128KB mode single access uses both bytes, but duration remains same as 64KB mode.However, also remember that it seems early ROMs had trouble keeping with DMA at all in the first place... imagine if they had to keep it at double the pace.
O_o ? When you use DMA to VRAM the memory is read as word and both bytes are used, you don't have byte granularity when writing VRAM (it's a bit unfortunate but that it understandable and also very useful to write table attributes). It's why you also have to set the address increment register to '2' when DMAing to VRAM.TmEE co.(TM) wrote: In 64KB mode DMA only uses one by of each access and it doesn't cache the second byte so it could skip an access or have longer accesses. In 128KB mode single access uses both bytes, but duration remains same as 64KB mode.