Sound, Blank Screens and ASM

[EmOneGarand]

Ok, first off, I know I should have posted this under programming but my other attempts to get help in the subject of programming for the lynx have gone unanswered.

 

Everything I see for programming sound is all written in C, all my tutorials are in ASM so it makes learning how to write programs for the Lynx difficult... Secondly I've written a little demo based on the ASM from the Tutorial I've been following yet I get the text but the screen is always blank, I've gone over all the display definitions AND the sprite defs and can't find anything wrong.

 

Anybody who is developing for the Lynx writing in ASM? If so, a little help please.

 

Source

[Duranik]

Hello

 

You should set the Reloadable depth in SPRCTL1, in your example

 

titleSCB

dc.b %11000001

dc.b %00010000 ; <=== Set Hsize, Vsize

dc.b %00000000

dc.w 0

dc.w title_sprite

dc.w 0

dc.w 0

dc.w $100 ; <==

dc.w $100 ; <==

dc.b $01,$23,$45,$67,$89,$AB,$EF,$00

 

 

Regards

 

Roland / Duranik

Edited November 26, 2006 by Duranik

[Nimtene]

Duranik makes a good point about this.

I didn't understand this concept very well

back when I wrote that source code. You

need to specify the Horizontal and Vertical

scale of your sprites, then your title screen

and main game sprites should appear fine.

[+karri]

And if you want to produce some sound you need to set values to certain registers:

 

FD20 40 - amplitude

FD21 1F

FD22 3F - DAC output (this is what really gets to the speaker. It changes all the time.)

FD23 2C

FD24 8D - pitch

FD25 00

FD26 6E - count register (it also changes by itself all the time)

FD27 B2

 

In asm something like:

 

lda #$40

sta $fd20

...

 

should do the trick. There is some more info in my Multicart 2006 blog

 

--

Karri

[EmOneGarand]

I have to say thank you so much hasn't been easy finding docs about this kind of thing

[TailChao]

Oh, you're using the CFighter demo I sent you. Very good, this is a good source to learn from.

 

On a side note about sprites, there are a few things you might want to remember.

When working with many similar sprites (like in a background) that share a palette and size (but have a different position, like you would want to tile the same pattern across the screen), you can tell Suzy to not reload all of this information to speed up the drawing process like this:

 

L1BG10_col	  db 0
L1BG10_SCB	  dc.b $01,$10,$00
			dc.w L1BG11_SCB; < This tells the Lynx to draw "L1BG11_SCB" immediately after finished with this sprite, so you can save code space.
			dc.w L1BG1_data
L1BG10_x		dc.w 095
L1BG10_y		dc.w 207
L1BG10_scx	  dc.w $100
L1BG10_scy	  dc.w $100
			dc.b $56,$00

L1BG11_col	  db 0
L1BG11_SCB	  dc.b $01,$08,$00; < The $08 here tells the Lynx to not reload scaling or distortion information and to reuse the palette information from the previous sprite drawn
			dc.w L1BG12_SCB
			dc.w L1BG1_data
L1BG11_x		dc.w 127
L1BG11_y		dc.w 207

 

Also, as a measure to conserve space if you are not using hardware collisions (which are slow anyway)

 

L1BG10_col	  db 0;	  < You can remove this extra value to save RAM
L1BG10_SCB	  dc.b $01,$10,$00
			dc.w L1BG11_SCB
			dc.w L1BG1_data
L1BG10_x		dc.w 095
L1BG10_y		dc.w 207
L1BG10_scx	  dc.w $100
L1BG10_scy	  dc.w $100
			dc.b $56,$00

 

Also, try playing with these registers:

$fc04

$fc06

 

$FDA0 through $FDAF and

$FDB0 through $FDBF

 

 

Write some random value to them, or just apply an INC or DEC instruction, I think you'll find the results helpful.

Edited November 26, 2006 by TailChao

[sage]

Ok, first off, I know I should have posted this under programming but my other attempts to get help in the subject of programming for the lynx have gone unanswered.

 

Everything I see for programming sound is all written in C, all my tutorials are in ASM so it makes learning how to write programs for the Lynx difficult... Secondly I've written a little demo based on the ASM from the Tutorial I've been following yet I get the text but the screen is always blank, I've gone over all the display definitions AND the sprite defs and can't find anything wrong.

 

Anybody who is developing for the Lynx writing in ASM? If so, a little help please.

 

Source

 

You might have seen this:

 

LynxDev

 

Sound:

 

look into sound.asm / .def / .mac in the BLL package.

This might give you an idea how to use the sound. This engine is quite powerful but very hard to compose sound for it.

[EmOneGarand]

Oh, you're using the CFighter demo I sent you. Very good, this is a good source to learn from.

 

On a side note about sprites, there are a few things you might want to remember.

When working with many similar sprites (like in a background) that share a palette and size (but have a different position, like you would want to tile the same pattern across the screen), you can tell Suzy to not reload all of this information to speed up the drawing process like this:

 

L1BG10_col	  db 0
L1BG10_SCB	  dc.b $01,$10,$00
			dc.w L1BG11_SCB; < This tells the Lynx to draw "L1BG11_SCB" immediately after finished with this sprite, so you can save code space.
			dc.w L1BG1_data
L1BG10_x		dc.w 095
L1BG10_y		dc.w 207
L1BG10_scx	  dc.w $100
L1BG10_scy	  dc.w $100
			dc.b $56,$00

L1BG11_col	  db 0
L1BG11_SCB	  dc.b $01,$08,$00; < The $08 here tells the Lynx to not reload scaling or distortion information and to reuse the palette information from the previous sprite drawn
			dc.w L1BG12_SCB
			dc.w L1BG1_data
L1BG11_x		dc.w 127
L1BG11_y		dc.w 207

 

Also, as a measure to conserve space if you are not using hardware collisions (which are slow anyway)

 

L1BG10_col	  db 0;	  < You can remove this extra value to save RAM
L1BG10_SCB	  dc.b $01,$10,$00
			dc.w L1BG11_SCB
			dc.w L1BG1_data
L1BG10_x		dc.w 095
L1BG10_y		dc.w 207
L1BG10_scx	  dc.w $100
L1BG10_scy	  dc.w $100
			dc.b $56,$00

 

Also, try playing with these registers:

$fc04

$fc06

 

$FDA0 through $FDAF and

$FDB0 through $FDBF

 

 

Write some random value to them, or just apply an INC or DEC instruction, I think you'll find the results helpful.

I tried the BlockSCB approach to reloading, Handy doesn't like it much gives me an overlap error. Dunno if that'd be the same if I run it on the actual Hardware.

 

Is there a way to define extra sets of Palettes? or is it only one universal palette def with the values in the dc.b altering the color?

 

My other problem at the moment is scrolling, it scrolls but when any scrolling object just touches the edge of the screen it disappears leaving a huge gap between the next segement. Dunno if theirs a definition for that I overlooked.

[EmOneGarand]

Ok, first off, I know I should have posted this under programming but my other attempts to get help in the subject of programming for the lynx have gone unanswered.

 

Everything I see for programming sound is all written in C, all my tutorials are in ASM so it makes learning how to write programs for the Lynx difficult... Secondly I've written a little demo based on the ASM from the Tutorial I've been following yet I get the text but the screen is always blank, I've gone over all the display definitions AND the sprite defs and can't find anything wrong.

 

Anybody who is developing for the Lynx writing in ASM? If so, a little help please.

 

Source

 

You might have seen this:

 

LynxDev

 

Sound:

 

look into sound.asm / .def / .mac in the BLL package.

This might give you an idea how to use the sound. This engine is quite powerful but very hard to compose sound for it.

I have, I couldn't get obj files created by Sprpck to convert to olb files. I'm not too keen on how to use cross langauge sources (especially how to compile a C and ASM combination source) so I'm trying to stick with one programming language until I get a better grip on it.

Edited November 27, 2006 by EmOneGarand

[TailChao]

Some help with scrolling

The Lynx's display world works like this, with two modes, an 8-Bit mode and a 16-Bit (considerable 9-Bit) for positioning sprites. The phenomenon you are describing is probably when a sprite reaches (0,y) or (x,0) it will immediately be positioned on (255,y) or (x,255) if you continue to decrease the position. This will make it jump/disappear. To prevent this, we can move the display window to a position away from the x=0 and y=0 lines. (95,132) is optimal, and we can accomplish this by writing #95 to $FC04 and $132 to $FC06.

 

LDA#95
STA $FC04
LDA#132
STA $FC06

 

The top left of the screen is now 95,132, so you must reposition things appropriately, but now you can scroll easily. You can also just keep your sprites in a static position and alter $FC04 and $FC06 to scroll.

 

You can define as many palettes as you want, but of course, can only show one at a time. It's as easy as this:

pal DP 000,005,555,5B5,00B,50B,00F,50F,B0F,F5F,FBF,FFF,505,000,B0B,FBF
pal2 DP FFF,0FF,EE5,5B5,FFB,50B,22F,56F,B0F,F9F,FFF,FFF,5E6,111,B0B,FBF
;color#: 0,  1,  2,  3,  4,  5,  6,  7,  8,  9,  A,  B,  C,  D,  E,  F

When you want to change palettes, just use SETRGB

 

SETRGB pal2

Would change to pal2

 

You can also modify the color registers directly (They are at $FDA0 through $FDAF (G) and $FDB0 through $FDBF (RB)) and get many cool color cycling effects this way.

 

As for the sprite error, did you make sure that you left the last sprite with a "0" in its link. If you have a loop of sprite drawing, Handy will crash, as will a Lynx. I never remember an "Overlap" error, but if you neglected top leave the "0" at the end of your drawing trail, the SCB will loop back upon itself and the sprite draw limit will exceed.

 

Hope this helps

TC

[EmOneGarand]

Some help with scrolling

The Lynx's display world works like this, with two modes, an 8-Bit mode and a 16-Bit (considerable 9-Bit) for positioning sprites. The phenomenon you are describing is probably when a sprite reaches (0,y) or (x,0) it will immediately be positioned on (255,y) or (x,255) if you continue to decrease the position. This will make it jump/disappear. To prevent this, we can move the display window to a position away from the x=0 and y=0 lines. (95,132) is optimal, and we can accomplish this by writing #95 to $FC04 and $132 to $FC06.

 

LDA#95
STA $FC04
LDA#132
STA $FC06

 

The top left of the screen is now 95,132, so you must reposition things appropriately, but now you can scroll easily. You can also just keep your sprites in a static position and alter $FC04 and $FC06 to scroll.

 

You can define as many palettes as you want, but of course, can only show one at a time. It's as easy as this:

pal DP 000,005,555,5B5,00B,50B,00F,50F,B0F,F5F,FBF,FFF,505,000,B0B,FBF
pal2 DP FFF,0FF,EE5,5B5,FFB,50B,22F,56F,B0F,F9F,FFF,FFF,5E6,111,B0B,FBF
;color#: 0,  1,  2,  3,  4,  5,  6,  7,  8,  9,  A,  B,  C,  D,  E,  F

When you want to change palettes, just use SETRGB

 

SETRGB pal2

Would change to pal2

 

You can also modify the color registers directly (They are at $FDA0 through $FDAF (G) and $FDB0 through $FDBF (RB)) and get many cool color cycling effects this way.

 

As for the sprite error, did you make sure that you left the last sprite with a "0" in its link. If you have a loop of sprite drawing, Handy will crash, as will a Lynx. I never remember an "Overlap" error, but if you neglected top leave the "0" at the end of your drawing trail, the SCB will loop back upon itself and the sprite draw limit will exceed.

 

Hope this helps

TC

Not quite sure where that code goes :/ I've experimented and havn't gotten any results. I'm not sure what you mean by applying 0 to the last sprite. Otherwise I'm quite surprised how quickly things can shape up hah hah.

[Nimtene]

I'm not sure what you mean by applying 0 to the last sprite.

 

He means that if you're linking sprites, then make sure the last one doesn't

link back to another sprite in the list, or you'll get a sprite limit error in 'Handy.'

 

For example:

floor1SCB	 dc.b $c1,$10,$00
		  dc.w floor2SCB; <==Links to floor section 2
		  dc.w floor_sprite1
floor1_x	  dc.w 0
floor1_y	  dc.w 50
		  dc.w $100
		  dc.w $100
		  dc.b $01,$C5,$EF,$67,$89,$A0,$00,$00

floor2SCB	 dc.b $c1,$08,$00
		  dc.w floor3SCB; <==Links to floor section 3
		  dc.w floor_sprite2
floor2_x	  dc.w 50
floor2_y	  dc.w 50

floor3SCB	 dc.b $c1,$08,$00
		  ;dc.w floor1SCB	 ;<==BAD, would create endless sprite loop.
		  dc.w 0			  ;<==GOOD, closes out this sprite list.
		  dc.w floor_sprite3
floor3_x	  dc.w 150
floor3_y	  dc.w 50

[sage]

 

I have, I couldn't get obj files created by Sprpck to convert to olb files. I'm not too keen on how to use cross langauge sources (especially how to compile a C and ASM combination source) so I'm trying to stick with one programming language until I get a better grip on it.

 

This is easy:

char variable;

functionname()
{
#asm
 xref _variable

lda _some_variable
sta #$FDB0
#endasm
}

Edited November 28, 2006 by sage

[+karri]

 

I have, I couldn't get obj files created by Sprpck to convert to olb files. I'm not too keen on how to use cross langauge sources (especially how to compile a C and ASM combination source) so I'm trying to stick with one programming language until I get a better grip on it.

 

This also depends on which C-compiler you choose. The old one used olb files you could just link in. The new one has a different object format and is trickier.

 

The new cc65 compiler at www.cc65.org works like this. What you need to do is:

 

sprpck -t6 -p2 mysprite.bmp

 

then you need to edit a file calles mysprite.s with this content:

. global mysprite

.segment RODATA

mysprite: .incbin mysprite.spr

 

After this you need to compile it:

ar65 -t lynx -o mysprite.o mysprite.s

 

And finally link it with your main program...

 

I have a rule in my Makefile that does this automatically:

 

# Rule for making a *.o file out of a *.bmp file

%.o : %.bmp

$(SPRPCK) -t6 -p2 $<

$(ECHO) .global _$* > $*.s

$(ECHO) .segment \"$(RODATA_SEGMENT)\" >> $*.s

$(ECHO) _$*: .incbin \"$*.spr\" >> $*.s

$(AS) -t lynx -o $@ $(AFLAGS) $*.s

$(RM) $*.s

$(RM) $*.pal

$(RM) $*.spr

 

In the main C-program you need to define

 

extern char mysprite[];

 

to be able to use the sprite in your sprite structure.

 

typedef struct {
unsigned char b0;
unsigned char b1;
unsigned char b2;
void *next;
void *bitmap;
int posx, posy, sizex, sizey;
char palette[8];
} sprite_t;

static sprite_t Smysprite = {
0xc0, 0x10, 0x20,
0, &mysprite,
0, 0, 0x100, 0x100,
0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef
};

tgi_sprite(&Smysprite);

 

--

Karri

Edited November 28, 2006 by karri