melonDS added power management settings in v0.9.4, allowing you to emulate the DS/DSi at different battery levels (DSi games have multiple battery states, whereas regular DS games only have "okay" and "low" battery states). That was how I was able to get the low battery title screens, so you're welcome. =)
Academic question of the day: Until I get bored, or something more interesting turns up, the current task I've set myself is to absorb TCRF's Sega material (although ironically, probably not the bits that were left on "the cutting room floor", because that involves learning the inner workings of thousands of video games to verify everything - a job for someone else) Quite a lot of the stuff TCRF hosts, at least for Sega games, isn't really what I would call "cut content" - they've got cheat codes up there, and although these aren't exposed directly to the player... are still in the ROM, and accessible without hacking the game to bits. I think if you bring in a Game Genie or Action Replay to see something (e.g. Hidden Palace Zone in Sonic 2), that qualifies as unused (and therefore probably "cut") content. But what about... Exception handlers. For non-programmers: what do you do if there's a game-breaking bug in your software? Say something attempts to divide by zero - what happens? Traditionally if you hit an error state, the game would stop because the system wouldn't know how to continue. But if you're a developer debugging unfinished versions of software, you might want to know what's happened, thus code is written in such a way that an "exception" is thrown when an error occurs. Something looking out for exceptions might then trigger, and a screen might show like above - "an error has occurred, this is what state the system was in when it happened". (you can trigger the above in Flashback by exploiting a "walk through walls" bug) Problem: games aren't meant to ship with bugs, and certainly not big game-breaking ones like above. That's one of the points behind Sega's quality control - you're not meant to get into situations where these screens could be seen, so you don't typically see them. So... is this hidden, unused content? You should never get here, but as long as the checking code is still running, you could get trigger a screen like this if something were to go wrong. A programmer would be lying if they guaranteed their work to be completely bug free - there's always a chance something could break. In fact it's probably very easy to trigger these on real hardware - just remove the cartridge while the game is running. Sonic 3D's exception handler is infamously its level select screen, and was usually accessed by doing just that. Basically this is "should be hidden content"... but seeing them suggests a "bug", and you could also class it as "technical information". Loads of games have them, and they're all subtly different (and some might even be fun). How do we want to handle the exception that is exception handlers?
With TCRF, it's a symbiosis of the weird things that you find inside the ROM and the errata that you can access normally. Exception handlers are fair game, because it's a function of the game that isn't easily accessible. And TCRF loves that. But with Sonic Retro, we're more like the baby from Tin Toy. Instead of playing with the toy in the box, we're more interested with the box than the toy itself. We could document exception handlers in the technical information section and how to trigger them, but we're kind of focused on the entire game as a whole i.e. when it came out, how much did it cost, what does the manual say, what some bum in Smethingwick Burninatingham thought about it in 1992, does it work on a Korean console, etc. tl;dr it checks out, but we have different priorities.
I'd think technical information is the best option. RE: "we're more interested with the box than the toy itself": Is this something outside of our priorities? I don't see it as such; how does this differ from our other content?
Found the 8-track for Grand National Chase up for auction. Not in great shape tho. https://page.auctions.yahoo.co.jp/jp/auction/u1087690283 Images should be added to the Wiki page, but I'm not in a place where I can do so right now, so this is a bookmark either for me to do later or someone else if they have time.
I seem to recall with TCRF, they document stage selects and debug modes as they see them more as 'developer aids' rather than cheats. Although they do tend to also document cheats that aren't particularly well documented anywhere else, (often original research where someone's been hacking at a binary). But yeah, it's entirely arbitrary. Question for the wiki gurus, I want to add PC cheats for Crazy Taxi to wiki. For the title screens of PC games, I've always just gone with the maximum resolution the game allows. For Crazy Taxi 2002 that's 1280x960 which is already pretty large, but if I did the Steam version too, it's basically unlimited! So do I just pick a sensible smaller size for cheat screenshots? 640x480 to match Dreamcast might make sense?
640x480 seems like a fair bet in this case. It becomes trickier with more modern games - it's a balancing act of "how it was designed to be played" and "how is it most likely to be played". Arguably as long as it shows the effect of the cheat, that should be fine. But I'll let you make the choice
640x480 has the added bonus of being the lowest legitimate resolution the game will allow, so I think I'll go with that, thanks.
I thought Tsurumi-0600 might have been uncredited in Star Wars and Astal for his design work, but then noticed Masahito Shimizu is credited as director in both. It got weird when I saw that Shimizu is sporadically credited in future Sony Computer Entertainment games with the same kinds of roles Tsurumi gets in his SCE credits, and Shimizu was a director on Mario & Sonic at the Rio 2016 Olympic Games, and Tsurumi said in his Denfaminicogames interview (about being SEGA's guy for communicating with Michael Jackson) that he made Rio 2016 while working at his then-current company ARZEST (Shimizu also has credits on ARZEST's Hey! Pikmin and Balan Wonderland). So, they're totally the same guy, right? Especially considering he originally wrote for BEEP under the name 氷水芋吉 (i guess that's pronounced Imochiki Himizu, it's a fake name, maybe they make different sounds), which is a bit like 清水 雅仁 (Masahito Shimizu).. The weirdness goes in the other direction, because both Masahito Shimizu and Tsurumi-0600 have separate credits in Spyro the Dragon. Still, I've tagged Tsurumi in a tweet about it ,hoping he spots it and confirms/denies. https://www.mobygames.com/person/61805/masahito-shimizu/credits/sort:date/ https://www.mobygames.com/person/403885/roppyaku-tsurumi/credits/sort:date/
More ROM headers Thousands of technical information sub-pages need to be made. Akane's been doing most of the heavy lifting so far, but the more involved, the better. https://segaretro.org/Special:CargoTables/romheadersmd Once you add pages, the wiki will be able to build a database of ROM headers. Why do we want this? Because ROM headers are often wrong - they can list old build dates or prototype game names, but by automating this process, we can report how wrong they all are. (Saturn | Dreamcast) However, we might find secret support for certain peripherals, or scrapped features, or whatever. We are currently aware of 8397 ROM dumps, and of those 2,408 are MD 402 are MCD 183 are 32X 2,020 are Saturn 415 are DC that's apparently 5,428 ROM headers in total. Except there's a lot more because we don't have a full list of dumps. So I don't know why I bothered posting all that.
You care, you just don't know it yet. About 10% of Mega Drive games have their ROM headers logged on Sega Retro. I think it was Andlabs which used this information as a primary source during the early days of Sega Retro, but... uh... it only gets you so far. Case in point, a good chunk of the ones we've logged already are wrong, such as... https://segaretro.org/European_Club_Soccer/Technical_information European Club Soccer, which forgot to put in the copyright details, leaving it just as COPYRIGHT. https://segaretro.org/Magical_Hat_no_Buttobi_Turbo!_Daibouken/Technical_information Magical Hat no Buttobi Turbo! Daibouken, which apparently calls itself "$^$8$+$k%O%C%H$N$V$C$H$S%?!<%\!*BgKA81". I've no idea what formatting this is meant to be, but it's not valid. https://segaretro.org/Super_Skidmarks/Technical_information Super Skidmarks, which is missing its product number and claims to have been made in March 1991 (it wasn't). https://segaretro.org/Thunder_Pro_Wrestling_Retsuden/Technical_information Thunder Pro Wrestling Retsuden, which doesn't have a name at all. https://segaretro.org/Action_52/Technical_information And Action 52, which being unlicensed, probably didn't realise "(C) 1993 ACTIVE ENTERPRISES LTD." is not valid modem information. Most unlicensed games don't seem to be bothering with ROM headers so this is quite unique.
Somebody's been playing with controller types. Template:MDThirdPartyControllers and Template:SaturnThirdPartyControllers are dead too.
See there is value: WWF Super WrestleMania/Technical information WWF Super WrestleMania has "OJ" listed as its inputs/outputs. "J" is a standard Mega Drive control pad, but "O" is... a Master System controller. Which means, according to the header, this game should work with just two buttons. Annoyingly we don't have a manual to confirm or deny this, and Mega Drive emulators don't typically bother trying to emulate Master System controllers, but even if it doesn't work (spoilers: it probably doesn't work) this might suggest that once upon a time it was planned to. Why would you want this feature? Two-player without a second Mega Drive pad? I've gone through about 300 games and this is the first time I've seen this.
Tried this on a model 2 European mega drive with a sega master system controller, didn't work. Considering the games can't discern which controller is used, and there are different methods to poll SMS vs MD controllers, there would have to be an explicit toggle for such an option. As is, I'd chalk it up to a data entry error in the header. EDIT: Just tried the NTSC-U version on a model 1 Sega Genesis and same thing. I would wonder, however, would the Mega Drive version of Phantasy Star have the master system controller label in the header?
I used to play Mega Drive Sonic games with a Master System QuickShot thingy, and from what I recall you only get 1 functional button. The other one is Start.
Right, that's because of how you poll the 3 button Sega Genesis controller, which is built on top of the SMS controller protocol. It's required to be polled twice, once with a multiplexing "select" line set to determine the second read, which is how they fit 8 buttons on 6 data lines. Poll 1 reads buttons C, Start, Left, Right, Up and down, and poll 2 reads B, A, Left, Right, Up, and Down. The master system has ground for the multiplexing "select" line, so it'll only ever read the first state on poll. The sega genesis controller itself is what sets the "select" pin for the second poll, the SMS controller lacks this. That's what I mean by the game needing an explicit mode for SMS controllers. They don't work right when polled as a Sega Genesis controller. You would need a second polling method specifically for SMS controllers. And the controllers can't present themselves to the game, so you'd need an option to enable it.
I've never fully understood that release, but I think it's literally just the Master System game on a Mega Drive cartridge, so doesn't have a ROM header. Many hundreds of games still to check - WWF Super WrestleMania might have friends.
