what a shame u_u

[kool kitty89]

Good lord at soem of the comments here. The 32X didn't have that much potential. I mean it's still a cart system that has to do everything in software rendering. It does a decent job at pushing flat shaded polygons around at a decent clip but both the Saturn and PSx looked a helluva lot better than the best 32x efforts.

Yes, which is pretty much what I implied with my post: there IS a lot more potential than was shown (even within common ROM limits of the time -ie 4-6 MB, perhaps 8 MB in 1996), but also with many limitations . . . and lost potential for a more cost effective alternative. (as I've said before, from the context of a machine designed and released in a little more than 6 months from inception, it's not bad at all, but a well-planned piece of hardware could have been a lot better for similar cost . . . then again, a well-planned design probably would have recognized the inherent impracticality of an add-on to the MD+CD and either dropped the design altogether, or designed a discrete, enhanced backwards compatible system in its place . . . or dropped compatibility altogether and gone another direction -with the Saturn taken into context, the "32x" probably should have been more like the Jupiter)

Still though, the 32x's current software doesn't really show most of its potential (not just graphics, but sound to a huge degree), and marketing/management has a lot more to do with such things than technical limitations. (tech cost/performance/programmability are all significant issues, but generally take a back seat to actual PR/funding/market/business/management descicions as far as software support quality/quantity, sales, etc, etc go -good hardware can help to counter negative areas, but it takes really bad hardware to totally ruin a company with good funding/marketing/management/PR -the PCFX is probably one of the closest examples to that except that NEC had already been making some major mistakes in their management end as well, both in Japan and obviously to a massive extent with their failure in managing their western markets -the Saturn obviously wasn't THAT bad at least, neither was the 32x, but Sega had many other problems that caused the real trouble -and exacerbated the issues that the 32x and Saturn did inherently exhibit)

Unless Sega was willing to up the ante on cart sizes the games weren't going to look like much. In order to really push the system Sega would've had to do something about that limited ram. In which Chilly has already stated that us a huge bottleneck.

Chilly Willy's biggest point about RAM was that it made games hard to source ports to the system (porting FROM the system to another wouldn't be nearly as big a problem -or ports from the SNES or MD given the more limited memory), that's a much bigger problem than for raw performance with the 32x by itself. (RAM is an issue there too -as are the bottlenecks for using the Sega CD, especially due to the limited MD CPU being the only bridge between them, but that's a different context than the pure difficulty of sourcing ports of PC games)

32X's best efforts? We saw none of that in the retail lineup. The closest we are ever gonna get (until homebrew gains momentum) to seeing what the 32X could really do is Darxide and Metal Head. Texture mapped polygons. I think we all already know the 32X could have been used efficiently enough to push some more complicated design than what Metal Head and Darxide showed. Besides, there's something you're forgetting Da_Shocker. Because everything inside the 32X is software-based or rendered, the device has incredible flexibility. You can use it in all sorts of different ways. Some better suited to certain types of game than others. Chilly likes to use the Slave Hitachi to drive the PWM sound chip, for instance. Or (I'm not sure if this is possible), perhaps you could use the Genesis 68k or z80 to operate the PWM. Maybe leave the 68k with game logic so the Master SH CPU can handle graphics and any other things like decompressing data. (again, not too familiar with what all the 32X can do. Feel free to correct me on my hypothetical examples Chilly or whoever else knows the 32X)

There's lots of flexibility, very much like PCs were prior to acceleration, though also some significant bottlenecks (and inherent limitations of raw CPU resource . . . the flexibility really isn't worth it for such extreme cases and the 32x really would have made more sense with 1 SH2 and more coprocessing hardware -be it DSP and/or blitter or other things . . . having a tweaked version of the Saturn's VDP1 and slightly cut-back Super VDP -like dropping the RLE mode- would have been nice and catered more to cross-platform 32x/Saturn games as well).

In any case still more potential than it demonstrated at the time. (the lack of PWM DMA documentation hindered high quality sampled sound considerably -and likewise hindered potential for efficient SH2 use, be it dedicating the slave for a 32 channel sample music/sound engine or something like a simpler 4-8 channel player with a lot more coprocessing for graphics handled by the slave -like 3D math or ray-casting computation)

There's the limits of ROM speed of the time, efficiently allocating resource of both CPUs, software rendering limits in general, pracitcal limits of ROM sizes, limits of on the fly decompression, limited RAM to decompress into ahead of time, etc.

The bigger limit of RAM would perhaps be difficulty of porting PC or newer console games that demand far more RAM. (similar games or remakes using custom engines could be possible, but direct ports for many games would be impractical or impossible -Doom barely managed to be hacked down to 32x compatible levels similar for GBA, but the SNES version required a custom engine in part because of RAM and in part because of very tight resource limitations -the SNES version of wolf3D may have been a custom engine too, but I'm not sure)

To be honest though, what I'd love to see, along with more elaborate polygonal 3D games, is more 2D games. Still very disappointing to see that Chilly is probably the only homebrewer making stuff for the 32X. How is Wolf32X coming along anyway?

More 2D in the short run would have been nice (ie before the market really declined for that ~1996), and Ray Man is one of those holy grail canceled games for the 32x. (and one that Chilly Willy mentioned being personally disappointed with)

Actually, with my recent observation of Mortal Kombat II's use of 32x graphics (and several other games that used 32x for sprites but not much BG), using the 32x for the main BG with MD graphics for foreground and sprites probably should have been more common (especially for games with a huge chunk of solid BG -definitely the case in MK), or games doing sprites and main foreground (with the foreground taking a major chunk of the BG) and leave MD for the far BG only (which is what Kolibri does).

Using the 32x just for sprites may have been simpler, but generally barely made a noticeable difference for the color (MK II's MD sprites look almost the same as MKII 32x -Primal Rage isn't much better either) and thus ends up quite wasteful.
Plus, if ROM space is the main issue, the 32x portion of the BG graphics could be mainly compressed and indexed (namely using 16 color indexed textures with compression on top of that) and unpack them to 32x work RAM (maybe cram a little into unused framebuffer space too) maybe with a limited amount of uncompressed animation used on the fly, or using simple/fast compression schemes like RLE. (in better cases, you could actually save a significant amount of ROM space over an equivalently detailed/animated MD version due to the increased amount of RAM available to decompress into -32x RAM on top of MD RAM)

For fighting type games, you'd probably end up decompressing as much as you can and resorting to uncompressed (or simply compressed) streamed graphics if necessary (doing 4-bit to 8-bit look-up or advanced lossless decompression would probably be impractical for on the fly loaded stuff -unless maybe if the slave SH2 had a lot of resource left that could be dedicated to such tasks)

However, for sidescrollers (especially rather linear ones) or similar games, more extensive periodic updates using more heavily compressed/packed memory might be realistic (though you might end up with some slowdown if large chunks were updated at once -more gradual updates could possibly be buffered with minimal hit to game performance), this would be rather comparable to CD based games doing on the fly updates (though with fewer headaches in some respects -lack of low CD bitrates but with more overhead for data decoding). For that matter, some existing MD games may do some rather heavy decompression on the fly. (not sure if any actually do that though)

[Flygon]

However, for sidescrollers (especially rather linear ones) or similar games, more extensive periodic updates using more heavily compressed/packed memory might be realistic (though you might end up with some slowdown if large chunks were updated at once -more gradual updates could possibly be buffered with minimal hit to game performance), this would be rather comparable to CD based games doing on the fly updates (though with fewer headaches in some respects -lack of low CD bitrates but with more overhead for data decoding). For that matter, some existing MD games may do some rather heavy decompression on the fly. (not sure if any actually do that though)

I'm nearly completely certain that Sonic 3 and Knuckles abused this sort of thing to a large degree, which really shows when you view the TAS's. The poor game can't get enough CPU time to replace VRAM tiles before the new ones must be displayed!

[Chilly Willy]

How is Wolf32X coming along anyway?

I'm looking into how to allow the full games to be used as opposed to just the demo, as well as working in the new sound code for music and sfx.

Demo is easy as it's small enough that I just decompress the data and use it straight from the rom. There's not really enough ram to decompress into the ram, which is where the full game has problems - decompressed, the full game is larger than the rom can be, but if I leave it compressed, there's not enough ram to decompress into when the data is needed. If you limit the data you keep decompressed at any one time, you wind up doing lots of decompression over and over again. This is where the ram limits hit worst on the 32X.

[Da_Shocker]

I'm looking into how to allow the full games to be used as opposed to just the demo, as well as working in the new sound code for music and sfx.

Demo is easy as it's small enough that I just decompress the data and use it straight from the rom. There's not really enough ram to decompress into the ram, which is where the full game has problems - decompressed, the full game is larger than the rom can be, but if I leave it compressed, there's not enough ram to decompress into when the data is needed. If you limit the data you keep decompressed at any one time, you wind up doing lots of decompression over and over again. This is where the ram limits hit worst on the 32X.

What about an 8MB rom?

[Chilly Willy]

What about an 8MB rom?

There's nothing that supports that on real hardware unless I make it NeoMyth specific. I could go with 5MB SSF2 format... I need to verify how much space it takes exactly. Both the NeoMyth and the Everdrive support SSF2 mapping. Unfortunately, they don't support more than just the 5MB that SSF2 takes.

The NeoMyth allows me to run in "native" mode, which would allow me to use all 8 MB of ram, but then it would ONLY work on the NeoMyth on real hardware. None of the emulators emulate the NeoMyth (yet). I'm not even sure if the emulators support SSF2 mapping for a 32X game... they SHOULD, but I haven't checked - I should make a test app that I can run in emulators (and flash carts) to test the SSF2 support to see what pages they allow mapping on, and how much mapping they allow, and if it's allowed in 32X mode.

[Barone]

Chilly, Do you have any documentation about the SSF2 mapper? 'Cause I would like to know how to proper split the address segments...

[Da_Shocker]

There's nothing that supports that on real hardware unless I make it NeoMyth specific. I could go with 5MB SSF2 format... I need to verify how much space it takes exactly. Both the NeoMyth and the Everdrive support SSF2 mapping. Unfortunately, they don't support more than just the 5MB that SSF2 takes.

The NeoMyth allows me to run in "native" mode, which would allow me to use all 8 MB of ram, but then it would ONLY work on the NeoMyth on real hardware. None of the emulators emulate the NeoMyth (yet). I'm not even sure if the emulators support SSF2 mapping for a 32X game... they SHOULD, but I haven't checked - I should make a test app that I can run in emulators (and flash carts) to test the SSF2 support to see what pages they allow mapping on, and how much mapping they allow, and if it's allowed in 32X mode.

How bout the one for the Jaguar?

[KnightWarrior]

Could the 32x pull of Sega Rally, Power Drift or even Daytona??

[Tor Landeel]

^ Forget it, maybe a Virtua Racing looking version of daytona...I don't really think a Sega Rally would look fine..

[Da_Shocker]

Could the 32x pull of Sega Rally, Power Drift or even Daytona??

Technically yes but would they would they be any good? Absolutely not, but Power Drift would make a great 32X game.

[Chilly Willy]

Chilly, Do you have any documentation about the SSF2 mapper? 'Cause I would like to know how to proper split the address segments...

It's not really the SSF2 mapper, it's the SEGA mapper, but only SSF2 ever used it, so people CALLED it the SSF2 mapper.

The cart space (0x000000 - 0x3FFFFF) is split into 8 pages of 512 KBytes each.
The rom can be up to 64 segments of 512 KBytes each (32 MBytes).
The first page (page 0) is ALWAYS mapped to the first segment of the rom.
Pages 1 to 7 can be mapped to any rom segment - store the segment number in the proper mapper register.

Registers:
0xA130F1 = Save RAM control, b0 = 1 = sram enabled, b1 = 2 = sram write-protected
0xA130F3 = Page 1 segment (0 to 63)
0xA130F5 = Page 2 segment (0 to 63)
0xA130F7 = Page 3 segment (0 to 63)
0xA130F9 = Page 4 segment (0 to 63)
0xA130FB = Page 5 segment (0 to 63)
0xA130FD = Page 6 segment (0 to 63)
0xA130FF = Page 7 segment (0 to 63)

When the Save RAM is enabled, it appears at 0x200000 in place of rom.

How bout the one for the Jaguar?

I don't have a Jaguar and am not set up to do anything for the Jaguar.

[Guntz]

Wouldn't it be possible for one to engineer a more complex memory mapper? If the chinese Famicom pirates can do it, certainly a Genesis fan could do it too.

[Chilly Willy]

Wouldn't it be possible for one to engineer a more complex memory mapper? If the chinese Famicom pirates can do it, certainly a Genesis fan could do it too.

Why would you want a more complex mapper? You could, but I don't see the need. Simple is nearly always better, especially for hardware.

[Guntz]

I dunno... Maybe so the Genesis / 32X can access more cartridge data? More memory is always better (though more RAM beats it out).

[kool kitty89]

I dunno... Maybe so the Genesis / 32X can access more cartridge data? More memory is always better (though more RAM beats it out).

The "SFII mapper" scheme (which was Sega's standard mapper implementation, though only used for that 1 game) supports up to 32 MB of memory space, but only 5 MB was used, and only 5 MB is supported in the Neo Myth (not sure if emulators support more than 5).

The MD alone flat addresses 10 MB to cart ROM space, but 6 MB of that is "reserved" (mainly for the expansion address range of the expansion port -used by CD- and cart expansion -used by 32x). If the 32x is used, only 8 MB of that space is usable for carts, or just 4 MB if 32x and CD are used.
No flash carts support using the reserved range either AFIK.



As for more complex mappers, those were mainly for very specific optimized circumstances (mainly for catering to tile/sprite graphics data -the mapper used for the PCE Arcade card also does that iirc), but that sort of thing isn't important for general purpose memory expansion. (and apparently wasn't really felt to be necessary for SSFII either. (though the scheme it uses does add a great deal of flexibility due to 7 independent 512k pages being mapped at a time -as per Chilly's description, so not just plain single page bank selecting)

It's not really the SSF2 mapper, it's the SEGA mapper, but only SSF2 ever used it, so people CALLED it the SSF2 mapper.

The cart space (0x000000 - 0x3FFFFF) is split into 8 pages of 512 KBytes each.
The rom can be up to 64 segments of 512 KBytes each (32 MBytes).
The first page (page 0) is ALWAYS mapped to the first segment of the rom.
Pages 1 to 7 can be mapped to any rom segment - store the segment number in the proper mapper register.

Registers:
0xA130F1 = Save RAM control, b0 = 1 = sram enabled, b1 = 2 = sram write-protected
0xA130F3 = Page 1 segment (0 to 63)
0xA130F5 = Page 2 segment (0 to 63)
0xA130F7 = Page 3 segment (0 to 63)
0xA130F9 = Page 4 segment (0 to 63)
0xA130FB = Page 5 segment (0 to 63)
0xA130FD = Page 6 segment (0 to 63)
0xA130FF = Page 7 segment (0 to 63)

Nice, so 7 independently programmable pages in addition to the fixed one . . . too bad the Z80 didn't get anything remotely close to that.

Actually, they COULD have worked around the internal Z80 banking mechanism by using on-cart mappers with parallel bank select and the ability to map multiple segments to the 32k chunk addressed by the Z80. (having up to 4 segmented pages available at a time would be really nice for multi-channel PCM . . . more than 4 would probably not be very useful, and fewer might often be used depending on the circumstances) A mapper that just did parallel banked 32k pages would be pretty useful too though.
That sort of mapper might have actually been the cheapest/most cost-effective sound enhancement Sega could have added on-cart for the MD.

I think Tiido mentioned something about a project he was working on for implementing such a banking scheme in the MD.