I recently finished modifying my SBasic compiler so it generates code for the Motorola 68000 family of devices. This new compiler, which I call SB68k, should make it easier for beginners to start out with the host of 68332 robot boards being developed by other SRS members. As with the older 68hc11 version of SBasic, SB68k is free for all; just hit my web site at: www.seanet.com/~karllunt and follow the links.
The SB68k compiler runs on a PC (386 or higher) in a DOS window or in DOS directly. It translates your source file of Basic code into an assembly language file for the target machine; in this case, a 68000-type MCU. You then use the as68k assembler (also supplied in the SB68k release), to translate this assembler source file into an object file for transfer to your 68332 board. Copy the object file into the 68332's memory, hit reset, and your program is running!
If you're familiar with the 68hc11 version of SBasic, you should feel right at home with SB68k. You'll see all of the original SB statements and functions, though I've had to make a few changes in how they work, to accomodate the 68000's larger register model and data path.
If you've never seen SBasic before, the following paragraphs might be a bit confusing. I encourage you to download the SB68k distribution files and leaf through the 65+ page manual that is included. It goes into far more detail than I can provide here.
The biggest difference between the two versions of SB lies in the size of variables. All variables are now 32 bits, rather than 16. Since SB uses signed integer math, this gives your variables a range of 2,147,483,647 to -2,147,483,648. If you use SB's unsigned integer operators, your variables span 0 to 4,294,967,295. Now that's got to be enough range for most robotics projects!
SB for the 68hc11 supported one-dimensional arrays, but SB68k also handles two-dimensional arrays. This should make mapping mazes and landscape much easier
All of the original SB functions and statements have been expanded to use 32-bit operations. For example, addition, subtraction, the boolean operators, the shift and roll functions ... all work with 32-bit values. This includes PEEK() and POKE, but I've added PEEKW() and POKEW to handle the 16-bit accesses, and you still have the PEEKB() and POKEB for 8-bit operations.
Using interrupts in SB has always been easy, and SB68k builds on that support. Your code can now use the INTERRUPTS statement to turn global interrupts on or off, and also to set the maximum allowed interrupt level. This can come in handy when your code needs to adjust priority of interrupts.
SB68k also supports the ASM and ASMFUNC statements, allowing you to embed native 68xxx assembly language source inside your SB68k program. Even though code written in SB68k runs about five times slower than hand-crafted assembly, which should be plenty fast enough, you sometimes need the raw speed that only assembly can provide. If so, SB68k provides the access. Your assembly language code can even refer to SBasic variables and addresses, and you can write functions in assembly that your SB68k code can invoke.
Unlike the 68hc11 used with the older SBasic, the 68xxx doesn't normally include a serial port. In the case of the 68332, used on several SRS boards, a serial port is included, but making that port act as a serial interface can be a real pain if you have to roll your own code. The SB68k distribution package on my web site includes two library files that provide support for character I/O using calls to Motorola's 332BUG monitor, available on many 68332 systems. If your target hardware uses a different type of monitor, or no monitor at all, you can use these library files as a starting point to building your own routines. Additionally, others in the SRS have already integrated SB68k's run-time libraries with some of the newer 68332 boards, so you should be able to pick up some tips via the listserver or the meetings.
Another small hurdle you will need to overcome concerns the reset vector. The 68hc11 had a very simple reset method; following power-up, the MCU fetched the contents of $fffe-$ffff and jumped to the address it found there. Couldn't be much simpler...
The 68000 systems, however, want all of their vectors, including the reset vector, starting at address $0000. Since you will normally want to change these vector addresses after your code is running, this area of memory usually starts out as ROM (to keep the reset vector intact), then switches to RAM a bit later. It's this switchover following reset that gets tricky. If the supplier of your target 68xxx system has already worked out these details, fine; you shouldn't have any trouble figuring out how to make SB68k generate the correct code. If this switchover mechanism isn't available, or if the system hasn't been defined for you, you will need to ask some questions before you're ready to start running SB68k applications out of reset.
Here's a sample SB68k program to show you how the whole system works. This program fills a large chunk of RAM on the target 68332 system with a specific pattern, then tests that memory to verify that the pattern was successfully written.
After compiling this program and assembling the resulting assembly source file (memtest.asm), move the object file (memtest.s19) into your 68332 board's target area and begin program execution. You should see a series of sentences describing whether an area of memory is "good," as in RAM, or "bad," as in ROM, non-working RAM, or unmapped.
Notice that this program does not set up the serial port; it relies on the two library files mentioned above to do that task. If your target hardware isn't compatible with 332BUG, you will have to write new versions of these library files before you can make this program run.
Here is the invocation line I used to compile this program for my system:
sb68k memtest /c3000 /v5000 /s4f00 /i >memtest.asm
As you can see, I compiled the program so the code resides at $3000, the variables at $5000, and the stack at $4f00. The /i option stops SB68k from creating any program vectors, including the reset vector. To run the program, I downloaded it into RAM on my target board, then used the 332BUG GO command to begin execution at $3000.
I encourage you to copy this program into your work area and compile it. The resulting assembly language source is quite instructive. I especially like not having to write the assembly language file myself! The whole idea of a compiler like SB68k is to let the compiler handle the grunge work of writing low-level code. You, after all, have more important things to do, like play with your new 68332 robot.
Keep on keeping on,
' ' memtest.bas test memory range in the 68332 EVB ' declare n declare good const START = $5010 const FINISH = $1ffff main: print printx "Filling memory from "; START; " to "; FINISH for n = START to FINISH step 4 poke n, n next printx "Testing memory from "; START; " to "; FINISH good = 1 printx "good "; START; " to "; for n = START to FINISH step 4 if peek(n) = n if good = 0 printx n printx "good "; n; " to "; good = 1 endif else if good = 1 printx n printx "bad "; n; " to "; good = 0 endif endif next printx n end