Modern tools and SNES programming compared to NES

[NeverCameBack]

Hello all,
A few questions if anyone would be so kind to answer:

#1. I'm at the point in "Nerdy Nights" where scrolling is being explained. It is the first time I'm seeing a .bin file used for the backgrounds.
Are there any tools out there that would allow one to quickly create the .chr file (two #$00 - #$FF tile tables)? It would be nice if a pixel picture could be copied and pasted.. or imported. Tile Layer Pro lets me import a .bmp file... One tile at a time.. but I didn't find it useful because it ignored the colors I was using and made my image consist of only 2 colors.

#2. Additionally, are there any tools out there to create a .bin file for the background of your "level", or in my case, an image with text (I'm making a text based visual novel type game).

#3. How similar is SNES programming to NES programming in 6502 Assembly? Wondering how translatable the NES programming skills will be once I sharpen them - and eventually, I'm dying to program a game for the Virtual Boy.

[lidnariq]

#1. I'm at the point in "Nerdy Nights" where scrolling is being explained. It is the first time I'm seeing a .bin file used for the backgrounds.
Are there any tools out there that would allow one to quickly create the .chr file (two #$00 - #$FF tile tables)? It would be nice if a pixel picture could be copied and pasted.. or imported. Tile Layer Pro lets me import a .bmp file... One tile at a time.. but I didn't find it useful because it ignored the colors I was using and made my image consist of only 2 colors.

#2. Additionally, are there any tools out there to create a .bin file for the background of your "level", or in my case, an image with text (I'm making a text based visual novel type game).

Shiru's NES Screen Tool.

Maybe also Kasumi's I-CHR

Maaybe thefox's NES Image Converter.

#3. How similar is SNES programming to NES programming in 6502 Assembly? Wondering how translatable the NES programming skills will be once I sharpen them - and eventually, I'm dying to program a game for the Virtual Boy.

Just in terms of writing code, the 65816 isn't that different from a 6502, but the SNES and NES require fairly different interactions with the sound and audio hardware.

[dougeff]

I am working on tools for SNES gamedev.

That plus superfamiconv (image converter) and MESEN-S emulator, and a well detailed wiki, is like 90% of what I'll need.

NES and SNES are very similar, except that SNES has a way to send data very fast to the PPU, DMA, even during active screen time (HDMA). NES passes data very slowly, and only during v-blank.

Virtual boy is very different from NES, and that may be harder transition.

[Bregalad]

I think one big thing SNES is lacking is good debuggers, as opposed to NES which have FCEUX, Nintendulator (and even Nesticle !) and other emulators with a lot of advanced deubuging & viewing features, such as real-time pattern table, name table and palette viewing. I could be wrong if such tools were developed more recently.

The APU is sure very different and more complex but it's not that much a huge beast as some of the doccumentation will make you think. Once again, debugging tools are limited and developing for a CPU that you can't see but only hear is a little bit more challenging.

except that SNES has a way to send data very fast to the PPU, DMA, even during active screen time (HDMA)

To be fair, HDMA sounds more like a way to have raster effects than a "way to send data very fast to the PPU". I think you're still disallowed to send data to VRAM during rendering, just like the NES. Maybe it's possible during HBlank, though, but aside of the palette there's few applications where it'd be any useful.

[tepples]

If you haven't tried Mesen-S, try it.

[calima]

bsnes-plus also has much of that.

[Oziphantom]

the 65816 is a dream compared to the 6502, but also a nightmare
It will solved every bugbear you have and give you a whole host more problems to deal with. It gets very advanced very fast.

The SNES is very similar the NES, just the SNES has a lot more thrown on top.

The virtual boy is a whole different machine and basically nothing carries over

[Pokun]

One good thing with the 65816 is its backwards-compatibility. You can literary treat it as a 6502 until you learn how to use its new features.

The SNES has tons of new hardware features (4 BG layers, mosaic effects, transparency, priority masking window, a bunch of screen and sprite modes among other things) and an overcomplicated 24-bit address map that looks like a Swiss cheese, all of which makes it take much more time to get into it. But if you know NES programming already, about any other "retro" game system is probably much easier to get into.

Virtual Boy supposedly uses a RISC CPU which is quite different from a classic CISC. Other than that I'd imagine the hardware would be quite similar to other consoles, but I don't really know as I have yet to study the VB in detail.

[lidnariq]

Virtual Boy supposedly uses a RISC CPU which is quite different from a classic CISC. Other than that I'd imagine the hardware would be quite similar to other consoles, but I don't really know as I have yet to study the VB in detail.

Someone used Nocash's documentation style to write up specifics here: https://web.archive.org/web/20190319100 ... stsvb.html (archive link b/c this is the newest version; other copies are the previous revision)

Very quick summary: Nametables ("Background segments") are 64x64 tiles, use 2bpp 8x8 patterns, 11 bits of patterns can be selected per tile. 14 nametables exist. A set of 32 rules controls how to draw subsets of nametables and any subset of sprites in any order, to either or both displays, to make it easier to build stereoscopic images. Nametables can be distorted using SNES Mode 7-style affine transformations. Four layers of bitmap images are also available, automatically interlaced, fixed for each eye. Four DMG-style palettes (2bpt+2bpp→2bpp) are available.

[Pokun]

Thanks for that document and summary!

Looks like classic game console hardware, asides from the RISC CPU. A notable feature seems to be that it has a whopping 32 windows for priority control of arbitrary parts of the screen to help the stereoscopic 3D for the two screens. SNES has only 1 window I think, and SuperGrafx has only 2.

14 nametables (although I'm not sure about calling them nametables since attributes are mixed in with the names on the same table unlike on NES) also sounds a lot, Gameboy just has 2.

Scrolling seems to be done in an interesting way involving the powerful windowing and background segment features, if I understand it correctly. There doesn't seem to be any hardware shifting of the background segments themselves like on other systems, instead you can stitch together a number of BG segments together into one larger BG segment (each 64x64 segment is only as large as the screen it seems) inside a window and shift them around there. A parallax scrolling feature is also in there.

I also like that the VSU uses several wavetable channels and a noise one, like the PC Engine. I guess that was only the natural evolution of the Game Boy (which only has one wavetable channel) as wavetable PSG technology became cheaper.

Finally the Direct Rendering bitmap mode is not bad to have either. Is that how Zero Racers did its wireframe 3D? Sounds to me like software 3D would be slow, but I don't know, much older systems used wireframe 3D.

[lidnariq]

I'm not sure about calling them nametables since attributes are mixed in with the names on the same table unlike on NES

SMS and Genesis refer to those as Name Tables, even despite having palette/flip information in-band.

I also like that the VSU uses several wavetable channels and a noise one, like the PC Engine. I guess that was only the natural evolution of the Game Boy (which only has one wavetable channel) as wavetable PSG technology became cheaper.

Also look into the Wonderswan at some point.

[Pokun]

I guess Sega systems inherited the term directly from the TMS9918 and people didn't feel it was necessary to change the terminology just because they added attributes into it. And the need for a general term for the BG screen data might also have helped. OK I buy that, nametable is a good term.


Sure, the Wondeswan is another system I'm interested in. I've been planning to get a SwanCrystal and a flashcart for a long time. Especially since it's a spiritual sequel to the GameBoy/VirtualBoy. I like the tate-mode feature and the LCD icon display separate from the dotmatrix display:

[Oziphantom]

nametable has never made sense to me, it neither holds names nor does it form a table.

charmap is the computer based term. As in its a map of characters.
Since consoles don't usually do character sets, Tiles seems to be the name they prefer and thus Tilemaps.
Having extra info such as colour, flip, reverse, flash, underline etc makes sense in a charmap/tilemap.

[tokumaru]

Yeah, I agree that "name table" is a terrible name. It's definitely a table, but nothing is being named, just referenced by number. To me it makes much more sense to say *what* is being referenced, so I find "tilemap" a much better term. And the "map" part makes it clear that the table doesn't hold the tiles themselves, it just arranges them for display.

[Pokun]

Yeah the term "nametable" was probably one of the biggest steps to get over when I started with NES homebrew (I imagined a table with names like John, Anna, Bert and so on ). Mirroring (when referring to nametable arrangement) was the other big one, and I still think it's really just reverse logic thinking that somehow stuck. "Mirroring" really means in what axis direction the second nametable is NOT in, talk about confusing.

Although the nametable is just a linear list of memory slots it can be drawn like a table on a paper and handled like a table in columns and rows, so in computer terms it's a table. I do agree that "map" is less confusing though since it really maps out the BG characters on the screen.

"Name" is another TMS9918 term that isn't too popular outside the NES homebrew community and systems based on the TMS9918 like the mentioned Sega ones. More common is tile index, tile number, or on Nintendo systems, CHR number. PC Engine officially uses the term Pattern Code (PC) which I like better than tile number because when I hear the term "tile" I think of BG characters, not the actual graphical pattern definition which is used for both background and sprites.
But the real confusion is that the term "name" is, in the NES homebrew community, used mostly only in the term "nametable", you seldom see terms like "BG name" or "sprite name".

"Character" seems to be used interchangeably with "tile" in homebrew communities, especially when abbreviated as CHR on Nintendo systems. Sometimes it means BG characters and sometimes it means the actual pattern data.
On modern systems "tile" is pretty much the only term used, and it's used mainly for segments of tiled backgrounds. I guess the lack of palettes on modern systems makes the different between an instance of a tile on a tilemap and the actual tile data pretty moot, and obvious by context.

"Sprite" is pretty much the only TMS9918 term that stuck and is widely used even on modern systems, even if they are software sprites. "Tile" is seldom used for sprite parts, but on the other hand, sprite usually means the whole part of any mobile 2D object.