Professor NES' Office Hours

2013-01-15 06:43:06 pm

Anything you can do I can do halfass

Since I'm getting snagged in streamchat and PM with similar questions on similar subjects that I'd imagine have some general interest and I'd rather not answer them a million times, I'm'a start this here to make anything I do have time for public. If you want to ask something, I'm more likely to see it in a PM since I get notified of those, and I can't guarantee I'll always have time or that I'll take all questions, but feel free to ask anyway.

Quote:

Do you play or stream any games yourself? And how did you acquire all that knowledge about games?

I don't actually run anything- I'm certain I could if I put in the time, but anything I'm decent at already has an epic-level run on the site, and putting in months practicing a game to perfection is lower on my priority list than screwing around with tech demos and indie game development or simply churning through my 50cm-tall queue of casual-play vintage RPGs. And really, my avatar speaks truth. I'm a Red Mage with a minor in Blue Mage. I specialize in doing/knowing a lot of things to a level where I can intermix them freely on the fly and pick up new talents easily rather than being perfect at any given task.

What I know (which is by no means complete; many times I've just gotten really good at piecing together a probable and convincing story between the readily verifiable facts) comes from years of overlap between personal and professional interest. Probably as early as elementary school I wanted to be a video game developer and spent a lot of time playing games. By middle school I was learning available starter-languages like LOGO and TI-83 Basic and dabbling in ROMhacking using off-the-shelf tools. By high school I'd greatly expanded my portfolio of programming languages and was fairly regularly trying to reproduce the mechanics of games I played and enjoyed, or else wanted but couldn't afford. And in undergrad I really lucked out and got to take a student-taught course on NES programming in a homebrew high-level Basic-oid language, which I followed with an engineering capstone project consisting of developing an NES on a prototyping board and learning 6502 Assembly code through literally recreating the chip itself from scratch. Unfortunately, by the time I was well-versed in vintage console development, it was the mid-2000s and game development had changed, so I derailed into another industry as a profession but kept up an interest in and gradual absorption of classic gaming tech.

If you're looking for raw tech info, there are a host of specialized sites and hacking communities out there such as nesdev.parodius.com or Sonic Retro which will get increasingly approachable the more you learn about programming and computer architecture in general.

Quote:

...since I've grown up in European boundaries, and since I'm clueless about the different versions and the technology behind it, I was wondering if you could clue me in what limits there are between EU, US and JP games and consoles.

So far as the differences between regions, most consoles have some form of lockout that isn't so much a tech difference as an after-the-fact active impediment, which is why many games will run on foreign consoles with the help of bypass tools and simple modifications. SNES in particular has physical design elements which prevent the insertion of foreign games, but can be bypassed with grinders or pliers (although a few games like Terranigma go a bit further and do a software check). Genesis has a couple electrical jumpers on the motherboard which cartridge code can check against bytes in the game header to determine whether it should run. Some Genesis models are easy to mod with a razorblade and soldering iron, I believe the Genesis 3 just agrees with whatever cart is put in it, and while I've failed at it myself, I've heard stories of success using Game Genie to spoof a cart's header bytes to match the console region. Nintendo reconfigured the connector pinout between NES and Famicom, removing a few pins for direct audio output from the cartridge and shuffling the remaining data pins. Cheap adapters will let you run NES games on a Famicom, and I think I caught wind at AGDQ that some NES boards still have pins to take a Fami cartridge socket, but I haven't actually checked this.

Either way, US and JP games are usually happy on the opposing system once you've tricked the lockout. EU games (PAL) have an additional snag in that the vast majority of vintage consoles don't time off the CPU clock but rather off the television-frame vsync signal. NTSC games expect a vblank every 1/60 second (but many only act on every other vblank, since each NTSC frame only carries half the scanlines).

Technically, as an aside, NTSC full-framerate is 29.someodd fps because it was originally 30fps for black and white TV but they needed extra signal time to fit the chroma data for color so they slowed it down a little but still within the analog tolerance of B&W TVs so existing TVs could still show a good image. Splitting the image into 2 half-frames at 60(-ish) likely had to do with the persistence time of early phosphor compounds and providing a cheap hack to allow more changes to the image per unit time. WHich means today we get to deal with shitty deinterlacing artifacts whenever we try to record TV-type video to digital Tongue

PAL framerate is 25 full frames or 50 half-frames per second. This means that NTSC-originating games not retuned for PAL will appear to run slowly on PAL, or conversely, PAL-sourced games not retuned for NTSC will appear to run fast on NTSC. Worse still, as I can only assume is the case in Terranigma, if a PAL game fills every bit of the time between frames with CPU logic, then such a game if played on an NTSC frameclock would just frameskip to all heck, so it's probably for the best that some games have more explicit lockout.

Thread title:

Since I'm getting snagged in streamchat and PM with similar questions on similar subjects that I'd imagine have some general interest and I'd rather not answer them a million times, I'm'a start this here to make anything I do have time for public.  If you want to ask something, I'm more likely to see it in a PM since I get notified of those, and I can't guarantee I'll always have time or that I'll take all questions, but feel free to ask anyway.

[quote]Do you play or stream any games yourself? And how did you acquire all that knowledge about games?[/quote]
I don't actually run anything- I'm certain I could if I put in the time, but anything I'm decent at already has an epic-level run on the site, and putting in months practicing a game to perfection is lower on my priority list than screwing around with tech demos and indie game development or simply churning through my 50cm-tall queue of casual-play vintage RPGs.  And really, my avatar speaks truth.  I'm a Red Mage with a minor in Blue Mage.  I specialize in doing/knowing a lot of things to a level where I can intermix them freely on the fly and pick up new talents easily rather than being perfect at any given task.

What I know (which is by no means complete; many times I've just gotten really good at piecing together a probable and convincing story between the readily verifiable facts) comes from years of overlap between personal and professional interest.  Probably as early as elementary school I wanted to be a video game developer and spent a lot of time playing games.  By middle school I was learning available starter-languages like LOGO and TI-83 Basic and dabbling in ROMhacking using off-the-shelf tools.  By high school I'd greatly expanded my portfolio of programming languages and was fairly regularly trying to reproduce the mechanics of games I played and enjoyed, or else wanted but couldn't afford.  And in undergrad I really lucked out and got to take a student-taught course on NES programming in a homebrew high-level Basic-oid language, which I followed with an engineering capstone project consisting of developing an NES on a prototyping board and learning 6502 Assembly code through literally recreating the chip itself from scratch.  Unfortunately, by the time I was well-versed in vintage console development, it was the mid-2000s and game development had changed, so I derailed into another industry as a profession but kept up an interest in and gradual absorption of classic gaming tech.

If you're looking for raw tech info, there are a host of specialized sites and hacking communities out there such as nesdev.parodius.com or Sonic Retro which will get increasingly approachable the more you learn about programming and computer architecture in general.

[quote]...since I've grown up in European boundaries, and since I'm clueless about the different versions and the technology behind it, I was wondering if you could clue me in what limits there are between EU, US and JP games and consoles.[/quote]

So far as the differences between regions, most consoles have some form of lockout that isn't so much a tech difference as an after-the-fact active impediment, which is why many games will run on foreign consoles with the help of bypass tools and simple modifications.  SNES in particular has physical design elements which prevent the insertion of foreign games, but can be bypassed with grinders or pliers (although a few games like Terranigma go a bit further and do a software check).  Genesis has a couple electrical jumpers on the motherboard which cartridge code can check against bytes in the game header to determine whether it should run.  Some Genesis models are easy to mod with a razorblade and soldering iron, I believe the Genesis 3 just agrees with whatever cart is put in it, and while I've failed at it myself, I've heard stories of success using Game Genie to spoof a cart's header bytes to match the console region.  Nintendo reconfigured the connector pinout between NES and Famicom, removing a few pins for direct audio output from the cartridge and shuffling the remaining data pins.  Cheap adapters will let you run NES games on a Famicom, and I think I caught wind at AGDQ that some NES boards still have pins to take a Fami cartridge socket, but I haven't actually checked this.

Either way, US and JP games are usually happy on the opposing system once you've tricked the lockout.  EU games (PAL) have an additional snag in that the vast majority of vintage consoles don't time off the CPU clock but rather off the television-frame vsync signal.  NTSC games expect a vblank every 1/60 second (but many only act on every other vblank, since each NTSC frame only carries half the scanlines).
[hidden]Technically, as an aside, NTSC full-framerate is 29.someodd fps because it was originally 30fps for black and white TV but they needed extra signal time to fit the chroma data for color so they slowed it down a little but still within the analog tolerance of B&W TVs so existing TVs could still show a good image.  Splitting the image into 2 half-frames at 60(-ish) likely had to do with the persistence time of early phosphor compounds and providing a cheap hack to allow more changes to the image per unit time.  WHich means today we get to deal with shitty deinterlacing artifacts whenever we try to record TV-type video to digital :P[/hidden]
PAL framerate is 25 full frames or 50 half-frames per second.  This means that NTSC-originating games not retuned for PAL will appear to run slowly on PAL, or conversely, PAL-sourced games not retuned for NTSC will appear to run fast on NTSC.  Worse still, as I can only assume is the case in Terranigma, if a PAL game fills every bit of the time between frames with CPU logic, then such a game if played on an NTSC frameclock would just frameskip to all heck, so it's probably for the best that some games have more explicit lockout.

Lone_Kilted_Ninja

2013-01-15 07:11:25 pm

Anything you can do I can do halfass

Quote:

Why do the ? blocks in the World 8 ships in SMB3 spin so fast?

I haven't done the disassembly, and don't care to, but I can put forward a strong theory.
NES graphics are built completely by arranging 8x8 tiles from one of at least 2 banks of 256 tiles each. Normally, one bank is used for sprites the other for background, but this can be changed on the fly to have either use either or both use the same bank.

To animate anything on the NES, you must change at least 1 of 3 things (and really, changing 1 is usually all it takes):
- the colors assigned to the palette used to draw a given background or sprite tile (e.g. waterfalls in many games, or MegaMan's charging and weapon switching)
- the tile index assigned to a background location or sprite
- the bitmap data comprising a given tile in the tile bank

Changing palettes is really quick and simple, but with the caveat that there are only 4 background palettes and 4 sprite palettes active at once, so changing the color of one thing will almost certainly change the color of something else (e.g. MegaMan always changes to the color of the weapon he fires (Plasma/buster shots use the face/lifebar palette)).

Changing the tile index of any one sprite or background location is fast enough, but changing more than about 64 at a time will consume enough CPU cycles to fill your ENTIRE frame, meaning you can't do that too heavily if you still want gameplay. (technically, there's an automated process to update all 64 sprites at once without using CPU, but no such luck for backgrounds)

Swapping fresh tiles into the bank can be fairly quick (since it doesn't actually copy data, it just connects a different segment of cartridge memory to the CHR tile-data pins), but without additional hardware, you've got to swap out the WHOLE BANK for another whole bank predefined in cart memory, so you really need to plan what art you'll need when.

Super Mario 3, however, has additional hardware. Namely, it has the MMC3 memory mapper which, like all memory mappers, literally assigns, or maps, new functionality to memory addresses which reside on the cartridge portion of the NES memory address space. The MMC3 provides things like extra video memory to allow both horizontal and vertical scrolling across a 4-screen-large chunk of background AND the ability to change what tiles are linked to the tile bank on a quarter-bank basis rather than bank-at-once.

For the sorts of animation like a rotating ?-block, tile-swappery is the only thing that will get the proper effect, unless you want to put all frames of an animation in your tile bank at the same time, which will both take up valuable bank space and mean you need to constantly rewrite your background. So I'm pretty darn sure SMB3 uses tile-swapping in and out of the bank to achieve background animation. But that also means that, even with MMC3, anything in the same quarter-bank will get swapped out at the same cadence, and thus appear to animate at the same rate. If I were the SMB3 developers, I'd say "hmmm… not everything in the level animates… really, only a few things in the level animate… so let's say that each level only has 1/4 of the tile bank cycling through, and any tiles that need to animate live in that same 1/4 bank so we don't need to clone all level art a million times or burn out the MMC3." Which would mean that the ? blocks live in the same quarter-bank as things like the shiny regular bricks, or background chomp-plants, or water-surface waves, or those useless little propellor thingies on the ships. And consequently, if the designers decided they really wanted to animate the waves or the propellors quickly, lo and behold all ? blocks in the same stage also animate quickly.

[quote]Why do the ? blocks in the World 8 ships in SMB3 spin so fast?[/quote]
I haven't done the disassembly, and don't care to, but I can put forward a strong theory.
NES graphics are built completely by arranging 8x8 tiles from one of at least 2 banks of 256 tiles each.  Normally, one bank is used for sprites the other for background, but this can be changed on the fly to have either use either or both use the same bank.

To animate anything on the NES, you must change at least 1 of 3 things (and really, changing 1 is usually all it takes):
- the colors assigned to the palette used to draw a given background or sprite tile (e.g. waterfalls in many games, or MegaMan's charging and weapon switching)
- the tile index assigned to a background location or sprite
- the bitmap data comprising a given tile in the tile bank

Changing palettes is really quick and simple, but with the caveat that there are only 4 background palettes and 4 sprite palettes active at once, so changing the color of one thing will almost certainly change the color of something else (e.g. MegaMan always changes to the color of the weapon he fires (Plasma/buster shots use the face/lifebar palette)).

Changing the tile index of any one sprite or background location is fast enough, but changing more than about 64 at a time will consume enough CPU cycles to fill your ENTIRE frame, meaning you can't do that too heavily if you still want gameplay.  (technically, there's an automated process to update all 64 sprites at once without using CPU, but no such luck for backgrounds)

Swapping fresh tiles into the bank can be fairly quick (since it doesn't actually copy data, it just connects a different segment of cartridge memory to the CHR tile-data pins), but without additional hardware, you've got to swap out the WHOLE BANK for another whole bank predefined in cart memory, so you really need to plan what art you'll need when.

Super Mario 3, however, has additional hardware.  Namely, it has the MMC3 memory mapper which, like all memory mappers, literally assigns, or maps, new functionality to memory addresses which reside on the cartridge portion of the NES memory address space.  The MMC3 provides things like extra video memory to allow both horizontal and vertical scrolling across a 4-screen-large chunk of background AND the ability to change what tiles are linked to the tile bank on a quarter-bank basis rather than bank-at-once.

For the sorts of animation like a rotating ?-block, tile-swappery is the only thing that will get the proper effect, unless you want to put all frames of an animation in your tile bank at the same time, which will both take up valuable bank space and mean you need to constantly rewrite your background.  So I'm pretty darn sure SMB3 uses tile-swapping in and out of the bank to achieve background animation.  But that also means that, even with MMC3, anything in the same quarter-bank will get swapped out at the same cadence, and thus appear to animate at the same rate.  If I were the SMB3 developers, I'd say "hmmm… not everything in the level animates… really, only a few things in the level animate… so let's say that each level only has 1/4 of the tile bank cycling through, and any tiles that need to animate live in that same 1/4 bank so we don't need to clone all level art a million times or burn out the MMC3."  Which would mean that the ? blocks live in the same quarter-bank as things like the shiny regular bricks, or background chomp-plants, or water-surface waves, or those useless little propellor thingies on the ships.  And consequently, if the designers decided they really wanted to animate the waves or the propellors quickly, lo and behold all ? blocks in the same stage also animate quickly.

Lone_Kilted_Ninja

2013-01-15 07:18:31 pm

Anything you can do I can do halfass

This one blew by so fast in streamchat I'm not sure I caught it properly, but I think it was along the lines of

Quote:

Why do some Bowser statues in SMB3 fire lasers, but others which look like they should actually don't?

Because the visuals and the game logic are not necessarily connected. In some places, the designers put statue art in the background and put a Fire Teh Lazars object at the statue's mouth ("object" in lack of a better term for a thing that is not background, sprite, or even a visible or tangible thing at all so much as a game-programming-specific logical specification that things should happen in association with a given location). In some places they just put the statue art in the background to look intimidating because psychologically the thing that you know may or may not happen is often scarier than the thing you have absolute certainty will happen Smiley

Countneko

2013-01-15 07:34:10 pm

Oh hey, I asked those questions. Thanks for your detailed replies here. :3

It seems like you've really studied the NES a lot, and here I thought I knew a thing or two about how video games work. XD

Qwarq

2013-01-15 08:32:31 pm

Old game console hardware is really fascinating once you start looking at the details. The architectures are so much different than modern computers that it's like being back in Programming 101 when you start developing on them.

I've been working on my own Gameboy rerecording emulator for a little while now, and it's been an amazingly fun and enlightening project. I've noticed there's a lot of overlap in the GB and NES architecture (not surprising, since they're both from Nintendo), but there's one thing I've never heard a solid answer for:

In some early NES games like Final Fantasy, what was the point of holding the reset button when turning off the console to save your data?

Countneko

2013-01-15 09:42:49 pm

Quote from Qwarq:

In some early NES games like Final Fantasy, what was the point of holding the reset button when turning off the console to save your data?

He'll probably provide a better answer than me, but I think it had something to do with flushing the RAM out so that nothing could write to the save data while you were turning it off so you didn't risk corruption.

Alko

2013-01-16 12:03:07 pm

Caution: This user contains Kana ^_^

Quote from Lone_Kilted_Ninja:

Either way, US and JP games are usually happy on the opposing system once you've tricked the lockout. EU games (PAL) have an additional snag in that the vast majority of vintage consoles don't time off the CPU clock but rather off the television-frame vsync signal. NTSC games expect a vblank every 1/60 second (but many only act on every other vblank, since each NTSC frame only carries half the scanlines).

Technically, as an aside, NTSC full-framerate is 29.someodd fps because it was originally 30fps for black and white TV but they needed extra signal time to fit the chroma data for color so they slowed it down a little but still within the analog tolerance of B&W TVs so existing TVs could still show a good image. Splitting the image into 2 half-frames at 60(-ish) likely had to do with the persistence time of early phosphor compounds and providing a cheap hack to allow more changes to the image per unit time. WHich means today we get to deal with shitty deinterlacing artifacts whenever we try to record TV-type video to digital Tongue

At least I can help you on this one ^^
The reason for splitting TV frames into half-frames has to do with flickering and how the eye perceives it. Everything that is faster than approx. 16 fps is recognised as a moving picture (as opposed to static interchanging pictures), so one might think 16 fps to be enough for a television broadcast. However, the higher the framerate the less flickering is perceived. Early televisions now also had to deal with the problem of low transfer bandwith (if you want to call it that) so they were looking for an easy way to increase framerates while not needing to increase data sent. The ideal solution was to build up TV pictures at 60 half-frames (where the power grid had a frequency of 60 Hz) or 50 half-frames per second (where the power comes in 50 Hz), resulting in an effective 30/25 fps framerate when looking at transferred data and an effective 60/50 fps framerate when dealing with flickering.

[quote="Lone_Kilted_Ninja"]Either way, US and JP games are usually happy on the opposing system once you've tricked the lockout.  EU games (PAL) have an additional snag in that the vast majority of vintage consoles don't time off the CPU clock but rather off the television-frame vsync signal.  NTSC games expect a vblank every 1/60 second (but many only act on every other vblank, since each NTSC frame only carries half the scanlines).

Technically, as an aside, NTSC full-framerate is 29.someodd fps because it was originally 30fps for black and white TV but they needed extra signal time to fit the chroma data for color so they slowed it down a little but still within the analog tolerance of B&W TVs so existing TVs could still show a good image.  Splitting the image into 2 half-frames at 60(-ish) likely had to do with the persistence time of early phosphor compounds and providing a cheap hack to allow more changes to the image per unit time.  WHich means today we get to deal with shitty deinterlacing artifacts whenever we try to record TV-type video to digital :P[/quote]
At least I can help you on this one ^^
The reason for splitting TV frames into half-frames has to do with flickering and how the eye perceives it. Everything that is faster than approx. 16 fps is recognised as a moving picture (as opposed to static interchanging pictures), so one might think 16 fps to be enough for a television broadcast. However, the higher the framerate the less flickering is perceived. Early televisions now also had to deal with the problem of low transfer bandwith (if you want to call it that) so they were looking for an easy way to increase framerates while not needing to increase data sent. The ideal solution was to build up TV pictures at 60 half-frames (where the power grid had a frequency of 60 Hz) or 50 half-frames per second (where the power comes in 50 Hz), resulting in an effective 30/25 fps framerate when looking at transferred data and an effective 60/50 fps framerate when dealing with flickering.

Lone_Kilted_Ninja

Edit history:

Lone_Kilted_Ninja: 2013-01-18 09:11:50 pm

Lone_Kilted_Ninja: 2013-01-18 09:10:40 pm

2013-01-16 07:47:24 pm

Anything you can do I can do halfass

Quote from Alko:

The reason for splitting TV frames into half-frames has to do with flickering and how the eye perceives it. Everything that is faster than approx. 16 fps is recognised as a moving picture (as opposed to static interchanging pictures), so one might think 16 fps to be enough for a television broadcast. However, the higher the framerate the less flickering is perceived. Early televisions now also had to deal with the problem of low transfer bandwith (if you want to call it that) so they were looking for an easy way to increase framerates while not needing to increase data sent. The ideal solution was to build up TV pictures at 60 half-frames (where the power grid had a frequency of 60 Hz) or 50 half-frames per second (where the power comes in 50 Hz), resulting in an effective 30/25 fps framerate when looking at transferred data and an effective 60/50 fps framerate when dealing with flickering.

Valid points as well. Although timing off the wall A/C... *shudder* oh, the hackage engineers felt compelled to resort to... But of course, there's also no flickering if an image updates even at low-fps without fading to blank, so phosphor chemistry and figuring out how to refresh an image while some image was still visible did likely lead to interleaving as opposed to, say, top-half/bottom-half frames.

Quote from Qwarq:

In some early NES games like Final Fantasy, what was the point of holding the reset button when turning off the console to save your data?

Countneko's note on RAM flushing is generally right for one part of the problem- by holding Reset, the Program Counter (the specific point in code being executed) is forced to jump to and stay at a fixed address after the most recent instruction finishes executing. ~~Some~~ all instructions take multiple cycles and ~~would~~ may be potentially dangerous to interrupt, so holding reset guarantees that you aren't in the middle of changing the data in memory when the power cuts out.

Another part of the problem on older carts is likely how the battery-backed RAM chips are fabricated and patched into the address space. They exist in a defined region of cartridge memory, but are necessarily a separate piece of hardware. When you get back into early digital systems, analog timing is of ever greater concern. Clock speeds were (and indeed still are, just at a much more sophisticated level) limited by how quickly the analog voltages making up digital signals could propagate along the wires/traces, and how long a voltage level had to be held at the input to a chip before the chip could register a value change. Active, constantly-refreshing battery-backed RAM chips were probably (a) laggy as heck and (b) had specific timings on when they could even receive new data, so keeping the system energized for a fraction of a second after the last attempt to read/write the battery-backed memory chip would ensure that voltage levels had time to stabilize and that any data "on the lines" or in e.g. memory interface/buffer registers waiting to get into the chip was properly received by the chip.

[quote="Alko"]The reason for splitting TV frames into half-frames has to do with flickering and how the eye perceives it. Everything that is faster than approx. 16 fps is recognised as a moving picture (as opposed to static interchanging pictures), so one might think 16 fps to be enough for a television broadcast. However, the higher the framerate the less flickering is perceived. Early televisions now also had to deal with the problem of low transfer bandwith (if you want to call it that) so they were looking for an easy way to increase framerates while not needing to increase data sent. The ideal solution was to build up TV pictures at 60 half-frames (where the power grid had a frequency of 60 Hz) or 50 half-frames per second (where the power comes in 50 Hz), resulting in an effective 30/25 fps framerate when looking at transferred data and an effective 60/50 fps framerate when dealing with flickering.[/quote]
Valid points as well.  Although timing off the wall A/C... *shudder* oh, the hackage engineers felt compelled to resort to...  But of course, there's also no flickering if an image updates even at low-fps without fading to blank, so phosphor chemistry and figuring out how to refresh an image while some image was still visible did likely lead to interleaving as opposed to, say, top-half/bottom-half frames.

[quote="Qwarq"]In some early NES games like Final Fantasy, what was the point of holding the reset button when turning off the console to save your data?[/quote]

Countneko's note on RAM flushing is generally right for one part of the problem- by holding Reset, the Program Counter (the specific point in code being executed) is forced to jump to and stay at a fixed address after the most recent instruction finishes executing.  [s]Some[/s] all instructions take multiple cycles and [s]would[/s] may be potentially dangerous to interrupt, so holding reset guarantees that you aren't in the middle of changing the data in memory when the power cuts out.

Another part of the problem on older carts is likely how the battery-backed RAM chips are fabricated and patched into the address space.  They exist in a defined region of cartridge memory, but are necessarily a separate piece of hardware.  When you get back into early digital systems, analog timing is of ever greater concern.  Clock speeds were (and indeed still are, just at a much more sophisticated level) limited by how quickly the analog voltages making up digital signals could propagate along the wires/traces, and how long a voltage level had to be held at the input to a chip before the chip could register a value change.  Active, constantly-refreshing battery-backed RAM chips were probably (a) laggy as heck and (b) had specific timings on when they could even receive new data, so keeping the system energized for a fraction of a second after the last attempt to read/write the battery-backed memory chip would ensure that voltage levels had time to stabilize and that any data "on the lines" or in e.g. memory interface/buffer registers waiting to get into the chip was properly received by the chip.

General Vagueness

2013-01-17 10:31:51 am

Faster than the speed of love

I just wanted to say ~~good luck~~ interesting stuff all around.

Countneko

2013-02-14 12:38:14 pm

If you're still keeping up with this topic, something else came to mind: Why does the NES have 72 pin cartridges and the Famicom has only 60? Is it purely a region lockout feature, or was there some other reason they did it? What do all of those extra pins do?

Alko

2013-02-14 12:58:24 pm

Caution: This user contains Kana ^_^

If I may expand: What do all those pins do anyway, and what's it like compared with SNES/Super Famicom?

Countneko

2013-02-14 01:00:46 pm

Quote from Alko:

If I may expand: What do all those pins do anyway, and what's it like compared with SNES/Super Famicom?

I was pretty certain both systems were functionally the same apart from tabs they put in intended to block import games that you can just cut off anyway.

Lone_Kilted_Ninja

2013-02-25 07:11:24 pm

Anything you can do I can do halfass

Hokay. I go off and make a new video for a couple weeks and you guys come back with questions... splendid. Need to keep better track of this.

Anyway... pin numbering... I'm'a' need to re-research and transcribe into layman's terms or just totally steal depending on how clear the docs are... *re-researches*
...
credit to http://www.benheck.com/Downloads/NES_Famicom_Pinouts.pdf , but I'll still go over what it ~means~:
My first reflex was that the Famicom should have more useful pins than the NES because the Fami has some pass-through pins that allow the cartridge to pipe sound directly to the console audio output (which is how games like CV3 and others have crazy awesome music in the Japanese releases, and why you can get adapters to run NES carts on a Famicom but not the other way around). But according to the pinout, the 12 pin difference between the connectors is due to
+4 pins on the NES for a lockout chip (I don't know offhand what the lockout chip checks for)
+10 pins on the NES for... wheeeeewwwww... so THAT'S how you get at those! Iiinteresting. Never knew that. Anyway, +10 pins on the NES passed through to the top secret connector behind the little pop-out plastic cover on the bottom of the model 1 (frontloader) NES. Presumably, this would have allowed games that cared to connect them to anything cartridge-side to interface with additional processing or output hardware accessories. In theory it would have allowed not only direct audio do be driven from the cartridge, but also possibilities for Sega 32x-like communication with more powerful processors, FDS-like connection with external media, or N64-like memory expansion. In fact... since 2 of the NES expansion pins are indexed to what used to be Famicom audio pins, it stands to reason that a suitable adapter accounting for those pin mappings, coupled with a speaker wired the right way to the expansion port might even allow playback of Famicom extra audio channels on NES, albeit in a very roundabout way... May need to try that sometime. Anyway. I ramble. Point is, the expansion port never really got used for anything at all whatsoever.
-2 pins on the NES removing both the drive-custom-audio function and the read-the-Famicom-microphone function.

More generally, all those pins labelled PRG and CHR A and D are in similar theory to cartridges on most systems. The connection is what is called a "parallel" interface, meaning that the entire numeric address of the desired memory location is provided at one time, and the entire numeric value being read/written to the memory is provided at one time. The "A" pins are "address" pins, and if you count, there are a few less than 16 of them for both PRG and CHR. Technically, the "address space" of the NES is 16-bit (that is, there are 2^16 distinct locations that can be read/written), but the NES is a "memory mapped" architecture, meaning that things like RAM, peripheral input/output, and control of the sound and graphics chips are all assigned specific addresses in memory. As a result, the address range available for use in storing/accessing the game program is less than the full 16-bit space.

The NES, furthermore (and unlike contemporary PC architectures) has 2 independent memory busses- PRG and CHR. PRG is connected exclusively between the CPU and Program memory (executable code and game data), while CHR is connected directly to the graphics chip and the memory containing the Character bitmap tiles from which all game graphics are built. This means the CPU can just tell the graphics chip how to do its thing using what tile addresses and the graphics chip will get on with it without the CPU needing to burn valuable cycles playing go-between. It also results in cute things like the… Rygar?… "Atari mode" glitch from a few marathons ago: the PRG bus was nice and clean, so the code could execute, could lay out tile indices onscreen, color them nicely, etc… but something was gumming up the CHR bus so no actual bitmaps were getting through. As a result, everything rendered as solid-color squares.

The D pins are Data, and there are 8 of them on each bus. 8-bit processor. All data values are single bytes. The CPU and PPU (Pixel Processing Unit; graphics chip) put the desired address on the Address lines for one cycle, and the next cycle, if the operation is a "write" to memory, the 1-byte value on the Data lines is stored there (if that location is electrically writeable), if the operation is a "read," the value at that location in memory is placed by the cartridge on the Data lines and the CPU/PPU will be able to see and use it.

There are a few other pins used as flags- RD and WR specify whether the current direction of transfer is read or write, CE is a behavior flag for which chunk of graphics memory to access, and IRQ and [null]2 provide useful hotlines from the cartridge direct to the CPU to manage certain behaviors and alert to useful or unusual events. Clock is just that- a regular pulse that delineates operations and when the cart should look for Addresses to have changed and when the NES should look for Data to have changed.

"But then shouldn't newer consoles with more memory and more bits have more pins?"
Not always. The faster a processor can run, the more cycles it can spare to access data. As a result, it is technically possible to send addresses and data just a few bits per clock tick over a series of multiple clock ticks. You could, for instance, design an architecture in which it was possible to retrieve a 16-bit value from a 32-bit memory space using only 8 pins total by setting up an understanding that on any given transaction, the address would be put on the pins, 8 bits at a time, for 4 ticks (4x8=32), after which the data value would be returned on the same pins over the next 2 ticks (2x8=16). This approaches a full "serial" connection in which there may only be 1 or 2 pins, and both the address/command and the data are delivered 1 bit at a time. This is actually how the control pad works: for 8 buttons, you'd expect that maybe there would be 8 pins (or 9 including a common ground, or 10 to run dedicated power, or 16 if each line had its own return, or…), but if you look, there are only 7 on the NES, and the SNES with 4 more buttons still has 7, and Gamecube has 6 and is doing f'ing analog shit, and… But no. What you're actually seeing is along the lines of
- 1 pin dedicated power
- 1 pin common ground
- 1 pin clock
- 1 pin data
- 1 pin "latch"
- [some other stuff]
wherein the "latch" is held for one clock tick to tell the controller to reset, and then every subsequent clock tick the 0/1 status of a single button is returned. Controllers like the light gun only really have 2 bits to return (trigger, optical sensor); the Power Pad and Power Glove have considerably more, and in theory, if you're willing to wait for enough cycles, just about anything can be chained through a suitable multi-tap which serves little other purpose than to concatenate the bits from multiple devices into a single longer bitstring.

So in theory you could put an entire game on a memory unit with only 5-ish pins and not be tremendously inconvenienced so long as you had a fast clock. In practice, this is called USB and you already do Wink

Hokay.  I go off and make a new video for a couple weeks and you guys come back with questions... splendid.  Need to keep better track of this.

Anyway... pin numbering... I'm'a' need to re-research and transcribe into layman's terms or just totally steal depending on how clear the docs are... *re-researches*
...
credit to http://www.benheck.com/Downloads/NES_Famicom_Pinouts.pdf , but I'll still go over what it ~means~:
My first reflex was that the Famicom should have [i]more[/i] useful pins than the NES because the Fami has some pass-through pins that allow the cartridge to pipe sound directly to the console audio output (which is how games like CV3 and others have crazy awesome music in the Japanese releases, and why you can get adapters to run NES carts on a Famicom but not the other way around).  But according to the pinout, the 12 pin difference between the connectors is due to
[b]+4 pins[/b] on the NES for a lockout chip (I don't know offhand what the lockout chip checks for)
[b]+10 pins [/b]on the NES for... wheeeeewwwww... so THAT'S how you get at those!  Iiinteresting.  Never knew that.  Anyway, +10 pins on the NES passed through to the top secret connector behind the little pop-out plastic cover on the bottom of the model 1 (frontloader) NES.  Presumably, this would have allowed games that cared to connect them to anything cartridge-side to interface with additional processing or output hardware accessories.  In theory it would have allowed not only direct audio do be driven from the cartridge, but also possibilities for Sega 32x-like communication with more powerful processors, FDS-like connection with external media, or N64-like memory expansion.  In fact... since 2 of the NES expansion pins are indexed to what used to be Famicom audio pins, it stands to reason that a suitable adapter accounting for those pin mappings, coupled with a speaker wired the right way to the expansion port might even allow playback of Famicom extra audio channels on NES, albeit in a very roundabout way...  May need to try that sometime.  Anyway.  I ramble.  Point is, the expansion port never really got used for anything at all whatsoever.
[b]-2 pins[/b] on the NES removing both the drive-custom-audio function and the read-the-Famicom-microphone function.

More generally, all those pins labelled PRG and CHR A and D are in similar theory to cartridges on most systems.  The connection is what is called a "parallel" interface, meaning that the entire numeric address of the desired memory location is provided at one time, and the entire numeric value being read/written to the memory is provided at one time.  The "A" pins are "address" pins, and if you count, there are a few less than 16 of them for both PRG and CHR.  Technically, the "address space" of the NES is 16-bit (that is, there are 2^16 distinct locations that can be read/written), but the NES is a "memory mapped" architecture, meaning that things like RAM, peripheral input/output, and control of the sound and graphics chips are all assigned specific addresses in memory.  As a result, the address range available for use in storing/accessing the game program is less than the full 16-bit space.

The NES, furthermore (and unlike contemporary PC architectures) has 2 independent memory busses- PRG and CHR.  PRG is connected exclusively between the CPU and Program memory (executable code and game data), while CHR is connected directly to the graphics chip and the memory containing the Character bitmap tiles from which all game graphics are built.  This means the CPU can just tell the graphics chip how to do its thing using what tile addresses and the graphics chip will get on with it without the CPU needing to burn valuable cycles playing go-between.  It also results in cute things like the… Rygar?… "Atari mode" glitch from a few marathons ago: the PRG bus was nice and clean, so the code could execute, could lay out tile indices onscreen, color them nicely, etc… but something was gumming up the CHR bus so no actual bitmaps were getting through.  As a result, everything rendered as solid-color squares.

The D pins are Data, and there are 8 of them on each bus.  8-bit processor.  All data values are single bytes.  The CPU and PPU (Pixel Processing Unit; graphics chip) put the desired address on the Address lines for one cycle, and the next cycle, if the operation is a "write" to memory, the 1-byte value on the Data lines is stored there (if that location is electrically writeable), if the operation is a "read," the value at that location in memory is placed by the cartridge on the Data lines and the CPU/PPU will be able to see and use it.

There are a few other pins used as flags- RD and WR specify whether the current direction of transfer is read or write, CE is a behavior flag for which chunk of graphics memory to access, and IRQ and [null]2 provide useful hotlines from the cartridge direct to the CPU to manage certain behaviors and alert to useful or unusual events.  Clock is just that- a regular pulse that delineates operations and when the cart should look for Addresses to have changed and when the NES should look for Data to have changed.

"But then shouldn't newer consoles with more memory and more bits have more pins?"
Not always.  The faster a processor can run, the more cycles it can spare to access data.  As a result, it is technically possible to send addresses and data just a few bits per clock tick over a series of multiple clock ticks.  You could, for instance, design an architecture in which it was possible to retrieve a 16-bit value from a 32-bit memory space using only 8 pins total by setting up an understanding that on any given transaction, the address would be put on the pins, 8 bits at a time, for 4 ticks (4x8=32), after which the data value would be returned on the same pins over the next 2 ticks (2x8=16).  This approaches a full "serial" connection in which there may only be 1 or 2 pins, and both the address/command and the data are delivered 1 bit at a time.  This is actually how the control pad works: for 8 buttons, you'd expect that maybe there would be 8 pins (or 9 including a common ground, or 10 to run dedicated power, or 16 if each line had its own return, or…), but if you look, there are only 7 on the NES, and the SNES with 4 more buttons still has 7, and Gamecube has 6 and is doing f'ing analog shit, and… But no.  What you're actually seeing is along the lines of
- 1 pin dedicated power
- 1 pin common ground
- 1 pin clock
- 1 pin data
- 1 pin "latch"
- [some other stuff]
wherein the "latch" is held for one clock tick to tell the controller to reset, and then every subsequent clock tick the 0/1 status of a single button is returned.  Controllers like the light gun only really have 2 bits to return (trigger, optical sensor); the Power Pad and Power Glove have considerably more, and in theory, if you're willing to wait for enough cycles, just about anything can be chained through a suitable multi-tap which serves little other purpose than to concatenate the bits from multiple devices into a single longer bitstring.

So in theory you could put an entire game on a memory unit with only 5-ish pins and not be tremendously inconvenienced so long as you had a fast clock.  In practice, this is called USB and you already do ;)

Lone_Kilted_Ninja

2013-02-25 07:14:07 pm

Anything you can do I can do halfass

Quote from Countneko:

Quote from Alko:

If I may expand: What do all those pins do anyway, and what's it like compared with SNES/Super Famicom?

I was pretty certain both systems were functionally the same apart from tabs they put in intended to block import games that you can just cut off anyway.

My understanding and experience is that the SNES and SFami connectors are in fact the same, and Nintendo resorted to a much lower-tech means of enforcing lockout; namely the stupid plastic tabs. But there's evidently some indication which the cartridge and/or the system can provide of what region they're supposed to be, so that games which care can know not to run. I seem to recall discussing this, specifically w/r/t NTSC vs PAL and e.g. Terranigma, probably earlier in this thread but I'm too lazy to check.

Lone_Kilted_Ninja

Edit history:

Lone_Kilted_Ninja: 2013-04-04 08:44:52 pm

Lone_Kilted_Ninja: 2013-04-04 08:43:04 pm

2013-03-22 08:06:04 pm

Anything you can do I can do halfass

Quote from Lone_Kilted_Ninja:

"Hmmm... how does the Virtual Boy work?"

Why, I'm so glad I asked. Through hours of ongoing research, it is my official provisional determination that the VB works by giving you a migraine. A joyful, joyful, migraine. Whether you are a player or a developer.

In related news, some months ago I was lucky enough to snag a VB flashcart. And now, thanks to the forum folks over at www.macscene.net , I have a tech doc containing, near as I can tell, everything I need to begin contemplating VB homebrews, or at least answering tech questions and continuing to more accurately BS how the systems ~between~ NES and VB probably do their stuff. My initial reactions, provided for your entertainment (follow along at home: http://www.planetvb.com/content/downloads/documents/stsvb.html ):

Virtual Image Processor (VIP)
Soooo... 32 "layers" which, while drawn back-to-front, can have independent depth parallax unrelated to their order, and in which "sprites", if used, can have depth parallax unrelated to the layer. The ratio of possible ways to use this power which result in headaches to possible ways that manage not to is... staggeringly large. o.o;

oh, and also, "layer" is a gross generalization. The region within each "layer" (i.e. the Window) that is drawn to has one depth value, but the tile contents of the Window (i.e. the Window Background) can have their own depth value. So you can... define a Window that floats in front of other stuff, with content that occludes but appears recessed behind... this... is dangerous. They should never have allowed me access to this document. ^_^ MWAHAHAHAHAA.

VIP Window Mode: Line Shift
Ye Gods... this functionality... I always knew players could get giddy migraines from VB. I can already see devs getting giddy migraines from the functionality available. And the graphics chip designers... to implement some of these features... yeah. Pixels addressed/drawn in column-major order with possible interrupts per column, tiles/chunks addressed in row-major, but added functionality to bake horizontal raster effects into the draw config for each layer...

VIP Window Mode: Affine
...That... is how I do "Mode 7" rotation...? Ugh. UGH. ... When can I start? Cheesy

VIP Column Table
What... I... what POSSIBLE good can come of allowing the programmer, at the application-level, to software-control the calibration of pixel delivery to the mirror during each display sweep? Sure! Go ahead! Make each screen independently horizontal-fisheyed! Do some bizarre counter-parallaxing! While you're at it, change the LED duty cycles for each eye independently! It's not like you were given general brightness control registers for any particular reason! >.<#

In fact, "Nintendo supplies a default column table for developers. In normal situations, this will never need to be changed" - SO WHY LET THEM CHANGE IT?!

... Really, I can't even be evil with this thing without risking fubaring the whole render timing, and maybe even the hardware Sad

Version Register
"Indicates the hardware version of the VIP, which can be used to determine what features are available. There was only ever one model of the Virtual Boy produced, and its version is 2."
And now you know.

Virtual Sound Unit (VSU)
Ooh! 6-channel chiptune! Figured as much. But channel 5 Modulation function... ow... my maths...

VSU Noise Generator
"The Virtual Boy noise generator is a 15-bit linear feedback shift register with a configurable tap location. ... The shift register is 15 bits wide and is initialized to all 1s. When a bit is produced as noise, two bits from the shift register are XORed together. One of the bits is bit 7, and the other bit is the bit specified by Tap Location. The inverse of the result (0 becomes 1 and vice/versa) is used as the output. The entire register is then shifted to the left one bit, and the result of the earlier XOR operation (not inverted) becomes the new bit 0. ... The {output} bit is then scaled to 6 bits to be the same size as the samples of the other sound channels. That is to say, if a 0 is generated, the sample is 0; and if a 1 is generated, the sample is 63."
That simple, eh?

That's it. I need a drink. Come back in a few days and maybe I'll have stomached the rest of the doc. That said, this little red powerhouse is rapidly rising in my list of underappreciated vintage hardware...

Edit: Sparing everyone a second post...
Data Types and Conventions
Oooohhh- 32-bit computation! Dedicated support/opcodes for ints, floats AND arbitrary-length bitstrings! But… they're talking like I still get to do it all in assembly. I… ye gods, this is… it ~is~ a 32-bit processor with the implicit expectation that the programmer works in assembly. … I suppose it could be worse. I suppose it could be x86. I'm still kinda depressed from what I remember of my brief investigation into the WonderSwan CPU Tongue

Instruction Formats
So… 16- or 32-bit instructions, with 32-bit arithmentic/logical ops, but since the full instructions are no more than 32-bits, immediates can only be 16-bit. Meaning long-distance jumps and absolute loads/stores are made using a register containing a 32-bit address, and a 16-bit immediate offset from that address. That… it's like… using the most awkward NES addressing mode as your STANDARD MODUS OPERANDI!! And yet… makes such perfect sense. *whimper*

Memory and Register Transfers
… and wait… there are typical MOV instructions to get data in and out of registers, but quick integer addition is performed via variants of the MOV instructions rather than dedicated ADD instructions, and further there are MOV instructions to add to either the low halfword or the high halfword of a register, because…? … *facepalm* 32-bit values. 16-bit immediates. They aren't being convoluted, they're just providing the perfectly sensible tools to put a 32-bit value in a register the only way one could ever expect to- convolutedly!

… even having just explained it to myself, the load/store operations still make my brain cry. To paraphrase, "register 2 equals the zero-extended value at an address computed by adding the 16-bit immediate to the 32-bit value in register 1, but only if you're accessing CPU memory, otherwise sign-extend the value." But… ooh! Pipelined architecture! Nice.
Silly Editor- "many" probably is dependent on the precise type of instruction and the instruction context. The fact that the longest execution is 5 cycles suggests that there are 5 sub-stages in the pipeline. If I had to hazard a guess, they'd be along the lines of {compute source} -> {retrieve data} -> {do math/logic} -> {compute destination} -> {store data}. So if instruction 1 reads from location A and writes to location B and instruction 2 reads from location C and writes to location D, then the two can be fully pipelined and execute in 6 cycles:

1. {compute source of 1 (A)}
2. {retrieve data at A} + {compute source of 2 (C)}
3. {do maths 1 on data from A} + {retrieve data at C}
4. {compute destination of 1 (B)} + {do maths 2 on data from C}
5. {store result 1 in B} + {compute destination of 2 (D)}
6. {store result 2 in D}

but if instruction 2 needs to read from B and store to D, then you need a few more steps:

1. {compute source of 1 (A)}
2. {retrieve data at A} + {compute source of 2 (B)}
3. {do maths 1 on data from A} + {retrieve data at B}
4. {compute destination of 1 (B)} + {do maths 2 on data from B}
5. {store result 1 in B} + { Oops, I guess what we retrieved from B isn't right- need to retrieve it again. But… dammit, the memory bus is already in use because instruction 1 is storing its result. Twiddle our digital thumbs! }
6. {NOW we can retrieve the CORRECT data at B}
7. {redo maths on 2 on CORRECT data from B}
8. {compute destination of 2 (D)}
9. {store result 2 in D}

And… okay. I get the need to have more than just an accumulator register when the set of arithmetic ops is more than just ADD and CMP. Why you decide to still use the numeric register IDs rather than more explicit names by purpose, yielding a non-contiguous list of extant registers r0-r31… *headshake* Engineers…

About Bitstring Instructions
…Lovely. Instructions which take probably-a-shitton of cycles and use registers as their own private internal state. … Once again because it's completely sensible and allows things like conditional breaking-out mid-instruction. … Which furthermore means assembly-level instructions are not necessarily atomic. … *sob*

List of Bit String Instructions
XORNBSU! XORNBSU!!!! XORNBSUUUUUUUUUU!!!! … What is this? Opcode naming auf Deutsch? Condense a whole sentence into a single opcode? I suppose at least I can pronounce that one. Unlike its close cousin ANDNBSU. Can I use NNBSU as an alternative to NOP?

Great googlay mooglay… the cycle count for bitstring ops… is an algorithm >.<;

CPU Miscellaneous Instructions
CAXI…? I prefer denim, but… wait, that isn't…? This is going to give me more of a headache, isn't it?
…
Multiprocessor synchronization. What the who how? There isn't even… Unless you can… … I don't want to know. I could go my whole life without knowing, and be perfectly happy. … Except now I know that I don't know, which means I need to know. Dammit. *reads further*
Okay, so there IS only one CPU. And CAXI is thus a glorified thunk. Not sure whether to be disappointed or relieved.

Whew. This console... This Console. It may only be a matter of time before I have to try developing something in earnest. So much cool stuff to play with, so may ways to get a migraine, so many more to give one ^_^ ~~Guinnea pigs~~ Playtesters for AGDQ14? Anyone?

[quote="Lone_Kilted_Ninja"]"Hmmm... how does the Virtual Boy work?"[/quote]
Why, I'm so glad I asked.  Through hours of ongoing research, it is my official provisional determination that the VB works by giving you a migraine.  A joyful, joyful, migraine.  Whether you are a player or a developer.

In related news, some months ago I was lucky enough to snag a VB flashcart.  And now, thanks to the forum folks over at www.macscene.net , I have a tech doc containing, near as I can tell, everything I need to begin contemplating VB homebrews, or at least answering tech questions and continuing to more accurately BS how the systems ~between~ NES and VB probably do their stuff.  My initial reactions, provided for your entertainment (follow along at home: http://www.planetvb.com/content/downloads/documents/stsvb.html ):

[b]Virtual Image Processor (VIP)[/b]
Soooo... 32 "layers" which, while drawn back-to-front, can have independent depth parallax unrelated to their order, and in which "sprites", if used, can have depth parallax unrelated to the layer. The ratio of possible ways to use this power which result in headaches to possible ways that manage not to is... staggeringly large. o.o;

oh, and also, "layer" is a gross generalization. The region within each "layer" (i.e. the Window) that is drawn to has one depth value, but the tile contents of the Window (i.e. the Window Background) can have their own depth value. So you can... define a Window that floats in front of other stuff, with content that occludes but appears recessed behind... this... is dangerous. They should never have allowed me access to this document. ^_^ MWAHAHAHAHAA.

[b]VIP Window Mode: Line Shift[/b]
Ye Gods... this functionality... I always knew players could get giddy migraines from VB. I can already see devs getting giddy migraines from the functionality available. And the graphics chip designers... to implement some of these features... yeah. Pixels addressed/drawn in column-major order with possible interrupts per column, tiles/chunks addressed in row-major, but added functionality to bake horizontal raster effects into the draw config for each layer...

[b]VIP Window Mode: Affine[/b]
...That... is how I do "Mode 7" rotation...? Ugh. UGH. ... When can I start? :D

[b]VIP Column Table[/b]
What... I... what POSSIBLE good can come of allowing the programmer, at the application-level, to software-control the calibration of pixel delivery to the mirror during each display sweep? Sure! Go ahead! Make each screen independently horizontal-fisheyed! Do some bizarre counter-parallaxing! While you're at it, change the LED duty cycles for each eye independently! It's not like you were given general brightness control registers for any particular reason! >.<#

In fact, "Nintendo supplies a default column table for developers. In normal situations, this will never need to be changed" - SO WHY LET THEM CHANGE IT?!

... Really, I can't even be evil with this thing without risking fubaring the whole render timing, and maybe even the hardware :(

[b]Version Register[/b]
"Indicates the hardware version of the VIP, which can be used to determine what features are available. There was only ever one model of the Virtual Boy produced, and its version is 2." 
[i]And now you know.[/i]

[b]Virtual Sound Unit (VSU)[/b]
Ooh! 6-channel chiptune!  Figured as much.  But channel 5 Modulation function... ow... my maths...

[b]VSU Noise Generator[/b]
"The Virtual Boy noise generator is a 15-bit linear feedback shift register with a configurable tap location. ... The shift register is 15 bits wide and is initialized to all 1s. When a bit is produced as noise, two bits from the shift register are XORed together. One of the bits is bit 7, and the other bit is the bit specified by Tap Location. The inverse of the result (0 becomes 1 and vice/versa) is used as the output. The entire register is then shifted to the left one bit, and the result of the earlier XOR operation (not inverted) becomes the new bit 0. ... The {output} bit is then scaled to 6 bits to be the same size as the samples of the other sound channels. That is to say, if a 0 is generated, the sample is 0; and if a 1 is generated, the sample is 63."
That simple, eh?

That's it.  I need a drink.  Come back in a few days and maybe I'll have stomached the rest of the doc.  That said, this little red powerhouse is rapidly rising in my list of underappreciated vintage hardware...

[i]Edit: Sparing everyone a second post...[/i]
[b]Data Types and Conventions[/b]
Oooohhh- 32-bit computation!  Dedicated support/opcodes for ints, floats AND arbitrary-length bitstrings!  But… they're talking like I still get to do it all in assembly.  I… ye gods, this is… it ~is~ a 32-bit processor with the implicit expectation that the programmer works in assembly.  …  I suppose it could be worse.  I suppose it could be x86.  I'm still kinda depressed from what I remember of my brief investigation into the WonderSwan CPU :P

[b]Instruction Formats[/b]
So… 16- or 32-bit instructions, with 32-bit arithmentic/logical ops, but since the full instructions are no more than 32-bits, immediates can only be 16-bit.  Meaning long-distance jumps and absolute loads/stores are made using a register containing a 32-bit address, and a 16-bit immediate offset from that address.  That… it's like… using the most awkward NES addressing mode as your STANDARD MODUS OPERANDI!!  And yet… makes such perfect sense.  *whimper*

[b]Memory and Register Transfers[/b]
… and wait… there are typical MOV instructions to get data in and out of registers, but quick integer addition is performed via variants of the MOV instructions rather than dedicated ADD instructions, and further there are MOV instructions to add to either the low halfword or the high halfword of a register, because…? … *facepalm* 32-bit values.  16-bit immediates.  They aren't being convoluted, they're just providing the perfectly sensible tools to put a 32-bit value in a register the only way one could ever expect to- convolutedly!

… even having just explained it to myself, the load/store operations still make my brain cry.  To paraphrase, "register 2 equals the zero-extended value at an address computed by adding the 16-bit immediate to the 32-bit value in register 1, but only if you're accessing CPU memory, otherwise sign-extend the value."  But… ooh!  Pipelined architecture!  Nice. 
Silly Editor- "many" probably is dependent on the precise type of instruction and the instruction context.  The fact that the longest execution is 5 cycles suggests that there are 5 sub-stages in the pipeline.  If I had to hazard a guess, they'd be along the lines of {compute source} -> {retrieve data} -> {do math/logic} -> {compute destination} -> {store data}.  So if instruction 1 reads from location A and writes to location B and instruction 2 reads from location C and writes to location D, then the two can be fully pipelined and execute in 6 cycles:

1. {compute source of 1 (A)}
2. {retrieve data at A} + {compute source of 2 (C)}
3. {do maths 1 on data from A} + {retrieve data at C}
4. {compute destination of 1 (B)} + {do maths 2 on data from C}
5. {store result 1 in B} + {compute destination of 2 (D)}
6. {store result 2 in D}

but if instruction 2 needs to read from B and store to D, then you need a few more steps:

1. {compute source of 1 (A)}
2. {retrieve data at A} + {compute source of 2 (B)}
3. {do maths 1 on data from A} + {retrieve data at B}
4. {compute destination of 1 (B)} + {do maths 2 on data from B}
5. {store result 1 in B} + { Oops, I guess what we retrieved from B isn't right- need to retrieve it again.  But… dammit, the memory bus is already in use because instruction 1 is storing its result.  Twiddle our digital thumbs! }
6. {NOW we can retrieve the CORRECT data at B}
7. {redo maths on 2 on CORRECT data from B}
8. {compute destination of 2 (D)}
9. {store result 2 in D}

And… okay.  I get the need to have more than just an accumulator register when the set of arithmetic ops is more than just ADD and CMP.  Why you decide to still use the numeric register IDs rather than more explicit names by purpose, yielding a non-contiguous list of extant registers r0-r31… *headshake* Engineers…

[b]About Bitstring Instructions[/b]
…Lovely.  Instructions which take probably-a-shitton of cycles and use registers as their own private internal state. … Once again because it's completely sensible and allows things like conditional breaking-out mid-instruction.  …  Which furthermore means assembly-level instructions are not necessarily atomic.   …   *sob*

[b]List of Bit String Instructions[/b]
XORNBSU!  XORNBSU!!!!  XORNBSUUUUUUUUUU!!!! … What is this?  Opcode naming auf Deutsch?  Condense a whole sentence into a single opcode?  I suppose at least I can pronounce that one.  Unlike its close cousin ANDNBSU.  Can I use NNBSU as an alternative to NOP?

Great googlay mooglay… the cycle count for bitstring ops… is an algorithm >.<;

[b]CPU Miscellaneous Instructions[/b]
CAXI…?  I prefer denim, but… wait, that isn't…?  This is going to give me more of a headache, isn't it?
…
Multiprocessor synchronization.  What the who how?  There isn't even…  Unless you can… … I don't want to know.  I could go my whole life without knowing, and be perfectly happy. … Except now I know that I don't know, which means I need to know.  Dammit. *reads further*
Okay, so there IS only one CPU.  And CAXI is thus a glorified thunk.  Not sure whether to be disappointed or relieved.

Whew.  This console... This Console.  It may only be a matter of time before I have to try developing something in earnest.  So much cool stuff to play with, so may ways to get a migraine, so many more to give one ^_^  [s]Guinnea pigs[/s] Playtesters for AGDQ14?  Anyone?

Lone_Kilted_Ninja

2013-06-23 12:53:14 pm

Anything you can do I can do halfass

Professor NES explains: the FF1 Anniversary Edition glitches

I just started watching the June 20 run, with commentary. Congrats, Lenophis! From what I've read in the run comments / knowledgebase, I think I can maybe get slightly closer to what's going on than the commentators, although they do have the right general direction. As usual, the specifics are only strong hypotheses at least barring my ever seeing the code, but the overall theory behind them is precise within the realms of CS and game design. So…

The Equipment Glitch
The KB explains how to do it at https://kb.speeddemosarchive.com/Final_Fantasy
To understand what is probably going on, we'll need to understand
- how the game represents data
- what a state machine is
- sequential execution and priority

How the game represents data. The game does not track equipment by name and stats- that is to say, a player's inventory is not actually full of entries that literally say "Hammer," "Leather Cap," etc. Not to say the game couldn't track that way, it's just horridly inefficient and any programmer who does that without a good reason should be hit upside the head and sent back to middle school computer camp.
Think about it: every time you want to see whether an item is what you think it is, you have to compare the entire name with another name, one letter at a time; and match against multiple fields of internal databases of valid equipment. To change equipment, the game would need to copy every single weapon parameter in and out of the character data. And if one letter of one name, or one stat, gets slightly corrupted, then suddenly nothing in the internal database would match the equipment precisely and you'd end up with a junk item that would seriously confuse the game. Unless the database had every single permutation of values which could be constructed from all possible fields, in which case, assuming a piece of equipment were nothing more than, say, 4 1-byte stats (256 possible values each) and a name consisting of up to 6 letters (26 lowercase, 26 uppercase, 1 space = 53 possibilities per character if they condensed it; 256 possibilities per character if they use raw e.g. ASCII), that would mean the database would need 256*256*256*256*53*53*53*53*53*53 = 9.52x10^19 entries, which at 10 bytes each, is 9.52x10^20 bytes, or 95195206TB of data and the programmer should probably be shot.
Rather, the game will give every item a numeric ID, and look up its specifics from a much smaller table based on that ID. The table may even be exhaustive, such that any possible value of the item ID corresponds to a real entry, and thus even if the data gets a little corrupted it will still at least resolve to something that doesn't confuse the game the game.
Now, I further suspect that FF Anniversary segments the inventory system- that is, it keeps separate lists of weapons, armor, and consumables. So ID #12 on the Weapons table might be "Hammer" while ID #12 on the Armors table might be Knight's Armor. When you equip e.g. weapons, the game presents the list of item IDs in your weapon sub-inventory, filtered by what the character is allowed to equip. You select an entry corresponding to a weapon of ID #12, the game puts #12 in the weapon slot, then looks through the weapon sub-inventory, locates the first item #12 it finds, and removes it (because it's no longer in the inventory; it's on the character).

Detour.

A state machine, at its highest level, is a system of "states" or conditions in which the machine may exist, and "transitions" dictating how those states may be entered and exited. A simple physical example might be the physical states of water- solid, liquid, gas.
- In state Solid:
-- there is a transition to state Liquid via adding heat.
- In state Liquid:
-- there is a transition to state Solid via removing heat,
-- there is a transition to state Gas via adding heat.
- In state Gas:
-- there is a transition to state Liquid via removing heat.

Yes, I know, plasmas, sublimation, etc., I haven't covered all physical phenomena, but if this was the extent of the machine representation of water, it would be a fair approximation. Each state would also have some metadata on what it represented or how it could function or the things that it was worthwhile to know about it.

Similarly, in a microcosm of most FF games, there exists e.g.
- In state equipment-menu-for-character-A-while-pointed-at-slot-1
-- there is a transition to state equipment-list by pressing A
-- there is a transition to state main-menu by pressing B
-- there is a transition to state equipment-menu-for-character-A-while-pointed-at-slot-2 by pressing down
-- there is a transition to state equipment-menu-for-character-A-while-pointed-at-slot-N by pressing up
-- there is a transition to state equipment-menu-for-character-B-while-pointed-at-slot-1 by pressing R
-- there is a transition to state equipment-menu-for-character-D-while-pointed-at-slot-1 by pressing L
- etc.

So what happens if we're in state equipment-menu-for-character-A-while-pointed-at-slot-1 and multiple buttons are pressed? Priority and sequential execution. The game can only evaluate one possible transition criteria at a time, so it steps through them all in order. Just like in a fighting game where two attacks interact and the game can't resolve them both at once, so it steps through its list, finds Light Punch and resolves its effects, one of which includes breaking any combo chain of the target, before it even gets to the other player's Super Killer Move. Only in FF Anniversary, either someone got clever and decided to ~try~ to evaluate multiple transitions at once, or simply left in any of a handful of specific programming structural faux-pas I won't get into. So it becomes possible to simultaneously change to the equipment list and change character. And evidently the order in which the changes are processed is
1) flag that next frame we will be going into/out-of a sub-inventory menu to fill the currently selected slot of the currently selected character
2) set the currently selected character to a different character
And compounding the entertainment is the fact that the game evidently tracks which slot each character has selected independently.

So.

You have a Hammer in your weapon sub-inventory. That is to say, the list of weapons in your possession contains an entry "ID #12."
You leave your White Mage in the pointed-at-armor-slot menu sub-state.
You switch to your Fighter's equip screen, select his weapon slot, and transition to the list of your weapon sub-inventory filtered by compatibility with Fighter.
You point at the Hammer (which is only really the number 12 sitting in a bucket)
You simultaneously select the Hammer and switch to your White Mage.
The game resolves the simultaneous transition by registering the #12 as the selected item, then changing the active character (which implicitly changes the selected slot, since the slot sub-state is tracked independently).
So now the game goes through the routine for placing #12 into the active character's armor slot. It sets White Mage's armor to #12 and removes the first #12 it finds from the armor sub-inventory. So now White Mage is wearing Knight's Armor, and while the net appearance is that it has been created out of thin air, in reality it did dutifully go through and remove it from your inventory, it just looked for it in your armor inventory, didn't find it there, and never even realized that it should remove it from your weapon inventory because as far as it was concerned, you were equipping armor the whole time.

RNG
RNGs aren't actually random. They tend to come from 3 primary sources:
- mathematical algorithms
- chaotic interactions
- fixed tables generated from one of the above (or rarely from a legitimate source of random values e.g. quantum sensors or cosmic background radiation)

Proper pseudorandom number algorithms can be pages long, and generally involve multiple iterations of computation to obtain a single value, and the good ones- the sort that Vegas certifies- require a constant background loop continuously pulling new numbers whether they're needed or not. On old consoles, this was right out. Too much memory, too much time, too low performance. On modern consoles (say, PS1 era and later) that can just bake in the C standard rand() call (which is a rather lousy RNG as RNGs go, but serves for most circumstances when lives and money aren't on the line), it's much more likely that's where the numbers come from.

Chaotic interaction are what I'm calling any conjunction of individually well-known events which in combination aren't human-predictable. Say, those desk toys consisting of a pendulum on the end of a pendulum on the end of a pendulum, or the precise frame from system boot on which a player last pressed the A button in normal gameplay, modulo the low byte of the total game time. While statistically dodgy, this is a cheap trick that most casual players won't notice if a game doesn't need much RNG, and it's quite easy to implement.

Tables, as long as they're "large enough," are a great alternative if you can afford the space. They're quick to access, and every bit as "good" as the source they came from.

Any RNG, however, is going to have certain key metrics, chief among these are
- Fairness/Uniformity (if you selected an infinite number of values, would they average half way between the minimum and maximum?)
- Volatility (would you like your 95% return on the slot machine to be a 95-cent win on every dollar spin, or a single $95 win once in a hundred spins with $0 win the rest of the time?)

If a game RNG can be manipulated e.g. by items or by invoking things that use the RNG, it is almost certainly a table RNG. Okay, okay, it could just be a seeded algorithm that doesn't tumble, in which case the universe of outcomes still equates to a fixed table, just a really ginormously huge table, and the only way you influence it is by the raw number of calls you make; you can't just jump to arbitrary points. This is the case for most early Final Fantasies. Anything that needs a number just pulls the next number in the table. However, likely due to known volatilities within certain regions of the table (e.g. strings of unusually low or unusually high consecutive values), I can only guess that certain random effects needed to be more constrained. E.g. iirc FF4 and/or FF6 Smoke Bombs fix the RNG. Perhaps there were known regions of the table in which pulling values for escape outcome would result in long strings of success or failure, either of which could bias the player experience. Or perhaps the art designers wanted to use random locations for the puffs of smoke, and just so happened to like the sequence of puffs generated from one specific part of the table. So before retrieving a value, they set the retrieval index to a known spot or a known neighborhood. And if that neighborhood contains values which trigger positive results in another system that uses the RNG, you have an exploit.

If a game RNG can be manipulated by e.g. frame timing, as one commentator mentioned, it's probably a chaotic/tumbling system, or a time-based seeding of an algorithm. It might be in conjunction with a table, but that's not strictly necessary. Point is, as long as you know what events are being tracked, executing those events identically will yield identical results. I believe the trick in FF3 (classic NES) is slightly more along these lines. If you know the exact sequence in which you will request RNG values, you know what those values will be. So you know what value will be pulled when the game grabs the number of steps you can take before the next battle. I believe multiple FFs actually explicitly reset the battle step counter if you happen to do something in the menu right when the battle would normally trigger. It could be an intentional mechanism to add a "skill" component to the trigger, or perhaps entering the menu just counts as an action which would reduce the step counter, so if you do it as the action which reduces the step counter to 0, the next step it gets reset, or simply wraps to 255. Either way, if you know when it will happen, you can abuse it.

FF Anniversary is new enough that it probably uses a stock software randomizing algorithm, meaning the only real way to exploit it is to control the seed passed into it. If that seed is the typical "number of milliseconds since arbitrary date in computer history," good luck. And yet just because it's a "proper algorithm" rather than a table doesn't mean it's good. In fact, in a table, you know you have a hard limit on the number of consecutive bad outcomes before you get to somewhere good- if the table has 256 values, success is possible within 256 tries guaranteed. Proportionally fewer based on the success threshold. Get into a bad spot in the universe of a dodgy algorithm and you could be there for quite awhile.

[b]Professor NES explains: the FF1 Anniversary Edition glitches[/b]

I just started watching the June 20 run, with commentary.  Congrats, Lenophis!  From what I've read in the run comments / knowledgebase, I think I can maybe get slightly closer to what's going on than the commentators, although they do have the right general direction.  As usual, the specifics are only strong hypotheses at least barring my ever seeing the code, but the overall theory behind them is precise within the realms of CS and game design.  So…

[b]The Equipment Glitch[/b]
The KB explains how to do it at https://kb.speeddemosarchive.com/Final_Fantasy
To understand what is probably going on, we'll need to understand
- how the game represents data
- what a state machine is
- sequential execution and priority

How the game represents data.  The game does not track equipment by name and stats- that is to say, a player's inventory is not actually full of entries that literally say "Hammer," "Leather Cap," etc.  Not to say the game [i]couldn't[/i] track that way, it's just horridly inefficient and any programmer who does that without a good reason should be hit upside the head and sent back to middle school computer camp.  
[size=6]Think about it: every time you want to see whether an item is what you think it is, you have to compare the entire name with another name, one letter at a time; and match against multiple fields of internal databases of valid equipment.  To change equipment, the game would need to copy every single weapon parameter in and out of the character data.  And if one letter of one name, or one stat, gets slightly corrupted, then suddenly nothing in the internal database would match the equipment precisely and you'd end up with a junk item that would seriously confuse the game.  Unless the database had every single permutation of values which could be constructed from all possible fields, in which case, assuming a piece of equipment were nothing more than, say, 4 1-byte stats (256 possible values each) and a name consisting of up to 6 letters (26 lowercase, 26 uppercase, 1 space = 53 possibilities per character if they condensed it; 256 possibilities per character if they use raw e.g. ASCII), that would mean the database would need 256*256*256*256*53*53*53*53*53*53 = 9.52x10^19 entries, which at 10 bytes each, is 9.52x10^20 bytes, or 95195206TB of data and the programmer should probably be shot.[/size]
Rather, the game will give every item a numeric ID, and look up its specifics from a much smaller table based on that ID.  The table may even be exhaustive, such that any possible value of the item ID corresponds to a real entry, and thus even if the data gets a little corrupted it will still at least resolve to something that doesn't confuse the game the game.
Now, I further [i]suspect[/i] that FF Anniversary segments the inventory system- that is, it keeps separate lists of weapons, armor, and consumables.  So ID #12 on the Weapons table might be "Hammer" while ID #12 on the Armors table might be Knight's Armor.  When you equip e.g. weapons, the game presents the list of item IDs in your weapon sub-inventory, filtered by what the character is allowed to equip.  You select an entry corresponding to a weapon of ID #12, the game puts #12 in the weapon slot, then looks through the weapon sub-inventory, locates the first item #12 it finds, and removes it (because it's no longer in the inventory; it's on the character).

Detour.

A state machine, at its highest level, is a system of "states" or conditions in which the machine may exist, and "transitions" dictating how those states may be entered and exited.  A simple physical example might be the physical states of water- solid, liquid, gas.
- In state Solid: 
-- there is a transition to state Liquid via adding heat.
- In state Liquid: 
-- there is a transition to state Solid via removing heat, 
-- there is a transition to state Gas via adding heat.
- In state Gas: 
-- there is a transition to state Liquid via removing heat.

[size=6]Yes, I know, plasmas, sublimation, etc., I haven't covered all physical phenomena, but if this was the extent of the machine representation of water, it would be a fair approximation.[/size]  Each state would also have some metadata on what it represented or how it could function or the things that it was worthwhile to know about it.

Similarly, in a microcosm of most FF games, there exists e.g.
 - In state equipment-menu-for-character-A-while-pointed-at-slot-1
-- there is a transition to state equipment-list by pressing A
-- there is a transition to state main-menu by pressing B
-- there is a transition to state equipment-menu-for-character-A-while-pointed-at-slot-2 by pressing down
-- there is a transition to state equipment-menu-for-character-A-while-pointed-at-slot-N by pressing up
-- there is a transition to state equipment-menu-for-character-B-while-pointed-at-slot-1 by pressing R
-- there is a transition to state equipment-menu-for-character-D-while-pointed-at-slot-1 by pressing L
- etc.

So what happens if we're in state equipment-menu-for-character-A-while-pointed-at-slot-1 and multiple buttons are pressed?  Priority and sequential execution.  The game can only evaluate one possible transition criteria at a time, so it steps through them all in order.  Just like in a fighting game where two attacks interact and the game can't resolve them both at once, so it steps through its list, finds Light Punch and resolves its effects, one of which includes breaking any combo chain of the target, before it even gets to the other player's Super Killer Move.  Only in FF Anniversary, either someone got clever and decided to ~try~ to evaluate multiple transitions at once, or simply left in any of a handful of specific programming structural faux-pas I won't get into.  So it becomes possible to simultaneously change to the equipment list and change character.  And evidently the order in which the changes are processed is
1) flag that next frame we will be going into/out-of a sub-inventory menu to fill the currently selected slot of the currently selected character
2) set the currently selected character to a different character
And compounding the entertainment is the fact that the game evidently tracks which slot each character has selected independently.

So.

You have a Hammer in your weapon sub-inventory.  That is to say, the list of weapons in your possession contains an entry "ID #12."
You leave your White Mage in the pointed-at-armor-slot menu sub-state.
You switch to your Fighter's equip screen, select his weapon slot, and transition to the list of your weapon sub-inventory filtered by compatibility with Fighter.
You point at the Hammer (which is only really the number 12 sitting in a bucket)
You simultaneously select the Hammer and switch to your White Mage.
The game resolves the simultaneous transition by registering the #12 as the selected item, then changing the active character (which implicitly changes the selected slot, since the slot sub-state is tracked independently).
So now the game goes through the routine for placing #12 into the active character's armor slot.  It sets White Mage's armor to #12 and removes the first #12 it finds from the armor sub-inventory.  So now White Mage is wearing Knight's Armor, and while the net appearance is that it has been created out of thin air, in reality it did dutifully go through and remove it from your inventory, it just looked for it in your armor inventory, didn't find it there, and never even realized that it should remove it from your weapon inventory because as far as it was concerned, you were equipping armor the whole time.

[b]RNG[/b]
RNGs aren't actually random.  They tend to come from 3 primary sources:
- mathematical algorithms
- chaotic interactions
- fixed tables generated from one of the above (or rarely from a legitimate source of random values e.g. quantum sensors or cosmic background radiation)

Proper pseudorandom number algorithms can be pages long, and generally involve multiple iterations of computation to obtain a single value, and the good ones- the sort that Vegas certifies- require a constant background loop continuously pulling new numbers whether they're needed or not.  On old consoles, this was right out.  Too much memory, too much time, too low performance.  On modern consoles (say, PS1 era and later) that can just bake in the C standard rand() call (which is a rather lousy RNG as RNGs go, but serves for most circumstances when lives and money aren't on the line), it's much more likely that's where the numbers come from.

Chaotic interaction are what I'm calling any conjunction of individually well-known events which in combination aren't human-predictable.  Say, those desk toys consisting of a pendulum on the end of a pendulum on the end of a pendulum, or the precise frame from system boot on which a player last pressed the A button in normal gameplay, modulo the low byte of the total game time.  While statistically dodgy, this is a cheap trick that most casual players won't notice if a game doesn't need much RNG, and it's quite easy to implement.

Tables, as long as they're "large enough," are a great alternative if you can afford the space.  They're quick to access, and every bit as "good" as the source they came from.

Any RNG, however, is going to have certain key metrics, chief among these are
- Fairness/Uniformity (if you selected an infinite number of values, would they average half way between the minimum and maximum?)
- Volatility (would you like your 95% return on the slot machine to be a 95-cent win on every dollar spin, or a single $95 win once in a hundred spins with $0 win the rest of the time?)

If a game RNG can be manipulated e.g. by items or by invoking things that use the RNG, it is almost certainly a table RNG.  [size=6]Okay, okay, it could just be a seeded algorithm that doesn't tumble, in which case the universe of outcomes still equates to a fixed table, just a really ginormously huge table, and the only way you influence it is by the raw number of calls you make; you can't just jump to arbitrary points.[/size]  This is the case for most early Final Fantasies.  Anything that needs a number just pulls the next number in the table.  However, likely due to known volatilities within certain regions of the table (e.g. strings of unusually low or unusually high consecutive values), I can only guess that certain random effects needed to be more constrained.  E.g. iirc FF4 and/or FF6 Smoke Bombs fix the RNG.  Perhaps there were known regions of the table in which pulling values for escape outcome would result in long strings of success or failure, either of which could bias the player experience.  Or perhaps the art designers wanted to use random locations for the puffs of smoke, and just so happened to like the sequence of puffs generated from one specific part of the table.  So before retrieving a value, they set the retrieval index to a known spot or a known neighborhood.  And if that neighborhood contains values which trigger positive results in another system that uses the RNG, you have an exploit.

If a game RNG can be manipulated by e.g. frame timing, as one commentator mentioned, it's probably a chaotic/tumbling system, or a time-based seeding of an algorithm.  It might be in conjunction with a table, but that's not strictly necessary.  Point is, as long as you know what events are being tracked, executing those events identically will yield identical results.  I believe the trick in FF3 (classic NES) is slightly more along these lines.  If you know the exact sequence in which you will request RNG values, you know what those values will be.  So you know what value will be pulled when the game grabs the number of steps you can take before the next battle.  I believe multiple FFs actually explicitly reset the battle step counter if you happen to do something in the menu right when the battle would normally trigger.  It could be an intentional mechanism to add a "skill" component to the trigger, or perhaps entering the menu just counts as an action which would reduce the step counter, so if you do it as the action which reduces the step counter to 0, the next step it gets reset, or simply wraps to 255.  Either way, if you know when it will happen, you can abuse it.

FF Anniversary is new enough that it probably uses a stock software randomizing algorithm, meaning the only real way to exploit it is to control the seed passed into it.  If that seed is the typical "number of milliseconds since arbitrary date in computer history," good luck.  And yet just because it's a "proper algorithm" rather than a table doesn't mean it's good.  In fact, in a table, you know you have a hard limit on the number of consecutive bad outcomes before you get to somewhere good- if the table has 256 values, success is possible within 256 tries guaranteed.  Proportionally fewer based on the success threshold.  Get into a bad spot in the universe of a dodgy algorithm and you could be there for quite awhile.