WordFire Quad-Screen Word Game Console and Clock
JRetSapDoog
Posts: 954
Note: The Game-Time console has been superseded by Quby. Please visit the Quby thread of the WordFire website for details. However, the Game-Time console and Quby are compatible, and the design philosophy is basically the same.
Hot Links: Last-Page Page-4 Page-5 Page-6 Page-7 Page-8
New Readers: To save time, I suggest viewing the first post below and maybe the last few pages.
Update (copied from Post 110 on August 9, 2018): I've got a few game consoles available for sale. Units are fully assembled and tested. If anyone wants to purchase one, send me a personal message (PM) here. The USD price is $250 + $50 shipping = $300 total. Payment will be through PayPal. Orders will be taken first come, first serve, with the exception that those who have previously expressed interest have five calendar days from now to decide whether to go ahead (Obviously, people's situations can change so there's no obligation to follow through). Shipping should start next week, with delivery a couple weeks after that. This offer will be available for the coming two weeks, if units are still available. For now, I'm just selling units from the initial batch, so I won't be taking backorders (and there are no immediate plans for a second batch). Again, PM me if you want to order a unit. Thanks. --Jim
In this completed customer project, a single Parallax Propeller serves as the basis for a quad-screen word-game console and clock. Although the console doesn't walk like a robot or fly like a quad-copter, I feel that it is a nifty application of the multi-core Propeller.
While one could theoretcally develop old-school video games for the console, it is mostly designed for text-based word games. From one to four players may play, wherein each player has his or her own private viewing screen and keyboard for input. The four screens are separately driven, so that they can show unique content on each screen. This configuration allows all players to play at the same time without waiting to take turns.
Today, I'm just announcing the existence of the system to see if there's any interest in it. The system isn't for sale yet, but hopefully will be in the near future. If and when it goes on sale, the price will be in the neighborhood of $300 plus shipping. That's about as cheap as I can offer it without risking a loss. While somewhat pricey, keep in mind that the system includes four 7" WVGA screens and four full-sized QWERTY keyboards.
If you would like to be kept updated on developments, such as new games, or alerted if the system becomes available for sale, private message (PM) me with your name and email address. By the way, I've already soldered up 10 PCB's and built 10 housings, but I haven't ordered the other parts (screens, driver boards, keyboards, etc). If possible, I'd like to get a feel for the level of interest before ordering the remaining parts.
Below, are some links pertaining to the console:
Overview of the Console:
Housing Detail:
Game: Copy Cats:
Game: Things People Say:
Game: Big Pile of Words:
More videos and information are available at the website wordfire.net. The site is overkill at this point, but hopefully it'll help to keep me motivated.
Bringing the console to life and developing games for it is a big task for basically one person, so if there's anyone out there that has ideas on how we could collaborate, feel free to PM me. And perhaps a word-game club could be formed. Also, feel free to post comments, suggestions and questions on this thread. Thanks for reading. --Jim Goodpaster
Hot Links: Last-Page Page-4 Page-5 Page-6 Page-7 Page-8
New Readers: To save time, I suggest viewing the first post below and maybe the last few pages.
Update (copied from Post 110 on August 9, 2018): I've got a few game consoles available for sale. Units are fully assembled and tested. If anyone wants to purchase one, send me a personal message (PM) here. The USD price is $250 + $50 shipping = $300 total. Payment will be through PayPal. Orders will be taken first come, first serve, with the exception that those who have previously expressed interest have five calendar days from now to decide whether to go ahead (Obviously, people's situations can change so there's no obligation to follow through). Shipping should start next week, with delivery a couple weeks after that. This offer will be available for the coming two weeks, if units are still available. For now, I'm just selling units from the initial batch, so I won't be taking backorders (and there are no immediate plans for a second batch). Again, PM me if you want to order a unit. Thanks. --Jim
In this completed customer project, a single Parallax Propeller serves as the basis for a quad-screen word-game console and clock. Although the console doesn't walk like a robot or fly like a quad-copter, I feel that it is a nifty application of the multi-core Propeller.
While one could theoretcally develop old-school video games for the console, it is mostly designed for text-based word games. From one to four players may play, wherein each player has his or her own private viewing screen and keyboard for input. The four screens are separately driven, so that they can show unique content on each screen. This configuration allows all players to play at the same time without waiting to take turns.
Today, I'm just announcing the existence of the system to see if there's any interest in it. The system isn't for sale yet, but hopefully will be in the near future. If and when it goes on sale, the price will be in the neighborhood of $300 plus shipping. That's about as cheap as I can offer it without risking a loss. While somewhat pricey, keep in mind that the system includes four 7" WVGA screens and four full-sized QWERTY keyboards.
If you would like to be kept updated on developments, such as new games, or alerted if the system becomes available for sale, private message (PM) me with your name and email address. By the way, I've already soldered up 10 PCB's and built 10 housings, but I haven't ordered the other parts (screens, driver boards, keyboards, etc). If possible, I'd like to get a feel for the level of interest before ordering the remaining parts.
Below, are some links pertaining to the console:
Overview of the Console:
Housing Detail:
Game: Copy Cats:
Game: Things People Say:
Game: Big Pile of Words:
More videos and information are available at the website wordfire.net. The site is overkill at this point, but hopefully it'll help to keep me motivated.
Bringing the console to life and developing games for it is a big task for basically one person, so if there's anyone out there that has ideas on how we could collaborate, feel free to PM me. And perhaps a word-game club could be formed. Also, feel free to post comments, suggestions and questions on this thread. Thanks for reading. --Jim Goodpaster
Comments
The first prototype was a dual-Propeller composite video version, but I wasn't fully satisfied with the video consistency from screen to screen. Then I changed to a dual-Propeller version and higher resolution WVGA screens, where one Propeller just handled the keyboards. Later, I changed to a version where one Propeller handled all the game logic but offloaded the video to a second Propeller over a link. But I felt that a single Propeller version was more desirable. So I doubled up some signals on some pins and slightly modified the video driver to use a single VSYNC signal to drive all four screens, allowing for a single Propeller design.
But the use of some pins for multiple signals was worrisome, and I had occasionally seen some SD card corruption when programming the console. I knew if I could share the HSYNC in addition to the VSYNC, I could avoid the pin contention, but my admittedly lame effort to do so failed. So I decided to contact the developer of the video driver I was using--the famous and talented kuroneko of this forum--to request modification of the driver to synchronize both the horizontal and vertical signals of the four screen instances. He was able to do so within just a couple hours or so and without any test hardware. Bravo! So that got things down to a single Propeller with no pin contention and even freed up a pin for a remote control.
Then there were a number of different form factors. The first prototype was a truncated pyramid known as a frustum (I even made an epoxy resin molded version). Later, I experimented with versions that stored the keyboards inside the console, but never was fully satisfied for various reasons. Then I made a version with an X-shaped stand that could accommodate beverage containers to go along with the snack bowl in the top. That was pretty slick, but it involved a PC board in the head of the console that had most of the brains that connected with a PC board in the base for the keyboards and power. But that combination was more difficult to construct and susceptible to resets from static electricity. So, I decided to go back to the drawing board and come up with a single PCB version and new form factor. That effort resulted in the current version with the box stand, but involved giving up the bays for beverage containers, which I think was a reasonable compromise.
So all that prototyping was partly why things dragged out so long. But another factor was bad judgment on my part. I wasted a lot of time with different form factors and fabrication methods. I may have spent as much time on the form factor stuff as the electronics or programming. I wish I had settled on the current "practical but still reasonably attractive" form factor early on. That would have saved a lot of grief. Of course, all the different electronic versions didn't help matters, either. And the first several PCB's were fabricated by hand and just drawn with vectors. But that's not an ideal way to design, so I finally wised up and purchased a copy of DipTrace, which has been a godsend. And working with a local laser cutter shop has helped a lot, too. And while it was a good move to ask for kuroneko's expertise in modifying the video driver, I should have done so a couple of years earlier, as it could have eliminated the need for a couple of prototypes and the saved me a lot of time and money. Well, I'm leaving out a lot, such as my efforts to modify keyboards to use infrared signaling, but what I have already shared evidences that it's been a long road. And while I've worked hard, I haven't really worked smart. But I've learned a lot along the way.
Speaking of judgment, I've realized all along that there's a limited market for such a console, though how limited I don't know (but if it had mass-market appeal, it would likely have already been done). And the saying "If you build it, they will come!" is mostly wishful thinking. I mean many people prefer video games and most people have smart phones and tablets and PC's that are way more powerful. Yet I have stubbornly forged ahead because I think word games are rewarding to play, and playing them in person seated around a table could fill a void that exists in the current state of things where people stare at their phones like zombies with little face-to-face interaction. I also think that people would enjoy building the console, programming it, or writing their own game content, rather than just buying pre-fab stuff. In that respect, the console could be quite educational, similar to the way that one can learn more by building a robot than by buying one. However, I realize that not everyone has time to build their own stuff. But perhaps they can find time to play word games with friends and family members. Hopefully, the console can migrate beyond just being a piece of hardware to being a platform for all manner of word-based games. But that may also be wishful thinking. And since I don't know the potential, I decided to put it out there rather than sit on it any longer and let the chips fall where they may. Hopefully something good will come of it, but it's sort of beyond my control. And this act of announcing it brings me a certain degree of closure, realizing that our lives are but a vapor and we may not be around tomorrow.
I really enjoy your project. There is a lot of thinking and dedication in it. I find the beverage container extremely cool, me myself and I would never had even given a thought about that, wonderful.
Running 4 screens, 4 Keyboards and SD from one Propeller is quite a challenge, I would love to see the source.
You are breaching the barrier between computer games and classic board games by having the players sitting together, even with space for beverage.
This is a really interesting. I would like to write some games, can you give examples how to do so?
curious,
Mike
Running four screens with all the other stuff on 32 pins is only possible due to using just a single pin each for the red, green and blue color channels of each screen. Moreover, the HSYNC and VSYNC signals are shared for all screens. If you get a chance, take a look at the Theory of Operation document under the Documents (Docs) tab of the website. It describes how many of the pins and cogs are used.
Among other things, it has the following image which shows how the video pins are connected:
And this image shows how the cogs are allocated (Note: Cog 7 is basically a spare and could be used for sound generation (though I just use the game logic cog for simple beeps currently) or other purposes):
In addition to the Theory of Operation document, the following documents (also from the Docs tab) may be of interest: Output Methods and Color Constants.
And regarding programming for four screens and keyboards, see the Code tab. It provides a simple coding example that shows how to make four simple video "typewriters" (which sort of reminds me of Don Lancaster's TV Typewriter) that run independently and look like this:
That should give you a good idea of what's involved. As you can see from the text editor example, it's really quite straightforward receiving text from four keyboards, and directing output to four screens just involves an array of screens (as there are four instances). Of course, this simple example doesn't parse or compare the text with, say, text retrieved from an SD card, but it shows the basic techniques involved. One could use the same approach to, for example, make a typing games, perhaps with some kind of rudimentary graphics, such as bar graphs for various letters, which wouldn't require using any SD card data files.
I don't think the above references detail the initialization code, but that would be pretty specific to the actual hardware of the quad-screen console. But in lieu of an actual console, perhaps one could do some development on a single-screen system, though I haven't thought that through yet. Anyway, hopefully the above references give you an overview. And feel free to ask questions to fill in whatever gaps there are.
By the way, the prior console prototype had beverage bays and a snack bowl, but the current one just has the snack bowl, which is perhaps what you meant.
Impressive what you packed into one prop - what do the 7" screen cost you ?
I see mention of 640 from Prop, but 800 in the LCD via some 'driver board' - what is on that ?
Does this fold down to pack away ? The only issue I can see, could be one of storage when not in use ?
@jmg: Regarding component costs, I figure it costs around $20 a seat for an LCD and driver board combination (not including my time or import fees), with the cost being split roughly equally among those two parts. It seems likely that one could source LCD's more cheaply by buying them by the case load, but I haven't done that so far. And the suppliers I deal with are sometimes of the "here today, gone tomorrow" variety. I'm just a hobbyist trying to pull this off. I can tell from some of your comments about sourcing PCB's and chips, that you are used to projects where components are bought in volume/bulk. Although I'm not really in a position to buy screens in bulk at this time, I'd be interested in any insights you have (and I can potentially see buying boxes of 50, which is how the manufacturer packs the screens that I use). I know that there's that Panelook (?) website or some name like that, but I haven't signed up yet. One thing that I've come to realize while working on this project is that large companies (like Apple) can probably source components for, say, a third the cost of a micro entity like me, as they buy in the millions of units. That's great for the end consumer, but it kind of sets a false reference point in consumer's minds for what things ought to cost. Things that are low volume or custom like my little project are always going to cost more.
As for the resolution matter, the native resolution of the screens is indeed 800x480 (WVGA), but the console outputs a resolution of 640x480. The driver boards are then configured to kick up the 640 pixels per line to 800 to thereby span the entire width of the screens (otherwise, there are vertical black bars on either side). With the standard Parallax font (16x32 bits), this allows for 40 characters per line. That's a nice number that makes for large, legible characters, for a good user experience. On the other hand, having 50 characters per line could be nice, too. For example, it would have allowed for longer sentences in the Things People Say game, making content easier to write due to the increased wording flexibility that longer lines would provide. The downside is that it would have eaten up more video buffer memory, and memory is already at a premium on the Propeller and each screen has it's own buffer (as I don't resort to tricks to try to share the common information). As such, 40-character lines are probably the sweet spot, and, again, seem easy to read. However, I have mused about the possibility of duplicating every fourth pixel of the character data being output to feed the driver boards at 800 pixels horizontally instead of 640. That would save the step of individually configuring the driver boards to do so. And it could allow driving the screens directly without driver boards, but, frankly, I don't know how to handle the backlights. I believe they need constant current sources (but I think Rayman has done his own BL drivers). So, I just use driver boards, plus, this way, I don't have to deal with the flex cables. Anyway, I don't even know if there's time available in the video driver to double up every fourth pixel, though kuroneko--the video guru who wrote the driver--would certainly know or be able to calculate it.
As for the console folding down, no it does not for better or for worse. During development, I did work on a version that could fit into a large USPS shipping box in disassembled state (as the USPS offers a good shipping rate on such boxes). But it requires a minimum of bezel area around the screens, which might be good for a smart phone or tablet but seemed to throw off the aesthetic balance of the console (at least if keeping the current snack bowl). Also, such might involve more assembly for the buyer. Now maybe I could create a "bring your own stand" version that could still allow for beefier bezels, but I don't know how well that would be received. If going that route, I might just provide the PCB and parts. Anyway, the console does take up some space, as you mention. Actually, I think it's kind of cute as is, but I realize that a plastic injection molded version could be smaller and cuter (but that's way out of my budget/expertise). Still, the snack bowl could be used to hold things while not in use for games: candy, keys, etc. And the console may also be used as a quad-screen clock.
Oh, just re-read your comment and realized that you were asking about the driver boards themselves (guess we read what we want to see). They use a Realtek RTD2660 to convert composite and VGA (and possibly HDMI) to drive the screens. That seems to me to be one of the most popular driver chips out there for small LCD driver boards. The boards also have backlight driver circuitry. Unfortunately, the caps they use are kind of big, so they add to the thickness of the boards. I've used driver boards employing the Solomon Systech SSD196x series that power the backlight using really slim components. But perhaps such components cost more or are not as readily available (or maybe IP is involved), so the manufacturer of the boards (whoever it is) just uses largish passives. By the way, there's an image of the driver boards I'm using available by clicking on the Specs tab of the project site or here for the image itself. Thanks for your feedback.
If you already have driver/backlight boards, you could look at those SSD1963 or RA8875 driver boards, as they have large display memory included, & give more font choices.
( RA8875 has 768KB of RAM) You can likely just fit 4 x SPI into the pinout, if you use a common/shared CS.
There is also this thread : https://forums.parallax.com/discussion/168553/newhaven-display-with-on-board-ftdi-ft813-embedded-video-engine#latest
Of course, that's a fairly large change, so you may be best to release this in the present form first, to gauge the market
I have a lot of SSD driver boards (wanna buy some?). And I designed one prototype around them. But it takes a lot of time to update the RAM buffer and they can't really buffer multiple pages for my application. Plus, on the prototype I made, I had a noise problem on my distributed data bus that caused corruption with the SSD1963, and I never fully resolved the problem. Moreover, such driver boards were pricier than the boards I used and appeared to only be available from one source or at least were very hard to find (I wasn't working with raw chips). So, in the end, I let the Propeller do most of the heavy lifting, admittedly with some help from the VGA-capable driver boards to interface with the screens. However, I did toy with driving the screens directly and bought small backlight driver boards that just handled the backlight, but my source for them dried up.
And when the RA8875 came out a few years back, I investigated it, too. But the bare chip was expensive at that time and the boards that used it were much more expensive than the driver boards I had experimented with and currently use. Keep in mind that I need four of them, so that can up the cost quickly. Perhaps the prices have come down over the last year; I haven't really checked recently.
And that's pretty much been the problem with the FTDI EVE product line. The boards that use it were always expensive when I checked. Again, I haven't looked exhaustively recently, but the builders of such boards know that the buyers are either makers of industrial products or building one-off or low-volume products where the component price doesn't matter that much, not folks trying to make a consumer-oriented and consumer-priced product.
Still, I love what the Eve product family can do, as I like the vector approach to graphics, or in the case of EVE, on-the-fly display-list approach where not everything has to be buffered. But the original Eve series didn't drive the 800x480 screens I had switched to. Now, the newer chips of the family do. But, again, it's kind of expensive unless you're working with the bare chips on your own board. I've considered that, but I think I'd need some help with the programming or design. I've followed Rayman's EVE efforts over the years, including his most recent work announced the other day. Anyway, I think I'd have to partner with someone if going that route. I'm willing to consider it, perhaps in combination with the P2 when it comes out (as I'm guessing that EVE has special hardware to do things on the fly that even the faster P2 won't be able to handle on its own, if one wants/needs such graphical effects).
But I think this line of thinking VASTLY underestimates the power of text, even with a fixed font style and font size. When I first started my project, I was looking for something that ran Flash .swf code. There were no chips at that time that ran Flash natively, but there was perhaps one that had some kind of hardware assist for a subset and maybe did some emulation, likely unlicensed. Then EVE came out, which allows for graphical effects very similar to Flash animation (Flash is obviously on the wane, giving over to the less-capable but non-proprietary HTML5). But by that time, I discovered that what I was really interested in was text-based gaming, not flying widgets and eye candy. Of course, having the latter could be a bonus. But that stuff takes some time to program and could distract one from working on text-based games and content.
The P1 seems to do what I need, which is still amazing to me. Now if a game were constantly and rapidly accessing the SD card or needed to do animation, then the P1 probably would fall short. But my games don't really need that. And my games seem to fit fine within the 32KB memory space of the P1, even with four text buffers for the, count 'em, one, two, three, four screens. Having said all that, would I love the extra overhead and power that the P2 would provide? Of course! That'd be great, even though I wouldn't be taking advantage of all the pinheads (my word for smart pins). But that chip doesn't exist yet in silicon form and will be somewhat harder to work with than the P1. However, based on the P2 forum, it looks like the chip is just about all wrapped up and will be in the oven soon. As such, I can see partnering with people on the Forum to build an enhanced console around it, with or without EVE chips (a P2 and 4 EVE chips might even be overkill for the word-game use case but could be nice in general and for other kinds of gaming, etc.).
Anyway, while some may see the current console design as "half empty," I see it as "half full," and a lot of gaming can be had in a half-full glass of water by small-sized ducks. And at the very least, the console represents a good start. Of course, the next thing one might ask for are touch screens, but therein lies more cost, and since I am focused on keyboards, such aren't really necessary (though they are in tablets, by definition).
I do appreciate the links, as there's lots of stuff out there that I haven't heard of, even though my name is not Horatio (he is my cousin, though). And I'm willing to consider different approaches. For example, I did at one time contact a supplier of RA8875 boards with on-board 5" and 7" LCD (or OLED) screens. But they were still costly. And while I haven't checked recently, the RA8875 chip seemed to be either failing in the marketplace or off to a slow start, as there were very few offerings using it. But maybe it's a success in the industrial PC market or similar.
One product that I did really like combined a DRAM chip with a CLPD to directly drive a screen. It offered 8 pages of buffer space and you could flick between them instantly (of course). That's a much better solution than the SSD1963 which updates slowly, and this CLPD solution had around 10 times the memory of the RA8875 (though not the fonts, etc.). But that particular CLPD solution (from China) seemly had vanished the last time I looked for it. And it's dangerous to design around a single supplier (a risk that I've decided to take with Parallax based on what they've said about their long-term commitment to their chips). Of course, the people over on the P2 forum could design something similar with an FPGA, but that's beyond my current or likely future ability.
Anyway, design is partly about making compromises, right? I mean, as someone here on the forum likes to say, "Don't let perfect get in the way of good" or words to that effect. Still, I hear what you're saying. And when I see you on the P2 forum pushing for things like quad-pin access to an SPI flash memory chip and realize that it could make access to a world of fonts and other symbols easier (or even possible), I sit up and take notice. But I have to work with what's currently available and what I can wrap my admittedly small brain around, and, for now, that's the P1. In the future, it could be EVE's display lists or whatever. Baby steps. But this baby is getting old and it's hard to teach an old dog a new trick, hence my willingness to consider partnering with others. Anyway, the whole purpose of the console is to give people a fun experience playing word games, regardless of the actual hardware involved.
The SSD1963 and RA8875 you can check prices here - reasonable stocks of both ?
https://lcsc.com/search?q=SSD1963QL9&filter_field=mpn
https://lcsc.com/search?q=RA8875L3N&filter_field=mpn
but as you say, they still need to be loaded
Alternatives are the new 45MHz Serial SRAM from ISSI, they could do 800x480x4b as 1 plane.
or, for CPLDs the new ICE40-ULTRAPLUS has more RAM, and might manage a text-centric design, with 4 x 32kB SRAM in the data. eg 1-2-3 plane for Font, and 1 for (14?) screens char FG:BF maps
or, as you said, wait for the P2. Getting closer all the time
I remember when the SSD1963 was sampling, but it's been out a long time now and seems sorely in need of an upgrade, especially more RAM. And if one is doing something like video, then one would have to be pumping out the pixels at a fast rate anyway from the microcontroller, likely obviating the need for the SSD1963's buffer. Anyway, if the P2 gets combined with a low-pin count memory chip such as HyperRAM, the Solomon chips would only get in the way.
But the RA8875 does have more tricks up its sleeve. Still, I believe it's a 100-pin package. But if there are reasonably-priced driver boards with it already soldered that have backlight drivers, it's worth revisiting. Depending on the boards, I might have to change screens, and the price that I could get on those screens might be a considerably higher. Currently, I use Innolux AT070TN90's or similar with 50-pin flex cables, as they seem to be available in low quantities at decent prices from the suppliers I use. But if buying in bulk, pricing on the other screens might be comparable.
The EVE chips seem more user-friendly from a soldering perspective, as they have lower pin counts. Plus, they offer more features and even sound. I could more likely see integrating something like that on a custom PCB than packages with 100+ pins. I'd be willing to move the brains back into the head of the console to get close to the flex cables of the LCD's for something like that.
The other solutions you mention are interesting. Thanks. The P2 should allow for bitmapped graphics/fonts at 800x480x2 (four colors per bit) x 4 screens with just its HUB RAM, with lots of RAM left over for game logic. But it sure would be nice to connect it to, for example, HyperRAM to have multiple bit planes to do windowing and effects (even the P2 gets low on pins if using DRAM). Of course, if just using tile-based graphics like the current P1 design, then no problem whatsoever, but a bit-mapped approach is more flexible in terms of centering and font variety. I wish the P2 had 1MB to do 4 bits/pixel in HUB, but you can't have everything. HyperRAM would allow storing multiple screens to flip between. I don't know if HyperRAM ever got fully verified on the P2, though, but it seems not. I can't complain, though, since I didn't contribute to the testing. I seem to recall that someone got HyperRAM working with the P1, so I presume it'll work, but I'm not sure about it working in synch with the P2's streamer.
Anyway, thanks for the links and suggestions. I'll also take a look at what's new in RA8875 land. --Jim
As for a P2 version, we'll see. It could still be a while before things settle out. Maybe that's something we could work on here on the forums as a team. Perhaps I could be kind of a Product Developer of sorts, since the electronics and programming skills of many here far exceed mine. But such a project could use a Product Developer who really believed in it and would keep it on track. It could generate good publicity for the P2, too, even without fully taking advantage of the smart pins. Anyway, the extra pins, speed, memory and overall power of the P2 would be nice. But the best way to cause something like that to happen (it seems to me) is by putting out the current console to test the waters and to serve as a proof of concept. Games for it could be ported over with some work. And perhaps a P2 version could work with the current housing and LCD+driver board combo, as the P2 will be able to generate VGA and has the built-in D-to-A for lots of colors.
The new ISSI QuadSPI RAM costs a little more in $/Mb, but is static SRAM, and comes in SO8 packages. Mouser have stock of 2Mb
One of those can manage a pixel map 800x480x4, or 2 alternate muxed could give higher write bandwidth, and 2 screen planes.
It's still on eBay.
That uses a MAX II and SDRAM - simple, but big packages, tho for a pack-plane PCB, who cares ?
An easier upgrade path certainly has appeal, and your current pin map could manage VGA-Analog, or QuadSPI digital links, which opens up a 1 x P2 + 4 x Driver design or 5 x P2 design. (P2 replaces 1 x P1, and replaces your driver cards)
P2 can likely support a follow the beam approach, which for your text-centric design can save memory. If you buffer 2 text strips, and alternate 1 as read, 1 as write, that's 800x32x2 pixels RAM needed. (51.2kBytes at 8bpp)
@jmg: Regarding HyperRAM, I'm not really thinking about it for the current design. I want to keep the current design simple. KISS. I mean it's one main chip: a Propeller flanked by an EEPROM and an audio amp. That's it! Simple is elegant in my opinion, if it does the job, which it seems to do for text. And it's something people can build and easily wrap their heads around. Still, thanks for the 256KB SRAM chip info. Perhaps a design with four of those could be good. But assuming I didn't share the SD card lines, I'd probably have to come up with 7 more free pins to pull that off in the current design. And that would likely require ganging the keyboards together somehow, meaning yet another chip. So that would change a three-chip design to an eight chip one. Sure, the LCD's could be connected directly, eliminating their driver chips/boards, but there would still be the issue of the backlights to deal with. And I'd have to move the e-guts back into the head unit to get close to the LCD flex cables, which I'd be willing to do for the right design. But if there are that many major changes, then it might make more sense to wait for a P2 to design around. But, again, I'd rather have something that works now and that I can write games for now. No matter how sweet the graphics ability is, most of what I want to do revolves around text. So there's a law of diminishing returns at play for the increased complexity. But keep the ideas coming, nonetheless, and please correct me if I'm wrong about pin usage.
@jmg: Regarding the MD070SD, thanks for the chip info. I think that board blows away the SSD1963 boards, but it doesn't seem to be that popular. Also, for my current console design, it looks like it would be difficult to integrate it into the head unit, but perhaps there's a way. Perhaps better would be to design a board with those chips that's half the size to mount on the backs of the LCD's. I wouldn't necessarily need the tough panel stuff. Alternatively, getting four each of those two big chips on a main board would eat a lot of real estate. Anyway, that would mean getting into CLPD design, which would be a huge time sink for me as I've never done it before (though clocking pixels and synch signals out seems theoretically simple). Moreover, such a design wouldn't be nearly as elegant as a P2 and a single HyperRAM chip solution (even though such a solution at current densities wouldn't offer as much memory per display).
@jmg: Regarding five-microcontroller solutions, there was a time when I considered doing a five-chip P1 design like you've mentioned: one for game logic and four slave controllers for video. But I felt it just added too much complexity, and it added around $40 in raw component costs (not including assembly and testing). I did do a two-chip version, wherein the second Prop was a slave handling video, but I didn't really like the indirectness of having to send display instructions and text to the slave (though I think I'd like that concept with something like the EVE series or maybe the RA8875), and updating the screens was somewhat slower. Also, for multiple Props, you have to flash multiple EEPROM's, at least until you get the slave's firmware stable. I felt that added more complexity for me (and potentially for my users). Having said all that, I'd rather use a P1 or a P2 as an LCD driver than the RTD2660 because the latter doesn't really contribute anything more in terms of graphics since it doesn't have a buffer that you can leisurely write to or any 2D hardware-assisted stuff. And while the RTD2660 can handle composite, VGA and HDMI (I believe), it doesn't exactly sip power. Still, a problem with using the P1 or P2 as display controllers is the need to drive the backlights. Maybe I should have focused on designing my own backlight driver boards (that omit the RTD2660 stuff, since the Prop can generate VGA (assuming it could do WVGA). But even without an RTD2660 (which I'm guessing costs the manufactures under $2), it would be hard to arrive at a price lower than what I can buy the RTD2660 driver boards at. But such a solution could allow for longer operation from a battery, although I'm currently not using battery operation on the present console. Oh, as I mentioned above, I did buy some small driver board strips that just did the backlights. But I can't find them anymore (and never figured out who the actual maker was, which has sometimes been a problem for me with stuff I've sourced from China (though sometimes one can guess)) and they did cost about two-thirds of what the RTD2660 boards cost.
I'm curious with all your LCD tests, did you ever try direct LCD drive - ie a P1 onto the RGB lines and clocked ?
I'm trawling the LCD data trying to gauge just where the fish-hooks are, and they are vague on Minimum CLOCK or Frame time.
Using the data sheets typical DCLK speed, gives a 'normal operation' frame rate of 30M/((800+128)*(480+45)) == 61.576 Hz
eg I have a 72MHz 8b MCU with a FIFO SPI port and simple external Logic MUX to RGB, using DE LCD mode drive, the data numbers give ~Min-column Frame Rate of (72M/4)/((800+88)*(480+4)) = ~41.8807 Hz
A 96MHz P1 could target something in the region of (96M/8)/((800+88)*(480+4)) = 27.9204 Hz (clocking only, I've not checked SW ability to feed that - perhaps 25Hz allowing some SW ?) )
So they are close, ( 28Hz or 42Hz vs 61Hz) but I cannot find LCD info on tolerated minimum frame rates, or tolerated jitter (aka small clock pauses).
With a small MCU there will be some jitter from other interrupts, & even in P2, getting it to a true zero clock gaps will take extra care.
@jmg: I have not tried directly driving the screens, even though I did buy some backlight driver boards for that purpose. By the way, I did manage to find a single source for those backlight driver boards last night, but, unfortunately, the vendor wanted more for them than I pay for the RTD2660 boards (as the latter are more in demand, I presume).
I recall that Rayman has directly driven raw LCD panels at 640x480, I believe it was, with very similar drivers to the "standard" ones on the OBEX. In my case, I'd have to modify things to work at 800x480, and I'm not sure that I'd be able to get it to work. Anyway, I'm a little lacking in the motivation department for trying that due to still needing to provide backlight drivers. And even if I could do my own BL driver circuitry, I'd have to move my main PCB back into the head and also equip it with four 50-pin fine pitch SMD connectors for the LCD's. But I don't know if those could take the heat of my unmodified toaster oven.
Also, I haven't overclocked anything, yet, but rather just cruised along at the standard 80 MHz. Of course, 96 MHz would give more time for the video driver to do stuff, but I have my doubts that I could modify kuroneko's driver appropriately to take advantage. Actually, maybe there's a chance that his driver could directly drive WVGA at 80 MHz by stuffing in duplicate pixels 20% of the time to "upscale" from 640 to 800 pixels per line while keeping the current text buffer footprint (as I need to conserve as much memory as possible for game stuff), but perhaps even the added bit of PASM logic to duplicate pixels would cause things to fall behind waitvid's needs.
Maybe I'm mistaken in the above speculation. I haven't calculated the maximum dot clock that an 80 MHz P1 can sustain (with the help of the shifter). But I seem to recall trying someone's code to output 800x480 with just the standard 80 MHz crystal. I forget the exact results for me. I think the display was either garbled a bit or unstable, but apparently things worked for someone else. Anyway, hopefully it's doable AND in ONE cog.
In your "trawling," I wonder if you were scooping up info on the AT070TN90/92/94 family of LCD's (their data sheets are out there, not that they'll necessarily provide the level of detail you're seeking). I've mostly used the 90's, though I started with the 92's. Anyway, hopefully the timing requirements are forgiving enough. So, even with the P2 and foregoing interrupts, you apparently still expect a small bit of jitter. I guess nothing is absolutely perfectly synchronized, but hopefully any jitter wouldn't show up on the displays or cause a loss of synch lock (if there is such a thing with a raw panel).
I recall his work around SSD1963 & can find this http://www.rayslogic.com/Propeller/Products/DviGraphics/DVI.htm
and I see mention of a 1024x768 VGA Driver, - but nothing on direct LCD RGB drive ?
Yes, data seems to be similar across many.
P2 should be able to get low jitter with 2 COGs, but it will likely need some careful tuning to time-match DE signals with streamer/LUT outputs.
The displays are all clocked, so they should tolerate clock edge variations, as the data moves too.
It may be that a 'visually even' display needs evenly paced pixels, but I expect there is at least a line shift register in the driver ICs, and that should tolerate small pauses ?
As for the P2, my project wouldn't be able to afford 2 cogs for video (as that would take up all 8 for 4 displays), unless the pair of cogs were generating video for more than one display screen. I guess each cog gets one set of four DAC's in the current version of the P2 that's going to press, so perhaps 2 cogs working cooperatively could drive two displays, providing each cog handled the final DAC connection separately. But I may be mistaken about the P2's architecture.
You're not saying that you've done the math and concluded that one P2 cog couldn't output 800x480 at say 2 or 4 bpp with one cog, are you? I would hope not, since the streamer can rapidly feed the DAC's and/or pins. But if you are saying that, that's unsettling. I guess the P1's shifter, as such, is gone, and bit-banging would likely be too slow to hit WVGA resolution. But hopefully the P2's new features can handle the job with abandon. Of course, that's all theoretical at this point prior to silicon, other than the FPGA testing (at slower clock speeds) that's already been done.
Ahh, this from 2009 I think...
Looks to use Video PLL and a Counter as the clock (continual).
P2 could certainly replace your P1, and use the DACs to give better colour choices (assuming they work as hoped) with the same looms and Driver VGA-TFT cards.
I was thinking/musing above more about a P2 replacing the RTD2660, initially on a simple 1:1 to keep mechanics simple
- uses one COG on video and one on Serial link/'Terminal'. Leaves 6 spare cogs - ie a lot of spare headroom for sound etc. and one COG could manage your backlight / supplies issues.
A P2 could manage 2 displays in full colour, with pins to spare, but that gets more 'interesting' mechanically, as it dictates the FFC lengths.
Even 4 displays in theory could fit One P2's ( 4 x COGS), with 12~15 pixels/display but I'm not sure about cabling that !!
With an eye on that simpler cabling side, I'm also working the numbers on an EFM8LB1 MCU as possible RGB display driver. QFP32, just over $1, + 2 x cheap Logic MUX's HC157 or HC257
Looks like it can manage a ~42Hz Frame rate display (800x480), 16x32 font, with 8bpp, and 15 or (tight) 18 char lines (800x480 or 800x600) a palette of 256 or 106 and two screen-planes.
A ~200k Baud serial link could sync RX chars by polling at line rate, and lower jitter effects, if that proved an issue.
Q: Is 200k baud & 2 screen planes viable ? ie maybe 60ms for full screen update. (37 ms chars only, noXYFB)
No, I'm not saying that
Yes, the streamer should manage each line scan, via CLUT & because you are Char based, you may not need 800x480x4bpp image memory
When real P2's are out, I'd expect such display examples to be early in the to-do lists...
If I was Parallax, RGB LCD display drive along the lines of EVE, (RGB, Touch, SMPS, BL, Sound*) would be up near the top, as the volumes here can grow quickly, plus it 'demos very well'
eg A dual screen LCD driver has point of sales applications.
For sound, the NAU88C22 looks an interesting companion part. Headphones and 1 W speaker, plus volume etc.