This thread makes me laugh...
EDIT :
I am not as infinitely familiar with SNES as I am with MD and SMS but here goes :
Sprite setup is a lot more flexible on MD. You get grouping and chaining from hardware, all the tile layout is linear, you can use any of the 16 possible sizes at any time on any sprite. Sprites can use all of VRAM and coordinates are all flat. You can multiplex sprites too if you can fit at least one VRAM write next to sprite table changes, or the internally cached table is not updated. I could fill 32 x 240 area with just one sprite.
VRAM can be updated any time on MD, you will never get missed writes or reads. There is a 4 stage FIFO on the data port too so you can freely blast in small bursts of data during active scan time. Though when FIFO is overflowed the CPU is stalled. There are 18 access slots per line in active scan, one slot every 16 pixels, and one VRAM refresh cycle every 16 pixels, so only 3 slots per 64 pixels. In passive scan you can never overwhelm the FIFO, the VDP can take one access every 2 pixels, totalling 198 slots per line (with refresh slots every 64 pixels as before). DMA can use up ALL the access slots because it is VDP itself that is doung it.
There's 313 lines in 50Hz and 262 lines in 60Hz, which of 224 or 240 (only possible in 50Hz) are active. That gives such kind of figures on VDP access :
Code: Select all
+------------+---------+--------+
| Line width | Passive | Active |
+------------+---------+--------+
| 256 pixels | 161 | 16 |
| 320 pixels | 198 | 18 |
+------------+---------+--------+
+----+------------+---------+---------+---------+
| Hz | Resolution | Passive | Active | Total |
+----+------------+---------+---------+---------+
| 60 | 256 * 224 | 6118 | 3584 | 9702 |
| | 320 * 224 | 7524 | 4032 | 11556 |
+----+------------+---------+---------+---------+
| 50 | 256 * 224 | 14329 | 3584 | 17913 |
| | 320 * 224 | 17622 | 4032 | 21654 |
| | 256 * 240 | 11753 | 3840 | 15593 |
| | 320 * 240 | 14454 | 4320 | 18774 |
+----+------------+---------+---------+---------+
Number of tiles that can be transferred :
+----+------------+---------+---------+---------+
| Hz | Resolution | Passive | Active | Total |
+----+------------+---------+---------+---------+
| 60 | 256 * 224 | 191 | 112 | 303 |
| | 320 * 224 | 235 | 126 | 361 |
+----+------------+---------+---------+---------+
| 50 | 256 * 224 | 447 | 112 | 559 |
| | 320 * 224 | 550 | 126 | 676 |
| | 256 * 240 | 367 | 120 | 487 |
| | 320 * 240 | 451 | 135 | 586 |
+----+------------+---------+---------+---------+
The numbers in 50Hz are pretty big compared to 60Hz. I would love to see exact numbers of SNES PPU access.
One other cool thing that you can do with the VDP is displaying a 512 color flat bitmap at cost of reduced CPU time (proportional to bitmap size). You set up the DMA to Color RAM and put auto-incremeth value to Zero. Now you overwhelm the FIFO to gain synchronity to the VDP, disable VDP rendering and start a DMA transfer. This gives you a 198 or 161 pixel wide flat bitmap with pixel format like this :
It is nicely 16 bits too and what 68K can deal with very well. Only problem is that these CRAM pixels are 2 screen pixels wide, with a 4 pixel wide CRAM pixels where VRAM refresh slots are. There are 4 refresh cycles visible, and some in normally invisible screen area.
This method also allows to show full screen image, 288 lines in 50Hz and 240 lines in 60Hz. But as said earlier the CPU is halted during this time so it is pretty much limited to slide shows when the image is large. You also cannot start the bitmap during passive scan as you cannot overwhelm the FIFO, you can only do it in active scan.
This is a lot more useful in MegaCD applications though where the other CPU can render a new bitmap while MD side is displaying one.
Cycle counting is impossible, MD is an async design. One Z80 or VDP access or interrupt is enough to ruin all the precision.
Are there any artifacts on SNES when you update a Color RAM entry midline ? On MD you get one pixel in the access slot point with the color of the color being written to the CRAM. This is because the CRAM is single port and you either have missed write or missed read. Write happens and when the color is read the value being written to is read instead.
...and now I remembered one more thing... bitplanes. They allow for some neat things but compress badly and are pain to render into when you want to.
Without these there would be no 2bpp BG layers modes though... When I work on SMS I wish there were none of that, so I could do some nice optimizations and VRAM use and rendering and tile management. I may be too accustomed to packed pixels though.
Z80 in MD is primarly meant for sound management. Unlike the SPC unit, Z80 has full access to ROM and limited access to RAM at all times with no restrictions besides the stupid serial banking register. I can access all the ROM space with no involvement from 68K side.
Communication between 68K and Z80 are a bit more complicated because 68K RAM access is restricted, you can only clear a value in it due to bus timing issues. 68K cannot see Z80 RAM at all, until Z80 bus is requested which stops Z80. Then 68K can see ALL the Z80 RAM (and use YM2612, it is on same bus as Z80).
The RAM at Z80 side is pretty much only for holding the sound driver, you do not need to put any music or SFX data there, you can read it off ROM directly.
As for as sound generation goes, synthesis has its pluses and minuses. Certain sounds are impossible to make without using whole chip for that sound (orchestra hits), but most stuff is. My most I mean it. FM is extremely versatile and powerful, but with about 50 parameters per sound it gets overwhelming when you don't know what you are doing. ADSR of the FM chips is more natural in a way that sound is not forced back to zero on a new note, like it seems to be on the SPC. When you tap a key or string on an instrument the sound gets louder and louder and wont go silent for a moment. You have to use software envelopes to overcome that on the SPC.
BRR compression is weird stuff. 4 bit samples that can be filtered to sound less bad, but still bad... Sample RAM is very limited and looping is restricted to block sizes, and many games have badly looped sounds because of it. Lot of games use looping on percussion instruments and it sounds rather... horrible, I don't have a better word to describe it. Other problem with samples is that you really do not get a good range on a sample, only few octaves before the sound gets very different from what it should sound like, there's also no way to shape the timbre of the sound either. On FM you can have really dynamic sounds and you have nearly full octave range on any sound you create. 53KHz sample rate really helps too with the crispness and range.
I do like smooth panning that the SPC can do, and the negative volumes. Some neat stuff can be done this way. I wish I could invert output of a channel on the YM chip...
I'll stop for now, when you have questions about MD inner workings I can most probably answer.
EDIT 2 :
Answer to the post below : This stuff is gone through so many millions of time by now... what makes me laugh is some of the ignorance and stubbornness that make such threads appear again from time to time.
CPU,PPU/VDP,APU,Etc.