Of things new, old and somewhere in between

I felt it important to post something, if just to remind myself that 6502lane is still here and only mostly dead.  The latest lack of updates can be attributed to any number of things, but here are a few thoughts, just off the top of my head.

I started this with another Apple /// user (fan? user? is there really a difference when it comes to this particular Apple?):


Yep, that’s an Apple /// podcast.  I have an unnecessarily long blog post mostly written up for that.  I think it will be up soon over at that web page.  It explains why we started it and what we hope to get out of a podcast about a very (*very*) small corner of our hobby.

And this changed:


I’ll be recording the next episode this weekend, actually.  Yep, you heard it here first, folks.  I don’t have a whole lot to say about it this very minute.  I may not have much more to offer once the mic is hot.  I know I have a few points I need to address and then maybe I’ll catch us up on the Apple II news.  Of which, there’s a lot…

I bought one of these:

BrickPi for LEGO and Raspberry Pi

Essentially, it lets you interface one of these:


with this:


I’m hoping to plug this:


into one of these:


… at the other end of the chain, the result being an Apple II that (eventually) talks to the LEGO NXT set at the other end.  Way back when, LEGO made a robotics set designed to interface directly with the Apple II.


Today, these sets are hard to find and command a premium price on the rare occasion they are offered for sale.  My little Frankenstein’s Monster project is probably as close as I’ll ever get to owning my own Technic set.  And who knows?  Maybe I’ll lug it with me to KansasFest this year and we can have some fun in the dorm hallways.

Next, a Facebook thread on the MicroSci A143 drive for the Apple /// prompted me to install a trio I acquired a while back and test them out.  According to the old articles in TauTales, ON THREE and other resources from that era, the A143s are notoriously tricky to configure properly.  I didn’t run into any of the problems noted by those authors, but that may be because the driver disk had already been configured for that set of drives, so it was mostly plug and play.

I did run into the dreaded “I/O Error” bomb when I tried to format a disk in any of the three A143s, but I think that’s probably a speed adjustment or alignment that needs to happen and not due to the vagaries of drive set up and installation.  The Apple /// was able to identify and communicate with the MicroSci’s, at any rate.  I attempted to document the process by making a video with this new thing I received for my birthday:


The Zi12 was designed by Kodak and was about to go to market when they went out of business.  When Kodak’s assets went up for auction, JK Imaging bought the unsold stock and licensed the designs and the rights to continue making them (and other cameras) using the Kodak name.  More on that here:


It’s a neat camera, earning high marks on most reviews and comparing favorably with the latest GoPro models.  I suspect that the Zi12′s uncanny resemblance to a circa-2005 BlackBerry dampens the “cool” factor that the GoPro enjoys, but it’s every bit as capable.

Anyway, my awfulness at making a video was really displayed nicely in the footage I captured.  I messed around with camera settings and watched a bunch of tutorials, but I couldn’t get anything decent, other than a new-found respect for anyone able to create watchable videos with home equipment.

And finally, my ongoing battle to learn 6502 assembly language continues unabated.  I’ve been trying to absorb the lessons of the Easy6502 guide found at: http://skilldrick.github.io/easy6502/

I really enjoy the interactive simulator and it has made a big difference in my learning process.  Of course, completely skipping the binary and hex math at the outset of the process is a big plus, as well.  For those keeping count (just me, I’m quite certain), my current obstacle is to understand how the carry flag works.  Admittedly, I am not making much headway, but hope springs eternal, and I’m not ready to give up just yet.

So that’s mostly what’s been happening.  6502Lane still has a pulse… sort of.

More on the Racal-Vadic VA3451S Auto-Dial Modem

A little searching around on the Googles turned up some information I didn’t already know about my beloved modem:

  • Racal introduced the VA3451S in 1982.  It retailed for $900.
  • The modem is based on the VA3400 protocol, which was developed by Racal and introduced in 1973, nearly ten years before the ’51S hit the market.  The protocol allowed full-duplex 1200-bps transmission over two-wire connections, a thing not previously possible.
  • Bell introduced its more-capable 212A modem three years later.  The 212A is incompatible with VA3400.  Fortunately, Bill Blue and Mark Robbins thought to include multiple protocols when they developed AE Pro.
  • Wang sold a re-branded version of this modem creatively called the WA3451S for its line of workstations and terminals.

And this, I was able to pull from the musty cobwebbed corners of my brain: the init string is S0=0 E1Q0V1X4&K3.  I know this because I had to key it in every time I loaded up AE Pro to wake the modem up.  Eventually, I discovered AE Pro’s awesome macro language and I never had to type it again, but not before it was scored into the gray fleshy folds of my brain matter.

Also, there’s a manual specific to the 3451S out there somewhere (that I never got to see since ours was a second-hand modem, inherited from my father’s place of work).  The manual goes into much greater depth on my specific model.   I’d love access to a PDF copy, if anyone can point me in the right direction.  Apparently, it’s part of a TOSEC collection, but I can’t locate it.

This old modem

As I was rooting through the storage unit the other day, in search of something entirely unrelated to anything Apple II’ish, I stumbled across my very first modem.  I thought I’d disposed of this thing years ago and was happy to learn I was mistaken.  I was almost as happy to learn that I’d had the sense to make sure I packed the massive power brick along with the rest of it. I despise proprietary power connectors for this very reason.  I don’t blame developers for rolling their own but I’m terrible at keeping track of them, especially as the years begin to roll by.  The worst offenders are the companies who don’t bother to mark the brick with information about what it’s intended to couple to.  But that’s another rant…

My father originally brought this home from work when the company he worked for, NCR, bought his engineering department a handful of Apple ///’s so they could put in extra hours at home on the weekend.  My dad and a few other key personnel each got one and every Friday night, he would pack that 26 lb monster and all its accessories into the family Opal, drive it home, unpack it again and set it up in his study.  On Monday morning, back it would go.

When NCR replaced their ///’s with shiny new IBM PCs, he got to keep the modem and it integrated nicely into the family II Plus (and later, IIe).

To get back on topic, I plugged it into my IIe to see if it still worked.  Spoiler alert: it did not, so I decided to take it apart for a little quick & dirty troubleshooting.  Here are some photos and notes I took.

(Click on the thumbnails for full-size images.)


2012-07-14 10.38.32

The Racal-Vadic Auto-Dial VA3451 300 bps modem.  This little baby and me, plus my hacked up copy of ASCII Express Pro, made one lean, mean BBS-in’ machine.  The manual states that this model could also do 1200 bps out of the box, but I specifically remember that it would only do 300 for the first few years we had it.  It wasn’t until I bought a PROM upgrade that the blazing speed of 1200 characters per second was unlocked.


2012-07-14 10.39.26

Self-test instructions are clearly delineated on the bottom of the modem.  Note the lack of screws holding the unit together.


2012-07-14 10.39.58

Back of the modem, showing the switches, phone and power cables and the 25-pin serial connection.


2012-07-14 10.41.49

With the cover off, we can see that the modem is a two-board device with lots of chips.

(More after the jump.)

Continue reading

A look at an early Apple IIe

(Warning: I’ll be discussing topics that may seem extremely obscure and pointless to the casual visitor.  If you’re don’t find interesting the minor nuances in Apple II design, manufacturing and engineering over the years, this will likely be terrifically boring.)

A while back, I came into possession of an early Apple IIe and I thought it might be fun to post about it here.

This is Apple IIe serial number A2S2-01601.  The motherboard is a Rev. A, date-coded “8233″, in hand-written ink, which would put it mid-August 1982, several months before the IIe was announced in December of that year. Here’s a look at some of the chips and their date codes.

(click the ‘i’ for image captions and information)

Notes: The date code on the PCB, 8233, is the 33rd week of 1982, which (if we assume the week starts on a Sunday) puts the date of “manufacture” (probably when the board was assembled, rather than when the PCB was etched) between August 16 and 22.  Steve Jobs was 27 years old; Woz had just turned 32.

Older Apple IIs don’t necessarily match up with older power supplies, by serial number.  There doesn’t seem to be any rhyme or reason to how Apple decided which power supply went into which machine.

The “newest” chip in this Apple IIe is the MMU, with a date code of 8244, made eleven weeks after the rest of the PCB was assembled. I’m not sure if this means this batch of machines was assembled and then put on a shelf until the next shipment came in from Synertek, or if this particular computer had its MMU replaced at some point.  Judging from the pins on the chip, it doesn’t appear to have been serviced.

OKI Semiconductor used a 5-digit date code on the DRAMs that I haven’t figured out yet.  I can’t find a datasheet or manual describing how they did their encoding.  I believe that either the first two numbers, “24″, indicate the week of manufacture, and the “1″ is used for the year, assuming a 1980 decade, so these were made in the 24th week of 1981; or the first digit indicates the year “1982″ and the “41″ indicates the week, which puts them as manufactured right around the same time as everything else in this IIe.  OKI had two plants, one in Taiwan and the other in Singapore.  I suspect the “52″ and “97″ trailing numbers on the DRAMs indicate factory of origin, though I might be way off here.

Here’s a look at some of the interesting and unique case features:

(click the ‘i’ for image captions and information)

Here’s a video clip of Apple II historian and hardware expert Tony Diaz comparing this computer to Apple IIe A2S2-01345 during his “Apple II Road Show” session at KansasFest 2013.  Fascinating to see how different were their fates, considering how seemingly close they were in production order.

Tomorrow, I’ll post some photos comparing this Apple to a II Plus, as well as a later model IIe.

Try and try and…

Wherein, I outline my intention to present completely biased and unfair reviews of a few books designed to teach readers how to program in 6502 machine language, and perhaps learn a thing or two along the way.

I’ve complained at length in the past (don’t go looking for the posts here – I never bothered to restore any blog entries after that extended period of downtime) about the tendency of most 6502 assembly tutorial authors to simply throw the reader face-first at the brick wall of learning binary maths, usually within the first five to ten pages.

These “introductions” usually kick off with dire warnings in bold font of failure, destruction, and the promise of the fiery overturning of buses full of nuns and kittens, if the lessons are skipped without fully understanding them.  Following these proclamations of imminent doom, the reader is presented a paragraph or two of brief explanation and a couple of exercises one can use to show off their new-found prowess to friends.

But what if you didn’t understand something?  What if the answers you come up with to the exercises don’t match what’s in the book?  You could try to read the lesson again, but without a corrective guide, you’re probably going to end up at the same conclusions.

You could plunge ahead, but… Well, you *do* remember those warnings, don’t you?

And so over the years, I’ve accumulated a pile of books, all of which have fifteen to twenty pages of well-worn material, and are retail-shelf new that point.  As I look through them again, one thing is clear above all else: the information is presented in a nearly-identical and uniform manner: learn this binary math stuff before you proceed.  There’s a reason for this, and it’s a simple one: it works.  Or it works well enough to get budding assembly language programmers on their way to greater coding fame.  Countless Apple II programmers have followed these well-trodden paths before me and have emerged at the other end, wiser, smarter and with optimized code flowing forth from them like a river.

The inevitable conclusion is the problem must be with me.  This is a challenge I’ve been unable to overcome.  I haven’t been able to make the connection between the lesson and the problems.  The data seems to make perfect sense as I read through it, but my answers to the exercises are invariably wrong and I can’t tell you how I got there, or where the error was made.  Whether it’s that I’m not processing the lessons logically, or that this is a thing I’m simply not smart enough to learn, one of the flyrods is going out of skew on the treadle between the page and how my brain processes what I’m seeing.

One solution then is to try again, this time taking care to analyze the lessons and try to divine how I absorb what I think is being taught, and see if a single point of failure emerges.

These are the books I’ve got on my shelf and I’ll be trying each one, documenting as I go.  And who knows?  Maybe I’ll get lucky and it will just click on one day like a light-switch…  Nah, nothing is ever that easy.

  • Apple Machine Language for Beginners, Mansfield
  • Assembly Lines: The Book, Wagner
  • Programming the 6502, Zacks
  • Apple Machine Language, Inman & Inman
  • How to Program the Apple II Using 6502 Assembly Language, Hyde
  • 6502 Assembly Language Programming, Fernandez, Tabler & Ashley
  • The Visible Computer: 6502

And a few other online resources and guides, such as Nick Morgan’s Easy6502 guide. I’m going to have a go at Wagner’s book tonight, since someone recommended it in the comments of the my previous post about this topic.  I expect I’ll have more to say tomorrow.