Embedded CircleMUD After many long nights and sleepless days it's finally here: CirlceMUD on an 8051 microcontroller. This project started off as a university project and has since grown into a full embedded MUD based on the Circle codebase. Due to the limitations of this 8bit architecture several compromises had to be made. These will be discussed in detail later. The hardware setup used is relatively simple, but the code relies on this particular setup. If you change your hardware be prepared to change the code to match. The compiled Circle binary is stored in ROM (well, EEPROM actually) and the data files[1], including world and pfiles, are in RAM, sharing the same address space (the 8051 has separate code and data memory). All testing and major debugging was performed on a simulator running on a PC to avoid needless EEPROM programming. Timer circuitry mirrors the RAM (data) into 64k of flash every hour (realtime) to keep a backup of the volatile memory and keep information over reboots. At power-on time this backup is read into RAM before the code begins execution. A neat side effect of the data storage method is that there is no need to save pfiles, etc. The only copy of player data is in memory at all times. Other external hardware includes a serially connected hardware TCP/IP stack with an ethernet port to provide internet connectivity. In the interests of reduced memory usage and program code size (both code and data memory are only 64k) some restrictions have had to be imposed on the MUD: - Room descriptions have been limited to one line (74 character). Nobody reads them more than once, anyway, so why waste the storage space? - Player descriptions have been removed. Nobody every sets them, so why waste the storage space? - Help files have been dropped. Commands are fairly intuitive, and help files are always out of date, so why bother? - Pfiles are dense binary with pnums corresponding to the upper bits of the memory locations the particular pfiles are stored. - There is only one world file (in dense binary format) and this is carefully edited to allow vnums to correspond exactly to rnums, allowing the removal of all the vnum/rnum differentiating code. - No OLC exists - all world modifications are made offline with a suitable editor and updated onto the flash backup before booting the mud. This unfortunately increases reboot time significantly (shutdown, remove flash, reprogram flash, insert flash, boot) but with suitable hardware this process may be automated from a remote PC. - The number of rooms, mobs, items, etc. must fit into the limited memory available. This results in a rather small world, but innovative area design can make up for this. Despite these limitations, the unique hardware platform has several advantages: - Relatively cheap to purchase the hardware, as opposed to setting up a PC server to run the MUD. My hardware cost in the region of US$100, and will probably be cheaper elsewhere due to the poor ZAR/US$ exchange rate (about 12 rand to the dollar at the time of hardware purchase). - Small size. This server can be built on a piece of PCB about 3 inches square. - Low power consumption. You don't even need a heatsink on the processor. - Portable. The small size and the fact that no moving parts (hard drives, etc.) are used means that with a wireless ethernet and battery power supply you can carry your MUD in your pocket wherever you go. No more driving to the server room to reboot/debug. - As the hardware is entirely dedicated to the MUD and not even an operating system stands between the MUD and the hardware, you are not competing with anything else for processor time and server lag is reduced. - Security. There are no security holes that allow access to your server because there's nothing on the server to access except the MUD itself. No command shell, no root password, no way to disrupt the running process except from within the MUD itself. - You can embed your MUD in common household appliances and have a MUD-based interface to a control system[2]. All in all, this MUD system (hardware and software) is not for everyone[3], but it may be useful to those on a tight budget or electronics wizards wanting to play with cutting-edge embedded network applications. Footnotes: [1] There are no real files as such - no filesystem exists to store them. However, the allocated memory segments are accessed through pointers which can be thought of as file descriptors and to all intents and purposes they are the same thing. [2] My MUD is curerntly located inside my VCR and I can use my Implementor character to schedule recording of favourite TV programmes. The next version of the MUD (possibly on a PIC microcontroller) will be located inside my HiFi and will use the CD changer to play music appropriate to the current location and activities in the MUD. [3] Check the post date. -Jeremy Thurgood, electronic engineering student and aspiring hardware hacker. -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | | Newbie List: http://groups.yahoo.com/group/circle-newbies/ | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT