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
Umm, yes... And? I was specifically stating in my first post that the TMS9918 does the sprite multiplexing.
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.
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...
I was referring to games post-9918.
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.
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.
No arcade games at the time are going to use the 5.37 MHz pixel clock because they didn't use NTSC monitors.
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.
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).
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.
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.
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...
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.
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.
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.
How many of these features have patents?
Hahahahaha. You are REALLY trying to put every argumentative trick out of your hat.
You know what? Nintendo copied Ralf Baer's design.
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.
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.
, 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.
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.
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?
The NES PPU is a specific copy of the TMS9918 design with additional changes.
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.