12 replies to this topic

[Gorf]

...sorry for the long-winded post but.....her goes...


Im driving poor ol' PacManPlus insane trying to get him to explain to me
exactly what is goin on with the DLL/DL...its not at all his fault....Im just rather
thick at first when I deal with unfamiliar hardware. So maybe with a chorus of
you pounding it into my noggin, I'll finally get it so I can write a higly efficient
32 sprite full screen character map kernal(is it actually called a Kernal with the
7800?)

I need this many sprites to do more robust Warbirds. Bob's DLL template
example is not a static disply that you simply update...he does tell me that
the example can be VERY optimized by only updating th necessary fields of
the DLL that can remain.

Gorf would have serious trouble using the current example code from Bob( though
I am beyond greatful for him sharing it as its been very helpful in underatnding most
everything else so far concerning the 7800.)

His example was simple enough to add the other sprites but its showing
its inefficiency(as Bob said it would) when I get more than 24 sprites on the
screen at once. I need a static field updatable 'kernal' instead of a dynamic
list.

Anyway....

in a DLL,

.byte $4F,<DL,>DL

this is holey DMA mode, H16 at 16 rasters.....represents 16 rasters on the screen, correct?

If I want 192 vertical lines I need 13 such entries in my DLL, yes?

Now, here is where Im having some trouble understanding.

Above we have the DLL pointing to all the same DL's...
Im having trouble with two things.

The 'software'ish nature of the Y postion:

I know that for sprites, you take your Y position and shift it right 4 to get your
zone of interest and add that to the sprites hi byte address field.....Im still not
sure what you do with the lower four bits because these are obviously the offset
into the zone.

I think I gather from what Bob was trying to explain to me ( most gracious man
that he is) that you need to stuff them in to the display list list zone that the sprite
will be in, in the offset field of that DLL? If this is the case, how does one handle two
different sprites in the same zone? I know Im looking at this wrong somehow....can
anyone help ol' Bob get my head around this?

The DLL/DL relationship:

My trouble here is clearly the relationship between the DL's and the DLL.
I need 32 sprites and I intend to use a full screen of characters for the back
ground stars and such. What is wrong or not wrong with the DLL/DL below?

DL:

; one char map:
				.byte	MAPLO, WM|IND, MAPHI, PAL|WIDTH, HPOS
;32 sprites
				.byte	SPR00LO,   PAL|WIDTH, SPR00HI, HPOS ;0
				.byte	SPR01LO,   PAL|WIDTH, SPR01HI, HPOS ;1
				.byte	SPR02LO,   PAL|WIDTH, SPR02HI, HPOS ;2
				.byte	SPR03LO,   PAL|WIDTH, SPR03HI, HPOS ;3
				......
				......
				......
				.byte	SPR31LO,   PAL|WIDTH, SPR31HI, HPOS ;31
				.byte	00,00,00	   ;end

 
DLL:
				.byte	$02, 0, 0			  ;   no holey DMA, 3 blank lines 
				.byte	$09, 0, 0			  ;   no holey DMA, 10 blank lines 
				.byte	$4F,  <DL, >DL	;   1st  16 rasters of visible   display and can show all sprites of DL1 in this zone0 
				.byte	$4F,  <DL, >DL	;   2nd 16 rasters of visible   display and can show all sprites of DL1 in this zone1 
				.byte	$4F,  <DL, >DL	;   3rd 16 rasters of visible   display and can show all sprites of DL1 in this zone2 
				.byte	$4F,  <DL, >DL	;   4th 16 rasters of visible   display and can show all sprites of DL1 in this zone3 
				.byte	$4F,  <DL, >DL	;   5th 16 rasters of visible   display and can show all sprites of DL1 in this zone4
				.byte	$4F,  <DL, >DL	;   6th 16 rasters of visible   display and can show all sprites of DL1 in this zone5 
				.byte	$4F,  <DL, >DL	;   7th 16 rasters of visible   display and can show all sprites of DL1 in this zone6 
				.byte	$4F,  <DL, >DL	;   8th 16 rasters of visible   display and can show all sprites of DL1 in this zone7 
				.byte	$4F,  <DL, >DL	;   9th 16 rasters of visible   display and can show all sprites of DL1 in this zone8
				.byte	$4F,  <DL, >DL	; 10th 16 rasters of visible   display and can show all sprites of DL1 in this zone9
				.byte	$4F,  <DL, >DL	; 11th 16 rasters of visible   display and can show all sprites of DL1 in this zone10
				.byte	$4F,  <DL, >DL	; 12th 16 rasters of visible   display and can show all sprites of DL1 in this zone11
				.byte	$4F,  <DL, >DL	; 13th 16 rasters of visible   display and can show all sprites of DL1 in this zone12
				.byte	$0F, 0, 0			 ; no holey DMA 16 blank lines 
				.byte	$0E, 0, 0			 ; no holey DMA 15 blank lines 
				.byte	$00,$00,$00,$00  ; end

What is missing? What do I have too much of? Does this belong in my recycle bin its so not there?


I appreciate any indulgence from anyone who might dare try chiseling through my think skull
this complex graphics chip.

Thanks

Gorf

[Crazyace]

Hi,

A couple of differences.

1: You set the blank DLL's to point to a DL at address 0. They should be pointing to an empty DL ( ie: 2 bytes of 0,0 )
2: All of your display DLL's point to the same DL - they should be pointing to 13 different DL's

If you have 32 sprites active in all zones you'll need nearly 2k for all the DL's and the DLL. For sprites that aren't present just set their high address to the holey area and they wont display.

For the Y address of the sprite - /16 gives the starting DL to modify.. you take the &15 and add to the high address - but this only gives you the starting part of the sprite - you then set the next DL's equiv entry to the (&15)-16 value.
( I could have mucked that up.. typing from memory here )

[DanBoris]

Gorf,

First, let me appologize if I say some things that are obvious, I am not sure which parts of the Maria you understnad and which you don't. Once of the things you might be missing is that the DL is a list of entires, not a single entry. So if you have 4 sprites in the same zone you will have a list of 4 entries in the DL, one right after the other. You mention that you are going to do a character mapped background. In this case you would probably want to put your character DL entries in the list first since they won't change, then put the sprite DL entries after them. Memory management can be a little tricky, you will need to have enough memory for each DL entry to hold the largest number of sprites that can appear in each zone.

Another thing to remember is that each sprite will probably have entries in two different DLs. If the DL falls on a even increment of 16 it will appear in only one zone, but in all other cases it will overlap two zones so you will have have a DL entry in the first zone to display the top of the sprite, then a second entry in the next zone to display the bottom.

Dan

[Gorf]

Hi,

Hey Crazy Ace and thanks for the reply,

Crazyace, on Mon Nov 3, 2008 11:35 AM, said:

1: You set the blank DLL's to point to a DL at address 0. They should be pointing to an empty DL ( ie: 2 bytes of 0,0 )

Oops my bad! Those are like you said supposed to be nulled....I do know that much.

Crazyace, on Mon Nov 3, 2008 11:35 AM, said:

2: All of your display DLL's point to the same DL - they should be pointing to 13 different DL's
If you have 32 sprites active in all zones you'll need nearly 2k for all the DL's and the DLL. For sprites that aren't present just set their high address to the holey area and they wont display.

Right, Bob pointed this out and I think I understood it and now I think so even more....

...what you are saying is I need a Display list( a list of 1 char and 32 sprite entries)
for every zone and in each DL I need all 32 sprites and the Char map as well?


Like this?

DLL:
				.byte	$02,  <NULL, >NULL ;   no holey DMA, 3 blank lines 
				.byte	$09,  <NULL, >NULL ;   no holey DMA, 10 blank lines 
				.byte	$4F,  <DL00, >DL00 ;   1st  16 rasters of visible   display 
				.byte	$4F,  <DL01, >DL01;   1st  16 rasters of visible   display 
				.......
				.byte	$4F,  <DL31, >DL31 ; 13th 16 rasters of visible   display
				.byte	$0F,  <NULL, >NULL ; no holey DMA 16 blank lines 
				.byte	$0E,  <NULL, >NULL ; no holey DMA 15 blank lines 
				.byte	$00,$00,$00,$00; end

DL00:

; one char map:
				.byte	MAPLO, WM|IND, MAPHI, PAL|WIDTH, HPOS
;32 sprites
				.byte	SPR00LO,   PAL|WIDTH, SPR00HI, HPOS;0
				......
				.byte	SPR31LO,   PAL|WIDTH, SPR31HI, HPOS;31
				.byte	00,00,00	;end
DL01:

; one char map:
				.byte	MAPLO, WM|IND, MAPHI, PAL|WIDTH, HPOS
;32 sprites
				.byte	SPR00LO,   PAL|WIDTH, SPR00HI, HPOS;0
				......
				.byte	SPR31LO,   PAL|WIDTH, SPR31HI, HPOS;31
				.byte	00,00,00	;end
......

DL31:

; one char map:
				.byte	MAPLO, WM|IND, MAPHI, PAL|WIDTH, HPOS
;32 sprites
				.byte	SPR00LO,   PAL|WIDTH, SPR00HI, HPOS;0
				......
				.byte	SPR31LO,   PAL|WIDTH, SPR31HI, HPOS;31
				.byte	00,00,00	;end

If so I see why it would take so much RAM. Dag nabbit!
It also explians why Im getting overwrites to some variables.
I am definitely over extending myself here. If only the emulators
recognized some form of external ram. Does the DL/DLL need
to be on the system RAM or can it indeed be on a cart RAM?

Quote

For the Y address of the sprite - /16 gives the starting DL to modify.. you take the &15 and add to the high address - but this only gives you the starting part of the sprite - you then set the next DL's equiv entry to the (&15)-16 value.
( I could have mucked that up.. typing from memory here )

So if a sprites y>>4 falls in to zone 8, I alter the DL in the list that represents DLL zone8?
If it falls inbetween 8 and 9 I have to update those DL's in DLL zone8 and DLL zone9?

Am I getting this?

Edited by Gorf, Mon Nov 3, 2008 6:34 PM.

[Gorf]

DanBoris, on Mon Nov 3, 2008 1:18 PM, said:

Gorf,

First, let me appologize if I say some things that are obvious, I am not sure which parts of the Maria you understnad and which you don't.

Oh please don't appologize!

I appreciate any help I can get with this even if its repeat info. Helps get it through my thick skull better.

DanBoris, on Mon Nov 3, 2008 1:18 PM, said:

Once of the things you might be missing is that the DL is a list of entires, not a single entry.
So if you have 4 sprites in the same zone you will have a list of 4 entries in the DL, one right after the other.

Yes, this much I can grasp now. If I want these four sprites in any of the 13 zones, I'd need to repeat
these 4 sprite lists 13 times.

DanBoris, on Mon Nov 3, 2008 1:18 PM, said:

You mention that you are going to do a character mapped background. In this case you would probably want to put your character DL entries in the list first since they won't change, then put the sprite DL entries after them.

It makes sense as its probably easier to index.

DanBoris, on Mon Nov 3, 2008 1:18 PM, said:

Memory management can be a little tricky, you will need to have enough memory for each DL entry to
hold the largest number of sprites that can appear in each zone.

I think I just might. Astro battles is probably the most heavy in sprite use at one time
only contending with Glaxian stage.

Astro battles alone would be 1 background charmap, 24 invader sprites, one player sprite, one missile
sprite and 6 invader bombs.

Also one bonus ship sprite(Gorf, saucer or hover craft) but that one only needs to be
in the top playfield zone.

that is 5(char) + (32 x 4) + 3(end) bytes or 136bytes per zone. DOH!

That comes to 13 x 136 bytes = 1768 bytes...yikes....Hey...I think I can fit that still!
1800 - 2000 is 2k and is where my current DL resides so thats still doable!
NICE!

DanBoris, on Mon Nov 3, 2008 1:18 PM, said:

Another thing to remember is that each sprite will probably have entries in two different DLs. If the DL falls on a even increment of 16 it will appear in only one zone, but in all other cases it will overlap two zones so you will have have a DL entry in the first zone to display the top of the sprite, then a second entry in the next zone to display the bottom.

Dan

I got that too but its good to have confirmation.

I appreciate your help Dan!

Thanks,

Gorf

[Mord]

Gorf, on Mon Nov 3, 2008 7:11 PM, said:

Does the DL/DLL need to be on the system RAM or can it indeed be on a cart RAM?

According to documentation I've read, DLs and DLLs need to be in system RAM due to time requirements and any DL can only cross at most 1 page boundary. (So a max size of 512 bytes) As to if any homebrewer ahead of us has found this is not the case, I dunno. If they contradict me, believe them.

[Gorf]

Mord, on Tue Nov 4, 2008 2:33 AM, said:

Gorf, on Mon Nov 3, 2008 7:11 PM, said:

Does the DL/DLL need to be on the system RAM or can it indeed be on a cart RAM?

According to documentation I've read, DLs and DLLs need to be in system RAM due to time requirements and any DL can only cross at most 1 page boundary. (So a max size of 512 bytes) As to if any homebrewer ahead of us has found this is not the case, I dunno. If they contradict me, believe them.

I believe that means that EACH list can only be two pages in length.
Otherwise I assume you can use the entire range of RAM in there.

My other guess is that external RAM should be fine if it is fast enough.
That also depends on the rate of the cart slot. I imagine it is not any
diferent than the rest of the system, but the Jaguar ROM slot is definitely
slower than the rest of the bus. The 7800 was developed in a time where
bus rate was consistant throughout in most designs.

[Mord]

Gorf, on Tue Nov 4, 2008 7:04 AM, said:

I believe that means that EACH list can only be two pages in length.
Otherwise I assume you can use the entire range of RAM in there.

My other guess is that external RAM should be fine if it is fast enough.
That also depends on the rate of the cart slot. I imagine it is not any
diferent than the rest of the system, but the Jaguar ROM slot is definitely
slower than the rest of the bus. The 7800 was developed in a time where
bus rate was consistant throughout in most designs.

It might be that the cart slot itself might not be fast enough, but the only way to really test that I guess would be to get one put together to test. :/ With the way the 7800 changes speed based on what it's using and which processor is in use, it could be a lot more trouble than it looks.

And yeah, any particular DL/DLL can't exceed 512 bytes, not 512 for all of them.


I really have to get down with seriously attempting to put something together on this console. All the reading and planning I'm doing won't mean a thing otherwise.

[Mitch]

It's also worth noting that the two Atari cart boards that support RAM seem to have slightly different timing.

Mitch

[Gorf]

External RAM either way would be fine. Then I could use the cart ram forvariables and such and the
internal RAM for lists.

[Crazyace]

It's way more fun if you write for the base system... ( although the use of ram for some 2600 projects like BDash is really cool )

[Gorf]

Crazyace, on Thu Nov 6, 2008 10:01 AM, said:

It's way more fun if you write for the base system... ( although the use of ram for some 2600 projects like BDash is really cool )

I'd want the extra ram so I can use the external for variables and the DLL's
and use the total 4k internally for a VIC-20 like frame buffer.

[Gorf]

Well good news!

I finally got my static display list to work and now pretty much fully understand
the display list format. I'll now have write some code and put it to use.

Its amazing just how many sprites can be displayed with no slow down using
a static list. Now to get some code working for updating the lists for animation.

Thanks to everyone who helped out!

Gorf