Perhaps Quby could do that intercommunication now (with some programming work on the host and slave ends) with what's already been provided with the expansion pads. However, I don't want to go down this path too far and derail things as in the other thread. As for games that will work on the console, I have more ideas than time to develop them. On the one hand, the potential for word games seems unlimited; but on the other hand, there are limits. It's kind of like how there are different "sizes" of infinity. While some of the complex games you may be interested in wouldn't work, I have many ideas for word games that will work just fine on the console (and some games that are not word-based will work, too). Hopefully, this thread can focus on games for the console, so, if and when I come up with anything new, I'll try to post an announcement here. I hope that you folks will, too.
Yes, there are lots of games that would work well on the console without any expansion. I only mentioned adding an additional processor as one option that would present itself if a few extra pins were available. As you say, that may already be possible with the existing console with some clever use of shared pins. Like you though, I haven't yet been blocked by lack of space on the Propeller itself. There is lots that can be done without any expansion.
I wrote some simple C driver interface code for WordFire and Cuby and used it to start a port of my game "Monsta!" to the WordFire/Cuby console. The sources are here:
This contains everything you need to build the game but you'll need to have PropGCC installed and openspin. I've included the Spin source code for the quad vga driver but it only includes a binary form (actually, an initialized C array) of the quad keyboard driver. The source for that driver is included in the code that comes with the WordFire/Cuby console. I've attached a .binary file here in case anyone wants to try it.
It is a maze game using a randomly generated maze. The interior walls of the maze are initially hidden but you discover them by moving around with the arrow keys. When you try to move in the direction where there is a wall, you bump into the wall and the wall becomes visible. There is a goal location that you are trying to reach and there is a monster who is trying to eat you. You have to reach the goal before the monster eats you to win the game. You can pick up various objects along the way. A club will allow you to beat the monster away once and a bomb will let you set a trap for the monster and will also blast away some of the maze walls maybe making it easier for you to reach the goal.
Here are the playing instructions:
The maze is represented with the following ASCII characters:
X is a wall
P is the player
M is the monster
! is a club that you can pick up
b is an inactive bomb that you can pick up
B is an active bomb that you've dropped
? is a randomizer
. is a player footprint
The following keys control the game:
UP/DOWN/LEFT/RIGHT move the player in the corresponding direction
D drops a bomb and makes it active
c cheats by unhiding the randomizers
C cheats by unhiding the randomizers and the maze walls
B enters beginner mode the next time a game is started
S starts a game when one is not already in progress
Q quits the game currently in progress
Also, it is only a single-player game at present and uses only one keyboard and screen. I plan to display the maze on all four screens at the same time and let all four players discover the maze and each other. I might even try to figure out a way to make the game cooperative.
I'm also looking for some help. You'll see that I just use ASCII characters to display the maze and its contents. I'd like to design custom characters for this but I'm not sure how to do that. Anyone know how to create custom characters for the WordFire VGA driver?
Cool! Does "Schloorp" mean that the monster ate me? Seems like the sound that one of those Jello shots makes going down the hatch. Whatever it means, it can't be good. I guess I was "mashed" by the Monsta (I did the Monsta mash).
As for defining custom characters, there's an article with an example of how to do that under the Docs tab of the project website called "Redefining Font Characters." That'll probably give you everything you need and more than you want (no one ever accused me of being succinct) to redefine characters.
BTW, based on member concerns about the exposed base, I have provisionally (see caveat below) added a piece of EVA foam to the console base. It replaces the rubber feet. If one doesn't look super closely, the console looks the same when standing upright as it did with the four rubber feet (since the foam doesn't extend to the very edges). The foam not only insulates the bottom of the PCB (with its protruding pointy leads) from whatever surface it's sitting on but also protects that surface from scratches. This particular foam is 6 mm thick, but I think a thickness of 5 mm would suffice. The foam does come in colors other than Model-T black (at a higher cost), but I figured that other colors would be much more noticeable around the edges of the base.
Prior to applying the foam, I tried just using PP plastic and also using a thick, transparent rubbery sheet. However, I think I like this foam solution the best because the four screw heads that attach the base to the stand compress the foam to recess within it such that they won't scratch the surface that the console is used on, dispensing with the need for the four rubber feet. However, the foam does noticeably muffle the sound level from the speaker, so I'm not sure yet if I'll really go this route. But maybe some small sound holes in the stand would restore the volume level. Alternatively, I might just enclose the whole PCB someday, but I like the simplicity of the current design.
On a related note, I'm working on--or at least toying with--an alternative version of the Quby PCB, and I'm giving some thought to putting a battery receptacle for a real-time clock on (or accessible from) the bottom of the base without needed to detach the base to access the battery. I'd likely have to dispense with the RTC module to do that, though, and just solder on an RTC chip. I've also considered giving up the clock functionality to simplify things, though, so far, I haven't made any decision to jettison it. Or maybe I'll just keep it like it is, as one rarely needs to change the battery (I've never had to change one, and I don't usually keep the console plugged in when not in use for games).
Got a "Victory" message while playing Monsta (after revealing almost all of the maze's walls to get to the goal location). Yes, using a solid block for the walls would double my enjoyment playing the game, as the current 'X' character for the walls just doesn't seem to resonate with my dense brain. You could even use a solid block character for the walls. To do that, you'd either redefine a single font character to be solid (such as either font character 0 or 1, though 0 can't be used in string functions) or, of course, you could just output a reverse video blank character, though that would take special processing by your output routine to invert the colors when fed an 'X' character from your map.
Also, rather than talking about a goal location, perhaps you could call it the treasure. Perhaps the treasure could even be visible (or visible at times), and maybe it could move around from time to time. Making the goal something "tangible" rather than just a location seems more intuitive. Or maybe you envision the goal location being a portal to another maze, but a treasure indicator could do that, too. Rather than being treasure, it could be a teleportation device or similar. Anyway, I'd get the solid walls coded first, then maybe consider a (possibly movable) treasure (or teleporter device).
As mentioned above, if a character with the ASCII value of 0 doesn't work for your normal text handling, then just assign the wall character to be character 1. Besides, as shown in the example code from the document on the website, it's typical to redefine a pair of characters at a time (due to the interleaving of the Propeller Font). Also, as I've mentioned somewhere, it's usually faster output-wise to have a solid blank character in one's redefined font than using inverse video. It allows one to output a whole string of characters in the same color without having to use inverse video to write or overwrite the space character(s) when a solid blank is needed.
David, in fact I now see that the example from the webpage probably gives you exactly what you'd need for solid walls by outputting an ASCII 0x01 for a solid blank (and you could ignore the truncated underscore character at ASCII 0x00):
DAT
user_font 'beginning address of user's custom font data
'shortened underscore solid block (inverse space)
C00_01 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%22222222_22222200 >< 32 + %%11111111_11111111 >< 32
long %%22222222_22222200 >< 32 + %%11111111_11111111 >< 32
long %%22222222_22222200 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32
And you could redefine additional characters similarly to be the monster and so on. By the way, the coding technique used for redefining the font comes from Roger Williams.
For the font character being redefined on the right, use 1's to define the "lit up" pixels in the foreground color, and for the character on the left, use 2's. For either the character on the left or right, use 0's for "un-lit" pixels in the background color. Easy-peasy. Thanks, Roger! Each redefined character does consume 64 bytes for the font data, so I try to limit myself to 16 characters or less. But I did redefine all of the first 32 characters once for a special font for large numbers, but that ate a lot of the HUB memory.
Thanks for this information. It looks pretty easy. BTW, I changed the walls to 'O' instead of 'X' and that seems to be a bit better. This is a game that people were playing back in the 80's I think on VT100 terminals connected to DEC VAX computers. I wrote a C version back then and this is still pretty much the same code. All I did was interface it to your drivers. Yes, "Schloorp" means you were eaten by the monster. I should put that in the documentation. All of these strings came from the original game. It was a bit more challenging on the VT100 terminal though since it supported 80x24 characters.
Nice history. Yeah, 80x24 would be a lot more complex than 40x15 (or 38x13). Although redefined font characters could double the resolution to 80x30 for the maze walls by dividing a font character into quadrants (with 16 possible block patterns = 16 redefined characters), doing the other objects (player, Monsta, bombs and so on) would be hard to say the least. So, it's probably best to keep it at 16x32-pixel characters rather than quadrants (and normal-sized characters would allow for better looking "icons" for the other things). And if any complications are needed, one could create a couple of doorways (like portals) between, say, three planes of mazes.
Hmm...rather than three planes of mazes, why not take advantage of all four screens and initially plot a different maze on each screen and connect them together via tunnels or portals. Up to four players could start out, each in his or her own maze. But then each player could independently move to another maze as desired. Although the views of the mazes wouldn't be locked together (that is, one player moving to another maze wouldn't change the mazes that the other players were in), each player could see when another player entered the same maze that he or she was in, something like that. This would still allow for single-player play, but the overall maze would be 4X as complex. And it would be kind of cool to peek around and see the other mazes. So, if just one player were playing, then maybe the four mazes could rotate when a player left one maze for another, if using tunnels, that is (not sure about portals); however, as mentioned, I don't think I'd "lock" the mazes together like that (in rotation) if more than one player were playing. Yeah, anyway, it'd definitely be good to take advantage of all four screens somehow, and that should more than make up for the col-row resolution only being 40x15.
Something like the foregoing perhaps could also work quite well for something in the vein of Pac-Man. Hey, maybe I was wrong about fill-in-the-blank word games being the killer app for the console. Quad-Screen Pac-Man could become the rage, like 3D chess. Okay, 3D chess never really panned out, but Quad-Man anyone? In such a version, maybe the ghosts would be confined to a single maze. Or not. Anyway, being able to redefine the font characters on the fly could allow for smooth animation for something like that without having to resort to a custom video driver. I guess one would have to dedicate two font characters to each pac-man or ghost (like a sprite), that way they could smoothly appear to "slide" over the text character boundaries, whether horizontally or vertically (but not diagonally). Anyway, taking advantage of the four screens could add an interesting dynamic, whether for Pac-man or Monstra.
BTW, based on member concerns about the exposed base, I have provisionally (see caveat below) added a piece of EVA foam to the console base. It replaces the rubber feet. If one doesn't look super closely, the console looks the same when standing upright as it did with the four rubber feet (since the foam doesn't extend to the very edges). The foam not only insulates the bottom of the PCB (with its protruding pointy leads) from whatever surface it's sitting on but also protects that surface from scratches. This particular foam is 6 mm thick, but I think a thickness of 5 mm would suffice. The foam does come in colors other than Model-T black (at a higher cost), but I figured that other colors would be much more noticeable around the edges of the base.
Prior to applying the foam, I tried just using PP plastic and also using a thick, transparent rubbery sheet. However, I think I like this foam solution the best because the four screw heads that attach the base to the stand compress the foam to recess within it such that they won't scratch the surface that the console is used on, dispensing with the need for the four rubber feet. However, the foam does noticeably muffle the sound level from the speaker, so I'm not sure yet if I'll really go this route. But maybe some small sound holes in the stand would restore the volume level. Alternatively, I might just enclose the whole PCB someday, but I like the simplicity of the current design.
On a related note, I'm working on--or at least toying with--an alternative version of the Quby PCB, and I'm giving some thought to putting a battery receptacle for a real-time clock on (or accessible from) the bottom of the base without needed to detach the base to access the battery. I'd likely have to dispense with the RTC module to do that, though, and just solder on an RTC chip. I've also considered giving up the clock functionality to simplify things, though, so far, I haven't made any decision to jettison it. Or maybe I'll just keep it like it is, as one rarely needs to change the battery (I've never had to change one, and I don't usually keep the console plugged in when not in use for games).
For what it's worth, I never use the clock. I wouldn't mind if it disappeared.
Hmmm... I suppose the "><" Spin operator reverses the bits of a value? Unfortunately, C doesn't have that operator.
That's too bad. Guess you'll have to manually sort things out. However, you could write a small program to generate the data for you based on just using 0's and 1's to draw one or two characters. But I guess redefining font characters is not something that you need often. Hmm...couldn't you just use SPIN and the Prop Tool and then copy-and-paste the hex from the binary or something like that? You might want to place a marker of some sort before the desired part to help you find it.
By the way, quoting you in full just now is one of the few times that I've quoted someone without weeding out all the chaff (paring down the quote to the salient part I'm commenting on). I think the thread looks better that way.
For what it's worth, I never use the clock. I wouldn't mind if it disappeared.
There I go again fully quoting someone. But about your use of the clock, I figured as much. I also guess that you haven't made much use of the speaker, too. But that will likely change at some point. Anyway, although the clock gives the console a second function, it could go bye-bye, as the console is principally a game machine. Then again, if the clock could help market the console, perhaps it's worth saving. I'm not sure. I seem to be on a path to simplifying things, so I'm more willing to let go of "sacred cows." Of course, these days, lots of systems can get the time from the net. Also, people have plenty of options for getting the time (though few in the "Big Ben" format). Anyway, maybe I could make the clock an "optional extra," though the PCB and console would still have to accommodate it. Speaking of time, it's hard for us to give up things we've put time into developing, even if they are holding us back. We get attached and have a hard time letting go and hang on too long. That's human nature. Thanks for the feedback.
I think the clock is useful when you write to the SD as I do.
Good point. I also think the speaker is a good feature. I can't imagine a game machine that doesn't have any sound capability. I would certainly keep the speaker.
Yeah, either entering a mirrored version or writing a simple program are both possible solutions. Right now I have to figure out why my color palette isn't working though.
Do you mean the backlight or the pixels? Either way, no, not from software, anyway (or at least not without flicker or some kind of dithering). There are a maximum of eight fixed colors available, one bit per color channel (for red, green and blue). For example, red is either on or off, regardless of the presence of green and blue. There's no in-between shades of red, like pink. It's basically saturated. Yellow combines red and green and omits blue, but there's just one yellow intensity. And so on. You likely realize all of that, so I may be missing something. To my knowledge, there are no ways for the system to signal the driver boards to effect any changes in the way that the pixels are output to the screens or the backlights are powered.
Oh! If you really just mean the display brightness (and contrast, etc.), then the answer is a qualified "no." No, the game console hasn't provided for adjusting those, but, yes, it's possible if one has a little optional keypad that attaches to the side of a driver board. With that, there's a on-screen menu system (OSD?) that one can get into to, for example, set the contrast, brightness and screen orientation. But those keyboards are optional accessories when purchasing driver boards and they weren't designed into the game console, nor was one or more provided with the system. Is there some problem with the brightness? A keypad could be fabricated (it's just switches), but it would need a PH2 cable or some carefully placed jumper wires to connect with the driver board to make adjustments. And if need be, I believe I have a spare keypad that could be sent to you.
Now, it might also be possible to wire in the IR detector to the keypad header of the driver boards, but I haven't tried that. I do know that some keypads I've seen in the past for other screens could control the OSD via an IR remote control. And I'm almost for sure that that's a standard feature of the driver board's main chip. But the keypads that I have don't have the IR detector diode on them (nor even pads for one to my knowledge), but I'll bet there's a line for one in the PH2 cable. By the way, the driver boards are also capable of displaying composite video, but that needs to be selected with the keypads (or a remote control). When I setup the console, I use a keypad to set the driver boards for VGA, widescreen stretched over 800 pixels horizontally. I change the screen orientation for your version of the console, too. Anyway, I believe that these settings must be stored in non-volatile memory within the Realtek video chip, since the settings persist over power cycles. And I've never seen the setting change on their own or revert back to the original settings, fortunately. As for the brightness and contrast, I don't touch those when I set up the screens. Are you saying that the screens too hot, brightness-wise? Are they burning in your eyeballs? Are they burning in the screens??? What's up? I'm doing a lot of guessing here.
The only other possibly related thing I can think of is that I use 180 Ohm resistors as the video DAC's. I used to use higher values, but the colors were muddier. For example, the red was more brownish. It's been a long time since I've done the calculations, but maybe things are being driven a bit too hot, though I never investigated that or considered that before, probably because things looked fine to me visually. But I suppose it's a possibility. I've been working all night and am not in good shape to think about it now, but it would be nice to know why you want to adjust the screen brightness (assuming that's what you want to do) or what problem you're experiencing (assuming that you're experiencing a problem). Anyway, hopefully, the above info. should give you something to chew on before I crash and burn for a while before needing to go out later today. I must say, you're scaring me. Hope things work out. I'll be around for at least a few more minutes.
Not in this console, anyway. The two monitor sensing pins are unconnected on my board (and maybe even on the driver board (not sure, need to check)), and I don't know if they can be used for other kinds of communications. I doubt that the driver boards use them for anything like that (if they're even connected). And while the manual for the Realtek chip that the driver boards use is thick, I kind of doubt that the RGBHV lines can be used to send settings, though I could be wrong. Maybe, but probably not, as I think that Realtek (and the driver board maker) assume that people will control the video chip through an attached keypad. If you'd like such a keypad, I could send you one gratis. Using one does require taking off the head cap with the bezels and then connecting the cable into the side of the driver board you want to adjust. On your version of the console, hopefully, I cut the wood of the underlying head frame such that there's just enough space to plug in the connector such that the driver board itself (or screen plus driver board combo) doesn't have to be removed. On Quby, the newer version of the console, accessing/removing the screens is easy once the top is removed. But getting to the driver boards is still pretty doable on your version, and perhaps you've been in there already to have a look. Anyway, let me know if you want me to send a keypad and cable.
If you'd like such a keypad, I could send you one gratis.
No need for that. I can probably address the problem by just choosing colors with high contrast. I just wondered it if was possible to adjust the display parameters programmatically.
Black text seems to get partially "swallowed" by a bright background. It's still legible and usable, but not the best combination. I'm not sure if that's due to the human eye or the LCD's, but I would guess the latter. Generating black means that the filters/shutters on the RGB sub-pixels have to block the backlight, and I think light escapes/leaks around (in addition to through) the filters to make black text a bit narrower.
Anyway, I think one of the most readable or striking combinations is white text on blue. That was used on the Atari, I believe, and it looks even better on VGA screens. Also, the Parallax font is three pixels wide and is quite legible. White text on red is also quite readable. White or green on black work well, too, but you might prefer to have some color in the background. For the players of the CopyCats game, the following are used: [north] white-on-blue, [west] black on yellow, [south] white on red, and [east] black on green. But that's just for one line of text at a time.
From the videos section of the website, the following one-minute video (with longer versions also available) shows a variety of color combinations at work/play:
That video was made for your version of the console with the snack bowl, but I think that everything else still applies. Hopefully, you'll find a color combination that will work for your particular application.
White on blue does look much better. Thanks for the suggestion!
White on green also looks very good. That and blue/white was what I used back in the EGA days when I spent a lot of time in front of a monitor. Much easier on the eyes than any other combinations.
White on blue does look much better. Thanks for the suggestion!
White on green also looks very good. That and blue/white was what I used back in the EGA days when I spent a lot of time in front of a monitor. Much easier on the eyes than any other combinations.
Now that I have the contrast problem resolved I need to create some custom characters to for my game pieces. Should be pretty easy. I had some designed for version of this game that I wrote for another platform that I can probably adapt.
I see what's making me think I have a brightness problem. It seems that display 3 is significantly dimmer than the others. The white on blue text works great with displays 0-2 but the background is too dark on display 3. Any idea why that might be? Also, the white characters look yellow. The odd thing is that it's just as bright as the others when it is displaying "No Signal". It just gets dimmer when it is displaying my game screen. I'm using the same settings for all four screens so I don't see why it would be darker.
I've attached the binary of the game that uses display 3 instead of display 0. Can someone try it and let me know if it has a dim background? I'm trying to figure out if this is a software or hardware problem.
Edit: Sorry for all of the edits but now I'm noticing that all of the pixels have shifted on display 3. Something very odd is going on. I guess I'd better look over the code when I'm more awake.
I guess the only way I will know if this is a problem with one of the displays or the software is to open up the box and swap the display cables to see if the problem moves to another display. I don't see anything in the code that treats the displays differently.
Hi, David. I've been outside all day long but am headed home shortly, and I'll load up your file on a console after I get home and report back. However, if that 4th screen is shifted, the it sounds like the driver for it didn't start it fasr enough. I'm on my phone now, but if you haven't tried already, try starting it first or by itself. And are you partly using C language?
Comments
https://github.com/dbetz/monsta
This contains everything you need to build the game but you'll need to have PropGCC installed and openspin. I've included the Spin source code for the quad vga driver but it only includes a binary form (actually, an initialized C array) of the quad keyboard driver. The source for that driver is included in the code that comes with the WordFire/Cuby console. I've attached a .binary file here in case anyone wants to try it.
It is a maze game using a randomly generated maze. The interior walls of the maze are initially hidden but you discover them by moving around with the arrow keys. When you try to move in the direction where there is a wall, you bump into the wall and the wall becomes visible. There is a goal location that you are trying to reach and there is a monster who is trying to eat you. You have to reach the goal before the monster eats you to win the game. You can pick up various objects along the way. A club will allow you to beat the monster away once and a bomb will let you set a trap for the monster and will also blast away some of the maze walls maybe making it easier for you to reach the goal.
Here are the playing instructions:
Also, it is only a single-player game at present and uses only one keyboard and screen. I plan to display the maze on all four screens at the same time and let all four players discover the maze and each other. I might even try to figure out a way to make the game cooperative.
I'm also looking for some help. You'll see that I just use ASCII characters to display the maze and its contents. I'd like to design custom characters for this but I'm not sure how to do that. Anyone know how to create custom characters for the WordFire VGA driver?
As for defining custom characters, there's an article with an example of how to do that under the Docs tab of the project website called "Redefining Font Characters." That'll probably give you everything you need and more than you want (no one ever accused me of being succinct) to redefine characters.
Here's a direct link: http://www.wordfire.net/docs/RedefineFont.html
Prior to applying the foam, I tried just using PP plastic and also using a thick, transparent rubbery sheet. However, I think I like this foam solution the best because the four screw heads that attach the base to the stand compress the foam to recess within it such that they won't scratch the surface that the console is used on, dispensing with the need for the four rubber feet. However, the foam does noticeably muffle the sound level from the speaker, so I'm not sure yet if I'll really go this route. But maybe some small sound holes in the stand would restore the volume level. Alternatively, I might just enclose the whole PCB someday, but I like the simplicity of the current design.
On a related note, I'm working on--or at least toying with--an alternative version of the Quby PCB, and I'm giving some thought to putting a battery receptacle for a real-time clock on (or accessible from) the bottom of the base without needed to detach the base to access the battery. I'd likely have to dispense with the RTC module to do that, though, and just solder on an RTC chip. I've also considered giving up the clock functionality to simplify things, though, so far, I haven't made any decision to jettison it. Or maybe I'll just keep it like it is, as one rarely needs to change the battery (I've never had to change one, and I don't usually keep the console plugged in when not in use for games).
Also, rather than talking about a goal location, perhaps you could call it the treasure. Perhaps the treasure could even be visible (or visible at times), and maybe it could move around from time to time. Making the goal something "tangible" rather than just a location seems more intuitive. Or maybe you envision the goal location being a portal to another maze, but a treasure indicator could do that, too. Rather than being treasure, it could be a teleportation device or similar. Anyway, I'd get the solid walls coded first, then maybe consider a (possibly movable) treasure (or teleporter device).
As mentioned above, if a character with the ASCII value of 0 doesn't work for your normal text handling, then just assign the wall character to be character 1. Besides, as shown in the example code from the document on the website, it's typical to redefine a pair of characters at a time (due to the interleaving of the Propeller Font). Also, as I've mentioned somewhere, it's usually faster output-wise to have a solid blank character in one's redefined font than using inverse video. It allows one to output a whole string of characters in the same color without having to use inverse video to write or overwrite the space character(s) when a solid blank is needed.
DAT user_font 'beginning address of user's custom font data 'shortened underscore solid block (inverse space) C00_01 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%22222222_22222200 >< 32 + %%11111111_11111111 >< 32 long %%22222222_22222200 >< 32 + %%11111111_11111111 >< 32 long %%22222222_22222200 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32 long %%00000000_00000000 >< 32 + %%11111111_11111111 >< 32And you could redefine additional characters similarly to be the monster and so on. By the way, the coding technique used for redefining the font comes from Roger Williams.For the font character being redefined on the right, use 1's to define the "lit up" pixels in the foreground color, and for the character on the left, use 2's. For either the character on the left or right, use 0's for "un-lit" pixels in the background color. Easy-peasy. Thanks, Roger! Each redefined character does consume 64 bytes for the font data, so I try to limit myself to 16 characters or less. But I did redefine all of the first 32 characters once for a special font for large numbers, but that ate a lot of the HUB memory.
Hmm...rather than three planes of mazes, why not take advantage of all four screens and initially plot a different maze on each screen and connect them together via tunnels or portals. Up to four players could start out, each in his or her own maze. But then each player could independently move to another maze as desired. Although the views of the mazes wouldn't be locked together (that is, one player moving to another maze wouldn't change the mazes that the other players were in), each player could see when another player entered the same maze that he or she was in, something like that. This would still allow for single-player play, but the overall maze would be 4X as complex. And it would be kind of cool to peek around and see the other mazes. So, if just one player were playing, then maybe the four mazes could rotate when a player left one maze for another, if using tunnels, that is (not sure about portals); however, as mentioned, I don't think I'd "lock" the mazes together like that (in rotation) if more than one player were playing. Yeah, anyway, it'd definitely be good to take advantage of all four screens somehow, and that should more than make up for the col-row resolution only being 40x15.
Something like the foregoing perhaps could also work quite well for something in the vein of Pac-Man. Hey, maybe I was wrong about fill-in-the-blank word games being the killer app for the console. Quad-Screen Pac-Man could become the rage, like 3D chess. Okay, 3D chess never really panned out, but Quad-Man anyone? In such a version, maybe the ghosts would be confined to a single maze. Or not. Anyway, being able to redefine the font characters on the fly could allow for smooth animation for something like that without having to resort to a custom video driver. I guess one would have to dedicate two font characters to each pac-man or ghost (like a sprite), that way they could smoothly appear to "slide" over the text character boundaries, whether horizontally or vertically (but not diagonally). Anyway, taking advantage of the four screens could add an interesting dynamic, whether for Pac-man or Monstra.
By the way, quoting you in full just now is one of the few times that I've quoted someone without weeding out all the chaff (paring down the quote to the salient part I'm commenting on). I think the thread looks better that way.
There I go again fully quoting someone. But about your use of the clock, I figured as much. I also guess that you haven't made much use of the speaker, too. But that will likely change at some point. Anyway, although the clock gives the console a second function, it could go bye-bye, as the console is principally a game machine. Then again, if the clock could help market the console, perhaps it's worth saving. I'm not sure. I seem to be on a path to simplifying things, so I'm more willing to let go of "sacred cows." Of course, these days, lots of systems can get the time from the net. Also, people have plenty of options for getting the time (though few in the "Big Ben" format). Anyway, maybe I could make the clock an "optional extra," though the PCB and console would still have to accommodate it. Speaking of time, it's hard for us to give up things we've put time into developing, even if they are holding us back. We get attached and have a hard time letting go and hang on too long. That's human nature. Thanks for the feedback.
you could simply go by and just type in the char-definition mirrored
11111111
10000000
11111111
10000000
11111111
for a E
will be
11111111
00000001
11111111
00000001
11111111
for most game-characters mirroring might not be a problem,, a PAC-Man character needs to have 4 versions for each direction anyways...
Mike
Oh! If you really just mean the display brightness (and contrast, etc.), then the answer is a qualified "no." No, the game console hasn't provided for adjusting those, but, yes, it's possible if one has a little optional keypad that attaches to the side of a driver board. With that, there's a on-screen menu system (OSD?) that one can get into to, for example, set the contrast, brightness and screen orientation. But those keyboards are optional accessories when purchasing driver boards and they weren't designed into the game console, nor was one or more provided with the system. Is there some problem with the brightness? A keypad could be fabricated (it's just switches), but it would need a PH2 cable or some carefully placed jumper wires to connect with the driver board to make adjustments. And if need be, I believe I have a spare keypad that could be sent to you.
Now, it might also be possible to wire in the IR detector to the keypad header of the driver boards, but I haven't tried that. I do know that some keypads I've seen in the past for other screens could control the OSD via an IR remote control. And I'm almost for sure that that's a standard feature of the driver board's main chip. But the keypads that I have don't have the IR detector diode on them (nor even pads for one to my knowledge), but I'll bet there's a line for one in the PH2 cable. By the way, the driver boards are also capable of displaying composite video, but that needs to be selected with the keypads (or a remote control). When I setup the console, I use a keypad to set the driver boards for VGA, widescreen stretched over 800 pixels horizontally. I change the screen orientation for your version of the console, too. Anyway, I believe that these settings must be stored in non-volatile memory within the Realtek video chip, since the settings persist over power cycles. And I've never seen the setting change on their own or revert back to the original settings, fortunately. As for the brightness and contrast, I don't touch those when I set up the screens. Are you saying that the screens too hot, brightness-wise? Are they burning in your eyeballs? Are they burning in the screens??? What's up? I'm doing a lot of guessing here.
The only other possibly related thing I can think of is that I use 180 Ohm resistors as the video DAC's. I used to use higher values, but the colors were muddier. For example, the red was more brownish. It's been a long time since I've done the calculations, but maybe things are being driven a bit too hot, though I never investigated that or considered that before, probably because things looked fine to me visually. But I suppose it's a possibility. I've been working all night and am not in good shape to think about it now, but it would be nice to know why you want to adjust the screen brightness (assuming that's what you want to do) or what problem you're experiencing (assuming that you're experiencing a problem). Anyway, hopefully, the above info. should give you something to chew on before I crash and burn for a while before needing to go out later today. I must say, you're scaring me. Hope things work out. I'll be around for at least a few more minutes.
Anyway, I think one of the most readable or striking combinations is white text on blue. That was used on the Atari, I believe, and it looks even better on VGA screens. Also, the Parallax font is three pixels wide and is quite legible. White text on red is also quite readable. White or green on black work well, too, but you might prefer to have some color in the background. For the players of the CopyCats game, the following are used: [north] white-on-blue, [west] black on yellow, [south] white on red, and [east] black on green. But that's just for one line of text at a time.
From the videos section of the website, the following one-minute video (with longer versions also available) shows a variety of color combinations at work/play:
That video was made for your version of the console with the snack bowl, but I think that everything else still applies. Hopefully, you'll find a color combination that will work for your particular application.
White on green also looks very good. That and blue/white was what I used back in the EGA days when I spent a lot of time in front of a monitor. Much easier on the eyes than any other combinations.
I've attached the binary of the game that uses display 3 instead of display 0. Can someone try it and let me know if it has a dim background? I'm trying to figure out if this is a software or hardware problem.
Edit: Sorry for all of the edits but now I'm noticing that all of the pixels have shifted on display 3. Something very odd is going on. I guess I'd better look over the code when I'm more awake.