So I have a longstanding goal to reduce a particular PC game that was popular in the early 90s to text adventure form, because (a) I'm weird and like text adventures and (b) I'm weird and think it would be fun. The game for now shall remain unspecified.
I would like to do this as a dedicated system. This is normally where the 6510 a pal gave me would come out of my junk bin and I'd teach myself 6502 assembly and all... but that just seems a bit unnecessary when I've got an Arduino hanging around -- or, rather, two of them. One is an Uno clone from eBay -- it has the Atmel serial chip, not the CH341 one; I was particular about that. The other is a Mega 2560. I also have the keyboard from a thoroughly wrecked Commodore Plus/4 and a 4-line 40-character LCD (although the TVOut scheme seems somewhat more attractive than a char LCD the size of a single Tweet).
Obviously, text adventure means string parser, and string parser means strings, and strings generally means malloc() -- which likes to take the Arduino's measly little speck of RAM and turn it into a plate of corned beef hash. I admit that I'm a complete noob when it comes to Arduino, and I hardly know any C++ type stuff -- I'm more comfortable, sadly, in shades of BASIC -- but I know that Arduino "things" have, at least in some sense, been around quite a while, and I know there are community-developed libraries which can replace certain core functions and do it better than the original. IIRC there's something that even does pin toggling (by which I mean setting a pin low or high) faster than the original.
So my question is: is there such an "enhanced" library for strings, that avoids malloc()?
IMO - It hardly seems worth it adding a keyboard and display to an Arduino but that's up to you. I suspect this will be the "hardest part" of your project.
Do you have an idea of how much memory you're going to need? The Arudino's memory is limited so it depends on the complexity of your game. Text requires "almost nothing" compared to grahics, but it seems like an adventure game could require lots of text.
You can either use [u]C-style strings[/u] which are character arrays or [u]C++ string objects[/u]. C++ strings are easier to work with but it's helpful if you first understand the concept of object oriented programming.
I hardly know any C++ type stuff -- I'm more comfortable, sadly, in shades of BASIC
The "basic" [u]Arduino C++ language Library[/u] is pretty easy and I don't think you'll have much trouble getting started. You already know about variables, loops, conditional branching, etc., so it's just a matter of adapting to a different language/style.
I've never done any object oriented programming with the Arduino (other than using some of the built-in functions) and most of the stuff I see in the examples and on the forum is more C than C++.
The whole C++ language is huge. Several years ago, I was looking for a book that covers the entire Standard C++ language and the only complete (printed) reference I could find was the ANSI/ISO language standard itself. (There are some complete online references). And, Standard C++ does not include graphics, mouse, sound, etc. All of that requires additional libraries. And, much of the stuff in the Arduino library is non-standard too... Standard C++ doesn't know anything about I/O pins or analog-to-digital converters, etc.
I'm not sure how much Standard C++ is supported by the Arduino. The most basic functions for keyboard input, display, and file storage are not included because there is no standard-associated hardware. All of that has to be customized if you want to include it.
Oy, maybe I should pull out that 6510 after all...
groan
I'm already planning on needing a ROM chip to store most of the game text -- I have that, too, it's a Winbond part, I'll need a level converter for it since it's 3.3v but that's not hard. It's an SPI part, 8mbit in size. That should reasonably hold enough text.
I am imagining this to be a sizable bit of work. As for my competency in C++, I think you overestimate me a little. I get a few basic concepts, and I can mostly read existing code (Google helps!) but I'm quite far from writing my own anything. TBH, when I have a logic problem to solve, I usually use 7400 and 4000 series chips, but that ain't gonna work with this.
No doubt it is possible to do this sort of thing with an Arduino but it seems to me that a RaspberryPi would make the whole thing a lot easier to implement.
Sketch uses 247216 bytes (23%) of program storage space. Maximum is 1048576 bytes.
Global variables use 43320 bytes (16%) of dynamic memory, leaving 218824 bytes for local variables. Maximum is 262144 bytes.
The text file database is an array in program memory (about 133kB). There are also some parsing arrays which take up some room.
IMO the external EEPROM is sufficient for this project. Don't forget a map from which you can retrieve the address of every string.
If you want to build your own keyboard, find enough circuit diagrams and code in the web. Or get an old PS2 keyboard, which can be attached to an Arduino.
As @Robin2 suggests a Raspberry Pi would be a more natural choice for the project.
You are thinking of using an EEPROM, you could equally well use an SD card.
You are thinking of storing just the game text in ROM. Instead @christop suggests using Z-code. I would not go that far but I would store both the text and the game structure. So each text item also includes pointers to other other text items. Depending on what action the player decides upon the game follows the relevant pointer to the next text item. Your program then becomes very small. Quite hard work ensuring the game structure is consistent, but you will always have that problem however you implement the game.
starhawk:
Thank you all for all your info I'd forgotten the PS/2 keyboard bit... hmmm...
I like the SD card idea, too... they're 5v tolerant, usually, aren't they...?
From what I remember SDcards are 3.3V tolerant - they normally run at 1.8V or so in native mode,
but for the simpler SPI interface you can stay at 3.3V which is the maximum allowed. Normally a
high speed device negotiates the voltage and I/O speed with the card. That's a lot more complex than
makes sense on a lowly microcontroller though, which is why the 3.3V SPI interface exists.
but that's not hard. It's an SPI part, 8mbit in size. That should reasonably hold enough text.
I'd forgotten the PS/2 keyboard bit... hmmm...