How many sprites can the Neo Geo update per frame?

[creaothceann]

I think somebody roughly estimated once that the 3.58 MHz S-CPU is probably equivalent to a 5-6 MHz 68000. Weaker overall than the Mega Drive CPU, but not nearly as much weaker as the clock speed difference suggests.

If it ran at 3.58mhz. It's closer to 3.05mhz since 65x design roots means it touches ram (slower work ram) for like 90% of its instructions.

Games could theoretically have RAM added on the cartridge and mapped in a fast region ($80..$BF:$8000..$FFFF / $C0..$FF:$0000..$FFFF), and use that as a manually-managed fast instruction and/or data cache.
That's one of the techniques Rebecca Heinemann tried for porting Another World from the Amiga to the SNES.

[turboxray]

I think somebody roughly estimated once that the 3.58 MHz S-CPU is probably equivalent to a 5-6 MHz 68000. Weaker overall than the Mega Drive CPU, but not nearly as much weaker as the clock speed difference suggests.

If it ran at 3.58mhz. It's closer to 3.05mhz since 65x design roots means it touches ram (slower work ram) for like 90% of its instructions.

Games could theoretically have RAM added on the cartridge and mapped in a fast region ($80..$BF:$8000..$FFFF / $C0..$FF:$0000..$FFFF), and use that as a manually-managed fast instruction and/or data cache.
That's one of the techniques Rebecca Heinemann tried for porting Another World from the Amiga to the SNES.

Sure, that's obvious and a given. But afaik we've yet to see anyone use that setup.

[NeoOne]

The Neo Geo's GPU does have a 24-bit data bus https://wiki.neogeodev.org/index.php?title=P_bus. It's really using it too!

Despite what their wiki says, that's primarily an address bus. Only the top 8 bits ever carry data. A bunch of different things are multiplexed on the full 24-bit bus, including fake-DDR 64-bit (32 wires, one clock used as an asynchronous address line; the contents of the P bus are latched by the cartridge, fed to two 16-bit ROMs, and data returned on the CRxx pins) for sprite tile data ("C address") and fake-DDR 16-bit (8 wires, another clock used as an asynchronous address line; again latched by the cartridge, fed to one 8-bit ROM, and data returned on the FIXDx pins) ("S address"). The vertical shrinking table output data is there so that it can be fed back into the address needed for sprite tile fetch, with the low 4 bits where they are so that they can be reused verbatim for the C fetch.

You know a lot more than me! so I will defer to you.. The 24 bit "addressing" is at least used by the larger games because the character number (of each 16 x 16 pixel tile) can be 20 bits long which gives access to a total of 1,048,576 different tiles without bank switching

Even though - like you say - its outputing data in 4 x 8 bits or 2 x 16 bits, it does output 32 total bits of data at a time from the Character ROM when drawing sprite tiles. I *think* the SNES and Megadrive both output 16 bits at a time. I'm sure I have seen some advertising literature where they optimistically(!) call the Neo Geo a 32 bit system. Maybe that is why?

When I code for Neo Geo it seems 100% 16 bit. Only the 68000's 32 bit addresses/registers and the 68000's 24 bit address bus (not fully used by any console) would say anything different.

In terms of advertising, I think the "24 bit" works because the general public doesn't know what "bits" actually means. They really just want a measure of power. And the Neo Geo could be placed ahead of other 16 bit systems of the time. Even the 32 bit Saturn struggles with many Neo Geo games. That's not just animation frames being cut. There can be slowdown when larger characters are on screen. E.g. 2 Fernandeaths on Waku Waku 7. I think the Saturn draws sprites pixel by pixel so large sprites are very hard for it to deal with. But these are very fast/easy on the Neo Geo

[NeoOne]

I remember reading an interview with Argonaut where they said the Super FX can only update the SNES graphics tiles at a set speed. So even if the game had somehow been made faster, the frame rate could not have been 60fps because of this screen update restriction.

They were probably talking about DMA. The S-PPU can't see the cartridge, and the Super FX renders to a framebuffer in Game Pak RAM, on the cartridge. So you have to DMA the finished framebuffer into VRAM in order to see it.

Normally you get about 6 KB of DMA per TV frame (on an NTSC SNES; PAL gets way more), minus overhead and other operations, because VRAM is locked during active display and HBlank. But you can letterbox the screen with forced blanking to get more time.

Typically a Super FX game's framebuffer is something like 224x192 and usually 4bpp, and can in principle be transferred in two blanking periods for a maximum sustainable frame rate of 30 fps. But there are other things that also have to be transferred during VBlank/forced blank, like palette, sprite attributes, and perhaps tilemap information and auxiliary tile data, so 20 fps may be more practical. Star Fox is capped at 20 fps.

There's an additional wrinkle, in that Star Fox, Vortex, and probably a majority of Super FX games were (for budgetary reasons) given insufficient Game Pak RAM to double buffer on the Super FX side. This means that the Super FX has to wait for the whole framebuffer to be transferred before it can start drawing the next frame; all it can do while waiting is clear the parts that have already been transferred. This is why Vortex is basically as slow as Star Fox despite running on a 21 MHz GSU1; essentially, to sustain 20 fps, the game would have to finish rendering in less than one TV frame. Star Fox manages this at the very beginning of the training mission.

Will you have any problems to do with that?

Yes and no, I think. The way I've set up the playfield size and letterboxing, I can transfer a 4bpp rendered layer at 30 fps, or a 2bpp layer at 60 fps, with enough room for the other stuff I have to transfer. Most scenarios will have to use the 4bpp 30 fps mode, but I doubt I'd be able to render some of the busier patterns at a reliable 60 fps anyway. But there are some patterns that do work at 2bpp 60 fps, and some are twitchy enough to need it...

I plan to run all motion and collisions at 60 Hz for accuracy reasons. Only certain components of the visuals will have to run at 30.

It's possible to re-use of sprites using raster interrupt but yes sadly the 96 sprite limit always there though Maybe for some bullet patterns it could use a single group of animated sprites though (Neo Geo is not short on graphics ROM!). That would be a nice trick.

Perhaps. But I think there are enough scenarios with several hundred bullets that are either heavily clustered or in highly chaotic patterns (or both) that tricks like these wouldn't work everywhere. These sorts of workarounds might fit better in an original game where you can design the game to work with the techniques, rather than a port.

The Neo Geo is certainly famous for its game sizes. Somebody once suggested that it could brute-force Space Harrier that way...

On the Y sorting I think you said a bin sort. Wouldn't this be slower than just using bit shifts to the right on object coordinates to just get a "screen zone" number

...no, I said "sorting into bins". Right shift is probably one of the quickest ways to do bin assignment.

Reviewing my code for the 128x128 collisions test, it looks like I used a hash table in WRAM (not the fastest place to put it, but I wanted to keep the ROM small) to assign sprites to cells based on the high byte of Y concatenated with the high 7 bits of X (you can cat bytes quickly on 65C816 by using 8-bit mode; you load one byte, swap the active and hidden halves of the accumulator, and load the other byte)...

The SNES CPU seems underrated. I always thought a lot of developers back in the day were coding it wrong.

I believe it is. You can do some pretty impressive-looking stuff with it if you know what you're doing. As for coding it wrong, I've played a very impressive slowdown removal hack of Gradius III that doesn't use the SA-1 (not to be confused with the more famous one that does), and unless they've fixed it recently, you basically can't play it on Arcade difficulty because the slowdown in the options menu is gone so you have to actually be Takahashi Meijin to tap the button fast enough to enable the secret mode...

I heard some SNES game used slower memory with slower CPU speed which seems crazy now. I think Castlevania was one

Virtually all early SNES games did that, because it was cheaper.

The SNES CPU has funny timing. It's hardwired to access different regions of the memory map at different speeds. There are three types of bus access cycles: Fast (6 master clock cycles per CPU cycle), Slow (8 clocks per cycle), and XSlow (12 clocks per cycle).

Internal (non-bus) cycles are always Fast. Most MMIO access is Fast, except for the serial ports which are XSlow*. WRAM is Slow, annoyingly enough. ROM is Slow, unless you set bit 0 of $420D, in which case ROM in the top half of the memory map is Fast.

Real code is mostly a mix of Fast and Slow cycles; if you set $420D.0 and run your code from bank $80 or higher, it will be closer to 3.58 MHz, and if you don't it will be closer to 2.68 MHz. (Minus the DRAM refresh, of course, which steals ~3% of every scanline...)

Nintendo required the purchase of 120 ns ROM to allow the use of the "FastROM" setting. Otherwise you could cheap out and use 200 ns ROM. Understandably, the prevalence of FastROM increased over the commercial lifetime of the console. (Note that Rendering Ranger R², the game I linked above, used SlowROM despite being a late release; this makes it even more impressive IMO.)


* Fortunately you don't need them much, or at all if you're using standard controllers and you can just use the S-CPU's controller autoread feature, which runs in the background and doesn't steal cycles. This hasn't stopped Sega fanboys from claiming the SNES is capped at 1.79 MHz if a controller is plugged in (or was that guy just a troll?)...

Yes think that was it - the transfer rate to the SNES's VRAM.

So does the VRAM being locked during display mean you cant do raster effects like you can on other consoles? On the Neo Geo you cant change Palette RAm during active display but you can change everything else - VRAM attributes and background color etc

That sounds like a lot of extra effort you have to go to there. I think this is why i code for Neo Geo, is a very simple + elegant system. All you need to know is how to display a sprite and you are 90% there really!

I don't understand hash sorting yet. That's something I will have to learn in the future. It must be fast though if it worked for your 128 object test

I actually have Rendering Ranger. I bought it when it was still a fairly low price (£129 here) It's an impressive game! Do you know the method they use to do collision checking in that? I know the Turrican guy wrote it. So he already had experience of C64 coding. He might use the C64 (8 x 8 pixel grid) style of checking. The SNES probably seemed unlimited to him! Pretty incredible it used slow rom too.

Interesting to read about all the different speeds of ROM/RAM in the system. It seems like FastROM almost became like a natural upgrade as it became more widely used over time. I wish they had just made the SNES 100% fast in all areas to begin with!. I owned a SNES at the time and still do. I avoided all the games with bad slowdown back then - Like Super R-Type - which was a shame

BTW the Neo Geo has a slower cheap ROM option - adds 2 CPU cycles delay to P ROM (the program ROM). Seems a bit strange just having it for that relatively small ROM section though. It seems like the sound and graphics ROM take up most of the cart capacity. Not sure what games used that slower ROM though.

That Sega Vs Nintendo argument is a lot of fun though. I saw a new Final Fight and Parodius being made on Sega Megadrive at the moment. They really seem driven by competition with the SNES even all these years later.

[NeoOne]

Games could theoretically have RAM added on the cartridge and mapped in a fast region ($80..$BF:$8000..$FFFF / $C0..$FF:$0000..$FFFF), and use that as a manually-managed fast instruction and/or data cache.
That's one of the techniques Rebecca Heinemann tried for porting Another World from the Amiga to the SNES.

I don't mean this in a derogatory way at all (I subscribe to live and let live) but every time I see a proper female game coder from back then, I can almost guarantee they used to have a male name. Because... what female do you know would want to spend their time counting CPU cycles?? It's not that women cant do it - its that they dont want to. Men get way more obsessed with all that kind of stuff. You mention this stuff to most women and they will back away from you slowly!

Looks like an interesting article, I will give that a proper read

[creaothceann]

So does the VRAM being locked during display mean you can't do raster effects like you can on other consoles? On the Neo Geo you can't change Palette RAM during active display but you can change everything else - VRAM attributes and background color etc.

VRAM is locked and OAM (sprite RAM) is almost locked - there's one known game (Uniracers/Unirally) that writes to OAM in HBLANK iirc, it only works because there are only 2 sprites active. CGRAM is accessible during horz./vert. blanking, afaik. The screen brightness register can be written to at any time (at least on early SNES models); Air Strike Patrol uses that to show a shaky shadow under the plane.
Most other registers can be changed during blanking. The SNES CPU has a special DMA mode, called HDMA, that writes bytes to the PPU during HBLANK.

Interesting to read about all the different speeds of ROM/RAM in the system. It seems like FastROM almost became like a natural upgrade as it became more widely used over time. I wish they had just made the SNES 100% fast in all areas to begin with!

It's almost always a matter of development time, money, and chip availability...

WRAM (Work RAM, made out of DRAM) seems to be able to handle the ~3.58 MHz, at least at room temperature. Perhaps the prototypes Nintendo used during development couldn't handle it, or got too warm over time. The DMA engine seems to be strictly designed for the ~2.68 MHz speed only.

[Pokun]

That Sega Vs Nintendo argument is a lot of fun though. I saw a new Final Fight and Parodius being made on Sega Megadrive at the moment. They really seem driven by competition with the SNES even all these years later.

Yep they really are. I think it's based on an inferiority-complex of the Mega Drive being the less popular system (at least in Japan, North America and Scandinavia, Sega was more popular in central Europe, UK and south America though) and always being behind Nintendo. This has turned out to be a powerful weapon because the Mega Drive seems to be enjoying much more and better homebrew than the SNES.

[93143]

So does the VRAM being locked during display mean you cant do raster effects like you can on other consoles?

Not at all. The SNES is one of the best raster effect machines out there. You usually don't even need raster IRQs (though of course the SNES has them), because HDMA can be used to automate up to 8 small DMA transfers during each HBlank; this lets you poke S-PPU registers and even rewrite palette entries. HDMA uses a table of values or pointers for each channel, with line counters to avoid needing an entry for every scanline, so setup can be done up front and CPU overhead is minimal.

VRAM itself is closed during active display and HBlank, and will ignore writes. OAM is busy and may put your writes somewhere they don't belong. But most S-PPU registers are wide open during HBlank - scroll, Mode 7 transform (this is how you get perspective, since it's only an affine transform), BG mode, main/sub layer assignment, window edge positions and settings, colour math settings, subscreen backdrop colour, column scroll table VRAM offset, etc. The palette is wide open during HBlank too.

This is not even getting into unintended tricks, like changing VRAM and OAM during HBlank (only useful in certain scenarios due to restrictions or side effects), changing S-PPU settings mid-scanline (can cause transient glitching, but this can often be hidden), changing VRAM offsets for the sprite character tables mid-screen to bust the 16 KB limit (which, to be fair, nobody else has, especially not the Neo Geo)...

...I see creaothceann has already mentioned most of this...

On the Neo Geo you cant change Palette RAm during active display but you can change everything else - VRAM attributes and background color etc

Is the Neo Geo flexible enough to handle the ground in Space Harrier without having to use a separate graphic for every possible camera position? It kinda sounds like it might be.

I don't understand hash sorting yet. That's something I will have to learn in the future. It must be fast though if it worked for your 128 object test

I don't know what hash sorting is, and I may be playing fast and loose with the term "hash table". I just generated a lookup table at boot, such that indexing into it using high(Y) | (high(X) & $FE) gets you the 16-bit address of the desired grid cell.

Do you know the method they use to do collision checking in [Rendering Ranger]?

I haven't looked into it. Perhaps I should...

I avoided all the games with bad slowdown back then - Like Super R-Type - which was a shame

Super R-Type is still pretty good IMO. R-Type III is generally considered to be a lot better (and has a lot less slowdown), but I liked the graphical style and music in Super R-Type more. Maybe it's nostalgia...

That Sega Vs Nintendo argument is a lot of fun though. I saw a new Final Fight and Parodius being made on Sega Megadrive at the moment. They really seem driven by competition with the SNES even all these years later.

There's a video of a Donkey Kong Country 2 demo on Mega Drive that was recently posted on this forum, showing a layer-interlace method that produces a pseudo-BG3 with fake colour blending. It looks pretty decent...

...I just remembered that I tried basically the same trick on SNES myself a while back, on a Mode 7 layer. It looked great on an LCD with a CRT filter, but it looked too flickery on my real TV.

I wish I had the time and spare mental energy to really make progress on this hobby. I might have produced a SNES port of Thunder Force IV by now... At some point, I want to at least do a remix of Metal Squad on the SNES and see what can really be accomplished when you push the chipset (leaving a couple channels and some storage and bandwidth for sound effects, of course, to keep it fair)...

[creaothceann]

VRAM itself is closed during active display and HBlank, and will ignore writes

Fun fact, since the PPUs (~5.37 MHz) are not synchronized to the CPU, there can be some edge cases where a write access will be cut off before the CPU cycle is over.

Also, analog effects can be fun.

At some point, I want to at least do a remix of Metal Squad on the SNES and see what can really be accomplished when you push the chipset (leaving a couple channels and some storage and bandwidth for sound effects, of course, to keep it fair)...

There are some already, if you want to compare:
https://youtu.be/hX0rRtbKYHk
https://youtu.be/clX3P7xjBi0

[93143]

Also, analog effects can be fun.

That's mostly just the FXPak trying to be cute by sneaking bus activity in between SNES accesses, which is not something I plan to worry about.

The INIDISP bug is real, though, and may have to be worked around if you're messing with brightness during HBlank. Fortunately it's pretty simple to set the destination address to $FF and do a two-registers-write-once HDMA transfer that writes the same value both times, which coincidentally also solves the DMA failure bug when leaving the address of the last HDMA channel at $00.

At some point, I want to at least do a remix of Metal Squad on the SNES and see what can really be accomplished when you push the chipset (leaving a couple channels and some storage and bandwidth for sound effects, of course, to keep it fair)...

There are some already, if you want to compare:
https://youtu.be/hX0rRtbKYHk
https://youtu.be/clX3P7xjBi0

The first one is competent but a tad basic. The second one has more personality, though it sounds a bit out of tune, and is IMO a respectable port (assuming it's an actual SNES track and not a soundfont mockup).

But there are a few tricks they aren't using, and I feel like it's possible to do quite a bit better.

This is all in the context of NeoOne's remark about the Mega Drive guys keeping the console war alive...

[turboxray]

That Sega Vs Nintendo argument is a lot of fun though. I saw a new Final Fight and Parodius being made on Sega Megadrive at the moment. They really seem driven by competition with the SNES even all these years later.

Yep they really are. I think it's based on an inferiority-complex of the Mega Drive being the less popular system (at least in Japan, North America and Scandinavia, Sega was more popular in central Europe, UK and south America though) and always being behind Nintendo. This has turned out to be a powerful weapon because the Mega Drive seems to be enjoying much more and better homebrew than the SNES.

Who told you the Genesis was less popular in the US/NA??? It was toe to toe. Even felt like the SNES was slipping the first two years.

[Pokun]

The Genesis obviously had a place in the NA market, otherwise we wouldn't see so many enthusiasts (much more than certain other systems), and I also believe the Mega Drive was more popular in Japan than some people says (at least it's a lot easier to find Japanese MD games than for older Sega systems), but if looking at sales I think it's quite clear that Nintendo had the edge and won the console war for that generation in both those regions.

Sweden was pretty much the same, the MD was pretty big, much bigger than the SMS before it (and the SC-3000 had only been released in Finland) but Nintendo, via Bergsala, always dominated Scandinavia, unlike certain other parts of Europe where Sega dominated.

In Scandinavia I think Sega did best in Finland. Finland even got to serve as a test market for the PAL version of the Saturn modem (though which was canceled), perhaps partly because they had a foot in there.

[Fiskbit]

Japan keeps pretty good sales records. Mega Drive was Sega's 2nd most successful console at 3.6 million, besting their earlier consoles (which peaked at 1 million for the Mark III) and being beaten only by the Saturn at 5.6 million. In comparison, the Super Famicom sold 17 million consoles, nearly 5x the Mega Drive.

In contrast, the Genesis and SNES had very similar sales in North America (both around 20 million). The majority of the Mega Drive's / Genesis' sales were in North America.

[Pokun]

the Genesis and SNES had very similar sales in North America (both around 20 million). The majority of the Mega Drive's / Genesis' sales were in North America.

OK I didn't know that Sega was so close on to Nintendo there. I think Sega won in Europe as a whole though, even if total sales are of course lower than in North America.

The Saturn did great and even beat the Nintendo 64 (though marginally) in Japan, but did poorly elsewhere and ended up a commercial failure (unlike the 64).

[NeoOne]

Sorry for delay to answer! Busy times. I did get all 380 Neo Geo sprites in that *simple* shooting game (at 60fps) I was working on. So I can say that is definitely possible. They are all separate sprites apart from the player's ship - which is 2 sprites joined together.

I only had to convert a couple of routines into assembler to hit the 60fps. Currently all the collision routines are still in C but I will convert one of them just to be sure (on some frames there is just one line of display time left so it's tight!)

VRAM is locked and OAM (sprite RAM) is almost locked - there's one known game (Uniracers/Unirally) that writes to OAM in HBLANK iirc, it only works because there are only 2 sprites active. CGRAM is accessible during horz./vert. blanking, afaik. The screen brightness register can be written to at any time (at least on early SNES models); Air Strike Patrol uses that to show a shaky shadow under the plane.
Most other registers can be changed during blanking. The SNES CPU has a special DMA mode, called HDMA, that writes bytes to the PPU during HBLANK.

I used to play Uniracers at a friend's house! It was a fun game for a while. What does the write to OAM do? Is it used for shadows again?

That's a cool trick with the shadow on Air Strike. I was actually thinking about something like that for Neo Geo because it has a "shadow" effect it can turn on and off. It's normally used on the whole screen in "pause" mode. It might be hard to get it accurately placed though.

That's a clever trick, but why did they do that rather than use a duplicate sprite or other transparency effect on the SNES?

Air Strike looks interesting to play. I will have to check that one out. I like isometric games.

It's almost always a matter of development time, money, and chip availability...

WRAM (Work RAM, made out of DRAM) seems to be able to handle the ~3.58 MHz, at least at room temperature. Perhaps the prototypes Nintendo used during development couldn't handle it, or got too warm over time. The DMA engine seems to be strictly designed for the ~2.68 MHz speed only.

3.58mhz doesn't seem that fast for RAM or ROM in the 90s. But I don't know much about ROM costs. But would it have been much more expensive? Maybe it was a way for Nintendo to charge developers more for carts?!