How exactly did SNK arrive at "330 megabit" for Neo Geo ?

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by tepples »

The Neo Geo's picture is theoretically 320 pixels wide, but I'll say 304 because the left and right 8 pixels are often blanked in the fix layer so as not to intrude on the horizontal blanking period. (Neo Geo pixels are wider than Genesis pixels, and only 312 of the 320 fit in the regulation scanline, compared to 350 for the Genesis.) Each scanline can have 96 slivers, each 16 pixels wide. Making a background out of linked sprites would eat up (304/16)+1 = 20 slivers, and that's only if the layer has full coverage (such as a semitransparent waterfall). A layer with lots of blank space in it, such as the layer that the player is on, would presumably have fewer background slivers. So even if you're using sprites to build three layers of backgrounds, comparable to the Super NES or CPS, you still have about 200% of overdraw left, compared to about 100% for the contemporary consoles (Genesis and Super NES).

The Super NES has a silicon bug where (if I recall correctly) only the 34 rearmost 8x1 pixel slivers would be drawn, not the frontmost. Does the Neo Geo have a similar bug?
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by Drew Sebastino »

MottZilla wrote:I'm thinking you have a bias against the NeoGeo or something like that. I didn't realize that the NeoGeo had a problem with no background layers. Every NeoGeo game I played certainly had a background and it even scrolled! Seems like the system they went with worked out ok. The system had support for over 10 years too.
There's definitely not a problem with the Neo Geo having no background layers in that the games look fine. However, no game is ever going to effectively make use of 384 sprites instead of less but with background layers for the same amount of bandwidth. The Neo Geo has way more overdraw than the SNES, Genesis, and especially Turbografx 16, (I don't know how you thought I thought otherwise) but not compared to other arcade machines of the same "class". The smart thing to do would be what tepples described and just not use sprites for blank parts of a background layer, but considering how safe most Neo Geo games play it and the fact that this is harder to program for (in that you can't just simply stick sprites together anymore) I'm not sure this was done too much. Of course, this isn't the system's problem. What I'm trying to say is that the Neo Geo has more flexibility in arranging the bandwidth but less overall. Whether this is better or not depends on what you're trying to do, but I'd say for most games, it's not worth it. I think a good idea for the Neo Geo would have been to have one background layer with the lowest priority. That's basically guaranteed to be solid, so there's no advantage to using sprites there. Although, being real, it's not like the Neo Geo is exactly lacking in bandwidth or anything... :lol:

And yes, I've played my fair share of Neo Geo games. The original Metal Slug is what really got me into run and gun games.
tepples wrote:comparable to the Super NES or CPS, you still have about 200% of overdraw left, compared to about 100% for the contemporary consoles (Genesis and Super NES).
What about the Super NES? :lol:
tepples wrote:I'll say 304 because the left and right 8 pixels are often blanked in the fix layer so as not to intrude on the horizontal blanking period.
What's being updated then?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by tepples »

Espozo wrote:
tepples wrote:if you're using sprites to build three layers of backgrounds, comparable to the Super NES or CPS, you still have about 200% of overdraw left, compared to about 100% for the contemporary consoles (Genesis and Super NES).
What about the Super NES? :lol:
With 3 backgrounds enabled (mode 1), Super NES has 272 sprite pixels per 256-pixel scanline, or 106% coverage. With 60 sprites taken up to make 3 backgrounds, Neo Geo has (96-60)*16 = 576 per 304-pixel scanline, or 189% coverage.
Espozo wrote:
tepples wrote:I'll say 304 because the left and right 8 pixels are often blanked in the fix layer so as not to intrude on the horizontal blanking period.
What's being updated then?
In the case of Neo Geo, it's not update time as much as making sure the monitor understands the signal being sent to it. A standard NTSC TV scanline is 52.1 microseconds long porch to porch, but 320 pixels at a 6 MHz dot clock are 53.3 microseconds. Cropping it with the fix layer reduces the picture to 50.7 microseconds, which doesn't come as close to the color burst on the left or the sync pulse on the right. For a very rough Nintendo counterpart, see the discussions about TVs that respond poorly to color $0D.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by MottZilla »

Espozo wrote: There's definitely not a problem with the Neo Geo having no background layers in that the games look fine. However, no game is ever going to effectively make use of 384 sprites instead of less but with background layers for the same amount of bandwidth. The Neo Geo has way more overdraw than the SNES, Genesis, and especially Turbografx 16, (I don't know how you thought I thought otherwise) but not compared to other arcade machines of the same "class". The smart thing to do would be what tepples described and just not use sprites for blank parts of a background layer, but considering how safe most Neo Geo games play it and the fact that this is harder to program for (in that you can't just simply stick sprites together anymore) I'm not sure this was done too much. Of course, this isn't the system's problem. What I'm trying to say is that the Neo Geo has more flexibility in arranging the bandwidth but less overall. Whether this is better or not depends on what you're trying to do, but I'd say for most games, it's not worth it. I think a good idea for the Neo Geo would have been to have one background layer with the lowest priority. That's basically guaranteed to be solid, so there's no advantage to using sprites there. Although, being real, it's not like the Neo Geo is exactly lacking in bandwidth or anything... :lol:
I have no idea what you are going on about. No game is going to use all 384 sprites and things about bandwidth. The sprite thing is easy, lots of games don't use their platform's maximum amount of ANYTHING. This thing about overdraw and who has more, again I've played lots of NeoGeo games and this doesn't seem to be an issue in those. Your comments about bandwidth I don't get. I can understand wanting to critique the hardware but I don't see your point.

The hardware I used to complain about was the Sega Genesis and it's lack of colors available at once. I always thought it would have been a relatively simple to implement more and made a huge difference. Something as straight forward as separate palette sets for background tiles and sprite tiles. I know the issue was probably related to die space on the VDP but I really think the cost would have been worth it.

I don't see your complaints about the NeoGeo making sense like that.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by AWJ »

tepples wrote: The Super NES has a silicon bug where (if I recall correctly) only the 34 rearmost 8x1 pixel slivers would be drawn, not the frontmost. Does the Neo Geo have a similar bug?
Drawing from back to front is simpler hardware-wise. To draw from front to back you have to read the line buffer before each write to check whether an already-drawn pixel is there. And there's no guarantee that drawing from front to back will look better--unless the sprites that get dropped are completely occluded by another sprite, you're still going to see that they're missing.

I thought the SNES selected active sprites from front to back, but fetched and drew them from back to front. Seems more likely to be an attempt at a compromise than a "bug". In practice time overs are much more likely than range overs, so the order sprites are selected in rarely makes a difference.

I think the Neo Geo draws from back to front but I might be wrong. At least one of the Konami arcade sprite generators has a register bit that selects front-to-back or back-to-front drawing.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by tepples »

AWJ wrote:Drawing from back to front is simpler hardware-wise. To draw from front to back you have to read the line buffer before each write to check whether an already-drawn pixel is there.
If one byte of the line buffer has more than one pixel in it, you need to read before writing anyway. I guess it depends on at what point the Neo Geo reads its palette.
And there's no guarantee that drawing from front to back will look better--unless the sprites that get dropped are completely occluded by another sprite, you're still going to see that they're missing.
Sprites used as a background layer are more likely to "completely occlude" what's behind them.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by AWJ »

tepples wrote: If one byte of the line buffer has more than one pixel in it, you need to read before writing anyway. I guess it depends on at what point the Neo Geo reads its palette.
Who says the line buffer has to be organized in 8-bit bytes? Integrated RAM can organized however you want--look at the NES color RAM (6 bits wide and with irregular mirrored "holes") or its OAM for that matter.

The video DAC in the Neo Geo is external to the video chips (it's a pair of SRAMs and a resistor network) The chips work entirely in indexed color space.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by tepples »

AWJ wrote:Who says the line buffer has to be organized in 8-bit bytes?
Then I must have misread the role of certain SRAMs. If the line buffer is indeed internal to the NEO-B1, then it's like the S-PPU, whose line buffer is probably 9 bits per pixel: 4 for color index, 3 for palette attribute, and 2 for priority against backgrounds.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by psycopathicteen »

6 of the ADPCM channels can only play at a fixed frequency, so if you need more than one ADPCM channel playing music, you need to resample the instrument at every note. That would certainly take up a lot of memory.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by Drew Sebastino »

I'm pretty sure Metal Slug does that. I remember opening up the game and loading the files into Audacity as raw data and you could actually hear all the samples. They're not compressed in any way, but I bet sound samples are streamed directly from the cartridge to where neither CPU has access. I think it's a shame that more Neo Geo games didn't take more advantage of its FM channels, because the PCM abilities by themselves aren't that amazing for an arcade machine.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by lidnariq »

Unlike on the Genesis, the Z80 on the Neo Geo doesn't really have access to a useful DAC, so it can't really stream any audio. Any high-quality samples are assuredly ADPCM-compressed and stored in the "V" ROMs.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by tepples »

You can certainly do drums or vocals on those channels. Likewise the NES needs a separate sample for most pitches if you're doing Sunsoft bass. And if you're on Neo Geo, you can probably make a V ROM big enough for a Mellotron-style patch set where each pitch has a separate sample. (The Mellotron was an early analog sampler that used sets of magnetic tapes, one per pitch.)
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by TmEE »

tepples wrote:In the case of Neo Geo, it's not update time as much as making sure the monitor understands the signal being sent to it. A standard NTSC TV scanline is 52.1 microseconds long porch to porch, but 320 pixels at a 6 MHz dot clock are 53.3 microseconds. Cropping it with the fix layer reduces the picture to 50.7 microseconds, which doesn't come as close to the color burst on the left or the sync pulse on the right. For a very rough Nintendo counterpart, see the discussions about TVs that respond poorly to color $0D.
Masking the edges has zero effect on how a TV or monitor understands the signal as it doesn't do anything with the Hsync signal. It might have effect only on modern TVs or monitors which try to center image by looking at what is actually displayed rather than just assume a portion between sync pulses.

Neo Geo active line lasts ~59µs and blanking is ~5µs long for total line length of ~64µs, just measured :
Image

EDIT: The spikes seen on top of the line are BIOS crosshatch test signal leaking into sync signal, which can be used to see the relative positioning of the image on a line. 304 pixels that are normally visible are roughly 50µs long indeed. Full 320 pixels would eat up pretty much entire front porch and only leak a little bit into back porch, there will still be plenty room for the burst if necessary, at least compared to MD which has its active image start roughly 5µs after sync, nearly where NeoGeo line would start if it showed full 320 pixels.
Last edited by TmEE on Wed Sep 07, 2016 1:53 pm, edited 2 times in total.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by Drew Sebastino »

lidnariq wrote:Any high-quality samples are assuredly ADPCM-compressed
Oh, if it were compressed, I'd have expected that I'd have to put it through some program like you need to for BRR decompression, but I assume ADPCM is common, where BRR only seems to be used in the SNES, CD-I (I can't help but find this funny, seeing Philips was a competitor of Sony) and PlayStation.
tepples wrote:(The Mellotron was an early analog sampler that used sets of magnetic tapes, one per pitch.)
Did you learn about this in one of your court cases? :lol:
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How exactly did SNK arrive at "330 megabit" for Neo Geo

Post by tepples »

TmEE wrote:Neo Geo active line lasts ~59µs and blanking is ~5µs long for total line length of ~64µs, just measured :

[Image: Graph of signal level of an hsync pulse with a small amount of grid picture mixed in, with the two not overlapping in time]

EDIT: The spikes seen on top of the line are BIOS crosshatch test signal leaking into sync signal, which can be used to see the relative positioning of the image on a line.
This is for MVS, right? How close does the overlap come to the composite color burst pulse on an AES or on an MVS through a SuperGun?
Post Reply