Yeah, the first 2 lines are part from the checksum routine. I think I will cut that off, brings more problems than it solves... About the second ones... what are wrong with them? I'm setting an illegal value or something?
To see my palettes in motion so far, check out this video. Shows 1-1 with both palettes. I know, Fiery Mario's outfit on RGB is a bit dark, and I think there's one more color I need to tweak on the dungeon floor tiles (not seen in this video).
I think that, and some other bugs (like the Cheep-Cheeps oscillating) are by the same reason: since the 6502 uses A LOT the stack to save temporary values (it has only 3 registers), I tried to save space and get more speed by avoiding those stack accesses saving some values in d3-d7, but those registers are used as auxiliars registers in some instructions that need them, so maybe that is what are hanging some parts of the code.
In doppelganger's disassembly, go to SprObjectOffscrChk and down to the last call to MoveESprRowOffscreen. See in the comment where it says "A should be 0 by now"? That's the disappearing sprites problem. There are probably others.
About the crash on hardware: not sure, but sometimes the DMA registers can cause problems. Try setting the last VDP reg to 0x80 (or don't bother setting it at all).
There's also a few other random MegaDrive bugs, like failing to setup the controller ports and not turning off the PSG correctly (pointer to the wrong data). No big deal.
Excellent work on the port. Cheers!
BTW, about that Flying Cheep-Cheep issue? Interesting story.
In the subroutine, MoveFlyingCheepCheep (not surprising), there's an array labelled PRandomSubtracter that is indexed by a 4-bit value. I had read the comment about the index, "note this tends to go into reach of code", but I guess it didn't hit me the first time around.
Odd things noticed: If you have a MegaMouse in controller port two, it runs in 320 wide mode, and ignores controller 1. Apparently, it looks for buttons on cp2 and doesn't recognize a non-joypad. Unplugging the mouse then lets cp1 work normally and you play along in 320 wide mode, with everything "centered" left of center. If you don't have the mouse plugged in (or a pad with the buttons held), it runs in 256 wide mode with lots of bad graphical glitches. Apparently there's at least one routine in the VDP code that calculates things as 40 wide instead of what it actually is. Also, reseting doesn't work - it just hangs with screen a solid BG color.
A feature request - once the hardware bugs are ironed out and it runs smoothly on the real thing, I'd like to see a cheat code that enables interlace mode 1. While interlace mode 2 requires pattern data to be formatted as 8x16 cells, interlace 1 basically just makes the Genesis output interlace instead of noninterlace, but still with a 224-line-high addressable screen. There are a few other differences, but I've only encountered them when busywaiting for a given scanline - in hacking commercial games to use interlace 1, I've not really had any problems, so as long as you are using Vints instead of busywaiting, an interlace 1 hack should merely be a matter of modifying one or two bytes each time you hit the register that holds the interlace mode bits (I forget which register it is off hand and am too lazy to look it up right now).
This "cheat" would be handy for those who either have a capture device or a TV that doesn't like noninterlaced signals.
Thanks for the video. Very helpful. The sound issue: the PSG doesn't get put down properly, so it might be that.
Is it the PSG? I thought it was the YM2612 since it seemed to be at the note of the last musical tone played. Like when I paused it, and unpaused it, and paused it again, it was stuck on the tune of the last notes played on the 2612..
LocalH: I like more the YUB pallete. The RGB isn't bad (it's more accurate IMO), but it's too bright. BTW, I already put the interlace cheat.
tascodlx: man, you was ABSOLUTLY right about the mising sprites in the castle levels. The reason was the same as I explained why some things doesn't work as it's supossed.
evildragon: Awesome video!! I think those bugs will not be in the revision I have ready to be launched... when localh send me the new palletes. And about the sound, yes, it's the PSG, since in the YM2612 I'm mutting all the channels setting the L/R flags to zero, but in the PSG I only put the min volume in each channel without setting another frequency. Should I put a zero frequency on each one?
Last Edit: Jul 6, 2010 17:06:55 GMT -5 by Mairtrus
Well, accuracy on the palette depends on what you're trying to be accurate to. The YUV palette is more accurate to the home console, while the RGB palette is more accurate to the arcade Playchoice-10, so I figured I'd make a palette for both. Occasionally, I do like to play through NES games using the RGB palette instead of the YUV palette.
I'll work on getting the palettes into a source format, like the one you posted before (and which immensely helped me locate the palette in the ROM). You should receive a PM later tonight (for me anyway, it's 6:30pm here right now). Don't know whether you'd want to include both palettes, or a second version of the ROM, but even if you only want to include the YUV palette, I'm happy to hack the ROM for my own use to have the RGB palette too
And about the sound, yes, it's the PSG, since in the YM2612 I'm mutting all the channels setting the L/R flags to zero, but in the PSG I only put the min volume in each channel without setting another frequency. Should I put a zero frequency on each one?
It should be enough to set the PSG volumes, but there's a bug in your init code that writes the wrong data (81048f01 instead of 9FBFDFFF). I patched it the second time around, but if it didn't change anything then whatever.
I haven't checked your YM stuff. Are you sending key OFF? If all the channels are key'd OFF, I don't think you need to worry about anything else.