Pretty interesting...! Don't know what else to say...
round 1-2 music is pretty slick
My antivirus blocked a malicious URL when I want to the board linked at the Youtube video. It may have just been someone's avatar or something, but I wanted to let people know just in case.
EDIT: Yeah, it's someone's avatar hosted at a bad site. Don't think it's anything to worry about.
They're using the PSG squares for the sound effects, and since they can't do 25% or 12.5% duty cycles they sound off sometimes (getting a mushroom, etc). However they could have done octaves to produce a 25%-sounding wave.
<fanboy>This just prooves that the Genesis has so crappy sound that it's worse than even the NES. In other words, Nintendo does what Genesis don't. </fanboy>
<rational> Yes I know this has already be discussed a few times so there is no point to start this again, I just couldn't resist </rational>
Bregalad wrote:
<fanboy>This just prooves that the Genesis has so crappy sound that it's worse than even the NES. In other words, Nintendo does what Genesis don't. </fanboy>
Now that doesn't make any sense. It does sound crappy, but that's what you get when you dynamically reassign register writes. If someone went through the trouble of manually converting the music it would obviously sound much better.
I'd like to prove a point, but I need the right tool. One can use NT2 or Famitracker to write NES music. What tracker do you recommend to write Genesis music? (Preferably one that doesn't need an invisible touch screen.)
Now you got me... I don't know much about music, and know even less about music on the Genesis/Mega Drive... I keep hearing about this "
SMPS engine", which is the music engine used in Sonic games (and many others), and that lots of people make music for it. Apparently most convert from this XM format using
this program. There's also this
TFM Music Maker software that's supposedly a tracker for the MD (and other machines).
Pretty neat. Sound is wonky and I think they literally assigned A NES as A Genesis which was retarded. It would be like flipping B and A on the NES controller and trying to play SMB. But otherwise it seemed it play fairly well.
At least a Genesis controller has the same number of buttons as an NES one, so no extreme button remapping has to be done.
I seem to remember the standard on Genesis platformers being C to jump.
Anyway, here's my first try with tfmmaker:
SMB1 Main Theme (TDS Remix) (
Listen |
Download TFE)
That's pretty good! Definitely better than what this conversion and a couple of pirate games have done.
The coder of that rom stated that he didn't emulate the APU on the fly. So he converted the source music and wrote his own engine. Makes the sound less impressive. But still cool that he did limited ppu simulation on the fly.
This is pretty bad ass, I had wanted to do something like this for a long time, but I was going to hand-translate the assembly and special-case the few things that would need it (world 36, for example). Few small issues I noted:
1) That palette is worse than the Nesticle palette. Reds are too purplish, and black is between dark and medium gray? Blech.
2) I'm not sure what the cause is, but there are a few points where it seemed the Genesis sprite limit kicked in, but that shouldn't happen since the NES and the Genesis in H32 mode both have the same per-screen sprite limits (64). I especially noticed it at the beginning of both 5-4 and 6-4, with the firebars (in 5-4, the long firebar appeared shorter for part of it's rotation, and the same happened on the firebar in 6-4 right below the powerup block, until I scrolled the previous firebar offscreen).
3) Cheep-cheeps in 2-3 and 7-3 seem a bit "floaty" - instead of a smooth arc, their vertical speed seems to oscillate.
4) Also in 2-3 and 7-3, I noticed the occasional bug with regards to a few metatiles having the wrong palette - it's not consistent, however, as across several playthroughs I saw it appear on different blocks, or not at all. I also think I heard mention somewhere of this happening to part or all of a cloud?
I don't consider world 36 crashing to be a bug per-se - since the behavior in the original game is based on reading out-of-band data, it's not surprising that it would have to be specifically handled on any other version (even the FDS had a different world 36 due to a differing memory layout).
Every trick I tried that I can reliably pull off worked flawlessly. I can't reliably walljump, so I was unable to test it, but I was able to jump in midair from a powerup, I was able to hatstomp enemies, and I was able to get Little Fiery Mario. Excellent port.
LocalH wrote:
I don't consider world 36 crashing to be a bug per-se - since the behavior in the original game is based on reading out-of-band data, it's not surprising that it would have to be specifically handled on any other version (even the FDS had a different world 36 due to a differing memory layout).
What is World 36?
The "Minus" world. It's world <space>-1.
LocalH wrote:
... since the behavior in the original game is based on reading out-of-band data ...
What exactly were you trying to say? Please don't re-purpose terms that already have strict definitions. :-)
Sorry, got my terms mixed up a bit. I meant "out-of-bounds" data.
Is anyone else curious to what degree their own NES code could be ported this way? I've never used the 68k, so I don't know if I could get anything working readily, but I'm still curious to see how the resulting asm looks. With label and variable names being defined, it seems like it would be readable enough.
Well, you could write a front-end that parses the original assembly code and generates common data, and then write target-specific back-ends (e.g. MD/68k) that handles all the gritty details related to the target system.
But to generate efficient code, you'll have to somehow translate between 6502's tendency to do things in zero page and Z80/68K's tendency to do things in registers.
tepples wrote:
But to generate efficient code, you'll have to somehow translate between 6502's tendency to do things in zero page and Z80/68K's tendency to do things in registers.
I see 6502 zeropage as being sort of a 2nd level of registers. I don't know about anyone else's programs, but I tend to re-use the same zeropage locations for almost everything by just reloading the pointer in it (it'd be pretty insane to have 128 different pointers active at once, at the most). If there were any 'extra' 68k registers left over, I guess it would help to treat specific zeropage locations as registers. Just speculation though.
But it'd still be a heck of a job for a program to discover which are being used as local variables, especially when the low and high bytes of a pointer might not be stored together in ROM. It'd be much the same problem for something trying to translate 6502 to Z80: which zero-page locations should be used for BC, DE, and HL at any given moment?
Yes it would be complicated to automate, I was thinking it would be something that would be added to the source code by the programmer.
Tentative accurate palettes, YUV and RGB. Based on the default palettes generated by Nestopia.
tepples wrote:
But it'd still be a heck of a job for a program to discover which are being used as local variables, especially when the low and high bytes of a pointer might not be stored together in ROM.
I don't follow you. Why would this be difficult?
tomaitheous wrote:
tepples wrote:
But it'd still be a heck of a job for a program to discover which are being used as local variables, especially when the low and high bytes of a pointer might not be stored together in ROM.
I don't follow you. Why would this be difficult?
How would your automatic translation program know whether a particular value left in some zero page location will be needed later by some other part of the program?
tepples wrote:
tomaitheous wrote:
tepples wrote:
But it'd still be a heck of a job for a program to discover which are being used as local variables, especially when the low and high bytes of a pointer might not be stored together in ROM.
I don't follow you. Why would this be difficult?
How would your automatic translation program know whether a particular value left in some zero page location will be needed later by some other part of the program?
Because you would keep a 256byte section of ram just for ZP and indirect/pointer calculation. No different than what you would do in real time emulation. But with the opportunity of translating the original source, you can scan the entire source code for all jump/branch/starting points. From there, you can optimize instructions accordingly (look ahead for compounding multiple instructions into less or single ones, etc).
Just got through playing it. The A and B buttons are reversed. It's a pain.
Mairtrus just released a new version:
Quote:
Version 1.4.1 released!!
http://www.fileden.com/files/2007/11/30/1616239//MULS_1.4.1.BINChanges since the last version:
- The pallete was replaced by a one more accurated. INFINITE thanks to localh for that.
- Some minor bugs around the whole code where fixed. Credits to Chilly Willy for some of them.
- The PPU emulation code was rearranged, so now (plus some minor things in some parts of the code) it SHOULD works on real hardware whitout graphical glitched and other shit. HUGE thanks to tascoDLX for ALL that.
- A small error in the musics was fixed (the D4 and D#4 notes was using the D4 frequency). Thanks to Bibin who reminds me to fix this.
- According to Sik (he said it first...), now in main screen the number of players is selected with the Up/Down buttons. Now the A and C buttons does the same function. Plus, the joypads are initilized properly, so now the joypad 2 works in Fusion (an I guess in real hardware too)
- The checksum routine now is gone (as you hear, space pirates), since it took less time hack it than it tooks to me create it.
- The new cheats are(always before the tittle screen): press "A" for enable the world selection cheat; press "Up" for set the screen in Interlace mode (as localh requested).
Enjoy it!!
- How did they get music and sound effects playing in separated channels?
Zepper wrote:
- How did they get music and sound effects playing in separated channels?
By using the original data but rewriting the playback code completely?
mic_ wrote:
Zepper wrote:
- How did they get music and sound effects playing in separated channels?
By using the original data but rewriting the playback code completely?
- I hope you're not making fun of me..?
No, I'm just pointing out that that's what he did. Which should allow him to play different sounds through different channels.