For control schemes, we basically have three possibilities:
1) Standard 6-button controller implemented like the Dualshock method of playing. GH requires ony seven buttons when done in this fashion (five frets, start and select). The original game also uses one of the analog sticks for whammy - for this we could use one more button and have the game handle a smooth transition from no whammy to full whammy
2) Physically hack a GH controller and wire it up to a standard 6 button pad. The only hard point here would be interfacing the whammy bar, and you wouldn't have a lot of resolution anyway. GH with a guitar needs 9 buttons (technically 10 but we can consolidate the tilt sensor and the select button fo our purpose). You have the same seven as used with the Dualshock but you also have up and down strum. This leaves 2 buttons left over for whammy support, leaving four levels of analog whammy position, which isn't really a whole lot. It'd work but the game would have to somehow interpolate between the positions and it would be a little funky. Between this method and method #1 the game wouldn't automatically know the difference and so it would have to be an option.
3) Design a PSX->MD adapter with special support for guitars. This would allow you the full range of 16 bits that you get with an otherwise standard 6-button gamepad poll. The adapter would be the best way to handle it - it doesn't require physical modification of the controller, it would allow standard Dualshocks to be used with Genesis games as well, and when a guitar is plugged up it could switch into guitar mode and give you 128 levels of whammy position (9 buttons out of 16 bits leaves 7 bits). Plus, the adapter could be designed to respond to a certain output from the Genesis that a regular pad would ignore, and thus the game could automatically detect the adapter and disable the option between the first two control methods unless there's a regular gamepad hooked up into port 2 (yes, I want two player support
![Smile :)](./images/smilies/icon_smile.gif)
As far as implementation goes, I was thinking the best way to handle the songs would be to have them written specifically for the game. Dedicate two FM channels to the tracks that would drop out, channel 0 for player 1 and channel 1 for player 2. Modify SMPS to check on each frame two flags that indicate whether each of those channels should be played or not - if the flag is set, turn the TL of that channel down to 0, otherwise turn it up to whatever the track requires. We could modify SMPS to use a single song and vector it's pointer through RAM, which we can then modify with the absolute pointer that we'd store in the 7th page of ROM (metadata).
For the chart, we can use a tool already used in the GH customs scene called Feedback (also known as dB) - this way, more people would be likely to be willing to make customs and we'd already have a large number of charts that would only require music to be made for them. To make things more simple for people we'd need to develop a small audio-only Genesis emulator that can essentially play raw SMPS binaries, which we'd then output to an OGG file for use in dB's chart creation process, because it would be unreasonable to ask the author of dB to add such an emulator.
To allow people to build their own ROMs, we'd need to supply a tool that would take a base ROM, the charts and song binaries, and build the necessary metadata and song pages. dB already supports the entering of song and artist titles for a chart so we could just pull from that. The tool would convert the .chart format to our native format (which I'm thinking should be frame-based for ease of implementation) and would keep track of how much ROM is taken up - if we try to add a song and it would push the ROM into a 65th page then warn the user that they don't have room and disallow it.
Thoughts on the native chart format - the actual notes only require 7 bits - 5 for each fret button, one to denote whether it's a star power note, and one to determine whether it's a hammeron/pulloff note. However, once again for ease of implementation I propose adding two bits to that to denote whether a note is on a beat or measure line for display purposes. We'd also need a list of frame counts for each measure for star power depletion use (since the game depletes star power by measure and not by time). The advantage of using a frame-based format is that our ROM generation tool could have a PAL/NTSC toggle which would modify the base ROM to make SMPS play at the right speed, and would modify the chart conversion based on 50/60fps. It would probably also be a smart idea to display on either the title screen or menu whether the ROM is PAL or NTSC.
I've got a few things to go do so I'll leave this thread here for right now and let people contribute their ideas on what I've posted so far or on things I haven't posted about yet (such as how we'd implement the core engine or the visuals). When I get back I'll respond to any replies and continue detailing my ideas.