Okay. So, when talk about using a text editor to "write the code in," by "code" do you mean the contents of the .adv adventure file? I guess so, as I don't know what else that .adv could be. I searched for ".adv" on your AdvSys2 Dev. thread, but didn't come up with anything. But if that is indeed what you mean, how high level is such code? Is it a declarative language? I guess what I'm really asking is can you provide a sample excerpt of what such text might look like (even if you haven't fully fleshed out the instructions of the language yet)? I also assume that it has built-in instructions for creating the data to define (or import) a world of some kind, such as the rooms of a mansion. What's that code look like? If you want to keep it close to the vest at this time, no problem. I'm mostly just curious at this point.
And a couple years back, I've briefly considered what it might take to write a high-level, general purpose word-game format (not necessarily a full-blown language, though maybe). A format that was high-level enough that non-programmers could specify game play, scoring and so on. I know, it's pretty daunting, and it would be limited in scope. But it might be feasible for dozens and dozens of simpler word games. Seems like what you've done is go beyond just a format to a "complete" language. That may put it in the realm of programmers, though, but many people can learn programming, especially for a narrow usage.
Anyway, there might be some overlap between what I briefly considered and what you have done (or are doing). While your language sounds less limited, perhaps what I had in mind is more general, as the goal would be to cover a wide range of word games (back then, I hadn't considered adventure games, per se). However, I never actually tried to specify the format or the scope/limits of what kinds of games would be possible. And I never created a list of desired attributes or specifications for such a format.
For example, as a starting point, a reasonable limit, particularly in the case of the game console, would be fixed-width text and 40x15 (ColsxRows). And such a format would likely have to work close in hand with the text data files for the content. Just as an example, consider a standard text (.txt) or data file with abbreviations from various fields (e.g. ENT: Ear, Nose and Throat; Medical Practice), and a game format file, call it .gam, specifying how to present the abbreviations, fields and input and how to respond to the input and do the timing and scoring, etc. Then, either [1] something similar but not identical to the GameMenu program on the Propeller would be ran to combine the .txt and the .gam in real-time to play the game straightaway, or [2] some PC/web program could post-process .gam to make it a Propeller binary, as it appears that you are doing. I suppose something like this already exists, but I haven't searched on it. I have heard that there are game engines for video games, though. And I suppose that they have multiplayer, multi-screen capability. But I talking about something simpler (though still complex in its own right) that would work of the Propeller/WordFire quad-screen game console.
Anyway, what you've developed and learned for your adventure game language sounds applicable, and I think that I recall your saying something about it not being limited to adventure games (but perhaps you meant that it extends to general programming rather than specifically applicable to a variety of game types (though the former may cover the latter)). It kind of seems unlikely to me that it would truly be general purpose in the sense I mean above such that it would be applicable to a wide variety of word games since that's a complicated realm. But, for all I know, perhaps it is. Anyway, keep up the good work. And you never know how an concept (resolved to practice) will grow and mutate (in a good way).
I'll give a more complete answer when I have some more time but here is a sample .adv file. This is the same simple game I already provided you as a .binary file. I've also included an additional .adi file. That is an "include file" sort of like a C .h file. In this case, it contains most of the code. The .adv file mostly has data declarations. You'll probably notice that the language looks a lot like C.
game.adv
include "game.adi";
actor northActor {
name: "Mr. North";
index: 0;
_loc: livingroom;
}
actor westActor {
name: "Mrs. West";
index: 1;
_loc: closet;
}
actor southActor {
name: "Ms. South";
index: 2;
_loc: pantry;
}
actor eastActor {
name: "Dr. East";
index: 3;
_loc: kitchen;
}
thing cat {
name: "a black cat";
_loc: pantry;
}
thing dragon {
name: "a fierce dragon";
_loc: closet;
}
location storage_room {
description: "You are in the storage room.";
west: hallway;
}
location hallway {
description: "You are in the hallway.";
east: storage_room;
north: kitchen;
south: livingroom;
}
location kitchen {
description: "You are in the kitchen.";
south: hallway;
west: pantry;
}
location pantry {
description: "You are in the pantry.";
east: kitchen;
}
location livingroom {
description: "You are in the livingroom.";
north: hallway;
west: closet;
south: outside;
}
location closet {
description: "You are in the closet.";
east: livingroom;
}
location outside {
description: "You are outside.";
north: livingroom;
}
def main()
{
initActor(northActor);
while (1)
checkActor(northActor);
}
game.adi
object location {
_child: nil;
}
object actor {
_parent: nil;
_sibling: nil;
}
object thing {
_parent: nil;
_sibling: nil;
}
property north, south, east, west;
property name, description;
var multiScreen = false;
def getc()
{
asm {
TRAP 0
RETURN
}
}
def screen(n)
{
asm {
LADDR 0
LOAD
TRAP 5
}
}
def reboot()
{
asm {
NATIVE mov t1, #0x80
NATIVE clkset t1
}
}
def getp(obj, prop)
{
var value;
try {
value = obj.(prop);
}
catch (e) {
value = 0;
}
return value;
}
def connect(c, p)
{
c._parent = p;
c._sibling = p._child;
p._child = c;
}
def disconnect(obj)
{
var this = obj._parent._child;
var prev = nil;
while (this) {
if (this == obj) {
if (prev)
prev._sibling = this._sibling;
else
obj._parent._child = this._sibling;
obj._parent = nil;
break;
}
prev = this;
this = this._sibling;
}
}
def printContents(obj, prop)
{
var desc;
obj = obj._child;
while (obj) {
if ((desc = obj.(prop)) != nil) {
print " ", #desc;
}
obj = obj._sibling;
}
}
def listContents(actr, prop)
{
var loc = actr._loc;
var child = loc._child;
var first = true;
var desc;
while (child) {
if (child.class != actor && (desc = child.(prop)) != nil) {
if (first) {
println "You see:";
first = false;
}
println " ", #desc;
}
child = child._sibling;
}
}
def look(actr)
{
var loc = actr._loc;
println #loc.description;
listContents(actr, name);
}
def announce(actr)
{
var loc = actr._loc;
var child = loc._child;
while (child) {
if (child.class == actor && child != actr)
println #child.name, " is here.";
child = child._sibling;
}
}
def announceMovement(actr, loc, tail)
{
var child = loc._child;
while (child) {
if (child.class == actor && child != actr) {
screen(child.index);
println #actr.name, #tail;
}
child = child._sibling;
}
}
def move(actr, dir)
{
var oldloc = actr._loc;
var newloc = getp(oldloc, dir);
if (newloc) {
disconnect(actr);
connect(actr, newloc);
look(actr);
announce(actr);
if (multiScreen) {
announceMovement(actr, oldloc, " left.");
announceMovement(actr, newloc, " arrived.");
screen(actr.index);
}
}
else {
println "You can't go that way!";
}
}
def initActor(actr)
{
screen(actr.index);
look(actr);
}
def checkActor(actr)
{
var ch;
// switch to the actor's screen
screen(actr.index);
// check for actor input
if ((ch = getc()) != 0 && ch != '\n') {
if (ch == 'n')
move(actr, north);
else if (ch == 's')
move(actr, south);
else if (ch == 'e')
move(actr, east);
else if (ch == 'w')
move(actr, west);
else if (ch == 'l')
look(actr);
else if (ch == 'q')
reboot();
else
println "Huh?";
}
}
By the way, my last post was a break from soldering and testing. I'm happy to report that the revised version of the PCB for the new form factor appears to be working (at least in preliminary testing). And I was able to excise some material from the existing base board to create a cutout that could accommodate the new power on/off power switch. Well, I haven't actually ordered the right-angle switches I need/want, yet, but I was able to solder a 180° rocker switch on to a header and fake things. Works just fine and it very strong/stable (but a bit time consuming to solder). And as for the new form factor, I really like it! It's much smaller and lighter, making it possible to grasp the console from the stand alone with one hand and move it around in the air. Anyway, this is a nice form factor. I think I like it around twice as much as the prior design, despite having to give up the snack bowl.
I just added the ability to generate Propeller binary files to the compiler itself. You can now run your program on a Propeller like this:
adv2com -t run game.adv
proploader -s game.binary -t
The -t option tells the compiler to generate a Propeller binary with the specified template. The "run" template just runs the program with I/O going to the serial port. The "step" template allows you to single step a program. The "wordfire" template builds a program for the WordFire console. If you leave off the -t option the compiler generates a game image .dat file as usual.
I thought about something like your template too. Some sort of a WFsystem object mimicking one Keyboard and one Screen to use on existing Propeller boards with SD, PS2 and VGA.
So Lunar Lander, EditMap and my current 'PacChild' could run on the WF console but also as single player on some normal Propeller Boards. The multiplayer Versions would require a WF console...
Hi, David. Thanks for asking. I'm making progress.
Last week, I nailed down (more like screwed down) some details of the console, such as how to secure the top of the head unit. And I got the housing stained and spray painted. I also took some pictures and will post those when the console launches (hopefully soon).
During my free time this week, I've been working through all of the pages of my local version of the website to update them for the new design. However, I haven't pushed the changes up to the server yet for public viewing.
I still need to update the instructions and photos under the three sub-pages of the Build tab: Soldering, Assembly and Testing. For example, I need to re-shoot all of the images for the soldering steps and rework the descriptions, as I plan to offer unsoldered versions (see below).
Unlike last time, where I soldered up all the boards I had ordered in preparation for announcing availability, this time, I'll keep some unsoldered boards for people who want to do their own soldering. That'll let people save some money while receiving the enjoyment of building something with their own hands.
I think that the circuit board is an enjoyable build. The soldering is pretty easy and consists of mostly connectors/jacks (though it takes a couple hours to do). I'll likely oven solder the surface mount resistors and capacitors myself (perhaps hand-soldering the SD card socket) but leave all of the through-hole stuff for those who want to go the DIY route. I think it's a satisfying build because, upon completion, one has a board that can drive four LCD screens simultaneously with differing content. Plus, there's a nice housing that holds everything together (a lot of kits don't include a housing).
Anyway, I'm marching along, step-by-step, to an eventual "re-launch" of the console. And although I realize that the forum members who want a console likely have already bought one, as with the last version, I'll still announce availability here first given that it's a Propeller-based device, before giving consideration to any kind of wider launch.
Oh, it is plausible that some additional forum members might want to get a console, as I'm planning to offer a two-screen version with blanks for the other two screens for $50 less. Such a version could be upgraded later to a four-screen console (by adding two screens, driver boards and keyboards). People are understandably cost conscious these days considering how much functionality they can get in mass-market devices, but I think that the console also offers a lot of bang-for-the-buck, what with multiple displays and keyboards. And it's something different/distinctive.
I hope to reveal the console sometime later this month, likely within the next couple of weeks if all goes well. --Jim
Thanks for the update. I'm moving along with my text adventure system. I think I have the compiler and VM to a point where I could write a game but writing a parser or even just converting my original parser is going to take some time and I think I'm going to take a break from it for a while to work on another project. I will get back to it though and I may try using the language for other purposes as well. I first need to create a way to edit lines on all four screens at the same time. That should be fun.
Congrats on moving the VM forward. I thought about asking about the progress, but the stuff that you are working on--and what Mike is doing--is a lot harder than what I'm doing. In your case, creating the parser sounds pretty tricky (even if converting). And in Mike's case, getting a video game up and running on the console, will also be a challenge (as it's harder to deal with four screens). Anyway, I can see how a break is in order, especially with other irons in the fire. I'm just glad that you guys have been able to accomplish on the console whatever you've set your minds to, despite so many resources (memory, cogs) already being in use.
So far my test programs haven't taken more than 1-2K bytes of memory. We'll see what happens when I try to write a substantial program. Since my language looks so much like C, I'm beginning to wonder if I might have been better off just using C and writing a library for the game-specific stuff.
To All: I've revamped the design of the game console and relaunched it under the name Quby (from WordFire). There's a new thread for it under the Customer Projects subsection of this site. Thanks. --Jim
Sure @"David Betz" we have the deluxe version, with snack bowls.
I am slammed with real work, but as soon as I have time I will play with it again. That 4 screen concept just asks for stuff like bouncing something around all screens.
My Map-Editor has reached a half-ways usable state, I made a first PacMan screen, but then my play-time run out.
That 4 screen concept just asks for stuff like bouncing something around all screens.
.....have fun,
Mike
How about a word game where the board is passed around the screens and scoring is based on both the value of added letters as well as the speed of adding them.
Greetings, vintage console owners here on the forum. I'd name you individually but the list would be too long to fit embarrassingly short. Thanks for hanging in there. Fortunately, your consoles are compatible with Quby (or vice-versa). Versions prior to yours were not compatible. Before your version, there was a one that had beverage bays in addition to the snack bowl. And prior to that, there was a tower version that held the keyboards inside. And the original (composite video) version was a truncated pyramid (frustum). All of those have been donated to the Boston Computer Museum. Awe, shucks! I see that it closed in 2000. How can that be? Well, the only thing that is constant is change itself.
By the way, when I released your version of the console (just a few months ago), I had no idea whatsoever (zero, nada) that I'd be designing a revised version. It was the process of building and shipping the first released version that led me to do a redesign, not due to consumer demand, obviously, but out of desire to simplify and optimize the concept. Each iteration gets easier, it seems, as there's more and more of the "infrastructure" in place. Gee, maybe someday I'll even look into trying to get the word out. But for now, I'm still just dipping a reluctant toe into the water.
As for games for the console, there's really little limit in terms of the number and variety that is possible. I hope to get back to working on them soon. We haven't even begun to think. In a way, it's like paper was just invented and now we need to figure out what to do with it (a solution in search of a problem?). But it's hard for us to invest the time and effort into developing games for the console when there's such a small contingent of console owners. I understand that. So I really appreciate that you guys have kept the faith, so to speak. And at the very least, I hope that you've gotten some enjoyment out of programming this rather unusual system.
Greetings, vintage console owners here on the forum. I'd name you individually but the list would be too long to fit embarrassingly short. Thanks for hanging in there. Fortunately, your consoles are compatible with Quby (or vice-versa). Versions prior to yours were not compatible. Before your version, there was a one that had beverage bays in addition to the snack bowl. And prior to that, there was a tower version that held the keyboards inside. And the original (composite video) version was a truncated pyramid (frustum). All of those have been donated to the Boston Computer Museum. Awe, shucks! I see that it closed in 2000. How can that be? Well, the only thing that is constant is change itself.
While the Boston Computer Museum has been gone for many years, there is still the Computer History Museum in California. My understanding is that they acquired some of the inventory from the old Boston Computer Museum. Check out the Computer History Museum if you're in California sometime. I saw the Babbage Difference Engine on display there once and it was amazing!
California is a long haul from your neck of the woods there near the right=east coast. Yeah, when I checked if I had the name right for TCM of Boston, I discovered that the CHM had taken possession of some of the inventory. That makes sense. But what doesn't fully make sense to me is how a tech area like Boston (with MIT and so many tech companies in the vicinity) apparently wasn't able to support a computer museum. It seems like there'd be interest in having such a museum on both coasts. Such a museum could be located outside of the city to lower the rent. I haven't studied that matter, but I wonder if MIT considered hosting TCM. That would seem like a match. Anyway, I never had a real opportunity to visit a computer museum, but it would be fun. Now I've seen pictures and read about Babbage's "Difference Engine," but seeing something in person leaves a more lasting impression. And what could be more visual than a computer museum? Well, a natural history one with dinosaurs. But it'd be fun to walk through a computer dinosaur, like an old main frame computer system complete with a raised floor for the cables and so on, even or particularly while realizing that it has less computational power than a microchip. Well, books can picture such stuff, but nothing beats a three-dimensional, life-sized display. Then again, perhaps many museums will go the virtual route in the future with 3D headsets that let us do walkthroughs and even some "hands on" stuff, like pressing a virtual button to start a data storage unit or whatever. Still, I hope that real museums don't completely disappear. Same for libraries with actual books.
FYI - the difference engine #2 is owned by Nathan Myhrvold, and he finally took possession. So #2 is no longer in Mountain View. I guess we'll have to fly to London to see #1.
Comments
And a couple years back, I've briefly considered what it might take to write a high-level, general purpose word-game format (not necessarily a full-blown language, though maybe). A format that was high-level enough that non-programmers could specify game play, scoring and so on. I know, it's pretty daunting, and it would be limited in scope. But it might be feasible for dozens and dozens of simpler word games. Seems like what you've done is go beyond just a format to a "complete" language. That may put it in the realm of programmers, though, but many people can learn programming, especially for a narrow usage.
Anyway, there might be some overlap between what I briefly considered and what you have done (or are doing). While your language sounds less limited, perhaps what I had in mind is more general, as the goal would be to cover a wide range of word games (back then, I hadn't considered adventure games, per se). However, I never actually tried to specify the format or the scope/limits of what kinds of games would be possible. And I never created a list of desired attributes or specifications for such a format.
For example, as a starting point, a reasonable limit, particularly in the case of the game console, would be fixed-width text and 40x15 (ColsxRows). And such a format would likely have to work close in hand with the text data files for the content. Just as an example, consider a standard text (.txt) or data file with abbreviations from various fields (e.g. ENT: Ear, Nose and Throat; Medical Practice), and a game format file, call it .gam, specifying how to present the abbreviations, fields and input and how to respond to the input and do the timing and scoring, etc. Then, either [1] something similar but not identical to the GameMenu program on the Propeller would be ran to combine the .txt and the .gam in real-time to play the game straightaway, or [2] some PC/web program could post-process .gam to make it a Propeller binary, as it appears that you are doing. I suppose something like this already exists, but I haven't searched on it. I have heard that there are game engines for video games, though. And I suppose that they have multiplayer, multi-screen capability. But I talking about something simpler (though still complex in its own right) that would work of the Propeller/WordFire quad-screen game console.
Anyway, what you've developed and learned for your adventure game language sounds applicable, and I think that I recall your saying something about it not being limited to adventure games (but perhaps you meant that it extends to general programming rather than specifically applicable to a variety of game types (though the former may cover the latter)). It kind of seems unlikely to me that it would truly be general purpose in the sense I mean above such that it would be applicable to a wide variety of word games since that's a complicated realm. But, for all I know, perhaps it is. Anyway, keep up the good work. And you never know how an concept (resolved to practice) will grow and mutate (in a good way).
game.adv
include "game.adi"; actor northActor { name: "Mr. North"; index: 0; _loc: livingroom; } actor westActor { name: "Mrs. West"; index: 1; _loc: closet; } actor southActor { name: "Ms. South"; index: 2; _loc: pantry; } actor eastActor { name: "Dr. East"; index: 3; _loc: kitchen; } thing cat { name: "a black cat"; _loc: pantry; } thing dragon { name: "a fierce dragon"; _loc: closet; } location storage_room { description: "You are in the storage room."; west: hallway; } location hallway { description: "You are in the hallway."; east: storage_room; north: kitchen; south: livingroom; } location kitchen { description: "You are in the kitchen."; south: hallway; west: pantry; } location pantry { description: "You are in the pantry."; east: kitchen; } location livingroom { description: "You are in the livingroom."; north: hallway; west: closet; south: outside; } location closet { description: "You are in the closet."; east: livingroom; } location outside { description: "You are outside."; north: livingroom; } def main() { initActor(northActor); while (1) checkActor(northActor); }game.adi
object location { _child: nil; } object actor { _parent: nil; _sibling: nil; } object thing { _parent: nil; _sibling: nil; } property north, south, east, west; property name, description; var multiScreen = false; def getc() { asm { TRAP 0 RETURN } } def screen(n) { asm { LADDR 0 LOAD TRAP 5 } } def reboot() { asm { NATIVE mov t1, #0x80 NATIVE clkset t1 } } def getp(obj, prop) { var value; try { value = obj.(prop); } catch (e) { value = 0; } return value; } def connect(c, p) { c._parent = p; c._sibling = p._child; p._child = c; } def disconnect(obj) { var this = obj._parent._child; var prev = nil; while (this) { if (this == obj) { if (prev) prev._sibling = this._sibling; else obj._parent._child = this._sibling; obj._parent = nil; break; } prev = this; this = this._sibling; } } def printContents(obj, prop) { var desc; obj = obj._child; while (obj) { if ((desc = obj.(prop)) != nil) { print " ", #desc; } obj = obj._sibling; } } def listContents(actr, prop) { var loc = actr._loc; var child = loc._child; var first = true; var desc; while (child) { if (child.class != actor && (desc = child.(prop)) != nil) { if (first) { println "You see:"; first = false; } println " ", #desc; } child = child._sibling; } } def look(actr) { var loc = actr._loc; println #loc.description; listContents(actr, name); } def announce(actr) { var loc = actr._loc; var child = loc._child; while (child) { if (child.class == actor && child != actr) println #child.name, " is here."; child = child._sibling; } } def announceMovement(actr, loc, tail) { var child = loc._child; while (child) { if (child.class == actor && child != actr) { screen(child.index); println #actr.name, #tail; } child = child._sibling; } } def move(actr, dir) { var oldloc = actr._loc; var newloc = getp(oldloc, dir); if (newloc) { disconnect(actr); connect(actr, newloc); look(actr); announce(actr); if (multiScreen) { announceMovement(actr, oldloc, " left."); announceMovement(actr, newloc, " arrived."); screen(actr.index); } } else { println "You can't go that way!"; } } def initActor(actr) { screen(actr.index); look(actr); } def checkActor(actr) { var ch; // switch to the actor's screen screen(actr.index); // check for actor input if ((ch = getc()) != 0 && ch != '\n') { if (ch == 'n') move(actr, north); else if (ch == 's') move(actr, south); else if (ch == 'e') move(actr, east); else if (ch == 'w') move(actr, west); else if (ch == 'l') look(actr); else if (ch == 'q') reboot(); else println "Huh?"; } }I thought about something like your template too. Some sort of a WFsystem object mimicking one Keyboard and one Screen to use on existing Propeller boards with SD, PS2 and VGA.
So Lunar Lander, EditMap and my current 'PacChild' could run on the WF console but also as single player on some normal Propeller Boards. The multiplayer Versions would require a WF console...
Mike
Last week, I nailed down (more like screwed down) some details of the console, such as how to secure the top of the head unit. And I got the housing stained and spray painted. I also took some pictures and will post those when the console launches (hopefully soon).
During my free time this week, I've been working through all of the pages of my local version of the website to update them for the new design. However, I haven't pushed the changes up to the server yet for public viewing.
I still need to update the instructions and photos under the three sub-pages of the Build tab: Soldering, Assembly and Testing. For example, I need to re-shoot all of the images for the soldering steps and rework the descriptions, as I plan to offer unsoldered versions (see below).
Unlike last time, where I soldered up all the boards I had ordered in preparation for announcing availability, this time, I'll keep some unsoldered boards for people who want to do their own soldering. That'll let people save some money while receiving the enjoyment of building something with their own hands.
I think that the circuit board is an enjoyable build. The soldering is pretty easy and consists of mostly connectors/jacks (though it takes a couple hours to do). I'll likely oven solder the surface mount resistors and capacitors myself (perhaps hand-soldering the SD card socket) but leave all of the through-hole stuff for those who want to go the DIY route. I think it's a satisfying build because, upon completion, one has a board that can drive four LCD screens simultaneously with differing content. Plus, there's a nice housing that holds everything together (a lot of kits don't include a housing).
Anyway, I'm marching along, step-by-step, to an eventual "re-launch" of the console. And although I realize that the forum members who want a console likely have already bought one, as with the last version, I'll still announce availability here first given that it's a Propeller-based device, before giving consideration to any kind of wider launch.
Oh, it is plausible that some additional forum members might want to get a console, as I'm planning to offer a two-screen version with blanks for the other two screens for $50 less. Such a version could be upgraded later to a four-screen console (by adding two screens, driver boards and keyboards). People are understandably cost conscious these days considering how much functionality they can get in mass-market devices, but I think that the console also offers a lot of bang-for-the-buck, what with multiple displays and keyboards. And it's something different/distinctive.
I hope to reveal the console sometime later this month, likely within the next couple of weeks if all goes well. --Jim
I am slammed with real work, but as soon as I have time I will play with it again. That 4 screen concept just asks for stuff like bouncing something around all screens.
My Map-Editor has reached a half-ways usable state, I made a first PacMan screen, but then my play-time run out.
have fun,
Mike
How about a word game where the board is passed around the screens and scoring is based on both the value of added letters as well as the speed of adding them.
By the way, when I released your version of the console (just a few months ago), I had no idea whatsoever (zero, nada) that I'd be designing a revised version. It was the process of building and shipping the first released version that led me to do a redesign, not due to consumer demand, obviously, but out of desire to simplify and optimize the concept. Each iteration gets easier, it seems, as there's more and more of the "infrastructure" in place. Gee, maybe someday I'll even look into trying to get the word out. But for now, I'm still just dipping a reluctant toe into the water.
As for games for the console, there's really little limit in terms of the number and variety that is possible. I hope to get back to working on them soon. We haven't even begun to think. In a way, it's like paper was just invented and now we need to figure out what to do with it (a solution in search of a problem?). But it's hard for us to invest the time and effort into developing games for the console when there's such a small contingent of console owners. I understand that. So I really appreciate that you guys have kept the faith, so to speak. And at the very least, I hope that you've gotten some enjoyment out of programming this rather unusual system.
http://www.computerhistory.org