News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - radorn

Pages: [1]
I was casually listening to the music from the GameBoy Turok games and remembered an interview with the composer that I read somewhere a long time ago, where he mentioned how, for at least one of the games(I think  Turok 2), he did program in stereo effects into the music, but somehow the person in charge of putting the ROM together slipped and turned off the stereo flag on the player routine or something like that, and, now, they play in mono in the finished game. I can't find the interview again and I think the technical details were pretty vague and didn't go much further than this anyway.
I was wondering if this could be restored through hacking, and if anyone would be interested in trying their hand at it.
These games have great music and I certainly see how some parts were probably meant to have stereo panning but yet sound in mono. Just before writing this, I loaded the GBSs for the four games (1, 2, 3, Rage Wars) and only Rage Wars seems to show channel differences on a stereo VU meter consistently, although there seems to be some here and there in T3 too and perhaps some in T1, but I'm speaking from memory in T1's case. I think the whole story was specifically about T2, but I guess it could also apply to T1? no idea.

Anyway, that's the story. Lost stereo panning in one or more Turok games for the GB, which have some pretty sweet tracks, maybe still buried in the code waiting for a brave soul to dig them up... ┬┐Anyone up for it?

Could it be because of this?
Super Game Boy 2

Alternate enhancements can be given to games when played using a Super Game Boy 2 adapter, done by examining the internal value of the CPU on start-up: 01 is for normal Game Boy or Super Game Boy and FF denotes Super Game Boy 2. Tetris DX is the only known example, displaying an alternate border. Super Game Boy 2 detection is achieved by examining the internal value of the CPU upon boot-up.

Maybe that game check that and disables the link functionality? No idea.
Or, maybe, it has nothing to do with the SGB: Does multiplayer work on a monochrome GB at all?

None of this clears any of my doubts, though.

Short version: What I'd like to know is just how much of an incompatibility is really there between SGB and GBC other than that there's no existing hardware that combines both, and that, therefore, no existing software is ready for such a hypothetical combination.

Long version: From what I can gather, the SGB basically works as an extension to the original GB's hardware, where the GB software has to communicate with the SGB and send it the borders, palettes and any other special enhancements. It's not that the SGB does all that stuff on it's own because if "finds" it in the GB cart, but rather the GB CPU has to explicitly tell the SGB to do all the stuff. I read the SGB does do some checking of the GB header first and sets some stuff, but still the GB part has to actually send the stuff over.

Now, the GBC couldn't possibly take advantage of any of that, except the color palettes (but then again the GBC had superior coloring than the SGB extensions could offer so Nintendo just scrapped SGB colors on the GBC and made a whole new system), and neither could the SGB run in GBC mode. Knowing that, it makes sense that even games that had BOTH SGB extensions and Color mode were made to run in one of the two mutually exclusive modes. They will run in normal GB mode with optional SGB extensions (borders, limited color pallet es, SNES sound and other tricks) OR in Color mode without any SGB stuff.

BUT I still have a question: While it made no sense for commercial games running in "Color" mode to attempt to use SGB extensions, since no official hardware ever existed combining both functionalities, is there actually any intrinsic insurmountable conflict between the two standards that would prevent coexistence? overlapping addresses? clock incompatibilities?

My curiosity is due to titles like Wario Land 2, Zelda DX, and others that contain SGB extensions and, also, can run in Color mode.
Would it be theoretically possible to make an environment (through hardware or emulation) that offered both Color mode and SGB extensions concurrently?
This would be combined with hacked versions of these games that would run in Color mode and still load, at least, SGB borders, specially for games that have more than one border and change them during the game.
Some emulators attempt to run SGB+C games in SGB mode first until the first border is loaded and then reboot into Color mode, retaining that initial border for all the play session.

Now, I'm not asking for it to be made (though, I'd be very glad to see it).
I guess that with enough time and resources anything is possible and such emu/hardware could be made and games be hacked to use it. But I presume it's a very long shot.

Newcomer's Board / Re: MSU-1-Like Upgrade for N64 Emus Possible?
« on: December 10, 2017, 04:17:42 pm »
I'm not entirely sure about what the exact MSU-1 specs are, so, someone correct me if I'm wrong, but, I think it is an extension to the SNES, such as any other special chip could have been, that just adds 4GB of storage (32-bit address space) that devs can use however they want. Storing audio and video are two "simple" ways to use it, but it could be used to add regular graphics and data too (?).

IF this correct, then I have two answers for you.

First of all, even though no cartridges were ever officially produced bigger than 64MB (512mbit), the address range available for ROM use on the console's specs is bigger than that. I looked into this a long time ago and I don't remember just how much you could have, but it's more.
If that isn't sufficient, keeping it to official hardware, there's the 64DD, but that's kinda messy and impractical to use for homebrew, I would say, plus very few people have one.

As for unofficial hardware, I don't know about the everdrive, but the 64drive allows direct access to the slotted SD card from software, so you can basically have multigigabytes of storage that way. Plus, the newer HW2 model has 256MB (that is, 2048Mbit, 4x the biggest released cart) of RAM mapped to the cartridge ROM address range, with RW access. I think you can even DMA from SD to ROM-RAM. You could use it as a large cache, as a slower RAM, or whatever really.

If emulator devs wanted that kind of functionality, they could copy that.

News Submissions / Re: Site: Revised RHDN Policy
« on: September 30, 2008, 05:17:38 pm »
In the scheme I'm suggesting, one can't selfproclaim himself the voicer, of course.
For a group to publish something under these terms, the voicer (or lack there of) would need to be backed by all interested parties at publishing time, but once one is named it means that all members that are not the voicer accept to give up their right to ask for removal or to stand against it. Of course, all removal requests are to be submitted to RHDN staff to decide if it is applicable or not.

Rogue submissions of works that belong to more people than the person submitting it or don't belong to the submitter at all, and the original authors have not given explicit permission for it to be submitted, are a completelly different matter.
In these cases, where authorship rights have not been respected, a removal is due, undoubtedly, but the case presented above is different because it depicts what I would call "whimsical behavior" by the very authors of something they submitted themselves.

If you are, say, a painter and voluntarily donate a picture you painted yourself to a museum that takes care of all the work and costs of showing it to the public and even listens to your suggestions and demands about how it should be presented and many other details, it's quite egoistical and unfair to everyone involved to come later and say "no no, remove my pictures, I'm taking them to another museum" or "I don't want them on public display any longer, so take them out".

Then again, all that "voicer" stuff was just a suggestion of a way to mantain order while keeping a reasonable amount of respect to the authors' will. In the end, if you voluntarily publish something of your own in a community which you aren't responsible for and/or fully pay for it, you have no right to remove something just for the sake of it. It needs to be a real good reason.

News Submissions / Re: Site: Revised RHDN Policy
« on: September 30, 2008, 02:34:53 pm »
First post.

Just wanted to say that I completelly agree that once things are made public they should stay where they are, unless for really important reasons. If someone wants to mantain control over something, host it yourself so you can pull the plug yourself, but don't give something out to a third party to publish it for you and for free and later come saying you changed your mind and have them remove it as it never existed.

I'm sad to hear that things have been lost this way in the past. I'm not sure if I want to know how big the loss has been so far, but I'm happy to know it won't be happening any more.

About the problem of shared authorship, I agree with dshadoff in that it's their problem, not RHDN's.
Shared authorship is an "internal affair" and should not be adressed by RHDN. This is a hacking community, not a court of justice.
The most RHDN should do is allow the group's members to name one of them as a voicer who will speak in the name of the group and whose decission is not to be "officially" contested by the other members. If they chose a bad voicer and conflict ensues, too bad for them. Better luck next time.
In any case, that voicer's decission is only to be submitted to the ruling authorities (RHDN) who will have the last word and executive power over the matter of the removal, which will be, of course, uncontested.

Pages: [1]