Getting a Simulator for the
6800 and 6809
Okay, so we've introduced assembly language by talking a little about adding small integers. But if we want to understand what's going on, we really need some way to watch what the processor does when it executes the code.
If I had more time and money, I would design my own hardware and build my own
simulator software, and offer the hardware for sale and put the software up
for download and all that, and it would all be real easy to use.
(Of COURSE! ;-)
Fortunately, there are useful simulators (software-based emulators) already available, as I have mentioned.
There are options other than the one I'm recommending, such as XRoar for the 6809 and 6801, which simulates the Dragon, the Tandy Color Computers 1, 2, and 3, and the Radio Shack MC-10, and the original Matra Alice 4K. If Ciaran doesn't beat me to it, I may try (again) to add hosted debugging to XRoar, but you can always run a self-hosted debugger (such as Disk EDTASM) on the emulated computer.
Now, Ciaran and his friends do provide an on-line emulator, and you can download Disk EDTASM and run it on the on-line simulator, but I don't want to be encouraging lots of people to put a heavy load on Ciaran's server.
I'll talk a little about getting XRoar and building it locally on your own hardware and using EDTASM for debugging later, but It's a pretty steep start-up for a topic that already has a steep learning curve.)
Similarly, VCC for MSWindows requires compiling (if I read the website right), and only emulates the Color Computer 3 (6809). I think I have heard that it supports direct debugging fairly well, but cannot vouch for that. It might be an option if you're running MSWindows.
Both VCC and Xroar require several libraries that are themselves dependent on other libraries, so building them is not necessarily straightforward. I want to avoid that kind of mess as a requirement.
Yes, MAME would work, too, but it's huge. Just huge. I understand it provides
hosted debugging, but I have not gotten that far with it yet. It does tend to be available on a number of common platforms.
So,
EXORciser
What I will use for 6800 and 6809 code, especially in the first part of this, will be Joe. H. Allen's EXORciser simulator, EXORsim.
(I suppose the name, EXORciser, was a deliberate pun on Motorola's part. Both
hardware and software needs exercising to find weak places, and sometimes
debugging designs does seem to be a little like exorcising demons. But it does
make searching for information on it a little difficult now. Looking for
EXORsim, in particular, will find your search engine determined to tell you
about exorcism, instead.)
The EXORciser was Motorola's 6800-based workstation microcomputer for developing both software and hardware for the 6800. It ran an operating system called MDOS provided by Motorola, along with applications supplied by Motorola and 3rd-party developers.
The EXORciser was a little expensive compared to popular microcomputers that
came out shortly after, but it turned out to work well enough as a general
purpose microcomputer to be used as an office computer, as well. Southwest
Technical Products (SWTPC) and others released microcomputers based on, and somewhat
compatible with the EXORciser, with less support for hardware development, but
also less expensive.
When Motorola introduced the 6809, they developed a CPU board for it with the
6809 replacing the 6800, and the software was kept mostly compatible, not
taking full advantage of the 6809's improved architecture.This allowed the same Exorciser hardware to be shared across projects using each processor.
EXORsim
Joe Allen's EXORsim simulates in software both the EXORciser, and the SWTPC
6800-based microcomputers. Recently, Joe added the 6809, so it can be used for
both CPUs, as well.
EXORsim is very convenient, in that the simulated terminal allows you to copy and paste, simplifying the process of getting code and data into the simulated microcomputer.
More importantly, it can be compiled easily on pretty much anything that supports ANSI C and a few of the basic POSIX libraries, which includes, well, lots of OSses and lots of compiler toolchains. In specific, you can definitely compile it on pretty much any Linux OS, Mac OS, or BSD OS, with the GNU compiler or CLang toolchains. You can also compile it on MSWindows with the Cygwin environment and compilers.
(It should be possible to get it working under Microsoft's LSW, but I don't
want to take the time to verify that. If you go that route, save yourself some
time and go ahead and load Ubuntu or openSUSE or whatever on top of LSW, and
work in that.)
You'll need the compilers and toolchains anyway, so you'll need to go ahead and get them now.
Old PCs running a Linux OS or BSD OS
If you aren't already using a Linux OS or Mac OS or freeBSD or netBSD, and you have an old (from even as long as 15 years ago) PC you aren't using, with 4 GB or more RAM, 40 GB or more of hard disk, and a CPU with at least two physical cores running faster than 1.2 GHz (or one core running faster than 2.5 GHz), you can save any data on it that you might need, wipe it clean, and install Devuan, Ubuntu, Debian, Mint OS, Cent OS, openSUSE, NetBSD, or FreeBSD or whatever on it.
(Note that openBSD may be a little too security-oriented to compile EXORciser and Hatari easily.)
Do remember to check it for important data before you do, and to back any
important data up somewhere safe.
Or, if it has at least 80 GB free on the hard disk, you might be able to defragment it, resize the MSWindows partition, and install the Linux or BSD OS in a dual-boot configuration. It's still best to back up any important data first.
If the old PC is a little tighter for resources than that, Ubuntu provides LUbuntu and
XUbuntu that might fit, and Debian and the others can be configured with a
light-weight window and desktop manager, and so forth.
While you're installing the OS, make sure you also install the C compilers, either GNU or CLang, and the POSIX libraries. (These should come along with any basic developers' environment option the distribution provides.)
Also make sure you install a programmers' text editor, such as gedit, kate, geany, VIM, or eMacs. And a command-line terminal window emulator for running commands in, like Xterm. And if your choice of Linux OS has gforth in the repositories, you might want to grab that, too, but it isn't, strictly speaking, necessary.
Just for the record, I do not recommend dual-booting. You tend to avoid switching back and forth, so you tend not to do things that require switching.
If you're not dual-booting, installing a Linux OS is really not that hard. FreeBSD or NetBSD will be a little on the difficult side for some people. They all have instructions on their sites oriented towards the technical level of people that the OS is geared towards, and these days it's relatively rare to run into exceptions in the install process. Look at the install instructions and pick one that feels comfortable.
Just one thing, again -- don't forget to check the hard drive for valuable data, and make sure you back anything important up off to some external medium, like an SD card or a USB memory device.
(Porn collections? Go ahead and wipe 'em. Retro computing is way more fun.)
Daily-driving User Account!
Oh, and one more thing. Just one. Promise.
PLEASE! for the love of peace, sanity, and a computer that can be somewhat protected from its internet connection, make yourself a non-admin privilege daily-driving user account to work in.
Once the default administrator-capable account is created, and everything you chose in the OS install is loaded, find where you can add users, and add a user without administrator privileges. This account should be the one you use for surfing around the internet, and for working on retro stuff, etc.
This is true no matter what OS you choose.
I know it requires some learning of how to handle privileges and such, but it's worth it for the peace of mind and the trouble you don't end up causing others so easily.
ARM based lightweight computers
If you don't have an old computer, a Raspberry PI or similar ARM-based lightweight computer can be had for pretty cheap, and versions of Debian or Ubuntu or NetBSD (in particular) can be loaded on them. Raspberry Pi, in particular, comes with Raspberry PI OS (Raspbian) already installed by default, which is basically Debian pre-customized and pre-loaded on the PI.
To find other computers similar to the Raspberry PI, search for "computers similar to raspberry pi" and you'll get links to lots. Le Potato, Orange, and Odroid are trending as I write this.
Note that I don't have any experience on these, but the ones named above should just work.
Mac OS
Doing this under Mac OS will also be pretty straightforward, and you don't have to worry about installing the OS. You will need to install the BSD developer tools subsystem (cough), well, I mean, XCode, which has the compiler toolchain. But that's straightforward, too. All the libraries and bc should just come with XCode. And XCode has its own integrated editor, so you don't need to choose a text editor. (But there are lots of great 3rd party text editors available, too, including those I mentioned for Linux and BSD OSses.)
MSWindows and Cygwin
If, for some reason, you must use an MSWindows computer for this project, you probably want Cygwin.
Visual Studio will have you jumping through hoops of Microsoft telling you,
"Let us help you! Let us HELP you!!!!!" and sending you on wild goose chases,
mostly to get you corralled back into their world. That's not why you're
reading this blog. Yes, LSW might work. If you load a Linux OS on top, it
should work. But if you have questions about that, I haven't been there, and
I'm afraid I won't give them priority.
So I recommend Cygwin if you can't do a Linux, BSD or Mac OS.
Make sure you're accessing the real https://cygwin.com/ site, download the installer, and check the checksum of the installer after the download is complete.
For MSWindows 10, the command-line command for checking checksums was
certutil -hashfile <TYPE>
search the web for how to specify the type of checksum, etc.
Once Cygwin is installed, open up the installer again and get either the gnu C
compiler or the Clang compiler. Either should work. And you'll need the ANSI
and Posix libraries. While you're at it, get bc, too. (I think it's in the
repositories.) I don't think they currently have gforth in the repositories,
so we'll just kind of punt on that. Terminal emulation should be in the
default install.
Get a text editor (see above).
VS Code? I'm not going to tell you don't do that, but give yourself an
alternative. Get a separate text editor so you can dodge when Microsoft's
stuff wants to fight with you.
Checking your environment
We need to check that the compiler works. Open up a terminal emulation window (XTerm or equivalent, Cygwin shell if you are using Cygwin) and type
cc --version
and it should report which compiler and which version. GNU's toolchain will
tell you it's from the Free Software Foundation, and Clang should report that
it's clang. Both should give you a version number.
If you're not getting that, check your package manager to see whether it gave you an error or something when it tried to install the compiler and toolchain.
When you get a version number, make a working directory and change into it, something like
~$ mkdir asmwork
~$ cd asmwork
~/asmwork$
open up an editor window or editor session and type the following program in and save it in asmwork as "beachead.c":
/* beachead.c
** by Joel Rees, Japan; assigned to public domain.
*/
#include <stdio.h>
#include <stdlib.h>
int main( int argct, char *args[] )
{ char * arg1 = ( argct < 2 ) ? "none" : args[ 1 ];
printf( "%s on the beach\n", arg1 );
return EXIT_SUCCESS;
}
Compiling and running it should give you something like this:
~/asmwork$ cc -o beachead beachead.c
~/asmwork$ ./beachead one
one on the beach
~/asmwork$ ./beachead
none on the beach
(Type what comes on the lines after the "$" dollar sign prompt. The computer should respond with the lines without the prompt. Don't forget ./ before the program name, so the shell knows that the beachead program is in the directory you are in.)
Compiling EXORsim
Once you have your system and toolchain ready to work with, open your web browser and go to Joe Allen's EXORsim repository on github:
And read through the description. For the record, we won't need to use MDOS or FLEX, and we won't need to use blank disk images. Not at this point. Maybe later. Also, whether you install EXORdisk in your system's /usr/bin to make it available to every user, or just run it from your user directories, will be up to you.
You can find a link to download the source as a .ZIP archive file by clicking
the [<> code] button above the directory listing. Make a directory for EXORsim under the
asmwork directory (such as "~/asmwork/exor") and unpack the archive there. Drag, select, and click in
your GUI should work.
Alternatively, you can copy the URL shown there and use the git clone command
-- if you've installed git. (It's worth installing, by the way.)
Change directory into the exor directory you made and then into the source code directory, if you didn't end up with the source code directly under the exor directory that you just made. Check the README file, and ...
Hold on. The build instructions you have read are okay, if you want to install it where you any user on your system can run it. If you don't want to do that, you can just make it without the sudo or runas command.
If make does not successfully complete, you'll need to look at the error messages to see if you need a library or something. But it should successfully complete on any of the OSses I've described above, if you have the ANSI and POSIX libraries installed.
If you have problems, leave a message in the comments here and I'll try to get back to you.
Now, if you don't want it installed system-wide, but you don't want to type the full (relative) path every time you run it, you can add a directory for locally runnable stuff in your user directory. Call it ~/me/prg or something you like, and add it to your search paths. Then make a symbolic link from the compiled object files into your local programs directory and you're set.
For now, you can run these from the directory where they are compiled. Type
$ ./exor -?
and the 6800 version of EXORsim should give you some helpful output about how
to run it. For now, type "./exor --mon" and hit enter:
$ ./exor --mon
Load facts file 'facts'
'exbug.bin' loaded.
EXBUG-1.1 detected
'mdos.dsk' opened for drive 0 (double sided)
OSLOAD...
Hit Ctrl-C for simulator command line. Starting simulation...
> 0 A=00 B=00 X=0000 SP=00FF ------ 0020: B6 E8 00 LDA E800
6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
%
and you are in the hosted debugger, being prompted to type a command. (The "%" is the prompt in the hosted debugger.)
And that is enough for this post. (It has likely been a long road, really.)
Type Q or ctrl-C to quit. Or leave it there and continue with the next post, if you aren't tired out.
Next post will be a short introduction to using EXORsim for running code on the 6800 and 6809.
No comments:
Post a Comment