IIgs and Super Nintendo

[olePigeon]

I was reading the Wikipedia on the IIgs, and apparently they were used for developing Super Nintendo games (the SNES used a slightly modified version of the CPU used in a IIgs.)

Anyone think a WINE/SheepShaver style program could bring SNES games to a IIgs?

Just thinking out loud, I guess. Would be cool.

 

[Dog Cow]

I've thought about it, and it seems unlikely, but possible. A stock IIgs likely wouldn't suffice. The SNES had extra supporting hardware which wouldn't be present on the IIgs. However, with a Transwarp, it might be possible.

 

[highlandcattle]

This actually happens a lot. Games for the Atari Lynx were made on an Amiga. The Atari Jaguar developkit was intitially only for the Atari Falcon. Xbox360 early developkit were two standard Powermac G5 quad core. I didn't know about the SNES and the IIGS.

 

[protocol7]

Silhouette was apparently an internal emulator used by Nintendo during SNES development. It leaked out years ago along with this backstory.

 

[Gorgonops]

The IIgs is basically nothing like a Super Nintendo other than sharing the CPU. Developers used the IIgs to get familiar with the CPU and work on game logic before the Super Nintendo development platforms became widely available but *by no means* are the systems even remotely enough alike to allow a fully-developed game using the SNES's custom video and sound CPUs to work.

(It's a bit like asking if a software emulator could get a Neo Geo arcade game cartridge running on a Macintosh Plus because, after all, they both use Motorola 68000s. The fact that the Macintosh Plus only runs at 2/3rds the clock speed of the Neo Geo is the very least of your problems. Overclocking the Mac isn't going to help the problem much since you're still comparing a single-CPU system with simple framebuffer video to a highly engineered console with *two* general-purpose CPUs, an immensely powerful sprite-based video accelerator, and a 15 channel sound chip. The gulf between the IIgs and the Super Nintendo's hardware is similarly vast.)

 

[olePigeon]

Awe shucks. Woulda been fun.

 

[notcrazy_iminsane]

What about a IIgs and NES? Or maybe bring it down more to an Atari 5200 or 2600?

 

[ClassicHasClass]

The 2600 is a bad example: despite its deceptively slow CPU speed, nothing less than a cycle-correct emulation will do because the CPU essentially draws the screen (using TIA). This needs beaucoup CPU power and a IIgs won't cut it.

 

[Gorgonops]

The 5200 is no slouch either. The 5200 is basically a slightly-tweaked Atari 800, and those machines had a separate almost-CPU called "ANTIC" that interprets data for the screen fetched via DMA based on a programmatic "display list". This independent unit then shoves the data into the "C/GTIA" chip which is an enhanced cousin of the TIA chip used in the Atari 2600, and itself has some rudimentary intelligence. (IE, it renders "Player/Missile" screen components, Atari's version of sprites.) Essentially the ANTIC works to offload some of what the main CPU had to do in the 2600 and allows the C/GTIA" to work with "real framebuffers" instead of the single-line buffer the *extraordinarily* RAM-constrained 2600 used.

(And the NES, likewise, has an independent "PPU" that includes its own onboard RAM and DMA engine and offloads a lot of work from the main CPU.)

There was a "semi-functional" Atari 800 emulator for the Atari ST (which is a substantially faster machine than the IIgs) but when running graphics modes it ran at less than 1/10th the speed of the real thing. (By comparison, an Apple II emulator by the same author for the ST could run at 40-50% of full speed, which indicates just how much overhead gets sucked up emulating elaborate graphics hardware.) You might argue that since a IIgs wouldn't have to emulate the main CPU it would have more left over for emulating the hardware, but... I'm skeptical one could easily write an emulator that could run an original unmodified binary "natively". You'd have to have some mechanism to "trap" attempts by the emulated binary to access hardware devices and interrupt program execution to run the hardware emulation code. On a simple machine without an MMU I just don't see it happening.

(The closest example I can think of is Shapeshifter/BasiliskII for the Amiga, which manages to run a MacOS emulation without true "virtualization", but it cheats *a lot* and falls down hard if presented with any non-well-behaved program that tries to tickle hardware without going through the MacOS ROM. Tickling hardware is *all* that 8-bit game programs do so it's really an apple-to-oranges comparison.)

Of course, the IIgs is easily fast enough to run a decent port of most 8 bit computer/early console games. Rewrite the graphics and sound routines to use the native hardware and you're good. (The IIgs has weaker video capabilities than most 8 bit game platforms as it lacks sprites, but its CPU is enough more powerful to compensate in most cases.)

 

[ClassicHasClass]

I've "virtualized" a 6502 on 6502, essentially by writing a software 6502 that distilled instructions that accessed memory into immediate instructions, while directly running the rest. The KIM-1 emulator I wrote for the Commodore 64 uses this idea. It runs at approximately 1/50th the speed of a real KIM-1, which has a CPU speed only slightly slower than the C64's own speed.

For a KIM-1 this is totally acceptable and surprisingly useable, but it would suck for any of the other systems, and even a TransWarp GS would have trouble keeping up.