26 replies to this topic

[shadow460]

First one: What's the Halt function compared to the normal 6502's registers? I know the MARIA uses that to stop Sally, doesn't Maria do that while she's reading Line RAM?

What's in my mind is this:
Normal 6502 registers:
Accumulator
X&Y
Stack Pointer
Status

...but where does that Halt line fit in?

In the Status register, you normally have negative, overflow, BRK command, decimal mode IRQ disable, zero, and carry modes. The guid I'm looking at here shows a blank bit there in the status register. Is that where the Halt command fits in?

IIRC, that's the only difference in the 6502 and Sally.

OK, I don't quite get how the 6502 has added this up:

A 16-bit addition routine.  $20,$21 + $22,$23 = $24,$25
		
		   CLC		 clear the carry
		   LDA $20	 get the low byte of the first number
		   ADC $22	 add to it the low byte of the second
		   STA $24	 store in the low byte of the result
		   LDA $21	 get the high byte of the first number
		   ADC $23	 add to it the high byte of the second, plus carry
		   STA $25	 store in high byte of the result
		   
		   ... on exit the carry will be set if the result could not be
			   contained in 16-bit number.

And here's what I came up with regarding this routine with some sample number I threw in (they're too small to have used the carry feature, though--would I need to clear the carry flag in this case?)

; addition
CLC
LDC $20
ADC $22
STA $24
LDA $21
ADC $23
STA $25

; 0010 0000 $20
; 0010 0010 $22
; -------------
; 0100 0010 $24
; =============
; 0010 0001 $21
; 0010 0011 $23
; -------------
; 0100 0100 $25

; therefore $20,$21 + $22,$23 = $24,$25

; so if the values are set like this...
; $20 = 3
; $21 = 4
; $22 = 2
; $23 = 5
; ...then $24 = 5 and $25 = 9 for an addition routine that does this:
; 3,4 + 2,5 = 5,9

Forgive me if I seem dumb, but when it comes to Sally, well, I kinda am. Anyway, it's $30,$31 where the data at $30 is "midnight" and $31 is "18", so I'm going to enjoy a few Z-80 based games and call it a night.

Let me know where I've gone goofy on this.

Edited by shadow460, Fri Nov 10, 2006 12:26 AM.

[kenfused]

shadow460, on Fri Nov 10, 2006 1:24 AM, said:

Let me know where I've gone goofy on this.

You dont have RAM at $20-$25. Those addresses are maria/tia registers.
Zero page RAM starts at $40

--Ken

[DanBoris]

shadow460, on Fri Nov 10, 2006 1:24 AM, said:

First one: What's the Halt function compared to the normal 6502's registers? I know the MARIA uses that to stop Sally, doesn't Maria do that while she's reading Line RAM?

What's in my mind is this:
Normal 6502 registers:
Accumulator
X&Y
Stack Pointer
Status

...but where does that Halt line fit in?

The halt line is not actually visible to the software running on the cpu. The halt line simply stops the 6502 clock in synchronization with the instruction cycle, and tri-states the data and address bus so that the MARIA can take control of the bus.

Dan

Edited by DanBoris, Fri Nov 10, 2006 11:55 AM.

[shadow460]

kenfused, on Fri Nov 10, 2006 8:08 AM, said:

shadow460, on Fri Nov 10, 2006 1:24 AM, said:

Let me know where I've gone goofy on this.

You dont have RAM at $20-$25. Those addresses are maria/tia registers.
Zero page RAM starts at $40

--Ken

Sounds 7800 specific. My example was written based on information from a generic 6502 programming guide. Knowing the 7800's registers will help greatly once I've learned the basics.

How's everything else, though? Assuming I was going to add values from RAM, is the sample program correct?

Edited by shadow460, Sat Nov 11, 2006 12:18 AM.

[kenfused]

shadow460, on Sat Nov 11, 2006 1:16 AM, said:

Sounds 7800 specific. My example was written based on information from a generic 6502 programming guide. Knowing the 7800's registers will help greatly once I've learned the basics.

How's everything else, though? Assuming I was going to add values from RAM, is the sample program correct?

Looks good to me

[shadow460]

Cool, and thanks. More questions to come, most certainly.

[EricBall]

Your 16 bit arithmetic is fine. Now, for a real mind warp: the same code is used irrespective of whether you're adding two unsigned numbers, two signed numbers or two 8.8 fixed point fractional numbers. Life gets a little more interesting if you're mixing types or sign extending, but for the 16 bit value + 16 bit value the code is the same. How you, the programmer, use the values gives them meaning.

From the games POV MARIA DMA is transparent. So you can happily do game logic while MARIA is processing the screen. Exceptions to this are:
1. STA WSYNC which is similar to the 2600 version - the CPU pauses until the start of the next line. You get 7 CPU cycles before DMA HALTs the processor. (Enough time to update a MARIA register or two.)
2. BIT MSTAT which reflects whether MARIA is in VBLANK or not.
3. Display List Interrupt, which causes an NMI before the start of a display list zone. The NMI interrupt routine executes independently of the main code, but and be used to do interesting things at specific lines. (Note: the main code shouldn't use WSYNC if you are also using DLIs.)

For the most part, write your code and just spin on MSTAT to keep track of frames (just like a 2600 program often waits on INTIM).

[shadow460]

To my understanding, Sally does whatever computations are needed for graphical changes, then sends that info to a MARIA register, which should be the Line RAM.
So if I'm drawing a ship at a given coordinate, and the trackball is moved just a tad to the right, Sally will load the current x coordinates for each pixel of each line, add one to each, and sends them to Line RAM. Maria's drawing something from a different section of Line RAM, and when she needs to read what Sally just wrote, Maria halts Sally, reads the RAM, then Maria lets Sally go while she processes the newly read line RAM.

Now here's where my understanding gets even foggier (this is Maria related anyway...haven't got that far yet...) Isn't a Display List simply a list of what to put at each pixel on a given horizontal line?

I need to look at a memory map, including the cart based Pokey chip to fully understand how the IC's tie in. then I'd need to look at Pac Man's original thread about XBoarD to see how that fits in with the rest of the family.

[gdement]

Quote

To my understanding, Sally does whatever computations are needed for graphical changes, then sends that info to a MARIA register, which should be the Line RAM.

The 6502 (called Sally I presume) only does what your program code tells it to do. It doesn't do anything behind-the-scenes involving graphics.

Quote

Isn't a Display List simply a list of what to put at each pixel on a given horizontal line?

It's not pixel oriented. The display list is a list of every graphical object (sprite) that needs to be drawn on that scanline. Each object is declared in it's own header - a sequence of headers makes up a display list.
The information in each header provides a pointer to the graphic data, the horizontal position, width, and what color format to use.

You (=Sally) fill in these parameters in a properly formatted data structure. When Maria tries to render a scanline, it will read the information you filled in and render the line RAM. Line RAM is an internal function of the Maria - the 6502 doesn't touch it. There are some Maria registers that you can adjust, controlling things like what screen resolution to use, or to configure the color palette. Those are mapped into the memory space at particular addresses. But nobody touches line RAM - that's maria's internal memory for screen rendering.

[EricBall]

gdement is correct, but more detail:

The MARIA DPPH/DPPL registers form a 16 bit address pointer to the start of the "Display List List" which is loaded at the start of every frame. The DLL is a series of 3 byte entries stored in RAM. Each DLL entry contains a 16 bit address pointer to the Display List, some flags, and the number of lines (1-16) to display using this Display List. (This is often called a zone.)

Each Display List is a series of 4 and 5 byte entries stored in RAM. Each Display List entry contains a 16 bit address pointer to either bitmap or tile list, 1 byte horizontal position, width (1-32 bytes), and palette (1 of 8).

So to put a sprite on the screen, the program adds the appropriate entry to the display list(s) based on the vertical position.

Edited by EricBall, Wed Nov 15, 2006 10:31 AM.

[shadow460]

*thinks for a few minutes*
I think I'm understanding a little bit. I gotta absorb this, though. I kinda got off on a tanget there.
Anyway, let's assume, then, that I want to draw Pac-Man on the screen with one ghost. No maze, no dots, etc. A single display list, then, might point to five bitmaps showing Pac-Man's mouth clised, then open a little, etc, all the way to fully open. Likewise, another DL would have headers pointing to sprites with the ghost's eyes facing different directions.
Once I tell Maria to render both objects, she will look to see which scanlines I wanted them rendered on, then write each line to her own RAM. Once I get the headers on a displlay list, though, Maria does the rest, if I understand correctly.

I got ahead of myself a little, though. I still need to finish the 6502 tutorials and be able to write some simple programs that Sally could run, then I'll figure out where the rest of the family fits in.

[gdement]

shadow460, on Wed Nov 15, 2006 4:08 PM, said:

Anyway, let's assume, then, that I want to draw Pac-Man on the screen with one ghost. No maze, no dots, etc. A single display list, then, might point to five bitmaps showing Pac-Man's mouth clised, then open a little, etc, all the way to fully open. Likewise, another DL would have headers pointing to sprites with the ghost's eyes facing different directions.

The DLL is a data structure that tells the Maria which display list to use for what scanlines. Maria will then only look at *1* display list for the duration of the scanline.
That display list contains headers for every object that will appear on that scanline. So if you have a display list with headers that point to 5 bitmaps of Pac-Man, then you'll end up seeing all 5 of those Pac-Man images rendered together on the same scanline.
If you just want 1 ghost and 1 pacman on the same scanline, then your display list would have 1 header pointing to a ghost bitmap, and 1 header pointing to a Pac-Man bitmap. Animation would be accomplished by changing the graphics pointers between frames.

Quote

Once I tell Maria to render both objects, she will look to see which scanlines I wanted them rendered on, then write each line to her own RAM. Once I get the headers on a displlay list, though, Maria does the rest, if I understand correctly.

That's correct. Once you have the data structures set up, Maria will scan that information during DMA and render it.

[shadow460]

OK, I see.
Sally is indeed the custom 6502 used in the 7800. I didn't want it confused with the typical 6502, though.

So next question...how are the bitmaps plotted? On the Apple II, I could plot a bitmap of any sort using x,y coordinates. Here's an example of a low res square smiley face written in Apple Basic: (I'm a little rusty on the code, so there might be errors...)

5 REM set low res graphics mode
10 GR
15 REM set color to magenta
20 color = 1
25 REM plot horizontal lines from 10,10 to 10,20 and 10,20 to 20,20
30 hlin 10,20 at 10
40 hlin 10,20 at 20
45 REM plot vertical lines in a similar fashion
50 vlin 10,20 at 10
60 vlin 10,20 at 20
65 REM plot eyes and nose
70 plot 13,13
80 plot 17,13
85 REM plot mouth
90 plot 13,17
100 plot 17,17
110 hlin 14,16 at 18

Now do I need to plot out x,y coordinates or perhaps vertical and horizontal lines for each pixel in the bitmap?
Also, where can I find a list of the colors Maria uses?

[EricBall]

From a programming perspective, Sally is a standard 6502. (Versus the NES 2A03 which is a 6502 missing decimal mode but with an on-board sound generator.) Oh, and a POKEY is a memory mapped device. It is controlled via normal stores to certain addresses, just like TIA sound. (Which addresses depends on whether it's on cart or an xBoard.)

For colors - see 7800 Color Palette in M.E.S.S., though I can't find the color selector demo.a78 as quickly.

You can't really think of the 7800 in terms of bitmaps like the Apple ][ or any other computer or console which uses a frame buffer for graphics. You certainly could allocate a chunk of RAM to use as a bitmap, set up some static display lists with entries pointing to the RAM, then have your program update the RAM like a frame buffer. Unfortunately, I think you'd find there isn't enough RAM or CPU time to do that method justice.

As Yoda says, "you must unlearn what you have learned."

7800 graphics data is stored as bytes, not pixels, with each byte representing 2 to 8 pixels depending on the graphics mode. The simplest two graphics modes are called 160A (2 bits/pixel, 160 pixels/line) and 320A (1 bit/pixel 320 pixels/line). The remaining four graphics modes don't have MSB to LSB = left to right bit to pixel mapping.

So say we want a 160A sprite which looks like a 4x4 pixel circle in 3 colors (to give a nice highlight):

0 1 2 0
1 1 3 2
1 1 1 1
0 1 1 0

which would translate to

DC.B %00011000, %01011110, %01010101, %00010100

Color = 0 translates to transparent or background (at least for 160A), assuming you have "Kangaroo Mode" turned off.

Well, not really. Due to how the 7800 handles graphics, the data is stored with each line on a separate page & upside down, thus:

	ORG	$F000
BALL
	DC.B	%00010100
	ORG	$F100
	DC.B	%01010101
	ORG	$F200
	DC.B	%01011110
	ORG	$F300
	DC.B	%00011000

Now, to display this in the center of the screen, you would create the following in RAM:

DLL
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	7, >DL0, <DL0
	DC.B	4, >DL1, <DL1; num lines, display list pointer
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	16, >DL0, <DL0
	DC.B	8, >DL0, <DL0

DL1
	DC.B	<BALL, 31, >BALL, 78; graphics pointer, 32-width, X-pos
DL0
	DC.B	0,0; end of display list

For things like backgrounds there are a couple of options. The first is to store the background as a large sprite. The other is to use "character tiles", where the display list entry points to a series of bytes, which are then used as the LSB of the sprite pointer. This requires more DMA cycles, but uses less ROM. You can also easily update the tile list instead of the display list entries.

Edited by EricBall, Thu Nov 16, 2006 11:53 AM.

[Schmutzpuppe]

> As Yoda says, "you must unlearn what you have learned."

Well said (And a very good explanation)

[shadow460]

You knew I was gonna start asking questions about Pokey...I'll have to absorb this when I'm a little more awake.

[supercat]

EricBall, on Thu Nov 16, 2006 11:47 AM, said:

Color = 0 translates to transparent or background (at least for 160A), assuming you have "Kangaroo Mode" turned off.

Why'd Atari name the graphics mode after the arcade game if they weren't going to port it to the 7800 (using Kangaroo mode, of course)?

[Shannon]

Man this makes DLI's on the 8-bit computers look simple.

It's like a madman mutated the 8-bit DLI's and ended up with this.

[gdement]

Shannon, on Fri Nov 17, 2006 11:47 PM, said:

Man this makes DLI's on the 8-bit computers look simple.

It's like a madman mutated the 8-bit DLI's and ended up with this.

I don't know anything about the A8, but DLI's on the 7800 are simple. You just put a flag in the DLL, and you'll get an interrupt whenever Maria hits that spot.

[EricBall]

gdement, on Sat Nov 18, 2006 2:52 AM, said:

It's like a madman mutated the 8-bit DLI's and ended up with this.

Although the 7800 may share some terminology with the A8/5200 (i.e. display list), there's really nothing in common.

Shannon, on Fri Nov 17, 2006 11:47 PM, said:

I don't know anything about the A8, but DLI's on the 7800 are simple. You just put a flag in the DLL, and you'll get an interrupt whenever Maria hits that spot.

Yeah, you just have to remember the DLI happens when MARIA finishes DMA in the previous zone.

[Shannon]

Display lists on the A8 define what graphics mode is used on each line. Tells the A8 where in memory to look for the graphics (bitmap only). Allows execution of code during vertical and horizontal blanks. Probably a couple of more things I dont remember off the top of my head.

The 7800 sounds like it extends on that by allowing you to control sprites thru the display list, whereas on the A8 sprites where seperate entities from the bitmap.

Unless I'm mis-understanding what is being said on the thread.

It's been years since I even read up on A8 display lists so my memory is a bit fuzzy.

Edited by Shannon, Sat Nov 18, 2006 6:43 PM.

[DanBoris]

At the most fundemental level you could say that the display list on the 7800 and the A8 do the same thing, they both define to the graphics chip how to generate the display, but the exact details of how this happens are quite different. For example as you point out the A8 doesn't use the display list to control sprites, but on the 7800 all graphics are generated via the display list. The display list on the 7800 is also a lot more flexible and gives a lot more control over how the screen is drawn.

Dan

Shannon, on Sat Nov 18, 2006 7:42 PM, said:

Display lists on the A8 define what graphics mode is used on each line. Tells the A8 where in memory to look for the graphics (bitmap only). Allows execution of code during vertical and horizontal blanks. Probably a couple of more things I dont remember off the top of my head.

The 7800 sounds like it extends on that by allowing you to control sprites thru the display list, whereas on the A8 sprites where seperate entities from the bitmap.

Unless I'm mis-understanding what is being said on the thread.

It's been years since I even read up on A8 display lists so my memory is a bit fuzzy.

[shadow460]

Just out of curiosity, which graphics chips did the A8's use? Was it ANTIC or something else?

[Shannon]

DanBoris, on Sat Nov 18, 2006 8:25 PM, said:

At the most fundemental level you could say that the display list on the 7800 and the A8 do the same thing, they both define to the graphics chip how to generate the display, but the exact details of how this happens are quite different. For example as you point out the A8 doesn't use the display list to control sprites, but on the 7800 all graphics are generated via the display list. The display list on the 7800 is also a lot more flexible and gives a lot more control over how the screen is drawn.

Dan

Actually what I was saying it sounded like the 7800 display list were a mutation (expanded upon so to speak) of the A8 display lists. But thanks for the info.

[Bruce Tomlin]

I really wouldn't go so far as to call them "sprites". A proper sprite allows you to set the X and Y position.

How the 7800 graphics work is that you're setting up a bunch of bitmaps all over the screen. Moving them around is the tricky part, because you have to rebuild the DLs to move them vertically. Holey DMA is the only vertical support you get for doing sprites, and you still have to put both halves of the sprite into separate DL zones.