Forums

I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS!

Heliophobe, Memetic?

Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap.

Quote

> I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS!

Based on your advice I stuck a couple NOP's in between writing the X coordinates and tile numbers to the sprite tables... interesting, I hadn't realized there needed to be a delay.. fortunately using OTIR seems to giveenough delay between writes, if that's even what the problem was.

Quote

> Heliophobe, Memetic?

Hmmm? Still working, will probably keep going up until close to the deadline (then enough time for 1, maybe 2 hours of sleep before an 8-hour work day.)

There's more to it that what you saw in the sample I sent you, but it's far from completed. I hope to use it as a launchpad to develop a complete game in the future, hopefully with some collaberation with others (especially in the categories of graphics and level design).

Quote

>> I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS!
> Based on your advice I stuck a couple NOP's in between writing the X coordinates and tile numbers to the sprite tables... interesting, I hadn't realized there needed to be a delay.. fortunately using OTIR seems to giveenough delay between writes, if that's even what the problem was.

I worked again on the problem because sending my submission (actually, I was forced too..).
To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing.

push ix
pop ix

Does it.
It's a long delay, mind you.

Quote

> There's more to it that what you saw in the sample I sent you, but it's far from completed. I hope to use it as a launchpad to develop a complete game in the future, hopefully with some collaberation with others (especially in the categories of graphics and level design).

I'm not against helping a bit with graphics and design, but then there's probably much better artists than me :)

Quote

> I worked again on the problem because sending my submission (actually, I was forced too..).
> To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing.

Uh.
I really hadn't thought I was doing such a thing. who wants to see me curse again?

Quote

> push ix
> pop ix

> Does it.
> It's a long delay, mind you.

mmm.

Quote

> I'm not against helping a bit with graphics and design, but then there's probably much better artists than me :)

yeah, well, I wouldn't be one of them (i drew a neat explosion animation though).

Hey, me!
Get back to work!

Quote

> I worked again on the problem because sending my submission (actually, I was forced too..).
> To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing.

> push ix
> pop ix

> Does it.
> It's a long delay, mind you.

I didn't think it was possible to access the video ram during screen refresh, only during VBlank (or screen off). That "rule" kind of made sense, as the VDP needs continuous access to VRAM when reading the data for the line currently being displayed, so I'm confused now! :-)

Presumably a read or write can take place during line flyback, and the delay is needed to ensure two read or write requests don't happen on the same line (since only one byte per line can be latched)? I'd be interested to know the details.

Mike

You can access the VDP during refresh, many games does it.
Xenon 2 for exemple rewrite the sprite table during display to be able to display more than 64 sprites.

The delay is to be sure the VDP has enough time to read the data and increment its counter. It's acting a bit differently while refreshing, I guess.

If one byte is missed while writing the tilemap, tile index and attributes will be shifted by one.
I noticed it in my demo yesterday night:
the screen is separated in four parts, each with a different attributes (0, 4, 8 and 12). I noticed in some parts, tiles of the number of the attributes were displayed instead of the regular tiles.
Not sure if I'm clear..

Quote

>
> > I worked again on the problem because sending my submission (actually, I was forced too..).
> > To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing.

> > push ix
> > pop ix

> > Does it.
> > It's a long delay, mind you.

> I didn't think it was possible to access the video ram during screen refresh, only during VBlank (or screen off). That "rule" kind of made sense, as the VDP needs continuous access to VRAM when reading the data for the line currently being displayed, so I'm confused now! :-)

> Presumably a read or write can take place during line flyback, and the delay is needed to ensure two read or write requests don't happen on the same line (since only one byte per line can be latched)? I'd be interested to know the details.

> Mike

Quote

> I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS!

> Heliophobe, Memetic?

> Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap.

What tools are you all using to debug your programs? Specifically, are you debugging with the help of an emulator, or do you all have dev carts?

Just curious. (And no, I'm not participating in Y2Kode, I'm just an interested third party.)

--
Eric Quinn

Quote

>> Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap.
> What tools are you all using to debug your programs? Specifically, are you debugging with the help of an emulator, or do you all have dev carts?
> Just curious. (And no, I'm not participating in Y2Kode, I'm just an interested third party.)

I'm using a 32 kb dev card for testing, and mainly Meka for the rest.
I did use BrSMS in the early stage of developments to remind me Z80 basics, because its debugger is obviously better than the one in Meka.

Quote

> >> Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap.
> > What tools are you all using to debug your programs? Specifically, are you debugging with the help of an emulator, or do you all have dev carts?
> > Just curious. (And no, I'm not participating in Y2Kode, I'm just an interested third party.)

As for me:
primarily BRSMS, for its ability to set breakpoints and track instructions one by one (this could still be improved considerably). Allowing me to view ram and rom numerically, and see the contents of all registers (CPU and hardware) is of course a plus.

Also, Meka, for the ability to view the tiles and the palette graphically. (Very handy, and I like being able to click on the tile and see which number it is in vram). And the ability to slow down the emulation. And because sound works for me in meka but not brsms. The tech info box is handy too, since I can watch it 'live'.

I don't think BRSMS emulates the 8-sprite per line limit either.

I'd love to get my hands on a devcart, I have been intending to build an SMS reader and hack up a spare Afterburner in hopes of making one, but I haven't had the time to devote to it.
I'd still do the bulk of my debugging through emulators, however. I'll usually go through up to several hundred recompiles in a long session... or I used to. I seem to be getting better.

i presume the VDP performs memory management allowing the CPU to access VRAM every 16 memory cycles; 372nS*16 = 5.95microSec. OTIR is slightly faster than this (5.6microSec) so using a OUTI in a loop such as

CP B
JR NZ, disp

will work.

i also noticed that unlike the 9918, the sms vdp has 16bit vram access, allowing it to access vram fast enough for double the sprites per line.

a s out.

Quote

> i presume the VDP performs memory management allowing the CPU to access VRAM every 16 memory cycles; 372nS*16 = 5.95microSec. OTIR is slightly faster than this (5.6microSec) so using a OUTI in a loop such as
>
> CP B
> JR NZ, disp

> will work.

Thanks, I see what you mean! Why 16 memory cycles by the way, is that the number of cycles needed to read four bytes from VRAM?

I also take it the timing is different in 50Hz mode compared to 60Hz, which is (possibly) why sprites in games like Xenon 2 go to pot when you attempt to run at 60Hz?

Mike

slight correction -

OUTI sets the zero flag according to the results of reg B, which it decrements, so the compare isn't needed in the loop:

OUTI ;out byte (HL) to port (C), inc HL and dec B
JR NZ,-2 ; loop if B does not equal zero

the loop above allows 8 accesses per scan line during active display.

the 16 cycles - i read the 9918 spec. the time it takes to refresh 8 pixels, or 1 tile, the VDP has time for 4 accesses; one to read the name table entry (remember memory accesses are 16 bits wide) and 2 to read the tile data (4 bytes per line). the forth may be used for CPU VRAM access every 4th tile or to traverse the sprite table and get the data for 8 sprites.

PAL vs. NTSC timing - i'm not sure accept that the pal screen has 313 line instead of the NTSC 262, so the line frequency is only 20Hz different. I presume the memory cycle time is still the same though, 372nS.

i think i covered everything...

a s out.

Author	Message
Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Y2kode Posted: Wed Feb 28, 2001 2:00 am
	I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS! Heliophobe, Memetic? Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Wed Feb 28, 2001 3:20 am
	Quote > I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS! Based on your advice I stuck a couple NOP's in between writing the X coordinates and tile numbers to the sprite tables... interesting, I hadn't realized there needed to be a delay.. fortunately using OTIR seems to giveenough delay between writes, if that's even what the problem was. Quote > Heliophobe, Memetic? Hmmm? Still working, will probably keep going up until close to the deadline (then enough time for 1, maybe 2 hours of sleep before an 8-hour work day.) There's more to it that what you saw in the sample I sent you, but it's far from completed. I hope to use it as a launchpad to develop a complete game in the future, hopefully with some collaberation with others (especially in the categories of graphics and level design).

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Wed Feb 28, 2001 7:38 am
	Quote >> I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS! > Based on your advice I stuck a couple NOP's in between writing the X coordinates and tile numbers to the sprite tables... interesting, I hadn't realized there needed to be a delay.. fortunately using OTIR seems to giveenough delay between writes, if that's even what the problem was. I worked again on the problem because sending my submission (actually, I was forced too..). To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing. push ix pop ix Does it. It's a long delay, mind you. Quote > There's more to it that what you saw in the sample I sent you, but it's far from completed. I hope to use it as a launchpad to develop a complete game in the future, hopefully with some collaberation with others (especially in the categories of graphics and level design). I'm not against helping a bit with graphics and design, but then there's probably much better artists than me :)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	uh-oh Posted: Wed Feb 28, 2001 7:43 am
	Quote > I worked again on the problem because sending my submission (actually, I was forced too..). > To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing. Uh. I really hadn't thought I was doing such a thing. who wants to see me curse again? Quote > push ix > pop ix > Does it. > It's a long delay, mind you. mmm. Quote > I'm not against helping a bit with graphics and design, but then there's probably much better artists than me :) yeah, well, I wouldn't be one of them (i drew a neat explosion animation though). Hey, me! Get back to work!

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Accessing video RAM Posted: Wed Feb 28, 2001 12:24 pm
	Quote > I worked again on the problem because sending my submission (actually, I was forced too..). > To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing. > push ix > pop ix > Does it. > It's a long delay, mind you. I didn't think it was possible to access the video ram during screen refresh, only during VBlank (or screen off). That "rule" kind of made sense, as the VDP needs continuous access to VRAM when reading the data for the line currently being displayed, so I'm confused now! :-) Presumably a read or write can take place during line flyback, and the delay is needed to ensure two read or write requests don't happen on the same line (since only one byte per line can be latched)? I'd be interested to know the details. Mike

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: Accessing video RAM Posted: Wed Feb 28, 2001 1:40 pm
	You can access the VDP during refresh, many games does it. Xenon 2 for exemple rewrite the sprite table during display to be able to display more than 64 sprites. The delay is to be sure the VDP has enough time to read the data and increment its counter. It's acting a bit differently while refreshing, I guess. If one byte is missed while writing the tilemap, tile index and attributes will be shifted by one. I noticed it in my demo yesterday night: the screen is separated in four parts, each with a different attributes (0, 4, 8 and 12). I noticed in some parts, tiles of the number of the attributes were displayed instead of the regular tiles. Not sure if I'm clear.. Quote > > > I worked again on the problem because sending my submission (actually, I was forced too..). > > To be precise, delay are needed only if you're accessing the video memory while the screeen is refreshing. > > push ix > > pop ix > > Does it. > > It's a long delay, mind you. > I didn't think it was possible to access the video ram during screen refresh, only during VBlank (or screen off). That "rule" kind of made sense, as the VDP needs continuous access to VRAM when reading the data for the line currently being displayed, so I'm confused now! :-) > Presumably a read or write can take place during line flyback, and the delay is needed to ensure two read or write requests don't happen on the same line (since only one byte per line can be latched)? I'd be interested to know the details. > Mike

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Wed Feb 28, 2001 4:10 pm
	Quote > I've finished and submitted my lame entry to the Y2kode contest. Doing actual coding on the SMS is harder than I thought. I spent three days on this demo, and well, it sucks. Oh anyway. Guess I have learned a lots more things about the SMS! > Heliophobe, Memetic? > Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap. What tools are you all using to debug your programs? Specifically, are you debugging with the help of an emulator, or do you all have dev carts? Just curious. (And no, I'm not participating in Y2Kode, I'm just an interested third party.) -- Eric Quinn

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Wed Feb 28, 2001 4:13 pm
	Quote >> Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap. > What tools are you all using to debug your programs? Specifically, are you debugging with the help of an emulator, or do you all have dev carts? > Just curious. (And no, I'm not participating in Y2Kode, I'm just an interested third party.) I'm using a 32 kb dev card for testing, and mainly Meka for the rest. I did use BrSMS in the early stage of developments to remind me Z80 basics, because its debugger is obviously better than the one in Meka.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Thu Mar 01, 2001 12:19 am
	Quote > >> Sorry everybody for the lack of answers. I'm answering to Mike and Martin asap. > > What tools are you all using to debug your programs? Specifically, are you debugging with the help of an emulator, or do you all have dev carts? > > Just curious. (And no, I'm not participating in Y2Kode, I'm just an interested third party.) As for me: primarily BRSMS, for its ability to set breakpoints and track instructions one by one (this could still be improved considerably). Allowing me to view ram and rom numerically, and see the contents of all registers (CPU and hardware) is of course a plus. Also, Meka, for the ability to view the tiles and the palette graphically. (Very handy, and I like being able to click on the tile and see which number it is in vram). And the ability to slow down the emulation. And because sound works for me in meka but not brsms. The tech info box is handy too, since I can watch it 'live'. I don't think BRSMS emulates the 8-sprite per line limit either. I'd love to get my hands on a devcart, I have been intending to build an SMS reader and hack up a spare Afterburner in hopes of making one, but I haven't had the time to devote to it. I'd still do the bulk of my debugging through emulators, however. I'll usually go through up to several hundred recompiles in a long session... or I used to. I seem to be getting better.

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	Re: Accessing video RAM Posted: Fri Mar 02, 2001 4:36 am
	i presume the VDP performs memory management allowing the CPU to access VRAM every 16 memory cycles; 372nS*16 = 5.95microSec. OTIR is slightly faster than this (5.6microSec) so using a OUTI in a loop such as CP B JR NZ, disp will work. i also noticed that unlike the 9918, the sms vdp has 16bit vram access, allowing it to access vram fast enough for double the sprites per line. a s out.

Mike G Joined: 21 Apr 2000 Posts: 598 Location: Newcastle upon Tyne, England	Re: Accessing video RAM Posted: Fri Mar 02, 2001 12:11 pm
	Quote > i presume the VDP performs memory management allowing the CPU to access VRAM every 16 memory cycles; 372nS*16 = 5.95microSec. OTIR is slightly faster than this (5.6microSec) so using a OUTI in a loop such as > > CP B > JR NZ, disp > will work. Thanks, I see what you mean! Why 16 memory cycles by the way, is that the number of cycles needed to read four bytes from VRAM? I also take it the timing is different in 50Hz mode compared to 60Hz, which is (possibly) why sprites in games like Xenon 2 go to pot when you attempt to run at 60Hz? Mike

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	Re: Accessing video RAM - addendum Posted: Mon Mar 05, 2001 3:13 am
	slight correction - OUTI sets the zero flag according to the results of reg B, which it decrements, so the compare isn't needed in the loop: OUTI ;out byte (HL) to port (C), inc HL and dec B JR NZ,-2 ; loop if B does not equal zero the loop above allows 8 accesses per scan line during active display. the 16 cycles - i read the 9918 spec. the time it takes to refresh 8 pixels, or 1 tile, the VDP has time for 4 accesses; one to read the name table entry (remember memory accesses are 16 bits wide) and 2 to read the tile data (4 bytes per line). the forth may be used for CPU VRAM access every 4th tile or to traverse the sprite table and get the data for 8 sprites. PAL vs. NTSC timing - i'm not sure accept that the pal screen has 313 line instead of the NTSC 262, so the line frequency is only 20Hz different. I presume the memory cycle time is still the same though, 372nS. i think i covered everything... a s out.

Forums

View topic - Y2kode