By way of background, Quby is a hobbyiest quad-screen, quad-keyboard game console system primarily designed for word games, wherein the current version is driven by a single Parallax Propeller (see my Quby thread
and/or the WordFire
website for more). And the P2D2 is a module designed by Peter Jakacki (PB&J?) that features the Parallax P2 successor chip to the P1 (see Peter's P2D2 thread
as well as some other related threads in the P2 sub-forum). I'm not speaking as a professional, but it really appears that he has done an outstanding job with the P2D2 board design, and his documentation is second-to-none. And from reading his thread, you can see that those in-the-know admire his work.
And now on to the matter at hand. Although I'm only at the early investigatory stage (and it's very early P2 days), I'm mulling over the idea of making a version of the Quby game console that is driven by Peter's nifty P2D2 module with the P2, wherein the module seems like it could be a good match for the console (not too much board, not too little, just right).
The main PCB board of the console would be a carrier for the P2D2, wherein the main board would have most of the through-hole stuff and the P2D2 would have most of the surface mounted stuff. And the main board would have most of the I/O connectors (for screens, keyboards, etc.) and the P2D2 module would take care of the processing. Seems like a nice division of "labor" or at least component types.
Another reason I like the idea of using a module is because, if the P2 got compromised somehow, it could be replaced by swapping the P2D2 for another one without having to throw the baby out with the bathwater. Conversely, the main board could be replaced, if need be, without tossing the P2D2 with its P2, power circuitry and so on. Moreover, putting the P2 on a module still allows for the main (carrier) board of the console to be offered as a kit where one can solder the main board and then just plug in the module (with the fine-pitch, SMD and more "sensitive" stuff).
In this particular application, the P2D2 would be enclosed within the console, where one couldn't readily get at it, not without removing some screws, anyway. Parallax's recently divulged development board is great, but I think that it'll work better out in the open where one can readily access its headers and ports. Plus, it's intentionally quite a bit larger than Peter's and probably overkill for what this game console needs (though never say never). Naturally, the Parallax P2 Development Board could be used for designing something like the console (and a million other things).
Now, it's true that the Quby game console likely wouldn't take advantage of a lot that the P2 has to offer, such as the the A-to-D capability and most of the smart pin functionality. But Quby could definitely benefit from the P2's speed, 512KB of hub RAM and the built-in DAC's, to name just some of the new features. For example, the P2 will likely run SPIN (or similar byte code languages) 25 to 40 times faster than the P1, and the added memory will allow enhanced graphics. Although Quby does quite well as it is right now being driven by the P1, it could really shine with a P2.
So, I'm wondering if you folks have any ideas about this. The following initial thoughts and questions have occurred to me:
 First and foremost, would Peter approve of such usage? I know: I could ask him directly (and may), but we mere hobbyists tend to tremble at the feet of the Masters. I think he'd approve, though, as I've read through his P2D2 thread a couple of times and he has indicated that the P2D2 is open-source hardware (OSH) and that the P2D2 would be a great module for a carrier board, at least in low volumes. As such, I'm guessing that he would be thrilled to see it put to use in a variety of applications, including Quby. And if I do ultimately apply the P2D2 to Quby, as a small token of my appreciation, there'll be a complementary console, sans the P2D2 module, with his name on it that's just waiting for a shipping address.
 Quby would likely use analog VGA video instead of the cool HDMI functionality that's being added in the re-spin because (a) legacy video is sufficient for this application where the displays are included, (b) driver boards are cheaper and more available for analog VGA, and (c) HDMI may need a higher operating frequency (250 MHz?) and I'm worried about power consumption and heat as it is. Quby would likely require using four cogs to generate video, one for each of Quby's four screens, as I believe that one cog can only "talk" to one set of four DAC channels, though a set of four DAC channels of a cog can be assigned to various consecutively-numbered pin "groups." So, I'm wondering what sets of pins would be, well, if not best, then at least good for the video signals of RGB and H (with the much slower V-sync signal being handled separately without a DAC assist). Four such sets of pins would be needed. For example, P0 through P3 (plus maybe P4 for V-sync) could be chosen as the set for just one of the four screens. Your thoughts? Of course, I'll stay away from the upper pins from the upper 50's onward.
 What would be a good way to power the P2D2 module? Quby currently receives around 6 volts from its power adapter (which powers the system through LDO regulators and is directly fed to the backlight circuitry of the driver boards). Am I right in presuming that this 6V can supply Vcc on the P2D2? If so, I guess I'd just feed it to the two Vcc pins of the headers: Pin 40 of Header A and Pin 39 of Header B.
 Quby currently brings out a connector/socket for the Prop Plug. Could I connect this to the P2D2 circuitry through the header pins or would something need to be wired up separately? With regards to Header B, the P2D2 schematic labels Pin 1 as RESn, Pin 5 as P63 and Pin 6 as P62. Can I just tie into those? Guess that would bypass the inline 220 Ohm resistors that go to Peter's header, but I guess I could add those to the carrier/main board, if prudent, but what about that Q1 transistor? And what other things am I missing and what other functionality would be lost?
 What would be a good target frequency to operate the system at in terms of power consumption/heat and video generation? There'd likely just be passive cooling, and the module wouldn't have good airflow due to being enclosed in the stand. I could maybe add some ventilation holes and maybe a heatsink to whichever side of the P2D2 that was facing upwards. The P2D2 would be piggybacked onto the carrier board with the carrier board on the bottom. Perhaps some kind of heat sink could be used between the two boards as well, but probably not (though maybe a flat heat spreader). As for video, I think Peter reported being able to lower the SysClk down to 25 MHz to run a VGA demo program. However, hopefully, the console could be run at something like 160 MHz (or perhaps some USB-friendly frequency, though Quby currently only uses PS/2 keyboards) to take advantage of its speed potential. Anyway, regarding the frequency, Quby shouldn't fly too high and melt its wax-based wings. By the way, when thinking about power consumption and heat, a P2-based Quby would likely utilize 7 or 8 cogs: 4 for video, 1 for the main app, 1 for the SD card, 1 for the keyboards that could possibly be combined with simple sound effects, and perhaps an optional cog for an audio synthesizer or video assistance (like sprites, cursors, etc), or maybe someday managing transfer to off-chip RAM, such as a HyperRAM chip). So, it's not like the P2 will just be sitting around twiddling its thumbs. Yet I'm cautiously optimistic that it will just be warm to the touch (and sometimes things just work out the way you need/want).
 I wonder if the P2D2 will be available without headers soldered in place (maybe that'll; be the default). I haven't concluded whether to use the P2D2 upright or reverse mounted, nor the gender of the headers. Despite some potential advantages to reverse mounting, I'm leaning towards upright for a couple of reasons but that could change. However, Peter mentioned reverse mounting his P2D2 on the carrier board he's designing, and, IIRC, he also stated his preference for female headers on the module and pins on the carrier board. But that's just in general and obviously subject to change depending on the actual application.
 As with the current Quby console, I'd expose an SD card socket to the outside world on the base of the console. Currently, I prefer and use full-sized SD cards because I think they're easier for users to handle and track, though that matter could be revisited. Anyway, the P2D2 module also provides a micro SD card socket on top (and an optional one on the bottom). I could see keeping this uSD card socket as some kind of "system" card, even though it wouldn't be readily accessible and that would consume more I/O pins. But I'm not sure if a uSD card could be withdrawn ("ejected") if there were a small, passive heatsink sitting atop the P2.
 Drat! I forgot what else I wanted to ask in the course of writing all of this.
Again, I'm just mulling things over and haven't committed to doing this. The only thing I've done so far is given a bit of consideration to whether I could make a main board that could take either a socketed P1 (like now) or a piggybacked P2 module (but not both at the same time). I haven't concluded anything but it might very well work. Of course, even the P1 could be on a module, but I haven't given that any real thought. And I'd likely be fine with the main/carrier board "only" working with the P2 (though both would be better in these early days). Anyway, I'm sure other questions will occur to me over time, but those above should get the ball rolling.
Lastly, at present, this is a very speculative proposition. The P2 isn't sampling or in mass production yet. And Peter is still refining the P2D2, perhaps as I write. As for the Quby game console, at this point, it's mostly a labor of love. Other than creating a website for it to support/track the project, I haven't announced it beyond this forum (and my YouTube videos are still set to "unlisted" rather than public). But I feel the console has a lot of potential for game play and learning, and given some luck, the right promotion, the right execution and the right timing lots of folks could be interested. I've personally learned a lot from working on it. Perhaps the biggest thing I've learned is that the console wouldn't have come about without this forum and the efforts of you folks. Now, at this point, I'm just dipping my toe in the water with this new thread. But perhaps someday there will be a group of forum members exploring what can be done on the Quby game console that's driven by either a P2 or a P1. And while a P2-based Quby can't really (or readily) exploit many of the P2's distinguishing features, it could make for a nice system to test out general P2 programs, what with a main screen for output, perhaps a secondary screen and maybe a couple of debugging screens (in addition to sound).
So what do you think: Could Quby and the P2D2 make for a good team? What say ye? Anyone for a QBP2D2? That just rolls off the tongue if you've had three cups of coffee, doesn't it? Okay, mates, I'll leave it at that for now. By the way, I'll be out of commission for much of the next two days, but I'll check comments and respond when I get a chance. So, thanks in advance for your comments and suggestions (or even just for reading this thread or keeping tabs on it). --Jim