Vaus-like controller planned for Alleyway?

[Jarhmander]

Two days ago, I attended a meetup of C++ Montréal. The presentation was about the presenter's (Frédéric Hamel) attempt to make a fairly accurate Gameboy (DMG) emulator in C++11. I have to say, it's quite a strange feeling to hear about things and people you only saw in the internet, never in the "real world"; for instance, he gave credits to the Pan docs, the higan emulator, and blargg's excellent suite of test ROMs.

But that's not the subject at hand.

The presenter explained near the end that when his emulator was good enough he tested some games, and upon trying a "brick game", he found that game to behave strangely: the paddle would stick to the edge and pause instantly. He then spent alot of time comparing with other emulators, while reverse engineering the game at the same time. Eventually, he found out the bug: the serial link data register ($FF01) should have a "default" value of $FF instead of 0. In the process however, he discovered that the game actually use the Game Link data, and judging by the code that use said data, the game could actually use some external rotary controller, analogous in operation to the Vaus controller for Arkanoid. By looking at his emulator's commit history, that "brick" game is Alleyway.

Now the question: is that news to you all? The speaker mentioned that he didn't find any information whatsoever about that on the internet. I tried myself and indeed, I found nothing about Alleyway's mysterious external controller, not even on tcrf. Maybe at some point Nintendo considered making a Vaus-like controller to be sold along with Alleyway, but then the idea was scrapped before the launch of the game? Understandable, because it could be awkward to hold the Gameboy with one hand and a rotary controller with the other.

[Great Hierophant]

I recall that the Nt Mini's Game Boy core has a very similar bug to what you describe for Alleyway, it is probably the same bug but it has been a long time since I last tried it.

[lidnariq]

... Looking at gnuboy (an ancient abandoned emulator), they have this gem:

Code: Select all

        case RI_SC:
                /* FIXME - this is a hack for stupid roms that probe serial */
                if ((b & 0x81) == 0x81)
                {
                        R_SB = 0xff;
                        hw_interrupt(IF_SERIAL, IF_SERIAL);
                        hw_interrupt(0, IF_SERIAL);
                }
                R_SC = b; /* & 0x7f; */
                break;

which I really bet is referring to the same thing

—

Quickly hacking around with this, the controller seemed to have a wheel and a button. The controller must have been canceled pretty early in development, because this isn't playable.

The API implemented by Alleyway goes:
* Values between 0 and 0xF0 are treated as valid. (0xF1 through 0xFF defer horizontal control to the joypad)
* Values less than 0x3F are clipped to 0x3F
* Values above 0x97 are clipped to 0x97
And the problematic one:
* When the value changes from ≥0x80 to ≤0x7f, the game acts as though the start button has been pressed. But this is in the middle of the above ADC range.

[nocash]

* When the value changes from ≥0x80 to ≤0x7f, the game acts as though the start button has been pressed. But this is in the middle of the above ADC range.

That's apparently supposed to start the game, isn't it?

[lidnariq]

I mean, it acts just like pressing start at any other time...

[nocash]

There are two bytes. The analog value can cross 7Fh <--> 80h without acting as start button. The other byte has a button in bit7, which works like a combination of start (for leaving title screen, and for pause) and button a (for letting the ball appear).

[lidnariq]

Oh, a 16 bit report? That would explain why I was getting nonsense.

[Jarhmander]

16bit report? That's... intense. Like, sure, the ADC in the controller is probably 10 bits in resolution, but 7 bits would be sufficient, right?

[lidnariq]

Well, it's one byte of ADC and one byte of button.