From 6502 assembly language to Blackberry java programming

You know you are a true geek (and a nostalgic one at that!) when you still have your copy of 6502 Assembly Language Programming by Lance A. Leventhal (published 1979). I do not program nearly as much as I did in the past, but one of our company’s projects had a tight deadline, so I took on some small Java forms programming for the Blackberry. The thread management and resource management constraints are concurrently similar and different that my initial forays into programming.

(BTW, I’m sure it says something about me that I also have:

  • The 8086 Primer
  • Assembly Language Programming for the IBM 360/370
  • Various PDP-11 programming manuals
  • and other packrat nostalgia

…my wife would say that it means I do not know when to throw anything away).

Assembly language programming was all about managing constrained resources. Memory in the form of registers was pitifully small by today’s standards, and the concept of storing data for later usage (called persistence in blackberry parlance) was a dance of pushing and popping registers. The 6502 had, for example, an Accumulator, a Status (P) register, two index registers (X and Y), a stack pointer (for pushing and popping bytes off of the stack and a program counter. All of these where 8 bits long, except for the program counter, which was a whopping 16 bits long. That’s right kids, in the old days we actually did twiddle bits. The 8086 (circa 1980) brought in 16 bit registers, and more of them, and longer addressable memory areas.

Programming these early computers was always easier if you understood the underlying computer architecture, even down to the electrical “gates” that were performing the instructions (AND, OR, XOR, etc.) because that was the majority of the manipulations that one did to the registers.

Over the years, progress has removed the programming further and further away from the underlying architecture. Second, third and fourth generation programming languages are more layers of abstraction away from the concepts of memory, process and storage management, the building blocks of the computer itself.

Which is why programming the Blackberry is kind of a flashback.

While I am still learning about RIM/Blackberry programming (all comments and corrections welcomed), it is certainly a memory, storage and thread constrained programming model. While the programming environment is java, to store data you must persist it and follow certain rules that are in place because memory (which = storage on a BB) is such a precious resource. If you do not persist the data, obviously is goes away when the program is terminated. While not called “popping the stack”, retrieving what you stored in persistent storage is similar. And you want to keep as few threads as possible running on the Blackberry so thread (“process”) management is key.

Interestingly, all this in a java programming model…which I have little experience with, but I’ve got great help (thanks, Christopher). It has a modern development environment, so at least I don’t have to write code in a text editor….ah, the good old days!

For some great Blackberry and mobile computing articles, click on my friend C. Enrique Ortiz’ mobility blog from my bloglist!

You may also like...

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: