Forums

It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics?

Chris :o)

Quote

> It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics?

> Chris :o)

In the case of the SMS, tiles are made up of sets of bitplanes (4 planes per pixel), and when you take the corresponding bits for a plane (ie, all bits at position 0 of each plane), you get a numerical value for each pixel. This value is then used to look into the colour palette to determine which colour gets displayed. This is similar to VGA programming, where each byte in the video memory identifies an entry in the 256 colour palette. Many other systems use a similar scheme.

Quote

> > It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics?

> > Chris :o)

Ignore my last post, it was confused. :) In the case of the SG-1000, there are 16 fixed colors. My interpretation
is that the sprite,
when it's written into the VRAM, is associated with a specific colour, therefore any "on" bits cause the
VDP to display the colour associated with the sprite, and "off" bits are displayed as transparent? I dunno on
that one, the docs are a little vague. :)

Hmm... great way to start off my first set of posts to the board. :)

If you feel the need so, you can introduce yourself to everyone ^_^
Chris, good luck. As for tiles and sprites stuff in SMS mode, it might be helpful for you to check my old SMS Power demo. Don't take the code as an exemple, it is pure crap. But being very simple, you should be able to figure out some things you don't understand yet.

Quote

> It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics?

I think one problem is that you're starting with SG-1000 modes, and the Sg-1000 doc (I assume you're looking at the one in the tech documents secrtion of this site) is rather sparse. It's better suited as a guide for someone familiar with the SMS to use as a reference for the difference betweent the SMS and the Sg-1000 (or the SMS using sg-1000 display modes). You'd be better off reading Richard Talbot Walkins' sms doc, which goes into more detail.

Quick review of how tile based consoles work.
Let's step away from the definitions of tiles first. Let's go back to the very first ibm PC's. The first PC's used a video card called a monochrome display adaptor (MDA). Basically, it had only a one color (whatever that color was depended on the color of your monitor, we'll say black and white for now) video mode with an unchangable font. The characters were printed in a 80 x 24 grid.
This was a simple tile mode. In video memory, each byte represented one tile (character) the way each byte represents one pixel in mode 13h: byte zero of vram stored the tile index for character on the upper right of the screen. Byte one stored the tile index for the second character to the left on the top row. Byte 80 stored the index for the leftmost character on the second row, etc.
So we have one byte defining each 'cell' that a tile can be in. Each byte stored sequentially, left to right, then top to bottom. But how does that single byte determine what goes in that 8x8 (or was it 8x16? i forget) map? On the card, patterns for each character in the character set were stored in rom, 256 in all. For every byte in video ram that cooresponded to a 'cell' on the screen, the video card used the value of that byte to find the appropriate pattern in the rom set. That pattern was used to output the final video signal which went to the monitor.
Thus, drawing one character to the screen took only one byte, not eight (or 16). This saved video ram (which was costly in those days) and speed up screen updates (since CPU's were very slow, and there's no point wasting all that time anyway). IBM (or whoever developed the MDA) logically chose to make each tile index coorespond with the ASCII equivelant (i.e. tile #65 is an image of a capital letter 'A')

So, we have tiles (patterns of characters, here stored in ROM), and the tile map (i.e. the grid of cells that tiles can live in, here an 80x40 grid, one byte per cell). On the SMS, the tile map is often called the name table. Don't know why, I don't think it's a very good name.

The MDA didn't support color because color monitors were so expensive nobody could afford to buy them. And besides, who needs 'em, the B in IBM stands for Business.

The CGA cards (color graphics adaptor) came along later and added color text modes (As well as color and mono graphics modes, but we'll ignore that for now). It kept the same overall architecture of the MDA in text mode, however, for every tile index byte in the tile map, there's also a second byte that the set the attributes. The attribute byte dedicates 4 bits for choosing the color of the tile(from a fixed 16 color palette), 3 bits to choose the background color of the tile (from a fixed 8 color palette), and one to select whether or not it blinks every second (or so). I'm not sure if the CGA text mode puts the attribute byte right after the index byte (i.e. byte 0 is top left index, byte 1 is top left attribute, byte 2 is top second left index, etc...) or if the attribute byte is stored in a second array (i.e. byte 0 is top left index, byte 1920 is top left attribute). Or something else entirely.

The Sg-1000 does something similar to that. All tiles are simple declared in terms of "color or no color" (1 or 0). When you place a tile in the tile map, you also set an attribute byte in the tile map to choose the foreground color (the tiles all share the same background color I think.).

As for how to define the actual tile image, most monochromatic 8x8 tile systems use the same system: one byte defines the pattern for one line (one bit per pixel, bit 7 is the leftmost, bit 0 the rightmost), so 8 bytes in a row determine the whole tile. In tasm, you can define a tile using binary notation like this:

.db %00000000
.db %00111100
.db %01100110
.db %01101110
.db %01110110
.db %01100110
.db %00111100
.db %00000000

and kind of 'see' it, while you draw it. The % is binary notation, the whole thing assembles to 8 bytes.
Generally (and in the case of the sg-1000), each tile is stored sequentially in video memory. If you specify tile 4 ina cell of a tile map, the video processor will add 4 (index number) times 8 (numbers of bytes per tile) to the start of the tile data to find the appropriate table.

The sg-1000 also offers sprites. The 8x8 sprites are defined the same way, and their patterns are stored in a table the same way. However, they don't have to live in a cell. You just tell which tile number you want to use, what color you want, and where to put it. Those values are stored in a table in vram somewhere.

that was wordy, but I hope it made sense.

Sg-1000 and SMS specific:
The Richard Talbot Walkins document explains more clear how to access video ram, but it's important to note that it's -not- mapped to the z80 memory space in any way. That is;

ld a,$40
ld ($3f00),a

does -not- put $40 in video ram. All video ram access is done through ports $bf and $be. You output the address in video ram you want to write to to port $bf (small byte first, and you add $4000 to the address for writes), and put the data you want to put in it in port $be. The vram pointer increases by 1 each time you write to $be, so if you have to copy a bunch of data to vram sequentially (As you often will) you only need to set the address once.

Alright, so lemme get this straight. Back in the day, the actual bitmap data was stored on ROM in the VGA card. The VRAM responded to byte data in a linear matrix of 80x24. So that means that there were 1920 bytes or around 1K of video memory, right? And from the DOS text mode programming mode that I'm used to, I guess that's where it originated from. And when data was written to row 24, data in the first row would be disgarded and all data below would be shifted up by 1 row.

Now, in the SG1000 there's a bitmap tile and an attribute tile?
Because Zoop's doc did say that there were 2 colors per tile. So, I guess the attribute byte must work like this...




0 = Color 1


1 = Color 2





.db %00000000


.db %00111100


.db %01100110


.db %01101110


.db %01110110


.db %01100110


.db %00111100


.db %00000000

Where 0 equals one color and 1 equals another. But, if there's 13 other colors, how do you select those?

But, back to tiles, I understand that Name Table refers to the address where the tile data is, but how does the system finally display the graphics? Let's use your 0 tile example and say that cell 1 or the first cell is your 0 tile. Is there some way that I could tell the system:

display Name Table Cell 1 at 12,12?

And what I mean by 12,12 is X,Y and that's by the top/left corner
of the screen.

Chris :o)

Quote

> Alright, so lemme get this straight. Back in the day, the actual bitmap data was stored on ROM in the VGA card. The VRAM responded to byte data in a linear matrix of 80x24. So that means that there were 1920 bytes or around 1K of video memory, right?

About 2k, yeah.I'm not sure if there was some extra vram for other things

Quote

> And from the DOS text mode programming mode that I'm used to, I guess that's where it originated from. And when data was written to row 24, data in the first row would be disgarded and all data below would be shifted up by 1 row.

Yes.
Or, rather, there was no row 24. When it was necessary to scroll up one row, the CPU manually moved the whole mess back 80 bytes and cleared row 23 for the next line of text. The video card didn't have any special hardware to support scrolling.

Before I respond to the rest of this, I'll attempt to clarify the main points:

The tile map (aka name table) and tile data are two -seperate- arrays in vram.
The tile data is the actual data that defines the tiles' images. (it's an array of small bitmaps: the format of the bitmaps depends on the system).
The tile map/name table is an array that says which tiles are drawn into which cells. In the case of the sms, each cell is two bytes long. The first byte of a cell tells which tile to put in that cell(*). The second byte allows you to set special attributes, like whether that cell should be flipped, whether it should appear in front of or behind sprites, etc.
Any tile can go into any cell.
Every cell uses one tile or another (even if you've set a cell's byte to zero, tile zero will be displayed.)

The reason I pointed out the way the old MDA cards work is the stress the importance of the tile map: You can, of course, stick any letter or character in any cell of the dos screen. The SMS and SG-1000 work the same way, except that the tile data (again, this is separate from the tile map) is not hard coded into rom, you can decide what every character (tile) looks like. You could even load the old MDA font in if you want to.

Quote

> Now, in the SG1000 there's a bitmap tile and an attribute tile?
> Because Zoop's doc did say that there were 2 colors per tile. So, I guess the attribute byte must work like this...

I'm still foggy on the details of the sg1000's tile map (zoop's documentation leaves me somewhat confused as to how colors are set).
But if I interpret correctly:

When he says 2 color, I think he means, background and foreground color (that's a common notation for 'monochrome', 2 color.)

Quote

> > 0 = Color 1 > 1 = Color 2




0 = background color


1 = foreground color (the actual color used to display the foreground color is determined by an attribute byte in the name table).

Quote
> .db %00000000 > .db %00111100 > .db %01100110 > .db %01101110 > .db %01110110 > .db %01100110 > .db %00111100 > .db %00000000 >
> Where 0 equals one color and 1 equals another. But, if there's 13 other colors, how do you select those?

Again, the tile image is defined in terms of 'foreground' (1) and 'background' (0). The actual colors that are displayed when that tile appears in the tilemap depends on what the background color is set to (it's the same for all tiles) and what that cell's attributes are.

Quote

> But, back to tiles, I understand that Name Table refers to the address where the tile data is,

as mentioned above, the name table is the map of cells.

Quote

>but how does the system finally display the graphics? Let's use your 0 tile example and say that cell 1 or the first cell is your 0 tile. Is there some way that I could tell the system:

> display Name Table Cell 1 at 12,12?

(I assume you mean display tile 1 in the twelfth cell to the left on the twelfth row of cells from the top).

absolutely.
On the SMS (not on the sg1000):

;Assumes the display is disabled or we are in vblank
ld a,$18 ;Set the VDP pointer to $7b18, which cooresponds to the cell at (12,12) in the name table.
out ($bf),a ;Set the VDP by writing the low byte first...
ld a,$7b
out ($bf),a ;Then the high byte. Anything output to $be will be written to VRAM starting at $7b18

ld a,1 ;Use tile 1 in that cell
out ($be),a
ld a,0 ;(this one gets put in $7b19)
out ($be),a ;No attributes (not flipped x or y, behind sprites, etc)

Done.
BTW, if you're curious how I arrived at $7b18:
The name table begins at $3800 (it can be moved elsewhere, but I always keep it at $3800).
To write to VRAM, the vram pointer must be set to the target address ANDed with $4000 (aka bit 14 must be set). Equivelant to adding $4000 in this case.
So, the writable name table begins at $7800
There are two bytes per cell, and 32 cells per row, so 64 bytes per row.
The twelfth row begins at nametable plus 768 (64 * 12). The twelfth character of that row is another 24 bytes down (12 x 2). So, that's the name table plus 792 ($318 in hex). $7800 + $318 = $7b18.

Quote

> The tile map/name table is an array that says which tiles are drawn into which cells. In the case of the sms, each cell is two bytes long. The first byte of a cell tells which tile to put in that cell(*). The second byte allows you to set special attributes, like whether that cell should be flipped, whether it should appear in front of or behind sprites, etc.

the display is disabled or we are in vblank

(the asterisk is for a footnote I forgot to make. specifically, I am aware that it's actually the first byte and and first bit of the second byte (i.e. 9 bits) that determine which tile is used in that cell, but I figure sometimes details confuse the main point, so I left it out).

Now the gears in my brain are starting to spin together :o)

Again, lemme back track cause this is a lot of stuff to soak in at once. All images are stored in the Tile Data. The screen is setup by a Name Table (btw, let's refer to the Tile Table as Name Table because it's easier to distinguish) and that name table refers to the Tile Data. Woah, something else just clicked! You said that the tiles the Name Table can be loaded from any tile in the Tile Data array, right? Because I noticed with the help of Nesticle and Meka that many games will have a huge garble for Tile Data but when you look at the Name Table you see the entire title screen (Well, besides the sprites). That's amazing! Oh, but..

Back to back tracking...So...The Name Table is a linear array of cells and each cell holds the location of the tile in the Tile Data array and little information like priorties and coloring? And the VDP depends on the Name Table to display the entire screen? So, really characters can't be display where ever on the screen like I assumed. When I said 12,12 I meant 12 pixels across and 12 pixels down; not 12 columns across and 12 rows down. And the VDP has a register pointer that points to the address where the Name Table begins? The VDP calculates all the information from both the Name Table and the Tile Data Array to finally render the screen? Hell, that just broke a big gaping hole in the ice! No wonder games repeated use of the same tiles because the name table can refer to the same tile as much as it wants! Hold on...Lemme get up and scream and do a carwheel!!

Phew! Ok, I'm calming down. But I still have more questions. Mainly about sprites. Unlike background tiles, can sprites be displayed anywhere (And when I say anywhere I mean pixel by pixel anywhere)? Is there a set for tile data and a set for character data? Two different Tile Data arrays? Are there two different Name Tables like one for Background and one for Sprites?

Chris :o)

Quote

> Now the gears in my brain are starting to spin together :o)

> Again, lemme back track cause this is a lot of stuff to soak in at once. All images are stored in the Tile Data. The screen is setup by a Name Table (btw, let's refer to the Tile Table as Name Table because it's easier to distinguish) and that name table refers to the Tile Data. Woah, something else just clicked! You said that the tiles the Name Table can be loaded from any tile in the Tile Data array, right? Because I noticed with the help of Nesticle and Meka that many games will have a huge garble for Tile Data but when you look at the Name Table you see the entire title screen (Well, besides the sprites). That's amazing! Oh, but..

> Back to back tracking...So...The Name Table is a linear array of cells and each cell holds the location of the tile in the Tile Data array and little information like priorties and coloring? And the VDP depends on the Name Table to display the entire screen? So, really characters can't be display where ever on the screen like I assumed. When I said 12,12 I meant 12 pixels across and 12 pixels down; not 12 columns across and 12 rows down. And the VDP has a register pointer that points to the address where the Name Table begins? The VDP calculates all the information from both the Name Table and the Tile Data Array to finally render the screen? Hell, that just broke a big gaping hole in the ice! No wonder games repeated use of the same tiles because the name table can refer to the same tile as much as it wants! Hold on...Lemme get up and scream and do a carwheel!!

(shouting to be heard above the noise)
Yes, you've got it.

Another thing you may find interesting, is that when you redraw a tile, every cell that uses that tile will display the changed version on the next screen frame. If you fill the name table with zeroes so that every cell displays tile zero, and at every vblank you update an animation with a spinning cross, the whole screen will be filled with spinning crosses.
For a demonstration of what I mean, load the SMSPower Demo and watch the tile display window change while the display changes. Notice the tile with the red is being updated every frame to look like motion. Everywhere where that tile is used in the main display you see that motion.

There are two main reasons why tiled display modes are so often used in older systems:
1-It allows you to set an entire 8x8 block of background in a single memory write (or two). In the case of the sms, screen updates would take up to 16 times longer. Scrolling would probably not be possible.
2-It saves on video ram needs: the sms has a 256 x 192 pixel display area. If every pixel could be independantly set, that would require 24k of ram (assuming two pixels per byte). And then there'd be more memory needed for sprites.
The SMS instead has 16k. There's enough for 384 tile definitions, the name table, and the table of sprite coordinates.

Quote

> Phew! Ok, I'm calming down. But I still have more questions. Mainly about sprites. Unlike background tiles, can sprites be displayed anywhere (And when I say anywhere I mean pixel by pixel anywhere)?

Yep, any old damn where.

Quote

> Is there a set for tile data and a set for character data? >Two different Tile Data arrays?

Do you mean, seperate sets of tiles for sprites and the background? Sort of. There are 384 tiles shared between the sprites and the background. The name table can refer to all 384 of them, whereas the sprites can use either the first 256 or everything after the first 256 (which 192 tiles). You choose which by setting a bit in a VDP reg, and the choice affects all sprites.

Quote

>Are there two different Name Tables like one for Background and one for Sprites?

The sprites don't use a name table in the sense that the background does, since they're not thunked into a grid. Rather you have 64 sprites (again I'm talking about the sms specifically), and there's an few arrays in vram that holds the coordinates (in screen pixels) and tile index for each one:
$3f00-$3f3f : (64 bytes) the y coordinates for each of the 64 sprites.
$3f40-$3f7f : (64 bytes) seemingly unused.
$3f80-$3fff : (128 bytes) 64 pairs of bytes which give (in order) the x coordinate and the tile to use for each sprite.

Unfortunately, there's no attribute byte for sprites (you'd think they'd have stuck it in $3f40-$3f7f but they didn't), so you can't flip x and y axes of sprites. That's a real tile-eater.

Quote

> Chris :o)

You mean to tell me after all of this programming stuff, the VDP in the master system can't flip sprites!!?? Forget tile eater..That makes me want to slam my monitor on the ground and constantly whack it with a golf club! My god, all those games had to draw the same tile in two different directions!!? No wonder they took the time to give Hayato different direction animations; they had to (Main character from Kenseiden)! I'm gunna continue my work but damn...That just really destroied the quality of the system. I think even the Atari 5200 supported sprite flipping.

Chris :o|

Quote

> You mean to tell me after all of this programming stuff, the VDP in the master system can't flip sprites!!??

Hey, it was in all the documents.

Quote

> Forget tile eater..That makes me want to slam my monitor on the ground and constantly whack it with a golf club! My god, all those games had to draw the same tile in two different directions!!?

Or flip them via the CPU and update in vsync (naturally, flipping time is limited).
It's not all that bad. I'd never trade nonflipped 16 color sprites for flippable 3 (er 4) color NES sprites.

Quote

> No wonder they took the time to give Hayato different direction animations; they had to (Main character from Kenseiden)!

In the case of kenseiden, it wouldn't have much mattered. The Hayato character's sprite tiles are loaded from rom into VRAM for every frame of animation, since the full range of his animations would have far exceeded the available tiles anyway, even with flipping.

Quote

>I'm gunna continue my work but damn...That just really destroied the quality of the system.

It's a pain, but not so much. It just forces the programmer to be a bit more clever.
At least we have background tile flipping. Backgrounds tend to eat up tiles very fast, so being able to stretch one's resources with tile flipping is a benefit.
Anyway, I think we're all a long way from having enough artwork to fill up the available vram anyhow. The sms dev scene, small as it is, has a serious drought of artists.

Quote

> I think even the Atari 5200 supported sprite flipping.

Since the 5200 is so closely related to the atari 8-bits, I am fairly sure they did not. However, since they had one color sprites that were taken from CPU addressable memory manually flipping was as simple as a table lookup.

Quote

> Chris :o|

My documentation being a draft, I know it is nearly full of bullshit, and not very clear in some case ^_^
I strongly suggest avoiding using it for references purpose as of yet.
I'll try to do an update of it someday.

Quote

> The SMS instead has 16k. There's enough for 384 tile definitions, the name table, and the table of sprite coordinates.

480 or so. Anyway, on a technical point of view all 512 can be used but in regular cases, being filled with the name table and sprite table they are garbage.
Also note you can have two name table and switch between them quickly. I think Quartet does it on title screen.

You can draw sprites in the regular background area.
Like Space Harrier does it (not very well, though).
Golden Axe does it too, but filling the sidespace with the real background, the background tile flipping attribute is no use there.

Quote

> You can draw sprites in the regular background area.

That is, sprites in the generic term for moving object sense, not hardware sprites.

Quote

> Like Space Harrier does it (not very well, though).
> Golden Axe does it too, but filling the sidespace with the real background, the background tile flipping attribute is no use there.

Laser Ghost, Thunder Blade, R Type are other games that make larger moving (and flippable) objects by drawing them as tiles directly onto the background. The obvious drawbacks there are that they are not overlaid onto the background, they are the background themselves, so the non-object parts of the shape that should show through to the background will just be blank pixels (golden axe being an exception) and objects must move in 8-pixel increments. But, no sprite size limits, and flippable tiles, ain't a bad deal.

Quote

> > The SMS instead has 16k. There's enough for 384 tile definitions, the name table, and the table of sprite coordinates.

> 480 or so. Anyway, on a technical point of view all 512 can be used but in regular cases, being filled with the name table and sprite table they are garbage.

Duh, that's right. Using the usual layout of sticking the name table at $3800 and sprite table after that, you can fit 448 tiles. I support you can use the two in the vram provided between the y sprite positions and the x-y pairs, plus there's enough for another 8 between the name table and the sprite table. Which gives 458. 16384 bytes - 1536 for the name table - 256 for the sprite table all divided by 32 bytes/tile gives 456, which doesn't account for the two extra in the sprite table, so it matches up.

Like I said, I've never come anywhere near using up those tiles.

Quote

> Also note you can have two name table and switch between them quickly. I think Quartet does it on title screen.

That would have to be it, I once theorized that they used some kind of palette swap or v-scrolling in horizontal blank trick (before I realized that's not possible on the sms) before, but now it makes sense.

No wonder half of my codes don't even work! But, do you see why before I spent time planning and learning things about the system before I went in "Gung-Ho!" screaming bullets 'n rage? Your draft document was the only thing I've been using so far. The registers are correct but some of the bit data for the registers is wrong. Like the video modes. I did things exactly as your document wanted but when I later ran them under Meka, I got Video Mode 4 (I wanted Video Mode 2) and stuff. Hopefully, since Colecovision, SG1000 and MSX1 use the same hardware I might find a more appropriate doc out there.

One good thing about your draft though is that it gave me an idea of what I was up against.

Chris :o)

The videomode correspondance table is somewhat as follow:

/* 10.00 */ Mode 0
/* 00.00 */ Mode 1
/* 00.01 */ Mode 2
/* 01.00 */ Mode 3
/* 00.10 */ Mode 4
/* 00.11 */ Mode 5

Author	Message
Consolemu Guest	Graphics Programming Posted: Tue Aug 22, 2000 5:41 pm
Consolemu Guest	It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics? Chris :o)

Belgarath Guest	Posted: Tue Aug 22, 2000 6:16 pm
Belgarath Guest	Quote > It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics? > Chris :o) In the case of the SMS, tiles are made up of sets of bitplanes (4 planes per pixel), and when you take the corresponding bits for a plane (ie, all bits at position 0 of each plane), you get a numerical value for each pixel. This value is then used to look into the colour palette to determine which colour gets displayed. This is similar to VGA programming, where each byte in the video memory identifies an entry in the 256 colour palette. Many other systems use a similar scheme.

Belgarath Guest	Re: Graphics Programming... ignore my last post, this one makes slightly more sense... :) Posted: Tue Aug 22, 2000 6:28 pm
Belgarath Guest	Quote > > It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics? > > Chris :o) Ignore my last post, it was confused. :) In the case of the SG-1000, there are 16 fixed colors. My interpretation is that the sprite, when it's written into the VRAM, is associated with a specific colour, therefore any "on" bits cause the VDP to display the colour associated with the sprite, and "off" bits are displayed as transparent? I dunno on that one, the docs are a little vague. :) Hmm... great way to start off my first set of posts to the board. :)

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Welcome abroard! Posted: Tue Aug 22, 2000 7:44 pm
	If you feel the need so, you can introduce yourself to everyone ^_^ Chris, good luck. As for tiles and sprites stuff in SMS mode, it might be helpful for you to check my old SMS Power demo. Don't take the code as an exemple, it is pure crap. But being very simple, you should be able to figure out some things you don't understand yet.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Tue Aug 22, 2000 8:24 pm
	Quote > It's not like I'm giving up or asking to be spoon fed already but now is the time where I seriously need help. Not really code, persay, but the concept behind doing graphics for video game consoles. I've done VGA programming before in Mode 13h or 320x200x8(256) where each memory address represents pixel data and holds the pallete index value. But, as I'm looking at this document I don't see anything like that. I see things like Tile address, Tile Encoding ,etc. Out of all that, the only thing I understand is the Tile Encoding and I kinda understand Tiles starting address. Tile Encoding in SG1000 is simple because each bit represents a pixel. And Tiles starting address you just tell the register what address your tiles start at. What I don't get is if the tiles are only 1 and 0's, how do you interface them with the pallete? How does it know whether to display red or organge, etc. Also, once you set up a simple tile, how do you put it on the screen? How does the system finally display it's graphics? I think one problem is that you're starting with SG-1000 modes, and the Sg-1000 doc (I assume you're looking at the one in the tech documents secrtion of this site) is rather sparse. It's better suited as a guide for someone familiar with the SMS to use as a reference for the difference betweent the SMS and the Sg-1000 (or the SMS using sg-1000 display modes). You'd be better off reading Richard Talbot Walkins' sms doc, which goes into more detail. Quick review of how tile based consoles work. Let's step away from the definitions of tiles first. Let's go back to the very first ibm PC's. The first PC's used a video card called a monochrome display adaptor (MDA). Basically, it had only a one color (whatever that color was depended on the color of your monitor, we'll say black and white for now) video mode with an unchangable font. The characters were printed in a 80 x 24 grid. This was a simple tile mode. In video memory, each byte represented one tile (character) the way each byte represents one pixel in mode 13h: byte zero of vram stored the tile index for character on the upper right of the screen. Byte one stored the tile index for the second character to the left on the top row. Byte 80 stored the index for the leftmost character on the second row, etc. So we have one byte defining each 'cell' that a tile can be in. Each byte stored sequentially, left to right, then top to bottom. But how does that single byte determine what goes in that 8x8 (or was it 8x16? i forget) map? On the card, patterns for each character in the character set were stored in rom, 256 in all. For every byte in video ram that cooresponded to a 'cell' on the screen, the video card used the value of that byte to find the appropriate pattern in the rom set. That pattern was used to output the final video signal which went to the monitor. Thus, drawing one character to the screen took only one byte, not eight (or 16). This saved video ram (which was costly in those days) and speed up screen updates (since CPU's were very slow, and there's no point wasting all that time anyway). IBM (or whoever developed the MDA) logically chose to make each tile index coorespond with the ASCII equivelant (i.e. tile #65 is an image of a capital letter 'A') So, we have tiles (patterns of characters, here stored in ROM), and the tile map (i.e. the grid of cells that tiles can live in, here an 80x40 grid, one byte per cell). On the SMS, the tile map is often called the name table. Don't know why, I don't think it's a very good name. The MDA didn't support color because color monitors were so expensive nobody could afford to buy them. And besides, who needs 'em, the B in IBM stands for Business. The CGA cards (color graphics adaptor) came along later and added color text modes (As well as color and mono graphics modes, but we'll ignore that for now). It kept the same overall architecture of the MDA in text mode, however, for every tile index byte in the tile map, there's also a second byte that the set the attributes. The attribute byte dedicates 4 bits for choosing the color of the tile(from a fixed 16 color palette), 3 bits to choose the background color of the tile (from a fixed 8 color palette), and one to select whether or not it blinks every second (or so). I'm not sure if the CGA text mode puts the attribute byte right after the index byte (i.e. byte 0 is top left index, byte 1 is top left attribute, byte 2 is top second left index, etc...) or if the attribute byte is stored in a second array (i.e. byte 0 is top left index, byte 1920 is top left attribute). Or something else entirely. The Sg-1000 does something similar to that. All tiles are simple declared in terms of "color or no color" (1 or 0). When you place a tile in the tile map, you also set an attribute byte in the tile map to choose the foreground color (the tiles all share the same background color I think.). As for how to define the actual tile image, most monochromatic 8x8 tile systems use the same system: one byte defines the pattern for one line (one bit per pixel, bit 7 is the leftmost, bit 0 the rightmost), so 8 bytes in a row determine the whole tile. In tasm, you can define a tile using binary notation like this: .db %00000000 .db %00111100 .db %01100110 .db %01101110 .db %01110110 .db %01100110 .db %00111100 .db %00000000 and kind of 'see' it, while you draw it. The % is binary notation, the whole thing assembles to 8 bytes. Generally (and in the case of the sg-1000), each tile is stored sequentially in video memory. If you specify tile 4 ina cell of a tile map, the video processor will add 4 (index number) times 8 (numbers of bytes per tile) to the start of the tile data to find the appropriate table. The sg-1000 also offers sprites. The 8x8 sprites are defined the same way, and their patterns are stored in a table the same way. However, they don't have to live in a cell. You just tell which tile number you want to use, what color you want, and where to put it. Those values are stored in a table in vram somewhere. that was wordy, but I hope it made sense. Sg-1000 and SMS specific: The Richard Talbot Walkins document explains more clear how to access video ram, but it's important to note that it's -not- mapped to the z80 memory space in any way. That is; ld a,$40 ld ($3f00),a does -not- put $40 in video ram. All video ram access is done through ports $bf and $be. You output the address in video ram you want to write to to port $bf (small byte first, and you add $4000 to the address for writes), and put the data you want to put in it in port $be. The vram pointer increases by 1 each time you write to $be, so if you have to copy a bunch of data to vram sequentially (As you often will) you only need to set the address once.

Consolemu Guest	Posted: Tue Aug 22, 2000 9:56 pm
Consolemu Guest	Alright, so lemme get this straight. Back in the day, the actual bitmap data was stored on ROM in the VGA card. The VRAM responded to byte data in a linear matrix of 80x24. So that means that there were 1920 bytes or around 1K of video memory, right? And from the DOS text mode programming mode that I'm used to, I guess that's where it originated from. And when data was written to row 24, data in the first row would be disgarded and all data below would be shifted up by 1 row. Now, in the SG1000 there's a bitmap tile and an attribute tile? Because Zoop's doc did say that there were 2 colors per tile. So, I guess the attribute byte must work like this... `0 = Color 1 1 = Color 2 .db %00000000 .db %00111100 .db %01100110 .db %01101110 .db %01110110 .db %01100110 .db %00111100 .db %00000000` Where 0 equals one color and 1 equals another. But, if there's 13 other colors, how do you select those? But, back to tiles, I understand that Name Table refers to the address where the tile data is, but how does the system finally display the graphics? Let's use your 0 tile example and say that cell 1 or the first cell is your 0 tile. Is there some way that I could tell the system: display Name Table Cell 1 at 12,12? And what I mean by 12,12 is X,Y and that's by the top/left corner of the screen. Chris :o)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Tue Aug 22, 2000 11:27 pm
	Quote > Alright, so lemme get this straight. Back in the day, the actual bitmap data was stored on ROM in the VGA card. The VRAM responded to byte data in a linear matrix of 80x24. So that means that there were 1920 bytes or around 1K of video memory, right? About 2k, yeah.I'm not sure if there was some extra vram for other things Quote > And from the DOS text mode programming mode that I'm used to, I guess that's where it originated from. And when data was written to row 24, data in the first row would be disgarded and all data below would be shifted up by 1 row. Yes. Or, rather, there was no row 24. When it was necessary to scroll up one row, the CPU manually moved the whole mess back 80 bytes and cleared row 23 for the next line of text. The video card didn't have any special hardware to support scrolling. Before I respond to the rest of this, I'll attempt to clarify the main points: The tile map (aka name table) and tile data are two -seperate- arrays in vram. The tile data is the actual data that defines the tiles' images. (it's an array of small bitmaps: the format of the bitmaps depends on the system). The tile map/name table is an array that says which tiles are drawn into which cells. In the case of the sms, each cell is two bytes long. The first byte of a cell tells which tile to put in that cell(). The second byte allows you to set special attributes, like whether that cell should be flipped, whether it should appear in front of or behind sprites, etc. Any tile can go into any cell. Every cell uses one tile or another (even if you've set a cell's byte to zero, tile zero will be displayed.) The reason I pointed out the way the old MDA cards work is the stress the importance of the tile map: You can, of course, stick any letter or character in any cell of the dos screen. The SMS and SG-1000 work the same way, except that the tile data (again, this is separate from the tile map) is not hard coded into rom, you can decide what every character (tile) looks like. You could even load the old MDA font in if you want to. Quote > Now, in the SG1000 there's a bitmap tile and an attribute tile? > Because Zoop's doc did say that there were 2 colors per tile. So, I guess the attribute byte must work like this... I'm still foggy on the details of the sg1000's tile map (zoop's documentation leaves me somewhat confused as to how colors are set). But if I interpret correctly: When he says 2 color, I think he means, background and foreground color (that's a common notation for 'monochrome', 2 color.) Quote > `> 0 = Color 1 > 1 = Color 2` `0 = background color 1 = foreground color (the actual color used to display the foreground color is determined by an attribute byte in the name table).` `Quote` `> .db %00000000 > .db %00111100 > .db %01100110 > .db %01101110 > .db %01110110 > .db %01100110 > .db %00111100 > .db %00000000 >` > Where 0 equals one color and 1 equals another. But, if there's 13 other colors, how do you select those? Again, the tile image is defined in terms of 'foreground' (1) and 'background' (0). The actual colors that are displayed when that tile appears in the tilemap depends on what the background color is set to (it's the same for all tiles) and what that cell's attributes are. Quote > But, back to tiles, I understand that Name Table refers to the address where the tile data is, as mentioned above, the name table is the map of cells. Quote >but how does the system finally display the graphics? Let's use your 0 tile example and say that cell 1 or the first cell is your 0 tile. Is there some way that I could tell the system: > display Name Table Cell 1 at 12,12? (I assume you mean display tile 1 in the twelfth cell to the left on the twelfth row of cells from the top). absolutely. On the SMS (not on the sg1000): ;Assumes the display is disabled or we are in vblank ld a,$18 ;Set the VDP pointer to $7b18, which cooresponds to the cell at (12,12) in the name table. out ($bf),a ;Set the VDP by writing the low byte first... ld a,$7b out ($bf),a ;Then the high byte. Anything output to $be will be written to VRAM starting at $7b18 ld a,1 ;Use tile 1 in that cell out ($be),a ld a,0 ;(this one gets put in $7b19) out ($be),a ;No attributes (not flipped x or y, behind sprites, etc) Done. BTW, if you're curious how I arrived at $7b18: The name table begins at $3800 (it can be moved elsewhere, but I always keep it at $3800). To write to VRAM, the vram pointer must be set to the target address ANDed with $4000 (aka bit 14 must be set). Equivelant to adding $4000 in this case. So, the writable name table begins at $7800 There are two bytes per cell, and 32 cells per row, so 64 bytes per row. The twelfth row begins at nametable plus 768 (64 12). The twelfth character of that row is another 24 bytes down (12 x 2). So, that's the name table plus 792 ($318 in hex). $7800 + $318 = $7b18.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	(forgot to explain asterisk) Posted: Tue Aug 22, 2000 11:30 pm
	Quote > The tile map/name table is an array that says which tiles are drawn into which cells. In the case of the sms, each cell is two bytes long. The first byte of a cell tells which tile to put in that cell(*). The second byte allows you to set special attributes, like whether that cell should be flipped, whether it should appear in front of or behind sprites, etc. the display is disabled or we are in vblank (the asterisk is for a footnote I forgot to make. specifically, I am aware that it's actually the first byte and and first bit of the second byte (i.e. 9 bits) that determine which tile is used in that cell, but I figure sometimes details confuse the main point, so I left it out).

Consolemu Guest	Ohhhh, so now... Posted: Wed Aug 23, 2000 12:25 am
Consolemu Guest	Now the gears in my brain are starting to spin together :o) Again, lemme back track cause this is a lot of stuff to soak in at once. All images are stored in the Tile Data. The screen is setup by a Name Table (btw, let's refer to the Tile Table as Name Table because it's easier to distinguish) and that name table refers to the Tile Data. Woah, something else just clicked! You said that the tiles the Name Table can be loaded from any tile in the Tile Data array, right? Because I noticed with the help of Nesticle and Meka that many games will have a huge garble for Tile Data but when you look at the Name Table you see the entire title screen (Well, besides the sprites). That's amazing! Oh, but.. Back to back tracking...So...The Name Table is a linear array of cells and each cell holds the location of the tile in the Tile Data array and little information like priorties and coloring? And the VDP depends on the Name Table to display the entire screen? So, really characters can't be display where ever on the screen like I assumed. When I said 12,12 I meant 12 pixels across and 12 pixels down; not 12 columns across and 12 rows down. And the VDP has a register pointer that points to the address where the Name Table begins? The VDP calculates all the information from both the Name Table and the Tile Data Array to finally render the screen? Hell, that just broke a big gaping hole in the ice! No wonder games repeated use of the same tiles because the name table can refer to the same tile as much as it wants! Hold on...Lemme get up and scream and do a carwheel!! Phew! Ok, I'm calming down. But I still have more questions. Mainly about sprites. Unlike background tiles, can sprites be displayed anywhere (And when I say anywhere I mean pixel by pixel anywhere)? Is there a set for tile data and a set for character data? Two different Tile Data arrays? Are there two different Name Tables like one for Background and one for Sprites? Chris :o)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Ohhhh, so now... Posted: Wed Aug 23, 2000 1:13 am
	Quote > Now the gears in my brain are starting to spin together :o) > Again, lemme back track cause this is a lot of stuff to soak in at once. All images are stored in the Tile Data. The screen is setup by a Name Table (btw, let's refer to the Tile Table as Name Table because it's easier to distinguish) and that name table refers to the Tile Data. Woah, something else just clicked! You said that the tiles the Name Table can be loaded from any tile in the Tile Data array, right? Because I noticed with the help of Nesticle and Meka that many games will have a huge garble for Tile Data but when you look at the Name Table you see the entire title screen (Well, besides the sprites). That's amazing! Oh, but.. > Back to back tracking...So...The Name Table is a linear array of cells and each cell holds the location of the tile in the Tile Data array and little information like priorties and coloring? And the VDP depends on the Name Table to display the entire screen? So, really characters can't be display where ever on the screen like I assumed. When I said 12,12 I meant 12 pixels across and 12 pixels down; not 12 columns across and 12 rows down. And the VDP has a register pointer that points to the address where the Name Table begins? The VDP calculates all the information from both the Name Table and the Tile Data Array to finally render the screen? Hell, that just broke a big gaping hole in the ice! No wonder games repeated use of the same tiles because the name table can refer to the same tile as much as it wants! Hold on...Lemme get up and scream and do a carwheel!! (shouting to be heard above the noise) Yes, you've got it. Another thing you may find interesting, is that when you redraw a tile, every cell that uses that tile will display the changed version on the next screen frame. If you fill the name table with zeroes so that every cell displays tile zero, and at every vblank you update an animation with a spinning cross, the whole screen will be filled with spinning crosses. For a demonstration of what I mean, load the SMSPower Demo and watch the tile display window change while the display changes. Notice the tile with the red is being updated every frame to look like motion. Everywhere where that tile is used in the main display you see that motion. There are two main reasons why tiled display modes are so often used in older systems: 1-It allows you to set an entire 8x8 block of background in a single memory write (or two). In the case of the sms, screen updates would take up to 16 times longer. Scrolling would probably not be possible. 2-It saves on video ram needs: the sms has a 256 x 192 pixel display area. If every pixel could be independantly set, that would require 24k of ram (assuming two pixels per byte). And then there'd be more memory needed for sprites. The SMS instead has 16k. There's enough for 384 tile definitions, the name table, and the table of sprite coordinates. Quote > Phew! Ok, I'm calming down. But I still have more questions. Mainly about sprites. Unlike background tiles, can sprites be displayed anywhere (And when I say anywhere I mean pixel by pixel anywhere)? Yep, any old damn where. Quote > Is there a set for tile data and a set for character data? >Two different Tile Data arrays? Do you mean, seperate sets of tiles for sprites and the background? Sort of. There are 384 tiles shared between the sprites and the background. The name table can refer to all 384 of them, whereas the sprites can use either the first 256 or everything after the first 256 (which 192 tiles). You choose which by setting a bit in a VDP reg, and the choice affects all sprites. Quote >Are there two different Name Tables like one for Background and one for Sprites? The sprites don't use a name table in the sense that the background does, since they're not thunked into a grid. Rather you have 64 sprites (again I'm talking about the sms specifically), and there's an few arrays in vram that holds the coordinates (in screen pixels) and tile index for each one: $3f00-$3f3f : (64 bytes) the y coordinates for each of the 64 sprites. $3f40-$3f7f : (64 bytes) seemingly unused. $3f80-$3fff : (128 bytes) 64 pairs of bytes which give (in order) the x coordinate and the tile to use for each sprite. Unfortunately, there's no attribute byte for sprites (you'd think they'd have stuck it in $3f40-$3f7f but they didn't), so you can't flip x and y axes of sprites. That's a real tile-eater. Quote > Chris :o)

Consolemu Guest	Wha Wu ...What!!?? Posted: Wed Aug 23, 2000 2:06 am
Consolemu Guest	You mean to tell me after all of this programming stuff, the VDP in the master system can't flip sprites!!?? Forget tile eater..That makes me want to slam my monitor on the ground and constantly whack it with a golf club! My god, all those games had to draw the same tile in two different directions!!? No wonder they took the time to give Hayato different direction animations; they had to (Main character from Kenseiden)! I'm gunna continue my work but damn...That just really destroied the quality of the system. I think even the Atari 5200 supported sprite flipping. Chris :o\|

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	have some chamomile tea Posted: Wed Aug 23, 2000 3:24 am
	Quote > You mean to tell me after all of this programming stuff, the VDP in the master system can't flip sprites!!?? Hey, it was in all the documents. Quote > Forget tile eater..That makes me want to slam my monitor on the ground and constantly whack it with a golf club! My god, all those games had to draw the same tile in two different directions!!? Or flip them via the CPU and update in vsync (naturally, flipping time is limited). It's not all that bad. I'd never trade nonflipped 16 color sprites for flippable 3 (er 4) color NES sprites. Quote > No wonder they took the time to give Hayato different direction animations; they had to (Main character from Kenseiden)! In the case of kenseiden, it wouldn't have much mattered. The Hayato character's sprite tiles are loaded from rom into VRAM for every frame of animation, since the full range of his animations would have far exceeded the available tiles anyway, even with flipping. Quote >I'm gunna continue my work but damn...That just really destroied the quality of the system. It's a pain, but not so much. It just forces the programmer to be a bit more clever. At least we have background tile flipping. Backgrounds tend to eat up tiles very fast, so being able to stretch one's resources with tile flipping is a benefit. Anyway, I think we're all a long way from having enough artwork to fill up the available vram anyhow. The sms dev scene, small as it is, has a serious drought of artists. Quote > I think even the Atari 5200 supported sprite flipping. Since the 5200 is so closely related to the atari 8-bits, I am fairly sure they did not. However, since they had one color sprites that were taken from CPU addressable memory manually flipping was as simple as a table lookup. Quote > Chris :o\|

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	SG-1000 Posted: Wed Aug 23, 2000 7:09 am
	My documentation being a draft, I know it is nearly full of bullshit, and not very clear in some case ^_^ I strongly suggest avoiding using it for references purpose as of yet. I'll try to do an update of it someday.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Just a little fix: Posted: Wed Aug 23, 2000 7:14 am
	Quote > The SMS instead has 16k. There's enough for 384 tile definitions, the name table, and the table of sprite coordinates. 480 or so. Anyway, on a technical point of view all 512 can be used but in regular cases, being filled with the name table and sprite table they are garbage. Also note you can have two name table and switch between them quickly. I think Quartet does it on title screen.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Sprite flipping Posted: Wed Aug 23, 2000 7:17 am
	You can draw sprites in the regular background area. Like Space Harrier does it (not very well, though). Golden Axe does it too, but filling the sidespace with the real background, the background tile flipping attribute is no use there.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Sprite flipping (clarity for the reader) Posted: Wed Aug 23, 2000 7:29 am
	Quote > You can draw sprites in the regular background area. That is, sprites in the generic term for moving object sense, not hardware sprites. Quote > Like Space Harrier does it (not very well, though). > Golden Axe does it too, but filling the sidespace with the real background, the background tile flipping attribute is no use there. Laser Ghost, Thunder Blade, R Type are other games that make larger moving (and flippable) objects by drawing them as tiles directly onto the background. The obvious drawbacks there are that they are not overlaid onto the background, they are the background themselves, so the non-object parts of the shape that should show through to the background will just be blank pixels (golden axe being an exception) and objects must move in 8-pixel increments. But, no sprite size limits, and flippable tiles, ain't a bad deal.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Just a little fix: Posted: Wed Aug 23, 2000 7:43 am
	Quote > > The SMS instead has 16k. There's enough for 384 tile definitions, the name table, and the table of sprite coordinates. > 480 or so. Anyway, on a technical point of view all 512 can be used but in regular cases, being filled with the name table and sprite table they are garbage. Duh, that's right. Using the usual layout of sticking the name table at $3800 and sprite table after that, you can fit 448 tiles. I support you can use the two in the vram provided between the y sprite positions and the x-y pairs, plus there's enough for another 8 between the name table and the sprite table. Which gives 458. 16384 bytes - 1536 for the name table - 256 for the sprite table all divided by 32 bytes/tile gives 456, which doesn't account for the two extra in the sprite table, so it matches up. Like I said, I've never come anywhere near using up those tiles. Quote > Also note you can have two name table and switch between them quickly. I think Quartet does it on title screen. That would have to be it, I once theorized that they used some kind of palette swap or v-scrolling in horizontal blank trick (before I realized that's not possible on the sms) before, but now it makes sense.

Consolemu Guest	Re: SG-1000 Posted: Wed Aug 23, 2000 10:46 am
Consolemu Guest	No wonder half of my codes don't even work! But, do you see why before I spent time planning and learning things about the system before I went in "Gung-Ho!" screaming bullets 'n rage? Your draft document was the only thing I've been using so far. The registers are correct but some of the bit data for the registers is wrong. Like the video modes. I did things exactly as your document wanted but when I later ran them under Meka, I got Video Mode 4 (I wanted Video Mode 2) and stuff. Hopefully, since Colecovision, SG1000 and MSX1 use the same hardware I might find a more appropriate doc out there. One good thing about your draft though is that it gave me an idea of what I was up against. Chris :o)

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: SG-1000 Posted: Wed Aug 23, 2000 6:35 pm
	The videomode correspondance table is somewhat as follow: /* 10.00 / Mode 0 / 00.00 / Mode 1 / 00.01 / Mode 2 / 01.00 / Mode 3 / 00.10 / Mode 4 / 00.11 */ Mode 5

Forums

View topic - Graphics Programming