SpritesMind.Net

Chilly Willy wrote: Controls:
A - play from current track to end of disc
B - play current track once
C - stop playing
X - show current track info
Y - play current track repeatedly
Z - pause/resume
START - check disc

How can I make "play random track?" (same as RANDOM-B in Japanese bios player?)

You can use the HV counter to introduce a psuedorandom number into track selection.

No. I don't need to start play random track once\repeated\or from random track to last track.
I ask for random-B mode (when track ends, next is random) - infinite disk play.

Still boils down to the same case, you just need a random number when you're going to decide which track to play next.

EDIT: also wait, seeing what post you quoted, are you coding this or just asking for how to do it in the player?

Sik wrote:Still boils down to the same case, you just need a random number when you're going to decide which track to play next.

No, I not just need a 'random number'.
I need to know that one track stops playing, to start playing next. How can I do it?

Sik wrote: EDIT: also wait, seeing what post you quoted, are you coding this or just asking for how to do it in the player?

For "Dune: The Battle for Arrakis" romhack.

...OK I think now that I'm looking at the docs I see the problem. Does anybody know what's the BIOS call you need to use to tell if a track is being played? (・・？)

Sik wrote:...OK I think now that I'm looking at the docs I see the problem. Does anybody know what's the BIOS call you need to use to tell if a track is being played? (・・？)

Or get track time, and use it as counter to start next track.

I think I found it: it's the BIOS call CDBSTAT. It tells you what the drive is currently doing (including whether it's playing music or not) as well as the current track and how much has been played (and a bunch of other information too).

OK so:

1) Pick a random track
2) Call MSCPLAY1 to play the track once
3) Call CDBSTAT to check when it's done playing
4) Go to 1

This one was harder to find out since this command is not among the CD audio commands (it's among the miscellaneous CD functions).

Since this thread get some new coverage, I tried myself to make SGDK compatible mode 1.
I go up to the sub run, then, I activate the vint synchronize thing and everything crash....
Probably something on my code but I don't know how to debug this !!!

It seems Fusion and RetroArch support this boot from cart mode....but they didn't come with a debugger of any kind.

Do you know any ? I'd like to found my loop or write on wrong address...

OK, I got it : RTE vs RTS

KanedaFr wrote:OK, I got it : RTE vs RTS

Yeah, those are SLIGHTLY different.

it seems the way you compute track number is wrong.
i had to ryemove your '& and >> to get the right numbers...under fusion

Are the track numbers not in BCD? That would be weird if they weren't. Hmm - looking at the CD BIOS manual, it doesn't say (BCD) after the fields, and it normally says (BCD) when fields are BCD. I'd have say you're probably right! Good find.

Another thing that bugs me.....
The way the CD player is made on the demo seems difficult to handle on a real game.
Let me explain :

every command uses wait_do_cmd and wait_cmd_ack.
These 2 are loops to check the communication flag.
On a real game, a loop is a disaster.
If your CD is dirty, every access to CD will result in several 1/75s lost.....

So, how is it done on commercial games ?
Do they check the communication flag on vint ?
Do they use some kind of command queue list ?
Do they rely on asynchrone programming with callback when ack is received (vs synchrone, waiting for ack on a loop!) ?

I have my idea on how to implement it but perhaps there is a well known way to do it : let's be Sega powered

From what I've seen in commercial games, they check the comm registers in a loop very much like I do. There's usually no provision for errors, and if they do anything else at all, it's check how many vblank ticks have elapsed and time out to a fatal error routine. Games on old hardware tends to do little to no error handling to keep the speed up. There's literally no time to "waste" on problems that might occur, like bitrot in a rom. If it passes a simple checksum, it assumes the rom is perfect. If not, it just crashes. Same for CDs - they assume the CD is perfect, and if it's not, it just crashes. You take ANY short cut necessary to get the game running at full speed. Not to mention, you're often working from example code that doesn't bother with error checking... like my own. Sega's code doesn't tend to be any better on error-checking. They assume that if you understand it, you can modify it for error checking if you feel you need it.