Timers.
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 149
- Joined: Sat Nov 17, 2012 3:58 am
Timers.
Although it's not neccessary yet, it's occurred to me that I'll need to implement a timer for seconds, minutes, etc. I'll need to it in order to calculate BPM (beats per minute) for the music tracker. I'm pretty sure I can figure out how to do BPM myself, once I have a timer. So, on a general level, how does one go about doing a timer like this? PAL/NTSC MD's can achieve 50/60 FPS right? So if that's the case, as long as my code isn't bottlenecking and everything is rendered on time, I have an easy timer right there correct? So 50/60 fps = one second = 1 beat if BPM = 60. Is there a better way to do timers, or is this the way?
-
- Very interested
- Posts: 619
- Joined: Thu Nov 30, 2006 6:30 am
The easiest time source on Genesis/MD is the vertical blanking interrupt which fires at every 1/50 or 1/60 of a second (approximately, video standards aren't exactly 1/50 and 1/60 due to the bandwidth constraints of stuffing color into bandwidth originally allocated for grayscale) depending on the video standard. Using an interrupt has the advantage that the code attached to it will always run even if the 68K is busy (as long as the interrupts are enabled. They can also be delayed if the 68K is blocked by DMA or VDP access). If you need more precision, you can turn to either the H/V counter or the timers in the YM2612. Both of those are more inconvenient though.
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
Like MoD and you said there is the main 50/60 Hz vblank, and also 223 (I think at least on NTSC) hblanks, so you'd have fractionals of 1/223rds of a second. I think you could scale this up to a reasonable range of BPMs.
my album - last thursday died last week
-
- Very interested
- Posts: 619
- Joined: Thu Nov 30, 2006 6:30 am
The problem with the hblank interrupt is that it's not very regular unless you choose your line interval carefully. HINTs don't occur it all during vblank so there's something like a 38 line gap during which no HINTs can fire. 360 ticks per second (6 per frame) should be doable on an NTSC with a setting that gives an interrupt every 37 lines, but getting the tick for the top of the frame is a bit messy.
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
You're right, I was thinking of just counting lines but I guess though that might work in a context of timing for linescroll graphics it doesn't actually translate well to a timer.
Isn't there some kind of problem with the 2612 timer that makes it spotty? Like something about how the timing isn't the same on a YM3438 MD2? Or am I just making that up.
Isn't there some kind of problem with the 2612 timer that makes it spotty? Like something about how the timing isn't the same on a YM3438 MD2? Or am I just making that up.
my album - last thursday died last week
-
- Very interested
- Posts: 2443
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
You need to poll that timer, it is the only drawback. Others happen automagically.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 619
- Joined: Thu Nov 30, 2006 6:30 am
I think an actual YM3438 has a timer with a different clock divider, but the YM3438 derived design integrated into later VDPs doesn't have that problem.
I do remember some talk of games that have timing issues between the two, but that might have more to do with the number of cycles the busy flag is set for rather than the timer.
I do remember some talk of games that have timing issues between the two, but that might have more to do with the number of cycles the busy flag is set for rather than the timer.
-
- Very interested
- Posts: 149
- Joined: Sat Nov 17, 2012 3:58 am
I guess understanding how it works is just as important as implementing it.
I can get a better understanding by asking around, where reading source can raise some questions. I definitely don't doubt the usefulness of SGDK, I was originally going to use that for this music tracker 2 years ago, until people started telling me that I need to do it in 68k. Even without the sound engine, I'm sure alot of things could be done much quicker in C versus using asm. I just find 68k so appealing right now. I'll still keep an eye on the SGDK source for help in understanding how to do things.
I'll have to come up with an algorithm for calculating BPM off the interrupts then. I'm also curious, is the information in the Sega Software manual enough for programming the YM and PSG chips or do I need that japanese->english translation for the other chip also?
I can get a better understanding by asking around, where reading source can raise some questions. I definitely don't doubt the usefulness of SGDK, I was originally going to use that for this music tracker 2 years ago, until people started telling me that I need to do it in 68k. Even without the sound engine, I'm sure alot of things could be done much quicker in C versus using asm. I just find 68k so appealing right now. I'll still keep an eye on the SGDK source for help in understanding how to do things.
I'll have to come up with an algorithm for calculating BPM off the interrupts then. I'm also curious, is the information in the Sega Software manual enough for programming the YM and PSG chips or do I need that japanese->english translation for the other chip also?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Lot of people think that SGDK is C only programming but definitely not.
Of course it's easier to program in C but you have free and full access to assembly if you prefer, some parts of SGDK are wrote in assembly, for speed reason mainly and sometime also for convenience (low level instruction access).
You can even use your own assembler if you prefer (just need a minor modification of the makefile).
Still i understand you want to understand everything and indeed re-implementing all from scratch is a good (and very difficult) way to learn
About FM and PSG, the Sega software manual is pretty complete and you won't find much by using original japanese data-sheet.
Of course it's easier to program in C but you have free and full access to assembly if you prefer, some parts of SGDK are wrote in assembly, for speed reason mainly and sometime also for convenience (low level instruction access).
You can even use your own assembler if you prefer (just need a minor modification of the makefile).
Still i understand you want to understand everything and indeed re-implementing all from scratch is a good (and very difficult) way to learn
About FM and PSG, the Sega software manual is pretty complete and you won't find much by using original japanese data-sheet.