Super Nintendo Entertainment System

Este artículo está en construcción.

Por esta razón, seguramente habrá lagunas en el contenido o en el formato. Por favor, antes de cambiar el contenido, consulta la página de discusión del artículo.

Super Nintendo Entertainment System

	CPU: Procesador Ricoh 5A22 W65C816 a 3.58Mhz. Soporte: Cartuchos. Almacenamiento: Memoria SRAM interna en los cartuchos. Online: No
Fabricante: Nintendo Lanzamiento: 21/11/1990 13/08/1991 11/04/1992 1/06/1992	Número de consolas vendidas (aprox.): 50 millones. Número de juegos (aprox.): Más de 1800.

Consola de videojuegos de 16 bits lanzada en Japón en 1990 de nombre Super Famicom por la compañía Nintendo. Sucesora de la Nintendo Entertainment System, o simplemente NES. En Estados Unidos y Europa fue bautizada como Super Nintendo Entertainment System y conocida como Super Nintendo, SuperNES o SNES.

Mantuvo una dura competencia con la Mega Drive/Genesis de Sega.

Historia

Años	1990-1996
Salida Japón	21 de Noviembre de 1990
Salida EEUU	1 de Agosto de 1991
Salida Europa	11 de Abril de 1992
Salida Australia	3 de Julio de 1992

Durante la anterior generación de consolas, Nintendo había sido la líder en ventas con su NES (Famicom en Japón)^{[Sin referencias]}. Otras compañías de videojuegos intentaron combatir este hecho lanzando antes que Nintendo sus consolas de 16 bits. La más destacada de éstas fue la Mega Drive, lanzada por SEGA en 1988.

Casi dos años más tardaría Nintendo en poner en el mercado japonés su apuesta en la generación de los 16 bits, la Super Famicom, bautizada como SNES en el resto del mundo. En aquellos momentos la consola de SEGA gozaba ya de bastante popularidad, sobre todo en Estados Unidos, y de una cuota de mercado considerable. Es por ésto que Nintendo desarrolló una gran campaña publicitaria paralela a la salida de su nueva consola para convencer al público de que todavía no había adquirido una 16 bits de verdad^{[Sin referencias]} y que la mejor apuesta era la suya. La publicidad española la presentaba como "El cerebro de la bestia".

Toda esta campaña y la superioridad técnica en algunos aspectos^{[Sin referencias]} de Super Nintendo consiguieron ponerla a la par de la Mega Drive en poco tiempo originando lo que puede que fuese una de las rivalidades más duras entre dos consolas vista en esta industria.

Características

La arquitectura de la SNES era novedosa comparada con la de sus competidoras de la época debido a que su CPU no era demasiado potente, relativamente hablando, pero era apoyada por otros procesadores dedicados específicamente a las tareas de video y sonido. Esta novedad en la consola provocó que los primeros juegos no desarrolados por Nintendo fueran de un nivel más bajo de lo que podía dar de sí la consola.

• Procesador principal
  • Ricoh 5A22, basado en un nucleo CMD/GTE 65C816 de 16 bits.
  • Frecuencia de reloj: variable, 1.79Mhz, 2.68 MHz, o 3.58 MHz.

• Video
  • PPU: dos chips (PPU1 y PPU2) de 16 bits.
  • Memoria de video: 128 KB.
  • Resoluciones: 256x224 a 512x448.
  • Efectos: rotación, escalado y perspectiva en un fondo (Mode 7)

• Sonido
  • Procesador SPC700 de 8 bits corriendo a 4.1 MHz desarrollado por Sony controlando un DSP.
  • Calidad del sonido: 16 bits, 32kHz, capacidad de panning para realizar efecto estéreo.
  • Memoria: 64KB.

• Soporte
  • Cartuchos desde 2 a 64 Mbits (256 KB a 8 MB).
  • Los cartuchos podian poseer SRAM alimentada por batería para salvar los progresos en el juego.
  • Podian incluir coprocesadores para mejorar las prestaciones de la consola en determinadas tareas en un determinado juego. Entre ellos, destacan el Super FX, el CX4 o la serie DSP.

Accesorios

• Mando de control.

• Super Nintendo Scope.

• Super Game Boy: Cartucho para SNES con una ranura para introducir juegos de Game Boy y jugarlos en una pantalla de TV.

• Nintendo Play Station. Proyecto de lector de CD para la Super Nintendo desarrollado entre Sony y Nintendo. Nunca llegó a salir a la venta. Cuando Nintendo abandonó el proyecto debido a diferencias de opiniones, Sony lo utilizó para hacer lo que en el futuro sería su primera consola, la PlayStation.

• Capcom Fighter Power Stick.

• Super Multitap. Expande el número de puertos a los que conectar mandos de SNES. Enlazándolos se puede llegar a jugar hasta con 16 jugadores de forma simultánea en los juegos que lo permiten

• Ratón Super Nintendo. Con el Ratón de Super Nintendo, que se puso a la venta con el cartucho Mario Paint, los aficionados al dibujo pueden crear en pantalla y fácilmente obras maestras inspiradas en Mario. El Ratón cuenta con dos botones y se conecta directamente al puerto de mando 1.

• Super Nintendo Score Master. Cuando necesitas ese toque de control extra para tus juegos Super Nintendo, Nintendo Score Master es la respuesta. Este accesorio se conecta directamente al puerto de mando de Super Nintendo y está formado por una base firme, sobre la que se levanta un enorme joystick más seis botones de control más grandes y mejor colocados para un acceso inmediato. Las funciones de fuego automático, turbo y cámara lenta, son el accesorio ideal para quienes baten todos los récords.

Modelos de Super Nintendo

• Super Nintendo (EU). Modelo Europeo. PAL.

• Super Nintendo (USA). Modelo Americano. NTSC.

• Super Nintendo Mini (USA). Revisión del modelo americano que disminuye las dimensiones y mejora el diseño. NTSC.

• Super Famicom (JAP). Modelo Japonés. NTSC.

• Super Famicon Jr (JAP). Revisión del modelo japonés que disminuye las dimensiones y mejora el diseño. NTSC.

Juegos

Entre los juegos más destacados de Super Nintendo estuvieron:

• 

  Super Metroid

• 

  Super_Ghouls_and_Ghosts

• 

  Super Probotector

• 

  Front Mission

• 

  The Legend of Zelda: A Link to the Past

• 

  Axelay

• 

  Biker Mice From Mars

• 

  Super Castlevania 4

• 

  Clocktower

• 

  Final Fantasy VI

• 

  Killer Instinct

• 

  Megaman X

• 

  On the ball

• 

  Pilotwings

• 

  Secret of Evermore

• 

  Super Probotector

• 

  Terranigma

• 

  Super Street Fighter II

• 

  Street Fighter Alpha 2

Saves de SNES

Sección del wiki donde encontrarás partidas guardadas de SNES.

Información de la consola

Chip Fx

Super FX

“La Super Nintendo solo es la caja que alimenta al super FX”. Argonaut, 1993.

Índice:

       -Historia de su desarrollo.
       -Super FX overclockeada.
       -Entrevista a Dylan Cuthbert, presidente de Q Games, y programador principal del Star Fox/Wing.
       -Arquitectura/Caracteristicas técnicas.
       -Juegos.
       -Juegos cancelados.

Historia de su desarrollo:

Un buen dia Argonaut le mostró a Nintendo una demo programada con un motor gráfico propietario de Argonaut, este corría una demo de StarGlider sobre un hardware prototipo de super nintendo, el resultado fué sorprendente, a base de renderizaciones 3D, y consiguiendo que nintendo se interesara por el trabajo, quizás software para su maquina, quizás no... Argonaut le dijo a Nintendo que desarrollando un chip especifico para tareas 3D podrían hacer eso, pero 10 veces mas rápido y complejo, a Nintendo le encantó tanto la idea que encargo de inmediato un chip especializado. Pero vamos muy deprisa, por aquel entonces, nintendo justo estaba terminando de montar el hardware, o mas bien, planificando su distribución mundial, así que la idea inicial de incluirlo junto con los chips gráficos PPU-1 y PPU-2 quedó rápidamente descartada (Megadrive ya estaba en la calle, y nintendo ya había sufrido bastantes retrasos, no podían tardar mas en lanzar su maquina). Ya anteriormente nintendo tuvo que descartar la inclusión de un motorola 68000, similar, aunque mas rápida que la de su competencia de sega, precisamente por el mismo motivo, se les echaba el tiempo encima. Con el 68000 descartado, e incluida una versión 16 bits del chip de su ya recauchutada NES, el hecho de que el FX se quedara fuera del hardware supuso un varapalo que hubo que encajar como fuera.

Ese fue el inicio del chip super FX de la SNES y apartir de ahí sucedieron muchas cosas, algunas buenas, y otras menos buenas. Se decidió no dar el proyecto por perdido, y acabó desembarcando en un prototipo para los propios cartuchos de la super nintendo. Su viabilidad estaba ya mas que demostrada en el sector (anteriormente, el Elite de NES incluyó un procesador matematico dentro del cartucho, para la gestión de gráficos 3D simples). La desventaja se convirtió en una ventaja: en vez de desarrollar el hardware(SNES con FX incluído), y a partir de ahí diseñar el software, se optó por hacer lo contrario. Primero se desarrolló el tipo de software que correría sobre el chip FX, y a partir de ahí, se diseñó el hardware que se montaría en los propios cartuchos. Algo nada usual en la industria... y como digo, se convirtió en una ventaja, ya que gracias a este detalle, el software que usara este chip, resultaría hasta 40 veces mas rápido desde el cartucho(con este sistema), que si hubiera sido montado en el hardware de la SNES (según el desarrollo habitual de la industria). Es decir, la clave de la mejora de rendimiento no estaba tanto en el cartucho, como si lo estaba en el hecho de haber sido rediseñada su "filosofía". Si bien 40 veces mas rápido es una estimación que debió proceder del mas exhacerbado optimismo, es de suponer que se refieran a los datos del FX2, ya que, de hecho, el FX1 es un FX2 que decidieron capar, y no una versión anterior. Por lo visto, también la filosofía como chip de apoyo tiene mucho que ver en esta estimación, en el cartucho es una sustitución de CPU, y en el hardware de la SNES solo hubiera sido un PPU-3, corriendo a las ordenes del 65816, que recordemos, apunto estubo de ser todo un 68000. Nintendo se durmió en los laureles con la NES...

El chip fué bautizado al principio como M.A.R.IO (Mathematical Argonaut Rotation & I/O). En total hubo 4 modelos de este chip, bueno pues el primero fue desechado, ya que el segundo resulto poder redireccionar mas memoria y mas rápido, y los otros dos solamente se llamaban FX2, pero el resultado fue el primer chip para aceleración grafica, y era literal, porque la SNES no hacia nada mas que alimentar al cartucho y Mostar la imagen en pantalla, todos los cálculos se hacían internamente en el cartucho. El chip era un microprocesador RISC (del inglés Reduced Instruction Set Computer), con una frecuencia de 21MHz, y era capáz de renderizar algunos cientos de polígonos. La primera versión comercial fue la GSU-2, aunque un limitado numero de cartuchos de Starfox llevaban el chip MARIO. Este procesador RISC hecho de forma personalizada fue típicamente programado para actuar como un chip acelerador de gráficos que dibujaría polígonos a un framebuffer en la memoria RAM, también situada en el cartucho. Para los juegos, los datos de este framebuffer se transfieren periódicamente a la memoria de vídeo principal dentro de la consola, usando DMA, y de ahí, directamente a la televisión.

La primera versión del chip, comúnmente llamada el Super FX (sin número), es sincronizada con una señal de 21 MHz, pero un divisor de la velocidad de reloj interno lo dividía a la mitad (a 10,5 MHz). Más tarde, el diseño fue revisado para convertirse en el Super FX GSU-2; esta, a diferencia de la primera revisión del chip Super FX , pudo llegar a 21 MHz.

Además de renderizar polígonos, el chip también se utilizó para ayudar a la SNES en la renderización de efectos 2D avanzados. Super Mario World 2: Yoshi's Island lo usó para efectos gráficos avanzados como escalado y morphing de sprites y layers, y múltiples capas de parallax en primer plano y de fondo para dar una mayor ilusión de profundidad, entre otras cosas, le otorgaban una gran versatilidad, punto clave de que nintendo diera luz verde al proyecto.

Todas las versiones del chip Super FX son funcionalmente compatibles en términos de su conjunto de instrucciones. Las diferencias surgen en la forma en que han sido encapsulados, sus pins de salida, y su velocidad de reloj interna. Como resultado de cambiar el paquete cuando se creó el GSU-2, más pins externos estaban disponibles y asignados para direccionamiento, con lo que una mayor cantidad de memoria ROM o RAM externa podía ser accedida.

Los cartuchos de juegos que contienen un chip Super FX usaban una serie de patillas que los cartuchos normales no usaban, impidiendo así el uso con dispositivos del tipo Game Genie, o pro action replay, que aprovechaban esos pines libres para sus "dudosos" fines.

¿Murió el Super FX con la extinción de la SuperNES?.

Bien, no, no murió. Estrictamente hablando falleció y lo revivieron con otro nombre y para otro proyecto. El ARC (Argonaut RISC Core) fue lo que surgió de ese proyecto.

En 1998, el departamento que llevaba estos temas, el Argonaut Technology Limited, se separó y se consolidó como una empresa independiente, la ARC.

Actualmente, la ARC sigue viva, ha comprado varias compañías más y hace microprocesadores, sistemas multimedia y un porrón de cosas. Vamos, que la jugada con el FX les salió bien, cosa que les podría haber salido también mal teniendo en cuenta el precedente de tres chips para tres consolas que fueron canceladas, la GreenPiece de Philips, la VeggieMagic de Apple y una de Hasbro de Realidad Virtual.

Durante el 2009 ARC fué adquirida por Virage logic [Click!], empresa fundada en 1996 que cuenta con aproximadamente 600 empleados, y que cotiza en bolsa en el índice NASDAQ desde hace ya mas de 10 años.

Super FX overclockeada

The Super FX was an extra graphics processor included in some Super Nintendo games. Using this chip, games like Star Fox were able to handle polygons and intensive sprite scaling. You can change the ceramic resonator with one faster. The result is a smoother frame rate and minimal slow down with multiple enemies.

Needed items: -Two ceramic capasitors at 18pf -An 24mhz quartz crystal (or 26Mhz if you find one)

First of all this mod is for cartridges that have the GSU1 and GSU2 FX chips. The older one MARIO CHIP 1 (used only in StarFox) can't be overclocked.

To do this mod you must open the cartridge and find the resonator. Take a look in the picture below to see the resonator from Vortex's cartridge.

You must replace the resonator with an 24mhz quartz crystal (a faster around 26MHz would be optimal). When solder the resonator, you must put the capasitors. Just take a look into the second picture for the capasitors.

After this mod, the game ran at with more speed and much, much smoother.

Props to marshallh from the benheck.com forums.

Entrevista a Dylan Cuthbert, presidente de Q Games, y programador principal del Star Fox/Wing.

This interview once appeared at http://www.emulatorium.com/ . The Emulatorium web site is now defunct.

Would you like to introduce yourself, explain your current job, and your connection with SNES software and hardware development?

Hi, I'm Dylan Cuthbert, programmer and games designer, I currently work at Sony Computer Entertainment Inc. in Tokyo, Japan. I currently have no connection with Nintendo. However, in the past, I developed X/Lunar Chase for the Gameboy and Starfox for the SNES.

What exactly was your role in the development of the FX chip(s)?

I had no direct role in the development of the FX chips - apart from being at the initial 'birth' meeting many years ago. The concept of the Super FX chip was almost solely Jez San's (president of Argonaut Software) idea, my boss at the time. I did, however, co-program the first game to utilize it.

How much input or help did Nintendo give you? Did they approach you with the idea for the chip, or did you go to them?

I can't comment on this, but it was probably a mutual collaboration out of a necessity for better 3D technology in consoles.

What was your role in the development of Star Fox?

I co-programmed Starfox with Giles Goddard and Krister Wombell. Various 3D support routines and a basic polygon core was supplied by the FX chip designers, Pete and Carl.

How did Star Fox come to be? Was it an Argonaut game or was it first developed at Nintendo? Was the game designed for the FX chip or the other way round?

Ideas to do with spaceships and the like came from Argonaut (have you ever seen a Nintendo game with spaceships in it before?), however the main game emphasis (railed and scripted arcade-style shooting) came from Nintendo. Of course, Namco's Starblade and Solvalou were in the arcades at about that time and I can't deny they had a serious impact in the direction of gameplay.

What was it like working with Nintendo and the infamous Shigeru Miyamoto?

Quite exciting, of course, at that time, no-one but diehard game fans had even heard of Miyamoto-san. When we began production of Starfox, Super Mario World had just been released and they were in the middle of making Mario Kart. It was generally just exciting to be living in Kyoto, which I'd have to say is one of the most pleasant, relaxing and exciting cities in the world — how it manages to mix all three of those things I just don't know. The best designer in Nintendo is a clever chap called Yoichi Yamada. You'll see his name crop up in the credits with regards to level layout in most Nintendo games. He laid out and edited the Starfox maps. Quite a remarkable and brilliant designer with extreme attention to detail.

What happened to StarFox2? Why was it cancelled and how far into development was it? How is it, if at all, related to StarFox64?

Starfox 2 was fully completed. I was lead programmer and whilst Giles made Stunt Race FX, myself and the rest of the original Starfox team (ie. Nintendo's artists and designers) expanded Starfox into a full 3D shooting game. We used state-of-the-art technology such as arbitrary plane clipping (which has only been seen recently in such games as Crash Bandicoot 2 & 3) to create some rather spectacular effects. (for the time) The reason for non-release was the then impending Nintendo-64 which of course was intended to be released a lot sooner than it actually was. Miyamoto-san decided he wanted to have a clean break between 3D games on the SNES and 3D games on the new superior 64 bit system. In retrospect, he could have released Star Fox 2 and there would have been over a year and a half before the N64 came out. But hindsight is always 20/20. Starfox 64 incorporated a lot of the newer ideas we created in Starfox 2 but it didn't, in my view, take the genre a full step forward. Starfox 2 really was a different direction of gameplay.

Where you ever involved in the proposed CDROM add-on, in either a software or hardware capacity. Did you receive prototype units? Can you shed any light on its demise?

No, never had anything to do with CD — you'd have to ask someone in my present company (Sony) about that probably.

How did you come across emulation? What emulation sites, if any, do you use or visit?

Basically, and rather selfishly, I just wanted to play Starfox again without having to find my old SNES. Besides, in the past I've bought a japanese snes, an english snes and an american snes — I'm sick of buying the damn things.

How involved are you in SNES emulation, or general emulation? What emulators do you use, and for what systems? What's it like seeing a game you have written for the SNES, for example, running on your home PC? What do game designers as a whole feel about their games being downloaded from the net and played on home computers, through emulators?

Right now, I'm too busy on certain newer systems that I don't have time to use emulators. :) As uninvolved as I am now with Starfox financially I, personally, quite like seeing people still able to enjoy Starfox. However, I'm sure the money men aren't happy.

What are you thoughts on emulation as a whole? How does the computer game industry view emulation? What are the views of other games programmers you know?

My personal opinion is that it is very interesting and good as long as it remains free. I don't think companies should be able to charge for an emulator of someone else's research-costly system — it is much cheaper to copy than to fund the initial research and idea process.

Have you ever come across any game related companies who where opposed/in support of emulation, and did they do anything to prevent/aid it. What is the general industries views of emulation, are they aware of it?

I don't think Sony America likes it, but that's about my entire knowledge of the company's positions.

What are your views on ROM piracy and the ISDA's recent closure of many ROM sites? Do you think games of a certain age should be released into the public domain? Would you support a move to legalise thge use of ROMs of a certain age? Do you have any knowledge of games companies views on this topic?

I think, with publisher permission, there should be no reason for not having old ROMs floating around. Let's face it, in most cases that's the only way the games will be preserved. What this means, of course, is that publishers should be allowed to decide for themselves — piracy is a bad thing all round. Many Spectrum (old 8 bit english computer) games publishers have already released ROM type images of their games to the public domain.

What computer or console equipment do you currently own? What is your favorite system and game, and why? Who do you think makes the best games? Did working with Nintendo teach you anything about game design?

The Playstation of course. Actually, I saw the Playstation launched when I was finishing up Starfox 2 and just the fact that Ridge Racer was as close to a 3D arcade game that a console had ever got sold me on it. The Saturn had Virtua Fighter which was glitchy, and ran at 20 to 15 frames per second. From working with 3D on the SNES I probably appreciated a 30 frames per second solid, fully textured frame rate a lot more than the average person. I immediately started sending my imaginary feelers towards Sony for a job. I wanted to work on that hardware. Best game of all time in the platforming category is Super Mario Bros 3. Best game of all time is pr0obably Carrier Command by Realtime Games (now Cross Products) on the Amiga/Atari ST. Duke Nuke'em 3D was a good attempt at generating a sense of awe and atmosphere in a game too. I had been designing and programming my own games since I was about 11 when a friend lent me his ZX81 — needless to say, I never gave it back. But even with that said, working with Nintendo definitely gave me an insight into their method. If something doesn't work, cut it completely — that is Miyamoto's general motto. It should be every game designer's. That, and of course, extreme attention to detail, especially around the main character or player's sphere of influence. (ie. Control, collision detection)

What are you views on the emulation of newer systems, such as the Playstation, Color Gameboy, and even the Dreamcast. Do you think such emulators hurt sales or these machines, and maybe even their games? Do such emulators worry the industry?

I'm probably not allowed to comment on this so I'd better not :)

What have you done since leaving Argonaut, who are you working for now? What projects do you have underway?

I worked at Sony Interactive Studios America (989 studios as it is called now) for over 2 years and was lead programmer on Blasto. However, once that was over, I felt a need to return to what has become the mecca for gamers — Japan. I'm now working on secret 'stuff' in a secret lab somewhere in Tokyo — however, you may have seen my duck and bath demo in recent movies posted on the web related to certain recent Sony press releases.

What are you most proud of in you game's career? What would you go back and change if you could?

Regrets? I would go back and make Blasto much easier and cut a lot of things out probably. Unfortunately, due to time constraints, we all had our hands tied behind our backs. Starfox was cool, but I really liked making X (Lunar Chase) on the Game Boy. It was and probably still is the only 3D shooting game for the Game Boy. Unfortunately, it didn't fit the puzzle game mold that Nintendo of America wanted so it was only released in Japan. It was no. 1 for quite a while though — and even re-surged to no. 1 when Star Fox was released a year later (because of an increased interest in 3D). Also, the designer of the Metroid series of games (Sakamoto-san) was director and co-designer of X. I'm also quite proud of the credits sequence of Starfox which was my design/program and was an enhanced version of the credit sequence in X. The music however was also incredible — unfortunately the composer left Nintendo after Starfox so there hasn't been music as good as that in any game from Nintendo since (just in my opinion).

Imagen

Arquitectura/Caracteristicas técnicas.

• Architecture: RISC
• Clock Speed: 10.74Mhz M.A.R.I.O chip & FX GSU-1 / 21MHz FX GSU-2
• Peripheral ROM: 8Mbits M.A.R.I.O chip / 16Mbits FX GSU-1 & GSU-2
• Peripheral RAM: 1Mbit max
• Internal Data Bus: 16 bits
• External Data Bus: 8 bits
• Internal Registers: 16 bit x 16
• Instruction Cache: 512 Bytes
• Processing Advantages: Polygon Processing; Software Sprite Processing

Imagen

Juegos:

Juegos que usaron el chip FX1:

   * Dirt Trax FX
   * Star Fox (North America/Japan) / Star Wing (PAL)
   * Stunt Race FX (North America/PAL) / Wild Trax (Japan)
   * Vortex

Juegos que usaron el chip FX2:

   * Dirt Racer
   * Doom
   * Super Mario World 2: Yoshi's Island
   * Winter Gold / FX Skiing

Juegos en desarrollo finalmente no comercializados que iban a utilizar el Chip FX2:

   *Comanche
   *FX Fighter
   *Powerslide 
   *Star Fox 2 (Aparecido en Super NES Classic Edition -SNES Mini- en 2017)
   *Transformers: Generation 2 
   *Yoshi Racing (Prototipo que finalmente acabó dando lugar a Croc: Legend of the Gobbos)

Juegos cancelados:

   Super Mario FX

En este proyecto Mario iba a protagonizar su tercer juego en SNES, tras Super Mario World y Yoshi's Island: Super Mario World 2, y estaba siendo diseñado utilizando el poderoso chip Super FX para hacer que los jugadores vivieran la aventura de mario con gráficos en tres dimensiones. Lamentablemente, el proyecto fué una pesadilla de producción desde el principio de su diseño. Shigeru Miyamoto y su equipo pasaron cinco años trabajando duro en Super Mario FX, pero nunca quedaron satisfechos con el resultado, y nunca dió la impresión de ser algo mas qeu un benchmark para la consola. El proyecto fue cancelado, pero mas tarde portado para Ultra 64 (Nintendo 64), donde Mario finalmente pisó con fuerza en los reinos de Super Mario 64.

Aunque recientemente se ha sabido, que este juego nunca llegó a existir, y ni siquiera fue planteado programarlo con el chip, en su lugar Miyamoto optó desde el principio por el Super Mario 64.

   Comanche

Link a youtube: http://www.youtube.com/watch?v=4uZeF4AvxM0

Estubo siendo desarrollado por novalogic en los 90, practicamente a mediados, justo antes de ser cancelado, presumiblemente por falta velocidad y rendimiento, aunque no es lo que hemos visto todos en los videos del E3. Sin embargo, se sobreentiende que siendo atacados por varios helicopteros, y bajo un intenso fuego enemigo, la tasa de frames no fuera considerada suficiente. y digo yo, si el star fox corre a unos 15 frames, puede que en algunos momentos a 20, ¿que consideraría esta gente como "tasa de frames insuficicente"?. Que conste que un servidor juega al star wing sin echar de menos mas rendimiento, y siendo sinceros, no me creo nada. Me da la sensación de que es la excusa "copy & paste" de siempre, y el verdadero problema debió radicar, viendo el aspecto que lucía el juego, en la extraordinaria necesidad de dotar al cartucho con mas de 16 megas, lo cual, choca frontalmente con la capacidad de gestión de la memoria del FX. Para una beta fué mas que suficiente, pero el juego completo tenía que pedir mas memoria para incluir todos los datos, mapas, musicas, etc... me en la nariz da que no me equivoco mucho.

   Powerslide FX

Link a youtube: http://www.youtube.com/watch?v=pAp978pDFeo

Otro juego cancelado que fué programado originalmente para 3DO y Super nintendo, este último, usando el chip FX2. Estuvo siendo programado por Elite para SNES, y por Maelstrom games para 3DO, y su cancelación acabó con un cambio de plataforma hacia el PC, llevada a cabo por los mismos que desarrollaron la versión 3DO, y estoy leyendo que no se trata de un port, que no tienen nada que ver el uno con el otro. Powerslide es un juego de rallies, con sus coches de rallies, y su conducción orientada a los rallies, pero muy diferenciado del otro juego de coches para la consola, siendo, al menos, mucho menos arcade, o esa era la intención. Del numero de coches y "circuitos" no se nada, o no se sabe nada, ya que finalmente fué cancelado antes de que decidiesen contarnos mas cosillas sobre todo lo que incluiría. Existe una beta del juego para Super Nintendo, que podrás encontrar facilmente usando el google. Practicamente no pasa de una demo técnica (sinceramente, no lo he probado), pero al menos el rendimiento es bueno.

   Star Fox 2

Link a Youtube: http://www.youtube.com/watch?v=Pda2jBcUBWg

Este juego cancelado, es la mayor rareza de todos los juegos cancelados, al menos en el sentido de que se trata de un juego que no salió estando casi completado (a un 98% de su desarrollo), por lo tanto, hay un montón de información al respecto, y hasta una rom que fué terminada de programar tras su liberación. Casi prefiero enlazar a la página de wikipedia, para no extenderme demasiado por aquí, ya uqe es bastante lo que este tema ofrece para leer.

Wikipedia en Español: http://es.wikipedia.org/wiki/Star_Fox_2

Wikipedia en Inglés: http://en.wikipedia.org/wiki/Star_Fox_2

   FX Fighter

Nada se sabe, nada se dice... solo hay disponibles unas pocas imagenes, y una preview del numero 69 de la revista Nintendo power. El juego estuvo siendo originalmente programado para PC y Super Nintendo, siendo el primer título de lucha 3D, estilo "virtua fighter" de ambas plataformas. Al final solo la versión PC fué completamente producida hasta su lanzamiento, y no se sabe por qué se decidió cancelar la versión SNES. Evidentemente no iba a estar ni cerca del virtua fighter de los arcades... ¿que?, ¿otra vez problemas de rendimiento?, parece ser que se quedaron sin excusas...

Mapas de memoria y direccionamiento

Bueno, pues os cuento a las deducciones que he llegado por mi cuenta. Resulta que, como sabréis, la SNES tiene 2 mapas de memoria (conocidos HiROM y LoROM) que le implican a la CPU el tiempo de espera entre una petición a memoria y el dato recibido (esto se debe a que es una transferencia asíncrona con la ROM del cartucho); así, en HiROM sólo espera 3 ciclos (creo recordar) y en LoROM son 4 ciclos del reloj maestro. Como el SuperFX es el que gestiona la ROM con los datos del programa (y la bufferea), lo lógico es usar el modo de memoria más lento, de modo que se pueda consumir el tiempo necesario dentro de la GSU para que los datos lleguen a la SNES. Al usar un mapa LoROM, ya implica usar el rango de memoria [$00-$3F]:[$8000-$FFFF] para los datos de ROM (2 Megabytes), más [$40-$7D]:[$0000-$FFFF] haciendo un total de 4Megaytes (algo menos realmente, por los dos bancos reservados a la WRAM). Pero además, hay que meter el acceso a la RAM que tiene la GSU, que es de 128Kbytes, es decir 2 bancos más, y también hay que meterla en LoROM (para tener los 4 ciclos), por lo que hace de ser en la zona de bancos [$40-$7D], así que es lógico pensar que, para simplificar el decodificador de direcciones, esta zona se reserva para la memoria RAM de la GSU, y de paso se usa para la memoria RAM que se usa para las partidas, de modo que se decodifica todo el rango [$40-$7F] de la misma forma, usando todo el banco, no sólo la parte alta del mismo.

Después de todo este rollo, tengo que añadir una cosa... realmente la SNES podría direccionar datos de programa en ROM en el rango [$C0-$FF]:[$0000-$FFFF] como una HiROM normal y en el rango [$80-$BF]:[$0000-$8000] como una LoROM normal, de modo que se podría añadir una ROM extra de hasta 4 Megabytes (HiROM) + 2 Megabytes (LoROM), haciendo un total de 48 Megabits que no podrían ser accedidos por la GSU. Imaginad por ejemplo esa zona para la música, enemigos y fondos 2D, texturas y demás cosas.

En cuanto a las características que hablábamos antes, están todas bien, añadiendo lo de las velocidades. Por cierto, que me sorprende que en la documentación que tengo describen la GSU-1 e indican que tiene 2Megabytes de direccionamiento como he explicado y funcionamiento a 10.74MHz, por lo que entonces entiendo que los nombres comerciales quedan así:

• MARIO chip -> usado sólo en StarFox, es la GSU-1 pero con capacidad de direccionar sólo 1 Megabyte de ROM. Funciona a 10.74 MHz

• GSU-1 -> usado sólo en Dirt Trax FX/Stunt Race FX, Vortex, con capacidad direccionar 2 Megabyte de ROM. Funciona a 10.74 MHz.

• GSU-2 -> usado en el resto de juegos, es la GSU-1 con alguna corrección interna y que funciona a 21 MHz.

Entonces estábamos equivocados, porque Stunt Race usa la GSU-1, pero creo que es indicada para StarFox 2 por la memoria que tiene la PCB instalada, que es de 512Kbytes y no de 256Kbytes como tiene Yoshi's Island, por ejemplo. He leído en Nesdev que usando la GSU-2 para el StarFox 2 se producen cuelgues y pantallazos negros, aunque no es algo confirmado 100%. Si hubiera una PCB con la GSU-2 y 512 Kbytes de SRAM se podría probar a poner el StarFox 2 a ver cómo funciona.

Por cierto, que este pinout lo hice yo con el polímetro y un cartucho del Stunt Race FX:

No lo había encontrado por ningún lado, así que lo hice yo mismo.

Conectores(Pinouts):

Conectores(pinouts) del puerto de cartuchos, EXT, y controlpad

   CONECTORES DEL CARTUCHO
   (La parte delantera del conector es la parte izquierda del dibujo)

Definiciones:

A0-A15 - address bus A (offset)

BA0-BA7 - address bus A (bank)

/RD - read control line for address bus A

/WR - write control line for address bus A

/CART - set low by console's address decoder when address bus A is accessing memoryin the cartridge region

/WRAM - set low by console's address decoder when address bus A is accessing memoryin the WRAM region

/IRQ - a cartridge can pull this low to request an IRQ interrupt on the main CPU

PA0-PA7 - address bus B

/PARD - read control line for address bus B

/PAWR - write control line for address bus B

CIC - the security chip (referred to as CIC because that's how it's labeled on cartridge boards)

EXPAND - line is pulled high through a resistor the only other thing this is connected to is a pin of the expansion port (probably meant to allow cartridges to know if something is in the expansion port)

CPU_CLOCK - I believe this is either the current memory access cycle clock, or it is the current clock given to the CPU core. I need to do more verification to be sure. I know that a 21.477MHz signal is given to the main CPU (+peripherals) chip, and depending on the current memory access cycle, the CPU core is actually clocked at 3.58, 2.68, or 1.79 Mhz (divided down from the original 21.477MHz). This line connects to the main CPU (+peripherals) chip, which I believe outputs this system frequency, probably to allow a cartridge to stay synchronized with the CPU's memory access cycles if it needs to.

REFRESH - This is also some kind of clock I believe. I think it is output from the MainChip and connects to the WRAM. It's probably some kind of memory refresh signal.

Audio Inputs - whatever the cartridge puts on these lines will be mixed into the SNES's audio output.

NOTA 1 En cartuchos LoROM, el pin A15 no se usa para acceder a la ROM. Esto es debido a que de cada página de 64Kb, sólo se puede acceder a los primeros 32Kb. Los siguientes son los mismos, un mirror. En HiROM si se usa, y se accede a los 64Kb.

NOTA 2 Puede que en otros pinouts y documentos veas las lineas /CART y /RD definidas de otra forma. Esto es porque la manera de acceder a las ROMs en la SNES es un poco confusa y compleja. Despues de mucho pensarlo, yo lo enfoco así:

/CART está conectado al /OE de la ROM, o al decodificador del cartucho, si lo hubiera. /RD está conectado al /CE de la ROM.

Según este enfoque, /CART indica que la dirección del bus se refiere al cartucho (a alguna ROM o a la SRAM). Cuando /RD se activa, los chips del cartucho se habilitan y por tanto se lee aquel cuyo /OE esté habilitado. Si sólo hay una ROM, no hay problema, y si hay varias, y/o una SRAM, el decoder se encarga de habilitar el /OE de uno de ellos.

Puede parecer confuso e incluso estúpido, pero Nintendo quiso hacerlo así. Después de mucho pensar, y de haberlo consultado con otros gurús de la SNES, está me parece la manera más correcta de verlo. Si se profundiza, acaba siendo mas comodo. Aún así, la mejor manera de entenderlo es echarle tiempo.

   ROM PINOUT

   DSP PINOUT

   MAD-1 PINOUT

   SECURITY PINOUT

   S-RAM PINOUT

   PUERTO DE EXPANSIóN(EXT)

• B0-B7 son las lineas de direccion del Bus B
• /BRD y /BWR son las lineas de lectura y escritura del Bus B
• D0-D7 son las lineas del bus de datos
• EXPAND esta conectado al pad 2 del conector de cartuchos.

   PUERTO DEL CONTROL PAD

1 - GND 2 - x 3 - x 4 - Data 5 - Latch 6 - CLK 7 - 5V

• Data es un pin de ENTRADA. Es por donde el pad manda a la SNES el estado de los botones.
• CLK es un pin de SALIDA. Cada vez que la SNES manda un pulso, el pad manda el estado del siguiente botón.
• Latch es un pin de SALIDA. La SNES manda un pulso por aqui para indicar al pad que debe registrar el estado de los botones, y almacenarlos, para mandarlos posteriormente por la linea Data. Para ello, el pad cuenta con un registro de 16 bits (dos chips 4021).

Fuente: consolasparasiempre.net

Conectores(pinouts) y Protocolos del ratón, multiout, y controlpad

1. About the Author

Author: Jim Christy Version: 1.02 E-Mail: jchristy@hplred.HP.COM

2. Introduction

For all you game hardware enthusiasts out there, I took the opportunity this weekend to put a scope on my Super Nintendo connectors and find out what is going on. Because the standard Multi-out cable connector only has internal contacts for the audio and video signals, I had to find some more push-in gold contacts at a local store to fully break out all the signals. It appears easier to do this than make your own connector.

In short, I found that in addition to S-VHS, the multiout also supports RGB and sync. I also got the controller pinouts and protocol, which opens up some interesting possibilities. One could rather easily construct a "macro recorder" that records your exact button presses for a game sequence and allows you to play them back. They will be time-accurate by definition of the protocol, and depending on how random the game plays, you should be able to replay those sequences that get boring, and then take over control when you want.

If all of this is already well known, then sorry for the waste of net bandwidth...

3. SNES Multi-out cable connector pins.

These are numbered the way Nintendo did, and the view is looking back "into" the connector on the CABLE.

Additional Notes:

As seen above, the SNES does have RGB capability. I was able to get a stable raster on my NEC MultiSync "classic" using the RGB and sync pins. However, the video levels are not RS-170 compatible. The DC offset needs to be filtered out with some large capacitors and the peak-to-peak video amplitude may need to be reduced to 0.7v by using a lower load impedance than 75 ohms. The Y/C (S-VHS) signals *appear* to be directly usable, but tests cannot be made until I find the pinouts for the S-VHS connector on my TV.

4. SNES Controller cable connector pins.

I could not find a Nintendo numbering scheme, so I made one up. The view is looking back "into" the connector on the CABLE.

(No se trata de la misma nomenclatura pero nos hacemos a la idea de los pins del pad).

Additional notes:

Pins 5 and 6 show a DC voltage of 5v on a DMM. I forgot to look at them on a scope so there may pulses too. However, they don't connect to anything at present.

The controllers have a small circuit board with 2 surface mount 14-pin ICs, marked by Nintendo as IC-A and IC-B. Although rubber domes are used to provide the tactile response of the buttons, they are not capacitive technology as originally thought. Instead they use what appears to be carbon impregnated rubber on the underside which makes a resistive path (200 ohms) across 2 carbon coated PCB pads when depressed.

   · The red wire goes to pin 2 on IC-A.
   · The orange wire goes to pin 8 on both IC-A and IC-B.
   · The yellow wire goes to pin 9 on both IC-A and IC-B. 

IC-A and IC-B appear to be identical, with a 91 date code and have another (possible part number) of 545. These are most likely 2 parallel load shift registers in series. Buttons on the controller pull the parallel load inputs to ground through the contact formed by pressing a button. IC-B serially feeds IC-A, which then drives the serial data line to the SNES CPU.

5. SNES Controller Communication Protocol

Every 16.67ms (or about 60Hz), the SNES CPU sends out a 12us wide, positive going data latch pulse on pin 3. This instructs the ICs in the controller to latch the state of all buttons internally. Six microsenconds after the fall of the data latch pulse, the CPU sends out 16 data clock pulses on pin 2. These are 50% duty cycle with 12us per full cycle. The controllers serially shift the latched button states out pin 4 on every rising edge of the clock, and the CPU samples the data on every falling edge.

Each button on the controller is assigned a specific id which corresponds to the clock cycle during which that button's state will be reported. The table in section 4.0 lists the ids for all buttons. Note that multiple buttons may be depressed at any given moment. Also note that a logic "high" on the serial data line means the button is NOT depressed.

At the end of the 16 cycle sequence, the serial data line is driven low until the next data latch pulse. The only slight deviation from this protocol is apparent in the first clock cycle. Because the clock is normally high, the first transition it makes after latch signal is a high-to-low transition. Since data for the first button (B in this case) will be latched on this transition, it's data must actually be driven earlier. The SNES controllers drive data for the first button at the falling edge of latch. Data for all other buttons is driven at the rising edge of clock. Hopefully the following timing diagram will serve to illustrate this. Only 4 of the 16 clock cycles are shown for brevity.

(La imagen no es muy clara, haced click encima para verla mejor).

6. SNES Controller Button-to-Clock Pulse Assignment

Additional notes:

Clock cycles 13-16 are left high by controllers. On a mouse, cycle 16 is low.

The way the SNES responds if data is low during these cycles varies from game to game. Donkey Kong contry 1 acts as there is no controller in the port, Super Bases loaded 2 does not care.

NOTE: S-VHS is not means to mean Super-VHS. It stands for Super-Video (connector and output)

OK, the SNES uses the 65816 processor, which is basically a 16-bit version of the 6502. It runs at 3.579545 MHz (color-burst), and has an 8-bit data bus. It can address up to 16MB.

The carts are nothing more than ROM. To tell you how much data is one, take the number of 'MegaBits' and divide by 8 to get megabytes. That's how much data is really in the carts. So, an 8-mbit cart really is only 1 megabyte.

7. SNES Mouse Protocol

The snes mouse uses the same timing and protocol as a regular pad for it's buttons. The left button is reported at the 9th cycle, and the right button at the 10th cycle. The snes recognizes the mouse when the bit at the 16th clock cycle is low instead of high.

2.5ms after the 16 clock pulses, another series of clock pulses occurs. This is in fact cycles 17 to 32 since no new latch pulse had occured yet. The data is active low, just like the buttons. This time, the clock timing is different:

Each time the SNES polls the mouse, the mouse reports how it moved since last poll. When no movement occured since last poll, all the motion bits stays high (which means binary 0). The direction bits keep their last state. Mouse sensitivity:

The mouse has 3 configurable sensitivity levels. The currently active sensitivity level is reported by bits 11 and 12:

   · Bit 11 low, Bit 12 high: High sensitivity
   · Bit 11 high, Bit 12 low: Medium sensitivity
   · Bit 11 high, Bit 12 high: Low sensitivity

Selecting the sensitivity mode:

A special sequence is used to rotate between the 3 modes. First, a normal 12us latch pulse is applied. Next, the first 16 bits are read using normal button timings. Shortly after (about 1ms), 31 short latch pulses (3.4uS) are sent, with the clock going low for 700ns during each latch pulse. For selecting a specific sensitivity, simply execute the special sequence until bits 11 and 12 are as desired.

Fuente: repairfaq.org

CPU 65c816

Una breve introducción:

La super nintendo tuvo un microprocesador central llamado W65c816 (el cual es una versión CMOS del 65816). Se trata de un "micro controlador" (http://es.wikipedia.org/wiki/Microcontrolador), basado en el 5A22 producido por Ricoh (http://en.wikipedia.org/wiki/Ricoh), el cual pudo ser usado en otros sistemas, como el apple IIGS, todos ellos procedentes de la tecnología MOS 6502 (http://en.wikipedia.org/wiki/MOS_Technology_6502). Esta CPU tenía 24 lineas de direccionamiento (bits de direccionamiento), por lo que es capaz de acceder a mas de 16 megas de memoria. Tuvo dos modos basicos de operación: modo de 16 bits nativos, y modo de 8 bits nativos. El procesador se comportaba de manera similar en ambos modos, con la excepción de que en "modo nativo" solo podías hacer calculos de 16 bits, y en el "modo emulación" solo podías hacer calculos de 8 bits. Resulta complicado mezclar calculos de 8 y 16 bits. La razón por la que el modo de 8 bits es llamado "modo emulación", es porque es casi 100% compatible con el procesador 6502 de 8 bits que usaba la NES (y anteriormente, algunos otros ordenadores y consolas).

Existen libros con documentación extensiva sobre microprocesadores 65816, y alcanzan facilmente las 400 paginas, si no mas. "65816/65802 assembly language programming" de michael fisher (http://www.amazon.com/65816-65802-Assem ... 0078812356), y "Programming the 65816" de william labiak (http://www.amazon.com/Programming-65816 ... 0893037893).

CPU central de SNES, basado en el 5A22 de Ricoh.

Alguna de sus caracteristicas principales:

   · Circuitería para a generación de interrupciones NMI en V-blank.
   · Circuitería para la generación de interrupciones IRQ en posiciones calculadas de pantalla.
   · Registros de multiplicación y división.
   · Una unidad DMA, soportando dos modos primarios:
   · DMA general, para transferencias en bloque, a un ritmo de 2.68 MB/s.
   · DMA H-Blank, para la transferencia de pequeños conjuntos de datos, al final de cada scanline, fuera del periodo activo de visualización.
   · Dos direcciones de bus separadas, dirigiendo el bus de datos de 8 bits:
   · Un bus de datos de 24 bits para acceso general (BUS A).
   · Un bus de datos de 8 bits, principalmente para registros APU y PPU (BUS B).
   · Diseño de CMOS completamente estático, para un bajo poder de consumo (300ma a 1Mhz), y una incrementada inmunidad al ruido(!).
   · Amplio rango de operación de voltajes: 1.8 V ± 5%, 2.5 V ± 5%, 3.0 V ± 5%, 3.3 V ± 10%, 5.0 V ± 5% (para su uso con periferico de voltaje variable).
   · Amplio rango de operación de frecuencia.
   · El modo emulación permite completar la compatibilidad con el software del 65c02, exceptuando códigos de operación(opcodes) indocumentados.
   · Puede alcanzar una frecuencia de 14Mhz.
   · El direccionamiento de memoria de 24 bits provee acceso a 16 Mbits de espacio de memoria.
   · 16 bits ALU, acumulador, puntero de pila(stack pointer) y registros de índice(index registers).
   · Salida de la "Dirección valida de datos" (VDA, valid data adress) y la "dirección valida de programas" (VPA, valid program adress) para caché dual e implementación DMA de robo de ciclos.
   · Salida VPB (vector pull) para indicar cuando un vector de interruptores está siendo direccionado.
   · La "entrada abortiva" (ABORTB) y su vector asociado soporta reparaciones de condiciones de error del bus del procesador, tales como violaciones de acceso de memoria.
   · Programa separado y registros del banco de datos permiten la segmentación del programa o 16 Mbits de direccionamiento lineal (solo datos).
   · El Registrador directo y el apilador relativo de direccionamiento provee capacidad de reentrada, recursiva y programación trasladable.
   · 24 modos de direccionamiento – 13 modos originales del 6502 con 92 instrucciones, usando 256 códigos de operación(opcodes), incluyendo la mayoría de nuevos opcodes implementados en el 65c02.
   · Las instrucciones adicionales “wait-for-interrupt”(WAI) y “stop-the-clock”(STP) reducen poder de consumo, disminuyen la latencia de interrupciones y permite la sincronización con eventos externos.
   · Las instrucciones del co-procesador(COP) con vectores asociados mantienen las configuraciones del co-procesador. P.ej: procesadores de coma flotante.
   · Instrucción “escape reservado”(WDM) para futuros “two-bytes” opcodes(códigos de programa) y un enlace a futuros diseños (P.ej: el “yet-to-be-released terbium 32 bit MPU”). WDM son las iniciales del fundador William D. Mensch.
   · Instrucciones de traslado en bloque. Permitiendo el copiado rápido de estructuras de datos desde un área de la RAM a otra, con código mínimo

Imagen del 65c816, como el de SNES, pero no compatible con su placa.

Detalles de su desarrollo:

La CPU es un procesador 5A22 hecho a medida para nintendo, basado en un núcleo 65c816 de 16 bits. El CPU emplea una velocidad del bus variable, dependiendo en la región de memoria desde la que está siendo accedida por cada ciclo de instrucción: el reloj de entrada está dividido por 6, 8, o 12, para obtener el “clock-rate” del bus. Los Ciclos no accedidos, la mayoría de accesos de registros, y algunos accesos generales, usan el divisor de 6. Los accesos a la WRAM, y otros accesos generales, usan el divisor de 8. Solo los registros de acceso del controlador del puerto serie usa el divisor de 12.

El chip tiene un bus de datos de 8 bits, controlado por dos buses de dos direcciones. El “BUS A”, de 24 bits, es usado por accesos generales, mientras que el “BUS B”, de 8 bits, es usado por los registros del chip de apoyo (principalmente los procesadores de video, y de audio). Normalmente solo un unico bus es usado al mismo tiempo, sin embargo, la unidad incorporada de acceso directo a memoria(DMA) sitúa una señal de lectura en un bus y escribe una señal en el otro para lograr una velocidad de transferencias en bloque superior a 2.68 Mbits/segundo(dato pendiente de ser corregido, ¿quizás sean2.68 Mbytes/segundo?).

La unidad DMA(acceso directo a memoria) tiene 8 canales independientes, cada uno de los cuales pueden ser usados en dos modos. DMA general transfiere hasta 64 KBytes en un instanste, mientras el H-blank DMA(H-DMA) transfiese de 1 a 4 bytes al final de cada scanline del video. HDMA es típicamente usado para cambiar parametros de video, para lograr efectos tales como perspectiva, pantalla partida(split screen), y "ventanado" no rectangular (non-rectangular windowing) sin la movilización de la CPU principal.

El 5A22 también contiene un puerto I/O de 8 bits (el cual estuvo mayormente en desuso en la SNES); La interfaz de circuitos del puerto de control, incluyendo el acceso paralelo y en serie al controlador de datos; una unidad de multiplicación y división de 16 bits; y circuitería para la generación no enmascarable de interrupciones en interrupciones V-blank e IRQ, en posiciones de pantalla calculadas.

El W65c816s (también 65c816 o 65816) es un microprocesador de 16 bits(MPU) desarrollado por “Western Design Center(WDC)”. El W65c816s es una versión mejorada del WDC 65c02 de 8 bits, es en si mismo una CMOS mejorada de la venerable tecnología MOS del 6502 NMOS MPU. El “65” del 65c816 viene de su modo de compatibilidad, y el “816” significa que el MPU tiene un modo seleccionable de 8 y 16 bits.

Además de la disponibilidad de registros de 16 bits, el direccionamiento de la memoria extendida de 24 bits del W65c816s, soporta hasta 16 MBytes de RAM, un conjunto mejorado de instrucciones, y un “apilador de punteros”(stack pointer) de 16 bits, tan bien como varias señales electricas para una gestión mejorada del hardware del sistema.

Al reseteo, el W65c816s empieza en “modo emulación”, significando esencialmente que se comporta como un 65c02. Despues del reseteo, el W65c816s podría ser cambiado al “modo nativo” con una secuencia de dos instrucciones, causando la permisión de todas las características avanzadas del procesador, sin embargo aún manteniendo una sustancial graduación de retrocompatibilidad con la mayoría del software para el 65c02. Sin embargo, al contrario que la versión PDIP40 del 65c02, el cual es un reemplazo compatible “pin a pin” para su antecesor NMOS, el PDIP40 W65c816s no lo es.

El desarrollo del W65c816s comenzó en 1982 después de Bill Mensch, fundador y CEO de WDC, consultado con APPLE computer en una nueva versión de las series Apple II de ordenadores personales.

Apple quiso un MPU que pudiera tener software compatible con el 65c02, entonces en uso en el Apple IIC, pero con la habilidad de direccionar mas memoria, y cargar y almacenar tratamientos de 16 bits. El resultado fue que el 65c816 acabó en marzo de 1984, con muestras proveídas a APPLE y ATARI.

APPLE, subsecuentemente integró el 65c816 en el Apple IIGS. Mensch fue ayudado durante el proceso de desarrollo por su hermana Kathryn, quién fue responsable de parte de la maquetación.

En 1990, el 65c816(así como el antecedente 65c02) fue convertido a un núcleo completamente estático, el cual lo hizo posible para completamente parar el reloj del procesador sin perder datos en cualquiera de los registros. Esta opción, junto con el uso de RAM estática asincrónica, hizo posible producir diseños que usaban un poder minimo de consumo en “stand by”.

El diseño básico del 65816 fue secundado por GTE, SANYO, y otras, desde mediados de los 80, y principios de los 90. Típicamente, cuando las fábricas de hardware diseñaban un proyecto desde cero, usaban el 65c816 preferiblemente sobre el 65c802, resultando este último retirado de la producción. A partir del 2010, el W65c816s está disponible desde WDC(Western Design Center) en un PDIP de 40 pines o en un encapsulado PLCC44, también como un núcleo para integración ASIC(por ejemplo las series W55V9x de Winbond). WDC, así misma una compañía de semiconductores fabulosa, trabaja con varias fundiciones para producir el W65c816s, así como otros productos compatibles.

En el pasado, WDC ofreció un 65c02 PDIP40(40 pines) compatible, variante del W65c816s, denominado 65c802. El 65c802 fue completamente compatible con el 65c02 en todos los aspectos, pero podría ser hecho para comportarse como un 65c816 si se deseara (incluyendo el uso de registros de 16 bits).

Mapa de memoria

(Mensaje antiguo de magno)

• Bancos $FF - $C0 -> 64 bancos x 64 kbytes/banco = 4 Megabytes = 32 Megabits (zona HiROM)
• Bancos $BF - $80 -> sólo se usa de ellos la parte alta y es la zona "shadow ROM" de la parte alta de los bancos $FF a $C0, es decir, que es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total
• Bancos $7F y $7E -> Es la memoria RAM, que no cuenta tampoco para el total.
• Bancos $7D - $40 -> 62 bancos x 64 Kbytes/banco = 3.875 Megabytes = 31 Megabits (zona HiROM)
• Bancos $3F y $3E -> son 2 bancos a los que sólo se puede acceder a la parte alta, así que esto suma unos despreciables 64 Kbytes
• Bancos $3D - $00 -> sólo se usa de ellos la parte alta y es la zona "shadow ROM" de la parte alta de los bancos $7D a $40, es decir, que es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total

Así que los cálculos dan un maravilloso total de................ ¿¿¿63 MEGABIT(más esos miserables 64 Kytes)??? Pues sí, así es, éste es el tamaño máximo que Nintendo fijó para sus PCBs, de modo que no vendió ninguna que permitiera más capacidad porque el decodificador de direcciones implementado en el MAD-1 y MAD-2 no permitía direccionar más memoria; él era el responsable de esa "Shadow ROM" de la que hablaba. Pero si ahora cogéis esas mismas dos zonas y pensáis que sí se pueden direccionar desde la SNES, tenemos que añadir al total de 63 megabits que habíamos calculado:

• Bancos $BF - $80 -> 64 bancos de 32 Kbytes/banco = 2 Megabytes = 16 Megabits (zona LoROM)
• Bancos $3F - $00 -> 64 bancos de 32 Kbytes/banco = 2 Megabytes = 16 Megabits (zona LoROM)

Por tanto, si no usáramos un mapper de los que da Nintendo y nos hacemos una PCB casera nosotros mismos con el decodificador de direcciones, tenemos un total de ¡¡¡95 MEGABIT!!!

ESPECIFICACIONES GENERALES:

- Unidad central de proceso: · Fabricado y procesado por "Ricoh". Se trata de un chip de uso genérico, modelo 5A22, basado en el procesador WDC W65c816, de 16 bits (evolución del 65c802 de 8 bits usado por la NES), y el 2a03, parte sonora de la Nintendo entertaiment system. · BUS de 24-bits, BUS de direcciones de 8-bits, y BUS de datos de 8-bits. · Opciones adicionales:

   · DMA and HDMA
   · Timed IRQ
   · Parallel I/O processing
   · Hardware multiplication and division

· Frecuencias NTSC:

   · input: 21.47727 Mhz
   · Bus: 3.58 Mhz, 2.68 Mhz, o 1.79 Mhz

· Frecuencias PAL:

   · Input: 21.28137 Mhz
   · Bus: 3.55 Mhz, 2.66 Mhz, o 1.77 Mhz

- RAM de sistema: · 128 Kbytes. · La memoria se asigna a varios segmentos del "BUS A", y también se puede acceder en serie a través de registros en el "BUS B". · El video y subsistemas de audio contienen RAM adicional reservados para uso de los procesadores.

- Sonido: · UCP de sonido: Sony SPC700 de 8 bits corriendo a 4.1 MHz, con 64 KB de RAM compartidas por los dos chips (S-SMP y S-DSP), y una ROM de inicio de 64 bytes. El subsistema de audio es casi completamente independiente del resto del sistema, con una frecuencia de 24.576 Mhz tanto en sistemas NTSC, como en sistemas PAL, y solo puede comunicarse con la CPU a través de 4 registros en el "BUS B". · Chip principal de sonido: S-SMP de 16 bits a 32 Khz de 8 canales con hardware de descompresión similar al ADPCM · Chip secundario de sonido: S-DSP de 16 bits a 32 Khz de 3 canales con hardware de descompresión utilizado para los efectos sonoros · Se accede a la RAM a 3.072 Mhz, con accesos multiplexados entre el SPC700 y el DSP. Esta RAM es usada para almacenar el programa SPC700, y apilar los samples de audio, la tabla de punteros, y el DSP echo buffer. · El DSP genera formas de onda a 32Khz por la entrada de mezcla de 8 voces independientes y 8 "tap FIR" típicamente usados para reverberación. Cada voz puede tocar su sample PCM a una tasa variada, con interpolación gaussiana, stereo panning, y ADSR (linear, no linear, o ajuste directo sobre el volumen). · Las salidas de la voz y del filtro "FIR" son mezclada por salida directa y por entrada posterior en el filtro "FIR". · Todos los samples de audio son ADPCM, comprimidos, y usando reducción en la tasa de bits. · El SPC ejecuta programas (subidos usando la ROM de inicio) para aceptar instrucciones y datos desde la CPU y manipular los registros del DSP para generar la musica y efectos de sonido apropiados. · Tiempo de Ciclo de Memoria: 279 Minutos · Audio RAM: 512 Kb · Canales de sonido: 8, usa samples en forma de onda comprimidos · Modulador de pulsos de códigos: 16 Bits · Extensión del archivo en PC: .SPC · Hardware en el cartucho, puerto de expansión, o ambos, pueden proveer audio en stereo para su mezcla en la salida de audio analogico del DSP, antes de que este salga de la consola · Algunos juegos "fluyen" sus samples constantemente desde la ROM, en lugar de volcarlo directamente sobre la ram del SPC

- Video: · Unidad procesadora de imágenes: 16 Bits · Paleta: 32,768 Colores · RAM de texturas y mapas: 128 KB · Colores en pantalla: 4096. Según el modo gráfico : ejemplo, 241 en mode 1 o 256 en mode 7, sin contar sub-blending · Resolución: 256x224 a 512x448. La mayoría de los juegos usan 256x224, 320x224 o 400x300 píxeles; había trucos para obtener 512x448 pero era usado raramente · Máximos sprites en pantalla: 128 (32 por línea, y/o 34 tiles de 8x8). · Máximo número de píxeles de sprites en un scanline: 256. El generador de imágenes tiene un error de software el cual se deshacía de los sprites más cercanos en vez de los más lejanos si un scanline excedía el límite. · Modos de pantalla más comunes: Modo 1 texto píxel a píxel (16 colores por tile; 3 capas de scroll) texto affine mapped, modo 7 (256 colores por tile; una capa de rotación/escalado) · La unidad de procesamiento de imágenes (PPU) se compone de dos distintos pero estrechamente vinculados paquetes IC, que puede considerarse como una sola entidad. También contiene 64 kB de SRAM para almacenar datos de vídeo (VRAM), 544 bytes de memoria de objetos de atributo (OAM) para almacenar información sprite, y 512 bytes de RAM generador de color (CGRAM) para almacenar datos de paleta. La PPU se registró por la misma señal que la CPU, y genera un píxel cada dos o cuatro ciclos. Ambos sistemas NTSC y PAL utilizar los chips PPU mismo, con un pasador por chip que selecciona operar en NTSC o PAL. · Las imágenes pueden ser salidas a 256 o 512 píxeles de resolución horizontal y 224, 239, 448, o 478 píxeles verticalmente. Resoluciones verticales de 224 o 239 son por lo general salida de escaneo progresivo, mientras que resoluciones de 448 y 478 se entrelazan. Los colores son elegidos entre el espacio del color RGB de 15 bits, para un total de 32.768 colores posibles. Los gráficos pueden tener hasta 128 sprites y hasta 4 capas de fondo, todos compuestos por combinaciones de cuadros de 8x8 píxeles. La mayoría de los gráficos almacenados en paletas de uso CGRAM, con el color 0 de cualquier gama de colores que representa la transparencia. · Los sprites puede ser 8x8, 16x16, 32x32, 64x64 o píxeles, cada uno con uno de las ocho paletas de 16 colores y los tiles de uno de los dos bloques de 256 en VRAM. Los sprites pueden ser volteados en sentido horizontal y vertical como un unico bloque. Cada sprite se puede encontrar en uno de los 4 planos. · Las capas del fondo(background) en la mayoría de los modos van desde los 32x32 hasta los 128x128 tiles, con cada tile en uno de los dos planos ("foreground" and "background") y usando una de las 8 paletas. Los tiles son tomados de un conjunto de capas de hasta 1024 (como los permisos de VRAM) y puede ser volteado horizontal, y verticalmente. Cada capa puede ser desplazada(scroll) tanto horizontal, como verticalmente. El número de capas de fondo y el tamaño de las paletas depende del modo:

   · Modo 0: 4 layers, all using 4-color palettes. Each BG uses its own section of the SNES palette.
   · Modo 1: 3 layers, dos usando paletas de 16 colores, y una usando paletas de 4 colores.
   · Modo 2: 2 layers, ambos usando paletas de 16 colores. Cada tile puede ser desplazado individualmente.
   · Modo 3: 2 layers, uno usando la paleta de 256 colores y uno usando paletas de 16 colores. La capa(layer) de 256 colores también se pueden especificar directamente desde una profundidad del color de 11-bit (RGB443).
   · Modo 4: 2 layers, uno usando la paleta de 256 colores y un usando paletas de 4 colores. La capa(layer) de 256 colores directamente puede especificar colores, y cada tile puede ser individualmente desplazado.
   · Modo 5: 2 layers, una utilizando paletas de 16 colores y una usando paletas de 4 colores. La decodificación de los tiles se altera para facilitar el uso de las resoluciones de 512 (anchura y entrelazado).
   · Modo 6: 1 layer, usando paletas de 16 colores. La decodificación de los tiles es igual que en el modo 5, y cada tile puede ser desplazado de forma individual.
   · Modo 7: 1 capa de 128x128 tiles de un conjunto de 256, lo que puede interpretarse como una capa(layer) de 256 de un solo color plano o una capa de 128 colores en dos planos. La capa puede ser rotada y ampliada mediante transformaciones de matríz. HDMA a menudo se utiliza para cambiar los parámetros de la matríz para cada línea de escaneo, para generar efectos de perspectiva.

· Las capas de fondo(background layers) pueden ser individual pixeladas, y las capas y los sprites se puede acortar de forma individual, y combinado por el añadido o sustracción del color para generar efectos más complejos y mayor profundidad de color que pueda ser especificada directamente. · El PPU puede ser instruido para trabar la posición del píxel actual en cualquier momento durante la salida de la imagen, tanto por el software del juego, como por el dispositivo conectado al segundo puerto de mando. El software del juego podría entonces leer de nuevo la posición trabada. El PPU también se puede utilizar para una rápida multiplicación de 16 bits por 8 bits.

-Tamaño de los cartuchos: · Super nintendo podía direccionar hasta 128 Mbits, aunque solo 117.75 estaban realmente disponibles. Un mapeado normal limpio podría facilmente direccionar hasta 95Mbits de datos en la ROM (48 Mbits en modo FastROM) con 8 Mbits respaldados por batería en RAM (no de sistema, si no en el propio cartucho), sin embargo, la mayoría de los controladores de acceso de la memoria, solo soportan mapeos de hasta 32Mbits. Los cartuchos mas grandes ocupan 48 Mbits (Tales of Phantasia and Star Ocean), y los cartuchos mas pequeño han llegado a ocupar tan solo 2Mbits. Algunos cartuchos podrían también contener una batería para partidas salvadas en una SRAM, también contener memoria RAM extra de sistema, o chips de apoyo para aumentar el rendimiento de la capacidad de proceso.

- Alimentación: ·Transformador de entrada: 120 V AC, 60 Hz, 17 Watts ·Transformador de salida: 10 V DC, 850 mA (NTSC), 9 V AC (PAL)

- Puerto EXT.

- Controladores y conectores: · Puerto para controladores de siete pins en el frontal de la máquina · Respuesta del controlador: 16 Milisegundos · Salida de audio/video SNS A/V Multiout · Bahía para dispositivos externos · Entrada de CD 10 V · Salida de radiofrecuencia A/V (Eliminada en la versión compacta del Super Nintendo) · Conector para cartuchos de juego

Fuentes: Google, & wikipedia

Accesorios, extendido

Nintendo Scope

Acompañando al lanzamiento de la consola, Nintendo quiso añadir su particular actualización de la Zapper de NES. Super Nintendo Scope no es sino la pistola de luz de la Super Nintendo, aunque en ésta ocasión de tamaño desmesurado. Fue el primer accesorio de éstas características inalámbrico, pues funciona conectando un pequeño receptor de infrarrojos en el puerto del mando 2 de la consola, pudiéndonos colocar hasta a 6 metros de la pantalla sin problema de transferencia de datos.

La forma del aparato, como se puede ver a simple vista, dista bastante de ser como las clásicas pistolas, adoptando el diseño de un bazoka futurista a juego con los colores de la consola. Dispone de 4 controles, una palanca de encendido ON/OFF, un botón de Pause ovalado, el botón de disparo Fire de mayor tamaño y de color rojo y un pequeño botón añadido en la empuñadura del periférico de uso variable, aunque por norma general no sirve más que para disparos secundarios en algunos juegos. El aparato está preparado para ser utilizado tanto por zurdos como por diestros, pues la mira es movible para suplir este problema.

Los materiales de fabricación son los mismos que componen la consola, con lo que es posible que con el paso del tiempo amarilleen (como se puede ver en la fotografía), el peso era bastante superior al de cualquier pistola óptica de la época, lo que sumado al diseño del accesorio hacían que su manejo no fuera precisamente cómodo. Además, consume 6 pilas AA para su utilización y no duran precisamente mucho.

El Super Nintendo Scope recibó duras críticas sobre todo por su excesivo tamaño y peso y por la pobre autonomía de las pilas, hecho que se reflejó en unas ventas pobres que propiciaron su cese de fabricación en 1995. Pese a todo, recibió siete juegos exclusivos y podía utilizarse en otros cuatro títulos más, lo que unido al juego que venía incluído con el accesorio nos da un catálogo de 12 títulos:

- Revolution X - Terminator 2 The Arcade Game - Yoshi's Safari - Battle Clash - Metal Combat Falcon's Revenge - X-Zone - Bazooka Blitzkrieg - Lamborghini American Challenge (utilizando el Super Nintendo Scope habilita otro modo de juego) - The Hunt for Red October (se utiliza para las fases de bonus en primera persona) - Operation Thunderbolt (permite utilizarse como control de juego, así como el Mouse) - Tin Star (permite utilizar el Scope como controlador, así como el Mouse)

Y el juego que venía incluído con el accesorio, el Super Scope 6.

Super Scope 6 se compone de 6 juegos, 2 de tipo puzzle, uno de puntería pura y dura y otros tres de acción, divididos en dos gurpos, Blastris y Lazerblazer:

- Blastris:

   - Blastris A: se trata de un Tetris horizontal en el que en lugar de rotar las piezas, las cosemos a tiros eliminando las partes que no nos interesan para formar líneas.
   

   - Blastris B: otro clon del Tetris en el que los disparos hacen rotar las piezas.
   

   - Mole Patrol: juego de puntería pura y dura en el que debemos disparar a unos alienígenas azules que se esconden en los cráteres lunares, sin duda, el juego más divertido de lejos del compendio Super Scope 6.
   

- Lazerblazer:

   - Intercept: básicamente, se trata de interceptar los misiles que van pasando por la pantalla para evitar que lleguen a su objetivo. Hay que calcular el retardo con el que nuestros disparos llegan a su objetivo para eliminarlos, lo que hace que sea más difícil de lo que parece en un principio.
   

   - Engage: todo un émulos del After Burner pero sin posibildad de mover la nave, lo único que podemos hacer es eliminar a los enemigos antes de que disparen o tratar de destruír sus misiles.
   

   - Confront: tres cuartas de lo mismo que el anterior, pero sin que se mueva el escenario. Bastante divertido.
   

Capcom Fighter Power Stick

[Review de chinitosoccer]

Lo prometido es deuda así que aquí va este review acerca de uno de los mejores mandos jamás lanzados para cualquier consola de 16 bit, no sólo por la calidad de sus componentes sino también por las ventajas que el uso del mismo ofrece al momento de disfrutar, o “reventar” si se quiere nuestros juegos de Super Nintendo (créanme que a mi por lo menos me ayudó a terminar varios juegos).

De la mano de Capcom, el Fighter Power Stick fue lanzado junto a un juego que ya todos tenemos requeterecontra conocido y que provocaba furor por aquel entonces entre los aficionados a los juegos de pelea 1 vs 1, estoy hablando del Street fighter 2 y sus diversas revisiones en formato Super Nintendo.

Ante la premisa “si queres jugar como los profesionales de los arcades, necesitas el mismo control del arcade”, aunque esto era verdad en un principio, también era cierto que se le podía sacar buen partido con muchos otros juegos de SNES, ya que el stick direccional, a base de microswitches, (como los verdaderos sticks usados en los muebles arcade japoneses) responde de maravilla aún en juegos de plataformas, como por ejemplo Super Mario Wolrd, Donkey Kong Country, Contra 3, Super Metroid etc. Pero es obvio que donde verdaderamente brilla es con juegos de puro estilo arcade, ya se trate de juegos de pelea 1 vs 1, “Beat em’ ups” o shooters “matamarcianos”.

En cuanto a las funciones que ofrece, estaban bastante limitadas si lo comparamos con otros sticks que habían disponibles en la época, y que ya incorporaban programación de movimientos, slow motion etc., No es el caso de el stick de Capcom, este solo ofrece las mismas funciones que las de un pad normal de SNES pero añade 3 velocidades de disparo automático, y permite intercambiar entre 4 u 8 direcciones (ideal para el Ghouls’n Ghosts PACMAN y demás juegos que no usan diagonales).

Esto que en un principio puede parecer poco, sobre todo si tenemos en cuenta el elevado precio que tenía este mando en la época que salió a la venta, pero para mi es una de las principales virtudes de este control, y que si activamos el turbo en velocidad 1 (la maxima) , obtendremos un arma letal contra cualquier escollo que nos pudiera plantar cara en ese X juego, siempre y cuando este se pueda sortear a base de aporrear botones XD …

Por ejemplo en Axelay ya no necesitamos preocuparnos por obtener power-ups, ya que podemos convertir el arma normal en una verdadera ametralladora, a mí en particular me resulto muy útil para pasarme el UN Squadron, que no incluía disparo automático por software; en Final Fight se puede hacer que hasta el lento de “Mike Haggar” lance puñetazos a la misma velocidad que Guy (bueno casi XD ), o en Street Fighter, donde la patada débil de Ryu se convierte en una pesadilla para aquellos oponentes que descuiden bloquear golpes por debajo…

Efectivamente, el Turbo 1 es tan rápido que en algunos juegos ni siquiera funciona como debería, las pulsaciones son tan rápidas que la lógica del juego ni siquiera las registra XD, por lo que deberemos limitarnos a usar el turbo en velocidad 2 o incluso 3 (En Super Street Fighter 2 el turbo 1 no funciona bien, creo que si lo hace en el SF2 World Warrior y en SF2Turbo HF).

En cuanto a la calidad de los componentes, como ya dije, el stick de Capcom incorpora las mismas piezas utilizadas en muebles arcade, mas que nada el joystick direccional, se trata nada menos que de un Sanwa modelo JLW, este incluye un restrictor de 4/8 direcciones ajustable, se puede cambiar a gusto del consumidor, pero para ello hay que desarmar el stick...

--Restrictor octogonal, girándolo 90º podemos eliminar las diagonales.

--Microswitchs activados por paletas.

Los botones por otra parte, no son los mismos que encontramos en un mueble arcade; pero estos son convexos y de rápida respuesta, activados tambien por medio de microswitchs, aunque reitero que no son de la misma calidad que los profesionales (que son cableados), estos van soldados a una plaqueta, aun asi trasmiten una buena sensación al ser pulsados y resisten bastante bien el embite del tiempo, y con años de abuso estos no quedan flojos como sucede con los de Neo Geo.

Un tiempo más tarde Capcom lanzó 2 nuevas revisiones de este stick , uno de los cambios realizados fue la sustitución de el joystick JLW por un LS-40 de la marca Seimitsu, Sin importar la versión, el CFPS ofrecía mejor calidad que cualquier stick con botones activados a base de membranas de goma, como por ejemplo el NES advantage o los arcade stick de 3 y 6 botones para Sega Megadrive, y hasta me atrevo a decir que supera a los sticks old style de la Neo Geo AES, ( la bola del CFPS es mas grande y mas pesada) tanto en calidad de materiales como en funciones y ergonomía,

Adaptadores: originariamente fueron lanzadas al mercado 2 versiones de este stick, uno para Megadrive y otro para la Super Nintendo, el primero es sólo compatible con Megadrive de serie, pero el modelo para la consola de Nintendo incluía cables para poder usarlo tanto en NES como Super Nintendo así como en el CPS Changer que incluía 2 puertos para mandos de SNES por lo que el Capcom Power Stick Fighter es totalmente compatible con este sistema. También fueron lanzados adaptadores que permitían conectar el stick a otras consolas y ordenadores personales como el Fm Towns y X68000 de Sharp que asimismo recibieron versiones de la saga Street Fighter 2. Aquí dejo el link de la web de un coleccionista japonés fanático del CFPS que tiene en su poder un sinfín de adaptadores para este mando http://www.pipitan.com/cpsf.html

Compartimiento para 4 pilas AA, desconozco qué propósito tendría ya que el modelo que yo tengo ni siquiera tiene el cableado ni los contactos de estas :-? ..

Resumen:

-'Calidad de componentes: stick Sanwa pero botones “custom”: 8,5'

-'Prestaciones: sólo 3 niveles de autofire, selctor 4/8 way pero sin programación de movimientos: 7'

-'Compatibilidad: sirve para cualquier juego de SNES además que permite también ser usado en la vieja NES y existen varios adaptadores para otros sistemas menos los de Sega y Atari : 9'

-'Aspecto y ergonomía : el CPFS es feo feote aunque funcional: 7'

Nota final: 8

DOCUMENTACIÓN TÉCNICA

Apéndice: Introducción al 65816 para programadores del 6502

by Brett Tabke

After programming in 6502 language for over a decade, I was getting a bit BORED. One can only code the same routines with the same opcodes so many times before the nausea of repetition becomes overpowering. When I heard the news that CMD was building a cartridge based on a 20 MHz 65816 I was overjoyed. For years I've heard those with 65816 bases systems brag about its capabilities. To us old 6502 programmers, the opportunity to program the fabled 65816 is a new lease on life.

The 65816 is an 8-/16-bit register selectable upgrade to the 6502 series processor. With 24 bit addressing of up to 16 Megabytes of RAM, the powerful 65816 is a logical upgrade that leaves 6502 programmers feeling right at home. It is amazing how fast one can adapt to the new processor. It sounds funny to say it, but the only difficulty I have had learning the 65816 is that there are so many options and choices to complete the same task, that it is hard to decide which method is best.

To get started programming the 65816, I would recommend purchasing the book, "Programming the 65816" from The Western Design Center, manufacturer of the 65816. While it is a bit pricey, the sheer quality and content of the 600 page book is worth the money. Rarely, if ever, has there been a CPU manual as thorough and detailed as the Western Design book. If you know 6502 assembly, then Programming the 65816 is probably the only 65816 book you will ever need.

• Getting a Feel for the Modes

The 65816 may be operated in Native mode or 6502 Emulation mode. Emulation mode is a 100% 6502 compatible mode where the whole processor looks and feels like a vintage 6502. Native mode offers 8- or 16-bit user registers and full access to 24-bit addressing.

While in emulation mode, not only are all the 6502 opcodes present in their virgin form, but the new 65816 instructions are also available for usage. In fact, the first lesson to learn about programming the 65816 is that emulation mode is much more powerful than a stock 6502. The only true difference between emulation mode and our venerable C64's 6510 processor is that unimplemented opcodes will not produce the results expected on the former. Since all 256 of the potential opcodes are now implemented on the 65816, older C64 software that uses previously unimplemented opcodes will produce erratic results.

To select between emulation and native modes, a new phantom hidden emulation bit (E) was added to the status register. Shown in programming models hanging on top of the Carry bit, the emulation bit is only accessible by one instruction. The new instruction (XCE) exchanges the status of the Carry bit and Emulation bit. To move to emulation mode, set the carry and issue an XCE instruction. To move to native mode, clear the carry and issue the XCE instruction.

• My, How Your Index Registers Have Grown!

While in native mode there are two new directly accessible bits present in the status register. The 65816 implements new hardware interrupt vectors which include a new hardware BRK vector in ROM; therefore, the old BRK bit of the status register is no longer needed. The BRK bit is replaced with the X bit to select either 8- or 16-bit index registers. The former empty bit 5 is now filled with the M bit to specify the accumulator and memory access as 8- or 16-bit. Two new instructions are used to clear or set bits within the status register. The SEP instruction sets bits, and REP clears bits. SEP and REP use a one byte immediate addressing mode operand to specify which bits are to be set or cleared. For example, to set the X bit for 8 bit user registers:

   SEP #%00010000 ; set bit 4 for 8-bit index
   _______________; registers. 

Or to clear bit 4:

   REP #%00010000 ; clear bit 4 for 16-bit index
   _______________; registers. 

When in 8 bit mode, the index registers perform their function in standard 6502 form. When status bit X is set to 0, both the X and Y index registers become 16 bits wide. With a 16-bit index register you can now reach out to a full 64K with the various indexed addressing modes. An absolute load to an index register in 16-bit mode will retrieve 2 bytes of memory-the one at the effective address and the one at the effective address plus one. Simple things like INX or DEY work on a full 16 bit, which means you no longer have to specify a memory location for various counters, and loops based on index counters can now be coded in a more efficient manner.

The formerly empty status register bit 5 is now referred to as bit M. M is used to specify an 8- or 16-bit wide acculmulator and memory accesses. When in 8 bit mode, (M=1), the high order 8 bits are still accessible by exchanging the low and high bytes with a XBA instruction-it is like having two acculmulators! However; when set for a full 16-bit wide accumulator, all math and accumulator oriented logical intructions operate on all 16 bits! If you add up the clock cycles and bytes required to perform a standard two byte addition, you can start to see the true power of 16-bit registers.

• More Register Improvements

Zero Page has now been renamed to Direct Page-corporate thinking, go figure. A new processor register D was added to allow Direct Page to be moved anywhere within the first 64K of memory. The direct page register is 16 bits wide, so you can now specify the start of direct page at any byte. Several old instructions now include direct page addressing as well. To move direct page, just push the new value onto the stack (16 bits) and then PLD to pull it into the direct page register. You may also transfer the value from the 16-bit accumulator to the direct page register with the TCD instruction. Direct page may also be moved while in emulation mode.

While in native mode, the stack pointer is a full 16 bits wide, which means the stack is no longer limited to just 256 bytes. It can be moved anywhere within the first 64K of memory (although while in emulation mode, the stack is located at page one). There are several new addressing modes that can use the stack pointer as a quasi-index register to access memory. Numerous new push and pull instructions allow you to manipulate the stack. A few of the more useful stack intructions useful to programmers, are the new instructions to push & pull index registers with PHX/PHY and PLX/PLY.

Two other new processors registers are the Program Bank Register (PBR) and the Data Bank Register (DBR). The Program Bank Register can be thought of as extending the program counter out to 24 bits. Although you can JSR and JMP to routines located in other RAM banks, individual routines on the 65816 still must run within a single bank of 64K-there's no automatic rollover from one bank of RAM to the next when executing successive instructions. In this sense, it may help to think of the 65816 processor as a marriage of Commodore's C128 Memory Management Unit (MMU) and an 'enhanced' 6502-a very similar concept.

The Data Bank Register is used to reach out to any address within the 16 megabyte address space of the 65816. When any of the addressing modes that specify a 16-bit address are used, the Data Bank byte is appended to the instruction address. This allows access to all 16 megabytes without having to resort to 24-bit addressing instruction, and helps enable code that can operate from any bank.

• New Addressing Modes

There are new addressing modes on the 65816. Several new instructions are designed to help relocatable code that can execute at any address. The use of relocatable code on the 6502 was extremely limited. With 16 megabytes of address space, writing relocatable code increases the overall utility of the program. To write relocatable code, several new instructions use Program Counter Relative Long addressing. This allows relative branching within a 64K bank of RAM. There's also Stack Relative addressing, and a push instruction to place the program counter onto the stack, so that a code fragment can pull it back off and can instantly know its execution address. Another new feature are two Block Move instructions, one for forward MVP and one for backward MVN. Simply load the 16-bit X register with the starting address, the Y index register with the ending address, the accumulator with the number of bytes to move, and issue the MVP or MVN instructions. MVN is for move negative, and MVP is for move positive, so that your moves don't overwrite themselves. Block Moves use two operand bytes: one for the source bank of 64K and one for the destination bank. Memory is moved at the rate of seven clock cycles per byte.

Several new addressing modes are used to access the full address space. A 65816 assembler would decode "long" addressing given this input:

   LDA $0445F2 ; load byte from $45F2 of RAM
   ___________; bank 4 

   LDA $03412F,x ; load byte from $412F of bank 3
   _____________; plus x. 

Quite a few instructions have been given new addressing modes. How many times have you wanted to do this:

   LDA ($12) ; load indirect without an
   _________; offset. 

Or how about a table of routine addresses:

   JSR ($1234,x) ; jump to a subroutine via
   ____________; indexed indirect addressing!

• Other fun new instructions:

   TXY,TYX Transfer directly between index registers
   BRA Branch always regardless of status bits
   TSB Test and set any bit of a byte
   TRB Test and reset (clear) any bit of a byte
   INC A/DEC A Increment or decrement the accumulator directly
   STZ Store a zero to any byte 

• Summing Up

As you can see, the 65816 opens up a whole new world of programming-it feels like a new lease on life. Of course, it's going to take some time to learn the new processor. But while the 20 MHz speed is a nice perk, I believe that the real power of CMD's new peripheral is indeed the engine under its hood: the 65816-a super CPU!

• Native Mode Options

While in Native Mode, the m flag controls the size of Accumulator A and most Memory Operations, while the x flag controls the size of the X and Y Index Registers. This provides 4 different configuration possibilities, as charted below. The REP and SEP instructions are used in combination to swith configurations.

   Imagen

It is important to note that the m flag will control the size of all operations dealing with memory except in operations involving the X and Y Index Registers (CPX, CPY, LDX, LDY, STX and STY) when the x flag controls the size.

• Emulation Notes

While in Emulation Mode, Accumulator A is forced to 8-bit mode. You can, however, access the upper 8 bits with instructions that specify Accumulator B, and all 16 bits at once with instructions that specify Accumulator C. The X and Y Index Registers are also forced to 8-bit mode, with no means available to access the upper 8 bits. To further assist in compatibility, the Stack is forced to Page 1 of Bank 0. The Direct page Register (D) is fully functional in this mode, allowing direct page to be placed anywhere in Bank 0. Likewise, the Program Bank Register (PBR) and Data Bank Register (DBR) are also fully functional. While it would seem that these latter items would allow programs to operate from any bank in Emulation mode, there are some caveats; interrups will force the program bank to zero without saving the PBR first, and RTI won't attempt to restore the bank. Therefore, Native mode would be recommended to execute programs in other banks.