Snes And Gba With Dynarec And Asm


wipeout2000

Member
Joined
Dec 8, 2005
Messages
170
Location
New York, New York
Website
Visit site
Ok granted I don't know much about programming, but from what I've read, Zodttd is using a dynamic recompiler to make his playstation emulator somewhat playable. I guess my first question is to what degree are the snes and gba emulators written in asm and my second question is would it be possible to write a dynarec for them to make them full speed like the psx emulator? (sorry if i sound like a noob)
 
wipeout2000 posted on Jul 15 2006 at 01:35 PM said:
Ok granted I don't know much about programming, but from what I've read, Zodttd is using a dynamic recompiler to make his playstation emulator somewhat playable. I guess my first question is to what degree are the snes and gba emulators written in asm and my second question is would it be possible to write a dynarec for them to make them full speed like the psx emulator? (sorry if i sound like a noob)

It's possible for every emulator, but the thing is that it takes a lot of TIME to write.
 
Last edited by a moderator:
The snes's main cpu is a 65c816 @ 2.68 and 3.58 Mhz. Creating a dynarec for it would not only be a lot of work, it would make a very small increase in speed as the cpu emulation doesn't take that long.

Now, if someone rewrote the PPU emulation in assembler, it could make a big difference in speed.
 
Shikaku posted on Jul 15 2006 at 05:36 PM said:
wipeout2000 posted on Jul 15 2006 at 01:35 PM said:
Ok granted I don't know much about programming, but from what I've read, Zodttd is using a dynamic recompiler to make his playstation emulator somewhat playable. I guess my first question is to what degree are the snes and gba emulators written in asm and my second question is would it be possible to write a dynarec for them to make them full speed like the psx emulator? (sorry if i sound like a noob)

It's possible for every emulator, but the thing is that it takes a lot of TIME to write.

nonsense, it only took zottd 12 hours :D
 
Last edited by a moderator:
xinfernoofdantex posted on Jul 15 2006 at 02:46 PM said:
Shikaku posted on Jul 15 2006 at 05:36 PM said:
wipeout2000 posted on Jul 15 2006 at 01:35 PM said:
Ok granted I don't know much about programming, but from what I've read, Zodttd is using a dynamic recompiler to make his playstation emulator somewhat playable. I guess my first question is to what degree are the snes and gba emulators written in asm and my second question is would it be possible to write a dynarec for them to make them full speed like the psx emulator? (sorry if i sound like a noob)

It's possible for every emulator, but the thing is that it takes a lot of TIME to write.

nonsense, it only took zottd 12 hours :D
Yes, but I heard a rumor that zottd, in his spare time, flies around with a red cape and a blue suit. :p
 
Last edited by a moderator:
TKF15H posted on Jul 15 2006 at 05:49 PM said:
xinfernoofdantex posted on Jul 15 2006 at 02:46 PM said:
Shikaku posted on Jul 15 2006 at 05:36 PM said:
wipeout2000 posted on Jul 15 2006 at 01:35 PM said:
Ok granted I don't know much about programming, but from what I've read, Zodttd is using a dynamic recompiler to make his playstation emulator somewhat playable. I guess my first question is to what degree are the snes and gba emulators written in asm and my second question is would it be possible to write a dynarec for them to make them full speed like the psx emulator? (sorry if i sound like a noob)

It's possible for every emulator, but the thing is that it takes a lot of TIME to write.

nonsense, it only took zottd 12 hours :D
Yes, but I heard a rumor that zottd, in his spare time, flies around with a red cape and a blue suit in his spare time. :p

GRR, nothing a little kryptonite can't handle, LEARN YOUR PLACE ZOTTD, CODE CODE CODE!!! :p
 
Last edited by a moderator:
Squidge posted on Jul 15 2006 at 01:45 PM said:
The snes's main cpu is a 65c816 @ 2.68 and 3.58 Mhz. Creating a dynarec for it would not only be a lot of work, it would make a very small increase in speed as the cpu emulation doesn't take that long.

Now, if someone rewrote the PPU emulation in assembler, it could make a big difference in speed.
What is a PPU? Is it on your to-do list, or is it just too much work?
 
Last edited by a moderator:
Yono posted on Jul 15 2006 at 04:41 PM said:
Squidge posted on Jul 15 2006 at 01:45 PM said:
The snes's main cpu is a 65c816 @ 2.68 and 3.58 Mhz. Creating a dynarec for it would not only be a lot of work, it would make a very small increase in speed as the cpu emulation doesn't take that long.

Now, if someone rewrote the PPU emulation in assembler, it could make a big difference in speed.
What is a PPU? Is it on your to-do list, or is it just too much work?

Post processing unit?

Eh?

Edit: Looks at Wiki... Picture processing unit? Whaaa?
 
Last edited by a moderator:
Peripheral Processing Unit / Picture Processing Unit. The SNES has both .. the most stressful, as I would imagine Squidge is referring to, would be the picture processing unit or more conventionally named, "VDP" .. Video Display Processor. Like a 2D GPU that also handles forming actual images to output to the TV in the real console. It takes the constructed frame data from the CPU and graphics tile data from VRAM and builds an actual digital frame, which then is converted to analog and made into a real picture. It's also where hardware scaling and rotation and other visual effects are handled. It's a lot beefier than the CPU in the SNES is, which is why using dynamic recompilation with SNES games would yield little benefit-- the CPU is not really the bottleneck at all.

It really does seem to me a faster video subsystem emulation method would be a much bigger performance boost to SNES emulation than anything-- that and perhaps audio. As Squidge said, were it ASM, it'd probably provide enormous gains-- Vobbo was describing to me over 20 FPS gains using ARM9 ASM graphics code rather than C in his MAME port.
 
This is why the snes is difficult to emulate:

Colour Palette
--------------

The SNES has a 256 entry 15-bit colour palette, allowing for 256 colours on
screen out of a total palette of 32768. However, games can and do change
colour entries during a frame, this combined with hardware colour value
addition and subtraction and an overall brightness setting, can easily boost
the number of colours on screen to several thousand!

Tiles
-----

All SNES graphics data is made up of tiles, a tile being an 8x8 block of
pixels, with each pixel made up of 2, 4 or 8 bits, allowing for 4, 16 or 256
colours per pixel.

To complicate matters, the SNES hardware stores tile data in planar format,
that is all the bit 1's of all the pixels of a tile are stored together,
then all the bit 2's and so on. Its like a sequence of 1-bit deep 8x8 pixel
blocks.

When a tile is used as background data, a 3-bit palette start address is
associated with each tile, allowing the programmer to choose a different
block of colours for each tile from the larger SNES colour palette. Sprites
can only use tiles of depth 4 (16 colours), but each sprite has a palette
start address.

Background Graphic Modes
------------------------

The SNES has eight background graphics modes, each mode varies the number of
individual background layers available, the depth of each layer and what
other features are available. Programmers can change the background mode
during a frame.

The two most commonly used modes are mode 1, which allows two 16-colour
background layers and one 4-colour layer and mode 7, which allows one 256-
colour layer, but the layer can be rotated, stretched, squashed, sheared and
generally messed around with.

Each background is made up 32x32 8x8 tiles. However, the number of tiles in
each direction can be double as can the individual tile size. This allows for
a virtual background size of 256x256 up to 1024x1024. Switching to 16x16 tile
size actually just groups four 8x8 tiles together, there is no true 16x16 tile
on the SNES.

Backgrounds have a pre-defined priority order - when pixels from one
background layer overlap on the screen pixels from another background layer,
the pixels from the lower numbered background are displayed.

Each tile can be flipped horizontally or vertically, has a 3-bit "palette
number" and a priority bit. The priority bit is used to make all the pixels
in the tile appear in front of pixels from another background layer or
sprite that would otherwise normally appear in front of them. Colour 0 from
each tile is special and means "transparent", allowing non-transparent
pixels from background layers or sprites "underneath" to be visible.

Normally only 256x224 or 256x239 pixels are visible on screen and backgrounds
have a scroll setting that allows the screen to act as a window onto any
portion of their virtual size.

Two background modes are available that can display up to 512x478 pixels,
but they're not used by many games because the flicker, caused by the
interlace used display the image on a standard television, would give game
players headaches.

Sprites
-------

The SNES has 128 hardware sprites, each sprite can be made up of one or
several 16-colour, 8x8 tiles. Each sprite is assigned a number which defines
its pixel priority when two sprites overlap on screen, it also has a separate
sprite-to-background priority value which defines whether the sprite should
appear in front or behind of the various background layers. Each sprite also
has a 3-bit palette number, horizontal and vertical flip flags, a start tile
number and, of course, an X and Y position.

There's no way to turn off a sprite - if you don't want it to be visible you
have to place the sprite at off-screen position.

The SNES hardware seems to impose limits on the number of sprites that can
appear on each scanline; there are one or two games out there that rely on
this 'feature' to hide sprites they don't want visible.

Mosaic
------

The SNES has a hardware mosaic effect. The upper left-hand pixel from a block
of pixels up to 16 pixels wide can be made to cover the area of the other
15; the pixel appears up to 16 times its original size. The effect can only
be used on the background layers, not sprites. All backgrounds share the
same size setting but the effect can be turned on and off per background
layer.

Many ROMs combine the mosaic effect with a brightness fade to zoom out of one
game screen then zoom on to the next.

Offset Per Tile
---------------

Three of the background screen modes reduce the number of visible background
layers by one, and use its screen data as per-tile background scroll data
for the remaining visible layers.

The background modes vary as to whether the vertical and horizontal scroll
values can both be altered, or just one of them. Tetris Attack uses the
effect to allow different parts of the screen to scroll vertically at
different rates.

The horizontal per-tile offset feature is very limited and only allows
adjustment in steps of 8 pixels.

Mode 7
------

Nintendo use this background screen mode to really show off the SNES compared
to the Sega's Mega Drive.

By specifying a centre of rotation and a 2 by 2 transformation matrix, the
mode 7 screen can be rotated, scaled, stretched, squashed, etc. just by
writing to a few PPU registers. By varying the values on each scanline, some
very interesting effects can be produced, these include a perspective
effect, shears, split-screen zooms, etc.

Each pixel is 8-bit (256 colours per pixel) and the screen itself has a
virtual screen size of 1024x1024.

Mode 7 has another feature where the number of colours are reduced to 128
and the spare bit is used to swap a pixel between background layer 0 and 1,
thus altering the sprite to background priority. This allows some pixels to
be appear in front of sprites and others appear behind.

Colour Addition / Subtraction
-----------------------------

The pixels of background layers and sprites can be directed to one of two
places, the main-screen or the sub-screen. The sub-screen is like a virtual
screen that cannot normally be seen, but the SNES has hardware that can add
or subtract the RGB colour palette values of each pixel on the sub-screen to
or from RGB values of pixels on the main-screen. The effect is that
background layers on the on the main-screen appear translucent, allowing the
sub-screen partly to show through. Examples are cloud, mist and water effects.

The effect can be turned on and off for each background layer on the
main-screen. There's a master switch for sprites as well, but when turned
on, only sprites with certain colour palette numbers actually have their
pixel values added to or subtracted from.

The SNES also has a separate fixed colour value; if colour addition or
subtraction is enabled and there's nothing on the sub-screen, the fixed
colour is added or subtracted instead. I've seen it used by games to darken
an area of the screen then overlay a menu on top, to implement a
fade-to-white effect and to tint an area of the screen a particular colour.

Windows
-------

The SNES provides two "clip windows". Each window is just an area defined by
a left and right position. A background layer or all sprites can be selected
to appear only inside or outside the window.

If both windows are enabled on the same background layer or for all sprites,
the areas they define are combined using one of four logical combination
modes: OR, AND, XOR and N-XOR.

If the left and/or right values are altered on each scanline (normally using
H-DMA), many different shaped windows can be created; I've seen circles,
pentagons, wavy lines, doughnuts, G's, etc.

There's also the colour window. Each window or both windows can be used to
define the area of the colour window. When the colour window is enabled for
the sub-screen, transparency effects occur only inside or outside the colour
window. When the colour window is enabled for the main-screen, it acts like
a master clip window, clipping all background layers and sprites and even
the back-drop colour to the area either inside or outside the colour window;
in the clipped areas, the sub-screen is displayed or just black.

Direct Colour Mode
------------------

On the 256 colour background modes, the otherwise unused 3-bit per-tile
colour palette number can be used in combination with the 8-bit tile pixel
data to form an 11-bit colour value (2048 colours) without using the SNES
colour palette registers.

Mode 7 has the same feature, but since mode 7 uses a different tile layout
with no 3-bit colour palette number, a fixed 256 colours are available
instead, again without using the SNES colour palette registers.

Interlace
---------

The SNES normally generates a non-interlaced picture. Interlace can turned
on and the only thing that happens is that the screen appears to flicker
slightly due to the way a television works. However, in the two hi-res.
background screen modes, if interlace is turned on the vertical resolution
doubles from 512x224 to 512x448 (or 512x478 if the expand vertical flag is
also set).

Not many games use the feature due to the flicker introduced by the
interlace, so its use is normally limited to title screens. However, one
game I know of, RPM Racing, uses the effect during the game.

DMA
---

The SNES provides 8 DMA (direct-memory-access) channels, although only one can
be active at once. Without any intervention of the 65c816 CPU, up to 64K of
data can be transferred from RAM or ROM to any PPU (picture processing unit)
register. Since V-RAM, colour palette and sprite position and display data can
only be written to via PPU registers, DMA provides a very convenient method of
transferring data faster than the CPU alone could provide. There are PPU
registers to read or write to the 128k work RAM, so DMA could be used to copy
data from ROM to RAM as well.

There is also a DMA read mode, where data is transferred from PPU registers
to RAM.

There are various limitations on DMA - if multiple DMA channels are started
at once, they execute in order, the numerically lowest one first, then the
next highest and so on. The 65c816 is stopped while DMA takes place. Each
DMA operation can only access one 64k bank at once. However, the biggest
limitation is that DMA can only take place when the graphics chips aren't
also performing graphics data DMA, i.e. DMA can only be used during the
v-blank period or when the screen is forcible blanked.

H-DMA
-----

H-DMA is like DMA in that data is transferred from ROM or RAM to PPU
registers without the intervention of the CPU. However, instead of all the
data being transferred in one block, a few bytes are transferred at a time,
just before the start of the each scanline.

H-DMA shares the same channels as normal DMA, so each channel can be set up
for DMA or H-DMA, but since normal DMA only occurs during v-blank and H-DMA
is disabled during this time, its actually easy to reuse a channel for both
types of DMA.

There are various H-DMA modes that define how many bytes should be
transferred each scanline, whether the destination PPU register is 8-bit or
16-bit, should new data be transferred each scanline, or can the same data
be reused if a count value hasn't reached zero, etc.

H-DMA gives a very powerful weapon to programmers, it allows PPU register
values to be easily changed each scanline, so many games can and do use it
to change screen colours, background scroll values, window shape values,
mode 7 matrix values, transparency effects, etc. during the frame.

Extra Chips Used by the SNES Inside Some Game Paks
==================================================

Super FX
--------

The Super FX is just a fast integer RISC-type processor but with a built-in
plot instruction that can draw a single pixel in the SNES' planar format into
a virtual screen very quickly, very handy for 3d polygon rendering. Its a
strange chip though - no stack, a 512 byte cache and a one stage pipe-line
that causes the instruction following a branch instruction to be executed.
Instructions fetched from the cache often execute in a single cycle.

Super FX games came with additional RAM inside the game pak that is used as
work RAM for the 'FX chip and as save-game positions, if the ROM supports it.

The 'FX chip has 16 16-bit registers and built-in fast integer multiply.
Although the Super FX and the 65c816 can run in parallel, the 'FX chip can't
access the game pack ROM or RAM at the same time as the main SNES CPU, so most
games just get the SNES CPU to execute a wait loop in the SNES work RAM.

The 'FX can't access the SNES custom hardware chips, so if the 'FX has
rendered a screen image in its work RAM, it has to go to sleep while the SNES
CPU copies the screen to video RAM, usually using DMA. The SNES CPU can pass
parameters to 'FX routines either by writing them into the 'FX work RAM or
writing directly into the 'FX registers, which it can be accessed by the CPU
only when the 'FX chip is sleeping.

There are two versions of the 'FX chip, the original 10MHz chip used in Star
Fox and limited to 1Mb of ROM access and 64K RAM and a newer version used in
Yoshi's Island, Doom, Vortex, Winter Gold, Star Fox 2, etc. which can be
clocked at 21MHz and can access twice as much ROM and RAM.

DSP1
----

The DSP1 is an early digital signal processor with an on-board ROM,
manufactured by NEC. The on-board ROM was loaded with a program developed
by Nintendo to turn the chip into a 3d maths co-processor, able to perform
most primitive, but time-consuming, calculations required when manipulating
objects in a 3d coordinate system relatively quickly, compared to the
speed of the 65c816 CPU alone, that is.

Most of the calculations supported seemed to be those required by a simple
flight simulator, i.e. the calculations available were choosen with Pilot
Wings in mind.

The DSP1 has been used in several other games, may be as many as 20, though
most ignore a lot of the available features. The games include Mario Kart, Top
Gear 3000, Battle Racers, Super Air Diver and Bases Loaded 2.

SA-1
----

The SA-1 is a fast, custom 65c816 8/16-bit processor, the same as inside the
SNES itself, but clocked at 10MHz compared to a maximum of 3.58MHz for the CPU
inside the SNES.

The SA-1 isn't just a CPU, it also contains some extra circuits developed by
Nintendo which includes some very fast RAM, a memory mapper, DMA, several
real-time timers, and the region lock-out chip.

The SNES (or ROM copiers) can only access the ROM inside the game pak via the
SA-1; and the SA-1 only enables access to the ROM once its internal region
lock-out chip has verified it has successfully communicated with a lock-out
chip inside the SNES. This very effectively prevents SNES ROM copiers from
being able to copy the ROM.

The SA-1 is used in Mario RPG and seems to be used in several other games
that Nintendo released in 1996 and beyond.

S-DD1
-----

Very little is known about this chip. It seems to be another digital signal
processor, possibly made by Texas Instruments, dedicated to decompressing
graphics data. Only two games I know of use the chip, Street Fighter Alpha 2
and Star Ocean.

Like the SA-1, the SNES and ROM copiers can only access the ROM via the S-DD1,
again preventing ROM copiers from dumping the ROM image.

[Taken from Snes9X docs]
 
Back
Top