Making a game console from parts like 6502,z80 etc possible
Moderator: Moderators
Re: Making a game console from parts like 6502,z80 etc possi
I'm pretty certain that combining multiple TMS9918s to produce more sophisticated graphics wasn't really on their radar when they designed it... but video overlay from a camera or recorded source had a clear use.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Making a game console from parts like 6502,z80 etc possi
I'm thinking about possible graphics modes for a 16-bit system.
Mode 0:
- 3 BG layers
- BG1 and BG2 always use 16x16 tiles
- BG3 can use either 8x8 or 16x16 tiles
Mode 1:
- 1 rotation/scaling BG layer
Mode 2:
- 2 BG layers (BG1 and BG3)
- BG1 is a windowed rotation/scaling layer (either 160 pixels of 256, or 192 of 320)
- BG3 can use either 8x8 or 16x16 tiles
Mode 3:
- 3 BG layers
- BG1 is a windowed rotation/scaling layer (either 80 pixels of 256, or 96 of 320)
- BG2 uses 16x16 tiles
- BG3 can use either 8x8 or 16x16 tiles
Mode 0:
- 3 BG layers
- BG1 and BG2 always use 16x16 tiles
- BG3 can use either 8x8 or 16x16 tiles
Mode 1:
- 1 rotation/scaling BG layer
Mode 2:
- 2 BG layers (BG1 and BG3)
- BG1 is a windowed rotation/scaling layer (either 160 pixels of 256, or 192 of 320)
- BG3 can use either 8x8 or 16x16 tiles
Mode 3:
- 3 BG layers
- BG1 is a windowed rotation/scaling layer (either 80 pixels of 256, or 96 of 320)
- BG2 uses 16x16 tiles
- BG3 can use either 8x8 or 16x16 tiles
Re: Making a game console from parts like 6502,z80 etc possi
Why would you deliberately inherit the weirdness of the SNES setup instead of designing something more sane and versatile to use?
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Making a game console from parts like 6502,z80 etc possi
More versatile? The reason the SNES is so insane is that it's the most versatile 16 bit system I've seen in that the bandwidth can be chopped a million different ways, but out of all 8 modes, there's only half are worth keeping. 64x64 sprites are also illogical, and there's some other stupid stuff that I think only about 1 game has ever used. Like, what practical application does direct color have?tokumaru wrote:and versatile to use?
I'd really liked to use a time machine and tell Nintendo to have used the PPU space more reasonably. They had enough room to implement the hi res modes that I think less than 10 SNES games ever used, but they were too tight on space to implement a fifth byte for sprites? Manipulating 4BG layers couldn't have been too easy either, and while it's more commonly used than hi res mode (It would actually be particularly useful for modern "retro" games), it's still not that widely used. How about more palette entries?
Sorry about that Koitsu...
Re: Making a game console from parts like 6502,z80 etc possi
If you want a Game Boy Advance, you know where to find it.
* Approximation intended. Out-Aspergering me about weighing the ARM's special-purpose PC against the 68K's D0-D7/A0-A7 divide is beside the point.
- Like the 68000 in the Genesis, the ARM7TDMI in the GBA has about 16* 32-bit registers, some form of hardware multiply, and a 16-bit bus to most of its memory.
- Like the VDP in the Genesis, the GBA allows writing to VRAM during draw time as well as sprite cel memory bigger than 16K. It also allows rectangular sprites (8x16/16x8, 8x32/32x8, 16x32/32x16, 32x64/64x32), and sprite memory layout can be set to 1D (Genesis style) or 2D (Super NES style).
- Like the VDC and VCE in the TurboGrafx-16, the GBA has sixteen 15-color subpalettes for background and another sixteen for sprites.
* Approximation intended. Out-Aspergering me about weighing the ARM's special-purpose PC against the 68K's D0-D7/A0-A7 divide is beside the point.
Re: Making a game console from parts like 6502,z80 etc possi
Versatility isn't necessarily about offering a ridiculously large amount of settings... it can also mean offering a solid set of essential features that can be efficiently exploited in many different ways. I've never coded for the SNES myself, but every time I see you guys talking about it, it sounds absolutely taxing how you have to deal with all the possible settings and how deeply they affect the most basic aspects of the software design, and hearing about it seriously discourages me from ever trying to code anything for it. It sounds more like a chore than like a fun challenge to me. Don't get me wrong, I love the SNES and acknowledge that it was one of the greatest consoles ever made, but I'd hardly take it as a good example of hardware engineering.Espozo wrote:More versatile? The reason the SNES is so insane is that it's the most versatile 16 bit system I've seen
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Making a game console from parts like 6502,z80 etc possi
Depends on how literal you mean by retro. If you mean "can't have VRAM faster than 7Mhz" then it gets tricky.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Making a game console from parts like 6502,z80 etc possi
That's definitely true. It's kind of like how the Neo Geo is less complicated in terms of screen modes and transparency and resolution and whatever, but the few things that are there are much, much more flexible, although brute force has a lot to due with this.tokumaru wrote:it can also mean offering a solid set of essential features that can be efficiently exploited in many different ways.
Yeah, it's not for everyone... I've wanted to make a game engine that makes it possible for you to really just forget about handling the video hardware, (which is 90% of the problem with the SNES) but this has proven itself to be too slow for many applications. However, it's still faster than the code in 90% of commercially released SNES games. For very CPU intensive games, you need to hardcode a lot more.tokumaru wrote:I've never coded for the SNES myself, but every time I see you guys talking about it, it sounds absolutely taxing how you have to deal with all the possible settings and how deeply they affect the most basic aspects of the software design, and hearing about it seriously discourages me from ever trying to code anything for it.
I think the problem is many features were implemented for how limited the hardware is. Hell, the SNES beats otherwise much more powerful 2D hardware in terms of special effects. I've heard stories that the SNES was originally going to be much more powerful, and then, all of the special features would have made much, much more sense. Then, it would be like the GBA, which is honestly a much better designed piece of hardware.tokumaru wrote:I'd hardly take it as a good example of hardware engineering.
Re: Making a game console from parts like 6502,z80 etc possi
I can show what I designed for video anyways. A separate "video processor" executes a program called a "display list" during vblank and hblank (it won't execute during rendering). The display list starts executing from the beginning at vblank, and will continue from where it left off during hblank. The display list program must configure the playfield address at the beginning of this scanline, the fine X scroll, the address of the sprite table, the address of the patterns, the sprite Y scroll position, the palette, and some other mode bits (such as controlling interpretation of the playfield data; the four settings are "Tile", "Tile + Attribute A", "Tile + Attribute B", and "Pixel"). By doing this, you can have the tile height to be whatever you want, or you can display tiles upside-down, or other possibilities. You could also try to make a simplified version of this if you want to, I suppose.
One way to share video memory with main memory is by implementing clock-interleave. (This is how I planned to do it.)
Amiga has "copper" with a much simpler instruction set than what I have, but could execute during rendering instead of having to wait for hblank. Amiga also has various modes, such as "dual playfield", "Hold And Modify", "Extra Half Brite", and so on; I don't quite know everything about them, but I somewhat know its working.
One way to share video memory with main memory is by implementing clock-interleave. (This is how I planned to do it.)
Amiga has "copper" with a much simpler instruction set than what I have, but could execute during rendering instead of having to wait for hblank. Amiga also has various modes, such as "dual playfield", "Hold And Modify", "Extra Half Brite", and so on; I don't quite know everything about them, but I somewhat know its working.
(Free Hero Mesh - FOSS puzzle game engine)
Re: Making a game console from parts like 6502,z80 etc possi
Instead of doing something tricky like all these vintage 2d consoles, just give devs a framebuffer and a 2d hw blitter, with alpha blending and common 2d transformations. Unlimited sprites/layers/colors, only limited by memory bandwidth. Just like early PC GPUs, Rage or Matrox.
@tepples
GBA 1D mode is not Genesis-like. It's the opposite order - row vs column. SCNR.
@tepples
GBA 1D mode is not Genesis-like. It's the opposite order - row vs column. SCNR.
Re: Making a game console from parts like 6502,z80 etc possi
Atari 400/800/5200 and Atari 7800 called, and they want their display lists back.zzo38 wrote:I can show what I designed for video anyways. A separate "video processor" executes a program called a "display list" during vblank and hblank (it won't execute during rendering). The display list starts executing from the beginning at vblank, and will continue from where it left off during hblank. The display list program must configure the playfield address at the beginning of this scanline, the fine X scroll, the address of the sprite table, the address of the patterns, the sprite Y scroll position, the palette, and some other mode bits (such as controlling interpretation of the playfield data...)
That ended up used in pretty much everything since the Atari Lynx. Before then, it needed too much fast memory compared to the TMS9918-style tile planes and sprites paradigm.calima wrote:2d hw blitter
It's still not 2D, about which on the Super NES psycopathicteen has complained several times because it increases setup time for DMA.calima wrote:GBA 1D mode is not Genesis-like. It's the opposite order - row vs column.
Re: Making a game console from parts like 6502,z80 etc possi
Most games just used the two 4bpp layers and third 2bpp layer, and didn't really do anything special with them.tokumaru wrote:Versatility isn't necessarily about offering a ridiculously large amount of settings... it can also mean offering a solid set of essential features that can be efficiently exploited in many different ways. I've never coded for the SNES myself, but every time I see you guys talking about it, it sounds absolutely taxing how you have to deal with all the possible settings and how deeply they affect the most basic aspects of the software design, and hearing about it seriously discourages me from ever trying to code anything for it. It sounds more like a chore than like a fun challenge to me. Don't get me wrong, I love the SNES and acknowledge that it was one of the greatest consoles ever made, but I'd hardly take it as a good example of hardware engineering.Espozo wrote:More versatile? The reason the SNES is so insane is that it's the most versatile 16 bit system I've seen
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Making a game console from parts like 6502,z80 etc possi
To be honnest, if anyone were to create a new system, I'd strongly discourage the usage of "graphics modes" alltogether. Just try to make a single useful and powerful graphic mode sounds much more useful than having multiple modes and having to chose between them later when you want to use half the features of each.I'm thinking about possible graphics modes for a 16-bit system.
As for the SNES, the standard way to do thing is use mode 1 normally, and use another mode whenever you want one of its distinct feature.
If I were designing my own retro video chip, I'll implement just a lot of sprites, and make the user supposed to simulate his BG(s) using sprites. This sounds more efficient than having several BGs and sprites in hardware.
Re: Making a game console from parts like 6502,z80 etc possi
You'd need to have Neo Geo style linking (each sprite has a list of one or more stacked 16x16s, and sprites can be set at an offset from the previous sprite in OAM) in order to make scrolling a background made of sprites as fast as updating a tilemap.
If Super NES devoted all its VRAM bandwidth to sprite slivers the way Neo Geo does, it'd be able to retrieve 170 slivers per line, which is equivalent to 85 16x16 sprites. That's almost Neo Geo level by itself, but then you lose color math and mode 7. Adding a single background to replace the fix layer would remove 32 slivers (if 4 color) or 48 slivers (if 16 color).
If Super NES devoted all its VRAM bandwidth to sprite slivers the way Neo Geo does, it'd be able to retrieve 170 slivers per line, which is equivalent to 85 16x16 sprites. That's almost Neo Geo level by itself, but then you lose color math and mode 7. Adding a single background to replace the fix layer would remove 32 slivers (if 4 color) or 48 slivers (if 16 color).
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Making a game console from parts like 6502,z80 etc possi
Wait, what? How would we all of the sudden be able to cover the screen a little over 5 times with 4bpp graphics using sprites, if no BG mode can even get to covering the screen 4 times with 4bpp graphics? Are you thinking that sprite data would still all be on the PPU, which I assume is much faster to get data from?tepples wrote:which is equivalent to 85 16x16 sprites.
I never understood the why Mode 3 (8bpp and 4bpp layer) wasn't more often used. I'm guessing a lot of it has to do with rom size.Dwedit wrote:Most games just used the two 4bpp layers and third 2bpp layer, and didn't really do anything special with them.