xdaniel

Back to phones and Madoka wallpapers! Also upgraded from Android 2.3.6 to 4.1.2 (both nearly stock and rooted); seems to be a lot faster again now, although that's probably just from having a fresh install in general, not necessarily from Android 4...

Isn't that what I was saying, the 64drive/ED64 bit aside...? Or do you mean something different? Edit: Also, Stadium 1 allows playing the Generation 1 Pokemon games, namely Red, Blue and Yellow, while Stadium 2 allows those plus Gold, Silver and IIRC Crystal.

So an N64 cart that plays GBC games...? Can the ROM chip on an N64 cartridge be replaced easily? Meaning, are they just bog-standard chips that store data or is there more to them? Do electrically and functionally identical or reasonably close replacements exist? Can you write a complete, full speed GB/GBC emulator in either MIPS assembly or C to run on the N64? Compatible with at least all official MBC memory controllers in GB cartridges, with full compatibility for those carts? Looking up images of the Transfer Pak's innards online, it looks like the chip it contains might be a GB Pocket CPU core (same pin count, at least), so a N64-side software emulator might not be necessary. The next point still stands, and might be even more important with that than before. Do you know how to interface with the Transfer Pak, code-wise? How to read the GB cart's ROM data, saved game data, etc.? Do you know if that requires going through the MBC, like the game would need to if it was running, and if so, do you know how to read/write to each MBC type? Just throwing those out there. Would be really cool to see a stand-alone N64 cartridge that runs GBx games Super Game Boy-style, but I'm guessing hacking Pokemon Stadium 2 to not reject non-Pokemon games and running the hacked ROM using a 64drive or ED64 might be easier to do?

4 days left, almost $2.6 million in Kickstarter-based pledges, plus some $50,000 in PayPal-based payments... including $20 from me via PayPal Next stretch goal at $2.75 million - and thus likely to be reached soon, I guess -, an online co-op challenge mode with Beck and Call.

...yeah. Damn those guys.

alphaheiti: Though I still think that... (hope that makes sense, not feeling that well right now)

Toaru Kagaku no Railgun S episode 23:

Sachika Misawa - Infinia (B-side to Toaru Kagaku no Railgun S ED2, Links, and ED for episode 23)

Miasma v0.9 Alpha 1 test build, if anyone wants (dares?) to try it out: http://magicstone.de/dzd/random/Miasma_v09A1_Test.rar Some sort of compatibility list is in the Readme, but no one ever reads that file, so here it is in the spoiler, too:

F5 and F3 are SetTile and LoadBlock, both of which have nothing to do with shading or lighting as such - texture loading, yes, but that's it. As for GeometryMode, here's documentation (F3DEX v1.x, but close enough) and in the spoiler are the flags as taken from the SDK's gbi.h (F3DEX_GBI_2 is F3DEX2, so ex. G_CULL_FRONT is 0x00000200). Sorry that I'm not much of a help right now, I'm about to go to bed finally (2:00 am)

Took a break from MikadoXNA over the week and went back to the buggy, experimental PC Engine emulator I was working on ages ago and never finished. Started a fresh project, imported the old code for CPU emulation, VCE & VDC, memory handling, etc., made that work properly, got the thread interaction stable (emulation runs in a separate thread), and fixed a lot of bugs in CPU and VDC in particular (the CPU's T flag not affecting certain opcodes like it should, mid-frame resolution switching not working at all, and so on). So, yeah, this emulator dubbed "Miasma" is a thing and I guess I'll release it someday... like, just for the hell of it, not for it to ever become something super-accurate and all. I mean, I'll probably never get the video timing 100% right, for example. Anyway, some screenshots for now:

To disable lighting altogether, you can remove the lighting flag from the GeometryMode command(s) in the display list, although I'm not sure how that'll look in-game. You could also try and compare the commands in the original tree's leaves' display list(s) to those in your tree's, and see in what way ex. the commands GeometryMode, SetOtherMode_L, SetOtherMode_H and SetCombine differ - selectively taking certain commands/parameters from the original and overwriting their equivalents in your tree's data might help.

I'm concerned about Nintendo too, but not because of Yamauchi's passing... Regardless, RIP Hiroshi Yamauchi, the "Iron Fist in the Velvet Glove" as USgamer put it, which I think describes him and his leadership style very well.

The KeyWaitB debug messages in NTSC v1.0 and MQ Debug are byte for byte identical - the text "KeyWaitB" (so it doesn't mean controller 2, as it works on controller 1 in regular OoT even though that also says "KeyWaitB"), the buttons listed, etc. Check the ROMs at the offsets I mentioned. Of course, the actual combination appears to differ in the Debug ROM, but the message printed to the console is identical.

Actually, you know what I just realized? ＬＲＺ 上下 上下 左左 右右 B A START is just the bog-standard OoT button combination. Press and hold L, press and hold R, press and hold Z, let all go, press and hold D-pad up, and so on; just tried it on my JPN v1.2. I have the hand movements for it memorized, but not the actual buttons in combination, so it took me a while to realize. So, either the code really is the same for the Debug ROM as well - which I figure it isn't, judging from this thread - or they never bothered to update that console message's text. And speaking of which, it's at 0xBBE398 in the ROM and at 0xB7F414 in a decompressed NTSC v1.0 ROM (which does not have the KeyWaitB' message, with the apostrophe).

It's a modified version of Mupen64Plus that outputs debug messages printed by the game (printf-style; I guess the DebugMessage function documented on the wiki?) to the console. I sadly don't have it, I just remember as much.