It is currently Fri Oct 20, 2017 1:00 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject:
PostPosted: Tue Apr 07, 2009 2:32 pm 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
In reply to this post:

Hah, I knew that Nintendo was inspired by the Colecovision, especially the TMS9918 VDP, when they designed the Famicom!

Quote:
There is a product that Nintendo strongly considered when the family computer is developed. It is "Coleco Vision" of U.S. Coleco Co. (Figure 1).

[...]

It is often said by the family computer that Atari2600 of the Atari Co. acted as a model. It might not have been able to launch out into the development of family-use game machines if there was certainly no success in the Atari Co.. However, Uemura says that it was Coleco Vision to think a kind of image commodity by receiving technical stimulation.


And many people told me I was crazy when I made the point that the Famicon/NES, in a way, is a technical successor to the Colecovision, because everyone just looks at their different CPU's, and not the similarities between the VDP and PPU.

This article is pure gold.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 07, 2009 4:03 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
Isn't the Sega Master System the real successor to the Colecovision?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 07, 2009 6:12 pm 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
Dwedit wrote:
Isn't the Sega Master System the real successor to the Colecovision?


There is no real successor to the Colecovision, though the Master System is closer to the Colecovision than the NES, but came later. The official successor of the Colecovision VDP is the V9938 found in MSX2 computers.

The Colecovision is basically the model architecture for ALL japanese 8 bit consoles and even the SNES and Mega Drive. Its TMS9918 VDP introduced several key design aspects:

1. The basic video timing base of 5,37Mhz pixel clock.
2. Sprite multiplexing via hardware (Colecovision can display 4 16x16 sprites per line out of 32 total sprites).
3. Sprite overflow detection.
4. Seperate VRAM access via read/write ports instead of multiplexing CPU/Video ram accesses.
5. Reading from VRAM is pipelined.

Most people never saw the similarities between the Famicom and the Colecovision because of the 6502<->Z80 issue. It's interesting that the article also mentions the fact that the hardware designers first wanted to use the Z80, but chose the 6502 instead because it only takes 1/3 of the Z80 chip space.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 07, 2009 6:37 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
Uh, the SG-1000 was finished in 1981, before the ColecoVision was released. You're reading way too into it.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 07, 2009 7:13 pm 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
kyuusaku wrote:
Uh, the SG-1000 was finished in 1981, before the ColecoVision was released. You're reading way too into it.


Ok, the nitpick starts again... :roll: Guess what? The TMS9918 was used even earlier, in 1979 in the TI-99/4 computer...

Everything I wrote references specifically the TMS9918 VDP. Fact remains, the Colecovision was the first released video game console which used this chip. Fact remains, ALL VDP/PPU designs I mentioned are based on its architecture. Fact remains, the article itself mentions that the Colecovision was the inspiration for the Famicom/NES, combined with aspects of the Donkey Kong video hardware, which uses 2bpp tiles and sprites.

Another interesting point in the article is that the NTSC and RGB PPU's were developed at the same time.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 07, 2009 8:54 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
So the Sega Game-1000 isn't a game console?

Well who's to say your "key design aspects" aren't all coincidental, most of them look like common sense these days and certainly had all been done before in arcade hardware. I think the point is simply that Nintendo liked seeing Donkey Kong running relatively faithfully on the ColecoVision, which is no surprise since the TM9918 was probably the most arcade-like VDP at the time.

And hardware multiplexed sprites? Which systems and since when?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 08, 2009 3:11 am 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
kyuusaku wrote:
So the Sega Game-1000 isn't a game console?


Yes it is, but 1981 was not the release year. I am especially sceptic about that year, because it is NOT mentioned in the japanese Wikipedia page and the official japanese Sega webpage. Furthermore, there are no 1981 release dates mentioned for the software.

The SG-1000 closely resembles the Colecovision hardware (same CPU, same VDP, same amount of RAM, same sound chip).

Quote:
Well who's to say your "key design aspects" aren't all coincidental, most of them look like common sense these days


I am describing one specific chip which served as a key model for FURTHER implementations.

Quote:
and certainly had all been done before in arcade hardware.


Then it seems you don't know a lot about how arcade hardware works. All specific key design aspects I mentioned in my first post WERE INTRODUCED with the TMS9918.

And yes, you can nail me on these statements, though it will just further this senseless debate... I hope you can read schematics.

Quote:
I think the point is simply that Nintendo liked seeing Donkey Kong running relatively faithfully on the ColecoVision, which is no surprise since the TM9918 was probably the most arcade-like VDP at the time.


All key specific design principles I mentioned in my post were INTRODUCED with the TMS9918. Of course arcade games had sprites before. Of course arcade games had tile graphics before. But that's not the point. I am mentioning ONE SPECIFIC WAY of how it was implemented.

Arcade games at the time of introduction of the Colecovision had a unified memory architecture, mapping VRAM into CPU space. The TMS9918 introduced seperate data buses for graphics and the CPU.

Arcade games at the time had NO hardware sprite multiplexing, displaying a fixed number of sprites without restrictions. The TMS9918 introduced hardware sprite multiplexing and the famous "sprite overflow flag".

Quote:
And hardware multiplexed sprites? Which systems and since when?


I get the feeling you are now arguing for the sake of arguing.

- Sega Master System VDP -> 8 sprites per line out of 64
- PC-Engine VDP -> 16 sprites per line out of 64
- Mega Drive VDP -> Up to 32 and 40 sprite per line out of 80.
- SNES PPU -> Up to 34 Sprites per line out of 128.
- Game Boy -> 10 sprites per line out of 40
- Game Gear -> 8 sprites per line out of 64

Since you seem to be so keen on researching and knowledgeable with release dates, I am now shocked you do not seem to know these facts...

Read the TMS9918 datasheet and programming documentation, and you'll clearly see THIS specific implementation served as a model for all those architectures I mentioned. Down to the the display timing, consisting of pixel clock (5,37 Mhz) and number of pixels per line (340) (Except Game Boy).

Both Nintendo and Sega had their game franchises ported to the Colecovision and apparently liked the faithfulness of those versions. That's the reason why they copied key design aspects from the Colecovision for their own consoles.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 08, 2009 1:06 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
6502freak wrote:
Since you seem to be so keen on researching and knowledgeable with release dates, I am now shocked you do not seem to know these facts...

I only know it means that there are 4/8/16/32 counters holding sprite X coordinates (and 8/16/32 tile shift registers) loaded upon evaluation. What is known as OAM cycling around here is commonly called sprite multiplexing elsewhere, and to my knowledge isn't a feature of any of the chips though obviously it would be extremely useful. So call it sprite "multiplexing" but it's probably not the best choice of words. Don't forget that by your definition the Atari VCS also had multiplexed sprites too. Hell, tile-based "background multiplexing" probably belongs on your list too as the first LSI implemention; each of the VDP mentioned have one 2/4bpp shift register for all 700+ tiles!

Quote:
Read the TMS9918 datasheet and programming documentation, and you'll clearly see THIS specific implementation served as a model for all those architectures I mentioned. Down to the the display timing, consisting of pixel clock (5,37 Mhz) and number of pixels per line (340) (Except Game Boy).

If it was released in 1979, I can't argue with it being the first as few if any contemporary arcade boards came close to the same specifications. I'm sure however that later discrete boards do use all of your key aspects as they just made the most sense at the time. Maybe you should change your praise from ColecoVision to TMS9918 because it sounds like you just have a ColecoVision fetish when there is absolutely nothing unique about it.

"Based on" is a strong phrase, Nintendo's PPUs may be influenced by the 9918 but unlike Sega's VDPs they are clearly not based on it. Sprite unit reuse, 5.37 MHz pixel clock, VRAM port access, oh my!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 08, 2009 5:11 pm 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
kyuusaku wrote:
6502freak wrote:
Since you seem to be so keen on researching and knowledgeable with release dates, I am now shocked you do not seem to know these facts...

I only know it means that there are 4/8/16/32 counters holding sprite X coordinates (and 8/16/32 tile shift registers) loaded upon evaluation.
What is known as OAM cycling around here is commonly called sprite multiplexing elsewhere, and to my knowledge isn't a feature of any of the chips though obviously it would be extremely useful. So call it sprite "multiplexing" but it's probably not the best choice of words.


I think it is the most accurate term to describe the mechanism, because it revolves around automatically mapping a limited number of sprite shift registers and counters to a multitude of sprites by dyamically fetching and SWITCHING their attributes through evaluation based on the actual raster position and entries in a look-up table.

All sprite systems before assigned to each sprite its own display circuit. In order to display more sprites, some of those systems allowed to reset the sprite parameters manually during screen rendering by the CPU (most common examples: Atari 800 and Commodore 64).

Quote:
Don't forget that by your definition the Atari VCS also had multiplexed sprites too.


Nope. Nothing in the TIA supports sprite multiplexing. It is the CPU which does ALL the work MANUALLY (not only multiplexing, but also fetching the DATA for the sprites). The TIA is as primitive as one can imagine.

Displaying the same graphics 3 times per scanline is in no way comparable to how the TMS9918 and the PPU works. Those 3 copies can have NO independent movement and thus, can still be regarded as 1 sprite.

What comes next? Pong uses sprite multiplexing because both paddles are driven by the same horizonzal counter signal 8H? :lol:

Quote:
Hell, tile-based "background multiplexing" probably belongs on your list too as the first LSI implemention; each of the VDP mentioned have one 2/4bpp shift register for all 700+ tiles!


Again, now you're getting a bit silly. Background tile displays are clearly not sprites. And no, the TMS9918 only works at 1bpp.

Quote:
If it was released in 1979, I can't argue with it being the first as few if any contemporary arcade boards came close to the same specifications. I'm sure however that later discrete boards do use all of your key aspects as they just made the most sense at the time.


What are you referring to by saying "later discrete boards" ? Practically all arcade games manufactured up to 1982 were made mostly of discrete components.

Name me one game made before 1983, not having an actual TMS9918/28, which has the same characteristics I mentioned as the TMS9918. Then I am going to dig out the schematics and prove that you are wrong.

Quote:
Maybe you should change your praise from ColecoVision to TMS9918 because it sounds like you just have a ColecoVision fetish when there is absolutely nothing unique about it.


Yawn. Anything else? And yes, I have a Colecovision fetish, as much as I have a NES fetish, a PC-Engine fetish, a Mega Drive fetish, a SNES fetish, a Playstation fetish...

Short: I have a fetish for computer and videogame systems. What fetishes do you have?

Quote:
"Based on" is a strong phrase, Nintendo's PPUs may be influenced by the 9918 but unlike Sega's VDPs they are clearly not based on it.


If nothing helps anymore, we are now nitpicking on particular choices of words (did I mention that English is not my native language?). Besides, I already mentioned that the Master System is much closer related to the Colecovision than the NES, but it came LATER.

Quote:
Sprite unit reuse, 5.37 MHz pixel clock, VRAM port access, oh my!


Is it my fault you fail to recognize similarities between particular methods of displaying and manipulating computer images?

Fact is, Nintendo copied (yes, COPIED) MANY aspects of the TMS9918 design (which are specific to the TMS9918), and added some of their own ideas to it (like scrolling with screen wrapping and the sprite 0 hit detection method).

The article mentions that the Famicom chip design group specifically chose the Colecovision as a guide to develop the chipset.

So, how many times do we have to go in circles now?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 08, 2009 9:57 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
6502freak wrote:
Nope. Nothing in the TIA supports sprite multiplexing. It is the CPU which does ALL the work MANUALLY (not only multiplexing, but also fetching the DATA for the sprites). The TIA is as primitive as one can imagine.

Well the registers ARE being reused each line, not reloaded by a state machine but by the CPU. Technically that is multiplexing :roll:

Quote:
Again, now you're getting a bit silly. Background tile displays are clearly not sprites.

What does it matter? The background hardware is still being multiplexed.

Quote:
What are you referring to by saying "later discrete boards" ? Practically all arcade games manufactured up to 1982 were made mostly of discrete components.

I was referring to games post-9918.

Quote:
Name me one game made before 1983, not having an actual TMS9918/28, which has the same characteristics I mentioned as the TMS9918. Then I am going to dig out the schematics and prove that you are wrong.

I really need to find evidence of registers indexing other memory in arcade games? Arcade games wouldn't WANT to do this... I'm just saying the logic wasn't new. Should I find just any chip with port access to another bus?

Why don't you tell me how many sprites Donkey Kong supports Vs how many shifters there are? Googling suggests there are 96 sprite attribute structures, but from the schematics it's not evident.

No arcade games at the time are going to use the 5.37 MHz pixel clock because they didn't use NTSC monitors. It's true that the 9918 introduced this frequency and Nintendo used it, but it's not like the frame timing is the same nor is the logic anywhere close to similar. Both devices chose it for the same reason, it nets you 256 relatively square horizontal pixels and is a derivative of colorburst. I'm still guessing there are at least a couple discrete boards with the same pixel clock, perhaps 1984-1986, unfortunately pixel clocks are not widely documented.

Apparently the original sprite chip, the Signetics 2636 (Pong stuff), has a sprite completion flag which is only a couple logic gates away from being an overflow flag. Obviously it doesn't use it this way since there are only 4 "unmultiplexed" sprites but sprite status has existed before the 9918. BTW, sprite to BG collision was a feature of this chip as well. Perhaps Nintendo got the idea here... or maybe it was just reinvented.

Quote:
What fetishes do you have?

Programmable logic and ninja fetishes.

Quote:
Fact is, Nintendo copied (yes, COPIED) MANY aspects of the TMS9918 design (which are specific to the TMS9918), and added some of their own ideas to it (like scrolling with screen wrapping and the sprite 0 hit detection method).

And you're one to say TI didn't copy every aspect from other products? How many of these features have patents?

Nintendo clearly built the PPU from the ground up... There is nothing internally resembling 9918, just the ideas of sprites and name tables, both of which existed before the 9918 (by other names). The 9918 could have been the first to bring these features into one chip, and Nintendo followed in TI's footsteps, but if you want to give credit where it's due, go find the true inventors. Seriously how else would Nintendo have gone if not the same route as the 9918? They obviously couldn't integrate/consolize their arcade hardware, as I said, it's just common (engineering) sense.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 08, 2009 11:09 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
So why the heck didn't nintendo put in a readable LY and LYC interrupt until they made the gameboy?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 09, 2009 12:55 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
In 1983 what the heck did you need a line interrupt for? :wink:


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 09, 2009 1:01 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
Nintendo excludes the scanline interrupt only to include a 60Hz timer IRQ in the CPU for sound purposes. They must have really liked Donkey Kong 3 or Punch Out a lot.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 09, 2009 4:09 am 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
kyuusaku wrote:
6502freak wrote:
Nope. Nothing in the TIA supports sprite multiplexing. It is the CPU which does ALL the work MANUALLY (not only multiplexing, but also fetching the DATA for the sprites). The TIA is as primitive as one can imagine.

Well the registers ARE being reused each line, not reloaded by a state machine but by the CPU. Technically that is multiplexing :roll:


Umm, yes... And? I was specifically stating in my first post that the TMS9918 does the sprite multiplexing. :roll: :roll: :roll:

Quote:
Quote:
Again, now you're getting a bit silly. Background tile displays are clearly not sprites.

What does it matter? The background hardware is still being multiplexed.


If you can't keep up with arguments, let's deconstruct everything. :roll:

So according to you, a bitmap display is also a sprite display, because after all, the CPU can copy the objects around. Oh wait, and if I blow my nose against the monitor, there's also lots of sprites appearing now...

Quote:
I was referring to games post-9918.


Me too.

Quote:
I really need to find evidence of registers indexing other memory in arcade games? Arcade games wouldn't WANT to do this... I'm just saying the logic wasn't new. Should I find just any chip with port access to another bus?


Yes, find me some random watchamadigga with port access, and claim it's technically identical to the way how the TMS9918 seperates VRAM from local CPU ram. :lol:

Quote:
Why don't you tell me how many sprites Donkey Kong supports Vs how many shifters there are? Googling suggests there are 96 sprite attribute structures, but from the schematics it's not evident.


Substituting everything I was referring to with anything you claim, like your hilarious sprite<->character screen analogy, won't distract me from the discussion.

The Donkey Kong hardware fetches sprite attributes from a sprite memory and copies the graphics for each sprite into a 256x8 line buffer. It does this wholly deterministic, every sprite the hardware fetches gets drawn. This line buffer is then being displayed during active display.

It's a whole different way and in no way comparable to how the TMS9918 and the NES PPU evaluates which sprites are being displayed amongst very few display units. NES PPU and TMS9918 drop sprites when too many per line are being displayed. Donkey Kong on the other hand, has a fixed number of sprites it can display in ALL situations. Exactly how other architectures work.


Quote:
No arcade games at the time are going to use the 5.37 MHz pixel clock because they didn't use NTSC monitors.


:lol: :lol: :lol:

Wrong. Pong for example, generates a perfectly valid NTSC sync signal from a 14,318Mhz crystal.

It really shows you are shooting your mouth off here.

Quote:
It's true that the 9918 introduced this frequency and Nintendo used it, but it's not like the frame timing is the same nor is the logic anywhere close to similar.


Ummm, the frame timing is identical to the NES PPU, 340 pixels per line, 262 lines, and if I had an oscilloscope, I would even bet that all blanking and sync signals start at the same positions between the 2 chips (because they are documented in the TMS9918 datasheet).

Quote:
Both devices chose it for the same reason, it nets you 256 relatively square horizontal pixels and is a derivative of colorburst.


Yes, but the TMS9918 did it first and Nintendo copied this approach.

Quote:
I'm still guessing there are at least a couple discrete boards with the same pixel clock, perhaps 1984-1986, unfortunately pixel clocks are not widely documented.


Umm, just look at the schematics.

Many arace games from that are based on either 14,318Mhz or 12,288Mhz master clocks. Many games which have a 256 horizontal pixel display use 12,288Mhz/2 as a pixel clock (Namco/Atari/Konami for example), which yields a display field slighty narrower than 5,37Mhz pixel display. There are also many games which use odd frequencies. My Phoenix pcb for example has a 11Mhz master oscillator, yielding 5,5Mhz pixel clock. If you manage to divide it down to 262 lines and closely to 15,75 khz horizontal frequency, you can pretty much use any master clock you want.

Quote:
Apparently the original sprite chip, the Signetics 2636 (Pong stuff), has a sprite completion flag which is only a couple logic gates away from being an overflow flag.


I knew from the start that you are just trying to be a HUGE smartass here... :lol:

Quote:
Obviously it doesn't use it this way since there are only 4 "unmultiplexed" sprites but sprite status has existed before the 9918.


Nice, but that's not what I was referring to. I was specifically referring to the specific way the TMS9918 handles it, and how the NES PPU and many other VDP's are a very close copy of THAT particular design.

Quote:
BTW, sprite to BG collision was a feature of this chip as well. Perhaps Nintendo got the idea here... or maybe it was just reinvented.


But only Nintendo came up with the Sprite 0 hit detection, one specific way to split the raster screen, while other architectures have a reloadable raster IRQ register.


Quote:
Quote:
Fact is, Nintendo copied (yes, COPIED) MANY aspects of the TMS9918 design (which are specific to the TMS9918), and added some of their own ideas to it (like scrolling with screen wrapping and the sprite 0 hit detection method).

And you're one to say TI didn't copy every aspect from other products?


Not the ones I was mentioning. The way how the TMS9918 handles sprites was introduced with this architecture.

Quote:
How many of these features have patents?


Hahahahaha. You are REALLY trying to put every argumentative trick out of your hat. :lol:

You know what? Nintendo copied Ralf Baer's design.

Quote:
Nintendo clearly built the PPU from the ground up...


Hmm, isn't that dirty? There is usually lots of dust and footprints on the ground.

Quote:
There is nothing internally resembling 9918


Of course there is. The way the video chip evaluates all sprite y coordinates during active display, and loading a limited number of shift register with them. If too many sprites are on a single line, a flag is set to indicate the overflow. Furthermore, the TMS9918 seperates between VRAM and local CPU ram via read and write ports, contrary to Nintendo's arcade boards like Donkey Kong, where the video hardware interleaves its DMA cycles with CPU cycles. Plus, the NES PPU uses the same frame timing as the TMS9918, derived from the same pixel clock.

Quote:
, just the ideas of sprites and name tables, both of which existed before the 9918 (by other names).


Yes, my little genius, but again, that's not what I was referring to. I was ALWAYS referring to ONE SPECIFIC IMPLEMENTATION of how this mechanism works. I have said in previous posts that tile and sprite displays existed prior to the TMS9918.

Somehow, I get the feeling that you are unable (or unwilling) to comprehend my posts very well.

Quote:
The 9918 could have been the first to bring these features into one chip,


Nope, chips from Atari and other manufacturers existed before which could display sprites and backgrounds.

Quote:
and Nintendo followed in TI's footsteps, but if you want to give credit where it's due, go find the true inventors.


Nintendo copied the specific TMS9918 way of handling graphics when they designed the PPU. AGAIN: it is even mentioned in the article.

It's like copying a specific painting of a woman. Of course people have painted women before, and no one can claim to have invented the painting of a woman. But this particular picture uses the same pose, the same expression on the face, the same hair colour. Just the background and the colour of her clothings (more colours) were changed.

Ever seen this?

http://www.collegehumor.com/video:1906578

The NES PPU is a specific copy of the TMS9918 design with additional changes.

Quote:
Seriously how else would Nintendo have gone if not the same route as the 9918? They obviously couldn't integrate/consolize their arcade hardware, as I said, it's just common (engineering) sense.


Ummm, they could have gone the same route as other manufacturers and use a unified memory architecture where the video circuit is a DMA busmaster. It's the exact same way how other architectures work, including their own arcade games. On the Commodore 64, you directly write into local video ram. On the Atari 800, you directly write into local video ram. On the Apple 2, you directly write into local video ram. On the VIC 20, you... I guess you get the idea (or maybe not). On most computers at that time, you don't have sprites at all. On the C64, you have 8 fixed sprites. On the Atari 800, you have 5 fixed sprites. On the TMS9918 and the NES PPU, you have 32/64 sprites which are automatically multiplexed by the video hardware. You have much more sprites this way, but you can't use them freely without restrictions.

Obviously the TMS9918 design made a lot of common engineering sense. That's exactly why Nintendo chose it to model their PPU based on its design.

Again, how many times do we have to go around in circles? It's sort of becoming a waste of time.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 09, 2009 1:13 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
6502freak wrote:
Umm, yes... And? I was specifically stating in my first post that the TMS9918 does the sprite multiplexing. :roll: :roll: :roll:
Just trying to point out so did the TIA albeit not with an internal state machine fetching from external memory.

Quote:
Substituting everything I was referring to with anything you claim, like your hilarious sprite<->character screen analogy, won't distract me from the discussion.
There was no analogy from sprites to background, just attempting to show how poorly worded it is to call it simply multiplexing. This all started with a misunderstanding, if you Google "sprite multiplexing" I'd hope you see why.

Quote:
It's a whole different way and in no way comparable to how the TMS9918 and the NES PPU evaluates which sprites are being displayed amongst very few display units.
Of course they aren't the same, but sprites are still multiplexed from line to line, no? They just don't have a shortage of them.

Quote:
Wrong. Pong for example, generates a perfectly valid NTSC sync signal from a 14,318Mhz crystal.
You could generate sync from a 1 MHz RC oscillator, what does that have to do with anything? If you want 256 pixels, 5.37 MHz is better than 14.32/3 MHz. If the PPU didn't internally generate NTSC (needing 21.48 MHz), maybe it wouldn't even use that pixel clock. My point is Nintendo chose it because it was convenient, not because it was necessary (because they literally used any part of the 9918).

Quote:
I would even bet that all blanking and sync signals start at the same positions between the 2 chips (because they are documented in the TMS9918 datasheet).
Thanks to that I could verify that neither blanking or sync are the same horizontally or vertically. You got my hopes up too because I'm interested in the PPU's Vsync.

Quote:
Ummm, the frame timing is identical to the NES PPU, 340 pixels per line, 262 lines, and if I had an oscilloscope
I thought you checked the datasheet... So the 9918 doesn't have 342 pixels per line?

Quote:
But only Nintendo came up with the Sprite 0 hit detection, one specific way to split the raster screen, while other architectures have a reloadable raster IRQ register.
And this was a feature? I always thought it was a lame hack based on economics. A large OR, 2 OR, 1 AND and a flip flop VS 9/10 flip flops, 8/9 XORs and a large OR.

Quote:
Not the ones I was mentioning. The way how the TMS9918 handles sprites was introduced with this architecture.
Specifically that it was the first to reload sprite registers from a state machine, OK. Since you say it was released in '79 I'd believe you.

Quote:
Of course there is. The way the video chip evaluates all sprite y coordinates during active display
The idea of Y evaluation or the implementation? We know the algorithms are not similar.

Quote:
Ever seen this?
Yes. So everyone reuses their own work?

Quote:
The NES PPU is a specific copy of the TMS9918 design with additional changes.
Well I'm going to continue to argue that it "copied" basic ideas, not the design.

Quote:
Ummm, they could have gone the same route as other manufacturers and use a unified memory architecture where the video circuit is a DMA busmaster. It's the exact same way how other architectures work, including their own arcade games.
Not if they wanted a powerful system on their memory budget. Nintendo probably would have wanted a "Donkey Kong-Neo Geo" if it wasn't like 10x more expensive than the Famicom parts.

Had VRAM been memory mapped the PPU would need another 10 address pins plus a great deal more internal logic than the port system. As for the sprite system, since sprite attributes are implemented in 256 bytes of internal dynamic memory (instead of in VRAM like the 9918), they couldn't afford an arcade sprite system, not to mention they probably needed a unified graphics bus if they didn't want a 100 pin cartridge. These things aren't features, they're compromises that the 9918 happened to do first, in a somewhat significantly different way.

Quote:
Again, how many times do we have to go around in circles? It's sort of becoming a waste of time.
It'd be worth it if you think twice about making bold claims, but I kind of doubt that will be happening :wink:


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group