SEGA CD Mode 1 [Archive] - Sega-16 Forums

Chilly Willy

12-16-2011, 09:13 PM

There's been a lot of talk since the release of Sonic 1 with Redbook Audio, mainly people asking for code. I can see why they might not want to post their code since it's probably hacked into Sonic 1 pretty bad. However, there still exists a need to show how to use Mode 1. To that end, I did a small demo - this is a tiny CD player done using Mode 1 of the SEGA CD, and includes full source. From this, you should get a good idea of how Mode 1 works. If not, ask questions in the thread here and I'll answer them.

The project was compiled with my gcc toolchain, but it wouldn't take much work to convert the code to whatever you normally use. The player goes beyond what you would use in a game, but it's an example.

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

Notes: The TOC is invalid until you check the disc. The CDBIOS doesn't initialize its TOC until you call DRVINIT (which is what my check disc routine does). So when you first start the player, the status may show wildly wrong disc info (first and last tracks being over 99, e.g.). If the tray/lid is open, it will show that. Insert a disc and press START - you should get proper disc info after the status is done showing "Reading TOC" and goes to "PAUSED". The current track may not be the same as the playing track - you can start a track playing and then change the "current" track to something else. Pressing X to see the track info shows the info for the current track displayed on the screen, not the track playing. The track info consists of the track time and track type; the track type is pretty straightforward - it's either a DATA track (track 1 of mixed mode discs), or a CDDA track for audio tracks. The track time shows the BCD minutes/seconds/frames/track number as MMSSFFTN. It shows where the track starts, while the track number is the same as the track number you asked for info on, or 00 is an error occured.

While this example is a CD audio player, I could have easily also read data discs, showing sector data. I did the audio player since that's mainly what people wanted - to see how to play CDDA from a game in rom. The Sub-CPU program is really simple - wait for commands from the Main-CPU, then do them. The commands all pertain to handling the CD audio, but they could as easily use the ASIC, use the PCM chip, read data from sectors, etc. When I start doing some ASIC tests, this will be the test bed to start from as it's easier for me to write the test file to SD card and run in Mode 1 than to keep burning CDRs.

I've tested this on a Model 2 Genesis + Model 2 CD and on a CDX. Let me know if you have any trouble on other models, but it SHOULD work on anything.

mode1player.zip (http://www.mediafire.com/?uu3decvu839zu5m)

EDIT: This also works in Kega Fusion. Edit the Fusion.ini file and scroll down to the bottom where you should find "CartBootEnabled=0" - change the 0 to 1, then load a CD image and run the cart image. If you don't load a CD image, it doesn't enable the CD emulation and the program complains that the CD can't be found.

Update - 20111219: Should work on the WonderMega and X'Eye, and MIGHT work on the LaserActive. Also changed this version to init the drive if a disc is in place when started so that you can immediately play tracks.

mode1player2.zip (http://www.mediafire.com/?88m8r5iaij52sdk)

Update - 20120105: Now works with LaserActive.

Mode1Example-20120104.zip (http://www.mediafire.com/download.php?ab0n2vukcu9aobl)

Thunderblaze16

12-16-2011, 09:26 PM

I wish someone would make a redesign model, one that wouldn't make bloody noises and won't go broke like the model 1.

Chilly Willy

12-16-2011, 09:38 PM

I wish someone would make a redesign model, one that wouldn't make bloody noises and won't go broke like the model 1.

They did, it's called the Model 2. ;) :D

Barone

12-17-2011, 11:39 AM

Mr. Chilly Willy,

I don't have enough words in my limited English vocabulary to express my gratitute, so let me say: thank you!
But, man, you rock!

I have tested the Sonic with Red book audio and it works like a charm in real hardware... I also tested it with Kega Fusion.

You know how many possibilities this Mode 1 "thing" creates to homebrews and hacks. It's just wonderful. Since the release of Pier Solar I was looking for something like this. I thought that some hard study using the lacking Sega CD documentation + some reverse engineering into the BIOS rom could reveal something, but it would probably be extremely painful.
So your code is like pure gold. Man, just think about MKII using the original arcade soundtrack or Samurai Shodown (this is the one that I'm working in) or any other fighter...

Well, one thing still bugs me about Pier Solar: the disc provides soundtrack but also some ambient sounds. I suppose that those ambient sounds (with some neat spatial panning effects) are using the Ricoh soundchip as well, right? So, I wonder that would be possible to hack Samurai Shodown, for an example, to play the arcade soundtracks using the CD and also some sounds for each stage, like a bonfire sfx or the water hitting the stones...
Would be possible to load those samples from the CD? Only possible from the CD or I could load them from the cartridge and send it to the Sega CD?

Chilly Willy

12-17-2011, 12:06 PM

You know how many possibilities this Mode 1 "thing" creates to homebrews and hacks. It's just wonderful. Since the release of Pier Solar I was looking for something like this. I thought that some hard study using the lacking Sega CD documentation + some reverse engineering into the BIOS rom could reveal something, but it would probably be extremely painful.
So your code is like pure gold. Man, just think about MKII using the original arcade soundtrack or Samurai Shodown (this is the one that I'm working in) or any other fighter...

That's why I like open source - everyone benefits. Most of my MD/32X releases has all been open source targeted at helping others do more in their own games.

Well, one thing still bugs me about Pier Solar: the disc provides soundtrack but also some ambient sounds. I suppose that those ambient sounds (with some neat spatial panning effects) are using the Ricoh soundchip as well, right? So, I wonder that would be possible to hack Samurai Shodown, for an example, to play the arcade soundtracks using the CD and also some sounds for each stage, like a bonfire sfx or the water hitting the stones...
Would be possible to load those samples from the CD? Only possible from the CD or I could load them from the cartridge and send it to the Sega CD?

The word ram can just as easily be used to send data from the main side to the cd side as the other way around. A mode 1 cart could easily have better audio than the MD is capable of alone to send to the PCM chip if the CD is present - it just makes the rom bigger. A mode 1 cart could also read that data off a CD like Pier Solar does, but there's nothing that forces the PCM chip to have to use only data from a CD, it just saves space in the rom to do so.

ThugsRook

12-17-2011, 12:37 PM

+rep

looking forward to S1M1 fully working someday (with the demotracks of course)

:)

Barone

12-18-2011, 03:19 AM

That's why I like open source - everyone benefits. Most of my MD/32X releases has all been open source targeted at helping others do more in their own games.
Yes, I know. I share the very same opinion. I'm keep tracking of all my steps in the hacking job I'm doing with Samurai Shodown 'cause if I get any success in my intents I would be happier to release the documentation than the IPS file itself.
IMO every step in the right direction, documented and shared with the community is a significant contribution for future releases, for better releases. When you keep it to your own things go lost, people have to "reinvent the wheel" all the time; and it's not good for the whole scene.
As a Mega Drive enthusiast, I want to see the progress going stronger in our community and contribute to it if possible; so the open source "attitude" is the only way IMO.

The word ram can just as easily be used to send data from the main side to the cd side as the other way around. A mode 1 cart could easily have better audio than the MD is capable of alone to send to the PCM chip if the CD is present - it just makes the rom bigger. A mode 1 cart could also read that data off a CD like Pier Solar does, but there's nothing that forces the PCM chip to have to use only data from a CD, it just saves space in the rom to do so.
Oh, thanks for the info!
But I asked that with the Mega Everdrive in mind:
As I understood its specifications, it will give us the possibility to use roms bigger than 32Mbit using continuous mapping/addresses (instead of the Sega Mapper that I have no idea how I could change a game rom to use it just by hacking), right (like the UMKT hack does)?

However, IDK how it would work in the Mega Everdrive OS. IDK if it will detect the extended addresses usage (by reading the rom header) or if we will have to set some option (this would be a sad note)... Whatever...

I know that using the whole 80Mbit (like the UMKT hack) implies the abandon of 32X and Sega CD usage, right?
So IDK if it would be possible to use certain amount of this space without breaking the Sega CD compatibility, like 40Mbit or 64Mbit (until this amount we should be OK since Pier Solar is 64Mbit and it uses the Mode 1 - but I have no idea how KRIKzz implemented the big rom support).
If we could easily expand the roms until 64Mbit we would have a lot of space for extra/better quality samples and content. Then IMO it would make more sense to use the mode 1 and the Ricoh soundchip to play such samples.

The dream scenario (using fighting games for example): original arcade soundtrack, high-quality voice samples played instantaneously from the cart using the Ricoh soundchip and ambient sound effects (maybe pre-loaded from the CD for each stage) using the multi-PCM playback ability of the Ricoh.
And here comes another question: Would it be possible to play samples loaded from the cartridge without the need of storing it into the tiny PCM ram of Sega CD? In other words, can the Ricoh soundchip read data from somewhere else that isn't the PCM ram?

+rep

looking forward to S1M1 fully working someday (with the demotracks of course)

:)
Check this (http://forums.sonicretro.org/index.php?showtopic=27135&st=0).

Chilly Willy

12-18-2011, 12:51 PM

Yes, I know. I share the very same opinion. I'm keep tracking of all my steps in the hacking job I'm doing with Samurai Shodown 'cause if I get any success in my intents I would be happier to release the documentation than the IPS file itself.

Sounds neat! I wish other game hackers did something similar, but we have to be happy with just the hack itself, usually.

IMO every step in the right direction, documented and shared with the community is a significant contribution for future releases, for better releases. When you keep it to your own things go lost, people have to "reinvent the wheel" all the time; and it's not good for the whole scene.
As a Mega Drive enthusiast, I want to see the progress going stronger in our community and contribute to it if possible; so the open source "attitude" is the only way IMO.

Yeah, it's very handy for when others want to make their own program - just point them to the tutorials and examples. :)

Oh, thanks for the info!
But I asked that with the Mega Everdrive in mind:
As I understood its specifications, it will give us the possibility to use roms bigger than 32Mbit using continuous mapping/addresses (instead of the Sega Mapper that I have no idea how I could change a game rom to use it just by hacking), right (like the UMKT hack does)?

However, IDK how it would work in the Mega Everdrive OS. IDK if it will detect the extended addresses usage (by reading the rom header) or if we will have to set some option (this would be a sad note)... Whatever...

I know that using the whole 80Mbit (like the UMKT hack) implies the abandon of 32X and Sega CD usage, right?

Right. Beyond 4MB and you lose the SCD; beyond 8MB and you lose the 32X. I'm not sure if up to 8M even works with the 32X... my guess is it MIGHT, but won't be accessible in the bank selected rom region of the 32X. You probably have to set RV and access it directly from the MD side. But it could just as easily be that beyond 4MB and you lose BOTH the SCD and the 32X. SEGA put support in the 32X for the 32MB mapper they designed to work in 4MB of space, so I would guess that 4MB of direct addressing is the limit for the 32X.

So IDK if it would be possible to use certain amount of this space without breaking the Sega CD compatibility, like 40Mbit or 64Mbit (until this amount we should be OK since Pier Solar is 64Mbit and it uses the Mode 1 - but I have no idea how KRIKzz implemented the big rom support).
If we could easily expand the roms until 64Mbit we would have a lot of space for extra/better quality samples and content. Then IMO it would make more sense to use the mode 1 and the Ricoh soundchip to play such samples.

The dream scenario (using fighting games for example): original arcade soundtrack, high-quality voice samples played instantaneously from the cart using the Ricoh soundchip and ambient sound effects (maybe pre-loaded from the CD for each stage) using the multi-PCM playback ability of the Ricoh.

Well, both the Neo Myth and the Everdrive MD support up to 5MB with the SEGA mapper, so you can do an extra megabyte of samples that way, but clearly the more rom space, the more better samples you can have.

And here comes another question: Would it be possible to play samples loaded from the cartridge without the need of storing it into the tiny PCM ram of Sega CD? In other words, can the Ricoh soundchip read data from somewhere else that isn't the PCM ram?

No. The wave samples MUST be in the pcm ram. That's the only memory the pcm chip can access. And that's the biggest issue with the pcm on the cd - only 64KB of pcm ram means that samples must be kept small, which means short and/or low sample rates. You CAN stream samples into the pcm ram on the fly, but that consumes much of your CPU time on the SCD 68000. However, if you've nothing else for that CPU to do, then you could have it handling that matter. Don't forget that the SCD 68000 cannot access the cart - you have to have the MD 68000 copy anything from the cart to Word RAM, then the SCD 68000 can pull the data from Word RAM.

Check this (http://forums.sonicretro.org/index.php?showtopic=27135&st=0).

I noticed some bugs in their CD setup. Hopefully now that I've posted my example, they can fix their bugs, or someone else can use the info to make a better hack for CDDA. :)

ThugsRook

12-18-2011, 01:37 PM

Check this (http://forums.sonicretro.org/index.php?showtopic=27135&st=0).
yes, thats what im refering to.
its not quite working correctly and the SONIC1 rom got some bugs from the editing.

also, importing CD tracks aint gonna be quite so easy for some games!
lots of rules to follow, lots of editing, i should know :(

i was working on (importing/editing) the demo tracks when i realized the rom itself was bugged ~ so i stopped :(

:)

Chilly Willy

12-19-2011, 01:15 PM

Speaking of Sonic1Mode1, one of the authors (Iron Sonic) blew a gasket yesterday over at Retro Sonic. He accused me of stealing code from him (when I was one of the people that made the code HE worked from), and "shitting" all over the project. He then made a bunch of huge claims about what he WOULD have done, but now wasn't as he was leaving and taking his ball with him.

A little perspective: I worked with a person on the mode 1 code, which that person then worked with Iron Sonic on adding CDDA support to Sonic 1. It had bugs, but Iron Sonic kept stating that they MIGHT fix them, but the code was too messy to release. He kept stringing people along, so I made my own example of using mode 1 that went far beyond what Sonic1Mode1 was doing... it was clean, well commented, open source, and best of all - it actually WORKED. I then went back to check the S1M1 code to see if I could help them fix their bugs - I mentioned where the bugs were in S1M1 and that's when Iron Sonic went completely off the deep end. His posts were so nasty that the thread was instantly closed (but I think he should have gotten a ban for his troubles).

Basically, from what I can tell, he believes I "stole his thunder", showing folks how to do something he thought he was the only one doing, and I MUST have stolen it from him since he was the only one doing it. He came across as a spoiled ten-year-old brat throwing the mother of all tantrums because I spoiled his magic trick by telling people how it was done, thus ending his 15 minutes of fame.

I hope he DOES leave the scene... we need hackers like him like we need a hole in the head. It's fortunate for him that I don't scare off from whiny little brats like him; the scene would be much worse off without me than without him. ALL the stuff I do is open and free for folks to use in their own stuff. His own hack wouldn't have been possible without me, although he never even realized it.
:shame:

Sik

12-19-2011, 01:40 PM

Speaking of Sonic1Mode1, one of the authors (Iron Sonic) blew a gasket yesterday over at Retro Sonic. He accused me of stealing code from him (when I was one of the people that made the code HE worked from)
The funniest thing is that I'd have done exactly the same code with the information that was public. It's the naivest possible algorithm for loading the BIOS. Actually now I'll try to examine all the BIOSes I can because something feels off... I want to make sure Flux isn't just doing a giant hack. Remind me to disassemble (again) Wonder Library later to see how it approaches that.

Oh, that too: he claimed that reverse engineering is disrespectful to the people who worked on the hack, yet completely ignoring the fact the information was retrieved by reverse engineering Flux (and some of the BIOSes if you count hunting the alternate location for the sub-CPU program as reverse engineering). So he's also being hypocrite!

His posts were so nasty that the thread was instantly closed (but I think he should have gotten a ban for his troubles).
Not going to happen, a few "big" hackers in Sonic Retro actually have this same mentality - and in fact they try to discourage any attempts at releasing any code to the public, because "it will be stolen and used in shitty hacks" and because "nobody will learn" (well, then remove all tutorials from the wiki!).

His own hack wouldn't have been possible without me, although he never even realized it.
Did he actually even do the CD coding?

Barone

12-19-2011, 01:45 PM

Well, I'm just sad about the nasty shit that happened there.

His attitude went from arrogant to completely mindless in a few posts...

First of all, how can a self-entitled child cry so loud about this or that piece of code when he actually HACKED a rom and RELEASED IT TO THE PUBLIC WITHOUT ANY PERMISSION to begin with?
The CDDA feature is awesome, but what are those lines of code compared to the Sonic 1's original code (in the copyright context)? Nothing.

About his 15 minutes of fame... Well, I think you nailed it in the head.
Great people became well-known by the quality/influence/importance of their work. Idiots think they can become well-known by self-entitling themselves and acting like arrogant jerks.

After all, look at this:

Before the fight:

There's way too many things that can go wrong with this source code and almost no one who knows the code well enough to know how to debug it and follow all the needed rules, because almost no one has taken the time to learn how to work with the Sega CD.Working with the Sega CD is a bitch and a half. People don't like reading through a mound of tech documents to understand how to interact with the Sega CD. We aren't releasing the source code because it's a mess that we know how to use and no one else. You may get lucky further down the road and we change our minds and spend the time needed to make the code usable to other people, but for now, no.
After:

Especially when, in the original scheme, we were going to clean up and improve the source so that people could do far more than just play audio with it, as well as include a wiki full of documentation that would complement it along with give documentation for a ton of other data.
:bs:

I would love to check with my own hands if his face is really made of iron.:p

ThugsRook

12-19-2011, 02:05 PM

boy that got ugly real fast.
he wanted all the glory to himself, not even realizing who Chilly was.

Chilly Willy

12-19-2011, 02:50 PM

@Sik - Yes, the hypocrisy was what made me laugh the most, despite how nasty he was being. He probably didn't even see the disconnect between what he accused me of and what he was doing himself. :D

@agostinhobaroners - Your quotes exactly show his change before and after. He was bating people before, then making grandiose claims afterwards. Anywho, I can do what he CLAIMED he would have done, and do it better. He was having trouble just getting the code to work, so I wouldn't have trusted his "wiki".

@ThugsRook - You could clearly see in his first rant that he didn't realize who I was, but tried to take it back in the second rant. :)

andlabs

12-19-2011, 04:17 PM

His last post before the topic got locked ended with the equivalent of "now that the source is out it can never be updated again or fixed again and that no one wants it to be updated or fixed." This worries me greatly; IDK if he wants to be the only one who made the thing work or if he genuinely believes software cannot evolve or what. I can try to reach out to theocas at least but eh

And now I'm considering adding a Mega CD section to my clean-room (almost? barely?) MD reference when I do continue working on it...

Sik

12-19-2011, 08:25 PM

Just gonna quote myself from Sonic Retro:

I was right to be suspicious about this method, it does not work with all BIOSes:

[BIOS] CDX (USA) (v2.21X) ...................... $016000
[BIOS] LaserActive (Japan) (v1.02) ............. $00D500/$01AD00?
[BIOS] LaserActive (USA) (v1.02) ............... $00D500/$01AD00?
[BIOS] LaserActive (USA) (v1.04) ............... $00D500/$01AD00?
[BIOS] Mega-CD 2 (Europe) (v2.00) .............. $016000
[BIOS] Mega-CD 2 (Europe) (v2.00W) ............. $016000
[BIOS] Mega-CD 2 (Japan) (v2.00C) .............. $016000
[BIOS] Mega-CD (Asia) (v1.00S) ................. $016000
[BIOS] Mega-CD (Europe) (v1.00) ................ $015800
[BIOS] Mega-CD (Japan) (1.00l) ................. $016000
[BIOS] Mega-CD (Japan) (1.00S) ................. $016000
[BIOS] Mega-CD (Japan) (v1.00P) ................ $016000
[BIOS] Multi-Mega (Europe) (v2.21X) [b] ........ $016000
[BIOS] Sega CD 2 (USA) (v2.00) ................. $016000
[BIOS] Sega CD 2 (USA) (v2.00W) ................ $016000
[BIOS] Sega CD 2 (USA) (v2.11X) ................ $016000
[BIOS] Sega CD (USA) (v1.00) ................... $015800
[BIOS] Sega CD (USA) (v1.10) ................... $015800
[BIOS] WonderMega (Japan) (v1.00) (Sega) ....... $016000*
[BIOS] WonderMega M2 (Japan) (v2.00) ........... $016000*
[BIOS] X'Eye (USA) (v2.00) ..................... $016000*
LaserActive has the BIOS code at a different address. Also for the WonderMega-based ROMs (the ones marked with an asterisk) the string "SEGA" isn't present at $016000, but rather "WONDER".

(of course, add $400000 to all those addresses when running code off a mode 1 program)

EDIT: addenum, found another possible location for the BIOS in the LaserActive: $01AD00 x_x

Chilly Willy

12-19-2011, 10:04 PM

That's another reason I posted the code with the program - so people can make changes. This was a perfect platform for testing on other consoles like the Laser Active. With info like this, it's pretty easy to change the start where it looks for the Sub-CPU BIOS.

Sik

12-19-2011, 10:13 PM

Chilly Willy

12-20-2011, 12:13 AM

Notice the current method happens to fail on the clones only. It works fine on the Sega branded stuff. Also even then we shouldn't call this failsafe, given that we're still missing a dump of the Linguaphone ROM (unless it's exactly the same ROM used in the CDX, that is).

True, but it's not a problem to support them anyway. :)

Also double checked, and both addresses I listed for the LaserActive look like the (compressed) BIOS code. I guess one of them is the CD BIOS and the other one is the LD BIOS.

Yeah, that's my guess. We'll have to have someone with an LA try it and see which works.

Here's an update that should work on the WonderMega and X'Eye, and MIGHT work on the LaserActive. I guessed the CD BIOS is the one at 0x1AD00 since it's closest to where the CD BIOS is in the other roms. I also changed this version to init the drive if a disc is in place when started so that you can immediately play tracks.

mode1player2.zip (http://www.mediafire.com/?88m8r5iaij52sdk)

tristanseifert

12-20-2011, 12:36 PM

Perhaps this (http://md.247server.net/index.php/Howto:Use_The_Sega_CD_In_Mode_1) will help those of you that want to use Mode 1 in your projects.

Sik

12-20-2011, 12:53 PM

True, but it's not a problem to support them anyway. :)
I was just pointing out how clones seemed to completely break the undocumented "rules" =P Note how all the Sega-branded ROMs have the BIOS at $16000 (save for the 1.x Western ROMs, which have it at $15800).

I guessed the CD BIOS is the one at 0x1AD00 since it's closest to where the CD BIOS is in the other roms.
Yeah, that's my guess too. In either case we'll end up knowing which one it is since there are only two possibilities =P Also if we know which BIOS is for the LD then it means we can reverse engineer that and get information about the LD hardware.

Chilly Willy

12-20-2011, 01:33 PM

Perhaps this (http://md.247server.net/index.php/Howto:Use_The_Sega_CD_In_Mode_1) will help those of you that want to use Mode 1 in your projects.

The code on the site is buggy and shouldn't be used without fixes. Refer to my code for a proper way of initializing mode 1. For example, from the init code on the HowTo page:

lea $A12000, a6 ; Load gate array start to a6

moveq #0, d0 ; Clear d0
move.b (a6), d0 ; Load reset reg to d0.
bset #1, d0 ; Request Sub-CPU Bus
bclr #0, d0 ; Reset Sub-CPU
move.b d0, (a6) ; Restore reset reg.

That code is wrong - the register is fetched as a byte, meaning the bits set are the wrongs ones. The code should fetch a word, or it should fetch 1(a6), not (a6). As a result, the CPU is neither reset, nor the bus requested properly. You'll also notice that the code only supports CDs with the Sub-CPU BIOS at 0x16000.

Another big problem is their Sub-CPU init routine arbitrarily changes the volume to max, and the pause to stop delay without regard to the BIOS defaults or the user preferences. Neither are needed for mode 1 and shouldn't be done. At the very least, the volume should be set to a user changeable value.

I was just pointing out how clones seemed to completely break the undocumented "rules" =P Note how all the Sega-branded ROMs have the BIOS at $16000 (save for the 1.x Western ROMs, which have it at $15800).

Well, fortunately there aren't many of them. As long as I guessed right for the LaserActive, they should all be covered now.

Yeah, that's my guess too. In either case we'll end up knowing which one it is since there are only two possibilities =P Also if we know which BIOS is for the LD then it means we can reverse engineer that and get information about the LD hardware.

I DID load the LA BIOS in Fusion and try my guess - which worked. I hope that carries over to a real LA. :)

EDIT: In that init code from the HowTo above, they probably meant to load a6 with $A12001 because just a little further from the bug I pointed out is another major one:

move.b #9, 2(a6) ; Write mem mode

That winds up setting the write protect on the Program RAM instead of the mem mode. With that setting, you cannot write the Program RAM from 0 to $1200. The odd thing here is the next two lines are

moveq #0, d0 ; Clear d0
lea ($A12003).l,a3 ; Word RAM Control to a3

If they had put move.b #9,(a3) after those lines, it would have been okay. In any case, a6 = $A12000, why are they loading a3 again? If they really wanted to, "lea 3(a6),a3" would have done the trick. As it is, they reload a3 later without ever having used a3 after that first load.

Sik

12-20-2011, 01:49 PM

Well, fortunately there aren't many of them. As long as I guessed right for the LaserActive, they should all be covered now.
The Linguaphone ROM is still missing and I can't guarantee the BIOS is at $16000 there. Granted, we don't even know anybody who has one of those in the first place, but it's something to take into account. We would first need to get one of those machines =/

But otherwise yeah, this should cover everything (except that).

Chilly Willy

12-20-2011, 02:02 PM

The Linguaphone ROM is still missing and I can't guarantee the BIOS is at $16000 there. Granted, we don't even know anybody who has one of those in the first place, but it's something to take into account. We would first need to get one of those machines =/

But otherwise yeah, this should cover everything (except that).

I've never even heard of it. :lol:

Oh well, if it turns up and is different, it's easy enough to add support.

tristanseifert

12-20-2011, 02:09 PM

The code on the site is buggy and shouldn't be used without fixes. Refer to my code for a proper way of initializing mode 1. For example, from the init code on the HowTo page:

lea $A12000, a6 ; Load gate array start to a6

moveq #0, d0 ; Clear d0
move.b (a6), d0 ; Load reset reg to d0.
bset #1, d0 ; Request Sub-CPU Bus
bclr #0, d0 ; Reset Sub-CPU
move.b d0, (a6) ; Restore reset reg.

That code is wrong - the register is fetched as a byte, meaning the bits set are the wrongs ones. The code should fetch a word, or it should fetch 1(a6), not (a6). As a result, the CPU is neither reset, nor the bus requested properly. You'll also notice that the code only supports CDs with the Sub-CPU BIOS at 0x16000.

Another big problem is their Sub-CPU init routine arbitrarily changes the volume to max, and the pause to stop delay without regard to the BIOS defaults or the user preferences. Neither are needed for mode 1 and shouldn't be done. At the very least, the volume should be set to a user changeable value.

...snip...

EDIT: In that init code from the HowTo above, they probably meant to load a6 with $A12001 because just a little further from the bug I pointed out is another major one:

move.b #9, 2(a6) ; Write mem mode

That winds up setting the write protect on the Program RAM instead of the mem mode. With that setting, you cannot write the Program RAM from 0 to $1200. The odd thing here is the next two lines are

moveq #0, d0 ; Clear d0
lea ($A12003).l,a3 ; Word RAM Control to a3

If they had put move.b #9,(a3) after those lines, it would have been okay. In any case, a6 = $A12000, why are they loading a3 again? If they really wanted to, "lea 3(a6),a3" would have done the trick. As it is, they reload a3 later without ever having used a3 after that first load.

Thanks for telling me about the issues. My code IS a pile of shit then, just like I expected. Anyways, I've fixed those bugs there and I'm pretty sure I can't find any more of them. The fact that your init code is in C though makes me sorta want to stay away from it, since the last time I tried to use C on the Mega Drive, it got ugly, if you know what I mean.

Sik

12-20-2011, 03:31 PM

I've never even heard of it. :lol:
http://www.sega-16.com/forum/showthread.php?17342-Rare!-my-LINGUAPHONE-EDUCATION-GEAR

It's a CDX clone.

Chilly Willy

12-20-2011, 05:20 PM

Thanks for telling me about the issues. My code IS a pile of shit then, just like I expected. Anyways, I've fixed those bugs there and I'm pretty sure I can't find any more of them. The fact that your init code is in C though makes me sorta want to stay away from it, since the last time I tried to use C on the Mega Drive, it got ugly, if you know what I mean.

Well, it's not shit - I'm sure we've all seen much worse code before. :)

Also, the bugs aren't quite as serious as my post might have read... the Sub-CPU clearly STARTS in a reset and bus held manner or your code wouldn't have worked at all. Also, setting the write protect doesn't prevent the Main-CPU from writing the Program RAM - the write protect is from the Sub-CPU... which is not running yet. And finally, while you didn't set the mem mode, the Word RAM isn't in use in this instance, so it really didn't matter that it wasn't set. All bugs, yes; all serious - under certain circumstances, but not as bad as they could be. The worst thing was actually only handling the Sub-CPU BIOS at 0x16000. The rest was tolerable (but still needed to be corrected, especially for a guide on using mode 1).

As to C, I think more people read C than 68000 assembly, which is one reason my code was in C. I could have easily made a 68000 assembly routine to handle the whole thing, but I figure for a tutorial app, C would be better for more people.

http://www.sega-16.com/forum/showthread.php?17342-Rare!-my-LINGUAPHONE-EDUCATION-GEAR

It's a CDX clone.

Given the fact that it LOOKS like a CDX with different text silkscreened on the case, I'm willing to be it's a CDX in the BIOS as well. :D

tristanseifert

12-20-2011, 06:02 PM

Well, it's not shit - I'm sure we've all seen much worse code before. :)

Also, the bugs aren't quite as serious as my post might have read... the Sub-CPU clearly STARTS in a reset and bus held manner or your code wouldn't have worked at all. Also, setting the write protect doesn't prevent the Main-CPU from writing the Program RAM - the write protect is from the Sub-CPU... which is not running yet. And finally, while you didn't set the mem mode, the Word RAM isn't in use in this instance, so it really didn't matter that it wasn't set. All bugs, yes; all serious - under certain circumstances, but not as bad as they could be. The worst thing was actually only handling the Sub-CPU BIOS at 0x16000. The rest was tolerable (but still needed to be corrected, especially for a guide on using mode 1).

As to C, I think more people read C than 68000 assembly, which is one reason my code was in C. I could have easily made a 68000 assembly routine to handle the whole thing, but I figure for a tutorial app, C would be better for more people.

Eh, I just now noticed that I was loading the BIOS from one location only. I thought I had code to do that there, but I've added it anyways. :p The bugs you pointed out did save me a little bit of time today since I did try to use the Word RAM and it didn't combust on me for once.

As for C - I think the lack of people using C is just because there is no easily usable toolchains that have libraries for the VDP, I/O, and so on. If something like that existed, I'm sure we'd see more MD homebrew done in C. Another issue I have with C is the fact that C compilers often turn a single line of code into a lot of senseless assembly statements. Perhaps it's just me, but I like to optimize the crap out of my code (See what those Japanese MD programmers did to me? :p) but I bet you could get a C compiler to output efficient code too. Perhaps you can't code timing sensitive code in C, but it does get the job done for a lot of things. Am I going awfully off topic again?

Sik

12-20-2011, 06:25 PM

All the homebrew devkits use C, what are you talking about? (though the fact everybody seems to implement its own API and that such APIs usually aren't very optimized for the hardware in question annoys me)

Chilly Willy

12-20-2011, 06:34 PM

Eh, I just now noticed that I was loading the BIOS from one location only. I thought I had code to do that there, but I've added it anyways. :p The bugs you pointed out did save me a little bit of time today since I did try to use the Word RAM and it didn't combust on me for once.

Well, at least something positive came out of it. :)

I think perhaps the most USEFUL thing for many folks about mode 1 would be being able to have another 256KB of RAM to work with by switching the Word RAM over to the MD side. I could see games using it for holding data - the data is compressed in the cart, and rather than decompress on the fly a little at a time, decompress it all at the start to Word RAM (when mode 1 available). 64KB of Work RAM in the MD isn't much, so some games won't be possible without the extra ram mode 1 can give.

As for C - I think the lack of people using C is just because there is no easily usable toolchains that have libraries for the VDP, I/O, and so on. If something like that existed, I'm sure we'd see more MD homebrew done in C. Another issue I have with C is the fact that C compilers often turn a single line of code into a lot of senseless assembly statements. Perhaps it's just me, but I like to optimize the crap out of my code (See what those Japanese MD programmers did to me? :p) but I bet you could get a C compiler to output efficient code too. Perhaps you can't code timing sensitive code in C, but it does get the job done for a lot of things. Am I going awfully off topic again?

I've seen quite a few more people combining my toolchain with Stef's SGDK dev kit for the MD.
http://code.google.com/p/sgdk/

Actually, C these days is quite good - gcc 4.x regularly does code almost as good as hand coded. I wouldn't feel bad about using C for anything on the MD except H interrupt code where you're counting the clock cycles for every instruction. Anything else is no problem for C.

tristanseifert

12-20-2011, 06:55 PM

Well, at least something positive came out of it. :)

I think perhaps the most USEFUL thing for many folks about mode 1 would be being able to have another 256KB of RAM to work with by switching the Word RAM over to the MD side. I could see games using it for holding data - the data is compressed in the cart, and rather than decompress on the fly a little at a time, decompress it all at the start to Word RAM (when mode 1 available). 64KB of Work RAM in the MD isn't much, so some games won't be possible without the extra ram mode 1 can give.

I've seen quite a few more people combining my toolchain with Stef's SGDK dev kit for the MD.
http://code.google.com/p/sgdk/

Actually, C these days is quite good - gcc 4.x regularly does code almost as good as hand coded. I wouldn't feel bad about using C for anything on the MD except H interrupt code where you're counting the clock cycles for every instruction. Anything else is no problem for C.

Eh, true. I guess those 256 KB of extra RAM are quite useful for decompression and the like. I could imagine a game loading art to there, and then utilizing the Sub-CPU to decompress it, this freeing up the main CPU to do other tasks during that time. The issue is just the fact that emulators don't actively support it - perhaps if more people start using Mode 1 from your code or my how to, perhaps we'll see some big emulators finally support it without some other shenanigans around it (*cough*Kega.)

As for C devkits - I haven't really ever been able to get a C devkit to work properly on my Mac. I mean my phrasing might not have been the best, but what I really meant is that most devkits are a pain in the ass to set up. I wish there was just one big devkit that would literally be "copy these files, run this command, done." sort of thing. I might just be talking out of my ass again, but I digress.

All the homebrew devkits use C, what are you talking about? (though the fact everybody seems to implement its own API and that such APIs usually aren't very optimized for the hardware in question annoys me)
That's the one fact that annoys me quite a lot. It really isn't that hard to at least TRY to optimize your code for these hardware APIs. There should be one unified style of API that all other APIs for sound, graphics, etc would adhere to.

Sik

12-20-2011, 07:42 PM

I think perhaps the most USEFUL thing for many folks about mode 1 would be being able to have another 256KB of RAM to work with by switching the Word RAM over to the MD side. I could see games using it for holding data - the data is compressed in the cart, and rather than decompress on the fly a little at a time, decompress it all at the start to Word RAM (when mode 1 available). 64KB of Work RAM in the MD isn't much, so some games won't be possible without the extra ram mode 1 can give.
You don't need to set up the BIOS for that though...

In fact, you only need to set up the BIOS if you want to use the CD or the back-up RAM (OK, the format for back-up RAM seems to be the same everywhere, but the BIOS handles it for a good reason). If you want to use the ASIC or the PCM hardware, you don't need the BIOS, although you'll need to load your own code to the sub-CPU (on the upside, all of PRG-RAM would be available to you in that case).

Chilly Willy

12-20-2011, 07:54 PM

Eh, true. I guess those 256 KB of extra RAM are quite useful for decompression and the like. I could imagine a game loading art to there, and then utilizing the Sub-CPU to decompress it, this freeing up the main CPU to do other tasks during that time. The issue is just the fact that emulators don't actively support it - perhaps if more people start using Mode 1 from your code or my how to, perhaps we'll see some big emulators finally support it without some other shenanigans around it (*cough*Kega.)

True - this needs to be in every emulator... at least NOW it does. :D

As for C devkits - I haven't really ever been able to get a C devkit to work properly on my Mac. I mean my phrasing might not have been the best, but what I really meant is that most devkits are a pain in the ass to set up. I wish there was just one big devkit that would literally be "copy these files, run this command, done." sort of thing. I might just be talking out of my ass again, but I digress.

That's the one fact that annoys me quite a lot. It really isn't that hard to at least TRY to optimize your code for these hardware APIs. There should be one unified style of API that all other APIs for sound, graphics, etc would adhere to.

Sounds like what you want is something like SDL, but aimed at older consoles. I'd love to see something like that as well. Maybe we could start a thread on that here in the Blast Processing forum and get some input on what programmers think is a good base for an old(er) console API similar to SDL.

You don't need to set up the BIOS for that though...

In fact, you only need to set up the BIOS if you want to use the CD or the back-up RAM (OK, the format for back-up RAM seems to be the same everywhere, but the BIOS handles it for a good reason). If you want to use the ASIC or the PCM hardware, you don't need the BIOS, although you'll need to load your own code to the sub-CPU (on the upside, all of PRG-RAM would be available to you in that case).

Right, the BIOS would really only be NEEDED if you wish to play CDDA or read data CDs. The rest can get by with custom (or no) code for the Sub-CPU. You would substitute your own 68000 code in place of where the Sub-CPU BIOS is decompressed to Program RAM, then after the Sub-CPU is started, that code would be run directly instead of needing to copy the Sub-CPU program to $6000 which is run by the BIOS. I would certainly do this if all I wanted was the RAM, ASIC, and/or PCM... avoid all the extra overhead of the CD BIOS and free up some program ram at the same time.

Sik

12-20-2011, 08:06 PM

Sounds like what you want is something like SDL, but aimed at older consoles. I'd love to see something like that as well. Maybe we could start a thread on that here in the Blast Processing forum and get some input on what programmers think is a good base for an old(er) console API similar to SDL.
Eh, I wouldn't say start something like SDL, but I would definitely want an API that was designed to make use of the hardware in a similar way most games did rather than being optimized for "hello world" and the like, which ironically backfires because then programmers learn to do things that way instead of the optimal way =P

If you ask me, I'd make an API that takes control of as much stuff as possible, using the most common algorithms and maybe even enforcing some structure common to games (e.g. things like doing I/O updates when starting the next frame). People criticize me because they think programmers should have as much control as possible, but most homebrewers just want to get stuff done, and if they really need to exploit the hardware to its fullest, they shouldn't be using an API in the first place.

Note that this doesn't mean the API should be weak. It can even support raster effects. What I mean is that it should take care of all the common stuff and be designed around the optimal way of doing things on the platform. I'd be willing to help design how this API should be if you want.

Chilly Willy

12-20-2011, 09:02 PM

Eh, I wouldn't say start something like SDL, but I would definitely want an API that was designed to make use of the hardware in a similar way most games did rather than being optimized for "hello world" and the like, which ironically backfires because then programmers learn to do things that way instead of the optimal way =P

If you ask me, I'd make an API that takes control of as much stuff as possible, using the most common algorithms and maybe even enforcing some structure common to games (e.g. things like doing I/O updates when starting the next frame). People criticize me because they think programmers should have as much control as possible, but most homebrewers just want to get stuff done, and if they really need to exploit the hardware to its fullest, they shouldn't be using an API in the first place.

Note that this doesn't mean the API should be weak. It can even support raster effects. What I mean is that it should take care of all the common stuff and be designed around the optimal way of doing things on the platform. I'd be willing to help design how this API should be if you want.

Someone who wants more control won't be using a set framework... or at least not ALL of one. Many SDL programs only use SOME SDL features, using SDL where it's convenient and ignoring it where they want more control. So I wouldn't worry about that when coming up with a framework. Just make sure it doesn't FORCE you to ONLY use the framework and it will be fine for everyone. A prime example would be H ints - while you might design a framework that allows specifying raster effects based on H ints, don't make it the ONLY way H ints are allowed - allow the programmer to replace the default H int handler with their own and you've covered both groups.

But this is what I was talking about - we would want a thread to cover details like this. That way we don't do something like make part of the framework mandatory when it should be optional. No matter how good or powerful or flexible you think you've made a function, someone somewhere will want to do something different. :D

Sik

12-20-2011, 09:10 PM

The problem is that I know that some people will complain if the API was to provide anything that wasn't 110% direct hardware access, even if trying to implement things the way they want would result in a lot of wasted performance.

Chilly Willy

12-21-2011, 01:49 AM

TrekkiesUnite118

12-21-2011, 09:58 AM

While I still want to learn Assembly, I don't have as much time on my hands now than I did a month or so ago to apply to learning it as I'd like. I would be very interested in something like an API as I'd still like to try and make something on the Genesis hardware. What I would personally like to see in something like this is something that is simple to just pick up and start programming with, where the libraries are easy to understand and follow as are the function calls. For example XNA while nice uses some quirky names for things which can make it hard to follow. For example if I remember correctly 2D graphics are referred to as Vector2 objects. It would be nice to have a set of libraries that use names that make sense for their functions and variables.

Another thing that might be interesting is to make it so you could decide your platform at compile time. For example if I had written Sonic in this library it would be nice to be able to say at compile time "Compile this for the Sega CD" and then the game would be compiled to run as a Sega CD game. Now obviously if someone says "Compile this for the Genesis" and they are using function calls for the Sega CD the compiler would have to catch that. Though in that case you could have the compiler ask "Would you like to compile for the Sega CD or Compile for the Genesis using Mode 1?" I'm not sure if this is entirely possible, but it would make for a rather nice all in one development platform.

Sik

12-21-2011, 10:08 AM

For example if I remember correctly 2D graphics are referred to as Vector2 objects.
Those are 2D coordinates, not 2D graphics. Vector2 = a vector with two coordinates (X, Y), Vector3 = a vector with three coordinates (X, Y, Z), Vector4 = a vector with four coordinates (X, Y, Z, W). Programmers should get accustomed to that because it's the proper term (it's taken from maths, actually).

Another thing that might be interesting is to make it so you could decide your platform at compile time.
Even better, also a way to specify the data that goes in the header, since all games should have a valid header (in before some quick ad-hoc tool that modifies the output binary).

Now obviously if someone says "Compile this for the Genesis" and they are using function calls for the Sega CD the compiler would have to catch that.
Compilers don't understand that stuff. The best you could get is the linker complaining that the function is missing (since the CD functions obviously wouldn't have been linked in).

TrekkiesUnite118

12-21-2011, 10:24 AM

Those are 2D coordinates, not 2D graphics. Vector2 = a vector with two coordinates (X, Y), Vector3 = a vector with three coordinates (X, Y, Z), Vector4 = a vector with four coordinates (X, Y, Z, W). Programmers should get accustomed to that because it's the proper term (it's taken from maths, actually).

It's still something that can throw people off. Especially if the person is not familiar with higher level math.

Sik

12-21-2011, 10:31 AM

It's still something that can throw people off. Especially if the person is not familiar with higher level math.
Don't expect to get very far if you don't learn this stuff for starters =/ (and generally all the heavy math is done by the API itself anyways, so it's not like you need to know a lot)

Pretty sure the documentation and most tutorials explain what those vectors are though...

TrekkiesUnite118

12-21-2011, 10:55 AM

Don't expect to get very far if you don't learn this stuff for starters =/ (and generally all the heavy math is done by the API itself anyways, so it's not like you need to know a lot)

Pretty sure the documentation and most tutorials explain what those vectors are though...

I did figure out what they were when I looked into tutorials, it still was something I wasn't expecting it to be for what it was used for. Even the calls to create the graphical objects that used the Vector objects for their coordinates were a bit vague. When you would look at the function header you were still left scratching your head if you didn't know the vector objects referred to coordinates. I'm not saying you shouldn't have to learn certain things, just that certain things should be named in a way to make it easy for people to pick up and know what something is without being a math or computer science major to figure things out.

For example if you were to have a Vector2 like object in this and you were pretty certain it was only going to be used as sprite coordinates in games, it would make more sense to call that a Coordinate2 object instead.

Chilly Willy

12-21-2011, 12:09 PM

What you probably want is a base project that you can use for a particular platform. Kind of a more generic version of the examples I did for my last toolchain where I made C and C++ examples for MD and 32X.

Barone

12-21-2011, 12:18 PM

You have to start from somewhere, with some language. Nothing is easy at the beginning.
Maybe 68K assembly is not the best choice. You should try something like C first. Then learn about pointers and other stuff... And then some assembly. But nothing for just a month or so. A month is for PHP or some script language IMO (and you'll still be a rookie programmer in that language; experience means a lot in programming tasks).

And, well, IMO makes no sense to complain about the available tools. In some situations you'll have to deal with more low-level stuff or pain-in-the-butt environment settings, so it's better to be prepared for the worst. We certainly don't have loads of money and resources like MS to turn things THAT easier. XNA is much easier than DarkSDK or Allegro or even SDL... But I can't imagine something like that for MD programming.

Like Chilly said, maybe a simple example plus tutorials/documentation could be a good start for you.

Anyway, any marathon begins with a first step.

TrekkiesUnite118

12-21-2011, 12:29 PM

I know how to program in Java and C++. I've read through documentation on C too so it's not like I don't know how to program at all. It's just programming for the Genesis that I don't know much about.

And I didn't say I want to learn it in a month, I said I don't have as much time on my hands as I did a month ago. There's a very dramatic difference there.

And I wasn't complaining about available tools, just mentioning some things I figured would be nice to see if people actually went through with it and made a Genesis API.

old man

12-23-2011, 10:41 PM

Personally I think an API should have only a few, really powerful, multifunction commands, and help facilitate generic tasks i.e. setup/initialization, reading joysticks, timing etc. You shouldn't need fifty billion commands that are interdependent on each other when one will do just as well (DirectX 8). There's also a matter of diminishing returns. Too much stuff to memorize and learn, and they might as well learn the hardware directly. On the other hand too much pandering to the easy crowd and you'll find yourself doing a bunch of work for people who aren't committed to finishing anything anyway. Good, clean, structured, well written documentation works more towards making things easier than that IMO.

ThugsRook

01-01-2012, 02:14 AM

happy new years! :)

hey Chilly, you gotta check this out!
apparently you can play ANY genesis ROM in mode1 on KEGA fusion?!?

1) enable cartboot mode via fusion.ini
2) load the normal rom sonic the hedgehog for genesis
3) while running ~ load sonic cd (or any cd i would assume)
4) sonic the hedgehog now runs in mode1? says SEGA CD is running in KEGA.

??????

Sik

01-01-2012, 02:42 AM

That's how he tested mode 1 in Fusion... =P It just makes Fusion turn on the Sega CD hardware while still booting from cartridge.

ThugsRook

01-01-2012, 03:13 AM

^ is it using the (virtual) CD hardware in any way?

the game seemed much smoother.

Sik

01-01-2012, 03:41 AM

^ is it using the (virtual) CD hardware in any way?
The CD hardware is emulated, but if the game isn't programmed for it then expect it to be just a waste of emulation resources.

the game seemed much smoother.
Which game. Sonic 1 (original, not the mode 1 hack) doesn't touch the CD hardware at all.

ThugsRook

01-01-2012, 11:03 AM

^ ok, i figured it would need code.
would have been way too simple if cartboot played on the CD cpu ;)

Chilly Willy

01-01-2012, 04:14 PM

evilevoix

01-01-2012, 04:20 PM

Is there any benefit in owning a model 2 SCD vs the model 1 besides the tray breaking?

TrekkiesUnite118

01-01-2012, 06:14 PM

Is there any benefit in owning a model 2 SCD vs the model 1 besides the tray breaking?

Um, this thread isn't about Models of the Sega CD.

But to answer your question, I've heard the Model 1 isn't as reliable due it having more moving parts.

Sik

01-01-2012, 09:56 PM

Fusion doesn't turn on the CD emulation unless a disc is loaded. Now just because the CD emulation is on doesn't mean carts WILL use it, merely that they CAN. Any difference between Sonic 1 with the CD enabled and disabled is completely in your head. ;) :D
Um, there's more than the CD tray to the Mega CD and that has to be emulated... Don't say a disc needs to be loaded =P

Chilly Willy

01-01-2012, 10:13 PM

Um, there's more than the CD tray to the Mega CD and that has to be emulated... Don't say a disc needs to be loaded =P

No, what I meant is that if you don't tell Fusion to have a disc image loaded, Fusion doesn't even bother to add the CD hardware to the emulator environment. My mode 1 example shows that - if you don't have a CD image loaded, the example doesn't find the CD at all, but when you load an image, it's there. It's just the way Fusion operates.

Sik

01-01-2012, 10:35 PM

Chilly Willy

01-01-2012, 11:31 PM

Huh, weird, because Flux and Wonder Library work as intended when I just press Ctrl+B (i.e. boot Mega CD without disc).

Are we talking about just the CD or the entire add-on? Because of course making it look like the CD works when there isn't a CD inside would be completely wrong.

Enable CartBoot and run my mode 1 example with loading a CD image... it will report no MCD found. Then load a disc image and it find the MCD and inits it just fine.

Sik

01-01-2012, 11:46 PM

Enable CartBoot and run my mode 1 example with loading a CD image... it will report no MCD found. Then load a disc image and it find the MCD and inits it just fine.
That would kind of defeat the point of cartboot though, wouldn't it? Since when you press Ctrl+B you are booting the Mega CD without an ISO (you'd need a real CD on a physical drive to boot with a disc), and the idea is that cartboot allows the software to work with the Mega CD hardware.

Chilly Willy

01-01-2012, 11:56 PM

ThugsRook

01-02-2012, 01:00 AM

^ i think SIK means booting a physical cd in KEGA for mode1.
i didnt try that for mode1.

but yea, KEGA doesnt say SEGA CD til youve pointed it to one (cue sheet) and loaded it.
KEGA will initiate SRAM and save states for the SEGA CD title. (not the Genesis rom)

which is why i wondered ~ what else is it doing?!?

Sik

01-02-2012, 01:34 AM

But given that you would be working with the CD implies using the CD, it seems to require the CD image. Anywho, I don't see a Ctrl+B in the Fusion menus, and pressing it does nothing. The only way mode 1 works that I've seen is to "Load SegaCD Image", which is Ctrl+C. Then the mode 1 example finds the hardware and inits the CD.
File > Boot Sega CD. Usually it boots the Mega CD firmware as-is (mode 2), without need to boot a game directly. If cartboot is enabled and you are running a cartridge, this causes a hard reset and starts the Mega CD in mode 1.

That said, what version are you using though? Because it's present in 3.64 (Windows), but it's completely missing in 3.63x (Linux).

Chilly Willy

01-02-2012, 02:22 PM

File > Boot Sega CD. Usually it boots the Mega CD firmware as-is (mode 2), without need to boot a game directly. If cartboot is enabled and you are running a cartridge, this causes a hard reset and starts the Mega CD in mode 1.

That said, what version are you using though? Because it's present in 3.64 (Windows), but it's completely missing in 3.63x (Linux).

3.63x in Xubuntu. I figured it might be something he added to 3.64. When is he going to update the linux version to match???? He also has fixes for the PWM sound in 3.64 that linux people don't get either. :(

Sik

01-02-2012, 02:28 PM

3.63x isn't just missing new features, it's missing some old features as well as a lot of shortcuts (he only included the most critical and everything else is menu-only - also you need to run windowed or you can't access the menu, since right click in fullscreen does nothing).

3.63x is a pretty incomplete port, period.

EDIT: and in fact, this is one of those cases - Boot Sega CD was in Fusion since quite some time already. He just didn't bother adding the option to 3.63x. Honestly, he only made a Linux port because so many people insisted, he doesn't care about Linux at all.

Chilly Willy

01-02-2012, 02:55 PM

Well, that's too bad. It's why I like Gens/GS better. There are still things Fusion does that others don't, but the others are still under development while Fusion languishes... especially for ports of Fusion to other platforms than Windows.

VGTM

01-02-2012, 02:56 PM

This is a GREAT discovery! Ever since I heard about Pier Solar's music enhancement disc, I've been wondering if i could possibly enhance games like Sonic & Knuckles, Sonic Spinball, Comix Zone, X-Men 2, Vectorman, and Toejam & Earl 2 by putting the cartridge in the Genesis and the disc in the Sega CD. Now, theoretically, I can! :D

Sik

01-02-2012, 03:00 PM

Nobody is gonna mention this (http://gendev.spritesmind.net/forum/viewtopic.php?p=14320#14320)? Looks like the real mode 1 is a feature of the firmware after all...

Chilly Willy

01-02-2012, 03:30 PM

Nobody is gonna mention this (http://gendev.spritesmind.net/forum/viewtopic.php?p=14320#14320)? Looks like the real mode 1 is a feature of the firmware after all...

It's not really worth mentioning except over at SpritesMind as an oddity for hackers. It won't work on existing flash carts without hacking, and the current "mode 1" code is at least as capable, and possibly more capable if we get the LaserActive working.

Sik

01-02-2012, 10:37 PM

At least we should stop calling this method "mode 1" then when it's just a giant hack...

Chilly Willy

01-02-2012, 11:31 PM

At least we should stop calling this method "mode 1" then when it's just a giant hack...

Perhaps, but I think the heart of "mode 1" is the fact that the Sub-CPU looks for a program in ram copied by the Genesis side BEFORE trying to boot the CD, and the current "mode 1" example makes use of that. Anything else is just setup.

Sik

01-02-2012, 11:48 PM

Actually its heart would be booting a game from cartridge =P But I don't like misinformation spreading. Let's call this thing by what it is, period.

(in before somebody coins the term "mode 0" :v)

Chilly Willy

01-03-2012, 02:09 PM

Actually its heart would be booting a game from cartridge =P But I don't like misinformation spreading. Let's call this thing by what it is, period.

(in before somebody coins the term "mode 0" :v)

Actually, we are. I went back and checked, and the hardware manual specially states that a Mode 1 Type 2 game boots from the cart at $000000 and shares the CD hardware at $400000. So it's perfectly okay to call what we're doing Mode 1.

Oh, there already is a Mode 0 - Mode 0 is booting the CD without a cart or a CD Game in place.

Mode 1 Type 1 is booting a cart that ignores the CD.

Mode 1 Type 2 is booting a cart that utilizes the CD.

Mode 2 Type 1 is booting a CD that does not utilize any kind of cart at $400000.

Mode 2 Type 2 is booting a CD that does utilize some kind of cart (BRAM, RAM, clock, etc) at $400000.

So the "auto-run a cart at $400200" part of the CD BIOS is actually a form of Mode 2, not Mode 1.

Chilly Willy

01-04-2012, 04:23 PM

Okay, between TascoDLX, Nemesis, and myself, we worked out the issue with getting the LaserActive to work. I'm just waiting on verification from Nemesis that my latest changes work on his LA, then I'll post the latest code for my mode 1 example. Nemesis is also going to post his code (over at SpritesMind). So this should be the basic init for any SCD or equivalent system out. Folks wanting to hack CDDA music into games should be happy. :)

Sik

01-04-2012, 04:46 PM

Great news! I knew the community would work out any issues once SOMETHING was released.
Who's laughing now? =P

Chilly Willy

01-04-2012, 05:09 PM

Who's laughing now? =P

Which is why I don't get people who withhold code on the basis of "it's messy." Okay, I can understand wanting to do some cleaning, but EVERYONE'S code is messy to some extent. It's not like they're the only ones to ever have messy code. If you post the code, the problems will get fixed if it's at all possible. If it's TOO messy, someone will take the fixed code and rewrite it in a cleaner manner. It's particularly bad when the people in question not only say they won't release it because it's messy, but then claim they have no time to clean it up. :confused: Uh - okay... get some of that free labor working for you - release it to the community.

In just over two weeks since I posted this example, we've gone from only working on the "official" SCD consoles to working on all known consoles. Nemesis is going to release his own version giving folks two examples to work from. Depending on whether Nemesis did his in assembly, I may do another version as 100% assembly for folks wanting to hack this into existing games who don't want to mess with C. I'm also working this into my 32X examples so that 32X cart homebrew can play CDDA when the CD is present. That will be in my next update to Wolf32X.