Embedded CircleMUD

From: Jeremy (thurgood@goshawk.is.und.ac.za)
Date: 04/01/02

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

- 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

- 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


[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

   | 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