ALPP 01-04 -- Getting a Simulator for the 6801 and Running Code on It

Getting a Simulator for the 6801
and Running Code on It

(Title Page/Index)

 

I'll assume that you've already gone through the steps for getting the necessary operating system environment and tools, and have got EXORsim up and running, and have tested it with the example I gave showing how to use the accumulator to accumulate a sum of a series of constants.

Several years back, I needed (wanted?) a nice debug system for developing some 6801 code. At the time I started the project (if I recall correctly) Ciaran and his friends had not yet added MC-10 emulation to XRoar. Or maybe I didn't want to jump through the hoops of a self-hosted debugger on it. Or something.

An option I considered was to write my own 6801 simulator (a project I had already shown myself I didn't have the discipline to take to completion) or get enough of the documentation for the M6801 USE module for the EXORciser and the MC6801 EXORciser Support System to add that module to Joe Allen's EXORsim. But that latter begged the question of where to get the documentation, and whether I could afford the persuasion rate if I could find someone who had it.

A less ambitious option would be to write an alternative reality main CPU module for EXORsim, from a world in which Motorola had made the bare 6801 core available as a direct substitute for the 6800 -- in other words, with no built-in IO or RAM. It could be invoked as exor01, just as the 6809 version of EXORsim is invoked as exor09. That would allow me (and you) to use git to pull in Joe's updates without (too much) conflict with my  6801 tools. 

Just for the record, the timing differences might have meant MDOS and other system-level software wouldn't run on the 6801 simulation, even if you cleared the built-in I/O devices out the memory map.

I just wanted to run code, didn't care about timing, didn't know at the time how Joe would implement the 6809 modules, etc. So I simply made a fork of the EXORsim project (allowed by the GPL license) and added 6801 instructions (without attention to timing) to the 6800 instruction set, with a command-line switch to enable 6801 instructions. It worked for my project, and that is what I'm going to recommend you use for the 6801 here -- for now.

Which is going to take a little extra explanation.

Now, for the accumulator example, the 6801 code and execution will be exactly the same as for the 6800, so it might be tempting to skip it. But you'll need the explanation of how to get, compile, and use the EXORsim6801 tools, so we won't. And we can talk a little about 8-bit bytes vs. 16-bit words while we are at it.

EXORsim6801

There was a local code repository provider here called sourceforge.jp, and I started using them because they are local. They changed their name to Open Source Developers' Network (osdn.net) about the time SourceForge changed hands and started going a little crazy, so I started using OSDN as my main repository provider. Things have changed more since then, with some of SourceForge's original owners being able to buy it back, and all. And OSDN's team has not been able to keep it the easy-to-use place it was. And Microsoft bought Github. Etc. 

Excuses, what-ifs, and excuses, but EXORsim6801 is in my personal chambers (workspaces) on OSDN, here:

https://osdn.net/users/reiisi/pf/exorsim6801/wiki/FrontPage

It takes patience to access sometimes. If you get a timeout or a gateway error, refresh it, stop it, and refresh again, and it should come up, although, if it still doesn't come up, you may need to wait an hour or three, or a day, and try again.

I kept it in a chamber workspace because I intended to give the code back to Joe. He then told me he didn't really see the point, since it didn't reflect any real retro computing hardware or software that ever existed -- which is not unreasonable. 

If I make a real alternate reality project out of it, I should at least get the timing right, and make it a separate executable so I can pull in his updates. But that will take time I don't have.

You can read my summary from back then, and then go to the source code menu and select "source tree", or you can go directly to the source tree here:

https://osdn.net/users/reiisi/pf/exorsim6801/scm/tree/master/

On the right of the source tree page, towards the top, you'll find the git URL for cloning, and ZIP and TAR buttons for export. Hit your choice of ZIP or TAR (.tar.gz) to download, or use the git clone command to get your copy.

You should probably want to clone it or unpack the archive in a directory called exor6801 under your assembly language working directory (as in "~/asmwork/exor6801"), or use some other clear structure to keep it separate from Joe's exorsim.

After cloning or unpacking, change into the source code directory produced and do NOT do a "sudo make install"! 

Just do a "make", without sudo and without install. 

If you want to make it available without the path, when it's built, you can link it into your executable directory under a different name, such as "exorprime" or something.

But for what we want to do for the present, we can work directly in the build directory. So, in the build directory, basically do the same as you did for the 6800, except this time you'll invoke exor with two switches:

./exor --6801 --mon

Other than that, the session should look pretty much like the 6800 session:

$ cd asmwork/exorsim6801/exorsim
$ ./exor --mon --6801
Load facts file 'facts'
'exbug.bin' loaded.
'mdos.dsk' opened for drive 0 (single sided)

Hit Ctrl-C for simulator command line.  Starting simulation...

>         0 A=00 B=00 X=0000 SP=FF8A ------ OSLOAD   E800: 8E FF 8A LDS #$FF8A                Load OS

Type 'help'
% a 1000
1000: START LDAA	#8	; Gotta start somewhere.
1002:  ADDA	#5
1004:  ADDA	#2
1006:  ADDA	#7
1008:  ADDA	#4
100a:  NOP		; landing pad for breakpoint
100b: 
% u 1000
1000: 86 08               LDA #$08
1002: 8B 05               ADDA #$05
1004: 8B 02               ADDA #$02
1006: 8B 07               ADDA #$07
1008: 8B 04               ADDA #$04
100A: 01                  NOP
100B: 00                  ???
100C: 00                  ???
...
% d 1000
1000: 86 08 8B 05 8B 02 8B 07  8B 04 01 00 00 00 00 00 ................
1010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
...
% s 1000
          0 A=00 B=00 X=0000 SP=FF8A ------ START    1000: 86 08    LDA #08   EA=1001 D=08   
>         1 A=08 B=00 X=0000 SP=FF8A ------          1002: 8B 05    ADDA #05                 

Type 'help'
% s
          1 A=08 B=00 X=0000 SP=FF8A ------          1002: 8B 05    ADDA #05  EA=1003 D=05   
>         2 A=0D B=00 X=0000 SP=FF8A ------          1004: 8B 02    ADDA #02                 

Type 'help'
% s
          2 A=0D B=00 X=0000 SP=FF8A ------          1004: 8B 02    ADDA #02  EA=1005 D=02   
>         3 A=0F B=00 X=0000 SP=FF8A ------          1006: 8B 07    ADDA #07                 

Type 'help'
% s
          3 A=0F B=00 X=0000 SP=FF8A ------          1006: 8B 07    ADDA #07  EA=1007 D=07   
>         4 A=16 B=00 X=0000 SP=FF8A H-----          1008: 8B 04    ADDA #04                 

Type 'help'
% s
          4 A=16 B=00 X=0000 SP=FF8A H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   
>         5 A=1A B=00 X=0000 SP=FF8A ------          100A: 01       NOP                      

Type 'help'
% b 100a
Breakpoint set at 100A
% c 1000

Breakpoint!
          0 A=00 B=00 X=0000 SP=FF8A ------ START    1000: 86 08    LDA #08   EA=1001 D=08   
          1 A=08 B=00 X=0000 SP=FF8A ------          1002: 8B 05    ADDA #05  EA=1003 D=05   
          2 A=0D B=00 X=0000 SP=FF8A ------          1004: 8B 02    ADDA #02  EA=1005 D=02   
          3 A=0F B=00 X=0000 SP=FF8A ------          1006: 8B 07    ADDA #07  EA=1007 D=07   
          4 A=16 B=00 X=0000 SP=FF8A H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   
          5 A=1A B=00 X=0000 SP=FF8A ------ START    1000: 86 08    LDA #08   EA=1001 D=08   
          6 A=08 B=00 X=0000 SP=FF8A ------          1002: 8B 05    ADDA #05  EA=1003 D=05   
          7 A=0D B=00 X=0000 SP=FF8A ------          1004: 8B 02    ADDA #02  EA=1005 D=02   
          8 A=0F B=00 X=0000 SP=FF8A ------          1006: 8B 07    ADDA #07  EA=1007 D=07   
          9 A=16 B=00 X=0000 SP=FF8A H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   
>        10 A=1A B=00 X=0000 SP=FF8A ------          100A: 01       NOP                      

Type 'help'
% t on
% c 1000
         10 A=1A B=00 X=0000 SP=FF8A ------ START    1000: 86 08    LDA #08   EA=1001 D=08   
         11 A=08 B=00 X=0000 SP=FF8A ------          1002: 8B 05    ADDA #05  EA=1003 D=05   
         12 A=0D B=00 X=0000 SP=FF8A ------          1004: 8B 02    ADDA #02  EA=1005 D=02   
         13 A=0F B=00 X=0000 SP=FF8A ------          1006: 8B 07    ADDA #07  EA=1007 D=07   
         14 A=16 B=00 X=0000 SP=FF8A H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   

Breakpoint!
>        15 A=1A B=00 X=0000 SP=FF8A ------          100A: 01       NOP                      

Type 'help'
%   

This older version likes to give you traceback after a breakpoint, if tracing is off. You can ignore it or examine it, as you like.

But that was all a bit boring since you've done it before, twice, so, before you hit control-C to break out, let's try adding a little code that does not assemble or  run on the 6800, just to be sure we actually have the 6801 emulator running. Go ahead and type this in by hand. It's not long:

% a 100b
100b: DSTART LDD #2056
100e:  ADDD #1285
1011:  ADDD #514
1014:  ADDD #1799
1017:  ADDD #1028
101a:  NOP
101b: 

Hit enter at the blank line to quit assembling, and then display the bytes and disassemble it:

% d 1000
1000: 86 08 8B 05 8B 02 8B 07  8B 04 01 CC 08 08 C3 05 ................
1010: 05 C3 02 02 C3 07 07 C3  04 04 01 00 00 00 00 00 ................
1020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
...
% u 1000
1000: 86 08               LDA #$08
1002: 8B 05               ADDA #$05
1004: 8B 02               ADDA #$02
1006: 8B 07               ADDA #$07
1008: 8B 04               ADDA #$04
100A: 01                  NOP
100B: CC 08 08            LDD #$0808
100E: C3 05 05            ADDD #$0505
1011: C3 02 02            ADDD #$0202
1014: C3 07 07            ADDD #$0707
1017: C3 04 04            ADDD #$0404
101A: 01                  NOP
101B: 00                  ???
101C: 00                  ???

You see that my choice of numbers to add was deliberate, right?

Set the break point at $101A  and set trace on, then restart execution at $1000:

% b 101a
Breakpoint set at 101A
% t on
% c 1000
         39 A=1A B=1A X=0000 SP=FF8A ------ START    1000: 86 08    LDA #08   EA=1001 D=08   
         40 A=08 B=1A X=0000 SP=FF8A ------          1002: 8B 05    ADDA #05  EA=1003 D=05   
         41 A=0D B=1A X=0000 SP=FF8A ------          1004: 8B 02    ADDA #02  EA=1005 D=02   
         42 A=0F B=1A X=0000 SP=FF8A ------          1006: 8B 07    ADDA #07  EA=1007 D=07   
         43 A=16 B=1A X=0000 SP=FF8A H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   
         44 A=1A B=1A X=0000 SP=FF8A ------          100A: 01       NOP                      
         45 A=1A B=1A X=0000 SP=FF8A ------ DSTART   100B: CC 08 08 LDD #$0808 EA=100C D=0808 
         46 A=08 B=08 X=0000 SP=FF8A ------          100E: C3 05 05 ADDD #$0505 EA=100F D=0505 
         47 A=0D B=0D X=0000 SP=FF8A ------          1011: C3 02 02 ADDD #$0202 EA=1012 D=0202 
         48 A=0F B=0F X=0000 SP=FF8A ------          1014: C3 07 07 ADDD #$0707 EA=1015 D=0707 
         49 A=16 B=16 X=0000 SP=FF8A ------          1017: C3 04 04 ADDD #$0404 EA=1018 D=0404 

Breakpoint!
>        50 A=1A B=1A X=0000 SP=FF8A ------          101A: 01       NOP                      

Type 'help'
% 

Notice what's happening in the accumulators. 

(This additional code, by the way, also runs on the 6809.)

******

Ah. Yes. I need to mention this. 

You may be wondering, when loading integer constants into the double accumulator on the 6801 and 6809, which accumulator gets the more significant byte? It's not apparent in this code, but, in both, A gets the more significant byte and B gets the less significant byte. 

This can be confusing when reading early code for the 6800, because the 6800 was apparently designed under the opposite assumption. Check the stacking order of interrupts. On both the 6800 and the 6801, A gets pushed before B, which results in B being saved lower in memory, where the most significant byte should be. And much of the code written for the 6800, including the EXORciser EXBug monitor ROM, follows the same order, with B holding the more significant byte in two-byte operations, and being stored lower in memory.

But when loading two-byte integers into D on either the 6809 or the 6801, B gets the less significant byte and A gets the more significant byte.

The push order is fixed on the 6809, by the way.

Trivia, but not trivia.

******

This should motivate our discussion of hexadecimal, and of the limits of sizes of integers within the CPU. Play around with it, or hang on to your questions for now, either way.

Again, there are other options, including XRoar or MAME emulating Tandy's MC-10 (which actually has a 6803, but that's just a 6801 without internal ROM). Also, for MSWindows, users, VMC10 can be found in the Color Computer Archives. 

If you decide to use XRoar or MAME or VMC10 or such, you'll also need self-hosted tools like HumBug and MCOS, which can also be found in the Color Computer Archives. And, if I remember right, the syntax will be a little different, so you'll have to figure that out. (It's not hard once you have the basic ideas down.)

And all that discussion should get us a little bit more ready to go after Hatari for working on the 68000.

 

(Title Page/Index)

 

ALPP 01-03 -- Running Code on the 6800 and 6809

 Running Code on the
6800 and 6809

(Title Page/Index)

 

Now that you have EXORsim running on your workstation, let's look at how you can use it to run some code.

If you shut down after working through the last post, boot back up and change directory to get back in the directory you built EXORsim in, doing something like

$ cd asmwork/exor/exorsim

In the directory where you built EXORsim, start it up with the --mon option.

$ ./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'
% 

We can start with the 6800 example showing how an accumulator works. The 6800 code, again:

START LDAA	#8	; Gotta start somewhere.
 ADDA	#5
 ADDA	#2
 ADDA	#7
 ADDA	#4
 NOP		; landing pad for breakpoint 

Select it from the START label and copy it to the end of the NOP line.

At the % prompt in the debugger, type 

a 1000

and enter/return. 

You could type it in by hand, but since you've just selected and copied it, just paste it in. Use the right button on the mouse to pull up an edit menu over the session window and paste it. Hit enter again after the paste:

% a 1000
1000: START LDAA	#8	; Gotta start somewhere.
1002:  ADDA	#5
1004:  ADDA	#2
1006:  ADDA	#7
1008:  ADDA	#4
100a:  NOP		; landing pad for breakpoint 
100b: 
% 

What have you done?

The "a" command is the assemble command. Joe put the ability to assemble source code into the hosted debugger. (Thanks, Joe!) So you've just assembled the source code of the example into memory starting at hexadecimal $1000.

You can unassemble it if you want, with the "u" command:

% u 1000
1000: 86 08               LDA #$08
1002: 8B 05               ADDA #$05
1004: 8B 02               ADDA #$02
1006: 8B 07               ADDA #$07
1008: 8B 04               ADDA #$04
100A: 01                  NOP
100B: 00                  ???
100C: 00                  ???
...

Unassemble, disassemble, same thing. 

Note that the address specified for the debugger commands is read by the debugger as hexadecimal. (Values in the assembler itself are default decimal.)

You can display the contents of memory where you assembled it with the "d 1000" command:

% d 1000
1000: 86 08 8B 05 8B 02 8B 07  8B 04 01 00 00 00 00 00 ................
1010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
...

Now you know why it's "u" for unassemble instead of "d" for disassemble. "d" is for display. (Or dump, if you prefer, but dump can mean other things.)

How do you run it? One way is to use the "s" command, for step:

% s 1000

          0 A=00 B=00 X=0000 SP=00FF ------ START    1000: 86 08    LDA #08   EA=1001 D=08   
>         1 A=08 B=00 X=0000 SP=00FF ------          1002: 8B 05    ADDA #05                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% 

You'll see that it went to address $1000 and stepped one op-code, showing you the next op-code. And it's nice to see the op-codes disassembled. Unassembled.

Hit "s" all by itself and return and it steps the next one:

% s

          1 A=08 B=00 X=0000 SP=00FF ------          1002: 8B 05    ADDA #05  EA=1003 D=05   
>         2 A=0D B=00 X=0000 SP=00FF ------          1004: 8B 02    ADDA #02                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          2 A=0D B=00 X=0000 SP=00FF ------          1004: 8B 02    ADDA #02  EA=1005 D=02   
>         3 A=0F B=00 X=0000 SP=00FF ------          1006: 8B 07    ADDA #07                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          3 A=0F B=00 X=0000 SP=00FF ------          1006: 8B 07    ADDA #07  EA=1007 D=07   
>         4 A=16 B=00 X=0000 SP=00FF H-----          1008: 8B 04    ADDA #04                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          4 A=16 B=00 X=0000 SP=00FF H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   
>         5 A=1A B=00 X=0000 SP=00FF ------          100A: 01       NOP                      

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% 

And you can watch the effects -- watch the sum accumulate in the accumulator, and watch the program counter increment as it the simulator sequences through the op-codes.

If stepping is a little slow for you, you can set a breakpoint with the "b" command, and use the "c" command for continue, until it hits the breakpoint:

% b 100a
Breakpoint set at 100A
% c 1000


Breakpoint!
          9 A=16 B=00 X=0000 SP=00FF H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   
>        10 A=1A B=00 X=0000 SP=00FF ------          100A: 01       NOP                      

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% 

Note that the simulator's PC has to hit the exact breakpoint to stop. That's part of the reason I use the NOP as a landing pad. It's easier to see where to set the breakpoint.

But you wanted to see it trace through the operations, not just hum away in silence until it hit the breakpoint?

Use the "t" command to turn trace on:

% t on
% c 1000

         10 A=1A B=00 X=0000 SP=00FF ------ START    1000: 86 08    LDA #08   EA=1001 D=08   
         11 A=08 B=00 X=0000 SP=00FF ------          1002: 8B 05    ADDA #05  EA=1003 D=05   
         12 A=0D B=00 X=0000 SP=00FF ------          1004: 8B 02    ADDA #02  EA=1005 D=02   
         13 A=0F B=00 X=0000 SP=00FF ------          1006: 8B 07    ADDA #07  EA=1007 D=07   
         14 A=16 B=00 X=0000 SP=00FF H-----          1008: 8B 04    ADDA #04  EA=1009 D=04   

Breakpoint!
>        15 A=1A B=00 X=0000 SP=00FF ------          100A: 01       NOP                      

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% 

Fortunately, the breakpoint was still set.

And you've probably noticed by now that there's a help command. Try it now, just for grins.

Okay, you've got the basics of the debugger in EXORsim down now, you can play around a bit. 

Go ahead and try things. If it gets hung up, you can always hit ctrl-C, and if that doesn't work, just close the shell session window and open a new one. 

How about the 6809?

Here's the 6809 code for the above:

START LDA	#8	; 6809 mnemonic: LoaD accumulator A
 ADDA	#5	; Mnemonic shared with 6800/6801.
 ADDA	#2
 ADDA	#7
 ADDA	#4 
 NOP		; landing pad for breakpoint 

 In EXORsim, it's not a whole lot different. The commands are the same. The main difference is the set of op-codes and their mnemonics. 

Oh, and the command to start it running is "exor09":

$ ./exor09 --mon
Load facts file 'facts09'
'exbug09.bin' loaded.
  EXBUG09-2.1 detected
'mdos09.dsk' opened for drive 0 (double sided)

OSLOAD...

Hit Ctrl-C for simulator command line.  Starting simulation...

>         0 A=00 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            0020: 86 10        LDA #$10                   

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% 

Everything above looks pretty much the same for the code example above, except for the 6809's extra registers, for assembling, copying and pasting, disassembling, displaying, stepping, setting breakpoints, continuing, tracing:

% a 1000
1000: START LDA	#8	; 6809 mnemonic: LoaD accumulator A
1002:  ADDA	#5	; Mnemonic shared with 6800/6801.
1004:  ADDA	#2
1006:  ADDA	#7
1008:  ADDA	#4 
100a:  NOP		; landing pad for breakpoint 
100b: 
% u 1000
1000: 86 08               LDA #$08
1002: 8B 05               ADDA #$05
1004: 8B 02               ADDA #$02
1006: 8B 07               ADDA #$07
1008: 8B 04               ADDA #$04
100A: 12                  NOP 
100B: 00 00               NEG $00
100D: 00 00               NEG $00
...
% d 1000
1000: 86 08 8B 05 8B 02 8B 07  8B 04 12 00 00 00 00 00 ................
1010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
...
$ s 1000

         10 A=1A B=00 X=0000 Y=0000 U=0000 S=00FF P=00 -------- START      1000: 86 08        LDA #$08                   
>        11 A=08 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1002: 8B 05        ADDA #$05                  

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

         11 A=08 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1002: 8B 05        ADDA #$05                  
>        12 A=0D B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1004: 8B 02        ADDA #$02                  

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

         12 A=0D B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1004: 8B 02        ADDA #$02                  
>        13 A=0F B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1006: 8B 07        ADDA #$07                  

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

         13 A=0F B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1006: 8B 07        ADDA #$07                  
>        14 A=16 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --H-----            1008: 8B 04        ADDA #$04                  

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

         14 A=16 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --H-----            1008: 8B 04        ADDA #$04                  
>        15 A=1A B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            100A: 12           NOP                        

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
%  
% b 100a
Breakpoint set at 100A
% c 1000


Breakpoint!
          4 A=16 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --H-----            1008: 8B 04        ADDA #$04                  
>         5 A=1A B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            100A: 12           NOP                        

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% t on
% c 1000

          5 A=1A B=00 X=0000 Y=0000 U=0000 S=00FF P=00 -------- START      1000: 86 08        LDA #$08                   
          6 A=08 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1002: 8B 05        ADDA #$05                  
          7 A=0D B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1004: 8B 02        ADDA #$02                  
          8 A=0F B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            1006: 8B 07        ADDA #$07                  
          9 A=16 B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --H-----            1008: 8B 04        ADDA #$04                  

Breakpoint!
>        10 A=1A B=00 X=0000 Y=0000 U=0000 S=00FF P=00 --------            100A: 12           NOP                        

6809 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% 

So, give the 6809 code a try, too, looking for differences. 

Then take a rest  before proceeding to getting a simulator for the 6801.

 

(Title Page/Index)

 

ALPP XX-XX -- Running Code on the 6800, 6801, 6809, and 68000

This chapter got scratched. Kept me spinning my wheels for a month or two. But I want to keep it around for my own reference. 

• Look here for getting a simulator for 6800/6809.
  
• Look here for running code on 6800/6809. 
• Look here for 6801.
• Look here for 68000.
  

Running Code on the
M6800, 6801, and 6809

(Title Page/Index)

So, we want to run code, and we want to see the code run step-by-step.

If we had, for instance, Motorola's Micro Chroma 68 prototyping board, we could hand-assemble 6800 code and use the built-in debugging monitor to step through it. That is educational, and interesting, but those are hard to come by. (I theoretically may still have one in storage somewhere I can't access right now.) And hand-assembling code does take more time than using an assembler.

Similarly, Motorola had an evaluation board for the 68000, the MEX68KECB (Educational Board Computer), with a really nice debugging monitor in the ROM that assembled and disassembled code for you (that I probably should have bought way back when). Those ought to be easier to find, if still hard to get owners to part with, but when you search the web for them, you have to wade through a lot of retro devices that reproduce, with varying degrees of reliability, the original, or even just ride on the name. Some of those retro devices are interesting, but you have to know what you're looking at. 

If I had managed to save up enough to properly retire, I could be building a few retro projects of this sort myself, and could recommend them directly. (Sorry. That didn't happen.)

Motorola also made a full workstation for developing hardware and software for the 6800 and related parts called EXORciser. (Yes, I think it was a cool, but unfortunate, choice of name.) You could also put in a 6809 processor, for 6809 development. 

It was somewhat comparable to Intel's Intellec 8 systems, but reportedly more usable as a general purpose computer, comparable to the Altair 8800 and other S-100 systems. 

And they made a full workstation for developing for the 68000, called EXORMacs. 

But you probably won't be finding real examples of either of these to use in learning assembly language -- they are very rare now.

(Yeah, if I had the time and resources, it'd be fun to build retro replicas of both the EXORciser and EXORMacs, too.)

As an example of a home computer using the 6801, Tandy/Radio Shack's MC-10 (which actually uses the 6803 variant) is still sometimes seen on ebay and elsewhere, and is supported by an active enthusiast community (including a group on Facebook). Even though it's not really intended for learning assembly language, they'll help you gather up software and hardware to make it useful.

For the 6809, the Tandy/Radio Shack Color Computer is relative easy to find, and is also actively supported by an active (active, active!) community of enthusiasts (many of whom are also in the MC-10 community) who, again, will help you gather up software and hardware necessary to use it to learn assembly language. (Several groups on Facebook, here's one. Also, there's a mailing list that can help with both the Color Computer and the MC-10.)

The Color Computer's sister computer from the UK, the Dragon, is not easy to find, but the Dragon community is active, and generally participates in the Color Computer groups, too.

Other options exist, of course, like the SWTPC 6800 and 6809 models, also the French cousin to the MC-10, the Matra Alice. These are rather rare now. Even rarer are the Thomson line of French 6809-based computers and quite a number of Japanese computers (Fujitsu, Hitachi, and others) that used the 6800 and 6809.

If you look around and are careful about what you get, there are various retro designs that you can build yourself.

As I've noted, I don't really have room for hardware. If you don't either, you'll be glad to know that software emulators (simulators) are available that run on the kinds of PCs you are likely to already own. 

If you are running a Microsoft operating system (MSWindows), you'll be able to find several emulators with a fairly quick web search. Members of the support communities will tell you which they favor. I don't have experience with those, so I won't recommend any, but they can be found fairly easily, and are said to be good.

Also, there are several on-line 6809 emulators, but I don't want to encourage lots of people to jump on those and load them down.

One emulator I like that runs on my equipment is XRoar, developed primarily by the Dragon community's Ciaran Anscomb. It can currently emulate the Dragon, the Color Computer, the MC-10, and certain versions of the Alice. I like it as a simulator, it's fairly easy to get going and to maintain, and doesn't take up the room that the MAME monster takes up on your hard drive. And the important thing for me is that it can be compiled on Linux OSses.

One downside to XRoar is that it does not include a lot of hosted debugging tools. You have to find self-hosted debugging software, such as EDTASM+ for the Color Computer, which means additional layers to wade through. (I want to help Ciaran add hosted debugging, but so far we haven't been able to connect when both of us have had the time to get me started.)

Speaking of MAME, MAME emulation is pretty good, too. But it's big, and complicated, and I don't want to recommend it for the beginner. (I haven't even figured out how to get debugging going on MAME yet, myself.)

As you noticed, I use a Linux OS, and I will be using simulators that run on those, in particular, Joe H. Allen's  EXORsim. EXORsim was originally just for the 6800, but Joe has recently extended it to simulate the 6809 as the main processor as well.

There was a 6801 hosted development module (auxiliary card) for the EXORciser, but EXORsim does not simulate that. If I can find enough documentation and time, I may try adding support for it sometime. But not just now. 

Several years back, I wanted to do something with the 6801, and I had a little time, so I added some code to EXORsim to let the main processor execute the additional 6801 instructions. The cycle-by-cycle timing is 6800 instead of 6801, and I did not add simulation for the 6801's internal devices, but it allowed me to get a version of fig-Forth optimized for the 6801 running and somewhat tested, and even running on the MC-10. So I will use that for the 6801.

EXORsim can be compiled to run on MSWindows and on Modern Mac OS, so you may want to consider it for that, as well.

I wish I had time to write an EXORmacs simulator, for the 68000, or even to use musashi or Moira to build a prototyping board style simulator for the 68000 -- Maybe I can do that once I've put enough money away to properly retire, if there's anything left of my mind by then. 

That failing, for now I'm using the Atari ST emulator, Hatari, for this project. Unfortunately, that requires some compromises, compared with EXORsim, such as not being able to copy text output from the Hatari window with copy/paste. Screenshots, typing by hand, and disk files it will be.

So you may want to get EXORsim and Hatari to make it easier to follow along with me. These are the tools I will be referring to when I show code running on the 6800, 6801, 6809, and 68000. 

Hatari is available from repositories in many libre OSses.

In order to get EXORsim to run, you'll probably have to build it yourself. But it's not that hard, if you have fairly standard tools installed on the computer you are using as a workstation.

ALPP 01-02 -- Getting a Simulator for the 6800 and 6809

Getting a Simulator for the
6800 and 6809

(Title Page/Index)

 

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:

https://github.com/jhallen/exorsim

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.

 

(Title Page/Index)

 

ALPP XX-XX -- Getting Simulators for the M6800, 6801, 6809, and 68000

This chapter also got scratched. Just didn't work right. But I want to keep it around for my own reference. 

• Look here for getting a simulator for 6800/6809.
  
• Look here for running code on 6800/6809. 
• Look here for 6801.
• Look here for 68000.

Getting Simulators for the
6800, 6801, 6809, and 68000

(Title Page/Index)

 

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.

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. For the 6801, it will be my hack on EXORsim, exorsim6801. 

For the 68000, I will be using the Atari ST (and beyond) simulator, Hatari.

I am choosing these because they seem to me to be the most generally available and accessible.

There are other options, 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 explain getting XRoar and building it locally on your own hardware later. 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.

You may find you need to build Hatari, but, if you are running a Linux OS, there are probably packages for it in your OS's repository. So you aren't necessarily faced with gathering all the dependent libraries yourself and all that. 

For Mac OS, you can get it pre-built from the project website, if you haven't yet got a package manager running on your Mac. 

For MSWindows, there is a 3rd party project, that the Hatari project links to, providing Hatari pre-built -- if you really have to use MSWindows.

There are other options for the 68000, as well, but Hatari seems to be the easiest to get, and to get started working on. And it seems to have the least in the way of advanced OS capabilities to get in the way of introductory-level practice. 

(I really should figure out Musashi, but I want to get this tutorial written. That will come later. Also, Amiga under emulation is cool, but you want to know what you're doing before you dig into writing code on Amiga. Likewise classic Macintosh.)

MAME, of course, is an option. It does everything, and supports direct debugging pretty well (I hear), but it's huge, and a bit daunting to get started with.

But!   (OS and Compiling)

For any of these, you'll need something to run the simulators on, both hardware (PC/workstation) and software (support in the operating system). And you'll need compilers to build anything that needs to be built.

Compilers are definitely one thing you'll need anyway, as we go along. There are more tools we want to use, and you'll need to compile some of them.

If you can run a Linux OS, or Mac OS, or freeBSD or netBSD, getting the compiler and other tools is really straightforward. They can usually just be selected during the install process, or installed later through some sort of package manager.

If you absolutely must run MSWIndows --

Cygwin

Microsoft's compiler toolchain (VS) has one not-small problem. Pretty much anything you try to do with it will try to drag you off into Microsoft solutions, and if Microsoft solutions were sufficient, you wouldn't be reading this blog. 

If you must use MSWindows, the first tool you need to download is Cygwin. (LSW with a full Linux OS install might work, but I've never tried it. And LSW is Microsoft. I have tried Cygwin.)

Make sure you're accessing the real https://cygwin.com/ site, and check the checksum after you download it. 

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.)

Also, if you don't already have a favorite text editor, get either gedit or kate, or maybe Geany. Vim or EMacs will also work, if you already know them.

At which point I'm going to repeat myself. 

Ubuntu or Debian or Devuan or Mint OS, ... 

There are lots of Linux OSses to choose from, they are mostly easy to install on older hardware you might have lying around -- or on inexpensive ARM hardware like Raspberry Pi, and they all have great compiler toolchains and other tools and repositories that are easy to install from. You can also dual boot, but, really, if you don't have a ten-year old PC in a closet somewhere that you're no longer using, a Pi or something similar is pretty inexpensive.

FreeBSD or NetBSD should work pretty well, too. OpenBSD, on the other hand, is so security oriented that I'm not sure compiling EXORsim will be very easy.

All of these have install instructions on their websites, and are easy to install. (Almost too easy. Do be careful to save any important data before wiping an old computer clean.) 

Make sure you choose a minimal developer's install, with either the gnu or clang compilers, and the basic set of libraries. And, as I mentioned for those using Cygwin, install a programmer's text editor, as well -- kate, gedit, geany, vim, emacs, or whatever.

Or if you're inclined toward Mac, 

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.)

Yeah, that's a lot of stuff, just to get started, isn't it? But it's tools that you need anyway, if you are interested in assembly level programming and/or retro computing.

Once you have your system and  toolchain ready to work with, 

1. Start with downloading and compiling EXORsim6801. 
2. Then download and compile the most recent EXORsim. 
3. And then install Hatari.

Well, you can install Hatari first, but please compile EXORsim6801 before compiling EXORsim, and I should explain why.

EXORsim6801

(Title Page/Index)