Electronic Projects
  • Micromite Microcontroller
  • Micromite Plus
  • The Microbridge
  • Air Quality Monitor
  • DDS Signal Generator
  • Super Clock
  • Boat Computer MkII
  • Parking Assistant
  • Micromite LCD Backpack
  • ASCII Video Terminal
  • GPS Controlled Clock
  • GPS Tracker
  • Colour Maximite Computer
  • The Original Maximite
  • The mini Maximite
  • Intelligent Fan Controller
  • GPS Synchronised Clock
  • GPS Boat Computer
  • GPS Car Computer
  • Making the GPS Computer
  • Energy Meter Firmware
  • ISM Band Scanner
  • Utility Power Supply
  • Precise Voltage Reference
  • Game of Pong
  • Water Level Meter

  • General Articles
  • Problems in Open Source
  • The Maximite Story
  • Programming PIC Micros
  • MMBasic on the UBW32
  • The TFT Maximite
  • Surface Mount is Easy
  • Measuring Capacitor ESR
  • EM-408 GPS Module
  • SG12232A LCD Driver
  • Custom PC Boards
  • The Gerber Format

  • Reviews
  • Hantek DSO-2250 Scope
  • Rigol DS1000 Scope
  • PIC C Compilers
  • Brickbats

  • PC Software
  • Weather Station
  • Mazing

  • About




    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Australia (CC BY-NC-SA 3.0)

    The Maximite Story


    This is the story of developing the Maximite, a small computer described elsewhere on this site.  It is not a particularly riveting story (like "The Soul of a New Machine") but it does illustrate the ups and downs of creating a complex device.

    It started with a simple idea and the thought "how hard could it be?" and ended up with a three month marathon and a remarkably complex and sophisticated device.

    The beginning can be traced to when I was experimenting with the PIC32, a new high performance 32 bit processor from Microchip.  It occurred to me that describing this chip and its capabilities would make a good article for Silicon Chip Magazine.  But to complete the article it needed a practical example of the chip in action, preferably something that readers could build and find useful.  The example needed to demonstrate much of the chip's capacity in a role that could not be accomplished by the smaller 8 and 16 bit chips that had been around for many years.  The question was, what should the project be?

    Eventually I settled on the idea of a simple computer running BASIC, just like the Tandy TRS-80 and Commodore 64 of many years ago.  Previously I had found a technique for generating a composite TV signal from the PIC32 in a book by Lucio Di Jasio (reference) and there should be an open source BASIC interpreter available somewhere on the Internet that could be used as a drop in module.   I thought to myself, "just how hard could it be?"

    BASIC Interpreter

    The first stage was to find a suitable BASIC interpreter.  I had a few criteria... because I wanted to emulate something like the Tandy TRS-80 the interpreter needed to be fully functional - not a cut down integer BASIC of the type that could run on an 8 bit microcontroller.  The interpreter also had to be written in standard ANSI C as that is the only compiler readily available for the PIC32.

    Another criterion was that it had to work with a console for text input/output.  Many authors seemed to have run off on a tangent implementing a windowed interface and it would be hard enough porting an interpreter without having to strip out or modify all that stuff.

    In the end I found Bywater BASIC (or bwBasic for short) and downloaded the DOS version for a test (illustrated on the right).

     It was rather ancient (the last serious update was in 1997) and it was not as polished as, say, Microsoft BASIC - but I was looking for a free interpreter with source code so I did not expect to find a refined commercial package.  I ran it through some tests and it appeared to do the job adequately enough, it even had a "user manual". 

    The only unsettling note came from the following paragraphs at the end of the "manual":

    This program was originally begun in 1982 by my grandmother, Mrs Verda Spell of Beaumont, TX.  

    She was writing the program using an ANSI C compiler on an Osborne I CP/M computer and although my grandfather (Lockwood Spell) had bought an IBM PC with 256k of RAM my grandmother would not use it, paraphrasing George Herbert to the effect that "He who cannot in 64k program, cannot in 512k."   She had used Microsoft BASIC and although she had nothing against it she said repeatedly that she didn't understand why Digital Research didn't "sue the socks off of Microsoft" for version 1.0 of MSDOS and so I reckon that she hoped to undercut Microsoft's entire market and eventually build a new software empire on the North End of Beaumont.

    Her programming efforts were cut tragically short when she was thrown from a Beaumont to Port Arthur commuter train in the summer of 1986.  I found the source code to bwBASIC on a single-density Osborne diskette in her knitting bag and eventually managed to have it all copied over to a PC diskette.  I have revised it slightly prior to this release. You should know, though, that I myself am an historian, not a programmer.

    Was this for real?  Was it a joke?   The BASIC interpreter was real enough so I did not know what to make of it.

    Postscript:   Years later a reader found the original author and he confirmed that it was just a bit of humour.


    With the important components in place it was time to get started on verifying the hardware orientated aspects (like the keyboard and video) before designing the PC board.  During this phase some additional ideas came up and were incorporated in the design.  The first was to implement external input/output pins capable of measuring voltage and interacting with the world outside of the computer. Then came the suggestion by Leo Simpson, the editor of Silicon Chip, that it should incorporate a VGA output.  Both of these were good ideas but they also added to the complexity of the PC board which was originally envisaged as being small and simple.

    After a week or two of developing the various software components, and with the basic hardware design working on a breadboard, I set about laying out the PC board.  The board turned out to be an almost perfect design with only 16 vias required, quite a feat on a PC board supporting a 64 pin surface mount chip with 0.5mm lead spacing. 

    A few prototype boards were duly ordered and when they arrived one was built - you can see it in the photo on the left.  Unfortunately the very first test revealed a fault in the connections to the keyboard, so it was back to the grindstone (or CAD software in this case) for modifications and another purchase order on the PC board fabricator.

    You might notice the title "The Mighty Mite" on the board.  This was the original name for the project but it was subsequently found that Dick Smith had trademarked the name for his version of Vegimite in the Australian market. So I also had to find a new name.

    While waiting for the second set of boards I made up an adapter cable to get around the keyboard mistake and started working on integrating and testing the software components developed earlier.  The aim was to have the firmware completed within a week or two.

    Not So Easy

    As integration progressed it gradually became obvious that bwBasic was not going to be a simple drop in module.  For a start it had a bewildering set of options (implemented as #define constructs in the C language) and these obscured the underlying workings of the code.  Also, I was discovering a distressingly large number of bugs and was further dismayed to find that the interpreter would often fail to execute a program downloaded from the Internet that it should have been able to run without fault.

    With most of the basic functionality working it was time to concentrate on the bwBasic bug list - but it seemed that some of them were going to be almost impossible to fix.  This was because bwBasic had started as a simple unstructured programming project (written by a grandmother?) with many additions and features tacked on by many people over the years.  For example, there was no clear method of detecting when the end of a statement had been reached and the code for each statement had its own method of figuring out if this point had been found.  When I tried fixing a bug related to statement separators (the colon character) I found myself having to modify many sections of code and when I did this I just uncovered or created even more bugs.

    By now I was a good 8 weeks into development with almost 5 of these spent working on bwBasic and still no end in sight.  The breaking point came when Mauro Grassi of Silicon Chip suggested that I add an SD card to the design. What a good idea!   Why hadn't I thought of that before?  The problem was that bwBasic was so fragile that I could not see myself adding support for this without causing a host of additional problems and anyway, bwBasic had so many bugs that no one would take the project seriously, with or without support for an SD card.

    After another fruitless search for a suitable interpreter on the Internet I came to the conclusion that there was nothing for it but to write my own BASIC interpreter... from the ground up.  In what was becoming a common refrain I thought to myself, "just how hard could it be?"


    Because I was reversing out of a blind alley and throwing away 5 weeks of work I gave myself a deadline.  The new interpreter had to be written in 7 days.  I did have the advantage of knowing what NOT to do by virtue of working with bwBasic, so the first step was to design an architecture that would support the new interpreter without having to be hacked and changed as new functionality was added.  The second step was to design an execution engine that all parts of the interpreter could use when decoding BASIC statements.  That way, when a bug was found, I only had to fix it once, rather than in the code for each statement.

    To cut a long story short the new interpreter (titled MMBasic) was up and running in 8 days.  Those days were very intense, often starting at 5 in the morning and finishing in the early hours of the next day.  My then wife got used to me hardly eating and walking around distracted while trying to unravel the endless details stuck in my head.

    To be fair I should add that MMBasic needed an additional week to fill in the gaps and add some polish but in retrospect it was still a good decision to build my own.  I can now fix bugs rather than just record them and the interpreter is robust enough to be published on the Internet for some other adventurer who needs a BASIC interpreter.

    The Maximite

    The saga was not over though, there was still the requirement to design a third PC board, this time to accommodate the SD card. By now the project was looking more and more like a "real" computer and it needed to be housed in a proper box - so the new PC board was bigger and sported more connectors.  This third design was dubbed the Maximite and it has subsequently appeared in Silicon Chip and is described elsewhere on this site. I had always felt a little sad that the original simplicity of the project had became lost, so later I designed a minimalist version of the PC board (without VGA or SD card support) which is called the mini Maximite.

    Overall the project took just over 3 months to complete with most days being occupied on the project.  In retrospect the process was not all that bad and it made a great learning experience but hopefully I will be more careful in the future when I ask myself "just how hard could it be?"

    For information on the Colour Maximite click on these links:

    For details of the original (monochrome) Maximite click on these:

    Other useful pages: