multi-screen output from a SNES game ...

Brainstorming here.

Let's say you took a typical SNES rpg. By plumbing the ROM you should be able to export/output the "map" fairly easily as a static image.

Now let's say that you dumped the ROM of this particular game and added logic to it to maintain a (shrunken) full size picture of that map at all times, and further, added logic to "poll" the in-game location of the character at all times.

At this point, at least programatically, and internal to the game itself, you would have everything you need to display a real-time map in addition to the actual video output of the game. Now here is where it gets tricky ...

The SNES has the normal video out. It also has the cartridge "out". There is also an expansion out on the bottom. So, again, brainstorming, how could we output the "map" to a secondary display, while the game runs on the primary display ?

Listed in order of easiest to hardest:

- attach a serial cable to the expansion out OR the cartridge out and output the "map" as ascii to a dumb terminal. This would look terrible and be very bizarre, but in terms of physical gimmickry, probably the easiest. It would basically be like seeing a nethack/rogue representation of the game alongside the actual game. Bandwidth is minimal since the ROM is instructed just to send bits of text when necessary.

- alternatively, many copiers already have either a serial or parallel interface ... it would require altering the copier firmware, but the same (odd, ugly) ascii mapping could be done with output over the already existing port on the copier...

- video out, perhaps limited to 8bit color, from the expansion port ? I doubt the expansion port has the bandwidth for standard SNES video output, but perhaps with a lower color palette and/or resolution, you could get an rgb output from the expansion port ?

- you could do something really weird like altering the ROM to split alternate
halves of the 240p signal into each different image and then split the output from the AV cable to two different displays.

The underlying idea here is that it would be a very interesting trick to see multi-display output from a super nintendo game, and a real time map to accompany an RPG is the first thought I had. Alternatively you could just output ascii text to a dumb terminal to display health/inventory/stats/etc.., or perhaps even more interesting, a scrollback of recent NPC chatter.

But the map would actually be "useful" ... that is, in the context of something as trivial as this idea is

Comments ?

 

I would rather suggest a Link or Networking approach.

Patch / Reprogramm the Game to allow Linking via the exp. Port on the SNES and then use a second SNES to render the map-Data or second screen.

 

I had not thought of that. I suppose that the expansion port does not have sufficient bandwidth for any kind of video, and even if it did, the internal bandwidth of the system is probably not up to driving two screens, even if one is only 8bit.

Looks like max internal bus speed is 2.68 megaBYTES/second ...

And 8 bit color would be ... check my math here ...

256*224*8*15 = 6881280 bits per second (H x W x colors x 15hz)

So, if the expansion slot has greater than or equal to 860 kiloBYTES/sec (6881280 / 8) (to get bytes) it should be able to drive standard SNES video @ 8 bit color depth.

Then you would need to ensure that the game does not eat more than 1.8 MB/s of system bus at any given time, yes ?

Perhaps my math is off ... or perhaps my figuring of the bus requirements and their competition with one another is off ?

Does that math seem right ?

 

No, you do not send the screen-data trough the Exp-Slot, as the second SNES has also a game cartridge with needed data inserted, you just send controlling data trough it. So no bandwidth problem in this regard.

 

A SNES network. W000t.

 

Yes, I understand - the conjecture + math in the previous post was still related to doing it all on a single SNES.

Since it's not really a "reasonable" project to begin with, and mostly a thought experiment, I'm still toying with the idea of doing it on one, hence the math about the expansion port video output ...

 

Dude, get a DS!

But more seriously (if you can call it that), are you thinking of driving a monitor directly from the SNES data drive? Even if you could output enough data, where would you begin to get the cpu time to formulate the data?

I think the two nes systems is the only way this could even begin to happen. Then you practically only need to transfer a location and the cart on the other end can plop a little guy on that location on a map.

 

Whats the ultimate expansion/add-on for the SNES???? another SNES!!!!!!:lol::lol::lol:

 

You "could" do it with one SNES and a little bit of analogue/digital hardware... put the SNES in interlace mode, with even fields displaying one image, and odd fields displaying another... and wire up some counters, etc that reroute the video output to one TV on even fields, and another on odd...

It would of course create flickery images on both TVs, but it would be a way to display separate images, as you wanted.

 

Yes, that is the thought experiment - can you drive a display @ 8bit color depth (or even 4, actually) from the expansion port ?

As to the question of CPU - certainly that is a problem if you are doing any kind of _gaming_ on the second display. But if all you are doing is showing a static image ... and merely moving a blip around it ... its a very inexpensive operation, computationally...

I need to check that math though ...

 

1) You can't split half a video image to separate TVs, that is crazy talk.

2) You can't generate video in software to be output to a DAC on a SNES, SNES video is something like 341 pixels x 261 lines x 60 Hz including blanking which is 5.34 Mb at 8bpp not including sync and the HUGE overhead of calculating the screen and the timing which is impossible. You would need to design a hardware framebuffer or tilemap circuit and decode to your own port-space probably on the cart slot, big project if you aren't a digital wizard!

3) Adding a hardware UART to a cart wouldn't be too hard.. but who wants a terminal for a second screen?

 

yeah, give 'em hell Calpis:rambo:

 

Something I just thought of is that really fast microcontrollers can generate composite video even if the SNES can't... you could make a display generator from one of those and synchronize it to the SNES's video to update both screens somewhat cleanly. Since no matter what you'll have to build something, even if just level translating stuff for a software UART.. This is probably the simplest option and the cheapest apart from the terminal idea...

Think this: http://www.acm.uiuc.edu/sigarch/projects/breakout/

 

Why can't you just use what is already in the SNES for this game? The SNES can handle RPGs with maps.

 

Its more the issue of the cpu usage involved in driving a second monitor, even if its just a static map with a blip or 2 on it.

 

Use a second SNES and communicate between the two.
On the first unit, transmit static map image once when needed to the second unit (shouldn't be too hard) and simply poll for location data and add that in... the map location data would be minuscule and easily handled by the expansion port bus.

'Course, I say this with zero programming knowledge.

 

or simply have two SNES running the same application but have them synced, you can probably do this through the controller port.

 

You misunderstood me. Why do you need a second display? Why can't you just make a regular SNES game? Plenty of SNES games were RPGs and you could view a map to see where you are in the world. You don't have to develop some elaborate 2 system thing to drive a second map screen.

 

No reason at all. I just thought a multi-head SNES would be interesting.

I have no intention of pursuing any of this - just an interesting technical "what if"

 

LOLWUT