How many sprites can the Neo Geo update per frame?

[NeoOne]

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

Very interesting to read and learn about all this. I have heard of HDMA before. There is a guy about online who knows a lot about the SNES and makes cool parallax demos that should run on the SNES which some people were critical of. I forget his name but it was from him. He seemed to know his stuff though.

Coming from the Neo Geo, it amazes me how complicated the SNES and Megadrive are to code for. But they do have some nice graphical effects they can use. On the Neo Geo, you draw everything straight from the cartridge - you don't move any graphics data into VRAM. So even that is easy and simple. I used to do some simple coding on the Amiga, and that could be complicated too, because of all the chips it had to use to do stuff.

8 transfers during 8 blank seems like a good number. Nintendo definitely thought that aspect of the machine through well. What does "16kb limit" mean? Is that the total OAM space?

I always thought Axelay used mode 7 raster effects for the 1st level background where it kind of warps and rolls round?

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.

Yes for sure. You can make a whole screen horizintally scrolling background with 21+ sprites (each sprite is 16 x 512 pixels so you put 20 side by side = 320 pixels to cover screen width + some extra for scroll on). Then you "stick" them together in hardware, so any changes you make to the first sprite is made to the others (apart from x zooming which is independent). Then you set the timer interrupt for each line, and change the x coord of the first sprite only, to scroll each line at a different speed. I think with the Space Harrier background you can just snap back to a repeat point in the pattern too.

Each interrupt (just the interrupt not the VRAM writing) would take maybe 130+ CPU cycles total (including acknowledge, saving/restoring registers, returning to main program etc). There are 768 CPU cycles per line, so to do every screen line might turn the 12Mhz CPU into a 9 MHz one I just guessed at that cycle count for interrupts but I'm sure it's more than 100

There are issues with sprite scaling on Neo Geo though that make those kind of games more work than you would expect. To do with the horizontal sprite limit (96 sprites) and how when sprites are shrunk vertically - they still use their original height for horizontal sprite limit calculations. So you can run out of horizontal sprites if you are not careful. You can get around this by turning the sprites off with interrupts etc and by using prestored inbetween sprites. But I think this is why there aren't many super scalar style games on the Neo Geo.

There is a demo game here that uses that kind of background https://www.youtube.com/watch?v=1ZGM55RpYHE. I know this one interrupts every 2 screen lines. It eventually evolved and became a bonus game in a game called NeoTris (yes Tetris!)

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

I think R-Type 3 uses smaller sprites so they don't quite have the visual impact. Still looks good though! I really like the Japanese box for that. It's a bold pink and white choice. Would be great to have Dragon Breed (another IREM game) on the SNES with that huge dragon. Even the Amiga had a pretty good version of that albeit at a lower frame rate.

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

It looks pretty good but not as colorful as the SNES. Clever idea though. Yes you need to fight back You should def do ThunderForce IV when you get more time - or when in retirement That would be a real statement of intent. I hope you can get more energy and rest soon. Coding really takes up a lot of time and mind power. I know that!

[creaothceann]

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?

(see attachment)
In 1-player mode there's only a single sprite on screen, for player 1.
In 2-player mode the game disables active display in the middle of the screen, writes a single byte to OAM (to the 32-byte region that controls the size and x-position of the sprites?) and writes to the PPU to scroll the backgrounds to a different position.

Basically it re-uses the same sprites instead of defining multiple sprites, like any other game on the system is doing.

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

That way they can use transparency for other stuff. Or they liked the "shaky" nature of the shadow (like most CPUs the SNES CPU can only serve the IRQ once it has finished executing the current instruction, and different instructions have different cycle counts).

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?!

Well, development of the SNES was started after the NES, between 1983 and 1987 (?). The WRAM size was actually increased some time after 1988 from 8 KiB to 128 KiB. (EDIT: 1989 it was 32 KiB)
Many games were SlowROM ("Can you use the slower ROM, it'll save 50 cents a cartridge").

8 transfers during 8 blank

Up to 8 DMA channels that can be configured for HDMA, each doing a 1 to 4 byte write access per HBLANK (iirc).
Some games even streamed audio data to the APU to overcome its 64 KiB RAM limit...

What does "16kb limit" mean? Is that the total OAM space?

I think that's referring to the amount of VRAM that can be used at once for sprite tiles? OAM memory is only 544 bytes (a 512-byte area of 4 bytes per sprite and a 32-byte area of 2 bits per sprite). RAM, especially video RAM, always was and is a very tight resource.

I always thought Axelay used mode 7 raster effects for the 1st level background where it kind of warps and rolls round?

Nope: https://youtu.be/vZmrZCpBJhc?list=PLLM_ ... nvdu&t=357

[93143]

Coming from the Neo Geo, it amazes me how complicated the SNES and Megadrive are to code for.

From what I understand, Neo Geo is much more of a brute force machine. Fairly simple but very expensive and therefore very capable. The consumer-grade home consoles couldn't throw ROM and CPU power at problems, so they had to get tricky. Especially the SNES.

Yes for sure. You can make a whole screen horizintally scrolling background with 21+ sprites (each sprite is 16 x 512 pixels so you put 20 side by side = 320 pixels to cover screen width + some extra for scroll on). Then you "stick" them together in hardware, so any changes you make to the first sprite is made to the others (apart from x zooming which is independent). Then you set the timer interrupt for each line, and change the x coord of the first sprite only, to scroll each line at a different speed. I think with the Space Harrier background you can just snap back to a repeat point in the pattern too.

Cool. I guess the joke was that the Neo Geo could do it entirely by switching out static graphics, not that it would necessarily have to.

Each interrupt (just the interrupt not the VRAM writing) would take maybe 130+ CPU cycles total (including acknowledge, saving/restoring registers, returning to main program etc).

The 65C816 is from a processor family that was designed for fast interrupts, so let's see how it stacks up:

An IRQ that sets 16-bit mode before both saving and restoring all three registers would take (by my count) 48 CPU cycles, or 354 master cycles, not including what the meat of the IRQ actually does. The master clock is 21.477 MHz, and a scanline is 1364 master cycles long, but 40 mcycles are stolen for DRAM refresh in the middle of the active scanline. So 354 mcycles is nearly 27% of the available time during a scanline (this is assuming no trampoline to get into FastROM, since the IRQ vector is only 16-bit and ROM in bank 0 is unconditionally Slow).

Of course, you may not need to push and pull every register and specify 16-bit mode both times; it may be possible to get away with just pushing and pulling A in the mode you're going to use for the active part of the handler. Assuming that's 8-bit (the scroll registers are 8 bits write twice), if I did my math right, the overhead would be 25 CPU cycles, or 184 master cycles, or about 14% of the scanline. Less than your estimate for the Neo Geo.

HDMA, of course, just skips all that and writes the values, taking an average of about 18 master cycles (depending on sync) per line of active HDMA, plus 8 master cycles per channel and 8 master cycles per byte written. A 2-byte transfer, with no other channels active to share the overhead, would therefore take a little over 3% of a scanline in total, including the actual transfer.

There are issues with sprite scaling on Neo Geo though that make those kind of games more work than you would expect. To do with the horizontal sprite limit (96 sprites) and how when sprites are shrunk vertically - they still use their original height for horizontal sprite limit calculations. So you can run out of horizontal sprites if you are not careful. You can get around this by turning the sprites off with interrupts

I know the pain of bumping one's head on the horizontal sprite limit - in my case, the 34-tile line buffer rendering limit due to the limited length of HBlank. My shmup port uses Mode 7 for some backdrops, which means I have to use a layer of sprites to display the Super FX framebuffer, and that, plus the left border, plus the garbage mask for the mode switch to do the sidebar in Mode 1, puts me at 25-26 tiles per line before anything even happens. (It also puts me over the 16 KB limit, but as I mentioned there is a way around that.) I'm thinking about checking player bullets for vertical collisions with other hardware sprites and actively flickering them to prevent more important stuff from flickering or disappearing.

I wish it were easier to mess with OAM during a frame on SNES. I think Super Mario Kart completely replaces it midscreen, but it isn't subtle about it (actually, that black bar is thicker than it needed to be; I wonder if they're doing something else in there too)...

mariokart.png

There is a demo game here that uses that kind of background https://www.youtube.com/watch?v=1ZGM55RpYHE.

Interesting. Looks really nice. There is a bit of Z-fighting going on in the distance now and then; I assume this is where the sprite priority wraps...

You should def do ThunderForce IV when you get more time - or when in retirement

Heh. There are a number of games ahead of it in the list (though the Metal Squad remix is ahead of most of those). I'm not much of a primary creative, but unrealized potential attracts me, so my list is full of ports and sequels, with one or two original games far down the list due to practicality issues...

3.58mhz doesn't seem that fast for RAM or ROM in the 90s.

It's not. The 65C816 inherits the half-cycle bus access behaviour of the 6502, so it takes 6 master cycles to produce a 3-master-cycle memory access, or 8 to produce a 5-mcycle access. I suspect that if Ricoh had done whatever Hudson did with the HuC6280, this wouldn't have been the case, but they didn't.

Basically it re-uses the same sprites instead of defining multiple sprites, like any other game on the system is doing.

Can't at least one of the unicycles on one half of the screen run into the screen split? Doing this prevents it from showing up on the other guy's screen.

It's still weird, because while the black separator between the screens is much thinner than with SMK, it's still more than thick enough to force blank and reassign a couple of sprites...

Some games even streamed audio data to the APU to overcome its 64 KiB RAM limit...

They did (notably Tales of Phantasia and Star Ocean), but I don't think any commercial games did it with HDMA specifically; I believe they just did it manually with CPU-to-CPU handshake methods. I think d4s might have been the first to do HDMA streaming, with N-Warp Daisakusen. More recently, lex managed it too. I came up with a method myself, but I haven't used it for anything yet; it's slated for use in my shmup port and basically every other major project I get around to (if any).

I just wish the ENDX register could be reset per-bit rather than all at once; it makes it a pain to use more than one long stream at a time. It's not like it'd be hard; you write to it to reset it, so why not just use the written bits to specify which ones to clear? Oh well...

What does "16kb limit" mean? Is that the total OAM space?

I think that's referring to the amount of VRAM that can be used at once for sprite tiles? OAM memory is only 544 bytes (a 512-byte area of 4 bytes per sprite and a 32-byte area of 2 bits per sprite). RAM, especially video RAM, always was and is a very tight resource.

OAM uses a single byte per entry to specify the top-left 8x8 tile of the sprite in a 16x16 grid of 8x8 tiles. At 4bpp, that's 8 KB. The attribute byte in an OAM entry also contains a single bit to specify the nametable to use, expanding the available space to 16 KB.

The OBSEL register ($2101) specifies the position of the first table in VRAM, as well as the offset of the second table from the first (and also specifies the two available sprite sizes). So those 16 KB of sprite tiles can be anywhere in VRAM, in two 8 KB chunks.

It is possible to rewrite OBSEL during active rendering, changing where the S-PPU looks for sprite graphics and thus breaking the 16 KB limit within a single frame. (This should be done during an active line and not during HBlank, because sprites are rendered during HBlank and changing OBSEL then will cause visible glitching.) As you will readily understand, this trick is difficult to use effectively in the general case, but if you're using sprites to fake a BG layer, it can be very helpful.

The Mega Drive's sprite system is simpler and more flexible, even though the specs on paper are much less impressive. Sprite graphics are stored linearly instead of in a grid, they can be anywhere in VRAM, and each sprite can have unique and different X and Y sizes.

I always thought Axelay used mode 7 raster effects for the 1st level background where it kind of warps and rolls round?

Nope: https://youtu.be/vZmrZCpBJhc?list=PLLM_ ... nvdu&t=357

Yeah, that looks cool but it's not Mode 7, or particularly difficult to pull off without it. The Mega Drive can do it too, although I must say that the additively-blended horizon in Axelay does add some flair...

[creaothceann]

Some games even streamed audio data to the APU to overcome its 64 KiB RAM limit...

They did (notably Tales of Phantasia and Star Ocean), but I don't think any commercial games did it with HDMA specifically; I believe they just did it manually with CPU-to-CPU handshake methods. I think d4s might have been the first to do HDMA streaming, with N-Warp Daisakusen.

byuu/Near mentioned ClayFighter: Tournament Edition (though I couldn't hear a difference between ZSNES and higan) and Earthworm Jim 2.

I guess an emulator author could easily add an if-statement in the HDMA code that blocks writes to the APU, and test some games.

[turboxray]

I always thought Axelay used mode 7 raster effects for the 1st level background where it kind of warps and rolls round?

Nope: https://youtu.be/vZmrZCpBJhc?list=PLLM_ ... nvdu&t=357

Yeah, that looks cool but it's not Mode 7, or particularly difficult to pull off without it. The Mega Drive can do it too, although I must say that the additively-blended horizon in Axelay does add some flair...

And the PCE/SGX too: https://www.youtube.com/watch?v=CutMY8MOGRE
Though, with all 16 subpalettes just for the BG layers.. he could have added the fade effect that he did with his Hu-Zero demo.

[NeoOne]

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?

(see attachment)
In 1-player mode there's only a single sprite on screen, for player 1.
In 2-player mode the game disables active display in the middle of the screen, writes a single byte to OAM (to the 32-byte region that controls the size and x-position of the sprites?) and writes to the PPU to scroll the backgrounds to a different position.

Basically it re-uses the same sprites instead of defining multiple sprites, like any other game on the system is doing.

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

That way they can use transparency for other stuff. Or they liked the "shaky" nature of the shadow (like most CPUs the SNES CPU can only serve the IRQ once it has finished executing the current instruction, and different instructions have different cycle counts).

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?!

Well, development of the SNES was started after the NES, between 1983 and 1987 (?). The WRAM size was actually increased some time after 1988 from 8 KiB to 128 KiB. (EDIT: 1989 it was 32 KiB)
Many games were SlowROM ("Can you use the slower ROM, it'll save 50 cents a cartridge").

8 transfers during 8 blank

Up to 8 DMA channels that can be configured for HDMA, each doing a 1 to 4 byte write access per HBLANK (iirc).
Some games even streamed audio data to the APU to overcome its 64 KiB RAM limit...

What does "16kb limit" mean? Is that the total OAM space?

I think that's referring to the amount of VRAM that can be used at once for sprite tiles? OAM memory is only 544 bytes (a 512-byte area of 4 bytes per sprite and a 32-byte area of 2 bits per sprite). RAM, especially video RAM, always was and is a very tight resource.

I always thought Axelay used mode 7 raster effects for the 1st level background where it kind of warps and rolls round?

Nope: https://youtu.be/vZmrZCpBJhc?list=PLLM_ ... nvdu&t=357

Thanks for all the info. It's good to learn and understand this more.

BTW the Neo Geo CD has DMA but its slower than using the 68000 (with MOVEM) to do memory copies! Also *I think* it locks up the system. I've heard people use it to stop hackers transferring Neo Geo CD games straight over to the cartridge system (since the cartridge system doesnt have DMA) but not sure it has much practical use otherwise

Re Uniracers - that's pretty crazy, to just use only 2 sprites in a game. Uniracers really seems like a tech demo they made into a game. Although I enjoyed playing it, it did get dull quite fast. Needed some extra stuff going on. A bit too simple. Clever hardware tricks though!

I guess 50 cents per cartridge adds up but I hate the idea of slower ROM. I think I just want a system to run at peak speed always. I remember a friend, back-in-the day selling his SNES early on because of the slowdown on many games. He did buy one again later though

[NeoOne]

From what I understand, Neo Geo is much more of a brute force machine. Fairly simple but very expensive and therefore very capable. The consumer-grade home consoles couldn't throw ROM and CPU power at problems, so they had to get tricky. Especially the SNES.

Yes it did seem like sprites were expensive back then (I guess you also need a certain amount of speed/memory bandwidth to display lot of them per line). Before I knew how other games consoles worked though, I always assumed they could display graphics straight from the cart. That would be the logical way to do it, but having that kind of high speed connection is expensive also...

Cool. I guess the joke was that the Neo Geo could do it entirely by switching out static graphics, not that it would necessarily have to.

It could def do the background like that. If you look at the game Fast Striker https://www.youtube.com/watch?v=Z5niUFJb98Q (sorry, I cant find a good picture quality video of this game, probably because the ROM hasn't been hacked). They use animated backgrounds on most of the stages on that. They use 120 full screen frames (at 60fps) to make a repeating 3D effect that loops every 2 seconds. The mid boss on the first level uses 32 Megabits of ROM by itself.

So you can go really crazy on the Neo Geo if you want to. But even so, you probably use up more space than you think. Fast Striker is a 1560 megabit cart (197 MegaBytes)

The 65C816 is from a processor family that was designed for fast interrupts, so let's see how it stacks up:

An IRQ that sets 16-bit mode before both saving and restoring all three registers would take (by my count) 48 CPU cycles, or 354 master cycles, not including what the meat of the IRQ actually does. The master clock is 21.477 MHz, and a scanline is 1364 master cycles long, but 40 mcycles are stolen for DRAM refresh in the middle of the active scanline. So 354 mcycles is nearly 27% of the available time during a scanline (this is assuming no trampoline to get into FastROM, since the IRQ vector is only 16-bit and ROM in bank 0 is unconditionally Slow).

Of course, you may not need to push and pull every register and specify 16-bit mode both times; it may be possible to get away with just pushing and pulling A in the mode you're going to use for the active part of the handler. Assuming that's 8-bit (the scroll registers are 8 bits write twice), if I did my math right, the overhead would be 25 CPU cycles, or 184 master cycles, or about 14% of the scanline. Less than your estimate for the Neo Geo.

HDMA, of course, just skips all that and writes the values, taking an average of about 18 master cycles (depending on sync) per line of active HDMA, plus 8 master cycles per channel and 8 master cycles per byte written. A 2-byte transfer, with no other channels active to share the overhead, would therefore take a little over 3% of a scanline in total, including the actual transfer.

That doesn't surprise me because 68000 seems slow for interrupts (As well as memory access!). It would be good to have something like HDMA on Neo Geo. BTW I changed my estimate to around 150 cycles now for a line interrupt on Neo Geo (that includes saving/restoring of the 4 scratch regs d0,d1,a0,a1) To interrupt every visible display line (224 lines) would bring effective speed of Neo Geo CPU down to 10Mhz. Still not terrible though.

6502 based CPU's seem faster for many things (cycle by cycle). Although the 68000 was designed to run faster I suppose. I used to do some simple coding on the standard Amiga (also 68000 based) and it has a Copper chip (Coprocessor) that just has 3 instructions. They basically allow you to wait for any line/time and then write values to the hardware registers. So you can play around with the display as much as you like for free. You can do things like swap between a low-resolution screens and higher resolution screens and then back again, as you go down the display. Or re-use sprites many times etc. Amiga is not that great for games otherwise but it is super flexible

Neo Geo CD has DMA but its slower than using the 68000! I think it locks up the CPU while you use it too

I know the pain of bumping one's head on the horizontal sprite limit - in my case, the 34-tile line buffer rendering limit due to the limited length of HBlank. My shmup port uses Mode 7 for some backdrops, which means I have to use a layer of sprites to display the Super FX framebuffer, and that, plus the left border, plus the garbage mask for the mode switch to do the sidebar in Mode 1, puts me at 25-26 tiles per line before anything even happens. (It also puts me over the 16 KB limit, but as I mentioned there is a way around that.) I'm thinking about checking player bullets for vertical collisions with other hardware sprites and actively flickering them to prevent more important stuff from flickering or disappearing.

I wish it were easier to mess with OAM during a frame on SNES. I think Super Mario Kart completely replaces it midscreen, but it isn't subtle about it (actually, that black bar is thicker than it needed to be; I wonder if they're doing something else in there too)...

Are you effectively using SNES sprites to display "sprite objects" that the Super FX draws to the buffer then ? But yes that is a big bite into your horizontal limit there! You really seem to be using every feature of the SNES in your game

I suppose that bar on Mario Kart is quite thick but no one noticed it at the time. On old computers they often use blank screen space (memory) to store variables! They turn the colors to all black and then just stick a load of extra variables in there.

I wish every system could display as many sprite per line as its total number of sprites. I do understand there would need to be a very high rate of output to achieve this though. I know Mattel Intellivision does this - admittedly only 8 sprites.

Heh. There are a number of games ahead of it in the list (though the Metal Squad remix is ahead of most of those). I'm not much of a primary creative, but unrealized potential attracts me, so my list is full of ports and sequels, with one or two original games far down the list due to practicality issues...

Do it for the SNES Squad! I understand though. You got to do what interests you or you will lose interest in teh project half way through. On the Amiga forum I was on, they were trying to make ThunderForce IV on there. Also there is a Neo Geo demo somewhere of it too - but only the background so far. People really use that game as a yardstick!

I always thought Axelay used mode 7 raster effects for the 1st level background where it kind of warps and rolls round?

Nope: https://youtu.be/vZmrZCpBJhc?list=PLLM_ ... nvdu&t=357

Yeah, that looks cool but it's not Mode 7, or particularly difficult to pull off without it. The Mega Drive can do it too, although I must say that the additively-blended horizon in Axelay does add some flair...

I have actually watched that video before but I forgot! I think everyone thinks its mode 7 because we only saw it on the SNES. Maybe that rotating hall in Castelvania many people thought was somehow mode 7 back in the day too. My fav use of Mode 7 - it might be in that video or one of them - was when the guy who did Wolfenstein on SNES used it to scale the screen up. I thought that was very clever.

It does seem like Mode 7 would have a lot of potential for actual Raster effects though. On the Neo Geo I always think the X shrink would be useful for cool raster effects.

[creaothceann]

BTW the Neo Geo CD has DMA but its slower than using the 68000 (with MOVEM) to do memory copies! Also *I think* it locks up the system. I've heard people use it to stop hackers transferring Neo Geo CD games straight over to the cartridge system (since the cartridge system doesnt have DMA) but not sure it has much practical use otherwise

It also stops the main program on the SNES, since there's only one CPU data bus. The PPU can still render pixels, and HDMA overrides regular DMA. The audio subsystem is also quite separated. Afaik the DMA transfers just activate the /rd control line of one device and the /wr control line of another device, so it transfers 8 bits at once per memory cycle.

Yes it did seem like sprites were expensive back then (I guess you also need a certain amount of speed/memory bandwidth to display lot of them per line).

I find it fascinating that, on 2D systems, the sprite line buffer is the closest equivalent to the flexible framebuffers of 3D systems (PSX and above). The tile slices are simply blitted into it, there's no fancy logic that decides which one has priority (which is what probably happens with the backgrounds).

That doesn't surprise me because 68000 seems slow for interrupts (As well as memory access!). [...] 6502 based CPU's seem faster for many things (cycle by cycle).

Yeah, but it's always worth remembering that the number of cycles can't always be compared, you really have to translate them to nanoseconds. The Genesis, for all its much-touted speed, has the same or slower ROM access speed (but twice the bandwidth).
The 65xxx systems also have several stages in their memory transfers, but those are not coupled to clock ticks.

They basically allow you to wait for any line/time and then write values to the hardware registers. [...] You can do things like swap between a low-resolution screens and higher resolution screens and then back again, as you go down the display. Or re-use sprites many times etc.

Yeah, that'd sound very familiar to programmers that know HDMA.

I think everyone thinks its mode 7 because we only saw it on the SNES

Racing games could use that technique too.

[SNES AYE]

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.

This is interesting. Following up on your comment, as well as some of the earlier discussion, I’d like to add my own observations:

Official reports show that the SNES sold 49.1 million units worldwide, with 17.7 million of those in Japan. By comparison, the Genesis sold roughly 35 million units globally, based on the CESA White Paper total of 30.75 million and the few other remotely reliable sources available, such as NPD data. The 35 million estimate also includes the Brazilian market (with figures of around 3 million units sold according to Tectoy) and the projected Majesco figures for the Genesis 3 (about 1.5 million units), along with the frequently cited estimate of roughly 3.6 million units sold in Japan (we can go with that for now).

If the cited figure of “around 20 million units in North America” for each system is accurate—though a 2014 Wedbush Securities report based on revised NPD sales data, actually states that the SNES outsold the Genesis in the U.S. by 1.5 million units—this would leave approximately 11.4 million units for the rest of the world for both systems.

We could summarize the results as follows:

Japan: Decisive win for the SNES.
North America: Roughly a draw, though revised NPD data suggests a slight edge for the SNES.
Rest of the world: Essentially then also a draw, with regional variations (Genesis will have outperformed SNES in some areas, while SNES led in others).

Alternatively, if we trust the revised NPD data, the picture looks like this:

Japan: Decisive win for the SNES.
North America: Slight edge for the SNES.
Rest of the world: Slight edge for the Genesis.

I know this has nothing to do with how many sprites the Neo Geo can update per frame, mind you, but I thought I’d contribute to this side discussion since I have very little understanding of what the Neo Geo is capable of beyond the usual details. Hopefully that’s okay and aligns with the other side comments.

[Pokun]

The Mega Drive was also slightly outsold by the PC Engine (around 3.9 millions) in Japan, making Sega's machine coming in 3rd place for home consoles of that generation. It sold around 10 millions worldwide (despite hardly being officially released outside Korea and North America where it failed), so against the Mega Drive's 35 millions PC Engine comes in 3rd worldwide.

I'm not sure if that counts all models though as I've seen additional numbers where the SuperGrafx, GT and Duo models are included for a total of just under 14 millions. It's a bit silly not to count GT and Duo etc since they use the same hardware (the SuperGrafx is more of an enhanced version though like the GB and the GBC).

Found sales here (it states that Mega Drive sales are only 31 millions though).

[SNES AYE]

Yeah, that looks cool but it's not Mode 7, or particularly difficult to pull off without it. The Mega Drive can do it too, although I must say that the additively-blended horizon in Axelay does add some flair...

There’s also a great example in Super Turrican 2 that adds a third layer to the effect:

https://youtu.be/5CFd7qc_EjY?t=3364

And technically—though I’ve never seen an actual demonstration—it should be possible to pull this effect off with four full background layers on the SNES (albeit with reduced color). I believe they could even include a similar window-masking effect as seen at the start of the Super Turrican 2 level too. I’d love to see someone attempt that feat one day!

[Dwedit]

Or maybe 3 layers and a window? Basic convex shapes can be made out of a window for things like shadows without needing a complete layer.

[SNES AYE]

Or maybe 3 layers and a window? Basic convex shapes can be made out of a window for things like shadows without needing a complete layer.

Sure. Also, I believe the window(s) can be applied so that, when working in Mode 0 with four backgrounds, it could visually appear
as four overlapping layers with the window mask(s) on top—effectively creating the illusion of five layers, or even six if the two window masks are drawn as separate moving shapes. At least, that’s how I currently understand it. Is that correct? I hope that makes sense as I’ve described it.

[93143]

Yes it did seem like sprites were expensive back then (I guess you also need a certain amount of speed/memory bandwidth to display lot of them per line).

The S-PPU uses the active display portion of the line to scan OAM (which is separate from VRAM) to collect a list of up to 32 sprites that overlap the next scanline. VRAM is simultaneously occupied entirely with loading background layer map and tile data, with the fetch pattern depending on the BGMODE setting. Then, during HBlank, the S-PPU starts loading sprite tile data from VRAM and rendering it into a line buffer; there's enough time allocated for this in HBlank for 34 8-pixel tile rows to be rendered before background layer data loading has to start again.

That's what you get with the hardware they could afford and the decisions they made on how to use it.

The Mega Drive only supports 16 (or 20) sprites per scanline, possibly because their sprite attribute table is in VRAM and has to share bandwidth with the BG layers. But the tiles-per-line limit is only slightly lower at 32 (or 40), resulting in 100% line coverage for the Mega Drive in both modes, versus 106.25% line coverage for the SNES.

Before I knew how other games consoles worked though, I always assumed they could display graphics straight from the cart. That would be the logical way to do it, but having that kind of high speed connection is expensive also...

The NES did it that way. It was a cost-saving measure, because the wider cartridge connector was cheaper than a large pool of VRAM would have been. I'm not sure what the thought process was when they decided not to allow that on the SNES - perhaps they wanted to allow developers to use compressed graphics and/or software-rendered framebuffers without having to stick a bunch of expensive RAM on the cartridge, and giving the S-PPU full access to VRAM and full access to cartridge-based CHR ROM/RAM would have been a bit much...

If you look at the game Fast Striker https://www.youtube.com/watch?v=Z5niUFJb98Q

I remember that game from way back. It really does look amazing for a Neo Geo game, even if the backdrops are a little repetitive.

To interrupt every visible display line (224 lines) would bring effective speed of Neo Geo CPU down to 10Mhz. Still not terrible though.

That's the advantage of arcade hardware. You can take a hit like that and keep going strong. A 2.68 MHz 68000 would have been horrible for raster interrupts (though I suppose that was never a real risk, as the 68000 can operate much faster than the 65C816 on the same memory spec)...

I used to do some simple coding on the standard Amiga (also 68000 based) and it has a Copper chip (Coprocessor) that just has 3 instructions. They basically allow you to wait for any line/time and then write values to the hardware registers. So you can play around with the display as much as you like for free.

Isn't Copper capable of precise mid-scanline writes? I seem to recall it pulling off stuff the SNES couldn't do, at least not without reengineering it to not need pixel-perfect raster effects...

Then again, the SNES is capable of changing a lot more things than you'd think mid-scanline, and some of them can be done without glitching, if you're super careful (and you're willing to lose a big chunk of the compute time you'd otherwise have on that scanline). Maybe I'm being too pessimistic... still, Copper is quite the resource; almost like HDMA for both axes instead of just one, if I've understood it correctly...

Are you effectively using SNES sprites to display "sprite objects" that the Super FX draws to the buffer then ?

Yes. As I've mentioned, there are way too many bullets to use hardware sprites for them, so I draw them into a framebuffer with the Super FX. Normally one would use a background layer to display a Super FX framebuffer. But a bunch of stages and bosses in this game have backdrop effects that can only be properly achieved with Mode 7, and Mode 7 only gives you one BG layer*: the affine layer. So to overlay the Super FX framebuffer on the Mode 7 backdrop, I have to use a grid of large sprites as a fake second layer.

It's not as bad when I don't need Mode 7 for a backdrop, because then I can use a real BG layer for the framebuffer and recover 20 tiles per line that I can then use for normal hardware sprites.

* Or technically two BG layers with EXTBG, but they share a pixel fetch; the only difference is that BG2 is 7bpp plus a priority bit instead of 8bpp. Useless for framebuffer overlay.

You really seem to be using every feature of the SNES in your game

The original game was on a much more powerful platform, and I'm trying to get as close as I can. A lot of elements seem to be just barely possible without needing to make large changes, but I've had to get creative with the hardware.

On old computers they often use blank screen space (memory) to store variables! They turn the colors to all black and then just stick a load of extra variables in there.

That's hilarious. I guess memory was really tight on systems that old. IIRC the Atari 2600 had 128 bytes of RAM - but it couldn't really do the trick you describe, because it only had enough VRAM (if you want to call it that) for one scanline...

Maybe that rotating hall in Castelvania many people thought was somehow mode 7 back in the day too.

It is Mode 7. There's X scaling going on. And look at that detail level - doing that with a raster racer technique would have taken a huge amount of ROM and probably more DMA bandwidth than they had.

Also note that the status bar has a black background in the rotating room areas, unlike the rest of the game where the level graphics continue up behind it. This relates to the fact that Mode 7 only has one BG layer. The status bar is a BG layer, so it can't be displayed in front of a Mode 7 backdrop.

My fav use of Mode 7 - it might be in that video or one of them - was when the guy who did Wolfenstein on SNES used it to scale the screen up. I thought that was very clever.

Pretty sure "the guy" in question was John Carmack. SNES Wolfenstein 3D was the genesis of the BSP tree idea for Doom, since the S-CPU was apparently too slow for actual raycasting at an acceptable frame rate. They'd been having trouble with the engine for Doom getting bogged down with recursion in their VSD scheme, and the same idea that saved SNES Wolf3D went on to save PC Doom.

SNES Wolfenstein 3D was also written in less than a month, since the subcontractor flaked out and the deadline was approaching.

It does seem like Mode 7 would have a lot of potential for actual Raster effects though.

It's monstrous for raster effects. It's a full affine transformation that can be completely changed out every scanline.

Lots of people think "Mode 7" means flat perspective floors, but Mode 7 alone can't do that. That's HDMA plus Mode 7. And of course, this then implies that the floor doesn't need to be flat; several games, including (perhaps most notably) Super Empire Strikes Back, featured hill effects. An SA-1 cartridge could have made much better use of it, since doing 3D calculations is not a strength of the S-CPU; I've got an F-Zero game on my list partly for this reason.

Lots of demos use Mode 7 in fun ways. The demo I linked earlier as an example of changing OBSEL wrong (Magical by First Try) does so to support a fullscreen sprite backdrop so as to use Mode 7 for the text scroller and logos, which allows some fancy distortions to be performed at high speed.

[SNES AYE]

Maybe that rotating hall in Castelvania many people thought was somehow mode 7 back in the day too.

It is Mode 7. There's X scaling going on. And look at that detail level - doing that with a raster racer technique would have taken a huge amount of ROM and probably more DMA bandwidth than they had.

Also note that the status bar has a black background in the rotating room areas, unlike the rest of the game where the level graphics continue up behind it. This relates to the fact that Mode 7 only has one BG layer. The status bar is a BG layer, so it can't be displayed in front of a Mode 7 backdrop.

Out of curiosity, since the area of the background behind the status bar does not use any of the curve effect and, as far as I can tell, is basically just static behind that opaque black bar, would it have been possible to use Mode 1 there with a duplicate set of tiles from the Mode 7 background, or a slightly modified set to make it look like its own separate wall section, and then scroll it vertically or keep it static? You could even scroll that section horizontally a bit faster than the rest of the room to emphasize that it is part of the roof or wall that sits above and in front of the rotating room. After that, you would overlay the status bar using the usual BG3 layer and switch to Mode 7 on the scanline where the affine effects begin to curve the background.

A link so anyone can view the level quickly, in case they are not following what I mean: https://youtu.be/VwOM3KtHLWg?t=1568

The idea is that this could make it look like there is an additional roof section in front of the rotating room at the top of the screen, with the HUD overlaid on top of it just like in most of the other levels and scenes in the rest of the game, while still allowing for the same lovely Mode 7 rotating room below as usual. Hopefully that explanation makes sense.

Of course, the game doesn’t need any tweaks for something like this, as it’s a product of its time, and that rotating effect was absolutely mind-blowing back then and still looks amazing today. I was just thinking about how one might remove even the hint of any limitation from using Mode 7 in that area. It’s the kind of approach I can imagine someone taking today if they were trying to create a similar effect with a more modern eye for detail.