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

I know it's just marketing, but digging through the information on wiki.neogeodev.org has left me confused.

How exactly did they arrive at 330 megabit?

( https://wiki.neogeodev.org/index.php?title=NEO-273 )

On the CHA board, ignoring any on-cart bankswitching:
The original Neo Geo C ROM layout nominally supports 2 Mi x 32bit, for 64 Mibit of sprite data.
The revised memory layout one uses the entire 24-bit P bus (plus CA4) to support 16 32 Mi x 32bit, or 512 1024 Mibit of sprite data.
128 KiB (1Mibit) are always used for the S ROM (fix layer).
Z80: one 64 Ki x 8 bit (512 Kibit; M ROM) for the sound driver

On the PROG board, again ignoring any on-cart bankswitching:
68k: 512 Ki x 16bit (8 Mibit; P ROM), plus a bonus nonadjacent 512 Ki x16bit that I guess they weren't counting?
YM2610: two 16 Mi x 8 bit (total 256 Mibit; V ROM)

so ... 256 Mibit(V) + 64 Mibit(C) + 8 Mibit(P) + 1 Mibit(S) + ½ Mibit(M) = 329½ Mibit? Is that what they were thinking?

You mean to tell me, that most of it was for sound?

That's surprising to me too. I mean, it's pretty crazy for the PCM/FM setup, but not enough for just streaming sound tracks. The only thing I can think of is for doing the former, but with dialogue, (beyond "oomph") but how often is that used in an arcade game? Even voice samples in a fighting game aren't long enough to use that much data. At least I know why "GIGA POWER" games came into existence though, because had you been able to use those "330 megabits" of data however you wanted to, Metal Slug 3 would not need bank switching. (I guarantee it's that not all the tile data fit into a regular cartridge)

At the launch of the Neo-Geo, most of SNK's own NG games had rather drab graphics, but tons of voice samples. That's obviously what they were trying to push at the start.

I think some of the earlier games had background songs playing (an early mahjong game was possibly an example, if my memory is correct), probably not streamed entirely, but with chip synthesized music coupled with recorded vocal (like the opening to Tales of Phantasia for the Super Famicom).

When SNK designed the console, they might have thought of Psycho Soldier.

God, that music is terrible...


I think a lot or people have forgotten how mediocre most Neo Geo games looked for the couple of years or the systems life. The following don't look like anything that wasn't done already done on the SNES, and would certainly be possible if it weren't for BG (that actually seemed more emphasized in the earlier titles) than scrolling in some of the games.







I don't think it was until 1995 that Neo Geo games started to look consistently good. Really, the Neo Geo doesn't have seemed to be any more powerful than the other arcade boards of the era. Well, I actually don't know, because although the number of pixels it can display horizontally including overdraw is most likely lower than its closest (as in year made) competitor I can think of, the Irem M92, (unless Mame's Irem M92 driver accuracy is the problem, somehow Gunforce II never experiences sprite pixels per scan line problems) (CPS1 was made significantly earlier, and the CPS2 was made significantly later. Konami makes a new system for every game, and Sega had a million different arcade boards, with the ones being put into production at that time probably costing as much as an amusement park ride) it's also more than likely streaming more data required to get all that stuff to display in the first place considering you're dealing with only sprites that have more data than a simple background tile. If this sets it over the M92's bandwidth is a mystery to me though. I still think the fix layer is a waste of perfectly good bandwidth. You could have used it towards sprites, which it then wouldn't have enough bandwith to cover the width of the screen like the fix layer, but I mean, come on. Actually, even in later games, the lack of "BG layers" is odd. Aside for some freak situations, I can't even think of a time any game routinely pushes the bandwidth to even 3/4s.

These games pre-dated the SNES. Neo-Geo is a product of the late '80s 1990, though these games were no doubt created in late '89 or so. Even the earlier games had a lot of animation and unique tiles as well.

So is the Super Famicom. The graphics of games released in comparable years may have looked similar. Adapting to a more detailed art style is a matter not only of hardware but also of artist labor, and that might explain progression in parallel until the Super Famicom's ceiling was hit. The Neo Geo had a bit more headroom for games that played to its strengths. In 1995, investment in graphical complexity on the Super NES started to tail off as 2D developers shifted to the Saturn and whatever PlayStation games Sony didn't block under its deprecation of 2D.

"Practical" ceiling. Although to be fair, I don't know of any Neo Geo games that push the system any harder than what the hardest games did on the SNES, so I'm sure there's extra room for improvement on the Neo Geo too, maybe just not quite as much. The specs of the Neo Geo seem a lot more "static" than the SNES's in that there are no BG modes, transparency, or vram, but the fact that you can essentially split the balance between background layers and sprites any way you want definitely combats that. Does the Neo Geo have any raster effects, because I imagine that would help too. I'm only asking because I haven't seen any. I'd say I think the other problem in the Neo Geo not looking as good as the hardware would suggest compared to the SNES is that some of the limits of the Neo Geo are so high that they never even come close to being hit. Although the Neo Geo has 16x the number of palettes as the SNES, most games I've seen don't look like they ever go over 2x the amount because why would you need to really. You're sure as hell not needing to do any of this: viewtopic.php?f=12&t=14662 Of course, I'm a big SNES fanboy, so don't take all of what I said earlier to seriously. One thing that I probably disagree with a lot of people is that I think the SNES's color count is kind of lame. I mean, if you take any popular arcade machine from the day and compare its bandwidth to the SNES's, it's just like 2-4 times as high. However, you compare the number of palettes, and it's like 8-16 times as high. The thing is that the number of palettes is too low to give every object their own palette, but kind of too high to go the NES and Genesis approach of just having all the palettes sit there. Donkey Kong country can pull it off in that there aren't many different types of objects onscreen at a time, or even that many objects onscreen in general, but for something like a run and gun with a bunch of random stuff, this kind of falls apart. I'm sure most people would say the DKC games are just as colorful as the Metal Slug ones, but it only looks like it because every object has their own unique palette, but there are just more objects in a Metal Slug game.

On cart systems, you're only limited by whatever you put in the cartridge hardware. You're right that there's no BG modes (only sprites and the fix layer) or transparency (needs to be faked with 60hz alternating checkerboards)


Neo Turf Masters heavily uses raster effects for rendering, as does Riding Hero. Some other games only really use it for effect (the house on fire stage in Last Blade 2 comes to mind).


Plus, managing the large number of palettes can be a pain in the ass (I'd imagine the developers of Ragnagard know a lot about this). This goes double when you realize the only "safe" time you can change palettes is during VBlank.

I disagree. Even some 1990/1991 games on the Neo had great graphics, basically far more varied graphical tiles compared to the SFC, thanks to gluttonous ROM space on Neo carts; as well as far more sprites (well, the Neo is essentially all sprites) for incidental effects. Anyway, in my post, I criticized only SNK-developed titles, because games from Alpha Denshi, Pallas, Sammy, etc. had some great graphical design and colour use.

By the way, the Neo-Geo hardware was originally designed by Alpha Denshi (check Wikipedia for info), and SNK did the manufacturing and marketing. (Thus, I doubt if Psycho Soldier was on their minds...)

Would GBA be about as powerful as Neo Geo, apart from the smaller display (240x160 vs. 304x224)?

• 16.78 MHz ARM7TDMI CPU performs both game logic and audio mixing
• Similar typical sample rate (18 kHz)
• 4 scrolling tiled background layers, with each pair replaceable by a tiled rot/scale layer
• 64K of VRAM for backgrounds: 2-4K per "normal" background, with the rest for tiles
• 128 sprites, with OAM writable during hblank for soft multiplexing
• 32K of VRAM for sprites, with conveniently fast DMA from ROM and WRAM
• Flexible sprite sizes 8x8-32x32, plus 64x64, 64x32, and 32x64, in both Genesis-style 1D and Super NES-style 2D layouts
• 4x overdraw for unscaled sprites (scaled sprites take about 2.5x as long)
• 16 background palettes and 16 sprite palettes (like TurboGrafx-16), writable at any time
• Game Pak up to 32 MiB (256 Megabits), plus 256 KiB auxiliary work RAM for decompressed tile data or multiboot client for players 2-4

Going point by point...


GBA wins here, easily, as far as I'm concerned. The CPUs in the Neo-Geo are a 68000 (main) and a Z80 (audio).


This is a push, unless you count the Neo-Geo cart system's ADPCM-B channel, which has a variable sampling rate. However, it's not available on Neo-Geo CD systems.


GBA wins, since Neo-Geo has no rotation or upward scaling (scaling down is possible). Also, no layers; all backgrounds are made of sprites, eating into the 96 sprites/scanline limit.


and

VRAM on Neo-Geo isn't really comparable with other systems, as it doesn't hold the actual graphics data. There's 68KiB available (split into 64KiB and 4KiB), which is split between sprite definitions and the fix layer tilemap.

As far as I know, there's no DMA on Neo-Geo cart systems, but the CD system has DMA for sending data to its RAM chips. Section RAM sizes will be explained later.


380 usable sprites; I'm not sure if multiplexing works at all.


The core Neo-Geo sprite size is 16px wide, and 16-512px tall. Graphics are stored in 16x16 chunks.


Not sure how to compare this one.


2 banks of 256 palettes, 16 colors each. Only one bank can be active at a time. The first 16 sets of palettes can be used by the fix and sprite layers. The remaining palettes can only be used by sprites.


Cart systems have the following limits, without bankswitching:
P (program) ROM theoretical maximum - 2MiB
C (character) ROM theoretical maximum - 128MiB ("if you're planning a Neo-Geo game with more than 128MiB of graphics, find another system")
V (sound) ROM theoretical maximum - 16MiB
M (music driver) ROM theoretical maximum - 62KiB ($F800-$FFFF used as RAM area)
S (fix layer) ROM theoretical maximum - 128KiB
(I hope that's right; got the info from here.)

Cartridges can include extra hardware used for banking, multiplayer (chip specifics), or other functionality.

CD games have different numbers, since the CD system's RAM only allows a certain amount to be loaded at once:
Program - 2MiB
Sprites - 4MiB
ADPCM/sound samples - 1MiB
Fix Tiles - 128KiB
Sound Driver - 64KiB

Mi and Ki notation? Has it really come down to needing to use these terms when referring ram/rom/memory? I mean, it might be a bit more accurate than Mbit/Mbyte or whatever, but it was always understood at what was being stated (binary based system). Just wanted to make an observation that its popularity has been on the rise in the past few years (from what I've seen on forums). Makes me chuckle when people spell out mebibyte or kibibit; like a kindergartener mispronouncing a word.

If you have a chance to prevent confusion or an argument about definitions, why not take it?

I went along with the wiki and what tepples had stated in his posts for consistency; in casual conversations I don't dare say things like "mebibyte" out loud.

I thought this was a no brainer... It's like 4 SNES put together!

Because vertical resolution doesn't impact how much data you can send per line (how many theoretical scanlines does the GBA have? I know it can send a crap ton of data to vram in one frame), you could get 240(4xoverdraw x 4bpp) + 248(4BGs x 8bpp) = 11,776 bits.

With the Neo Geo, it's easier, just do 320(4bpp) + 96(16pixels x 4bpp) = 7,427 bits. That's less than 2/3's as much as the GBA. However, I'm sure the bandwidth of the Neo Geo is actually closer to the GBA in that each sprite is going to have more additional information sent to it than a BG tile on the GBA, but it can't close the gap that much. Me adding the fix layer was also kind of giving the Neo Geo a boost in this comparison.

Plus, like what has been said earlier, the GBA is a lot more flexible in how it can manipulate the graphics in terms of transformation. However, you have to sacrifice a BG layer for every affine transformed one you add. Sprites are fine though. The Neo Geo also doesn't support transparency or (if I'm correct) have window layers, and we don't even know if it supports any sort of sprite multiplexing.


I'd say this is a loss. the GBA can pull of most reasonable object sizes with either less sprites or less bandwidth. 16x512 is bigger than 64x64, but you really only want a size like that if you're creating "BG layers". I'm not even sure why they settled with a size like 512, it's over twice as tall as the screen and ultimately seems like it just takes up more data in vram.

While the GBA can't beat the Neo Geo at every situation (much like how the SNES can't beat the Turbografx at everything but is generally considered more powerful), I'd say it's more powerful overall by a sizable margin. However, there's one thing that the Neo Geo has a great advantage over, and that's the number of palettes available (just like the Turbografx, actually.) I'm not sure what's up with Nintendo's refusal to add more color palettes to their systems. I guess they observed that most arcade boards with 1024+ colors use less than half of them anyway.

I think the Neo Geo's biggest problem is the fact that there are no BG layers. Although the hardware was designed to do this for sprites, it's just not the most efficient way to go about it in that a lot of bandwidth is wasted on loading redundant information, like the x and y of every sprite when they're all linked together. The Neo Geo can display a lot onscreen at a time, but not as much as most of the other arcade machines from the time period. I still don't understand the big scare to using 3BG layers, I mean, you have 1.5x overdraw for sprites, and that's more than the SNES, Genesis, or Turbografx. I think the Neo Geo would have looked better if developers were more conscious of the fact that there aren't actually BG layers on the system but sprites instead. If your background doesn't take up the whole screen, just don't put sprites there. You could have a fighting game where the arena is in the woods and has a log cabin on the right as the only thing in the foreground aside from the ground. Although the ground covers the whole ground horizontally, the log cabin doesn't so there don't need to be blank sprites to the left. Doing this will mean you can't do the auto stick feature thing for sprites, but who cares, it's not like the 12MHz 68000 is taking much of a performance hit.

Is it me or after reading the complete thread we still have no conclusion on why 330 megabits? That was the main goal of the thread... Right?

Wasn't that just about answered in the first post? It's not really 330 (it's 329 and a half, but that'd sound lame).

Also, I think you'd know better in that threads here wander wherever they want to...

330 could just be SNK's counterpart to Heinz's 57.

I was hoping to get something resembling confirmation from anyone who had any more in-depth knowledge, since I managed to rationalize my way to the number 329.5 rather than finding an authoritative answer.

But since none's shown up yet, this is probably the wrong forum to ask. (If, in fact, the answer is even publicly known)

I decided to remove my last post instead of a double post. I thought I was up to something but maybe it was not the case.

For some reason I decided to check wikipedia for the neogeo but in Japanese. I know wikipedia cannot be trusted but what was written in Japanese instead of english was interesting:



They say that until metal slug 2, the "string" that is shown was PRO-GEAR-SPEC. Initially "MAX 330 MEGA" was believed to means the max size of a rom cartridge but on the body (of what, console? box? sometime japanese omit important details) there is string that says "ROM access 330 megabits per seconds". This is written on the box of the neo geo.

I tried to search on the net for the Japanese neo geo box. I found some that shows on the back the specification written in english but with some japanese text scattered around but I cannot find that string, only that it can access 330 megabits. It doesn't seems to be on the console either.

Since wikipedia must be taken with a grain of salt I cannot say that it is the reason until I find the proof. If I find one in the store I will check but in the south of Japan... A little bit hard to find. When I was in Tokyo I could I found one easily.

I found some confidential neo geo dev document by accident but there was no mention on that subject either.

I attached the picture for the back of the box.

Thanks for the interesting research; however...

Honestly, this all sounds like marketing wank. I'm no expert, but if you do some really rough math:

Main CPU: 12M (Mhz) ÷ 4 (cycles/read instruction) x 16 (bits/read instruction) = 46 megabits per second.

Sound CPU: 4M ÷ 7 x 8 = 4.36 megabits per second.

GPU: 24M (÷ ?) x 24 (bits) = 549 megabits per second....?

Yamaha YM2610: (1.85–55.5 khz + (6 * 18.5 kHz)) * 8 (bits/adpcm sample) = 1.27 megabits per second.

So, umm... how does one calculate these or add them all up anyway?

Pixel clock is 6MHz. Both tile busses do fetches at 1.5MHz. CROM data bus is effectively 64 bits wide (it's 32 bit with fake DDR). SROM data bus, similarly, is 16 bits wide.

So that's 80 bits at 1.5MHz, or 120mbit/sec ?

Maybe you get to add all the other data that goes via the P bus? That'd include the L0 vertical shrink control and the palettes for both the fix(S) layer and sprite(C) layer too.

Absolutely. I even conceded that in the first post... it's just ... whence the number?

After searching more on the subject, I think the information written by the person in japanese is not accurate and didn't read the specification on the box properly.

I have come to the same conclusion as everyone, that 330 was used for marketing purpose. I think the number may have been generated based on the possible size of rom, like Lidnariq mentioned.

From the "Product Development Component Specifications", in the "sample cassette board" example they show that fix (s rom) could be 1m, characters (c rom) 8m or 16m, program (p rom) 4/4/8/16m, music (n rom?) 1m and pcm (v rom?) 1/8/16m. A combination of those size and you could have 42m (1/16/8/1/16), max 50m (1/16/16/1/16) which would give something like 336 mbits and 400 mbits.

I gave 8m in first sample since usually program code is smaller than data. To get to 330mbits, since fix shouldn't be big either, if I set 256KiB for it, I would have 41.256 x 8 = 330.048 mbits, after rounding it would give 330.

This is just guess work but hey, I had fun reaching that assumption

I see the 330 in the right end of that statblock, "DIRECT ROM ACCESS CAPABILITY"…but no units.

The box never say anything like what is written in the wiki so my conclusion is the person didn't read the box properly. My guess is the picture I found is from the japanese version since there is japanese text on it but i'm not 100% sure. But with other knowledgeable people who gave opinion on the subject regarding this theory... I think that lead was a false positive. My bad

Sprites can be attached and the system see them like only one (practical to scroll a background and less CPU usage).


Of course it does(a little TF4 demo):
https://www.youtube.com/watch?v=t9NqKXxS9Cw

Additionally, Sengoku Denshou 2 does raster effects on the title screen for a 3-D skew.

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.

Everyone can have their own opinion on what games they think look good. But I certainly don't remember anyone talking about NeoGeo and saying how they wished it looked as good as the SNES, Genesis, or TurboGrafx 16. The systems certainly work quite differently. If you want to see a similar era system that did use background layers you have the CPS2 from Capcom. It featured 3 scrolling background layers. I don't think game players cared which method the hardware uses to draw the picture.

Maybe I just don't understand your criticism of the NeoGeo. Are you just going off specs you read somewhere or actual games?

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?

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

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.


What about the Super NES?


What's being updated then?

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.


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.

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.

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.

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.


Sprites used as a background layer are more likely to "completely occlude" what's behind them.

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.

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.

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.

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.

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.

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

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 :


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.

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.


Did you learn about this in one of your court cases?

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?

Yup, MVS. I also edited my post with slight extra info.
I recall AES having different master clock, something else than 24MHz. I have none to look at though.
EDIT: AES master clock is 24.167829Hz. Seen on schematics on Neo Geo Dev wiki.

3579545 Hz / 227.5 * 384 * 4 = 24167829 Hz

Makes sense, because there are 384 Neo Geo pixels per line, 4 master cycles per pixel, and 227.5 color cycles per line, and 3579545 color cycles per second.