Hmmm... Not sure what's going on but I can only seem to get something to display on screen 0 even though I'm running the same code on all four screens. I guess I'll have to debug this tomorrow. Time to call it quits for the night.
Edit: I left it running for a while and now I see the text I displayed on screens 1 through 3 but shifted right. It seems like the SYNC is messed up on all of the screens except 0. Obviously, I must have broken the VGA driver somehow. Ugh.
I assume that you have an array of VGA screen drivers, such as vga[0], vga[1], etc. (if you're not using an array, then I'd need more info). I usually send text strings to the four screens in a repeat loop from 0 to 3 (or NORTH to EAST if using constants), using the repeat loop index, s for screen or whatever, to identify the screen. Make sure that your screen indicator variable is incrementing, such that you're not writing to the same screen (screen 0) four times in a row (on top of existing text the last three times), as it might update so fast that you wouldn't notice it. By the way, you could program a beep using a debug line to see hear how many times your output line or method is being called. *Important* The output methods that I wrote expect an integer from 0..3 (or possibly 0..4, 4 indicating all screens), not the driver object. So just send in s = 0..3 (or similar), not vga[0] or vga[ s ]. However, if you're not using those output methods or similar ones, then you could use the array syntax directly.
Also, one of the output methods lets one send a single character to all four screens automatically. So you could try that just to see if you can get a single character on all four screens. Then try just the method to output a character to a single screen, but in a loop to test all four screens. If that works, then move on to writing strings, as described above. For example:
repeat s from 0 to 3
write(s, 10, 3, WB, string("Testing Screen:")) 'output a string at column 10, line 3
putChar(s, 26, 3, YB, 48+s) 'output the screen number, 0..3
where, for write(), s=screen number, 10=column, 3=row, WB=white text on a blue background (white-on-blue)
and similar for putChar(), except that 48+s gives a yellow text character on blue from "0".."3"
Hmm...another possibility is that only the first screen has been instantiated. Make sure that you're firing up all four screens in the initialization code (and that you're using separate text buffer areas for each).
David - this risks distraction, but did you know that there's a facebook page for zil (Zork Implementation Language)? There's documentation from Infocom, and tools which you can run under mono.
David - this risks distraction, but did you know that there's a facebook page for zil (Zork Implementation Language)? There's documentation from Infocom, and tools which you can run under mono.
Yes, I know about that facebook page. In fact, I supplied them with some of the ZIL documents they have online. The adventure system I've been talking about in this thread was actually used by Infocom for some later games after they were acquired by Activision/Mediagenic. My system isn't nearly as powerful as ZIL but the compiler can run on pretty much any computer. The ZIL system required a mainframe at the time.
I assume that you have an array of VGA screen drivers, such as vga[0], vga[1], etc. (if you're not using an array, then I'd need more info). I usually send text strings to the four screens in a repeat loop from 0 to 3 (or NORTH to EAST if using constants), using the repeat loop index, s for screen or whatever, to identify the screen. Make sure that your screen indicator variable is incrementing, such that you're not writing to the same screen (screen 0) four times in a row (on top of existing text the last three times), as it might update so fast that you wouldn't notice it. By the way, you could program a beep using a debug line to see hear how many times your output line or method is being called. *Important* The output methods that I wrote expect an integer from 0..3 (or possibly 0..4, 4 indicating all screens), not the driver object. So just send in s = 0..3 (or similar), not vga[0] or vga[ s ]. However, if you're not using those output methods or similar ones, then you could use the array syntax directly.
Also, one of the output methods lets one send a single character to all four screens automatically. So you could try that just to see if you can get a single character on all four screens. Then try just the method to output a character to a single screen, but in a loop to test all four screens. If that works, then move on to writing strings, as described above. For example:
repeat s from 0 to 3
write(s, 10, 3, WB, string("Testing Screen:")) 'output a string at column 10, line 3
putChar(s, 26, 3, YB, 48+s) 'output the screen number, 0..3
where, for write(), s=screen number, 10=column, 3=row, WB=white text on a blue background (white-on-blue)
and similar for putChar(), except that 48+s gives a yellow text character on blue from "0".."3"
Hmm...another possibility is that only the first screen has been instantiated. Make sure that you're firing up all four screens in the initialization code (and that you're using separate text buffer areas for each).
I'm mostly using your code and I do have code like you describe above. I must have broken something though. I had it working on all four screens initially and the clock program works fine so the hardware itself is working. I just have to track down my bug.
I think I'll create a new thread for this AdvSys2 work instead of cluttering up your WordFire thread.
If pressing ESC doesn't take you to the GameMenu program after a fresh power up, then perhaps there's an older version of the GameTime clock program burned into the EEPROM. Could you load up the PropTool with the GameTime.spin program in the GameTime folder on the SD Card I supplied and then burn it into the EEPROM, just so that we know that we're on the same page? Or, if worse comes to worse, I'll send you the file that I'm using just to be sure that we're testing the same thing.
As I mentioned by PM, I don't have access to the latest file versions since my development PC crashed before I backed up, but I just tried the version that I sent to you, and it is working here. It doesn't immediately escape when the GameTime splash screen displays, but does so once the yellow clock screen appears (I'm referring to screen 0/north/blue). Or you can wait until the clock screen appears before pressing escape to load the GameMenu.
Just a heads-up, the GameTime clock program used to let four different keyboards control it independently. But that was unnecessary complexity for little if any added value, so I ripped that functionality out. But I haven't adequately tested it. Still, if you stick to controlling the clock with one keyboard, hopefully it's okay. Anyway, please burn the clock program I sent and let's pick up from there. Feel free to PM me for a back-and-forth on it.
Me, again, David. I know it's just dawn where you're at (as there's a 12-hour time difference between us this time of year). But I was thinking, for your development work, you might want to burn the GameMenu program into the EEPROM. If you're not really using the real-time clock right now (and haven't put a battery in it), then having the GameMenu program boot-up after cycling power would probably be more convenient. From there, you can always load the GameTime clock program if you do want to take a look at it briefly.
Then, you could add your adventure game to the SD card, by creating a folder for it, such as Advent1A and storing Advent1A.spin in the folder. Then, if you create a five-line About.txt file for it in the same directory similar to the format of one of the examples, the GameMenu program will automatically discover the game and show it's name(s) (and the description for it once it's selected). Then you can play/test the game without having to use the PropPlug (and without burning your game permanently into EEPROM). Of course, I realize that for your regular game development, you'll want to use the PropPlug so that you can make frequent changes. But once you hit a milestone (a certain level of progress and stability), you might want to add it to the SD card. Just a thought, something that you would probably do sooner or later.
That sounds like a good idea. I'll put the GameMenu program in the EEPROM so it boots on startup. Actually, this isn't really bothering me as I just load my game using a PropPlug and everything is fine. I just wanted to see what your game menu looked like and maybe try some of the games you sent along with the console.
I got my console today. This thing is just beautiful.
Very nice packaged, everything arrived undamaged. The quality is very good, precise cuts, nice finish, quite thought thru design. The keyboards are also nice and about as small as those PS2 ones Parallax used to sell.
The circuit board is HUGE, it fills the whole bottom, as soon as I can get hold of the right battery I will take it apart for a better look at the inside of the box.
It booted up without problems, even with no keyboards attached yet, the only thing I am missing is a power switch. But since it shows date and time I might let it run anyways.
Since I recently moved into my new House most of my Parallax stuff is still in 2 big boxes, and PropPlugs are so tiny, I had to dig thru the boxes to find one.
One thing I completely missed out on is that I do not have any table where 4 person can sit around, so I need to unclutter, clean and rearrange my Desk to make some space for the console and keyboards.
My first impression is that this is a must have for any Propeller-Nerd,
Yes, it is quite cool. I'm glad there are now at least three of us with these consoles. What are your plans for it? Are you going to be writing a game?
Also, really only the Propeller could do the job in this console. What other MCU can drive four VGA displays at the same time?
I am not sure about my plans with it, yet. I just could not resist to buy it.
The last two years I was busy to buy, fix up and move into my new home and had not much time to do anything with my Parallax stuff. But now live is calming down, I have some time again, no current project and the P2 is still far away from me until Parallax can sell me a module I can use in a Bread Board setup, something like a FLIP with 32 pins down and 32 pins up to plug it into my trusted PPDB.
So I will look at the existing software and figure out how much space is there to do something.
But Battleship could be a nice game and seems doable. Another thought is to connect it to a PC and allow the screens to connect to sockets, 4 telnet clients in a box? One could run software on the PC and just use screens and keyboards in the box.
Jim mentioned that the font has some user definable characters, so maybe it is possible to build a moving player char, PacMan possible?
If one could write a interpreter for the old infocom games like ZORG(?) there would be a lot stuff out in the net, some years ago I looked at doing that, but with a P1 is just not enough memory there to do this.
So I paid Jim the full price, in my opinion it is fully worth $300 and I do not want him to loose money on this endeavor. But I still think about programming a game for it. Just no promise there, life is unpredictable.
One of the first programs I typed into a TRS80, a classic, the moon landing.
The program tells you your current distance, speed, direction and remaining fuel. You enter next amount to burn. Repeat.
at the end it calculates the size of your impact crater.
Someone recently pointed me to a ZIP interpreter for the Propeller. I haven't tried it yet but maybe it could be made to run on the WordFire. However, it would only use one screen. None of the old Infocom games are multi-player.
Thanks for those kind words, Mike (For Mike's eyes only: The check is in the mail). I'm glad that the console arrived intact (Thanks EMS/USPS). It took longer to arrive than I thought it would, almost a week (David's arrived in under 4 days). I think the parcel was held up in Customs for nearly a couple days. Maybe they thought, "What the heck is this?" Oh, just recalled that there was a holiday on Monday. By the way, sorry about not including a square card table and a set of chairs in the box; they just wouldn't fit.
If you want to put a battery in the real-time clock (RTC) module, that video in the first post about the housing tells you how to get inside the core of the console. The battery is the commonly available CR2032. Don't use a rechargeable one; the non-rechargeable one should keep the clock running for months, even if the console is unplugged the whole time (though hopefully that won't be the case).
I do believe that old-style action games like Pac-Man are possible by redefining the font on the fly exactly as you mentioned. Perhaps such are possible entirely in SPIN, but I'm not sure about that. I think the hard thing about doing an action game would be figuring out a way to do a four-player version (whether using competitive or cooperative game play). But I'm sure there's some cool things that could be done. Or maybe it'd be good to think of a new kind of action game that would only work on multiple screens. Anyway, in the beginning, start with something simple, like just putting text on the screens.
Thanks again for letting me/us know that the console arrived safe-and-sound. I had been tracking the parcel's progress (and PM'ed you with updates a couple times). The last I saw, it was through Customs and in a facility in Nor-Cal, which I figured was a day or so away from you by truck. I was just going to track it again, when I saw your post about receiving it. Wonderful, another child out of the nest and off to college.
BTW: My meaning above with respect to the battery is that you can remove the food bowl and the foam "floor" piece and reach a hand down inside the console (see the video). Down in the bowels or engine room, you can just pull out the entire real-time clock (RTC) module (it's socketed/removable), as it may be easier to replace the battery outside the console. When inserting a battery, be sure that it snaps in place (and to remove the battery, just compress the little clip to pop it out, but don't squeeze too hard). Then just insert the RTC module back into its socket, making sure to put it back in the way it came out, which is with the battery facing inwards towards the Prop kind of, *not* outwards towards the adjacent wooden stand wall. That is, the flatter side of the RTC module faces the wooden wall (that's how I remember it, anyway (as the socket is not keyed)).
Of course, if you want to remove the main PCB at some point to explore it or for whatever intent, it would be best to go inside the console as described above and remove all eight driver board cables (4 for VGA and 4 for power) from the main PCB (That is, it's probably best to leave those cables attached to the driver boards to avoid stressing any components on those boards). Then you can remove the four screws on the bottom to remove the PCB along with the entire base from the stand. But when you reassemble the console, be sure to orient the base such that the SD card side is facing the blue side of the cap (assuming you haven't switched the cap with the bezels around). I think there are marking on the top of the stand (on the ends underneath where the foam floor piece rests) to tell you what the directions are (N, W, S and E, anti-clockwise from above). While this is not critical, reassembling the console the way it came apart will help to align the screws with the existing holes, possibly making re-assembly smoother. Anyway, whatever you do while exploring the PCB, please don't remove the flux capacitor that makes time travel possible. Happy tinkering.
Cool! I'll try it later. FYI, I don't think Jim wants us to distribute his drivers so you might want to change the zip file to include only files you've written yourself.
Mike, you're joshing me! You've had the console less than a day and you've already coded a functioning game for it? You don't mess around! It would take me longer than that just to learn the lay of the land and get text on a screen.
Okay, after "piloting" the Lunar Crasher..eh..Lander at least a dozen times, I managed to set it down gently enough not to kill myself (Thankfully, there was plenty of fuel for the starting conditions). Attached is a screen shot as evidence. Note, I took off the bezels to get the shot as they covered the periphery just a bit. Sorry about the moiré pattern; I was too close when I took the shot. I like the colors. Very spacey!
As for distributing my portion of the code, I don't mind your attaching it here for people in the forum. While I haven't made the code open source at this point, it's fine to post it in this forum.
But great work on figuring out how to use the system so blindingly fast. At first, I just downloaded the game with the Prop Plug. But then I did copy the Lander01 folder over to an SD card, and, indeed, it works from there. You suitably included an About.txt file such that the Game Menu program could automatically add it to the list of games on the SD card. Fantastic!
Now, I just need to work on my piloting skills. I noticed that some scenarios are impossible to land (as I burned max fuel in one game but still rammed the moon in an apparent seismic test). And I see that you made it multi-player. I mean, multiple players can play different starting scenarios independently. It's kind of like having four little computers in one device (That would have blown some minds in the early '80's).
Anyway, playing that old-style text game was fun for me, as was testing David's work, as those are the first times I've played anything on the console that wasn't written by me. Thanks, Mike and David.
You are right that 200 max fuel is too less, I upped it up already to 250 for the next version.
Currently up to 4 player can play complete independent from each other with randomized starting height. But now we need competitive or cooperative game play, I guess here competitive might work. some sort of High-Score List and nick-names.
Not sure how to rank them, trials vs fails? Starting height vs time needed (fastest landing)?
Anyways, Jim I am really happy about playing with Spin again.
Anyways, Jim I am really happy about playing with Spin again.
I'm really pleased that you're playing with Spin, too.
As for game modes, there could obviously be a cooperative play option that let players take turns, where everyone viewed the same screen info. While such a mode doesn't really require four screens, it still could be interesting.
Then, in line with what you've already wrote, players could play independently, but probably should all start with the same initial conditions. And you might want to add a timer to add some suspense. If a player didn't input anything within the time interval, then you could use the last burn rate for that player. In this mode, the players screens would show differing data.
Then, there could be another independent mode as in the foregoing but where the screens showed what each player was doing, as it'd be cool if all players could monitor the progress of the other players. One might be going too fast, another too slowly. Again, you'd probably want to introduce a timer to move things along and discourage copying. And you might prevent players from inputting burn rates within a certain percent, say 25%, of what any other players had already played (as there would be no turns as such). That would be an incentive not to wait and watch what other players did and then copy or adjust from there.
Sorry, I'm just stating some of the more obvious possibilities; there are no doubt others. And one thing can lead to the next in the creativity process.
I don't know if you meant persistent high scores, but I think I'd focus on the playing modes first. But high scores do bring back thoughts of arcade machines. To be honest, I don't write anything to the SD card during play, just read it, as I don't 100% trust the writing process. Hopefully, it's reliable enough, but I just haven't tried it yet. And if something did go wrong, one could just burn a copy of the SD card image back to the SD card after a quick format. I suppose a 64 KB EEPROM could be used for high scores (or game state), too, but I just included a 32 KB one (as that's all I could find locally without ordering).
Anyway, adding some multi-player options to this old-style game could give it a new twist. That's cool. I hadn't thought of that. I've thought mostly about word games, but it seems that there are lots of other possibilities. Thanks for working on one...and on Day-1. Incredible!
Here is a folder for my adventure game that you can put on your SD card so you can select the game from the menu. There is something wrong with the About.txt file though since only two lines appear in the lower window when MAdvent is selected. I have the same number of lines as the WordFire About.txt file so I'm not sure what's going wrong. I haven't included sources because they're on GitHub.
I finally got around to installing the CR2032 battery in the RTC module. It was quite easy and now I have a clock that displays the correct time! You really did a nice job with this console!
I'm wondering if the missing lines in my About.txt file are due to the fact that the Mac only puts \n at the end of each line. The About.txt files that were on the SD card that came with the WordFire console all have \r\n line endings. Could the GameMenu program be made to handle either type of line ends?
@David: You got the RTC battery installed. That's good. I'm surprised that you said that the process was "quite easy" considering that one has to get into the "guts" of the console. No, it's not hard, but opening the "hood" can be dauting. I'm glad the process went well.
I added your folder with the About.txt file to an SD card and can now see your game listed in the Game Menu program, though, like you said, some of the description is missing (see below). I then play tested again your updated version. I see that the cat is back in the pantry again. And I could have sworn that I slew the dragon that's in the closet.
About the missing text lines from the About.txt file for the description, I'm sure that you're right about it being related to the Mac using just the LF character to terminate lines instead of Window's CRLF pair. As I recall, when Kye's driver fetches a string off the SD card, it stops on either the CR character or the LF character. I probably assumed that both were present. I'll try to look into that to see if the Game Menu program can be easily modified to handle both formats.
@All: Okay, I added a line to the Game Menu program to try to handle text files with lines terminated in either LF or CRLF (though I just read something about older Macs just using the CR character, which I didn't code for). Anyway, the change seems to work, or at least it shows all four lines of the description for David's About.txt file.
BTW, while editing on my laptop (as I've at least temporarily lost access to my desktop "development" PC with the latest file versions), I noticed that the infrared remote control reader object file was missing from the GameMenu folder, such that it wouldn't compile. This is probably the case with the version I sent out on SD cards with shipped consoles. Sorry about that. The following zipped folder has the missing object along with the modified Spin file. You'll want to replace the existing GameMenu folder with this one.
Jim, you are right, writing the SD causes corruption, you are using a quite old version of Kye's drivers, the newer FAT_ENGINE does work with RT-Clocks for date modified etc.
The current versions do work but leave the modified date empty thus windows complains about a corrupt card. Its not damaged, just dateless...
So I have to search for the newer version of FAT_Engine and prune it to shorten the size. Right now my code is working fine, except the missing dates. The older version you use has also problems creating and deleting files, something I currently get along with thru creating all needed files upfront on the PC. For now I stay with the provided driver.
After some fiddling with the vga object to return the screen address I am quite happy to report progress!
One thing I have build is to save and restore complete screens. This comes in quite handy to display things like Help Screens, just save current screen, display what you want and restore current screen.
This lead to the ability to just load screens from file instead of writing them in code, a big win with the small memory footprint.
This lead to the ability of displaying a Window from a much larger Screen-Map into some area of the existing screen memory.
Now I can scroll thru a Map-File on SD, independent for every screen, this will come in handy for Map based games but also to just display text info hold in text files.
I am rewriting Lander01 to separate game-code from system code, WFsystem is the only object a game needs to import, Slowly this gets very neat, simple and easy to use.
But - hey there is a squirrel - I got distracted by that Map possibility and will write a small Map-Editor, to check this out...
Comments
Edit: I left it running for a while and now I see the text I displayed on screens 1 through 3 but shifted right. It seems like the SYNC is messed up on all of the screens except 0. Obviously, I must have broken the VGA driver somehow. Ugh.
Also, one of the output methods lets one send a single character to all four screens automatically. So you could try that just to see if you can get a single character on all four screens. Then try just the method to output a character to a single screen, but in a loop to test all four screens. If that works, then move on to writing strings, as described above. For example:
repeat s from 0 to 3 write(s, 10, 3, WB, string("Testing Screen:")) 'output a string at column 10, line 3 putChar(s, 26, 3, YB, 48+s) 'output the screen number, 0..3where, for write(), s=screen number, 10=column, 3=row, WB=white text on a blue background (white-on-blue)and similar for putChar(), except that 48+s gives a yellow text character on blue from "0".."3"
Hmm...another possibility is that only the first screen has been instantiated. Make sure that you're firing up all four screens in the initialization code (and that you're using separate text buffer areas for each).
I think I'll create a new thread for this AdvSys2 work instead of cluttering up your WordFire thread.
As I mentioned by PM, I don't have access to the latest file versions since my development PC crashed before I backed up, but I just tried the version that I sent to you, and it is working here. It doesn't immediately escape when the GameTime splash screen displays, but does so once the yellow clock screen appears (I'm referring to screen 0/north/blue). Or you can wait until the clock screen appears before pressing escape to load the GameMenu.
Just a heads-up, the GameTime clock program used to let four different keyboards control it independently. But that was unnecessary complexity for little if any added value, so I ripped that functionality out. But I haven't adequately tested it. Still, if you stick to controlling the clock with one keyboard, hopefully it's okay. Anyway, please burn the clock program I sent and let's pick up from there. Feel free to PM me for a back-and-forth on it.
Then, you could add your adventure game to the SD card, by creating a folder for it, such as Advent1A and storing Advent1A.spin in the folder. Then, if you create a five-line About.txt file for it in the same directory similar to the format of one of the examples, the GameMenu program will automatically discover the game and show it's name(s) (and the description for it once it's selected). Then you can play/test the game without having to use the PropPlug (and without burning your game permanently into EEPROM). Of course, I realize that for your regular game development, you'll want to use the PropPlug so that you can make frequent changes. But once you hit a milestone (a certain level of progress and stability), you might want to add it to the SD card. Just a thought, something that you would probably do sooner or later.
Very nice packaged, everything arrived undamaged. The quality is very good, precise cuts, nice finish, quite thought thru design. The keyboards are also nice and about as small as those PS2 ones Parallax used to sell.
The circuit board is HUGE, it fills the whole bottom, as soon as I can get hold of the right battery I will take it apart for a better look at the inside of the box.
It booted up without problems, even with no keyboards attached yet, the only thing I am missing is a power switch. But since it shows date and time I might let it run anyways.
Since I recently moved into my new House most of my Parallax stuff is still in 2 big boxes, and PropPlugs are so tiny, I had to dig thru the boxes to find one.
One thing I completely missed out on is that I do not have any table where 4 person can sit around, so I need to unclutter, clean and rearrange my Desk to make some space for the console and keyboards.
My first impression is that this is a must have for any Propeller-Nerd,
Enjoy!
Mike
Also, really only the Propeller could do the job in this console. What other MCU can drive four VGA displays at the same time?
The last two years I was busy to buy, fix up and move into my new home and had not much time to do anything with my Parallax stuff. But now live is calming down, I have some time again, no current project and the P2 is still far away from me until Parallax can sell me a module I can use in a Bread Board setup, something like a FLIP with 32 pins down and 32 pins up to plug it into my trusted PPDB.
So I will look at the existing software and figure out how much space is there to do something.
But Battleship could be a nice game and seems doable. Another thought is to connect it to a PC and allow the screens to connect to sockets, 4 telnet clients in a box? One could run software on the PC and just use screens and keyboards in the box.
Jim mentioned that the font has some user definable characters, so maybe it is possible to build a moving player char, PacMan possible?
If one could write a interpreter for the old infocom games like ZORG(?) there would be a lot stuff out in the net, some years ago I looked at doing that, but with a P1 is just not enough memory there to do this.
So I paid Jim the full price, in my opinion it is fully worth $300 and I do not want him to loose money on this endeavor. But I still think about programming a game for it. Just no promise there, life is unpredictable.
Enjoy!
Mike
One of the first programs I typed into a TRS80, a classic, the moon landing.
The program tells you your current distance, speed, direction and remaining fuel. You enter next amount to burn. Repeat.
at the end it calculates the size of your impact crater.
Need to google a bit,
Mike
If you want to put a battery in the real-time clock (RTC) module, that video in the first post about the housing tells you how to get inside the core of the console. The battery is the commonly available CR2032. Don't use a rechargeable one; the non-rechargeable one should keep the clock running for months, even if the console is unplugged the whole time (though hopefully that won't be the case).
I do believe that old-style action games like Pac-Man are possible by redefining the font on the fly exactly as you mentioned. Perhaps such are possible entirely in SPIN, but I'm not sure about that. I think the hard thing about doing an action game would be figuring out a way to do a four-player version (whether using competitive or cooperative game play). But I'm sure there's some cool things that could be done. Or maybe it'd be good to think of a new kind of action game that would only work on multiple screens. Anyway, in the beginning, start with something simple, like just putting text on the screens.
Thanks again for letting me/us know that the console arrived safe-and-sound. I had been tracking the parcel's progress (and PM'ed you with updates a couple times). The last I saw, it was through Customs and in a facility in Nor-Cal, which I figured was a day or so away from you by truck. I was just going to track it again, when I saw your post about receiving it. Wonderful, another child out of the nest and off to college.
Of course, if you want to remove the main PCB at some point to explore it or for whatever intent, it would be best to go inside the console as described above and remove all eight driver board cables (4 for VGA and 4 for power) from the main PCB (That is, it's probably best to leave those cables attached to the driver boards to avoid stressing any components on those boards). Then you can remove the four screws on the bottom to remove the PCB along with the entire base from the stand. But when you reassemble the console, be sure to orient the base such that the SD card side is facing the blue side of the cap (assuming you haven't switched the cap with the bezels around). I think there are marking on the top of the stand (on the ends underneath where the foam floor piece rests) to tell you what the directions are (N, W, S and E, anti-clockwise from above). While this is not critical, reassembling the console the way it came apart will help to align the screws with the existing holes, possibly making re-assembly smoother. Anyway, whatever you do while exploring the PCB, please don't remove the flux capacitor that makes time travel possible. Happy tinkering.
Just copy the folder "Lander01" in the attached zip onto your WordFire SD and Lunar Lander 01 will show up in the Game Menu.
It is a breeze to program the WordFire, but the attached code needs serious refactoring, its clobbered together.
I need to look thru the samples, it could use some high-score list ...
Enjoy!
Mike
Okay, after "piloting" the Lunar Crasher..eh..Lander at least a dozen times, I managed to set it down gently enough not to kill myself (Thankfully, there was plenty of fuel for the starting conditions). Attached is a screen shot as evidence. Note, I took off the bezels to get the shot as they covered the periphery just a bit. Sorry about the moiré pattern; I was too close when I took the shot. I like the colors. Very spacey!
As for distributing my portion of the code, I don't mind your attaching it here for people in the forum. While I haven't made the code open source at this point, it's fine to post it in this forum.
But great work on figuring out how to use the system so blindingly fast. At first, I just downloaded the game with the Prop Plug. But then I did copy the Lander01 folder over to an SD card, and, indeed, it works from there. You suitably included an About.txt file such that the Game Menu program could automatically add it to the list of games on the SD card. Fantastic!
Now, I just need to work on my piloting skills. I noticed that some scenarios are impossible to land (as I burned max fuel in one game but still rammed the moon in an apparent seismic test). And I see that you made it multi-player. I mean, multiple players can play different starting scenarios independently. It's kind of like having four little computers in one device (That would have blown some minds in the early '80's).
Anyway, playing that old-style text game was fun for me, as was testing David's work, as those are the first times I've played anything on the console that wasn't written by me. Thanks, Mike and David.
You are right that 200 max fuel is too less, I upped it up already to 250 for the next version.
Currently up to 4 player can play complete independent from each other with randomized starting height. But now we need competitive or cooperative game play, I guess here competitive might work. some sort of High-Score List and nick-names.
Not sure how to rank them, trials vs fails? Starting height vs time needed (fastest landing)?
Anyways, Jim I am really happy about playing with Spin again.
Enjoy!
Mike
I'm really pleased that you're playing with Spin, too.
As for game modes, there could obviously be a cooperative play option that let players take turns, where everyone viewed the same screen info. While such a mode doesn't really require four screens, it still could be interesting.
Then, in line with what you've already wrote, players could play independently, but probably should all start with the same initial conditions. And you might want to add a timer to add some suspense. If a player didn't input anything within the time interval, then you could use the last burn rate for that player. In this mode, the players screens would show differing data.
Then, there could be another independent mode as in the foregoing but where the screens showed what each player was doing, as it'd be cool if all players could monitor the progress of the other players. One might be going too fast, another too slowly. Again, you'd probably want to introduce a timer to move things along and discourage copying. And you might prevent players from inputting burn rates within a certain percent, say 25%, of what any other players had already played (as there would be no turns as such). That would be an incentive not to wait and watch what other players did and then copy or adjust from there.
Sorry, I'm just stating some of the more obvious possibilities; there are no doubt others. And one thing can lead to the next in the creativity process.
I don't know if you meant persistent high scores, but I think I'd focus on the playing modes first. But high scores do bring back thoughts of arcade machines. To be honest, I don't write anything to the SD card during play, just read it, as I don't 100% trust the writing process. Hopefully, it's reliable enough, but I just haven't tried it yet. And if something did go wrong, one could just burn a copy of the SD card image back to the SD card after a quick format. I suppose a 64 KB EEPROM could be used for high scores (or game state), too, but I just included a 32 KB one (as that's all I could find locally without ordering).
Anyway, adding some multi-player options to this old-style game could give it a new twist. That's cool. I hadn't thought of that. I've thought mostly about word games, but it seems that there are lots of other possibilities. Thanks for working on one...and on Day-1. Incredible!
I added your folder with the About.txt file to an SD card and can now see your game listed in the Game Menu program, though, like you said, some of the description is missing (see below). I then play tested again your updated version. I see that the cat is back in the pantry again. And I could have sworn that I slew the dragon that's in the closet.
About the missing text lines from the About.txt file for the description, I'm sure that you're right about it being related to the Mac using just the LF character to terminate lines instead of Window's CRLF pair. As I recall, when Kye's driver fetches a string off the SD card, it stops on either the CR character or the LF character. I probably assumed that both were present. I'll try to look into that to see if the Game Menu program can be easily modified to handle both formats.
BTW, while editing on my laptop (as I've at least temporarily lost access to my desktop "development" PC with the latest file versions), I noticed that the infrared remote control reader object file was missing from the GameMenu folder, such that it wouldn't compile. This is probably the case with the version I sent out on SD cards with shipped consoles. Sorry about that. The following zipped folder has the missing object along with the modified Spin file. You'll want to replace the existing GameMenu folder with this one.
The current versions do work but leave the modified date empty thus windows complains about a corrupt card. Its not damaged, just dateless...
So I have to search for the newer version of FAT_Engine and prune it to shorten the size. Right now my code is working fine, except the missing dates. The older version you use has also problems creating and deleting files, something I currently get along with thru creating all needed files upfront on the PC. For now I stay with the provided driver.
After some fiddling with the vga object to return the screen address I am quite happy to report progress!
One thing I have build is to save and restore complete screens. This comes in quite handy to display things like Help Screens, just save current screen, display what you want and restore current screen.
This lead to the ability to just load screens from file instead of writing them in code, a big win with the small memory footprint.
This lead to the ability of displaying a Window from a much larger Screen-Map into some area of the existing screen memory.
Now I can scroll thru a Map-File on SD, independent for every screen, this will come in handy for Map based games but also to just display text info hold in text files.
I am rewriting Lander01 to separate game-code from system code, WFsystem is the only object a game needs to import, Slowly this gets very neat, simple and easy to use.
But - hey there is a squirrel - I got distracted by that Map possibility and will write a small Map-Editor, to check this out...
So no updates/files right now, but soon...
Enjoy!
Mike