Blink the LED “Hello World!”

This is the second installment in a series exploring 65xx technology. My first post was a high-level introduction to the W65C265SXB and a wonderful little gem called the Monitor ROM. Now it’s time to take the next step and blink the LED (P72) on W65C265SXB, which is located in the middle of the board just above the W65C265S 16-bit Microcontroller chip. Blinking the LED in the embedded world is synonymous with writing a “Hello World!” program in software. I’ve written many “Hello World!” programs over the years in numerous programming language however, those pale in comparison to controlling something tangible like an LED at the lowest level.

Ok, so there are few ways in which you can control the LED (P72) on the W65C265SXB:

  • C Language program
  • Assembly Language program
  • Loading an S28 record via the Monitor ROM
  • Manually entering opcodes via the Monitor ROM

I might be able to guess your reaction to this list… “c program, not a big deal…I just need a little time to get back up-to-speed”, “assembly language, ah, hmm…I’m sure I can find some examples on the internet”, “S28 record, what is that?” and finally “opcodes, that sounds hard!” I’m going start from the ground up by using opcodes. Why? Well, I believe the best way to an understanding of how to program 65xx technology is to start with a simple exercise at the lowest level by talking its language, i.e. machine code.

Software engineers gain in-depth knowledge of their tools and high-level programming languages over years of experience. However, few engineers seek to decode the output of a compiler (e.g. Assembly language or machine code) or hexdump of an executable mainly because it’s unnecessary, which I agree. I’m going to provide you with a glimpse “under the compiler” in order to gain a deeper level of understanding. If you haven’t been here before, enjoy this new world that’s been here all along. So, lets get started with a quick review of the Monitor ROM.

Monitor ROM

As I mentioned previously, the Monitor ROM (aka Monitor or Mensch Monitor) provides you with an interface into the mask ROM of the W65C265S. The Monitor was designed specifically for the W65C265S and it resides in the 8K byte mask ROM.

The W65C265S has a 8K byte mask ROM from $00:E000 to $00:FFFF. This may be enabled or disabled by hardware or software. The mask ROM is added to the chip as part of the manufacturing process. – W65C265S Monitor ROM REFERENCE MANUAL

The Monitor is the main reason why I decided to first buy the W65C265SXB over the other boards. I think of the Monitor like a Bash shell for the W65C265S. It behaves more like a REPL with its rich interactive environment to load, run and debug programs. Moreover, I like the idea of having a board with a built-in tool to assist with learning the technology. I simply need a terminal application, usb cable and board.

Serial Terminal

CoolTerm is the terminal application I’m using to connect to the 265SXB via the J5 USB connector. CoolTerm is great cross-platform terminal built for communication with hardware connected to serial ports. The default serial port options in CoolTerm work the 265SXB. You will have to specify the port where the board is connected. If you do not see the connected port in the dropdown list simply click on the Re-Scan Serial Ports button to re-populate the Ports list.

CoolTerm options for connecting to the W65C265SXB
CoolTerm options for connecting to the W65C265SXB

Once you have CoolTerm configured, simply click the Connect button and you’ll see one ‘.’ in the upper left corner of the screen. Also, the bottom footer will indicate ‘Connected’. Then press the Reset button (RESB) on the board and you will see the initial screen of the Monitor.

CoolTerm connected to the W65C265SXB
CoolTerm connected to the W65C265SXB

Ok, our tools are setup and we’re ready to go! I really like the simplicity.

How to blink the LED Using Opcodes

Yes, that’s right opcodes (aka machine code)! We don’t need no assembler! Well, not for this simple task. Opcodes (operation codes) are individual instructions from a machine’s language. A machine’s language is defined by an Instruction Set Architecture (ISA). So, since we’re working with 65xx technology we’ll be using instructions from the 65xx ISA called ARA (Addressable Register Architecture).

The 65xx ISA was used to define RISC within the Microprocessor Report many years ago.

According to the datasheet, we’ll be writing our opcodes in cache memory locations within $00:0200-$00:7FFF. Great, but where is that exactly? You can find the chip set on the board labeled “32KByte SRAM”.


Let’s blink the LED and then explain what is happening. In the Monitor User Console:

  1. Press ‘M’ key
  2. Enter 002000. This is the starting memory address.
  3. Enter the following 12-byte sequences of hex characters and then press Enter.
  4. A9 00 8D 23 DF 00 A9 04 8D 23 DF 00

  5. Press the ‘J’ key
  6. Enter 002000 to turn ON the LED
  7. Press the ‘J’ key
  8. Enter 002006 to turn OFF the LED

Congratulations! You just turned an LED on/off with machine code, woot!

Loading a program using the 'M' command
Loading a program using the ‘M’ command
Using the 'J' command to turn the LED on and off
Using the ‘J’ command to turn the LED on and off

Now lets understand what we’ve done. The ‘M’ command (Change Memory) is used to view and change data in memory locations. So, when you entered $00:2000 you will see 16 memory locations starting with $00:2000 and ending at $00:200F. When you entered the 12-byte sequence of hex characters you modified memory locations $00:2000 through $00:200B. In other words, you loaded your program into memory.

The ‘J’ command (Jump to subroutine) executes a program in memory. We actually have two programs in memory; one starting at location $00:2000 and the other starting at $00:2006. When you entered ‘J’ then $00:2000, the first program executed from $00:2000 and stopped at $00:2005 hence turning on the light. When you entered ‘J’ then $00:2006, the second program executed from $00:2006 and stopped at $00:200B hence turning off the light.

What generates the opcodes?

So, where did we get the 12-byte sequence of hex characters? Now we work our way up to the first level of abstraction, Assembly Language. The 12-byte sequence is a product of the Assembler. Here is the actual Assembly listing:

LDA #$00  ;Load the A register with $00 which turns on the P72 LED
STA $DF23 ;Store A to turn on the LED using absolute addressing P72
BRK       ;Break back to the embedded Monitor
LDA #$04  ;Load the A register with $04 which turns off the P72 LED
STA $DF23 ;Store A to turn off the LED using absolute addressing P72
BRK       ;Break back to the embedded Monitor

If you take this listing and assemble it then perform a hexdump you will see the 12-byte sequence you entered earlier.

A9 00 8D 23 DF 00 A9 04 8D 23 DF 00

I recommend taking a look at Easy 6502 for a great introduction to 6502 Assembly language. There is a Javascript 6502 assembler and simulator on the page where you can copy and paste the listing above and perform a hexdump and see for yourself.

What really helps tie everything together is to disassemble the assembled listing and you’ll see the association between the opcodes (hexdump) and assembly language. I used the Easy 6502 assembler to disassemble the listing. The address locations are different in the Easy 6502 simulator than on the 265SXB so you can ignore the Address column. Now the relationships should be very clear.

Address  Hexdump   Dissassembly
$0600    a9 00     LDA #$00
$0602    8d 23 df  STA $df23
$0605    00        BRK 
$0606    a9 04     LDA #$04
$0608    8d 23 df  STA $df23
$060b    00        BRK

I’ve seen the “light” and now I’m hooked. So, what else can this board do?

Leave a Reply