What is ARA?

Posted on October 7, 2015October 29, 2015 by Rod

In previous blog posts I’ve mentioned some terms like “65xx ISA” and “Addressable Register Architecture (ARA).” I suspect most software engineers have conceptual knowledge of instruction sets and their classification. As an example, the x86 instruction set is much more complex than the reduced instruction set of the ARM. This is where the terms CISC and RISC get thrown around and most conversations end. I felt compelled to do more research to deepen my conceptual knowledge and find out where ARA fits in the landscape of ISAs. That’s my goal of this post. If you’re looking for something more in-depth then you’ll likely have to keep looking but check out the Fun Facts before you go. A special thanks to my uncle Bill Mensch for providing information on ARA and tolerating my basic knowledge questions.

In order for me to understand ARA, I needed to get a better understanding of ISA. So, like most, I looked to the internet. I was not setting out to do a “deep dive” but just to gather enough information to get some context. The “aha” moment for me came when I discovered the separation between the ISA and the underlying microarchitecture of a microprocessor. A microarchitecture is a given way to implement an Instruction Set Architecture. I immediately saw similarities in the relationship between the Java Virtual Machine (JVM) specification and runtime being analogous to an ISA and microarchitecture. Oracle maintains JVM specifications (e.g. Java SE 7) that can be thought of like an Instruction Set Architecture. As most software engineers know, Oracle also offers a implementation (or runtime) of the JVM specification similar to how a microarchitecture implements an ISA. There are 40+ implementations of the JVM specification including the Dalvik and ART JVMs that make up the Android runtime. So, now it was clear to me the role of an ISA and I can start pestering uncle Billy about ARA. 🙂

Bill told me that he coined the term Addressable Register Architecture (ARA) about 5 years ago to describe the 65xx ISA. According to him, “…there had to be an essential architectural advantage to explain the extremely wide and successful application of the 6502 and it’s decedents (W65C02, W65C02S & W65C816)“. Bill explains his realization to me in an email:

…I realized that the wider data widths such as 64-bit floating point operations might be the key. So it was always related to by Motorola and others as “memory mapped IO” but no one actually looked at the fact that the floating point registers were in “page Zero” and could have been anywhere in memory. Page Zero was selected because it uses less machine cycles. Using a C compiler, other registers are stored in memory. Actually, all IO registers are “addressed” and that is how I arrived at defining the 65xx as an ARA. – Bill Mensch, Oct 2015

ARA gives 65xx ISA a unique identity which is neither CISC nor RISC. So, in my “layman’s world” I think of ARA as an ISA that is the “best of both worlds” sitting nicely in between CISC & RISC. This is where I leave you to continue exploring and digging deeper if you desire. This is a fascinating world that is extremely complex.

Before you leave, take a look at the Fun Facts, I think you’ll be surprised!

Fun Facts

Fun Fact #1: Did you know that a microarchitecture has more affect on power, energy and/or performance than instruction set architectures, e.g. CISC or RISC? Here’s a great EETimes blog post (RISC vs CISC: What’s the Difference?) that reveals this finding of a 4 year study from the Vertical Research Group.

Fun Fact #2: “The ARM engineers Steve Furber and Sophie (then Roger) Wilson visited me in my WDC Mesa offices the November-December time frame in 1983 asking me to design a 32-bit microprocessor which could have been best described as a RISC processor. They were partially funded by Apple for around $3M and Apple used the Acorn RISC Machine (ARM) in the failed Newton PDA. Acorn RISC Machine became Advanced RISC Machine and in an attempt to get away from the RISC identity became just ARM.” – Bill Mensch, June 2015

…Bill respectfully declined to design the 32-bit microprocessor for the ARM engineers.

Fun Fact #3: The 6502 made an appearance in the first Terminator movie! The T-800 HUD (Head Up Display) features 6502 assembly code. It was determined to be Apple-II code taken from Nibble Magazine. (http://www.pagetable.com/?p=64) The feature image is from the T-800 HUD.

Blink the LED “Hello World!”

Posted on June 30, 2015 by Rod

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

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.

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:

Press ‘M’ key
Enter 002000. This is the starting memory address.
Enter the following 12-byte sequences of hex characters and then press Enter.

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

Press the ‘J’ key
Enter 002000 to turn ON the LED
Press the ‘J’ key
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?

The W65C265SXB 65xxcelr8r Board

Posted on June 12, 2015July 7, 2015 by Rod

I’m a software engineer working as a consultant for Chariot Solutions developing software solutions for clients to solve business problems. My path to becoming a software engineer started in hardware specifically integrated circuits while working at the Western Design Center (WDC) in the late 1980’s. It was at WDC where I learned how to layout circuits in a work-study program while studying Electrical Engineering at Arizona State University. Later, I changed majors and finished school with a B.S. in Computer and Information Sciences.

The last few years I’ve been focused on mobile applications primarily developing native Android applications. It’s very satisfying building apps that run on devices that you can hold in your hands. A refreshing change from building enterprise server-side software that runs on virtual machines in a cloud located somewhere on this planet. I still enjoy developing apps for mobile devices however, I find myself wanting to get back to my roots and get “closer to the metal”…to quote my Uncle Bill Mensch who taught me about integrated circuits years ago. Uncle Bill and I continue to stay in contact and have had many discussions on technology, philosophy, Embedded Intelligence, business, and family.

So, I’m one of 11 million professional software developers in the world today. My goal is to explore 65xx technology and share my experiences through the eyes of a software engineer. The first step starts with the W65C265SXB.

W65C265SXB Board

What is a W65C265SXB? The W65C265SXB (Standard chip Xxcelr8r Board) is a board designed for developing Hi-Rel (High Reliability) low-power applications for the W65C265S microcontroller. You can read about all the features of this board in the datasheet. WDC explained to me that their microcontrollers are general purpose making them ideal for use in industrial control systems, e.g. weigh belt conveyor systems, industrial refrigeration, access control, general communication, etc. The W65C265S is built on the 65xx Instruction Set Architecture (ISA), which is a very efficient ISA (benchmark comparison). Most microcontrollers today are RISC-based like the Atmel ATmega328 used in the popular Arduino Uno board. The difference in instruction set architectures is an important distinction. There are many RISC-based microcontrollers in the market however, there are only two (W65C134S & W65C265S) that are based on 65xx ISA.

The W65C265SXB is based around the W65C265S which is a feature rich 8/16–bit microcomputer based on the W65C816 microprocessor.

The first thing I did after unboxing my board was to plug in a USB cable into the J5 connector then into my MacBook Pro. Next, I downloaded the Python Terminal interface created by WDC. I had to make a few changes to the python script to run on my Mac since it was built to run on Windows. Finally, I ran the script and pressed the S1 reset button and …

…my board comes alive. 🙂 What you’re seeing is the initial output of the W65C265S internal Monitor ROM.

The monitor acts as a simple operating system, allowing the user to examine registers and memory, load and save programs, and debug applications in RAM.

The Monitor provides you with an interface into the mask ROM of the W65C265S. The Monitor was written in Assembly language (code listing) in the early 1990’s. As a software engineer, I find this pretty amazing that a simple operating system written in Assembly over 20 years ago can still be a valuable asset!

So my journey begins once again. I feel like it’s “back to the future” for me. It’s been 20 years since I last worked with 65xx technology. Now as I look at the W65C265SXB I wonder, can this technology still be relevant after all these years of technological advancement? I plan on finding out however, I bet I already know the answer. 😉

A Guiding “Light” to Learning Clojure

Posted on February 13, 2013February 18, 2013 by Rod

I wrote a blog post (A Guiding “Light” to Learning Clojure) for Chariot Solutions on using LightTable as a tool for learning Clojure.

Here is a repost:

I’ve recently started learning Clojure after a little encouragement from co-worker of mine. I’ve been developing in Java for a while now and spent the last 1 1/2 years with Groovy. The Groovy experience was great and the use of closures certainly “whet my appetite” for functional programming.

Ok, for me, when I learn something new I need to have tools that are not distracting so that I’m focused on the material. In this case, I wanted to take a little time to view the tools landscape for Clojure while trying not get carried away. After doing some research, I narrowed it down to a few options. First, I’m a long time Intellij IDEA user so I could just download the La Clojure plugin (I did) to get a REPL, syntax highlighting, source code navigation, etc. This is fine but it’s a bit of an overkill for just getting started with Clojure. Intellij IDEA is a great IDE however, I wanted to stay open-minded to what else is out there.

Next, I tried configuring Vim for Clojure after seeing a co-worker work on a Clojure project with Vim. The great thing about Vim is it’s lightweight editor that’s extremely fast. If you’re proficient Vim user then you get things done quickly. If you’re a basic Vim user (like me) then there’s a learning curve. Regardless, I thought I’d give it a try by downloading and configuring VimClojure. There is a way to configure Vim to dynamically work with Clojure to provide documentation lookup, REPL running in a Vim buffer, etc. You have to build a Nailgun interface by downloading a client program and so on. I eventually got a dynamic Clojure development tool in Vim but I found that I was focusing more on learning this Vim/VimClojure/Nailgun environment than on Clojure! So, I reluctantly moved on.

I thought about jumping into the deep end with Emacs, which is the choice for most Clojure developers but I’m not an Emacs user (please don’t hold it against me). I didn’t want to get involved in a big learning curve again. I was feeling a bit like, “Hi, my name is Rod and I’m a tools-aholic”…this was starting to consume a lot of my time and taking away from what I set out to do…learn Clojure.

Well the tools story continues, in November 2012 I attended Clojure-conj in Raleigh, NC. That’s where I saw Chris Granger present LightTable for the first time. I was impressed with the presentation and thought to myself that I need to take a closer look at LightTable some time (not immediately but some time). I was trying to resist the temptation and I did for a little while. Well, three months later I “fell off the wagon” and took a “drink” of LightTable and I’m glad I did. 🙂

This is not a review of LightTable nor a “HowTo”, I think of it more as getting the word out about a new and different kind of developer tool. The UI is simple with a very modern look and color scheme. My first impression was this could be a next generation Vim editor. I found myself wanting to use the tool. The intuitive UI is easy to use and it feels natural like you’re closer to the terminal.

Instarepl

What appeals to me the most happens to be one of LightTable’s guiding principles “Discover by doing”. The REPL (Read-Eval-Print-Loop) provides an interactive session to write and execute code. This isn’t something new to the “Lispers” since REPL has been around a long time. However, the REPL (Instarepl) in LightTable takes things one step further.

Here’s your typical REPL TryClojure. Simply write some Clojure code and get the result.

Here’s the same basic example in LightTable’s Instarepl.

Ok, that’s cool, you see what you type on the left, which is mirrored on the right with the result. However, it’s not much different than the Clojure REPL. But wait, it gets better.

Here’s a simple function that I pulled from Chris’ blog post. You can see that the right side of Instarepl is just showing the function as it was written. However, things change after writing code to call the function.

The right side shows the data flowing through the function. It is pretty awesome to try various inputs and watch how the values flow through the code. I’m not sure if Chris has officially coined a term for this feature but I’ve read it being referenced as “live evaluation” or “real-time evaluation and visualization”. This is what makes me want to use LightTable even if nothing else works. 🙂 I have to wonder how this type of code “visualization” impacts TDD (Test-Driven Development). It would be interesting to explore LightTable’s impact on TDD…sounds like a good blog post. 🙂

There are many more features to LightTable and I highly recommend that you watch the video on the LightTable web page and see Chris drive the IDE. The version I’m currently using is 0.2.7 and some of the features that he demonstrates in the video I wasn’t able to get working. However, there is a new 0.3.0 version coming out Feb.-Mar. timeframe and (according to Chris) this version is about “crafting an editing experience so a lot of things will be much, much better”…can’t wait, I have seen the Light!

Emerging Technologies for the Enterprise

Posted on February 12, 2013 by Rod

It’s that time of year again for the anual Emerging Technologies for the Enterprise conference in Philadelphia, PA hosted by Chariot Solutions. It’s always a great time.

Rod Biresch