VDP 128Kb Extended VRAM mode

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

User avatar
TmEE co.(TM)
Very interested
Posts: 2320
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » 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.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

ob1
Very interested
Posts: 407
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Tue May 07, 2013 1:04 pm

Wow !
What an insanely great topic of knowledge !!!
Congrats to all !!

Could it be implemented in an emulator ?
Charles MacDonald wrote:And if they had brought out the digital video bus to a connector we could have gotten a palette upgrade too.
Why ? Or how ?
And, also, could it be implemented in an emulator ?
A "Mode 3" Genesis (à la SuperNES) ?

http://en.wikipedia.org/wiki/Super_Nint ... stem#Video

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Tue May 07, 2013 9:40 pm

Why ? Or how ?
And, also, could it be implemented in an emulator ?
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.

In Sega's C2 arcade system which uses the Genesis VDP, they connected these pins to 16K of color RAM and a DAC. This gave 128 colors (64 for backgrounds, 64 for sprites) displayable out of 32K colors (5:5:5 RGB). So you'd have regular Genesis graphics, but with much more colors and a greater color depth. In this case, the CRAM wasn't used at all, it was completely bypassed.

On the Genesis they didn't even connect those pins to the cartridge connector or expansion connector, so there was no way to utilize them. If they had, a Genesis upgrade could have added more colors.

For example if those signals were available on the cartridge port, the 32X wouldn't have needed that video pass-through cable.

Or if they were on the expansion connector, the Sega CD could have been designed to mix its own "mode 7" video layer with the Genesis graphics, and there wouldn't have been a need to transfer that data to VRAM via DMA. It could have had a much higher frame rate that way.

In both cases some extra hardware would have been needed to 'snoop' CRAM writes for compatibility with games that didn't use these theoretical upgrades, but that's not hard to do.

A lot of potential, too bad it wasn't used. :)

User avatar
Huge
Very interested
Posts: 185
Joined: Sat Dec 13, 2008 11:50 pm

Re: VDP 128Kb Extended VRAM mode

Post by Huge » Thu Dec 10, 2015 12:26 am

This reminds me, the recent Megadrive Collected Works has had an interview with the Megadrive hardware designer, Masami Ishikawa, where he talks a bit about the 128Kb VRAM mode. Apparently it was added as an experiment to significantly increase performance, but in the end it unfortunately didn't. Which might explain why in 128Kb mode, the VRAM is interleaved.

Here's the interview in question:
Image

User avatar
TmEE co.(TM)
Very interested
Posts: 2320
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by TmEE co.(TM) » Thu Dec 10, 2015 9:12 am

The main thing about the 128KB mode is that all VRAM access has twice the bandwidth, including DMA :D
Mega CD games, Virtua Racing and 3D games could easily reach 50/60Hz speeds...
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
Stef
Very interested
Posts: 2788
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by Stef » Thu Dec 10, 2015 9:59 am

TmEE co.(TM) wrote:The main thing about the 128KB mode is that all VRAM access has twice the bandwidth, including DMA :D
Mega CD games, Virtua Racing and 3D games could easily reach 50/60Hz speeds...
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.

Here is the exchanges we had (in french) :
Stef 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.
Je regardais aussi les schéma et je pense avoir enfin compris comment fonctionne la VRAM sur MD
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)
then
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) ?
La franchement je vois pas trop comment.
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)

User avatar
TmEE co.(TM)
Very interested
Posts: 2320
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by TmEE co.(TM) » Thu Dec 10, 2015 12:23 pm

It is already verified by some people (the Titan demo guys) that DMA bandwidth is doubled. The second VRAM chip is in parallel with existing one, giving 16bit VRAM bus, and DMA or VRAM access cycle will write both bytes of the word at the same time rather than just one of them. CRAM and VSRAM are natively 16bit, and each cycle will always transfer 16bits, in 128KB mode VRAM becomes 16bit too.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
Stef
Very interested
Posts: 2788
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by Stef » Thu Dec 10, 2015 3:28 pm

Ok, that was my first theory... so we basically really double the data BUS (4 bits to 8 bits for the random port which is used for writes), that is :)
I really wonder why Sega decided to not add it then because it definitely bring a very nice performance boost (both in storage and speed) !
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.

User avatar
TmEE co.(TM)
Very interested
Posts: 2320
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by TmEE co.(TM) » Thu Dec 10, 2015 7:16 pm

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. In 128KB mode both bytes go to VRAM at once. 128KB mode makes VRAM 16bit wide rather than keeps it at 8bits and it is why you cannot enable the mode without GFX getting messed up unless you have extra VRAM physically present.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Mask of Destiny
Very interested
Posts: 572
Joined: Thu Nov 30, 2006 6:30 am

Re: VDP 128Kb Extended VRAM mode

Post by Mask of Destiny » Thu Dec 10, 2015 9:09 pm

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

I'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.

User avatar
Stef
Very interested
Posts: 2788
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by Stef » Thu Dec 10, 2015 10:36 pm

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.
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.
Also in Sega technical bulletin they explain that when we do ROM to VRAM DMA, we should trigger the DMA command from main RAM else the system can lockup. I wonder if this have to do with slow rom speed.
I'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.
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 VRAM ;)

User avatar
TmEE co.(TM)
Very interested
Posts: 2320
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by TmEE co.(TM) » Fri Dec 11, 2015 11:16 am

Mask of Destiny wrote:The duration of individual memory requests is identical though which is probably what you meant.
Yes, that's what I meant. Memory access speed. It remains same, but bandwidth doubles.

DMA crash if you don't trigger it from RAM and Z80 missing data when when controllers are read are directly related to ROM speed, there's diagrams in the tech bulletins showing how access cycle can shorted in those cases and early ROMs were on the brink of being too slow and would have experienced issues. That probably stopped being an issue later on and definitely isn't as issue with modern flashcarts and such that have under 100ns speed memory chips in them.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
Sik
Very interested
Posts: 719
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by Sik » Sun Dec 13, 2015 6:12 pm

Something to take into account: this was a last ditch attempt to improve the VDP after they had trimmed out a lot of features (it was in response to the then recently announced Super Famicom specs). So yeah, it probably just went away when cutting costs.

As for why they may have thought it gave no benefit: well, it's hard to argue that being able to transfer 14KB in vblank time (instead of 7KB) is not a huge benefit. 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. And then recall that RAM is only 64KB, and that originally they were reporting the maximum ROM size as just 1MB (1/4 the final size). Suddenly things start making sense I guess?

Considering the size of tilemap tables though it still could have been really useful for 2.5D games even with those restrictions, honestly, but I guess that wasn't worth enough for the added cost.
Sik is pronounced as "seek", not as "sick".

User avatar
TmEE co.(TM)
Very interested
Posts: 2320
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by TmEE co.(TM) » Sun Dec 13, 2015 6:59 pm

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.
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.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
Stef
Very interested
Posts: 2788
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: VDP 128Kb Extended VRAM mode

Post by Stef » Mon Dec 14, 2015 10:09 am

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.
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.
In 64 KB mode any words wrote to the FIFO require 2 bytes write slots to be sent to the VRAM so when you do DMA to VRAM the FIFO is getting filled faster than it can be emptied and stall occurs so ROM is less stressed. In 128 KB mode we assume VRAM can be wrote as CRAM or VSRAM (word write) so definitely it requires more 'bandwidth' from ROM, earlier ROM did not supported CRAM to ROM DMA (you had to do it from RAM instead) so that would have been an issue to have 128 KB for that reason (or they required to cap DMA speed then).

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests