Feasibility of Integrating Peter's P2D2 into the Quby Game Console
JRetSapDoog
Posts: 954
in Propeller 2
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:
[1] 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.
[2] 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.
[3] 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.
[4] 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?
[5] 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).
[6] 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.
[7] 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.
[8] 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
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:
[1] 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.
[2] 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.
[3] 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.
[4] 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?
[5] 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).
[6] 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.
[7] 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.
[8] 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
Comments
I think the graphical improvements are a major plus for your Quby product if you go with the P2.
I personally like the minimal look of your current graphics and the P1 in general, but I know a lot of consumers would want to look at something more bit-mapped and graphical in nature.
Yes, I believe you're right. And the P2 would allow for more colors, too.
As for graphics modes, tile maps (mostly text) could still be used to conserve memory. Or tile maps could perhaps be merged with a bitmap field, like for button boundaries and so on.
But the most flexible approach would be to render text as straight bit maps. That allows for both text in different fonts styles and various graphical elements and widgets. It takes a lot of memory, though. But text games generally don't need that much memory, at least not the ones I've been working on.
Using bitmapped graphics and without adding an external memory chip, the P2 could do, for example, 640x480 at 2 bpp x 4 screens = 307,200 bytes (or 460,800 bytes for 3 bbp), which still leaves room for code. Those numbers assume that the screens are being driven with 640 pixels per line rather than 800, just like is presently being done (wherein the 640 pixels are stretched to span 800 pixels).
Although that's not a lot of colors, the color set could probably be selected for each scan line across the screen, allowing for differently colored areas. For that matter, perhaps the screen could be broken up into somethng similar to tiles but only for selecting the color set used for each "tile", not the pixel contents, sort of like the local dimming feature for some backlights on LCD TV's. There's probably a lot of possibilities.
Of course, an external memory chip could make things wide open and allow for paging, but it's not a strict requirement and adds complexity. Besides, I haven't seen the P2 interfaced to one yet. I wrote up a large post about that a few days ago, but didn't pull the trigger on it, which is probably good as I'm already "poluting" the P2 forum with this thread.
Thanks for your comment and encouragement.
As for mounting that is up to you but as I mentioned before I see no reason to mount it any other way than what I described since the female header on the P2D2 module means it is easy-peasy for anyone to use cheap pin headers that can be cut to length and with the female header on the module means you will never end up with busted pins. Plus when it is stand-alone I can poke components or wires directly into the socket. If it pins instead then you would always need a connector.
As for 4 screens why don't you consider QVGA resolution with 8-bit bmp palette over VGA timing so that you end up with 4 screens in 310k? It also means you have memory for buffers so that you can use those really fast setq/rdlong/setq/wrlong memory move sequences to update the screens smoothly.
My P2D2 as it is at the moment.
Hey, your welcome buddy. : ]
You could use a tile mode of 16x16 pixel fonts, 16 colors per pixel (4 bit), that's 128 bytes per tile.
256 tiles is enough to include all the letters and symbols. That would need 32k of RAM to store those tilesets.
640x480pixels across is 40x30 tiles. So you'll need 1.2k per each screen.
Having 16 colors per pixel would give you options to add drop shadow and outline to the text.
Bitmap will let you draw things not locked to a tile grid, but like you said that does take a lot of memory. bitmap does have the advantage of variable width fonts. which might look better for your application. since it is text heavy.
Just thinking out loud.
Quby is cool!
Keep in mind, there are multiple P2D2's, the shipped rev F has a few hand-capped parts, and for the next rev, Peter has mentioned changes in regulator.
I'd expect the next packaged parts not going into the Parallax board, will mostly go into P2D2 rev H+?
'around 6V' could need care, as many switchers are designed for 5V (5.5V max) rails.
Linear regulators are pushed when powering P2. given the high Icc and the high MHz numbers mean users will want to push Icc higher...
The P2 eco-system would definitely benefit from a board like the P2D2 along with a larger dev. board, so if Parallax does end up making/selling these small modules, that would be great.
Thanks for the fan and mounting information, too, as well as the QVGA comments. Regarding the latter, I've always loved the three-pixel-wide Parallax font for it's readability, and it works well at VGA or WVGA resolutions. But the P2 will open up lots of possibilities with other font options (different sizes, fixed- and variable-width (if using bitmapped screens)).
To Ym2413a: Yes, it'd be nice if text wasn't locked to a tile grid. That allows for horizontal and vertical centering, and also allows for proportionally-spaced fonts.
As for Quby being cool, thanks. It's at least cute. And it certainly runs cool now, but it could ironically heat up if transitioned to the super-cool P2.
To jmg, thanks for your comments. I seem to recall reading about a version H being in the works. Forgive my ignorance, but I'm not sure what "hand-capped" parts are (though I tried to look it up). I wonder if that has something to do with whether the decoupling caps can use P&P. I assume that you're not talking about the preliminary package for the P2 itself since you used plural form.
As for the switching regulator comment, thanks for the warning! I wasn't aware of that (never directly used one before). I don't know if the MCP1700 is still on the table, at least as an option, but I see that the datasheet lists a Vin range of 2.3V to 6.0V. I think the power adapter I use outputs 6.2V when not loaded much. That's technically outside the stated range, though, isn't it?
I might be able to drop down to a 5V adapter, as the driver boards have DC-to-DC circuitry for the backlights and they seem to work fine at 5V. I've ran them from power banks before. Sometimes, the datasheets for them do specify 5V on the lower end, but I think that they are more efficient at higher voltages (which could lower the total power draw of the console, which currently uses a 3A, 6V adapter).
But then I'm not sure how I'd power the keyboards. Maybe I could use 5V from the adapter straight in, but that might be risky. I think that the keyboards that I use can work off of 3V3, so I guess I could power them through an LDO regulator. But I perhaps that would mean that I'd have to keep using PS/2 style keyboards rather than USB. Actually, that's my plan anyway for now, because I'm not sure if USB can work in one P2 cog, especially for four keyboards, and even if it can, I wouldn't know how to code it.
Thanks for comments, guys. I need to submerge again but will check back later.
I like to describe smartpins as "peripheral per pin" technology but if somebody were to look for a "UART" in a smartpin, then it doesn't exist as such. What we do have though is way better in that unlike a so called "Universal Asynchronous Receiver Transmitter", the smartpin is far more universal and able to handle up to 32 bits and synchronous as well. It is so easy to setup as well, in fact from TAQOZ you would only have to type 21 PIN 921600 TXD to configure P21 as 921,600 baud async transmitter and then 21 SERIAL ." Hello World" to output to that "port" which must be the shortest and most efficient Hello World code there is.
In regards to USB I will be using wireless dongles so that I can connect any number of keyboards and mice etc to the same USB port. The only problem is that this won't identify which keyboard sent the data which Quby needs to know. However you could use cheap wireless keyboards and not have external connectors. I really wish I could buy an active USB to PS/2 module that really did accept USB HID but interfaced as PS/2 signals (but please, not the big connector and bulky plug).
To Peter: Do any USB HID to PS/2 modules exist even with big connectors? No, I don't want and don't use the big connectors either. There's those HC-05/6 devices that use SPP, I believe, but I've never used those. I suppose that SPP is similar but somewhat different than PS/2. Anyway, it seems that people normally want to make customized keyboards that can do Bluetooth rather than go the other way. But yeah, whatever keyboard solution is used for Quby definitely needs to be able to identify or differentiate between the keyboards, as you indicated (unless the keyboards were modified to only output certain keys which likely ain't happening).
To jmg/Peter: Rather than using a 5V power adapter, I wonder if the 6V adapter that Quby uses could be knocked down by ~0.7V with an inline power diode to get under 6V, which would at least get the voltage within the range that the MCP1700 can accept (don't know about other SMPS devices). And maybe that could offer some reverse polarity protection if the P2D2 module were plugged in the wrong way. Feeding the module through a power diode would still allow the carrier board to have the full 6V to feed to a LDO 5V regulator (though maybe 1V is not enough headroom for some LDO's).
Never underestimate the power of inertia. There are working designs for LS/FS-USB (no R&D cost) which will enumerate perfectly well on HS ports. The more likely future shift is to USB-C, but even then an adapter is a more likely near-term solution.
Re USB to PS/2 connectors:
Not cheap, but there are these KVUSB-PS2
As for differentiation between keyboards, you could implement a keyboard identify routine on start-up that asked users to strike a key on each keyboard in turn. If the USB driver allows reading of the address of each keyboard, as well as the data received, a single USB driver could manage all four keyboards, possibly even feeding four separate input buffers for the game logic to process, or encoding the keyboard ID into the input buffer stream; whichever is preferable.
I forgot about Bluetooth keyboards, that should be a bit easier although good Bluetooth keyboards aren't cheap. Practically every board I've seen that accepts PS/2 seems to use those bulky PS/2 sockets and then that bulky plug that goes into it. If you use a passive USB-PS/2 adapter because the PS/2 keyboard has a USB connector, then things get worse. Just use a USB A socket in the first place so that an PS/2 compatible USB keyboard can plug directly in and let software decide to talk to it as PS/2 or if able to, then USB.
I see there are a lot of USB keyboard to PS/2 adapters but they usually turn out to be passive connectors designed for PS/2 compatible USB keyboards. Either way, standard USB keyboards are plentiful and cheap, anything else is not.
I was also going to mention using a diode or just to drop 6V down to within a safe operating range as long as the 6V is 6V and not 7V. The new P2D2 will still have an option for an LDO or for an XCL220 switcher in case more 3.3V power is required externally. If you are worried about plugging in the P2D2 the wrong way then don't get out of bed or don't ever plug a P1 into a 40 pin socket just in case you get it back to front. I mean, is that likely to happen? Yes, the same as getting struck by lightning or hit by a car. Besides the new P2D2 has that little bit of an extended edge for a reset switch and larger leds and connector etc and so I would simply put a post or something down the other end on my dev board. Then guess what? You won't be able to plug it in the wrong way around.
Keyboard: https://www.amazon.com/StarTech-com-Replacement-USB-Keyboard-Adapter/dp/B000A0K2JO
Mouse: https://www.amazon.com/USB-Female-Male-Adapter-Mouse/dp/B00HDGULP8
They are probably the same inside, just color coded for mouse/keyboard.
Of course, getting USB HID working on P2 is preferable, but those cheap adapters work fine.
Yeah, they are "passive" adapters that are meant for and supplied with USB keyboards that internally support PS/2. Very very few support this mode.
The Amazon ad has this note:
Note: This is a replacement adapter that can only be used with USB keyboards that are both USB and PS/2 compliant. If you keyboard shipped with a similar adapter than this adapter will work with your keyboard. If your keyboard did not ship with a similar adapter than this adapter will not work with your USB keyboard
BTW, that's what I mean by "bulky".
I only pointed out the existence (and expense, and bulk) of active USB to PS/2 adapters. Inspection of the internals of the BB unit shows not one, but two PIC microcontrollers.
I agree that getting P2 talking USB is a far superior option, hence the rest of my response.
Maybe in time we can get CDC, MSC, and ADC as well as HID.
It's often supported because PS/2 supports more n-key rollover. I have my current keyboard hooked up this way, because it supports full keyboard rollover, vs only 6 key with USB.
Well I have USB A on my test board so I will plug in some keyboards and see if they respond to PS/2 protocol. Of course I will have pullups for this test although I should look at enabling pullups on the P2. I'm testing audio and Ethernet at the moment but I will write some Q&D routines for PS/2 in the meantime anyway.
BTW, it's the bulky connectors and adaptors that I dislike. They turn a nice neat little unit into a clunky and rickety "junction' box.
For P2, It's unlikely that the n-key rollover thing will matter much, I mainly run into it in certain games I play. I think the issue is in the HID spec, not allowing for enough simultaneous key presses in one "packet" or whatever it is, whereas PS/2 can just send as many as it wants.
I'll use whatever gets sorted out.
To All: The consoles I've made have never used actual P2/2 connectors nor adapters. As is mentioned above, I just use USB Type A jacks with keyboards that can handle both the USB and PS/2 protocols, automatically detecting the connectivity behind the scenes.
As for being able to source PS/2 capable keyboards with USB cables, I've had absolutely no problem finding them from multiple vendors. Well, the only problem I've had is that the vendors generally don't know whether the keyboards they sell can do PS/2 or they just say "No" because the keyboards only have a USB jack or don't ship with a bulky adapter. So in that case, I'll usually buy one to test it first and then order more if PS/2 works. I've never had one that didn't work, and I've tried about five or six vendors. Also, I've picked up various keyboards in retail stores here in Taiwan before and all of them have been able to use PS/2 signaling with the exception of one. But I only buy the slim keyboards with the chiclet (or chocolate) keys. Oh, I also used two different kinds of flexible silicon (roll up) keyboards, and they worked also, but those keyboards don't store well in my experience, with some keys failing to work after they've been rolled up too long.
Maybe PS/2 keyboards will be difficult to source some day, but, so far, they are easy for me to get. However, I imagine that many premium keyboards don't support PS/2, though I haven't tested them, as I only buy the ones that I'm hopeful will work. Now as Roy said, PS/2 may offer rollover and even response time advantages for gamers, so I don't mean that kind of premium keyboards.
Anyway, if we could get low-speed USB working in one cog and supporting four keyboards, that'd be fantastic, but, for now, I'll be sticking with PS/2 keyboards.
Gaming? Yeah.
Frankly, I prefer PS2 for simplicity. Some keyboards made today skip PS2 support.
I pretty much will just get one that does. PS2 keyboard and mouse are cheap, low footprint, simple, etc...
Got nothing against USB. Use it all the time on PC, laptop...
For P2? I will likely skip it, unless there are super compelling reasons not to. Storage maybe?
It's not noticeable in normal typing. It's usually at least 6 keys.
Needing 3-4 COGs for this would be getting out of hand if PS/2 only uses a single COG for both devices combined. Ultimately getting some hub support would definitely be a major winner there.
I'm currently working on a USB mass storage demo that's getting close to a drop, and after that hub.
Edit: Currently the mass storage focus is on "thumb drive" media, and I have a couple of SDCard readers that work. In general, USB 2.0 parts work well, but 3.x parts can be finicky, which I think may be related to the current 80Mhz ceiling.
So 80MHz won't be a problem in the release silicon. What sort of COG/LUT memory consumption are you experiencing? Is higher speed likely to be enough to bring the current driver down to one core?
Chip really needs to get you a P2 Board, so you can chase down the more subtle issues like that "In general, USB 2.0 parts work well, but 3.x parts can be finicky"
Can't wait to see what you will do with a real P2. Are you getting an eval board?