Wow! That's good detective work on your part on at least two fronts. And you've also made progress on extending the console's functionality. I figured that you were "running silent" for a reason.
I wasn't even aware that I was using an older version of Kye's SD card code. Although I've never gotten around to writing any files to the console's SD card, I have noticed that Windows sometimes reports a problem with an SD card that's been used by the console, but it then says that no errors were found when it does its scan. I don't think that I've seen Windows report any actual corruption or repair anything, which seems consistent with what you've reported. Prior to your post, my guess (mere speculation) was that the SD card wasn't being shut down properly by the console, or something along those lines. Frankly speaking, I've had so many other aspects of the console to work on (electronics, game creation, the formfactor, fabrication, etc.) that I didn't investigate it, and, in fact, I probably wouldn't have known how to look into it if I had tried. So I really appreciate your efforts in that regard.
So, based on your post, I think you're saying that the problem results from the modified date field on the card being empty. I had no idea. I wonder how you figured that out. Did you use some diagnostic tool to look at the SD card or just regular reporting from your PC's OS? Whatever the case, that's very good investigative work on your part. Thanks for doing that and informing us.
By the way, one of the reasons for the latest version of the console was that I wanted to stop sharing the SD card lines with pins being used for other things. I figured that such sharing was asking for trouble. But it took some video driver modification work by kuroneko to free up some pins (by sharing the HV sync lines). Now, all four pins used by the SD card are dedicated to SD card usage. So that may make it easier to track down any problems.
I've also never used the console to create or delete any files or directories, creating them on the PC instead, as you said. Does the newest version of Kye's driver also fix that problem (like it did for the date problem)? If it doesn't, the problem can be worked around, like you said. For example, HighScrs.txt or SaveGame.txt files could be created in advance, even if they weren't used.
Sounds like a new version of the SD card driver is needed for the console. I haven't really looked at the SD card driver for at least a couple years. But I do recall that I pruned out some of the unneeded functionality, just like you mentioned, in order to make more room available for other code. Some programs may need all the space they can get. For example, the GameMenu program only leaves 123 longs for the stack (since it loads all the game names and descriptions into HUB memory for fast access). I haven't used any stack measuring object or other techniques to see how much stack space is needed, but I imagine that 123 longs is close to pushing things to the breaking point.
Meanwhile, your work on paging in screens opens up new possibilities. Instruction screens--well, really anything with a lot of text--eats up precious memory. So loading them in from SD makes sense where such instructions are lengthy. Beyond that, the ability to load in "tiles" for larger screen maps make possible more complex games, especially those involving worlds to pan around in or whatever. While I've confined myself to straight text games, I can see how that functionality would come in handy. You've really pressed the pedal to the metal. I'd tell you to keep up the good work, but then I'd feel guilty about encouraging you to do stuff that I probably should have done. Ah, heck with it: keep up the good work!
And don't mind those squirrels. It's often the case that getting distracted by a squirrel leads to something good (if one doesn't get hit by a car chasing the squirrel).
As I've mentioned to a couple of members via PM, I'm working on a new version of the game console. From the electrical and programming standpoints, it will work the same as the existing console. But it will have a new formfactor. Currently, a new PCB design is underway to accommodate that new formfactor. Barring any unforeseen circumstances, I hope to have a working prototype in a couple of weeks. This new version has been keeping me busy recently, but I hope to get back to designing games once the new console is ready.
The reasons for the new console version are that I want to: [1] make the console smaller/lighter to the reduce shipping cost, and [2] make the console less complex to build to lower the fabrication cost (and effort required). The existing console is too big and complex to continue offering at the $250 price point plus shipping. As you might guess, to accomplish the foregoing goals, something had to give. In particular, the snack bowl has been phased out, which a couple of you mentioned that you could live without. But what the new console sacrifices in functionality (namely, snacking convenience), it makes up for in cuteness, I feel.
I'm considering also offering a two-screen, two-keyboard version with blanks standing in for two of the screens in the console itself. Such a two-screen version could be sold for around $50 less than the four-screen version, getting people in at a lower price point. Some people mostly want to play games with one other player, anyway, so a two-screen version fits that bill. Moreover, the two-screen version could potentially be upgraded to the four-screen version (via an upgrade kit) with some assembly effort. Although I had a design for a dedicated two-screen version, I think it's better to go with a version that's upgradeable in light of the fact that the new formfactor will be smaller and cheaper anyway (but I could change my mind on that).
Anyway, that's what I'm working on at present. Once I make good progress, I'll try to provide an update.
I haven't taken any pics yet, David. I probably won't until there are working electronic guts inside. If I were to take some pics now, I'd probably sit on them until everything is ready. I mostly posted my previous update just to let folks know that I'm still working on the console and still think that it has potential. But you can probably envision the new console as a "junior" version of the existing console (after all, it still has four screens, which limits how much one can change the design). Remember the IBM PC Jr.? Think of the new console like that, only I hope it will be much better received than the Jr. Again, it'll utilize the same electrical design of the current console, only redone due to the overall size reduction. Moreover, the new version uses the same 7-inch screens as the old one. I did build a prototype once with somewhat smaller screens, but those screens aren't as popular, so they're harder to source and more expensive. I like the size of the screens in the existing console, so I'm keeping them. I think that they are fairly ideal when using the console seated around a table (with players a foot or two away from them). While there are bigger screens available, they cost more, use more power and would make the console too large. So, the 7-inch screens are kind of in the Goldilocks zone (not too big, not too small = juuuust right). I did toy with using them in VGA mode (640x480) instead of the stretched WVGA mode (800x480) to facilitate wider bezels (kind of opposite of the narrow/zero bezel cell phone trend), but I decided against that (as that would make the effective screen area quite a bit smaller). Anyway, that should give you an idea of the direction I'm headed.
Thanks! I'm glad you feel that way. And after all, you are one of the few, the proud, the Wordfirers...who has a console to view in person upfront and personal. 7-inch screens it is then.
You will. Or at least I think that you will. On the other hand, it sounds like you've expanded the scope well beyond the initial scope, so it won't be easy. Hopefully, you haven't bitten off more than you can chew. If I had to bet, I'd bet on you. It seems like you're making progress on multiple fronts, not that it's easy to fight a multi-front war. Good luck and don't lose sight of the forest for the trees (unless you elect to reduce the scope to that of a few trees (such as just handling adventure games, which would still be cool in its own right)).
Actually, it is my game system that is slowing me down now not other stuff. I think I spent half an hour adding the ability to flash LEDs on the Propeller. What I'm really having trouble with is trying to keep the language simple but allowing the use of nested arrays. That is needed for the vocabulary statements that were in the old adventure writing system. The old system did it by have specialized C code to implement the parser but I want this new version to have the parser implemented in the adventure language itself. This is more than just an idealistic goal since there isn't enough memory on the Propeller for the C parser.
Reminds me a bit of a compiler being able to compile itself, which seems a lot like a human trying to contemplate the brain or the nature of consciousness.
I am absolutely against VGA resolution, it is perfect with 40X15
For your new design I would ask for tilted or even tilt-able displays, currently the screens are to low and you constantly have to 'duck' to read the screens. Or put the console on a phonebook.
All 4 of my screens have a visible defect in form of a H in the upper right quadrant and the bezels are slightly to big and overlapping the display. On the other hand the screens have a very stable and colorful picture, nice video driver.
I am pushing along fine on the Map Editor, this 4 screen concept is absolutely cool. So currently 4 people can work simultaneously on a 400 X 150 Map. (10X10 Screens) A little crude and beta beta, but usable.
Hi, Mike. As for the screen "defect," I intentionally left the protective screen films on the screens to [1] help protect them from scratches, and [2] let people know that they are new. If you remove those films, the H's will go away. Those films easily peel off from little tabs in the upper-right corners of the four screens. However, if you can't access the tab, you'll need to take off the colorful bezel cap (it slides on and off but don't force it when putting it back on). In my usage, I peel off the films because they slightly reduce brightness and/or clarity. But one could choose to leave them on. Then one can be like a person from my grandmother's generation (sorry for the stereotype) who keeps the sofa covered for years to prevent damage even if the cover is kind of hideous and hides the colorful fabric.
As for the bezels slightly overlapping the screens, that was by design. Maybe it was a poor design choice, but it was intentional. It's very difficult for me to control all the variables working from home to "perfectly" align the bezels with the viewable areas of the screens, especially for four screens at the same time. For example, a slight tilt can wreck havoc. So, I chose to make the bezels slightly overlap the viewable areas. That way, if the alignment of the bezels was off a bit, you wouldn't see the "ugly" silver metal bezels of the screens themselves. Also, wood varies in thickness, even the laser-cut stuff can vary. It can throw things off quickly for four screens. Plus, I'm no carpenter, unfortunately. Anyway, in my thinking, it was best for games to leave the top and bottom lines blank and to not put text characters in the first and last columns to give the text some margins (or so-called whitespace). That's how my games utilize the screens, but I did notice that your Lunar Lander game used the top and bottom rows.
Perhaps I can try to keep the bezels from encroaching on the viewable areas of the screens in the new design. I come from the era where TV titles were always well indented because the bezels of various TV brands covered the periphery of the screens to differing extents. In times gone by, I did a stint as a TV cameraman and back then TV stations referred to a chart that gave the "safe area" for displaying the main content, especially titles. But nowadays, that is unnecessary, as modern bezels (except for mine ) don't overlap the viewable portion of screens. Nevertheless, from a design aspect, it's generally good to have some margins, as that seems to allow for more "comfortable" viewing. Having said that, my laptop puts the task bar right on the bottom edge of the screen, so there is no wasted space there. So, your point is noted.
As for the VGA resolution, over time, many display resolutions have been offered that have the letters "VGA" in their abbreviations. But when I say "VGA," I mean what I think is the base resolution of 640x480. Expansions on that include, for example, super VGA = SVGA = 800x600. Then there's WVGA for wide VGA, which bumps up the horizontal resolution to 800 pixels (and increases the aspect ratio from 4:3 to 16:9). Going in the other direction, there's also something called quarter VGA, QVGA, which is 320x240 pixels. Lots of smaller screens used that a few years back.
Anyway, in the case of the console, the screens are driven by the Propeller (using kuroneko's driver) at a resolution of 640x480, which is the original VGA resolution (I think). The driver boards are configured to stretch that to 800x480 to fully span the screens, which I assume that they do by doubling up every fourth pixel (that's just a guess, but I don't know how else they could do it unless they did some kind of interpolation). With the built-in Propeller font being 16x32 pixels (WxH), that equates to 40 columns by 15 rows (40x15). All of this won't change in the new console. The screens will still be 7" screens driven at 640x480 (VGA) resolution that gets stretched by the driver boards to 800x480 (WVGA).
I wonder how tall you are. I've never had any difficulty viewing the screens with the console placed on a standard-height table with regular chairs. Maybe you're using taller stools or similar to view the console. In designing the console, I need to get the weight and size down to make it economical to ship (otherwise, there will be no one else with consoles), so like with everything else, there's a limit (not that I've had difficulty viewing the screens in my particular situation). Another thing is that I didn't want the console to be so tall that it blocked a player from viewing the player opposite. But players sit at different heights depending on the length of their torsos (some people are long-waisted) and posture. Anyway, you could make a taller stand for the console. There's nothing special about it. Doing so just takes four wooden pieces that are sufficiently thick to receive the four screws from the base and four more that penetrate the head frame. The wood that I've used is between 17 and 18 mm. But I think you could use something thicker, like some 3/4" stock. That's just a tad over 19 mm, so you'd hardly see a difference (I'm referring to the nominal thickness when I say 3/4", as the actual thickness might be different/thinner).
As for tiltable displays, it's a good idea, and I can see how that would be especially desirable if people were looking at the displays eight hours a day like in an office. But tilting the displays won't work for my next iteration of the console, as I've committed to making it as small as possible, which means bringing the screens closer together such that they can't be tilted since they obstruct one another. Every design is a compromise where the designers strive to hit a balance. My hope is that the new console will be much more practical to build (for me) and ship. I really like the new design, but it involves some compromises. I suppose that it won't work for everybody, but I'm shooting for something that I think will have the most appeal. We'll see though. Thanks for the feedback; it's food for thought.
I am pushing along fine on the Map Editor, this 4 screen concept is absolutely cool. So currently 4 people can work simultaneously on a 400 X 150 Map. (10X10 Screens)
Sounds cool. Gee, a map that's 400x150 text tiles (of 16x32 pixels each) in expanse; that's big! Let's see, in actual pixels, that would be 400x16 by 150x32 = 6400x4800 (yeah, 10x640 by 10x480). That should be big enough to wander around in and explore. Thanks for the update. Looking forward to more.
Another thought is that the food bowls turn out to be really practical, having it sitting on my desk. Cigarettes, Lighter, Cigarette paper, keys and a pen already found there home there.
So my advise would be to have both designs available, say standard and enhanced version.
What I really miss is a power switch or at least a reset button, fiddling around with the power plug to reset is cumbersome.
Have you thought about a foldable version? To not send empty space?
@Mike: Guess I should have mentioned my intention to make a new version before I made any design decisions and chiseled them in stone. Based on your recent comments, you're going to hate the next console: no food bowl, a tad shorter than the existing one, still no power switch, and perhaps other things. I might be able to offer different stand heights, though. And perhaps someday I'll figure out the power switch matter. Anyway, hold on to your console version: Perhaps someday it'll sell on EBAY for a million dollars as the originally released version. Yeah, I jest.
By the way, for better or worse, I already pulled the trigger on ordering some reworked PCB's for the new formfactor. And although I was quite satisfied with my old board house, I'm trying out jlcpcb for this go. They are cheaper per board (though shipping is higher). And I like being able to order from the PCB fabricator directly rather than going through a middle man company. I was impressed by a factory tour video I saw of their amazing operation (this one, I think). That kind of sold me on trying them out.
Back to the formfactor, having a collapsible stand of some kind does seem like a good idea. Member jmg foresaw the desirability for something like that, too (the breadth of his knowledge/insight is scary). I don't know if I ever figured out a good way to do it, though. However, at one time, the keyboards plugged directly into the head. And the stand consisted of two interlocking pieces that could be slid apart to store flat. But I didn't like how the keyboard cables needed to be plugged into the head: it seemed kind of ugly and awkward, so I nixed the design.
I've really been through a lot of formfactors for this project. While designing something with one screen is pretty straightforward, it gets much trickier for four screens pointed in different directions. I've definitely spent much more time on various formfactors and related fabrication methods than on the electronics or programming. In retrospect, that was a huge mistake, and I probably should have went for the simplest design possible from the get-go.
That's what I'm aiming to do now: keep it simple and practical. The latest design probably cuts the fabrication time for the housing (but not the entire console) in half, making production much more practical. Perhaps if I had access to plastic injection molding, things like food bowls, tiltable screens and collapsible stands would be easier to implement. But I'm working in wood mostly at home, and it limits what I can do (though I did once resin mold a truncated pyramid (frustum) housing at home and was rather pleased with the result).
As for the shipping volume matter, it turns out that the consoles that I shipped recently were dominated by the weight rather than by the volume. That is, for that particular sized box I used, I was over its volumetric weight minimum by something like 1 kg. Fortunately, this new design I'm putting together should reduce the entire weight by about 1 kg, a hefty savings. That seems like a step in the right direction.
So the new design involves some compromises, but I hope that it strikes the right balance. It'll be less expensive and time-consuming to make. It'll be a bit smaller to ship and store. I think it'll be cuter, but that's debatable. Mainly, it'll be a whole lot more practical to produce. It's something that I can see making in quantity, much more so than the current design. But it won't please everyone. Oh well, it's like that old song says, "But it's all right now, I learned my lesson well. You see, ya can't please everyone, so ya got to please yourself." Hopefully, the new design will please myself and some potential customers.
As for offering multiple versions with different formfactors, it's not something I'm set up to do right now. I live in a small apartment, and it's all I can do now to deal with making one design. And dealing with two BOM's and fabrication flows is more than I can and/or want to take on. However, I suppose multiple versions is something that I could consider if a particular design did well enough and there were demand for a variant. However, right now, supply exceeds demand, but I haven't advertised things beyond this forum. I don't want to do that until I get the design "right" to my satisfaction.
I'm not sure if that will ever happen. But I think it's a lot more possible with the latest version. If this new version is well received, perhaps multiple people can write games for it. That's important. For games consoles, there's always the "chicken-and-egg" problem: Which should come first, the hardware in the hands of a sufficiently-large user base, or games for the console written by developers? But this console is not a mass-market item, obviously, so I'll be reasonably happy--at least in the early days--if just a few people are writing games for it and maybe a few dozen are using it. Thanks for being both a user and a developer, Mike, and thanks for the feedback.
I am fine with your decisions, they are understandable, but I personally am very happy to have a original designer model of the WordFire. In my opinion your woodworking skills are quite good, and I really like it like it is.
So to make it possible for you to move in a bigger apartment and produce multiple versions of the WF console, I will help you out on the software side of things.
I haven't had time to solve the SD-driver issue, but the only problem is that on writing files the modified date gets overridden by spaces instead of the current date. I will look into that later. Windows claims the SD is corrupt, but it isn't, it is just fine.
To clean up the Lander01 code I build a WFsystem object to separate Game from System code. You already provided most of it, I just needed to tweak it a little bit.
So the attached Lander02 Game is the cleaned up and ported to WFsystem Version of Lander01. The source is quite short now.
I also attach Version 1 of EDITMAP. This one is also using WFsystem as base object and is slightly larger. You should consider it as a preview.
Both Apps need to be installed on the SD card to work, since the folder contain files needed by the programs.
Once on the card you can tweak and run them, the sources are included.
Currently I have no file selector in EditMap, not done yet, so you can just edit the file given in the source, but I am working on it.
I'm glad that you like the current console design. I like it, too. And I also like the new design that I've been burning the midnight oil on of late. The design that you have (WordFire Classic?) is a Ford Explorer, whereas the new design is a Nissan Leaf, or something along those lines. The old design got us to where we are, and now it's passing the torch to the upstart to take us home.
As for programming, I can use all the help I can get, which is rather obvious from looking at my undisciplined code. It's beneficial to see other people's code and best practices. Currently, I've got my hands pretty full with the redesign efforts and haven't been able to think about coding much, let alone game development or content creation (things I want to get back to). But I got the new PCB finished (hope it works) and it's in DHL's hands and headed my way. Last night, I designed a new console base to accommodate the new PCB, and I hope to get it lasercut by tomorrow in time to try out with the new PCB (which will need to be populated and soldered). Things are moving forward, but it sure is nice to be able to collaborate with other console owners. And it seems that you and David are code warriors extraordinaire. I'm definitely out of my league, but that's okay, I guess, as I can bring other ingredients into the mix.
Great job on factoring out various routines to make the WordFire System (WFSystem) object. It looks good. Obviously, it was more than just factoring, as quite a bit of refactoring went into it. Although referencing the object does take some typing (such as wfs. or wfs#), it better isolates things, which could help game writers focus better on their own game logic (rather than system stuff). One thing I wondered about, though, was unused methods. Being lazy, I've only used the Propeller Tool, which doesn't remove uncalled routines. I guess BST and maybe others do remove such code. Anyway, if one were using the Propeller Tool, they could still create a variant of the WFSystem object with unused stuff removed to free up some space, though I guess most games would need most of the stuff that's in there.
I played Lander02 and both died and landed. But I noticed from the help data that it's also possible to crash and survive (not die, or at least not die immediately). In the event of such a crash, hopefully, there's another Lunar Lander within limping distance with an open seat (and a medic). I think it might be nice to have the ENTER key default to the last burn rate/amount in the event no numbers were typed (rather than defaulting to zero). Also, in another version of the game, it might be nice to let four fingers control five keys, such as H, J, K, L and the semicolon (home position for the right hand), with pre-specified burn rates. Then a timer could be added, and one would need to pick a burn rate (such as: H = zero, J = low, K = medium, L = high, ; = pedal to the metal) within that time period or continue with the last burn rate.
Or, as an alternative to a time interval, things could happen dynamically with the quad keyboard driver modified to return the KeyUp or KeyDown status of the keys, such that one would generally continuously hold down keys, but varying the keys as needed. In the latter case, the altitude, velocity, and remaining fuel would be reported continuously, perhaps with some guidance (possible through text color) as to whether one was in the "window" for a safe landing (or maybe that'd make it too easy). Hmm, all that could apply to the method in the previous paragraph, too, where one didn't have to continually hold a key down. Anyway, either of those ways could work well for multiple players and all their flight data could be displayed for every player to see (though one would need to keep their eyes on their own situation most of the time). It would be fun seeing a "crashed" status next to a player's line (or death colors). Perhaps the computer could play (stand in for) any vacant seats around the console. All of that would make for a nice game. It wouldn't be a video game, per se, but it would be dynamically responsive, fun to play alone or with others. It'd make for a nice change from word games when people didn't want to think about words and wanted more "action" (not that word games can't involve action, mind you).
I also test drove EditMap01. Indeed, you did implement it such that it can define a 400x150 text character map. It's a utility program, obviously. Gee, I didn't really foresee the console being used for development. Anyway, good job with the layout, controls, help, popup windows and so on, as well as with the tricky column scrolling. I really like how the character selector page (Char) is laid out; it's perfectly balanced. And for the color picker, I'll bet you cursed me a bit for designing a system with only 8 colors to choose among for foreground and background colors. But I like how you presented all 64 possible fg/bg combinations, even if some of them are similar and some of them are nearly "illegible" (like yellow text on white). Now, I didn't do any serious testing (though I did notice some out-of sequence numbering in the column headers, which is minor stuff for a beta).
I'm curious: What kinds of games do you envision will use the maps created with this utility? Perhaps there are several types. I suppose one obvious type would be where one needs to represent a "world" to wander around in, such as a cave system or a sea with fixed islands, or whatever. Such are probably "duh!" possibilities, so I wonder what the other potential uses are. I think you have other things, different uses in mind. Maybe there some examples on the net that could illuminate the matter for me.
Thanks for the hard work on the WFSystem and MapEdit objects, as well as on the LL2 game. I'd say "Keep up the good work," but I can't ask that of you. But it does seem that you are putting the game console through its paces. That's wonderful! And since you're bound-and-determined (just kidding) to use the top and bottom rows for important text (and perhaps the first and last columns), I'll have to see if can adjust the bezels to accommodate such usage in the new model (so sue me: I didn't know it was a development system, ha-ha). --Jim
Actually the first need for EditMap was the Start Screen. Your method in the example did just allow on FG/BG combination per row. And I wanted the 02 in Lander 02 to stick out.
So storeScreen and restoreScreen where build and I needed to edit the screens. So I needed a simple Screen Editor. But a screen Editor can handle 400X150 with the same ease as 40X15 or 36X12. And it does, that is the way I made the COLOR and the CHAR Map. With EditMap1.
I bit the bullet and 'ported' the newest FAT_Engine from Kye to the WFsystem today. It replaces SD-MMC1A.spin and INCLUDES the rtc driver DSRTC_driver2.spin.
As usual I had to uncomment all the not yet used but provided functions in Kye's driver to match SD-MMC1A.spin and to reduce its overall size.
But the end result is quite OK, I still have newFile and deleteFile included and am just 62 LONGS longer as with the old drivers.
And - TADA - the sd-card driver now nicely reads the rtc to set a correct modified or create date and time … sweet.
EditMap1 is indeed a utility program, I plan to add the ability to edit any file in form of a simple HEX editor. A useful tool anyways. Thinking about them 'corrupted' SD cards, maybe a sector editor also.
As for 'corrupted' SD-cards I finally found out what the problem is, it's ME.
Since I write to the cards, the SD driver needs to unmount.
When the Editor (or Lander02) get exited by loading the GAME MENU they both correctly unmount the drive before starting the MENU, thus NOT corrupting the SD card.
But if you - like me - just rip the card out without ending the program back to the MENU, the card gets NOT unmounted, thus some data does not get updated in the FAT file-System.
So program OK, User Error. End Program before removing SD.
Now to what Games to do with EditMap?.
A lot of the Games in the early days relayed on MAPs. Say PacMan. The borders define where the PacMan can go. Draw a different MAP, have a different Screen. The Game just says - 'you can't move over the following characters...'.
Or say Mario, some chars in the map protect you from falling, others don't, you fall, some are climbable some not. Some are doors, teleporters, whatever.
All of what those kind of games have in common is a MAP to walk/fly/jump/run in. And some set of rules applied to the characters in the map, made up in the game-logic.
My cursor is a very simple animation, we do not have sprites as far as I know. So I just write the cursors in the main loop on the screen, constantly.
But we have 32 user definable characters. If one changes the definition of them ALL occurrences of the character on any screen will change immediately. That could make moving waves, animated Players, all sorts of stuff.
Development on the console. Partly possible.
The MAP Editor makes sense because of that if multiple people can design on the same MAP interactively, someone can draw the walls of the castle, while some other one does the floors and a third one the outside, while the 4st one puts in teleporters/doors and other stuff.
And all user can see what the others are doing, I think this is fun. And you see what you will get out.
The coding of the game logic still needs to be done on a PC, that might be different on a P2.
Anyways I will post the newer Versions tonight, still doing some cleaning up.
I can't believe that you've already updated to the latest version of Kye's driver and paired it down to a smaller size. For its reliability and added functionality, giving up 62 longs is worth it. Most games should be readily able to accommodate that. An exception might be the GameMenu program, as it loads up all the game names and descriptions in advance for speed. So, that'll likely need some rework (as it's down to around 120 longs for the stack).
I had wondered about the unmount situation, even in the "read only" usage scenario that I've been using (and who really knows what the controller chip is doing under the hood). So, it seems wise/prudent to unmount, but always unmounting the card may be tricky to implement. And the user could always turn off the power to the console at an inopportune time. However, maybe that's on the user (his/her fault). However, perhaps a shutdown procedure should be provided, kind of like on Windows, only it would just unmount the card but not turn off the power. Ideally, running the clock program would only mount the card if a user wanted to escape to the GameMenu program. But it can't unmount it because another program quickly loads and runs. I don't know what happens to the card during that time. Also, I presume that everything in COGS gets clobbered in the process, which would abruptly terminate any drivers that were running (hence the screens blank out and who knows what happens to an SD card).
Anyway, for biting that nasty tasting bullet (to undate the SD card driver), I think that you've earned a steep discount on the slim version of the console, should you have interest and providing its big brother doesn't get too jealous of the new kid on the block. That work you've done is really helpful, as it's a core system driver.
About EditMap1, yes, I can see it being useful for creating splash screens and so on, as you mentioned, in addition to its primary duty for creating maps. And your version of the routine to display "banners" (large, pseudo-font) in multiple colors (without additional Spin loops) is good, assuming that it can still update the whole screen in a twinkle of an eye for a good user experience (I haven't specifically paid attention to the screen update speed yet--or pondered the code--but I didn't notice anything being slower).
As for development, nooooo, I didn't mean PASM or SPIN development, of course, but rather just the creation of text/data files for games to use (I should have worded that differently). For example, it's conceivable that we might create some kind of game that progressively remembers stuff (words, sentences) that users type in by adding them to a text file. Or, a user could specifically use the console to edit a text/data file while not playing a game. It's be kind of cool to add additional content--whether questions to a trivia game or what have you--using only the console. Of course, I'd still want to have the Internet and a spellchecker at the ready for more serious content creation.
You sure are cruising right along. You understand the console (and it's limits and potential) better than me now (though I for one think that we've barely scratched the surface with respect to its word game potential). You've really dove right in! There must be something about the console that resonates with you--perhaps the four screens and keyboards--ins such a way that you're motivated you to look under the hood with no real user manual (other than a few documents on the website). Whatever the allure, I'm glad that you've undertaken the challenge.
And I'm doing my best to ready the next version of the console. I did go to the lasercutter shop today (sleep deprived), and they actually cut the new console base for me while I waited. I used to deal with another shop that took about three days to complete an order, but, so far, this shop has done everything I requested within the same day (if not on the spot). Anyway, soon I hope to know if the new PCB works. Again, it's compatible with your console. I don't mean backwards compatible, but compatible in all ways, as it uses the same circuitry connections with the small exception of one of the lines on its so-called expansion connector (which we're not using, as the Propeller has been able to run everything we've thrown at it so far all by itself without resorting to another chip (though such wouldn't be the case for memory-intensive games, I realize)).
Oh, getting back to the SD card matter, are you saying that you only foresee a problem with the card state--though not actual corruption--when one has opened files for writing? I realize that buffers often need to be flushed when doing I/O. But I'm still not sure that there wouldn't be a problem in a read-only situation, as I don't know what the SC card controller chip does behind the scenes with the FAT table and so on. And the answer may vary from card to card depending on the specific controller chip being uses (not to mention flash memory type). Hopefully, reading is safe, but I don't know. At least it doesn't seem to result in actual card corruption, even if Windows may report that before doing a scan that finds no problems.
What? You "rip the card out" without exiting and/or with the power still on? Gee, that seems like asking for trouble. You like to live dangerously or on/over the edge. Good luck with that, though we might learn something useful as a result. As for me, I've been keeping my seatbelt fastened and haven't yet taken off the training wheels.
Well, sorry about rambling out of order here (BTW, I just now went back over this five-hour old post and corrected some typos and added a couple things). Congrats on the EditMap1 work. While my focus has been (and will likely continue to be) word games, I look forward to either writing or seeing something that's in a different vein, such as something using the tile maps in a way for something other than for text. And, yes, being able to redefine part of the character set could make for some smooth animation on a limited basis. No, there are no sprites (unless one writes a different video driver), but redefining font characters could make some old school action games (like Pacman or Space Invaders possible), or a smooth moving Pong or Breakout ball. But the key would be doing something that works for multiple screens in some way (even if only allowing four games to be played at once). Well, I need to post this and run. My apologies if I've neglected to comment on anything.
@"David Betz" , yes he did mention that and it is the same.
I cleaned up the WFsystem object and it does now use the newest driver from Kye out of the OBEX changed to support the existing DSRTC_driver2.spin. Works nicely.
The attached Lander 02 has now a Score-List showing success, crash and dead tallied up for each player and zeroed out at start of the program, so no permanent score-list, yet.
Hi, David. Good question. Yes, code for the existing console will run on the new console with absolutely no changes (though see below). The new circuitry is the same from a component connection standpoint. So the same exact same programs should be able to run on either console.
The only things I did differently in the new design connection-wise were: [1] eliminate the secondary real-time clock socket (as its battery was difficult to source and/or install), [2] change a couple of lines to the so-called expansion header, which won't affect any programs that only use the Propeller chip, and [3] add a 0 Ohm SMD jumper resistor on the infrared (IR) line in case one wants to desolder it to free it up for unfettered use with the expansion header.
Regarding the expansion header, there are some changes there that are not compatible from both the wiring and programming standpoints. Sorry about that (though one could modifiy the existing console board by adding a jumper and cuttting a trace to make it compatible). On the existing board, P25, P30 and P31 were brought out, whereas on the new board, P25, P29 and P31 were brought out. The reason for the change is that P30 is used to drive the blue channel of screen 3 (east), so it wouldn't be free anytime that screen were being used.
In the new version, rather than bring out P30, I brought out P29, which is the SDA line. My thinking was that if one held the SCL (clock) high, the SDA line might then be available to go off board (without affecting the EEPROM or RTC). But I've never used the expansion header to try to connect to another processor, so I don't know for sure if it will work. But that's potentially two pins (P29 and P31) for communication. As mentioned above, there's also a third line available if one is willing to sacrifice the IR line (though maybe there's a connection scenario that could allow the IR line to be kept intact). Anyway, my focus is what the Propeller can do by itself without any external help from another board. Pins are at a premium on the console; this seemed the best that I could do. *Update* Hmm...now that I think about it, I think my original plan was that maybe some kind of wireless board could be added, possibly for programming, in which case P30 might be a better choice. But that's all uncharted territory for me at this point, and I have no immediate plans to pursue such expansion as I have my hands full as it is.
BTW, I received the new PCB's and hope to provide an undate soon. I've got one of the new PCB's mostly soldered, and there are no shorts and the voltages look good. Fingers crossed.
BTW, I received the new PCB's and hope to provide an undate soon. I've got one of the new PCB's mostly soldered, and there are no shorts and the voltages look good. Fingers crossed.
Is there any chance you might decide to offer the new PCB by itself and not installed in a console? Are you using the DIP or the QFP Propeller chip?
Hi, Mike. We cross-posted, but thanks a lot for fielding that question.
So you've incorporated Kye's latest SD card driver, paired down, I presume, as you mentioned before. That's great! Thanks for posting it. I plan to take a look at it or the Lander02 game after I get the new PCB up and running (assuming things go well).
You are using Pin 30 for the screen? Looking at docs, yes you do. This is pretty bad since one can not use the PropPlug as means of communication to a host system once running. But studying your docs further I see why you did that.
Bad, bad. So P25 is the IR-line P29(SDA) and 31 (RX) and they are on the expansion header. That mean one need to solder a adapter cable to connect a PropPlug and can just use it when RTC off or sacrifice the Remote. That is really uncool.
Even worse one may not even be able to connect a PropPlug there AND use a second one to program the console since both Plugs would drive P31 using it as TX to propeller RX.
That leaves sacrifice IR and put a mechanical switch [PGM/RUN] above PropPlug connector, switching between P30 (for Programming) and P25 (for use as serial Host Connection), The serial driver on the prop can start with 31,25 instead of 31,30… all OK, the PropPlug stays connected and I2C bus is undisturbed.
Maybe a 3 way switch [PGM/RUN-IR/RUN-SER] so one just needs to sacrifice the IR if the serial Host connection is needed.
Looks like I need to take the console apart and add a 3 way switch, a reset button and if possible a power switch. Somewhere I had a Dremel tool, it is in one of those boxes still unpacked after moving into my new home. So that will have to wait for a while.
But it would be nice to have 0 ohm resistors (or even better jumpers) on /reset and P30 near the PropPlug Connector, on P25 where you already have planned it in and on VIN directly next to the plug.
I also like @"Peter Jakacki"s standard connector, he uses two rows of 4 pins, the top row is the original PropPlug connector the row below has +3.3V, sda and scl, not sure in what order. one pin is left free for key coding if needed so the plug can not be plugged in wrong.
This allows to directly program the eeprom while holding the propeller in reset. @"Peter Jakacki" made some programmer for it, prop based.
There one could install external eeproms as Game cartridge, booting them from the game menu...
I looked over your GAMEMENU, actually you where almost there I just needed to add two lines.
At the end of PUB getAppData I added shutdownSDCard and at the beginning of PUB bootSDCApp I added mountSDCard.
Now the SD card gets unmounted after reading the MENU and can be removed replaced without getting corrupted as long as the GAME Menu is shown. After re-inserting just reload GAME MENU to see the new directory.
Before loading a new app/game the program now remounts the partition and everything is fine.
Hi, Mike. Way back when, I experimented with different pins for the blue channel. P30 seemed like the best option. It allowed for communication with the Prop before starting up screen 3, and one can keep the Prop Plug connected during a programming session to reset and upload a new program to either the HUB or the EEPROM (of course, game programs that follow the GameMenu conventions may also be ran from the SD card without using a Prop Plug, but that's a longer process). That experimentation was long before there was any sharing of either the hsync or vsync lines.
No, one wouldn't be able to talk to the console while using screen 3, but the four screens allow for displaying debugging info, and there is also a speaker for audible feedback. In designing the system, I wanted all four video screens to use the same sets of pins within each of the Propeller's four eight-pin video groups, thus allowing an array of four video instances to be used (without needing some kind of programming exception in the video driver to handle screen 3). This is the best I could come up with at that time that works with a standard video driver or something pretty close to it.
Also, the console was an evolution, as originally, vsync and hsync were separate for all four screens (i.e., not shared). Later, I was able to share vsync with all four screens, freeing up three pins. Still later, I asked kuroneko for help in sharing both the vsync and hsync signals, freeing up some more pins and allowing a dedicated connection to the SD card. And because of the simularity to the prior design, I was able to modify an existing board with a few jumpers and severed traces to test things. In retrospect, perhaps the vsync and hsync signals could have been moved off of P0 and P1 to keep the lower three pins of each video group for the color channels. Now that vsync and hsync are shared, perhaps that's a possibility. Is that what you're suggesting? Or do you have a another way to drive four screens that wouldn't involve any tradeoffs? If so, would such a way require significant changes to the video driver? If you want to suggest an alternative design, feel free to speak up, as maybe it's not too late to make changes (though midnight is fast approaching when Cinderella's carriage will turn back into a pumpkin). Of course, any such changes likely won't be backwards compatible.
For better or worse, the pin mappings for both the video screens and the keyboards are clearly illustrated on the WordFire website in the documents available from the DOCS tab. And I also posted a colorful diagram of the Pin connectivity for the video screens in Post #5 of this thread in response to your post that said "Running 4 screens, 4 Keyboards and SD from one Propeller is quite a challenge, I would love to see the source." I realize that the gurus on this forum always try to keep P28-P31 free. But most people don't need to drive four video screens (and talk to four keyboards). Also, in designing the console, my main goal was to make a word game console, not a general purpose Propeller programming test rig. Honestly, I figured that most of the user base wouldn't even own a Prop Plug, as they'd just run games off of an SD card.
As for the so-called expansion connector, now, I kind of regret designing it in (or at least mentioning it). Again, I don't expect the average user to monkey with that. It's just there in case it might be useful to a hardware person. In fact, in the latest version of the console, I plan to lightly seal the top of the head unit, such that people won't have ready access to the driver boards and video cables. The reason is, if one reaches in and starts pulling on things without knowing what one is doing, something could get damaged. And those flex cables to the LCD screens are pretty vulnerable. So, I decided that it's best not to make it easy to get into the head, as I envision a target audience that likely isn't familiar with electronics and taking proper precautions "under the hood." Easy access to those video guts is asking for problems, it seems to me (now, anyways). Thus, that so-called expansion header won't even be readily accessible, even for Prop enthusiasts.
Now as for the so-called expansion header, what is your preferred pin connectivity? It might be good to provide two answers, one for the current video pin mapping, and one for any totally reworked video pin mapping (not that I'm committing to implementing such a big remapping at such a late date, but I'm willing to listen/consider it). Again, though, the expansion connector won't be readily available in the next version (if, in fact, I release a new version, the releasing of which is still my hope).
As for switches, I'm reluctant to add any since they likely wouldn't be readily accessible. And I don't want to add any switches to the outer periphery of the PCB because there's already a lot of jacks or sockets there now (a total of 7: 4 USB type A jacks, a power jack, a Prop Plug header, and an SD card socket). That makes for a lot of holes (cutouts) in the base, and the new base is quite a bit smaller than the existing base and barely has room for a full-sized SD card socket, which I prefer to a micro SD card one. Early in the design process, I considered having a switch for the Prop Plug back when I was sharing one or two of those high-numbered pins for the SD card. But I felt that was a pretty awkward solution. Well, that's about as best that I can answer for now. Honestly, I'm sort of foggy on why a serial host connection is needed. I have no problem programming and flashing the console for active game develpment. And I use either one or more of the screens or the speaker for debugging. Perhaps there's something that I'm not seeing.
Bad, bad. So P25 is the IR-line P29(SDA) and 31 (RX) and they are on the expansion header. That mean one need to solder a adapter cable to connect a PropPlug and can just use it when RTC off or sacrifice the Remote. That is really uncool.
I don't quite get your meaning. The new console version provides a connector for the Prop Plug, just like on the existing console. (By the way, I think you understand, but, ignoring the expansion header, P25 is only used as the IR line.)
Even worse one may not even be able to connect a PropPlug there AND use a second one to program the console since both Plugs would drive P31 using it as TX to propeller RX.
Oh, do you mean a second Prop Plug? Could you elaborate on why a second Prop Plug is needed? *Update* Hmm...I suppose you mean if using the game console as a general purpose Propeller programming rig. I'm definitely not a power user. I've never used more than one Prop Plug with the Propeller. Now, perhaps I can partially see why you're talking about switches.
There one could install external eeproms as Game cartridge, booting them from the game menu...
Oh, you mean like on the Hydra Game System? Gee, that's a great system, but, honestly, I have no plans for this game console to use cartridges. And for the word games it was designed for, it doesn't seem necessary (at least not for most of the kinds that I envision). Besides, providing a cartridge "slot" ups the geek factor and might make the console more scary to non-hardware people. I prefer to just stick with SD cards. Hey, at least I'm not like Apple, as there is an SD card socket on board (though not a cartridge slot).
At Mike, thanks for those changes to GameMenu. They seem merited. You continue to roll right along! I'm appreciative of that.
However, when one mounts the SD card just before calling the boot procedure, that leaves it mounted during the boot from the perspective of the card, doesn't it? Do you think anything could go wrong during the boot process from the SD card standpoint? At the very least, it would seem that the SD card would get mounted twice in succession: once just prior to the boot call and once by the new game program that loads in. I'm assuming that the SD card driver doesn't check the card's status, though perhaps it always does an unmount before mounting just to be safe--need to check. I don't know that a successive mount operation could potentially cause a problem, but I also don't know that it wouldn't (and maybe it depends on the SD card controller chip).
Comments
I wasn't even aware that I was using an older version of Kye's SD card code. Although I've never gotten around to writing any files to the console's SD card, I have noticed that Windows sometimes reports a problem with an SD card that's been used by the console, but it then says that no errors were found when it does its scan. I don't think that I've seen Windows report any actual corruption or repair anything, which seems consistent with what you've reported. Prior to your post, my guess (mere speculation) was that the SD card wasn't being shut down properly by the console, or something along those lines. Frankly speaking, I've had so many other aspects of the console to work on (electronics, game creation, the formfactor, fabrication, etc.) that I didn't investigate it, and, in fact, I probably wouldn't have known how to look into it if I had tried. So I really appreciate your efforts in that regard.
So, based on your post, I think you're saying that the problem results from the modified date field on the card being empty. I had no idea. I wonder how you figured that out. Did you use some diagnostic tool to look at the SD card or just regular reporting from your PC's OS? Whatever the case, that's very good investigative work on your part. Thanks for doing that and informing us.
By the way, one of the reasons for the latest version of the console was that I wanted to stop sharing the SD card lines with pins being used for other things. I figured that such sharing was asking for trouble. But it took some video driver modification work by kuroneko to free up some pins (by sharing the HV sync lines). Now, all four pins used by the SD card are dedicated to SD card usage. So that may make it easier to track down any problems.
I've also never used the console to create or delete any files or directories, creating them on the PC instead, as you said. Does the newest version of Kye's driver also fix that problem (like it did for the date problem)? If it doesn't, the problem can be worked around, like you said. For example, HighScrs.txt or SaveGame.txt files could be created in advance, even if they weren't used.
Sounds like a new version of the SD card driver is needed for the console. I haven't really looked at the SD card driver for at least a couple years. But I do recall that I pruned out some of the unneeded functionality, just like you mentioned, in order to make more room available for other code. Some programs may need all the space they can get. For example, the GameMenu program only leaves 123 longs for the stack (since it loads all the game names and descriptions into HUB memory for fast access). I haven't used any stack measuring object or other techniques to see how much stack space is needed, but I imagine that 123 longs is close to pushing things to the breaking point.
Meanwhile, your work on paging in screens opens up new possibilities. Instruction screens--well, really anything with a lot of text--eats up precious memory. So loading them in from SD makes sense where such instructions are lengthy. Beyond that, the ability to load in "tiles" for larger screen maps make possible more complex games, especially those involving worlds to pan around in or whatever. While I've confined myself to straight text games, I can see how that functionality would come in handy. You've really pressed the pedal to the metal. I'd tell you to keep up the good work, but then I'd feel guilty about encouraging you to do stuff that I probably should have done. Ah, heck with it: keep up the good work!
And don't mind those squirrels. It's often the case that getting distracted by a squirrel leads to something good (if one doesn't get hit by a car chasing the squirrel).
The reasons for the new console version are that I want to: [1] make the console smaller/lighter to the reduce shipping cost, and [2] make the console less complex to build to lower the fabrication cost (and effort required). The existing console is too big and complex to continue offering at the $250 price point plus shipping. As you might guess, to accomplish the foregoing goals, something had to give. In particular, the snack bowl has been phased out, which a couple of you mentioned that you could live without. But what the new console sacrifices in functionality (namely, snacking convenience), it makes up for in cuteness, I feel.
I'm considering also offering a two-screen, two-keyboard version with blanks standing in for two of the screens in the console itself. Such a two-screen version could be sold for around $50 less than the four-screen version, getting people in at a lower price point. Some people mostly want to play games with one other player, anyway, so a two-screen version fits that bill. Moreover, the two-screen version could potentially be upgraded to the four-screen version (via an upgrade kit) with some assembly effort. Although I had a design for a dedicated two-screen version, I think it's better to go with a version that's upgradeable in light of the fact that the new formfactor will be smaller and cheaper anyway (but I could change my mind on that).
Anyway, that's what I'm working on at present. Once I make good progress, I'll try to provide an update.
I am absolutely against VGA resolution, it is perfect with 40X15
For your new design I would ask for tilted or even tilt-able displays, currently the screens are to low and you constantly have to 'duck' to read the screens. Or put the console on a phonebook.
All 4 of my screens have a visible defect in form of a H in the upper right quadrant and the bezels are slightly to big and overlapping the display. On the other hand the screens have a very stable and colorful picture, nice video driver.
I am pushing along fine on the Map Editor, this 4 screen concept is absolutely cool. So currently 4 people can work simultaneously on a 400 X 150 Map. (10X10 Screens) A little crude and beta beta, but usable.
Some files coming soon, still need some cleanup.
Enjoy!
Mike
As for the bezels slightly overlapping the screens, that was by design. Maybe it was a poor design choice, but it was intentional. It's very difficult for me to control all the variables working from home to "perfectly" align the bezels with the viewable areas of the screens, especially for four screens at the same time. For example, a slight tilt can wreck havoc. So, I chose to make the bezels slightly overlap the viewable areas. That way, if the alignment of the bezels was off a bit, you wouldn't see the "ugly" silver metal bezels of the screens themselves. Also, wood varies in thickness, even the laser-cut stuff can vary. It can throw things off quickly for four screens. Plus, I'm no carpenter, unfortunately. Anyway, in my thinking, it was best for games to leave the top and bottom lines blank and to not put text characters in the first and last columns to give the text some margins (or so-called whitespace). That's how my games utilize the screens, but I did notice that your Lunar Lander game used the top and bottom rows.
Perhaps I can try to keep the bezels from encroaching on the viewable areas of the screens in the new design. I come from the era where TV titles were always well indented because the bezels of various TV brands covered the periphery of the screens to differing extents. In times gone by, I did a stint as a TV cameraman and back then TV stations referred to a chart that gave the "safe area" for displaying the main content, especially titles. But nowadays, that is unnecessary, as modern bezels (except for mine
As for the VGA resolution, over time, many display resolutions have been offered that have the letters "VGA" in their abbreviations. But when I say "VGA," I mean what I think is the base resolution of 640x480. Expansions on that include, for example, super VGA = SVGA = 800x600. Then there's WVGA for wide VGA, which bumps up the horizontal resolution to 800 pixels (and increases the aspect ratio from 4:3 to 16:9). Going in the other direction, there's also something called quarter VGA, QVGA, which is 320x240 pixels. Lots of smaller screens used that a few years back.
Anyway, in the case of the console, the screens are driven by the Propeller (using kuroneko's driver) at a resolution of 640x480, which is the original VGA resolution (I think). The driver boards are configured to stretch that to 800x480 to fully span the screens, which I assume that they do by doubling up every fourth pixel (that's just a guess, but I don't know how else they could do it unless they did some kind of interpolation). With the built-in Propeller font being 16x32 pixels (WxH), that equates to 40 columns by 15 rows (40x15). All of this won't change in the new console. The screens will still be 7" screens driven at 640x480 (VGA) resolution that gets stretched by the driver boards to 800x480 (WVGA).
I wonder how tall you are. I've never had any difficulty viewing the screens with the console placed on a standard-height table with regular chairs. Maybe you're using taller stools or similar to view the console. In designing the console, I need to get the weight and size down to make it economical to ship (otherwise, there will be no one else with consoles), so like with everything else, there's a limit (not that I've had difficulty viewing the screens in my particular situation). Another thing is that I didn't want the console to be so tall that it blocked a player from viewing the player opposite. But players sit at different heights depending on the length of their torsos (some people are long-waisted) and posture. Anyway, you could make a taller stand for the console. There's nothing special about it. Doing so just takes four wooden pieces that are sufficiently thick to receive the four screws from the base and four more that penetrate the head frame. The wood that I've used is between 17 and 18 mm. But I think you could use something thicker, like some 3/4" stock. That's just a tad over 19 mm, so you'd hardly see a difference (I'm referring to the nominal thickness when I say 3/4", as the actual thickness might be different/thinner).
As for tiltable displays, it's a good idea, and I can see how that would be especially desirable if people were looking at the displays eight hours a day like in an office. But tilting the displays won't work for my next iteration of the console, as I've committed to making it as small as possible, which means bringing the screens closer together such that they can't be tilted since they obstruct one another. Every design is a compromise where the designers strive to hit a balance. My hope is that the new console will be much more practical to build (for me) and ship. I really like the new design, but it involves some compromises. I suppose that it won't work for everybody, but I'm shooting for something that I think will have the most appeal. We'll see though. Thanks for the feedback; it's food for thought.
Sounds cool. Gee, a map that's 400x150 text tiles (of 16x32 pixels each) in expanse; that's big! Let's see, in actual pixels, that would be 400x16 by 150x32 = 6400x4800 (yeah, 10x640 by 10x480). That should be big enough to wander around in and explore. Thanks for the update. Looking forward to more.
So my advise would be to have both designs available, say standard and enhanced version.
What I really miss is a power switch or at least a reset button, fiddling around with the power plug to reset is cumbersome.
Have you thought about a foldable version? To not send empty space?
Mike
By the way, for better or worse, I already pulled the trigger on ordering some reworked PCB's for the new formfactor. And although I was quite satisfied with my old board house, I'm trying out jlcpcb for this go. They are cheaper per board (though shipping is higher). And I like being able to order from the PCB fabricator directly rather than going through a middle man company. I was impressed by a factory tour video I saw of their amazing operation (this one, I think). That kind of sold me on trying them out.
Back to the formfactor, having a collapsible stand of some kind does seem like a good idea. Member jmg foresaw the desirability for something like that, too (the breadth of his knowledge/insight is scary). I don't know if I ever figured out a good way to do it, though. However, at one time, the keyboards plugged directly into the head. And the stand consisted of two interlocking pieces that could be slid apart to store flat. But I didn't like how the keyboard cables needed to be plugged into the head: it seemed kind of ugly and awkward, so I nixed the design.
I've really been through a lot of formfactors for this project. While designing something with one screen is pretty straightforward, it gets much trickier for four screens pointed in different directions. I've definitely spent much more time on various formfactors and related fabrication methods than on the electronics or programming. In retrospect, that was a huge mistake, and I probably should have went for the simplest design possible from the get-go.
That's what I'm aiming to do now: keep it simple and practical. The latest design probably cuts the fabrication time for the housing (but not the entire console) in half, making production much more practical. Perhaps if I had access to plastic injection molding, things like food bowls, tiltable screens and collapsible stands would be easier to implement. But I'm working in wood mostly at home, and it limits what I can do (though I did once resin mold a truncated pyramid (frustum) housing at home and was rather pleased with the result).
As for the shipping volume matter, it turns out that the consoles that I shipped recently were dominated by the weight rather than by the volume. That is, for that particular sized box I used, I was over its volumetric weight minimum by something like 1 kg. Fortunately, this new design I'm putting together should reduce the entire weight by about 1 kg, a hefty savings. That seems like a step in the right direction.
So the new design involves some compromises, but I hope that it strikes the right balance. It'll be less expensive and time-consuming to make. It'll be a bit smaller to ship and store. I think it'll be cuter, but that's debatable. Mainly, it'll be a whole lot more practical to produce. It's something that I can see making in quantity, much more so than the current design. But it won't please everyone. Oh well, it's like that old song says, "But it's all right now, I learned my lesson well. You see, ya can't please everyone, so ya got to please yourself." Hopefully, the new design will please myself and some potential customers.
As for offering multiple versions with different formfactors, it's not something I'm set up to do right now. I live in a small apartment, and it's all I can do now to deal with making one design. And dealing with two BOM's and fabrication flows is more than I can and/or want to take on. However, I suppose multiple versions is something that I could consider if a particular design did well enough and there were demand for a variant. However, right now, supply exceeds demand, but I haven't advertised things beyond this forum. I don't want to do that until I get the design "right" to my satisfaction.
I'm not sure if that will ever happen. But I think it's a lot more possible with the latest version. If this new version is well received, perhaps multiple people can write games for it. That's important. For games consoles, there's always the "chicken-and-egg" problem: Which should come first, the hardware in the hands of a sufficiently-large user base, or games for the console written by developers? But this console is not a mass-market item, obviously, so I'll be reasonably happy--at least in the early days--if just a few people are writing games for it and maybe a few dozen are using it. Thanks for being both a user and a developer, Mike, and thanks for the feedback.
I am fine with your decisions, they are understandable, but I personally am very happy to have a original designer model of the WordFire. In my opinion your woodworking skills are quite good, and I really like it like it is.
So to make it possible for you to move in a bigger apartment and produce multiple versions of the WF console, I will help you out on the software side of things.
I haven't had time to solve the SD-driver issue, but the only problem is that on writing files the modified date gets overridden by spaces instead of the current date. I will look into that later. Windows claims the SD is corrupt, but it isn't, it is just fine.
To clean up the Lander01 code I build a WFsystem object to separate Game from System code. You already provided most of it, I just needed to tweak it a little bit.
So the attached Lander02 Game is the cleaned up and ported to WFsystem Version of Lander01. The source is quite short now.
I also attach Version 1 of EDITMAP. This one is also using WFsystem as base object and is slightly larger. You should consider it as a preview.
Both Apps need to be installed on the SD card to work, since the folder contain files needed by the programs.
Once on the card you can tweak and run them, the sources are included.
Currently I have no file selector in EditMap, not done yet, so you can just edit the file given in the source, but I am working on it.
Enjoy!
Mike
I'm glad that you like the current console design. I like it, too. And I also like the new design that I've been burning the midnight oil on of late. The design that you have (WordFire Classic?) is a Ford Explorer, whereas the new design is a Nissan Leaf, or something along those lines. The old design got us to where we are, and now it's passing the torch to the upstart to take us home.
As for programming, I can use all the help I can get, which is rather obvious from looking at my undisciplined code. It's beneficial to see other people's code and best practices. Currently, I've got my hands pretty full with the redesign efforts and haven't been able to think about coding much, let alone game development or content creation (things I want to get back to). But I got the new PCB finished (hope it works) and it's in DHL's hands and headed my way. Last night, I designed a new console base to accommodate the new PCB, and I hope to get it lasercut by tomorrow in time to try out with the new PCB (which will need to be populated and soldered). Things are moving forward, but it sure is nice to be able to collaborate with other console owners. And it seems that you and David are code warriors extraordinaire. I'm definitely out of my league, but that's okay, I guess, as I can bring other ingredients into the mix.
Great job on factoring out various routines to make the WordFire System (WFSystem) object. It looks good. Obviously, it was more than just factoring, as quite a bit of refactoring went into it. Although referencing the object does take some typing (such as wfs. or wfs#), it better isolates things, which could help game writers focus better on their own game logic (rather than system stuff). One thing I wondered about, though, was unused methods. Being lazy, I've only used the Propeller Tool, which doesn't remove uncalled routines. I guess BST and maybe others do remove such code. Anyway, if one were using the Propeller Tool, they could still create a variant of the WFSystem object with unused stuff removed to free up some space, though I guess most games would need most of the stuff that's in there.
I played Lander02 and both died and landed. But I noticed from the help data that it's also possible to crash and survive (not die, or at least not die immediately). In the event of such a crash, hopefully, there's another Lunar Lander within limping distance with an open seat (and a medic). I think it might be nice to have the ENTER key default to the last burn rate/amount in the event no numbers were typed (rather than defaulting to zero). Also, in another version of the game, it might be nice to let four fingers control five keys, such as H, J, K, L and the semicolon (home position for the right hand), with pre-specified burn rates. Then a timer could be added, and one would need to pick a burn rate (such as: H = zero, J = low, K = medium, L = high, ; = pedal to the metal) within that time period or continue with the last burn rate.
Or, as an alternative to a time interval, things could happen dynamically with the quad keyboard driver modified to return the KeyUp or KeyDown status of the keys, such that one would generally continuously hold down keys, but varying the keys as needed. In the latter case, the altitude, velocity, and remaining fuel would be reported continuously, perhaps with some guidance (possible through text color) as to whether one was in the "window" for a safe landing (or maybe that'd make it too easy). Hmm, all that could apply to the method in the previous paragraph, too, where one didn't have to continually hold a key down. Anyway, either of those ways could work well for multiple players and all their flight data could be displayed for every player to see (though one would need to keep their eyes on their own situation most of the time). It would be fun seeing a "crashed" status next to a player's line (or death colors). Perhaps the computer could play (stand in for) any vacant seats around the console. All of that would make for a nice game. It wouldn't be a video game, per se, but it would be dynamically responsive, fun to play alone or with others. It'd make for a nice change from word games when people didn't want to think about words and wanted more "action" (not that word games can't involve action, mind you).
I also test drove EditMap01. Indeed, you did implement it such that it can define a 400x150 text character map. It's a utility program, obviously. Gee, I didn't really foresee the console being used for development. Anyway, good job with the layout, controls, help, popup windows and so on, as well as with the tricky column scrolling. I really like how the character selector page (Char) is laid out; it's perfectly balanced. And for the color picker, I'll bet you cursed me a bit for designing a system with only 8 colors to choose among for foreground and background colors. But I like how you presented all 64 possible fg/bg combinations, even if some of them are similar and some of them are nearly "illegible" (like yellow text on white). Now, I didn't do any serious testing (though I did notice some out-of sequence numbering in the column headers, which is minor stuff for a beta).
I'm curious: What kinds of games do you envision will use the maps created with this utility? Perhaps there are several types. I suppose one obvious type would be where one needs to represent a "world" to wander around in, such as a cave system or a sea with fixed islands, or whatever. Such are probably "duh!" possibilities, so I wonder what the other potential uses are. I think you have other things, different uses in mind. Maybe there some examples on the net that could illuminate the matter for me.
Thanks for the hard work on the WFSystem and MapEdit objects, as well as on the LL2 game. I'd say "Keep up the good work," but I can't ask that of you. But it does seem that you are putting the game console through its paces. That's wonderful! And since you're bound-and-determined (just kidding) to use the top and bottom rows for important text (and perhaps the first and last columns), I'll have to see if can adjust the bezels to accommodate such usage in the new model (so sue me: I didn't know it was a development system, ha-ha). --Jim
So storeScreen and restoreScreen where build and I needed to edit the screens. So I needed a simple Screen Editor. But a screen Editor can handle 400X150 with the same ease as 40X15 or 36X12. And it does, that is the way I made the COLOR and the CHAR Map. With EditMap1.
I bit the bullet and 'ported' the newest FAT_Engine from Kye to the WFsystem today. It replaces SD-MMC1A.spin and INCLUDES the rtc driver DSRTC_driver2.spin.
As usual I had to uncomment all the not yet used but provided functions in Kye's driver to match SD-MMC1A.spin and to reduce its overall size.
But the end result is quite OK, I still have newFile and deleteFile included and am just 62 LONGS longer as with the old drivers.
And - TADA - the sd-card driver now nicely reads the rtc to set a correct modified or create date and time … sweet.
EditMap1 is indeed a utility program, I plan to add the ability to edit any file in form of a simple HEX editor. A useful tool anyways. Thinking about them 'corrupted' SD cards, maybe a sector editor also.
As for 'corrupted' SD-cards I finally found out what the problem is, it's ME.
Since I write to the cards, the SD driver needs to unmount.
When the Editor (or Lander02) get exited by loading the GAME MENU they both correctly unmount the drive before starting the MENU, thus NOT corrupting the SD card.
But if you - like me - just rip the card out without ending the program back to the MENU, the card gets NOT unmounted, thus some data does not get updated in the FAT file-System.
So program OK, User Error. End Program before removing SD.
Now to what Games to do with EditMap?.
A lot of the Games in the early days relayed on MAPs. Say PacMan. The borders define where the PacMan can go. Draw a different MAP, have a different Screen. The Game just says - 'you can't move over the following characters...'.
Or say Mario, some chars in the map protect you from falling, others don't, you fall, some are climbable some not. Some are doors, teleporters, whatever.
All of what those kind of games have in common is a MAP to walk/fly/jump/run in. And some set of rules applied to the characters in the map, made up in the game-logic.
My cursor is a very simple animation, we do not have sprites as far as I know. So I just write the cursors in the main loop on the screen, constantly.
But we have 32 user definable characters. If one changes the definition of them ALL occurrences of the character on any screen will change immediately. That could make moving waves, animated Players, all sorts of stuff.
Development on the console. Partly possible.
The MAP Editor makes sense because of that if multiple people can design on the same MAP interactively, someone can draw the walls of the castle, while some other one does the floors and a third one the outside, while the 4st one puts in teleporters/doors and other stuff.
And all user can see what the others are doing, I think this is fun. And you see what you will get out.
The coding of the game logic still needs to be done on a PC, that might be different on a P2.
Anyways I will post the newer Versions tonight, still doing some cleaning up.
Enjoy!
Mike
I can't believe that you've already updated to the latest version of Kye's driver and paired it down to a smaller size. For its reliability and added functionality, giving up 62 longs is worth it. Most games should be readily able to accommodate that. An exception might be the GameMenu program, as it loads up all the game names and descriptions in advance for speed. So, that'll likely need some rework (as it's down to around 120 longs for the stack).
I had wondered about the unmount situation, even in the "read only" usage scenario that I've been using (and who really knows what the controller chip is doing under the hood). So, it seems wise/prudent to unmount, but always unmounting the card may be tricky to implement. And the user could always turn off the power to the console at an inopportune time. However, maybe that's on the user (his/her fault). However, perhaps a shutdown procedure should be provided, kind of like on Windows, only it would just unmount the card but not turn off the power. Ideally, running the clock program would only mount the card if a user wanted to escape to the GameMenu program. But it can't unmount it because another program quickly loads and runs. I don't know what happens to the card during that time. Also, I presume that everything in COGS gets clobbered in the process, which would abruptly terminate any drivers that were running (hence the screens blank out and who knows what happens to an SD card).
Anyway, for biting that nasty tasting bullet (to undate the SD card driver), I think that you've earned a steep discount on the slim version of the console, should you have interest and providing its big brother doesn't get too jealous of the new kid on the block. That work you've done is really helpful, as it's a core system driver.
About EditMap1, yes, I can see it being useful for creating splash screens and so on, as you mentioned, in addition to its primary duty for creating maps. And your version of the routine to display "banners" (large, pseudo-font) in multiple colors (without additional Spin loops) is good, assuming that it can still update the whole screen in a twinkle of an eye for a good user experience (I haven't specifically paid attention to the screen update speed yet--or pondered the code--but I didn't notice anything being slower).
As for development, nooooo, I didn't mean PASM or SPIN development, of course, but rather just the creation of text/data files for games to use (I should have worded that differently). For example, it's conceivable that we might create some kind of game that progressively remembers stuff (words, sentences) that users type in by adding them to a text file. Or, a user could specifically use the console to edit a text/data file while not playing a game. It's be kind of cool to add additional content--whether questions to a trivia game or what have you--using only the console. Of course, I'd still want to have the Internet and a spellchecker at the ready for more serious content creation.
You sure are cruising right along. You understand the console (and it's limits and potential) better than me now (though I for one think that we've barely scratched the surface with respect to its word game potential). You've really dove right in! There must be something about the console that resonates with you--perhaps the four screens and keyboards--ins such a way that you're motivated you to look under the hood with no real user manual (other than a few documents on the website). Whatever the allure, I'm glad that you've undertaken the challenge.
And I'm doing my best to ready the next version of the console. I did go to the lasercutter shop today (sleep deprived), and they actually cut the new console base for me while I waited. I used to deal with another shop that took about three days to complete an order, but, so far, this shop has done everything I requested within the same day (if not on the spot). Anyway, soon I hope to know if the new PCB works. Again, it's compatible with your console. I don't mean backwards compatible, but compatible in all ways, as it uses the same circuitry connections with the small exception of one of the lines on its so-called expansion connector (which we're not using, as the Propeller has been able to run everything we've thrown at it so far all by itself without resorting to another chip (though such wouldn't be the case for memory-intensive games, I realize)).
Oh, getting back to the SD card matter, are you saying that you only foresee a problem with the card state--though not actual corruption--when one has opened files for writing? I realize that buffers often need to be flushed when doing I/O. But I'm still not sure that there wouldn't be a problem in a read-only situation, as I don't know what the SC card controller chip does behind the scenes with the FAT table and so on. And the answer may vary from card to card depending on the specific controller chip being uses (not to mention flash memory type). Hopefully, reading is safe, but I don't know. At least it doesn't seem to result in actual card corruption, even if Windows may report that before doing a scan that finds no problems.
What? You "rip the card out" without exiting and/or with the power still on? Gee, that seems like asking for trouble. You like to live dangerously or on/over the edge. Good luck with that, though we might learn something useful as a result. As for me, I've been keeping my seatbelt fastened and haven't yet taken off the training wheels.
Well, sorry about rambling out of order here (BTW, I just now went back over this five-hour old post and corrected some typos and added a couple things). Congrats on the EditMap1 work. While my focus has been (and will likely continue to be) word games, I look forward to either writing or seeing something that's in a different vein, such as something using the tile maps in a way for something other than for text. And, yes, being able to redefine part of the character set could make for some smooth animation on a limited basis. No, there are no sprites (unless one writes a different video driver), but redefining font characters could make some old school action games (like Pacman or Space Invaders possible), or a smooth moving Pong or Breakout ball. But the key would be doing something that works for multiple screens in some way (even if only allowing four games to be played at once). Well, I need to post this and run. My apologies if I've neglected to comment on anything.
I cleaned up the WFsystem object and it does now use the newest driver from Kye out of the OBEX changed to support the existing DSRTC_driver2.spin. Works nicely.
The attached Lander 02 has now a Score-List showing success, crash and dead tallied up for each player and zeroed out at start of the program, so no permanent score-list, yet.
Enjoy!
Mike
The only things I did differently in the new design connection-wise were: [1] eliminate the secondary real-time clock socket (as its battery was difficult to source and/or install), [2] change a couple of lines to the so-called expansion header, which won't affect any programs that only use the Propeller chip, and [3] add a 0 Ohm SMD jumper resistor on the infrared (IR) line in case one wants to desolder it to free it up for unfettered use with the expansion header.
Regarding the expansion header, there are some changes there that are not compatible from both the wiring and programming standpoints. Sorry about that (though one could modifiy the existing console board by adding a jumper and cuttting a trace to make it compatible). On the existing board, P25, P30 and P31 were brought out, whereas on the new board, P25, P29 and P31 were brought out. The reason for the change is that P30 is used to drive the blue channel of screen 3 (east), so it wouldn't be free anytime that screen were being used.
In the new version, rather than bring out P30, I brought out P29, which is the SDA line. My thinking was that if one held the SCL (clock) high, the SDA line might then be available to go off board (without affecting the EEPROM or RTC). But I've never used the expansion header to try to connect to another processor, so I don't know for sure if it will work. But that's potentially two pins (P29 and P31) for communication. As mentioned above, there's also a third line available if one is willing to sacrifice the IR line (though maybe there's a connection scenario that could allow the IR line to be kept intact). Anyway, my focus is what the Propeller can do by itself without any external help from another board. Pins are at a premium on the console; this seemed the best that I could do. *Update* Hmm...now that I think about it, I think my original plan was that maybe some kind of wireless board could be added, possibly for programming, in which case P30 might be a better choice. But that's all uncharted territory for me at this point, and I have no immediate plans to pursue such expansion as I have my hands full as it is.
BTW, I received the new PCB's and hope to provide an undate soon. I've got one of the new PCB's mostly soldered, and there are no shorts and the voltages look good. Fingers crossed.
So you've incorporated Kye's latest SD card driver, paired down, I presume, as you mentioned before. That's great! Thanks for posting it. I plan to take a look at it or the Lander02 game after I get the new PCB up and running (assuming things go well).
You are using Pin 30 for the screen? Looking at docs, yes you do. This is pretty bad since one can not use the PropPlug as means of communication to a host system once running. But studying your docs further I see why you did that.
Bad, bad. So P25 is the IR-line P29(SDA) and 31 (RX) and they are on the expansion header. That mean one need to solder a adapter cable to connect a PropPlug and can just use it when RTC off or sacrifice the Remote. That is really uncool.
Even worse one may not even be able to connect a PropPlug there AND use a second one to program the console since both Plugs would drive P31 using it as TX to propeller RX.
That leaves sacrifice IR and put a mechanical switch [PGM/RUN] above PropPlug connector, switching between P30 (for Programming) and P25 (for use as serial Host Connection), The serial driver on the prop can start with 31,25 instead of 31,30… all OK, the PropPlug stays connected and I2C bus is undisturbed.
Maybe a 3 way switch [PGM/RUN-IR/RUN-SER] so one just needs to sacrifice the IR if the serial Host connection is needed.
Looks like I need to take the console apart and add a 3 way switch, a reset button and if possible a power switch. Somewhere I had a Dremel tool, it is in one of those boxes still unpacked after moving into my new home. So that will have to wait for a while.
But it would be nice to have 0 ohm resistors (or even better jumpers) on /reset and P30 near the PropPlug Connector, on P25 where you already have planned it in and on VIN directly next to the plug.
I also like @"Peter Jakacki"s standard connector, he uses two rows of 4 pins, the top row is the original PropPlug connector the row below has +3.3V, sda and scl, not sure in what order. one pin is left free for key coding if needed so the plug can not be plugged in wrong.
This allows to directly program the eeprom while holding the propeller in reset. @"Peter Jakacki" made some programmer for it, prop based.
There one could install external eeproms as Game cartridge, booting them from the game menu...
Enjoy!
Mike
I looked over your GAMEMENU, actually you where almost there I just needed to add two lines.
At the end of PUB getAppData I added shutdownSDCard and at the beginning of PUB bootSDCApp I added mountSDCard.
Now the SD card gets unmounted after reading the MENU and can be removed replaced without getting corrupted as long as the GAME Menu is shown. After re-inserting just reload GAME MENU to see the new directory.
Before loading a new app/game the program now remounts the partition and everything is fine.
Enjoy!
Mike
No, one wouldn't be able to talk to the console while using screen 3, but the four screens allow for displaying debugging info, and there is also a speaker for audible feedback. In designing the system, I wanted all four video screens to use the same sets of pins within each of the Propeller's four eight-pin video groups, thus allowing an array of four video instances to be used (without needing some kind of programming exception in the video driver to handle screen 3). This is the best I could come up with at that time that works with a standard video driver or something pretty close to it.
Also, the console was an evolution, as originally, vsync and hsync were separate for all four screens (i.e., not shared). Later, I was able to share vsync with all four screens, freeing up three pins. Still later, I asked kuroneko for help in sharing both the vsync and hsync signals, freeing up some more pins and allowing a dedicated connection to the SD card. And because of the simularity to the prior design, I was able to modify an existing board with a few jumpers and severed traces to test things. In retrospect, perhaps the vsync and hsync signals could have been moved off of P0 and P1 to keep the lower three pins of each video group for the color channels. Now that vsync and hsync are shared, perhaps that's a possibility. Is that what you're suggesting? Or do you have a another way to drive four screens that wouldn't involve any tradeoffs? If so, would such a way require significant changes to the video driver? If you want to suggest an alternative design, feel free to speak up, as maybe it's not too late to make changes (though midnight is fast approaching when Cinderella's carriage will turn back into a pumpkin). Of course, any such changes likely won't be backwards compatible.
For better or worse, the pin mappings for both the video screens and the keyboards are clearly illustrated on the WordFire website in the documents available from the DOCS tab. And I also posted a colorful diagram of the Pin connectivity for the video screens in Post #5 of this thread in response to your post that said "Running 4 screens, 4 Keyboards and SD from one Propeller is quite a challenge, I would love to see the source." I realize that the gurus on this forum always try to keep P28-P31 free. But most people don't need to drive four video screens (and talk to four keyboards). Also, in designing the console, my main goal was to make a word game console, not a general purpose Propeller programming test rig. Honestly, I figured that most of the user base wouldn't even own a Prop Plug, as they'd just run games off of an SD card.
As for the so-called expansion connector, now, I kind of regret designing it in (or at least mentioning it). Again, I don't expect the average user to monkey with that. It's just there in case it might be useful to a hardware person. In fact, in the latest version of the console, I plan to lightly seal the top of the head unit, such that people won't have ready access to the driver boards and video cables. The reason is, if one reaches in and starts pulling on things without knowing what one is doing, something could get damaged. And those flex cables to the LCD screens are pretty vulnerable. So, I decided that it's best not to make it easy to get into the head, as I envision a target audience that likely isn't familiar with electronics and taking proper precautions "under the hood." Easy access to those video guts is asking for problems, it seems to me (now, anyways). Thus, that so-called expansion header won't even be readily accessible, even for Prop enthusiasts.
Now as for the so-called expansion header, what is your preferred pin connectivity? It might be good to provide two answers, one for the current video pin mapping, and one for any totally reworked video pin mapping (not that I'm committing to implementing such a big remapping at such a late date, but I'm willing to listen/consider it). Again, though, the expansion connector won't be readily available in the next version (if, in fact, I release a new version, the releasing of which is still my hope).
As for switches, I'm reluctant to add any since they likely wouldn't be readily accessible. And I don't want to add any switches to the outer periphery of the PCB because there's already a lot of jacks or sockets there now (a total of 7: 4 USB type A jacks, a power jack, a Prop Plug header, and an SD card socket). That makes for a lot of holes (cutouts) in the base, and the new base is quite a bit smaller than the existing base and barely has room for a full-sized SD card socket, which I prefer to a micro SD card one. Early in the design process, I considered having a switch for the Prop Plug back when I was sharing one or two of those high-numbered pins for the SD card. But I felt that was a pretty awkward solution. Well, that's about as best that I can answer for now. Honestly, I'm sort of foggy on why a serial host connection is needed. I have no problem programming and flashing the console for active game develpment. And I use either one or more of the screens or the speaker for debugging. Perhaps there's something that I'm not seeing.
Oh, do you mean a second Prop Plug? Could you elaborate on why a second Prop Plug is needed? *Update* Hmm...I suppose you mean if using the game console as a general purpose Propeller programming rig. I'm definitely not a power user. I've never used more than one Prop Plug with the Propeller. Now, perhaps I can partially see why you're talking about switches.
Oh, you mean like on the Hydra Game System? Gee, that's a great system, but, honestly, I have no plans for this game console to use cartridges. And for the word games it was designed for, it doesn't seem necessary (at least not for most of the kinds that I envision). Besides, providing a cartridge "slot" ups the geek factor and might make the console more scary to non-hardware people. I prefer to just stick with SD cards. Hey, at least I'm not like Apple, as there is an SD card socket on board (though not a cartridge slot).
However, when one mounts the SD card just before calling the boot procedure, that leaves it mounted during the boot from the perspective of the card, doesn't it? Do you think anything could go wrong during the boot process from the SD card standpoint? At the very least, it would seem that the SD card would get mounted twice in succession: once just prior to the boot call and once by the new game program that loads in. I'm assuming that the SD card driver doesn't check the card's status, though perhaps it always does an unmount before mounting just to be safe--need to check. I don't know that a successive mount operation could potentially cause a problem, but I also don't know that it wouldn't (and maybe it depends on the SD card controller chip).