Homebrew Discussion SNES Online - Mod Discussion
- Thread starter 18Phoenix
- Start date
- Views 116,758
- Replies 459
- Likes 17
- Status
I didn't know that, i just assumed they were the same because of the name and the developers made a mistake on the usa footer...
I did test all of the roms and only Mario Kart has the Snes Rom Header in the second bank and this value set, we would need more samples to test this theory.
Star Fox™ & Stunt Race FX™ use the Super FX GSU-1 and the value for 0x55 is 1340
Super Mario World™ 2: Yoshi's Island™ uses Super FX GSU-2 and the value for 0x55 is 1610
these values only exist on these 3 games and all 3 are Super FX games, knowing that GSU-2 should have twice the speed (is this confirmed?) then these values should match the Clock Speed.
After dumping a few 3DS/WiiU SNES roms and looking at their headers, i can confirm now that the 3DS header match perfectly with the unused code in the Switch.
Header1 must look like this:
Code:
00 01 00 00 00 00 00 00 AA AA AA AA 00 00 00 00
00 00 00 00 BB BB BB BB CC CC CC CC 00 00 00 00
00 00 00 00 57 00 00 00 00 00 00 00 00 00 00 00
AA AA AA AA = pointer to Rom
BB BB BB BB = pointer to Header2
CC CC CC CC = pointer to pointer to Value of Type 0x44and Header2 like this:
Code:
00 AA AA AA AA 00 00 00 00 00 00 00 00 BB BB CC
DD 00 EE 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA AA AA AA = Size of rom (in bytes)
BB BB = PresetId
CC = Value of type 0x70
DD = Value of type 0x76
EE = Value of type 0x65It should be possible to use this header instead of the Footer.
note: Type 0x44 is only used when PresetId is identical to 0x1135 (Street Fighter Zero 2) or 0x123F (Star Ocean)
the only games with S-DD1, so Type 0x44 should be clear now ^^
edit:
i don't own a snes classic or the roms for it, but could it be that this unused code is for the snes classic?
Last edited by Falo,
What you are describing is not the 3DS header format. That's the WiiU/SNESC header format. And I would expect there to be residual code for it in the Switch fork. To keep it short, the key difference is the value at 0x14-0x17 (BB BB BB BB in your example). On 3DS that is not a pointer to header2, but instead a pointer to the end of the ROM data.
0x18-0x1B (CC CC CC CC in your example) is known to be used with SFA2. It points to what I've called Header3. Header3 is just itself a pointer to the decompressed graphics data.
But it is interesting and helpful that you have identified the relation to value 0x44 in the switch footer table. I can update my SFA2 test patch.
Yes. It fits very much with the SNESClassic. The only oddity is that the byte at 0x24 in Header1 is actually checked and required. That was definitely not the case on the SNESC, to the evidence that for my tool/database I used 3DS and Wii Product IDs at that location for games that did not have a verified official WiiU ProductID. For Wii that byte would be R for RVL-JXXY, and for 3DS it would be K for KTR-UXXY. I never heard of any issues that could be traced to such difference.
This code is completely unused? Meaning, if you give the Switch's canoe emulator a WiiU/SNESC formatted .sfrom, it just wont do anything with it? Bummer if so, but at least you are able to get some information from it still.
Like... you just confirmed my theory about value 0x76 of the Switch footer being the Volume byte. No clue why that was kept, but there it is. 0x65 is confirmed to be the special chip value, and 0x70 for the maxinput value, but that was already made clear. FYI, the byte in between DD and EE in your example is used for ROM Map override. Just forces the emu to recognise it as either LoROM 0x14, or HiROM 0x15. Good they finally got rid of that.
What I'd be especially interesting in is if you can find reference to values store at 0x13-0x16, 0x17-0x1A, and more importantly 0x1B-0x1E & 0x1F-0x22 in Header 2. 0x13-0x16, 0x17-0x1A may just be padding, but 0x1B-0x1E & 0x1F-0x22 are not. They have values that change with some ROM's.
On WiiU/SNESC the value at 0x1B-0x1E is almost always 0x00000001 except for a small list of games where its instead 0x00000000. On the 3DS that same value is always 0x00000003 except for that same list of game with with it is then 0x00000002.
On WiiU/SNESC/3DS 0x1F-0x22 is always 0x00000001.
These values have puzzled me my whole time working on this stuff!
EDIT:
Here's an update of the SFA2 test patch based on new information.
Last edited by DarkAkuma,
The code is unused for the currently released sfroms, but adding that header changes that.
the ReadRom function starts with this:
if ( !ptrRom->field_0 && ptrRom->field_1 == 1 && ptrRom->field_24[0] == 0x57 )
return ParseHeader(info, ptrRom);
before it actually reads the new footer
ParseHeader:
the ReadRom function starts with this:
if ( !ptrRom->field_0 && ptrRom->field_1 == 1 && ptrRom->field_24[0] == 0x57 )
return ParseHeader(info, ptrRom);
before it actually reads the new footer
ParseHeader:
Code:
signed __int64 __fastcall ParseHeader(RomInfo *info, SnesRomHeader1 *hdr1)
{
SnesRomHeader2 *hdr2; // x8
int v3; // w9
bool v4; // zf
bool v5; // zf
hdr2 = (SnesRomHeader2 *)(&hdr1->field_0 + hdr1->ptrHdr2);
if ( !hdr2 )
return 15LL;
info->szRom = hdr2->szRom;
v3 = LOBYTE(hdr2->PresetId) | (HIBYTE(hdr2->PresetId) << 8);
info->PresetID = v3;
info->Value70 = (unsigned __int8)hdr2->Value70;
info->Value76 = (unsigned __int8)hdr2->Value76;
info->Chipset = hdr2->Chipset;
if ( (unsigned int)(v3 - 0x10DF) >= 2 )
v4 = v3 == 0x123F;
else
v4 = 1;
info->ptrRom = (__int64)hdr1 + hdr1->ptrRom;
if ( v4 )
v5 = 1;
else
v5 = v3 == 0x1135;
if ( v5 )
info->Value44 = (__int64)hdr1 + *(signed int *)(&hdr1->field_0 + hdr1->ptrValue44);
return 0LL;
}So then .sfrom's from my tool should work on the Switch as is? (outside of PCM patched games).
Nice!
Then there should be no problem with people getting most games to work, as long as they refer to SNESClassic compatibility findings and .sfrom generation with my tool. I documented and refined the hell out of that format to obsurd/obscure detail to make sure .sfroms generated with my tool/databases where 100% byte for byte matches to what the game would be like if Nintendo officially made the .sfrom themselves.
The only restrictions are, don't use PCM audio (No evidence that its supported on Switch.), and make sure the first character of the Product ID is a capital W in the Advanced window.
That said... I personally would still like to figure out the Switch .sfrom format, and support it as well. I begun work on reading switch .sfroms today, and will eventually get to generating them.
...
Oh. So is there any trace of those header2 values I mentioned above being checked on the Switch?
Even using the correct footer? Damn. I wonder why it works correctly on the Japanese app but not in the western version.
Ok, that's it, footers are absolutely useless. Star Fox 2 doesn't work if you use either the Yoshi's Island footer (a SFX2 game, just like Star Fox 2), or the Star Fox or Stunt Race footers. But use the footer from Mario Kart, the one that has no business working, and it works flawlessly, no problems. Footers are useless.
This one doesn't work either. Just to clarify, I am patching a good .sfc rom of the US version of Street Fighter Alpha 2, then doing the usual process to add it to the SNES Switch Online app (changing the extension to sfrom, etc.) Is that what you want me to do? I ask because after patching, the resulting rom doesn't have a footer. Should it? Should I be adding a specific footer? In any case, I tried it just like it came out and also tried it adding a footer and in both cases it didn't load.
I'm sorry to say that I have had no real success loading sfroms created with your tool. I've tried a few, with or without patches, with or without footers added by me. I'll keep trying later.
As it stands now, pretty much every game I've tried works and the ones that don't work I didn't really expect them to in the first place as they're mostly expanded roms and SFA2. The notable exception so far are the Quintet games which have horrible audio problems or just plain don't work. It would be fantastic to get those working, specially the expanded roms (Tracia 776!) but I know it's a slim chance not, if ever.
The games that do work seem to work flawlessly. Even Star Fox 2 with the "wrong" footer that shouldn't have any mention of SFX2 anywhere runs like a charm. The only exception I've noticed is a bit of slowdown after pressing start on the title screen of Mega Man X2 (but I'm hoping that doesn't mean the bosses with that weird wire frame thing also slow down).
Last edited by RadMcFist,
For me ALL roms work with the Mario Kart footer. Even all FX games (only Dirt Trax FX has graphic errors).
And Secret of Mana 1+2 work aswell, the highres menu is only shown a bit blurred, but they're full playable.
There're "only" canoe compatibility problems concerning sound with games like ActRaiser, Illusion of Gaia, SoulBlazer, Terranigma.
And Secret of Mana 1+2 work aswell, the highres menu is only shown a bit blurred, but they're full playable.
There're "only" canoe compatibility problems concerning sound with games like ActRaiser, Illusion of Gaia, SoulBlazer, Terranigma.
Yes. the Intention is just to patch the normal good/nointro version of the ROM with the IPS. The IPS adds its own footer. That's part of the whole point, so you don't have to edit footers. Anyone who can apply an ips can test.
The ROM does have a footer... its just burried inside the resulting file. Its not at the end of the file.
I suspect there's something being lost in your setup. Things that should work, don't for you. I'm missing something. Maybe there's steps that need to be taken for Falo's finds of SNESC .sfrom support to work. And as you say, the SMK footer works for you for games that it should, and footers that probably should don't. Things just aren't adding up. Starfox 2 should work for you with the Starfox 1 or Yoshi's Island footer, as long as you change the Preset ID.
I'm afraid I'm not going to be able to help with these issues, as I don't own a Switch and don't have experience with the setup.
My SFA2 test patch may have a flaw, but I can't be certain of that atm until I can see you or others having success with footers that definitely should work.
FYI, this is the footer I made for the SFA2 patch. (I'm assuming you tried test#2, as you quoted that post.)
Code:
47 02 00 00 DF 10 74 06 70 02 44 04 00 00 20 00 40 00 12 00 00 00 43 61 6E 31I did just notice a mistake, and its fixed in this version. But I don't think that mistake would cause a complete fail.
Its possible my educated guess at how value 0x44 works is wrong. This part "44 04 00 00 20 00 40 00". But as I said. There's not really any sense trying to refine my attempts when I'm not certain my attempts are even causing the fail.
Last edited by DarkAkuma,
Value68 can only be 1, 2 or 3, otherwise default values are used
Value6D seems to be a "force SA-1" flag, otherwise emulator checks for preset id 0x10A2 & 0x10A3 and sets the same flag
i'm not sure if these values make any sense:
maybe ram size?
Value6D seems to be a "force SA-1" flag, otherwise emulator checks for preset id 0x10A2 & 0x10A3 and sets the same flag
i'm not sure if these values make any sense:
Code:
switch(Value68)
{
case 3:
settings->field_0 = 2;
settings->field_4 = 2;
settings->field_8 = 512;
break;
case 2:
settings->field_4 = 2;
settings->field_8 = settings->field_0 << 8;
break;
case 1:
settings->field_0 = 2;
settings->field_8 = 512;
break;
default:
settings->field_0 = 1;
settings->field_8 = 256;
break;
}Secret of Mana 3 works, but not the officially translated one from the Mana Collection as that one is an expanded rom. Like I said before, so far pretty much every game works except Quintet games, some expanded roms and SFA2 (Star Ocean too, almost certainly, but I haven't bothered trying). Still, it's a hell of a lot better than the NES Online app where a crapton of the games I wanted to play weren't compatible (but I added them anyway for the pretty covers
OK, good to know.
OK, I'll try the new changes in a while, can't right now.
Well, at least know that I assure you there's nothing wrong with my setup on my end, at least not any more wrong that everyone else's setup is right now. Things that don't work for me, won't work for anyone else. I understand the doubts since you can't see for yourself and I have a hard time believing it myself, but I assure you that the only people who have managed to make this work are all using the same footer for every single game, regardless of Preset ID or enhancement chip or anything else, and that, in fact, using a Preset ID from any game not included already will be a guaranteed failure.
Just in case you don't know since I know people tend to be very vague in their posts sometimes, this is how things work right now: we open one of the included sfrom on a hex editor (usually mario kart but some have used others, like mario world), copy the footer, open the rom we want to insert (can be either .sfc or .smc), paste the official rom's footer as is, without any changes (leaving even the wrong Preset ID), into the rom we want, save the changes and change the extension to .sfrom, add the correctly formatted information to the lclassics file, put it into the Switch and that's it, the game works. Anything other than that and the game doesn't work. If we try to use the correct Preset ID, the game doesn't work. Games that are not included officially only work if you use the "wrong" footer and with the "wrong" Preset ID. And this really isn't just for me, you can check this very thread to see multiple people saying variations of this, just right now 18Phoenix said that every rom works for him with the mario kart footer, just like they do for me (with the exceptions that I mentioned).
For example, if I take Breath of Fire 2 and add the Mario Kart footer but change the Preset ID to the correct one for Breath of Fire 2, it doesn't work. But if I add the Mario Kart footer and leave the Mario Kart Preset ID, it will work like a charm.
So rest assured that my setup is correct, or at least as correct as it can be right now with what little we know, and that the results of your tests as I do them are accurate and someone else will have the same results for now. I'm not an expert by any means but I'm also not a complete noob (despite the stupid questions I've asked, I know, I just want to make sure that I'm not doing something wrong and giving you false reports).
Star Fox 2 is a very curious case: it wasn't working for me because I logically assumed that a footer from an SFX game was necessary, but it works with the Mario Kart footer (as corroborated by 18Phoenix just a couple of posts above this one) and not with the obvious Yoshi's Island one or the slightly less obvious Star Fox and Stunt Race footers.
It's a shame that you don't have a way to test things out but I'm willing to help as much as I can and and as long as you're willing to keep trying. Don't feel any pressure though, I know you're doing this because you want to so work on it as you like and ask for my help or someone else's here and we'll gladly help as we are able in the hopes that we can figure out how to make things work a bit better and to help you in your research. Thanks for everything so far.
Edit:
Used the patch and just like before the game doesn't load at all. Added the footer you mentioned via hex editor and the game didn't load. Added the same footer but with the Mario Kart Preset ID and the game loaded just like it had the other day when I first used the complete Mario Kart footer (with messed up graphics and a crash after the logos).
As far as I can tell, footers do diddly squat when it comes to whether a game works or not or even how it works. If we don't include them the game doesn't work but aside from that any old footer will do as long as it's from a game already included. Could this be a byproduct of the way we're bypassing the sig check? Doesn't make much sense to me, but what do I know?
By the way, I don't know if it's intended or not cause most of this is way over my head, but applying your patches to SFA2 doubles the size of the rom.
Yes, I tried that one as well yesterday. I edited my post but I think you might not have seen it. I didn't want to make a double post.
Last edited by RadMcFist,
If no matter what I do to correctly tailor a footer to a game, it won't work, then there's not much I can do right now. While games may boot with SMK or other stock game footers, I suspect they won't be running optimally without the designated preset id working. I don't think games like SFA2 or Star Ocean will get made working with just the SMK footer as I'm sure the value 44 part will be required.
I'm not sure whats going on. Perhaps there's a checksum being made and stored somewhere of stock games footers? Similar to how the SNESC's sram was checked with a SHA1, and thats SHA1 was stored at the end of the .sram and in in a hash file. I havent kept up on efforts outside of the .sfrom itself, so i dont know anything about the .sfromsig file or if that could be related. A quick glance at it and its not looking as easy as the snesc sram.
For now... I hope it doesn't work, but because its stupid. But heres another test patch of SFA2. This time using SMK's footer. Yes. The doubling of the size of the ROM expected.
I know people on the internet always say a game runs perfectly on whatever emulator when it's actually not even close to that, but that's not me, I know my SNES, I've been playing these games for almost three decades, most of them on real hardware. So believe me that the games I've played run perfectly, with the very few exceptions I've mentioned before. I haven't played every game that I've inserted super extensively but I've played a lot of them enough to say that, and some of them I've even played to completion knowing how they are supposed to run and, man, they run beautifully, just as well as they do on the best emulators. I just beat five stages on Star Fox 2 and it played even better than I remembered and that's NOT supposed to be even close to happening if it was using the Mario Kart setting.
I know it's hard to believe but as far as I can tell and see, based on my absolutely waaaaay less educated opinion, this thing just checks if there's a footer with a Preset ID and that's pretty much it, past the Preset ID it doesn't give a crap what it says. Sadly, whatever needs to be worked out is somewhere else, man. The reason I was stumped at first and couldn't get anything running was because I was sure your tool or at least the correct Preset IDs were needed and kept trying with those until someone just threw any old footer in and it worked.
I'll give that patch a go as soon as I am able. Edit:
Edit: I just remembered that Wario's Woods music doesn't play correctly, although nothing even half as bad as the Quintet games and this game's audio seems to be problematic for some reason. There's not even an spc rip of the music available (a shame 'cause the SNES's version OST is really good).
Edit 2: The Gradius 3 patch to remove slowdown works like a beaut. Hard as nails too.
Edit 3: SFA2 didn't even load, as expected.
Last edited by RadMcFist,
I'd first think sram size. But as I know sram size checks were used in copyright protection, and 256 is the max (used in like 1 game), i don't think that's it.
Perhaps its for screen resolution support? Like scaling, framing, etc.
Since its not officially used with a game, its harder to make a guess.
For 0x6D, I can mention that the special chip byte on the SNESC has 6 variations of the SA-1. 0x06-0x0B. Perhaps they eliminated the difference from that byte and programmed it into the 0x6D? But you call it a flag, which suggests a boolean. Not sure how a 2 state value could replace 6 options...
Oh. I missed this as I wasen't expecting edits. Is that the test#4 I posted a couple hours ago? That I'd expect to at least boot for you, as its using the SMK footer.
Last edited by DarkAkuma,
Ah, ok. I thought it runs good, but you're right. When the bigger dragon enemy appears out of the sand it slows down extremly.
Have you used a special ips patch or was it something like a standard speed fix ?
Update:
Aaaaah, already done, I got it: Gradius III (U) [!] {Fast Rom}.ips
Runs much better, but not perfect, still some smaller slowdowns
When the third sanddragon appears and many other enemies it goes down again.
Or do exist different patches ?
Update2:
Oh, I got it again, there're really different ones.
The newest is Ultra Smooth Gradius (SA-1 Root - Gradius III (v1.5) : https://github.com/VitorVilela7/SA1-Root/releases)
Now it runs PERFECT
Last edited by 18Phoenix,
Something I overlooked that you mentioned before Falo, because I didn't believe it and thought I was just misunderstanding what you were saying. But yea. SMK happens to be the only HiROM game in this roster! So "63 01" = HiROM, and "63 00" or not supplied = LoROM makes sense. It makes sense now that it seemed like they got rid of the ROM Map override byte if almost all the stock games use the same map.
Is there evidence in the code to show support for something like a "63 02" or "63 03". If so, that might mean then improved support for Ex ROM mappings. They supported ExLoROM before, but not ExHiROM. The old ROM Map override byte would not allow them to work no matter what values I tried.
From the old sfrom format header2, it seems more values have carried over then initially thought
Is there evidence in the code to show support for something like a "63 02" or "63 03". If so, that might mean then improved support for Ex ROM mappings. They supported ExLoROM before, but not ExHiROM. The old ROM Map override byte would not allow them to work no matter what values I tried.
From the old sfrom format header2, it seems more values have carried over then initially thought
- FPS = No
- ROM Data Size = No
- PCM Data Size = No
- VAR Data Size = No
- Preset ID = Yes
- Volume = Yes
- ROM Map = Yes
- Special Chip = Yes
- Unknown 3 = ???
- Unknown 4 = ???
Yes, it's the test 4 patch. It doesn't even boot, like all of the previous patches. It behaves just like when a game is missing a footer, just flashes for less than a second and goes right back to the menu. Other games that don't work but do have footers usually load but give a black screen. I obviously don't have any idea what I'm talking about but I'm not scared of sounding stupid so... shouldn't the footer be at the end? Maybe that's where the emulator expects it to be and that's why it didn't boot even with this patch when you expected it to? The only other games that I've seen behave like this are some of the patched expanded roms I mentioned before that don't even load.
Sorry about the edit, it's just that usually between the time I reply to you and I get to do the test no one else replies and making a double post would just get the two posts merged anyway. Next time I'll just double post to see if you get an alert.
No, that's not what I meant. That slowdown is normal in Gradius 3, it's famous for it, it's how the SNES port was (poorly) programmed. But there's a recent-ish patch (around May this year) that eliminates all slowdown by converting the game to work as an SA-1 game. The patch that you used is probably an alternative to this one to work with the SNES mini that still has some slowdown, but with this other patch I just beat the infamous bubble stage with four options behind me and there was absolutely no slowdown whatsoever. Here, I think this is it: https://twitter.com/hackervilela/status/1126003826614513665?s=21Ah, ok. I thought it runs good, but you're right. When the bigger dragon enemy appears out of the sand it slows down extremly.
Have you used a special ips patch or was it something like a standard speed fix ?
Aaaaah, already done, I got it: Gradius III (U) [!] {Fast Rom}.ips
Runs much better, but not perfect, still some smaller slowdowns
When the third sanddragon appears and many other enemies it goes down again.
Or do exist different patches ?
This patch causes some graphic glitches on canoe, however: on the SNES mini I've read that save states causes it, but here on the Switch save states work perfectly, it's rewinding the game that causes the ship and some other graphics to glitch out. in any case, this is more a curiosity than a necessity considering removing all slowdown from such a hard game as Gradius 3 makes it near impossible to beat!
Last edited by RadMcFist,
Why I'm not including the footer at the end of the file with that one comes from that fact that the Switchs .sfrom footer heavily draws from header2 of the previous .sfrom format. That header2 was technically often at the end of the file, but not always. In particular with SFA2 it was in the middle of the file. The decompresses graphics data was at the end of the file. So it makes sense to adapt that setup to the new .sfrom format when there's no direct evidence to show a change. I also suspect that the emulator searches for the footer by either the "47 02 00 00", "43 61 6E 31" (Can1), or both. Not just assumes it's at the end of the file. And from that position may determine the ROMs size based off the start of the footer to the beginning of the file.
I can try putting the footer at the end of the file. The 0x44 value can point to the location of the graphics data, so it can find it either way as long as the footer is located by the emu. Maybe it will calculate the ROM size if needed based off the start of the graphics data when supplied.
SFA2 Test 5
SFA2 Test 6
Test 5 is just using the SMK footer move to the end. There's a header 3 that points to the graphics data start location, but that header3 is itself unreferenced in the footer of course since SMKs footer does use that value.
Test 6 is like the 3rd test patch, using my best conclusion for a proper footer. Just the footer is moved to the end, and its value 0x44 points to header3.
Last edited by DarkAkuma,
Oh. I somehow missed that when making my notes of known values. Thanks.
Well, that lends itself more to my resolution theory. Super Family Tennis was known to have overscan issues on the SNESC that could not be fixed by any ID like other games with such issues. 0x68 set to 3 may be how they fix that.
I certainly have no "solid" guesses yet. 0x6A is only used on 2 games that seemingly have nothing special in common at a glance. And for 0x74, my best long shot guess was its a value used for fine tuning netplay. That guess is made only based off that I feel Tennis might require more precision in netplay than other games outside of Japan.
0x41 - ??? not currently used
0x44 - sda pointer for S-DD1 graphics
0x47 - preset
0x50 - ??? (Joe & Mac = 1E)
0x53 - ??? not currently used
0x55 - ??? maybe sfx clock speed
0x61 - ??? not currently used
0x63 - 01 = hirom, if missing or 00, lorom
0x65 - special chip
0x68 - ??? overscan? (0, 1, 2, 3 valid values)
0x6A - ??? (Super Mario Kart, Brawl Brothers, both use 38)
0x6D - ??? not currently used (some relation to SA1)
0x70 - players
0x72 - ??? not currently used
0x74 - ??? (usually 06, Super Tennis = 07)
0x76 - volume
so is this quick summary accurate for what's been discovered/theorized? have I missed/skipped anything?
EDIT: updated due to nitpicking
0x44 - sda pointer for S-DD1 graphics
0x47 - preset
0x50 - ??? (Joe & Mac = 1E)
0x53 - ??? not currently used
0x55 - ??? maybe sfx clock speed
0x61 - ??? not currently used
0x63 - 01 = hirom, if missing or 00, lorom
0x65 - special chip
0x68 - ??? overscan? (0, 1, 2, 3 valid values)
0x6A - ??? (Super Mario Kart, Brawl Brothers, both use 38)
0x6D - ??? not currently used (some relation to SA1)
0x70 - players
0x72 - ??? not currently used
0x74 - ??? (usually 06, Super Tennis = 07)
0x76 - volume
so is this quick summary accurate for what's been discovered/theorized? have I missed/skipped anything?
EDIT: updated due to nitpicking
Last edited by k1r92,
- Status
Similar threads
- No one is chatting at the moment.
-
-
-
@
RedColoredStars:
Sooo. How about Dune part 1 & 2? The cinematography is fantastic, but thats some of the most boring ass sci-fi Ive seen in my life. -
-
@
RedColoredStars:
Im going to see the new Godzilla next week. Sure they aren't some cinematic masterpieces but the last few were all really great and fun popcorn flicks to see on the big screen.
-
-
-
@
RedColoredStars:
Oh. Wait. I took my mom to see Elvis. I think that was the last time I went. I'll most likely see the new Planet of the Apes in a theater too.+1
-
-
@
RedColoredStars:
..since it's locked and I really dont want to be a part of their attention seeking nonsense any longer.
-
-
-
-
-
-
@
RedColoredStars:
Hey. I'm really tired too. Going to eat my ham, green beans, and stuffing then take a nap. lol+1
-
@
SylverReZ:
Lol. I've had two naps one in the morning, another in the afternoon. Didn't have much sleep last night. -
-
-
-
@
SylverReZ:
@AncientBoi, Very little on money right now, so not at this time. But I'd wish I had a fucking big mac.+1
-
-
-
-
] 