Your search skills are impressive. Gee, time does fly.
Sorry, I temporarily lost sight of the replacing the RTD2660 angle.
Yeah, the P2 could be a nice replacement for the P1 in my application with a lot more overall power, especially graphically. And the DAC's would eliminate the resistor DAC's I currently use (even though I just use one resistor per channel), opening up a spectrum of colors.
I've asked myself about the idea of one P2 cog being able to handle four screens before, freeing up three cogs. The main thing that limited the P1 was getting data from the HUB, but things should move much faster on the P2 (and things would scream if things can be kept in step with the streamer).
But what I'm unsure of is the internal connection of the DACs. While there are 64 smart pins, there's only 8 sets of DAC's. In a prior design of the P2, I think one could choose which DAC set to connect with, and that allowed for one cog to potentially connect with more than one DAC (though probably not in the same instruction). But looking at a diagram for the latest architecture, I'm not sure that such is still the case. It looks like a cog is limited to one DAC. And there's no inter-cog communication channels, so I'm not sure how one would break out of that. But maybe I'm wrong about all that, as I may be reading in too much to the system architecture diagrams I've seen. Maybe things didn't change after all. I must confess that, in order to make progress with my project, I've taken to doing some skim reading of that P2 forum over the last year or so.
The EFM8LB1 seems interesting from a cursory look at this datasheet. It might be over my head, though, even with an extended look. And it's another thing to program. Yikes! I wonder if those DAC's can operate at video speeds. And I'm not sure how to get data to them, and it seems like the chip count is getting up there with the MUX's. Also, offhand, I'm not seeing how that simplifies cabling. If you say it does, it does, but the light hasn't turned on for me. All I know is that I eventually have to connect to 50-pin flex cables with the present LCD's. And are you talking about the EFM8LB1 in connection with the P1 or the P2? If I moved the project to the P2, I likely wouldn't want to limit things to "just" text displays.
As for baud rates, if using the P1 (and maybe even the P2), I think full screen refresh rates of around a tenth of a second (100ms) are acceptable, perhaps even a bit slower. I like for the screens to basically change in a blink of an eye from screen to screen, but I don't need video rates. As for planes, I currently don't use any sprites or cursors, but if something could be overlaid, so much the better. With a P2, ideally, it would be nice to support popup windows that could truly overlay the background without blanking stuff out around the edges, but I figured that would be more doable with off-chip memory. With the P1, I can certainly get by without that.
If moving to the P2, character-based displays are simpler and one could buffer many different screens; however, using 2 bpp bitmapped displays would allow maximum flexibility for centering text horizontally and vertically and for simple boxes without having to resort to tricks with a tile-map setup. But that may be looking ahead way too far at this point. It's fun to think about, though.
Maybe I can check out that sound chip later. I realize that people say that the TDA7052A is "long in the tooth," but it seems to get the job done for my current purposes. But I've just used it for simple beeps or buzzes. And I haven't thrown a sound cog of some kind at it.
Thanks for your comments. While I wasn't able to keep up with all your ideas this time, such as for the cabling, I do appreciate them. BTW, I'll be offline for 10 hours or so.
Yikes! I wonder if those DAC's can operate at video speeds. And I'm not sure how to get data to them, and it seems like the chip count is getting up there with the MUX's.
The DACs have a slew-limit, so I've found you can INC and DEC at full speed (LSB at 36MHz) but you cannot do a 50% step.
So, not enough for video, but good enough for low-distortion Sine/triangle wave function generator.
Data from P1 to the 4 x EFM8LB1 would be via 4 separate serial links. (200k+baud)
The MUX's are quite cheap, ~ 15c, and easy to handle, and they allow a decent 8bpp.
And are you talking about the EFM8LB1 in connection with the P1 or the P2? If I moved the project to the P2, I likely wouldn't want to limit things to "just" text displays.
The EFM8LB1 pairs better with the P1, as it can manage 16x32 font and do a full 50x15 chars with a 8bpp palette, but not much more.
It's easiest to use what you already have that works, but if you found you needed to bump chars from 40 to 50, or more colours, or cannot get RTD2660, or hit enough volumes you are motivated to cost-down a bit, the EFM8LB1 may be viable.
Once you dropped in a P2 master, the EFM8LB1 is not keeping up with what a P2 could manage, so there I think P2's on video are better... which brings us to :
Also, offhand, I'm not seeing how that simplifies cabling. If you say it does, it does, but the light hasn't turned on for me.
The cabling comments relate to P2's as RGB drivers, not so much to EFM8LB1 as being simpler. EFM8LB1 has a uart link, which is slightly fewer wires than HV(RBGx4).
With P2, that has enough horsepower to drive all 4 x 50 pin connectors, to some useful bpp, but how to design a PCB that easily accepts 4 cables ?
I guess a quite large PCB with a connector on each edge might work, tho it's nice to secure that connection during assembly and transit ?
Not sure about 1 P2 COG driving 4 displays, I may have been unclear above, I was meaning 1 COG per display, ie as you do now. I'd do the 1/COG first, then see if 2/ or 4/ was comfortable.
Whether the whole shebang (P1 and 4 display drivers ) could swallow into just 1 P2 likely depends on the Pin budget, and the bpp you want. ~11 bpp (x4) would equate to P1 pins.
On frame rates for SW RGB : I did find an other forum comment that claimed 1MHz min on LCD, but I'm not sure how believable that is. That's ~10Hz frame on the smaller TFT display they were talking about.
I found a couple of 480x272 data sheets that mentioned 5MHz min, 9MHz typ, which maps to a min frame rate of ~ 25Hz, sounds more plausible.
It may be that the lower limit is more related to human eye effects, as movies are projected at 24 fps, so it's likely best to try to keep above that.
On that basis, the ~42Hz an EFM8LB1 can get, is sounding like it could be ok.
Okay, perhaps the light is starting to dawn. The four EFM8LB1's would replace the four RTD2660's. The reason is to elimiate the driver boards to reduce cost and maybe complexity, as well as bump up the the number of colors.
So, looking at the EFM8LB1's datasheet, I'm seeing a lot of FLASH but not much RAM. Thus your idea would use the FLASH to store a character set (font) similar to the one that's built in to the Prop. For example, 256 16x32-bit (64 byte) characters would take up 16KB (and the EFM8LB1 datasheet says it has up to 64KB).
Then I guess you're proposing using much of the 4+ KB of RAM in the EFM8LB1 to buffer one or two screens worth of characters. A 40 char x 15 line screen at 2 bytes/char (1 for ASCII and 1 for a fg/bg color pair) would need 1200 bytes, and a screen with 50-character lines would need 1500 bytes. Perhaps two screens be stored or a screen with two planes.
And apparently your suggesting using part of the EFM8LB1's up to 29 I/O pins to directly drive the LCD, no DAC's required. And even if it had video DAC's, we'd be back to needing driver boards, wouldn't we. Sorry for the confusion on my part with my own project. It's sounds a bit similar to using 5 Props, except that the EFM8LB1's are, say, one-fifth the cost and they don't need EEPROM's or external crystals. The solution might also use less power. Am I getting things right, or have I walked from one cloud into another?
For the current console form-factor, such a solution would work best by putting the main PCB back in the head (including the SD card socket). That's how my older prototypes worked. The PCB size was 15x15 cm, with some room to spare around the edges. I think the space occuppied by the 12-pin and 4-pin PH 2.0 connectors that were (and still are) used to connect up with the driver boards would be enough for the flex connectors for the screens. But I'm not sure about the rest of the chips. I guess the Prop might have to switch to the QFP package for that to work (and maybe things could be an all SMD one-sided design).
Of course, there would still be the matter of driving the backlights of the LCD panels.
As for a single P2 solution, using four cogs to drive four VGA driver boards seems attractive. Firstly, I don't think that one cog can connect with more than one DAC. And secondly, using a whole cog potentially allows for more graphical effects than trying to drive multiple displays with one cog. So, my apologies for driving us down that road.
Then one could use a five-P2 solution, but that would be as expensive as using VGA driver boards and wouldn't take advantage of the DAC's. And a single P2 would not pair well with four EFM8LB1's because it would unnecessarily limit things to text.
As for the frame rates of LCD's, I recall that Rayman has driven them at rates well below standard video rates. I forget the exact numbers, but perhaps something like 15 fps or lower. It almost for sure depends on the panel and the size may be a factor. Also, I don't know if doing so long term can cause any damage. Hopefully, its still fast enough to keep the liquid crysals happy (not degrade them). But I guess something like that would have to be tested for many hours (days?) with a specific setup (the EFM8LB1) and panel (like the AT070TN90). Alternately, perhaps relevant research is already available.
Okay, perhaps the light is starting to dawn. The four EFM8LB1's would replace the four RTD2660's. The reason is to elimiate the driver boards to reduce cost and maybe complexity, as well as bump up the the number of colors.
So, looking at the EFM8LB1's datasheet, I'm seeing a lot of FLASH but not much RAM. Thus your idea would use the FLASH to store a character set (font) similar to the one that's built in to the Prop. For example, 256 16x32-bit (64 byte) characters would take up 16KB (and the EFM8LB1 datasheet says it has up to 64KB).
Then I guess you're proposing using much of the 4+ KB of RAM in the EFM8LB1 to buffer one or two screens worth of characters. A 40 char x 15 line screen at 2 bytes/char (1 for ASCII and 1 for a fg/bg color pair) would need 1200 bytes, and a screen with 50-character lines would need 1500 bytes. Perhaps two screens be stored or a screen with two planes.
And apparently your suggesting using part of the EFM8LB1's up to 29 I/O pins to directly drive the LCD, no DAC's required. And even if it had video DAC's, we'd be back to needing driver boards, wouldn't we. Sorry for the confusion on my part with my own project. It's sounds a bit similar to using 5 Props, except that the EFM8LB1's are, say, one-fifth the cost and they don't need EEPROM's or external crystals. The solution might also use less power. Am I getting things right, or have I walked from one cloud into another?
Yup, pretty much nailed it
There are some minor variants possible around the details of fg/bg, but the rest is 100%.
With the simplest 1-byte fg/bg, as you listed above, that gives 4bits each, and needs a single So16 mux, ... but is only 16 colours.
It a minor speed penalty to have that fg.bg byte instead index a palette, which has a pair of bytes for 8b fg and 8b bg, (512 added total) and uses 2 ports on the LB1 and now 2 MUX's, but bumps to 256 colours.
I've confirmed the SPI port has 3 byte deep buffering (1 x shifter + 2 fifos), so that helps simplify code. (16 w font can simply load 2 bytes, no polling )
The uart looks to have 2 bytes deep buffer in TX, but RX side is not co-operating, and looks to be single buffered. Data is rather conflicted there, as it suffers from cut/paste-itis - maybe I've missed some RX-fifo enable bit somewhere **
I've confirmed the EFM8UB3 has a 5 deep UART buffer, (1 buffer+4 FIFO) on TX side - that's a 48MHz core, 40k Flash, 2048 XRAM.
** Addit: I changed LB1 code from a read_buf to a poll TI,RI, and that can only accept 2 bytes sent, if phased just before the 2nd byte mid-stop bit. ie it is just single buffered Rx, but can queue 2 on Tx.
As for the frame rates of LCD's, I recall that Rayman has driven them at rates well below standard video rates. I forget the exact numbers, but perhaps something like 15 fps or lower. It almost for sure depends on the panel and the size may be a factor. Also, I don't know if doing so long term can cause any damage. Hopefully, its still fast enough to keep the liquid crysals happy (not degrade them). But I guess something like that would have to be tested for many hours (days?) with a specific setup (the EFM8LB1) and panel (like the AT070TN90). Alternately, perhaps relevant research is already available.
Interesting. I'd expect mainly flicker type effects to keep designs away from lower speeds.
While all of this discussion of how to implement a better version of WordFire with a P2 is interesting, it would also be interesting to hear people talk about the kinds of games this platform might support. I've been thinking of multi-player text adventure games. What other ideas do people have?
Yes, palettes can be a good way to go. Even the video driver for the current console uses a palette that allows for 16 foreground and 16 background colors selected from 64. But the console hardware can only generate 8 colors, so there's no real need for the indirection with it. But it allowed for potentially more colors for a two-screen version where maybe two-bit RGB color channels were used instead of one-bit channels.
As for using the EFM8LB1 or one of its relatives to replace the VGA driver boards, if I had to decide right now, I'd probably say that I fear that it would add more complexity than it's worth. It does add tons of colors, but I feel I'm getting by pretty well with the eight that I have, which, again, allows for dozens of fg/bg pairs. Sure, all things being equal, the more colors the better. But they come at a price of complicating the main board that I'd have to manufacture and test.
Also, I just checked, and I see that I can now get the driver boards for around $8 each (in low volumes), not including shipping, etc. But I figure that using the EFM8LB1 could cost around $2, maybe more, for the chips, support chips and the FFC connectors. So, I'd really only be saving $6 per screen, which amounts to $24 off the BOM, which is not insignificant but may not be enough to justify the change.. Plus that doesn't take into account the backlight circuitry.
Another reason I'm inclined to stay with the driver boards is that they could work with a single P2 version using its DAC's. That allows for a possible upgrade path for the current system by changing out the main board on the bottom. That is, the LCD's and driver boards (with cables), as well as the console housing could all be reused. I don't know how likely it is that one would upgrade, but, if I can keep that door open, I'd like to.
But it is interesting to ponder replacing the driver boards. Now if the microcontrollers that would replace them had, say, an additional 96,000 bytes of RAM at a minimum that could be used as a buffer for 800x480x2bpp, then it would be more tempting to consider them. The reason is that such would allow for placing text anywhere on the screen (to allow centering) and drawing boxes and other graphic elements.
I just feel that the current solution is pretty elegant as is: one Prop driving everything (at least on the main board). And it means only needing to program one controller. It's true that the driver boards are a fly in the ointment, but they're kind of a necessary evil. And with the P2, they would allow for tons of colors using just five pins per screen (assuming no sharing of the HS and VS lines among screens). I know that the P2 has 64 pins, but there still is a need to conserve pins, particularly if adding some kind of external memory chip. And driving four VGA screens eats up 20 pins right off the bat. That's not to say that I wouldn't consider replacing the driver boards with something else in combination with the P2, but there's a good chance that they will still be present (assuming some persistent display technology doesn't come out at a cheap price and make this discussion somewhat moot).
Anyway, it's still interesting to consider other designs that would work with the P1. Maybe I could still be persuaded. Never say never (except when saying "Never say never") is a good rule of thumb. If time and effort were going to be put into a new design, it might be good to look ahead at the P2 or at least to something that can do bit-mapped graphics (or display list stuff). That last sentence reminds me about the EVE line being used with the P1. No, it wouldn't save much money, if any, but it would add quite a bit of graphics flare for the added complexity, making it worth consideration. Then again, the focus of the console isn't on being able to, for example, bounce a hundred balls around on the screen or something like that. But the EVE line can do a lot with fonts and widgets that could be quite useful. But the P2 will be so powerful on its own that additional chips may not be warranted. Well, I can see advantages to having a font chip. That could be very useful. But I haven't done the math (nor do I understand the P2 well enough) to calculate if a font chip (flash chip of some kind) could be accessed fast enough for on-the-fly tiled characters. I presume so, particularly for a quad channel chip like you (jmg) have mentioned in the P2 forum, but I'm not sure. A font chip could store fonts at different sizes, maybe different styles, mono or proportional, and even things like Asian characters, not to mention graphical elements, all good stuff for text games.
Perhaps at this stage, I'd be better off focusing on game development and trying to promote the current console than going back for yet another round at the drawing board. But there's nothing wrong with looking ahead to what might be possible in the future with the P2 or other chips that are (coming) out. But if going the P2 route some day, there would be so much to consider. For example: Should a P2 be on the main board or on a module? Should an external memory chip be used? Should a font chip be used?
@Dave: You're right, of course. I think that there are dozens upon dozens of possibilities. A couple obvious ones are a sentence unscrambling game and a game where one fills in blanks in paragraphs, both of which I touched briefly on in some of the videos. But that's just a couple of obvious examples.
Here's another: Suppose an article was loaded off the SD card, such as a story, a conversation, an explanation and so on. Then maybe the first few words of the first sentence would be displayed to all players. Next, players would type the first character of whatever they thought the next word was, receiving several points when correct or a small penalty otherwise. That next word might be displayed with blanks to tell players how many letters it had to help players guess. Players would then progressively work their way through the article collaboratively but in competition to the end.
Or here's a somewhat similar idea that reminds me of the first electronic game I had, the SIMON game where you repeated the tones of a tone sequence by pushing four buttons (you could play alone or with others). Players would be presented an article (as above) to read through. Perhaps players could take turns even reading the articles aloud. Then the article would disappear and players would need to reconstruct the article by typing the first letter of each word, similar to the way that players had to reconstruct a tone sequence. For this particular game idea, it might actually be best to have players take turns, even though the console in general doesn't require players to take turns. But players would be given a limited time to type a letter (such as 5 seconds) to keep things moving. And play wouldn't end just because one made a mistake, but they just wouldn't get points for mistaken guesses. And maybe they could pass if they were afraid to guess, not sure.
I think that there's lots of good ideas for games for the console that haven't even been considered yet.
I wonder if some kind of adventure game on steroids, so to speak, is possible.
Also, I just checked, and I see that I can now get the driver boards for around $8 each (in low volumes), not including shipping, etc. But I figure that using the EFM8LB1 could cost around $2, maybe more, for the chips, support chips and the FFC connectors. So, I'd really only be saving $6 per screen, which amounts to $24 off the BOM, which is not insignificant but may not be enough to justify the change.. Plus that doesn't take into account the backlight circuitry.
Yes, that's why I've suggested the EFM8LB1 as either the cost down (when volumes justify) or if the present char/colour limits prove too limiting.
Another reason I'm inclined to stay with the driver boards is that they could work with a single P2 version using its DAC's. That allows for a possible upgrade path for the current system by changing out the main board on the bottom. That is, the LCD's and driver boards (with cables), as well as the console housing could all be reused. I don't know how likely it is that one would upgrade, but, if I can keep that door open, I'd like to.
... Well, I can see advantages to having a font chip. That could be very useful. But I haven't done the math (nor do I understand the P2 well enough) to calculate if a font chip (flash chip of some kind) could be accessed fast enough for on-the-fly tiled characters. I presume so, particularly for a quad channel chip like you (jmg) have mentioned in the P2 forum, but I'm not sure. A font chip could store fonts at different sizes, maybe different styles, mono or proportional, and even things like Asian characters, not to mention graphical elements, all good stuff for text games.
The external serial chips would need some form of buffering. They have an address preamble overhead that needs many clocks, and that's a high cost for a short strip of pixels.
A full screen soft font buffer, (no repeated fonts), would need 48k Bytes, so that's doable in a P2.
Is there any reason that the P1-based board couldn't be replaced by a P2-based board later on leaving everything else intact? I realize that maybe the driver boards wouldn't be required with the P2 but would they hurt?
I realize that maybe the driver boards wouldn't be required with the P2 but would they hurt?
That comes down to pins, and backlight drivers.
The drivers allow analog in, which could nicely use the P2 DACS, and the same loom design.
-or-, you could take 4 FFCs into one P2 board, and drive 4 screens skipping the drivers, but you still need to replace the backlights, and the pin-mapping gets tricky.
In theory, 11 bits per pixel could fit in the pins, but I think the P2 streamer is only binary-sized, giving 8 or 16 as the choices.
Assembling & handling something with 4 FFCs facing in 4 different directions is also a challenge.
Oops, sorry! I didn't read all of the above messages throughly enough. Sounds like a P2 replacement board down the line is possible. That means anyone who buys one of these now can have an upgrade path.
The external serial chips would need some form of buffering.
Ah, that makes sense. Well, as you say, things could be buffered. However, if no external SRAM/SDRAM chip were present AND the screen buffers used bitmaps instead of tile maps, then memory would be tight.
Assembling & handling something with 4 FFCs facing in 4 different directions is also a challenge.
That's a good point. I can't believe your insight into things! I have to focus a bit to connect an LCD's flex cable to a driver board on a wide-open table. It would be much, much harder inside the confined head of the console with little finger room. Might need tweezers or something to slip them in and pliers to close the locks. Or perhaps the main board could go into the head after the LCD's were connected to it, but that has issues, too. My older prototypes had a hole in the mainboard for cables (keyboards and power) to come up through from the stand below to make assembly easier. But a hole eats a lot of PCB real estate.
That means anyone who buys one of these now can have an upgrade path.
An upgrade path, you say. Cool! By the way, the check is in the mail.
Well, I suppose that the upgrade path might actually be that the buyer can make his/her own PCB to replace the P1 one that comes with the WordFire device. I guess there is no guarantee that you will offer an upgrade yourself. Of course, I don't think you've even decided for sure that you'll productize the P1 version have you? I've been thinking a bit more about this and wondering if the Propeller could be coupled with an ARM to run the game logic. The Propeller could handle all of the I/O. That would open up the possibility of significantly more complex game logic and not much more cost since there are very cheap ARM chips around. One problem though might be having Propeller pins available to communicate with the ARM.
It'd be great to offer an upgrade path if I could; that would make the most sense. The problem would be whether I would try to maintain support for the P1 console. My thinking in announcing the P1 console here is that people interested in developing games could at least get started with it. And later they could upgrade if an upgrade became available. But the P1-based console is plenty powerful on its own. Easily hundreds of game could be developed for it that would all fall comfortably within its memory confines.
As for productizing the current console, I hope to do so soon. I spent a lot of money on development recently, so I'm waiting for the project coffers to recover before pressing ahead with an order for screens and so on. Also, I wanted to gauge if any interest existed before ordering a bunch of parts that I might get stuck with. Again, I think this project would be better launched to a wider audience on a crowd-funding site, but I was hopeful that P1 enthusiasts would show interest first to get the ball rolling in terms of game development. And if the console did move to the P2, games could be ported over. For many word games, developing the content can take much longer than writing the game engine. But a lot of other games are also possible that don't involve generating content.
At one time, I thought about combining the Prop with a chip with a lot of RAM that had BASIC in FLASH (the name escapes me), but I found that I could do practically all of the main kinds of games that I'm most interested in with just the 32KB Prop. And I don't think anyone will ever need more than 640K in a desktop computer. Just kidding about that, but, seriously, the SPIN bytecodes are really efficient for packing in a lot of logic. Of course, graphics eat memory, as well as long text strings, but most of the text for the games developed so far comes off the SD card.
Having said that, as mentioned above I believe, I did do a two-Prop version, where one Prop handled game logic and the other handled the screens. That worked fine. The game logic Prop sent display commands to the second Prop over a single pin. There was a reverse channel (pin) for confirmations or whatever, but I never used it. But I prefer the one-Prop solution, as doing graphics is more direct and it's more elegant/less complicated. But if an ARM chip (such as in a Raspi) were used (or that chip that ran BASIC), it could be more worth doing (than using a second Prop) because those chips have more resources in terms of memory and language support to bring to bear. Anyway, I like programming games in SPIN, other than perhaps the limited built-in string handling.
Dave: Can the console be upgraded to the P2?
Jim: Why yes, Dave, I mean complete stranger to me. I'm glad you asked.
Dave: That's wonderful! You've really thought ahead.
Jim: Thanks, stranger. By the way, see me after the presentation; I have something for you.
Assembling & handling something with 4 FFCs facing in 4 different directions is also a challenge.
That's a good point. I can't believe your insight into things! ...
That's just my inbuilt laziness at work, I try to avoid tricky mechanicals or wiring, to the point where another MCU might be added to save some wires.
With the smallest MCUs now sub 30c, that's less than the cost of a single wire in a typical loom, and less than many detect/micro switches...
FYI : As an update to the EFM8LB1 approach, I did manage to improve the UART handling, as that 200k was sounding a bit low...
By reserve of a single palette index (eg 00H) as a repeat/keep code, one line of code can test that, and skip the 9 lines of palette update, and instead use those 9 lines to check/read a uart byte into a buffer, to be read during flyback times.
Peak rate is then 1 char/16 pixels of stable FG.BG info, so a say 50% FG.BG change rate, could support > 500kBytes/s or 5MBd.
The MCU is unlikely to be able to process at that 5MBd, but 200k baud is a much lower number.. - now means UART read is no longer a bottle neck & also lowers jitter impact (in case that matters)
This is a great invention and game; Fantastic job. I like the games, I can see this could get really fun with a small group or even solo. It would be cool to see a Boggle type game created. I imagine this could be used for learning a new language as well; has anyone adapted it to use another language?
That's just my inbuilt laziness at work, I try to avoid tricky mechanicals or wiring, to the point where another MCU might be added to save some wires.
Your breadth of expertise is mind boggling. First, I discovered that you had intimate knowledge of IC fabrication. But I figured that you wouldn't know applications that well. Then I came to know that you knew chip families, programming and even things like the particulars of LCD displays. What planet are you from? All I know is that you use British spellings. Anyway, your chip strategy makes sense, but that's partly because you have experience with so many kinds of microcontrollers. For a hobbyist like myself, there's a learning curve to overcome when adding a new chip. Another thing is that you appear to be used to working with huge volumes, where a lower BOM helps to get to an acceptable price point.
It will take some working code examples by Chip to fully flesh out what the streamer + LUT can, and cannot do, when connected to TFT LCD displays.
I figured, despite having rather terse "manual" describing the chip/instructions. Anyway, that means that it would likely be easier for mere mortals to stick to the DAC's rather than synchronize with the streamer to drive LCD pins directly, unless, of course, someone blazes a trail. Also, DAC's save pins. But never say never.
As an update to the EFM8LB1 approach, I did manage to improve the UART handling, as that 200k was sounding a bit low...
Are you coding in your head mostly, or have you tried something out on a real EFM8LB1? Perhaps for you theory and practice are the same thing.
Peak rate is then 1 char/16 pixels of stable FG.BG info, so a say 50% FG.BG change rate,
Yes, that sounds plenty fast for text. Does that "1 char/16 pixels" refer to just one scan line of a character? If so, then it would seem that the fg/bg colors could change for every character (and maybe even from scanline to scanline within a single character, not that that's needed). That's way more than is generally needed for text, as, for example, a word (such as five adjacent characters) would almost always be rendered in the same fg/bg colors. The exception might be a cursor. And there are some games (possibly not word games) where it would be nice to be able to regularly change the fg/bg color pairs of adjacent characters. Your skip code sounds like it really increased the throughput. Kind of reminds me of the skip codes that infrared remote control protocols use.
[That] now means UART read is no longer a bottle neck & also lowers jitter impact
Does that refer to potential "jitter" on the LCD screens similar to shimmying or to "jitter" with respect to updating the characters/colors in the buffer that might be noticeable to viewers? We definitely wouldn't want text to shimmy like it sometimes does on some composite displays.
As an update to the EFM8LB1 approach, I did manage to improve the UART handling, as that 200k was sounding a bit low...
Are you coding in your head mostly, or have you tried something out on a real EFM8LB1? Perhaps for you theory and practice are the same thing.
The buffer depth tests noted above were done on a real EFM8LB1, and given all the data waffle about FIFOs I was dissappointed to see they have only 1-deep RX side handling. (perhaps an errata is why ?)
The timing, I run in a simulator, which is an (appx) guide, and the inner loop is not large (of course) because it needs to be fast.
All fits on one editor screen Currently 69 bytes and 46/53/55 clocks for the 3 possible code forks - it needs to be under ~64+4? to fit inside the time to send 16b at SysCLK/4 SPI speed (18MHz).
Peak rate is then 1 char/16 pixels of stable FG.BG info, so a say 50% FG.BG change rate,
Yes, that sounds plenty fast for text. Does that "1 char/16 pixels" refer to just one scan line of a character? If so, then it would seem that the fg/bg colors could change for every character (and maybe even from scanline to scanline within a single character, not that that's needed). That's way more than is generally needed for text, as, for example, a word (such as five adjacent characters) would almost always be rendered in the same fg/bg colors. The exception might be a cursor. And there are some games (possibly not word games) where it would be nice to be able to regularly change the fg/bg color pairs of adjacent characters. Your skip code sounds like it really increased the throughput. Kind of reminds me of the skip codes that infrared remote control protocols use.[/quote]
As you say, it is more common to have whole words the same colour.
Yes, you can change colours on every single char, if you need to, but if you do that across the whole line (rare) you drop the possible extra RX check slots. There is still flyback time to check, so even that is not drop-dead.
[That] now means UART read is no longer a bottle neck & also lowers jitter impact
Does that refer to potential "jitter" on the LCD screens similar to shimmying or to "jitter" with respect to updating the characters/colors in the buffer that might be noticeable to viewers? We definitely wouldn't want text to shimmy like it sometimes does on some composite displays.
LCD screens have their own clock, so they should be immune to those RC type edge effects.
The jitter that is not spec'd on the LCD data, is from one clk to the next, but would only be an issue if the LCDs had a PLL on board, in their driver chips and I think they do not do that. Data I have found shows a simple long shift register.
I did trial an EFM8LB1 driving an Analog Monitor a while back, and the RC oscillator was not quite up to it. It all worked, and actually looked better on highest resolution monitors, but smaller monitors with lower resolution eg (800x480) have more coarse jumps, so you notice that more. (likely your 'shimmy').
That effect is the RC oscillator jitter 'beating' with the sync'd sampling clock. Needs an external oscillator for that.
Dave: Can the console be upgraded to the P2?
Jim: Why yes, Dave, I mean complete stranger to me. I'm glad you asked.
Dave: That's wonderful! You've really thought ahead.
Jim: Thanks, stranger. By the way, see me after the presentation; I have something for you.
@jmg: That's certainly well beyond theoretical, then. Theory is great, but the devil is often in the details. So the 1-deep RX instead of 3-deep wasn't a deal breaker, it seems. It's nice that you got things down to a tight loop. As for shimmer, it seems that things would be rock solid on a raw LCD panel as compared to the analog monitor you've tried in the past, even though it mostly worked.
@David: You perhaps have already surmised that I was trying to thank you for sort of setting me up to spike the ball, whether intentionally or not with your comments about there being an "upgrade path" that could make the current console even more attractive. I've appreciated your ideas/interest over the course of this thread.
No. I did a schematic for a prior version (my first and only schematic using DipTrace). But I haven't updated it yet. One can basically derive most of the schematic by checking the Docs section of the website about how the video screens and keyboards are wired and by looking at the PCB images. Let me know if you have questions about specific pins.
No. I did a schematic for a prior version (my first and only schematic using DipTrace). But I haven't updated it yet. One can basically derive most of the schematic by checking the Docs section of the website about how the video screens and keyboards are wired and by looking at the PCB images. Let me know if you have questions about specific pins.
You could publish a net-list style doc, that lists what each P1 pin connects to. That would help those looking to roll their own games ?
On the LCD side, I notice Mouser etc have some new displays
MOP-TFT800480-50A-BLM-TPN - this seems to need just a single 3v3 (200mA) with all other supplies derived on-panel ? - and 18.6V @ 40mA LED
There is also
EVE2-50A-BLM-TPN - that has the EVE2 included
Prices are maybe not low enough yet, but it does give a way to investigate EVE2 on a more easily managed panel ?
When I first saw this thread, I thought it might make a good foreign language training device. Maybe vocabulary tests. Or match the native word to the foreign meaning or vice versa.
@jmg: Yes, a net list is as informative as a schematic. I may release that later. Thanks for the LCD links. I'm always interested in new developments in the display industry. The offerings are expensive, prohibitively so in my case, but as you say, prices could decline. Based on the first link, even prices for QTY 200 are currently much more expensive than what I pay for an LCD+driver-board combination in QTY 1. And even with QTY 200 pricing, that would add around $50 to the cost of the console, which is already up there. But it's nice that some displays generate their own voltages. If memory serves correctly, the one that I use needs four different voltages. I recall coming across an IC chip that can generate such multiple voltages, but I've never used it (of course, it needs some passives).
@DaveJenson: Thanks for your feedback. it likely could be used for foreign language learning, particularly if it were used in a language lab where more than one user could use it at a time (otherwise, a tablet or smart phone or PC could suffice). As it stands now, the game console uses the built-in Propeller font, so it's basically limited to whatever languages can be written in that font, at least without resorting to tricks. And the games that have been written so far are really for native English speakers. For example, Things People Say - Level 3 is really aimed at native speakers that are teenagers or adults. However, I'd like to make a Level 0 or 1 version that might be useful for non-native speakers of English and also for young native speakers. It's fun to create content, but it does take a lot of time.
@David: I've ordered things mainly through suppliers in China, surprise, surprise. Since you asked about my sourcing, the specific website that I've used the most is Taobao. Suppliers on there tend to come and go, but it can be a good source. As you might expect, communication can sometimes be a problem, but many vendors in China are willing to use some English. Having said that, the site caters mainly to people in China (as will be abundantly clear when visitors are confronted with a Chinese interface), but it can be used by people abroad (Google Translate's rough translations sometimes come in handy). For folks outside China, it's necessary to set up a way of paying. Generally, that means working through a "middleman" that handles the final payment in China for a modest fee. I don't have any specific recommendations about the best way to pay (things periodically change), but there are videos on YouTube that explain various ways one can set that up. Things on Taobao are often in a state of flux, as their policies and website have changed several times over the years, but I think things are generally improving and overall I'm impressed with the site. Of course, there are thousands of vendors on there, just like on EBAY, so Taobao can't really vet them all. It's easy for sketchy vendors to set up business credentials in China and there were some cases of fraudsters on Taobao in the news a few years back that prompted Taobao to crack down. Personally, I've never been the victim of fraud on Taobao. I have received some products that didn't work (which I didn't contest), and I've received something different than what I ordered even after chatting with the vendor to try to specifically prevent that from happening, but I've ALWAYS received my orders, and timely so. However, someone in the States could probably save some time and brain cells for a small order by sticking with EBAY or similar, even though prices are sometimes higher. By the way, I'm sorry that it seems like my console costs "an arm and a leg." I've really worked hard to get the costs down and thought that I had gotten the cost down to "just" a leg, ha-ha. But apparently I still have a ways to go, and like we've discussed by PM, I'm thinking about what I could do to reduce costs further, such as by leaving all of the assembly to the end-user. Still, there's far more time and effort that goes into getting a product out the door than what is immediately apparent.
@David: I've ordered things mainly through suppliers in China, surprise, surprise. Since you asked about my sourcing, the specific website that I've used the most is Taobao. Suppliers on there tend to come and go, but it can be a good source. As you might expect, communication can sometimes be a problem, but many vendors in China are willing to use some English. Having said that, the site caters mainly to people in China (as will be abundantly clear when visitors are confronted with a Chinese interface), but it can be used by people abroad (Google Translate's rough translations sometimes come in handy). For folks outside China, it's necessary to set up a way of paying. Generally, that means working through a "middleman" that handles the final payment in China for a modest fee. I don't have any specific recommendations about the best way to pay (things periodically change), but there are videos on YouTube that explain various ways one can set that up. Things on Taobao are often in a state of flux, as their policies and website have changed several times over the years, but I think things are generally improving and overall I'm impressed with the site. Of course, there are thousands of vendors on there, just like on EBAY, so Taobao can't really vet them all. It's easy for sketchy vendors to set up business credentials in China and there were some cases of fraudsters on Taobao in the news a few years back that prompted Taobao to crack down. Personally, I've never been the victim of fraud on Taobao. I have received some products that didn't work (which I didn't contest), and I've received something different than what I ordered even after chatting with the vendor to try to specifically prevent that from happening, but I've ALWAYS received my orders, and timely so. However, someone in the States could probably save some time and brain cells for a small order by sticking with EBAY or similar, even though prices are sometimes higher. By the way, I'm sorry that it seems like my console costs "an arm and a leg." I've really worked hard to get the costs down and thought that I had gotten the cost down to "just" a leg, ha-ha. But apparently I still have a ways to go, and like we've discussed by PM, I'm thinking about what I could do to reduce costs further, such as by leaving all of the assembly to the end-user. Still, there's far more time and effort that goes into getting a product out the door than what is immediately apparent.
Thanks for the detailed info. Maybe I'll wait for you to get your units ready for production. Sounds like it's easier to do all of this from Taiwan!
Just out of curiosity, how many of these things have you made so far? You show ten of them in pictures on your website. Are those all functioning units?
Comments
Sorry, I temporarily lost sight of the replacing the RTD2660 angle.
Yeah, the P2 could be a nice replacement for the P1 in my application with a lot more overall power, especially graphically. And the DAC's would eliminate the resistor DAC's I currently use (even though I just use one resistor per channel), opening up a spectrum of colors.
I've asked myself about the idea of one P2 cog being able to handle four screens before, freeing up three cogs. The main thing that limited the P1 was getting data from the HUB, but things should move much faster on the P2 (and things would scream if things can be kept in step with the streamer).
But what I'm unsure of is the internal connection of the DACs. While there are 64 smart pins, there's only 8 sets of DAC's. In a prior design of the P2, I think one could choose which DAC set to connect with, and that allowed for one cog to potentially connect with more than one DAC (though probably not in the same instruction). But looking at a diagram for the latest architecture, I'm not sure that such is still the case. It looks like a cog is limited to one DAC. And there's no inter-cog communication channels, so I'm not sure how one would break out of that. But maybe I'm wrong about all that, as I may be reading in too much to the system architecture diagrams I've seen. Maybe things didn't change after all. I must confess that, in order to make progress with my project, I've taken to doing some skim reading of that P2 forum over the last year or so.
The EFM8LB1 seems interesting from a cursory look at this datasheet. It might be over my head, though, even with an extended look. And it's another thing to program. Yikes! I wonder if those DAC's can operate at video speeds. And I'm not sure how to get data to them, and it seems like the chip count is getting up there with the MUX's. Also, offhand, I'm not seeing how that simplifies cabling. If you say it does, it does, but the light hasn't turned on for me. All I know is that I eventually have to connect to 50-pin flex cables with the present LCD's. And are you talking about the EFM8LB1 in connection with the P1 or the P2? If I moved the project to the P2, I likely wouldn't want to limit things to "just" text displays.
As for baud rates, if using the P1 (and maybe even the P2), I think full screen refresh rates of around a tenth of a second (100ms) are acceptable, perhaps even a bit slower. I like for the screens to basically change in a blink of an eye from screen to screen, but I don't need video rates. As for planes, I currently don't use any sprites or cursors, but if something could be overlaid, so much the better. With a P2, ideally, it would be nice to support popup windows that could truly overlay the background without blanking stuff out around the edges, but I figured that would be more doable with off-chip memory. With the P1, I can certainly get by without that.
If moving to the P2, character-based displays are simpler and one could buffer many different screens; however, using 2 bpp bitmapped displays would allow maximum flexibility for centering text horizontally and vertically and for simple boxes without having to resort to tricks with a tile-map setup. But that may be looking ahead way too far at this point. It's fun to think about, though.
Maybe I can check out that sound chip later. I realize that people say that the TDA7052A is "long in the tooth," but it seems to get the job done for my current purposes. But I've just used it for simple beeps or buzzes. And I haven't thrown a sound cog of some kind at it.
Thanks for your comments. While I wasn't able to keep up with all your ideas this time, such as for the cabling, I do appreciate them. BTW, I'll be offline for 10 hours or so.
So, not enough for video, but good enough for low-distortion Sine/triangle wave function generator.
Data from P1 to the 4 x EFM8LB1 would be via 4 separate serial links. (200k+baud)
The MUX's are quite cheap, ~ 15c, and easy to handle, and they allow a decent 8bpp.
The EFM8LB1 pairs better with the P1, as it can manage 16x32 font and do a full 50x15 chars with a 8bpp palette, but not much more.
It's easiest to use what you already have that works, but if you found you needed to bump chars from 40 to 50, or more colours, or cannot get RTD2660, or hit enough volumes you are motivated to cost-down a bit, the EFM8LB1 may be viable.
Once you dropped in a P2 master, the EFM8LB1 is not keeping up with what a P2 could manage, so there I think P2's on video are better... which brings us to :
The cabling comments relate to P2's as RGB drivers, not so much to EFM8LB1 as being simpler. EFM8LB1 has a uart link, which is slightly fewer wires than HV(RBGx4).
With P2, that has enough horsepower to drive all 4 x 50 pin connectors, to some useful bpp, but how to design a PCB that easily accepts 4 cables ?
I guess a quite large PCB with a connector on each edge might work, tho it's nice to secure that connection during assembly and transit ?
Not sure about 1 P2 COG driving 4 displays, I may have been unclear above, I was meaning 1 COG per display, ie as you do now. I'd do the 1/COG first, then see if 2/ or 4/ was comfortable.
Whether the whole shebang (P1 and 4 display drivers ) could swallow into just 1 P2 likely depends on the Pin budget, and the bpp you want. ~11 bpp (x4) would equate to P1 pins.
On frame rates for SW RGB : I did find an other forum comment that claimed 1MHz min on LCD, but I'm not sure how believable that is. That's ~10Hz frame on the smaller TFT display they were talking about.
I found a couple of 480x272 data sheets that mentioned 5MHz min, 9MHz typ, which maps to a min frame rate of ~ 25Hz, sounds more plausible.
It may be that the lower limit is more related to human eye effects, as movies are projected at 24 fps, so it's likely best to try to keep above that.
On that basis, the ~42Hz an EFM8LB1 can get, is sounding like it could be ok.
So, looking at the EFM8LB1's datasheet, I'm seeing a lot of FLASH but not much RAM. Thus your idea would use the FLASH to store a character set (font) similar to the one that's built in to the Prop. For example, 256 16x32-bit (64 byte) characters would take up 16KB (and the EFM8LB1 datasheet says it has up to 64KB).
Then I guess you're proposing using much of the 4+ KB of RAM in the EFM8LB1 to buffer one or two screens worth of characters. A 40 char x 15 line screen at 2 bytes/char (1 for ASCII and 1 for a fg/bg color pair) would need 1200 bytes, and a screen with 50-character lines would need 1500 bytes. Perhaps two screens be stored or a screen with two planes.
And apparently your suggesting using part of the EFM8LB1's up to 29 I/O pins to directly drive the LCD, no DAC's required. And even if it had video DAC's, we'd be back to needing driver boards, wouldn't we. Sorry for the confusion on my part with my own project. It's sounds a bit similar to using 5 Props, except that the EFM8LB1's are, say, one-fifth the cost and they don't need EEPROM's or external crystals. The solution might also use less power. Am I getting things right, or have I walked from one cloud into another?
For the current console form-factor, such a solution would work best by putting the main PCB back in the head (including the SD card socket). That's how my older prototypes worked. The PCB size was 15x15 cm, with some room to spare around the edges. I think the space occuppied by the 12-pin and 4-pin PH 2.0 connectors that were (and still are) used to connect up with the driver boards would be enough for the flex connectors for the screens. But I'm not sure about the rest of the chips. I guess the Prop might have to switch to the QFP package for that to work (and maybe things could be an all SMD one-sided design).
Of course, there would still be the matter of driving the backlights of the LCD panels.
As for a single P2 solution, using four cogs to drive four VGA driver boards seems attractive. Firstly, I don't think that one cog can connect with more than one DAC. And secondly, using a whole cog potentially allows for more graphical effects than trying to drive multiple displays with one cog. So, my apologies for driving us down that road.
Then one could use a five-P2 solution, but that would be as expensive as using VGA driver boards and wouldn't take advantage of the DAC's. And a single P2 would not pair well with four EFM8LB1's because it would unnecessarily limit things to text.
As for the frame rates of LCD's, I recall that Rayman has driven them at rates well below standard video rates. I forget the exact numbers, but perhaps something like 15 fps or lower. It almost for sure depends on the panel and the size may be a factor. Also, I don't know if doing so long term can cause any damage. Hopefully, its still fast enough to keep the liquid crysals happy (not degrade them). But I guess something like that would have to be tested for many hours (days?) with a specific setup (the EFM8LB1) and panel (like the AT070TN90). Alternately, perhaps relevant research is already available.
Yup, pretty much nailed it
There are some minor variants possible around the details of fg/bg, but the rest is 100%.
With the simplest 1-byte fg/bg, as you listed above, that gives 4bits each, and needs a single So16 mux, ... but is only 16 colours.
It a minor speed penalty to have that fg.bg byte instead index a palette, which has a pair of bytes for 8b fg and 8b bg, (512 added total) and uses 2 ports on the LB1 and now 2 MUX's, but bumps to 256 colours.
I've confirmed the SPI port has 3 byte deep buffering (1 x shifter + 2 fifos), so that helps simplify code. (16 w font can simply load 2 bytes, no polling )
The uart looks to have 2 bytes deep buffer in TX, but RX side is not co-operating, and looks to be single buffered. Data is rather conflicted there, as it suffers from cut/paste-itis - maybe I've missed some RX-fifo enable bit somewhere **
I've confirmed the EFM8UB3 has a 5 deep UART buffer, (1 buffer+4 FIFO) on TX side - that's a 48MHz core, 40k Flash, 2048 XRAM.
** Addit: I changed LB1 code from a read_buf to a poll TI,RI, and that can only accept 2 bytes sent, if phased just before the 2nd byte mid-stop bit. ie it is just single buffered Rx, but can queue 2 on Tx.
Interesting. I'd expect mainly flicker type effects to keep designs away from lower speeds.
As for using the EFM8LB1 or one of its relatives to replace the VGA driver boards, if I had to decide right now, I'd probably say that I fear that it would add more complexity than it's worth. It does add tons of colors, but I feel I'm getting by pretty well with the eight that I have, which, again, allows for dozens of fg/bg pairs. Sure, all things being equal, the more colors the better. But they come at a price of complicating the main board that I'd have to manufacture and test.
Also, I just checked, and I see that I can now get the driver boards for around $8 each (in low volumes), not including shipping, etc. But I figure that using the EFM8LB1 could cost around $2, maybe more, for the chips, support chips and the FFC connectors. So, I'd really only be saving $6 per screen, which amounts to $24 off the BOM, which is not insignificant but may not be enough to justify the change.. Plus that doesn't take into account the backlight circuitry.
Another reason I'm inclined to stay with the driver boards is that they could work with a single P2 version using its DAC's. That allows for a possible upgrade path for the current system by changing out the main board on the bottom. That is, the LCD's and driver boards (with cables), as well as the console housing could all be reused. I don't know how likely it is that one would upgrade, but, if I can keep that door open, I'd like to.
But it is interesting to ponder replacing the driver boards. Now if the microcontrollers that would replace them had, say, an additional 96,000 bytes of RAM at a minimum that could be used as a buffer for 800x480x2bpp, then it would be more tempting to consider them. The reason is that such would allow for placing text anywhere on the screen (to allow centering) and drawing boxes and other graphic elements.
I just feel that the current solution is pretty elegant as is: one Prop driving everything (at least on the main board). And it means only needing to program one controller. It's true that the driver boards are a fly in the ointment, but they're kind of a necessary evil. And with the P2, they would allow for tons of colors using just five pins per screen (assuming no sharing of the HS and VS lines among screens). I know that the P2 has 64 pins, but there still is a need to conserve pins, particularly if adding some kind of external memory chip. And driving four VGA screens eats up 20 pins right off the bat. That's not to say that I wouldn't consider replacing the driver boards with something else in combination with the P2, but there's a good chance that they will still be present (assuming some persistent display technology doesn't come out at a cheap price and make this discussion somewhat moot).
Anyway, it's still interesting to consider other designs that would work with the P1. Maybe I could still be persuaded. Never say never (except when saying "Never say never") is a good rule of thumb. If time and effort were going to be put into a new design, it might be good to look ahead at the P2 or at least to something that can do bit-mapped graphics (or display list stuff). That last sentence reminds me about the EVE line being used with the P1. No, it wouldn't save much money, if any, but it would add quite a bit of graphics flare for the added complexity, making it worth consideration. Then again, the focus of the console isn't on being able to, for example, bounce a hundred balls around on the screen or something like that. But the EVE line can do a lot with fonts and widgets that could be quite useful. But the P2 will be so powerful on its own that additional chips may not be warranted. Well, I can see advantages to having a font chip. That could be very useful. But I haven't done the math (nor do I understand the P2 well enough) to calculate if a font chip (flash chip of some kind) could be accessed fast enough for on-the-fly tiled characters. I presume so, particularly for a quad channel chip like you (jmg) have mentioned in the P2 forum, but I'm not sure. A font chip could store fonts at different sizes, maybe different styles, mono or proportional, and even things like Asian characters, not to mention graphical elements, all good stuff for text games.
Perhaps at this stage, I'd be better off focusing on game development and trying to promote the current console than going back for yet another round at the drawing board. But there's nothing wrong with looking ahead to what might be possible in the future with the P2 or other chips that are (coming) out. But if going the P2 route some day, there would be so much to consider. For example: Should a P2 be on the main board or on a module? Should an external memory chip be used? Should a font chip be used?
Here's another: Suppose an article was loaded off the SD card, such as a story, a conversation, an explanation and so on. Then maybe the first few words of the first sentence would be displayed to all players. Next, players would type the first character of whatever they thought the next word was, receiving several points when correct or a small penalty otherwise. That next word might be displayed with blanks to tell players how many letters it had to help players guess. Players would then progressively work their way through the article collaboratively but in competition to the end.
Or here's a somewhat similar idea that reminds me of the first electronic game I had, the SIMON game where you repeated the tones of a tone sequence by pushing four buttons (you could play alone or with others). Players would be presented an article (as above) to read through. Perhaps players could take turns even reading the articles aloud. Then the article would disappear and players would need to reconstruct the article by typing the first letter of each word, similar to the way that players had to reconstruct a tone sequence. For this particular game idea, it might actually be best to have players take turns, even though the console in general doesn't require players to take turns. But players would be given a limited time to type a letter (such as 5 seconds) to keep things moving. And play wouldn't end just because one made a mistake, but they just wouldn't get points for mistaken guesses. And maybe they could pass if they were afraid to guess, not sure.
I think that there's lots of good ideas for games for the console that haven't even been considered yet.
I wonder if some kind of adventure game on steroids, so to speak, is possible.
Yes, that's why I've suggested the EFM8LB1 as either the cost down (when volumes justify) or if the present char/colour limits prove too limiting.
Fingers crossed the P2 works first time
The external serial chips would need some form of buffering. They have an address preamble overhead that needs many clocks, and that's a high cost for a short strip of pixels.
A full screen soft font buffer, (no repeated fonts), would need 48k Bytes, so that's doable in a P2.
No, & exactly that was mentioned above.
That comes down to pins, and backlight drivers.
The drivers allow analog in, which could nicely use the P2 DACS, and the same loom design.
-or-, you could take 4 FFCs into one P2 board, and drive 4 screens skipping the drivers, but you still need to replace the backlights, and the pin-mapping gets tricky.
In theory, 11 bits per pixel could fit in the pins, but I think the P2 streamer is only binary-sized, giving 8 or 16 as the choices.
Assembling & handling something with 4 FFCs facing in 4 different directions is also a challenge.
Ah, that makes sense. Well, as you say, things could be buffered. However, if no external SRAM/SDRAM chip were present AND the screen buffers used bitmaps instead of tile maps, then memory would be tight.
Powers of two, huh? Good to know.
That's a good point. I can't believe your insight into things! I have to focus a bit to connect an LCD's flex cable to a driver board on a wide-open table. It would be much, much harder inside the confined head of the console with little finger room. Might need tweezers or something to slip them in and pliers to close the locks. Or perhaps the main board could go into the head after the LCD's were connected to it, but that has issues, too. My older prototypes had a hole in the mainboard for cables (keyboards and power) to come up through from the stand below to make assembly easier. But a hole eats a lot of PCB real estate.
As for productizing the current console, I hope to do so soon. I spent a lot of money on development recently, so I'm waiting for the project coffers to recover before pressing ahead with an order for screens and so on. Also, I wanted to gauge if any interest existed before ordering a bunch of parts that I might get stuck with. Again, I think this project would be better launched to a wider audience on a crowd-funding site, but I was hopeful that P1 enthusiasts would show interest first to get the ball rolling in terms of game development. And if the console did move to the P2, games could be ported over. For many word games, developing the content can take much longer than writing the game engine. But a lot of other games are also possible that don't involve generating content.
At one time, I thought about combining the Prop with a chip with a lot of RAM that had BASIC in FLASH (the name escapes me), but I found that I could do practically all of the main kinds of games that I'm most interested in with just the 32KB Prop. And I don't think anyone will ever need more than 640K in a desktop computer. Just kidding about that, but, seriously, the SPIN bytecodes are really efficient for packing in a lot of logic. Of course, graphics eat memory, as well as long text strings, but most of the text for the games developed so far comes off the SD card.
Having said that, as mentioned above I believe, I did do a two-Prop version, where one Prop handled game logic and the other handled the screens. That worked fine. The game logic Prop sent display commands to the second Prop over a single pin. There was a reverse channel (pin) for confirmations or whatever, but I never used it. But I prefer the one-Prop solution, as doing graphics is more direct and it's more elegant/less complicated. But if an ARM chip (such as in a Raspi) were used (or that chip that ran BASIC), it could be more worth doing (than using a second Prop) because those chips have more resources in terms of memory and language support to bring to bear. Anyway, I like programming games in SPIN, other than perhaps the limited built-in string handling.
Jim: Why yes, Dave, I mean complete stranger to me. I'm glad you asked.
Dave: That's wonderful! You've really thought ahead.
Jim: Thanks, stranger. By the way, see me after the presentation; I have something for you.
That's just my inbuilt laziness at work,
With the smallest MCUs now sub 30c, that's less than the cost of a single wire in a typical loom, and less than many detect/micro switches...
FYI : As an update to the EFM8LB1 approach, I did manage to improve the UART handling, as that 200k was sounding a bit low...
By reserve of a single palette index (eg 00H) as a repeat/keep code, one line of code can test that, and skip the 9 lines of palette update, and instead use those 9 lines to check/read a uart byte into a buffer, to be read during flyback times.
Peak rate is then 1 char/16 pixels of stable FG.BG info, so a say 50% FG.BG change rate, could support > 500kBytes/s or 5MBd.
The MCU is unlikely to be able to process at that 5MBd, but 200k baud is a much lower number.. - now means UART read is no longer a bottle neck & also lowers jitter impact (in case that matters)
I figured, despite having rather terse "manual" describing the chip/instructions. Anyway, that means that it would likely be easier for mere mortals to stick to the DAC's rather than synchronize with the streamer to drive LCD pins directly, unless, of course, someone blazes a trail. Also, DAC's save pins. But never say never.
Are you coding in your head mostly, or have you tried something out on a real EFM8LB1? Perhaps for you theory and practice are the same thing.
Yes, that sounds plenty fast for text. Does that "1 char/16 pixels" refer to just one scan line of a character? If so, then it would seem that the fg/bg colors could change for every character (and maybe even from scanline to scanline within a single character, not that that's needed). That's way more than is generally needed for text, as, for example, a word (such as five adjacent characters) would almost always be rendered in the same fg/bg colors. The exception might be a cursor. And there are some games (possibly not word games) where it would be nice to be able to regularly change the fg/bg color pairs of adjacent characters. Your skip code sounds like it really increased the throughput. Kind of reminds me of the skip codes that infrared remote control protocols use.
Does that refer to potential "jitter" on the LCD screens similar to shimmying or to "jitter" with respect to updating the characters/colors in the buffer that might be noticeable to viewers? We definitely wouldn't want text to shimmy like it sometimes does on some composite displays.
The timing, I run in a simulator, which is an (appx) guide, and the inner loop is not large (of course) because it needs to be fast.
All fits on one editor screen
Yes, that sounds plenty fast for text. Does that "1 char/16 pixels" refer to just one scan line of a character? If so, then it would seem that the fg/bg colors could change for every character (and maybe even from scanline to scanline within a single character, not that that's needed). That's way more than is generally needed for text, as, for example, a word (such as five adjacent characters) would almost always be rendered in the same fg/bg colors. The exception might be a cursor. And there are some games (possibly not word games) where it would be nice to be able to regularly change the fg/bg color pairs of adjacent characters. Your skip code sounds like it really increased the throughput. Kind of reminds me of the skip codes that infrared remote control protocols use.[/quote]
As you say, it is more common to have whole words the same colour.
Yes, you can change colours on every single char, if you need to, but if you do that across the whole line (rare) you drop the possible extra RX check slots. There is still flyback time to check, so even that is not drop-dead.
LCD screens have their own clock, so they should be immune to those RC type edge effects.
The jitter that is not spec'd on the LCD data, is from one clk to the next, but would only be an issue if the LCDs had a PLL on board, in their driver chips and I think they do not do that. Data I have found shows a simple long shift register.
I did trial an EFM8LB1 driving an Analog Monitor a while back, and the RC oscillator was not quite up to it. It all worked, and actually looked better on highest resolution monitors, but smaller monitors with lower resolution eg (800x480) have more coarse jumps, so you notice that more. (likely your 'shimmy').
That effect is the RC oscillator jitter 'beating' with the sync'd sampling clock. Needs an external oscillator for that.
@David: You perhaps have already surmised that I was trying to thank you for sort of setting me up to spike the ball, whether intentionally or not with your comments about there being an "upgrade path" that could make the current console even more attractive. I've appreciated your ideas/interest over the course of this thread.
You could publish a net-list style doc, that lists what each P1 pin connects to. That would help those looking to roll their own games ?
On the LCD side, I notice Mouser etc have some new displays
MOP-TFT800480-50A-BLM-TPN - this seems to need just a single 3v3 (200mA) with all other supplies derived on-panel ? - and 18.6V @ 40mA LED
There is also
EVE2-50A-BLM-TPN - that has the EVE2 included
Prices are maybe not low enough yet, but it does give a way to investigate EVE2 on a more easily managed panel ?
@DaveJenson: Thanks for your feedback. it likely could be used for foreign language learning, particularly if it were used in a language lab where more than one user could use it at a time (otherwise, a tablet or smart phone or PC could suffice). As it stands now, the game console uses the built-in Propeller font, so it's basically limited to whatever languages can be written in that font, at least without resorting to tricks. And the games that have been written so far are really for native English speakers. For example, Things People Say - Level 3 is really aimed at native speakers that are teenagers or adults. However, I'd like to make a Level 0 or 1 version that might be useful for non-native speakers of English and also for young native speakers. It's fun to create content, but it does take a lot of time.
Just out of curiosity, how many of these things have you made so far? You show ten of them in pictures on your website. Are those all functioning units?