A Weblog


Emacs Blogging for Fun and Profit

Thursday, July 12 2018 at 6:30 AM PDT

You may notice something quite different about this blog if you've been here before. The look and feel is different, yes, but it's more than just skin deep.

For the last nine years, I've kept my blog in WordPress, a very capable blogging platform. But, starting today, I've switched my entire website to a technology from the 1970s: Emacs, the venerable text editor.

Am I crazy? No, I just think it suits my workflow better.


Emulating The AT&T 3B2 Computer

Tuesday, May 22 2018 at 2:59 PM PDT

On November 29, 2014, I posted the following message to the Classic Computer Mailing List.

Folks,

For some reason I got it in my head that writing an AT&T 3B2
emulator might be a good idea. That idea has pretty much
been derailed by lack of documentation.

I have been unable to find any detailed technical description
of any 3B2 systems. Visual inspection of a 3B2 300 main board
reveals the following major components:

  - WE32100 CPU
  - WE32101 MMU
  - 4 x D2764A EPROM
  - TMS2797NL floppy disk controller
  - PD7261A hard disk controller
  - SCN2681A dual UART
  - AM9517A Multimode DMA Controller

How these are addressed is anybody's guess.

To even dream of doing an emulator, I at least need to know
the system memory map -- what physical addresses these devices
map to. Without that it's pretty pointless to get started.

If anyone has access to this kind of information, please drop
me a line. Otherwise, I'll just put this one on the far-back
burner!

-Seth

When I sent that message, I had no idea that it would lead to almost four years of effort, and perhaps if I had known I would have given up. But thankfully I didn't, and today I'm happy to say that the effort was, at long last, successful. The 3B2/400 emulator works well enough that I have released it to the world and rolled it back into the parent SIMH source tree.

Because this project required so much reverse engineering, and because documentation about the 3B2 is still so scarce and hard to come by, I wanted to take the time to document how the emulator came about.


MMU Caching Finally Explained

Friday, March 24 2017 at 6:19 PM PDT

I had an absolute breakthrough tonight regarding how the WE32101 MMU handles caching. In fact, when I implemented the change, my simulator went from having 108 page miss errors during kernel boot, to 3. The cache is getting hit on almost every virtual address translation, and because of what I learned, the code is more efficient, too.

The key to all this was finally looking up 2-way set associative caching (see here, here, and here), which the WE32101 manual identifies as the caching strategy on the chip. Once I read about it, I was enlightened.


3B2 System Timers and SIMH

Friday, March 24 2017 at 8:26 AM PDT

I think I made a grievous error when I originally laid out how the 3B2 system timers would work in SIMH, and last night I started down the path of correcting that.

The 3B2/400 has multiple sources of clocks and interrupts: There's a programmable interval timer with three outputs being driven at 100KHz, a timer on the UART that runs at 235KHz, and a Time-of-Day clock. They're all driven at different speeds, and they're all important to system functionality.

SIMH offers a timing service that allows the developer to tie any of these clocks to the real wall clock. This is essential for time-of-day clocks or anything else that wants to keep track of time. I used this functionality to drive the UART and programmable interval timers at their correct clock speeds.

But that's completely wrong. Of course this is obvious in retrospect, but it seemed like a good idea at the time. The problem is that the main CPU clock is free to run as fast as it can the SIMH host. On some hosts it will run very fast, on some hosts it will run quite a bit slower. You can't possibly know how fast the simulated CPU is stepping.

When your timers are tied to the wall clock but your CPU is running as fast as it can, there are going to be all kinds of horrible timing issues. I had lots of unpredictable and non-reproducible behavior.

Last night, I undid all of that. The timers are now counting down in CPU machine cycles. I used the simple power of arithmetic to figure out how many CPU machine cycles each step of each timer would take, and just did that instead.

Now, it seems like everything is a lot more stable, and much less unpredictable.


Simulating the Disk Controller

Thursday, March 23 2017 at 7:48 AM PDT

I spent last night probing my 3B2/310's hard disk controller with a logic analyzer so I can see exactly how it behaves, both with and without a hard disk attached to the system. It proved to be very tricky to get the logic analyzer probes attached because the motherboard is so incredibly dense. In fact, I couldn't get a probe attached to the chip select line no matter how hard I tried. There just wasn't any room to fit a probe between the chip and a nearby resistor array, so I resorted to using a little piece of wire to just touch against the pin. I could have used three hands for that operation.


It's Hard Disk Time

Wednesday, March 22 2017 at 8:34 AM PDT

My next mini-project in the 3B2/400 simulator will be emulating the hard disk. The 3B2/400 used a NEC ?PD7261A hard disk controller (PDF datasheet here), which has proved to be harder to emulate correctly than I would have liked.

So far, my hard disk controller emulation has been limited to the most minimal functionality needed to get the emulator to pass self-checks at all. Other than that, it's just a skeleton. But I believe that it's actually hanging up the floppy boot process now when UNIX tries to discover what hard drives are attached, so it's time to get serious and fix it.

My progress isn't good. I am following the datasheet to the letter, trying to give the correct status bits at the correct time, but the 3B2 just gets confused. It never even tries to read data off the drive, it just gives up trying to read status bits. So, clearly I'm doing something wrong, but I don't know what it is.

Tonight I will strap a logic analyzer to the PD7261a in my real 3B2 and see exactly what it's doing. I'll report on my findings when I have them.


The Equipped Device Table Question is Answered

Tuesday, March 21 2017 at 7:59 PM PDT

And just like that, it's solved. I figured out the mystery of the Equipped Device Table.

The answer was in some obscure piece of System V Release 3 source code. The 3B2 system board has a 16-bit register called the Control and Status Register (CSR). In the CSR is a bit called named TIMEO that I never figured out.

It turns out that I just wasn't reading the disassembled ROM code closely enough. The exception handler checks this status bit whenever it catches a processor exception while filling the EDT. If the bit is set, it skips the device.

So what is TIMEO? It's the System Bus Timeout flag, according to the SVR3 source code.

The correct behavior, then, if nothing is listening at an I/O card's address is to set an External Memory Exception, plus set this bit in the CSR. Once I implemented that in my simulator, the EDT started working exactly the same as it does on my real 3B2/310. Success!


The Mystery of the Equipped Device Table

Tuesday, March 21 2017 at 8:18 AM PDT

EDIT: I have made a followup post detailing the answer to this mystery!

There is yet one more puzzling aspect of the 3B2 that I do not yet understand, and that is the equipped device table, or EDT. I've documented the nitty-gritty details on my main 3B2 reverse-engineering page, so I won't bore you with the details. But here's the short version.


A Last Word on MMU Caching

Monday, March 20 2017 at 10:37 AM PDT

Over the weekend I conducted several experiments with caching using my 3B2 simulator. I learned a few critical bits of information. For background, see this post and this post.

The first and most important thing I learned is that indexing cache entries only by their tags does not work. There are collisions galore, and no way to recover from them. However, if I index SD cache entries by the full SSL, and PD cache entries by the full SSL+PSL, everything seems to work perfectly. This leaves several big questions unanswered, but they are probably unanswerable. After all, I have no way of looking inside the MMU to see how it actually indexes entries in its cache, I can only go on published information and make educated guesses.

Second, I learned that implementing MMU caching is required for the 3B2 simulator to work correctly. Until this weekend, I had not implemented any caching in the simulated MMU because I assumed that caching was only used for performance reasons and could be skipped. But this is not true. In fact, UNIX SVR3 changes page descriptors in memory without flushing the cache and relies on the MMU to use the old values until it requests a flush. Not having implemented caching was a source of several serious bugs in the simulator.

Third, I learned that the "Cacheable" bit in segment descriptors is inverted. When it's a 1, caching is disabled. When it's a 0, caching is enabled.

The 3B2/400 simulator now makes it all the way through booting the SVR3 kernel and starting /etc/init. There are some other bugs preventing init from spawning new processes, but I hope to have these ironed out soon.


MMU Caching Redux

Sunday, March 19 2017 at 8:41 AM PDT

I had a Eureka! moment last night about MMU caching, but it all came tumbling down this morning.

My realization was that the Segment Descriptors are 8 bytes long, and that Page Descriptors are 4 bytes long. So, if we assume that the virtual address encodes the addresses of the SDs and PDs on word-aligned boundaries (and SDs and PDs are indeed word-aligned in memory), then you don't need the bottom three bits for SD addresses, nor do you need the bottom two bits for PD addresses. Voila!

But this morning, I remembered two very important facts:

  • The SSL field in the virtual address is an index into the table of SDs, not an address offset.
  • Likewise, the PSL field is an index into the table of PDs, not an address offset.

MMU Caching for Fun and Profit

Saturday, March 18 2017 at 6:37 PM PDT

I'm in the middle of a very long, very drawn out project to try to emulate the AT&T 3B2/400 computer. I should probably have been sharing my progress more frequently than I have been, but it has for the most part been a painful and solitary endeavor.

Today, though, there is something in particular that is bothering me greatly, and I must yell into the void to get this frustration off my chest. And that is, how in the hell does the MMU cache work?

So first, a little background.


An Ode to the Cruxen

Sunday, December 18 2016 at 1:51 PM PST

This is the story of a short time, a quarter century ago, when a little cluster of computers at Cornell University played a very important part in in my life and in the lives of my friends.

It was the fall of 1992, and the Internet was growing up. It would still be another year or two before it became a household name, so for the time being it was our little playground, our special place that you couldn't get to unless you were at a big research company or a reasonably well endowed University. I lived at Mary Donlon Hall, one of two dorm buildings that had recently been wired with Ethernet and therefore offered its residents a mainline into the addictive world of the Internet.


Fiber Optic Bliss

Tuesday, August 4 2015 at 1:34 PM PDT

IMG_2183.jpg

It's been a long time since I wrote about my tragic tale of Internet woe I owe you all an update, and I'm very happy to say that at long last, we have broadband. It's kind of a long story.


The WATs of JavaScript

Monday, June 29 2015 at 2:28 PM PDT

At CodeMash 2012, Gary Bernhardt gave a now infamous lightning talk that has become known simply as The WAT Talk, in which he presents several of the more surprising behaviors of Ruby and JavaScript. I've passed the video around quite a few times, and I've pointed out some other JavaScript behaviors that seem pretty outlandish at first sight. But I'm feeling a little guilty about poking fun at JavaScript, so I wanted to dive further into these WATs and talk about why they happen.

I'm not here to defend JavaScript — it doesn't need my defense. It's not a perfect language, and it's not my favorite language, but it is the single most popular language on the web right now, and because more and more people are using it for the first time, I think it's worth the effort to go over some of these unexpected behaviors to help newcomers avoid common pitfalls.

But first, the WATs.

The WATs

> [] == []
false
> [] == ![]
true
> [] + []
''
> [] - []
0
> [ null, undefined, [] ] == ',,'
true
> [] + {}
'[object Object]'
> {} + []
0
> Math.min() < Math.max()
false
> 10.8 / 100
0.10800000000000001

WAT?!


Do You Want To Build an FPGA? Part Two

Sunday, April 5 2015 at 3:33 PM PDT

In my last post, I showed you how to download Altera's Quartus II software and get a new, empty project started for the BeMicro CV platform.

This time, we'll learn how to build a Verilog module and compile it.


Rural Cable Expectations

Saturday, March 28 2015 at 1:05 PM PDT

My story kind of hit social media hard this week. To say it caught me off guard is an understatement. I never in a million years expected the response to be so big. I'm just some guy, I don't particularly enjoy all the attention suddenly paid to my problem. But, that said, I'm grateful for all the support and tips I've received, and I'm investigating all connectivity options.

One of the frequent criticisms I've seen goes something like this: /“Well, you moved to a rural area, what did you expect? Even though Comcast said it was serviced, you share some of the blame for even expecting cable out there. You should have known better!”/

Well, I disagree pretty strongly with this criticism. Let me tell you why.


Do You Want To Build an FPGA? Part One

Sunday, March 15 2015 at 4:37 PM PDT

My internet fiasco aside, I think it's time I start getting back into some technical matters here on the blog. So welcome to the first in a series of posts about FPGA development!

Introduction

If, like me, you've always wanted to try your hand at programming an FPGA, there's no time like the present. FPGA kits that are accessible to hobbyists have become affordable and plentiful! One of the most affordable is the BeMicro product line from Arrow and Altera, with kits starting at $30 and going all the way up to $149.

I recently bought the BeMicro CV package to play around with. The BeMicro CV is a nifty little $50 FPGA development board with an Altera Cyclone V FPGA, 128MB of on-board SDRAM, and 2MB of Flash memory. It's also got a two push-buttons, three DIP-switches, and a MicroSD card slot available for your projects to use. I think it's an ideal platform to get your feet wet in the world of FPGA development. But after you get your BeMicro CV out of the box, what do you do with it to get started?


It's Comcastic, or: I Accidentally Bought a House Without Cable

Sunday, February 22 2015 at 2:30 PM PST

UPDATE 1: See the FAQ At The Bottom of This Post

UPDATE 2: Be sure to read my follow-up post. Spoiler Alert: It has a happy ending!

This is a very long post, but it needs to be long to properly document all the trouble we've gone through with Comcast. In short: We moved into our new home in January after verifying that Comcast was available. They said no problem, and we ordered their service. After moving in, and only after a month of confusion and miscommunication, we discovered the truth: There's no Comcast service on our street.

Introduction

Late last year we bought a house in Kitsap County, Washington — the first house I've ever owned, actually. I work remotely full time as a software developer, so my core concern was having good, solid, fast broadband available. In Kitsap County, that's pretty much limited to Comcast, so finding a place with Comcast already installed was number one on our priority list.

We found just such a place. It met all of our criteria, and more. It had a lovely secluded view of trees, a nice kitchen, and a great home office with a separate entrance. After we called (twice!) to verify that Comcast was available, we made an offer.


The 1993 Social Network

Monday, October 13 2014 at 10:42 AM PDT

I was a freshman at Cornell University in Fall of 1992 when I logged into my first UNIX system.

I’d heard of UNIX before, of course—it was a popular subject in trade magazines of the period, and if you tinkered with computers you’d probably have heard of it—but I’d never actually used it. So one day I marched over to the campus IT department to register for a UNIX account. It took some wrangling, but very shortly I was drinking from the UNIX firehose.


Retrochallenge: The Final Entry

Wednesday, July 30 2014 at 8:18 PM PDT

Well. Here it is, the final entry for my Summer Retrochallenge project. I wanted to do more, but as so often happens, real life intervened and I didn't have nearly as much time to work on it as I'd wanted. C'est la vie!

But I'm still proud of what I accomplished. I have a working ROM monitor, and I'm happy to report that as a final hurrah, I got it fully integrated with Lee Davison's Enhanced 6502 BASIC.


State of the Retrochallenge

Friday, July 25 2014 at 6:52 PM PDT

As I write this, it's early on the evening of July 25th, and I'm staring next Thursday's deadline in the face. I haven't been able to work on my Retrochallenge entry for over a week, and it's in poor shape.

But am I going to give up? No way. I'm going to go down fighting.

My over-enthusiastic early plans called for me to finish up my 6502 ROM monitor so early that I'd have time to work on cleaning and sorting my RL02 packs. That, needless to say, is not going to happen. Instead, I'm going to concentrate on polishing up and documenting my monitor this weekend. Whatever I have ready to go next week will just have to be good enough. It won't be as fully-featured as I originally wanted, but at least it's something, and at least it works.

I have to pick my remaining features pretty carefully now. I want to enhance the Deposit and Examine commands to add syntax that will allow auto-incrementing the address, and then work on tying my monitor into EhBASIC, so I can run it on my home-brew 6502 after Retrochallenge is over.

It's a race to the finish, now. Expect an update from me on Sunday or Monday. Until then, I'm face down in the code!


Parsing and Tokenizing

Thursday, July 10 2014 at 1:29 PM PDT

I'm fairly happy with my parsing and tokenizing code now. I wanted to give a little breakdown of how it works.

The over-all goal here is to take a command from the user in the form:

C NNNN [(NN)NN [NN NN NN NN NN ... NN]]

where C is a command such as "E" for Examine, "D" for Deposit, etc., and store it in memory, tokenized and converted from ASCII to binary.

I wanted to give the user flexibility. For example, numbers do not need to be zero-padded on entry. You should be able to type E 1F and have the monitor know you mean E 001F, or D 2FF 1A and know that you mean D 02FF 1A.

I wanted whitespace between tokens to be ignored. Typing "E 1FF" should be the same as typing "E    1FF "

And finally, I wanted to support multiple forms of commands with the same tokenizing code. The Examine command can take either one or two 16-bit addresses as arguments—for example, E 100 1FF should dump all memory contents from 0100 to 01FF. But the Deposit command takes one 16-bit address and between one and sixteen 8-bit values, for example D 1234 1A 2B 3C to deposit three bytes starting at address 1234.


Examining Memory

Sunday, July 6 2014 at 9:53 PM PDT

[Today is kind of a big update, and not all the source code will be presented in-line here in the blog post. As always, you can look at the current source Here at GitHub.]

Good news, everyone! After quite a lot of hacking, I can examine memory with my monitor. It's a very primitive feature, right now: I can only examine one byte at a time, so I can't dump memory regions yet. But hey, it's a good start. Let's dive into the code.


Getting Input

Friday, July 4 2014 at 2:26 PM PDT

I'm moving kind of fast here because I really want to get to the meaty parts of the code, but I want to cover how I'm getting input from the console into the system. As you might expect, it's all about reading from the ACIA instead of writing to it.


Our First Macro

Friday, July 4 2014 at 1:23 PM PDT

Last night I got string output working. But what if I want to make string output generic? I want to write a STOUT (STring OUT) subroutine that can take the address of any null-terminated string and print it to the console, but there's a problem: The 6502 is an 8-bit machine, so passing a 16-bit address as an argument takes some wrangling.


Talking to the World

Thursday, July 3 2014 at 5:20 PM PDT

Now that I have a skeleton 6502 assembly project set up and building, it's time to get going and writing some real code for the ROM monitor. But wait, there's just one more thing I need to get set up, and that's an emulator so I can test code easily. Without an emulator, I'd have to flash a new ROM image to an EPROM and put it into a real 6502 computer every time I wanted to run it, and debugging would be very, very hard. Luckily for me, I wrote a 6502 emulator called Symon a couple of years ago! You can download it from GitHub if you want to follow along.


Baby Steps

Tuesday, July 1 2014 at 6:48 PM PDT

Before we get our ROM monitor off the ground, we'll need to sort out a few things first. The most important decision will be what assembler to use. I've decided to go with the CC65 tool chain, because I'm already familiar with it and I don't have a lot of time to come up to speed with a new assembler. Now, a word of caution: CC65 is no longer being developed, so its fate is uncertain. There are other assemblers out there, and if I were doing this outside of Retrochallenge and had more time, I would probably look into them. Chief among these seem to be Ophis, a 6502 cross assembler written in Python, and XA, a venerable cross assembler with a long history.


Getting Started

Monday, June 30 2014 at 11:27 PM PDT

Here it is, Retrochallenge Summer 2014. It's time to get started. It's time to write a ROM monitor.

But just what is a ROM monitor? In simple terms, it's a program that gives the user direct control over the lowest level of a computer. Typical monitors will, at the very least, allow a user to read and write memory contents directly using a very simple command-line interface. Now, when I say "very simple", I mean primitive. ROM monitors usually don't have such luxuries as user help or warnings or anything of the sort. No. They allow you to shoot yourself squarely in the foot, using whatever gauge you happen to have on hand.


Retrochallenge 2014

Friday, June 13 2014 at 3:53 PM PDT

Well here we are again. It's June of 2014, and I have to come up with a Retrochallenge entry.

Last year I decided to tackle an original hardware design and convert a VT100 keyboard to USB. It was a lot of fun, and a lot harder than I thought it would be. This year, I just haven't been able to come up with a cohesive and innovative idea for something to do, so instead, I'm going to do two smaller projects.


ASR-33 Teletype

Thursday, October 10 2013 at 12:38 AM PDT

Things have been quiet around here recently. What have I been working on?

This guy!

asr33-1024x768.jpg

It's a Model 33 ASR Teletype, better known as just an ASR-33. This is the "Before" picture. With the help of some amazing Teletype experts on the GreenKeys mailing list, I've been cleaning it, oiling it, and replacing broken parts.

I'll have more to post in a few days.


No love on the TV front

Saturday, August 17 2013 at 7:23 PM PDT

I had hoped that adding Composite Video to my little black and white Panasonic television would be a piece of cake, and in fact it looked like it would be a piece of cake. But it is not. It is not a piece of cake. It is not a piece of any kind of pastry.


Composite Video

Monday, August 12 2013 at 2:28 PM PDT

Sweet, I just found this YouTube video about adding composite input to a television. It looks much simpler than I anticipated.

I also just got the schematics for my set, so I'm in business.


Adventures in NTSC

Saturday, August 10 2013 at 4:28 PM PDT

While I was in Seattle last weekend I popped into a few thrift shops looking for vintage electronics goodies to pull apart. I found this little 5" television from 1984, for a whopping $2.50:

tr5110t-1024x765.jpg

I know it looks like it's color, but it's actually black and white–I connected a Commodore 64 through a horribly kludged together RF demodulator just to test it out, since we don't have analog television broadcasting any more.

What I'd like to do first is open it up and add a composite video input, so maybe I can drive it with a Raspberry Pi or something. It has no video input other than antenna right now. I've never really hacked video equipment before, so it'll be fun new territory for me. Don Lancaster's classic book "TV Typewriter Cookbook" (PDF, 13.5MB) has a treasure trove of information about how to interface with an analog television, so it's going to be my bible for TV experiments.

I do need to get my hands on a service manual for the TV. I found a place that sells them online (for $17, almost 7 times what I paid for the TV itself!), so maybe I'll just have to do that.


Retrochallenge 2013 Wrap-up

Monday, July 29 2013 at 10:58 PM PDT

It's done. I'm happy with it. I managed to squeeze a few final features into the firmware, including persistent storage of the Keyclick / Bell config. I learned a lot, and best of all, I had a lot of fun doing it.

I'm already wondering what my next project should be. Something slightly less useless, maybe, but where's the fun in that?!


Out of the Breadboard

Friday, July 19 2013 at 11:01 PM PDT

I have learned an incredibly valuable lesson, and that lesson is: I do not like soldering prototypes on perfboard. I was at it for about eight hours spread out over the last few days, and in perhaps the fifth hour I paused to reflect on how much time I was putting into cutting, stripping, routing, soldering, and checking connections. I thought about how, these days, it only costs $75 to get a batch of 4 or 5 PCBs made and shipped to your door, with just a week of lead time or less. And finally, I concluded that doing perfboard prototypes is for the birds. Next time, I'm just going to get PCBs made at a board house. Eight hours of my time is worth more than $75.

This time, I powered through my prototype anyway. It's not the prettiest thing in the world, but it works! This is the first (and will be the last) time that I've tried using copper tape as ground and power bus. I'm not convinced the benefits outweigh the complications.

I might get a batch of PCBs made for fun, anyway, but if I do I'm going to shrink the design and use a bare ATmega32U4 instead of a Teensy.


Success II: Now Even More Successier

Tuesday, July 16 2013 at 3:48 PM PDT

When we last spoke, I used the term "Success!" to describe what was going on. That was only partly true. I was not referring to completing the project, but rather to the success of getting raw key scan addresses out of the keyboard. It is a very long way between raw key scan addresses and a usable keyboard. So perhaps I should have titled that post "I can actually write some keyboard firmware now!" Yesterday between obligations I powered through writing rather a lot of firmware, and today I am happy to report that I actually have a better success than the last success. Even more successier than I expected in so short a time!


Success!

Friday, July 12 2013 at 10:13 PM PDT

At last, I'm getting valid keyboard input.

What was wrong? It's so embarrassing. I had a 21.5K 1% resistor out of place. It was supposed to be part of a voltage divider on one of the input pins of the LM311 comparator. Instead, it was just hanging out doing nothing. So, why was I getting ANY input at all? I'm sure that if I dug in I could analyze the circuit and figure out exactly why it was almost-but-not-quite-working without that resistor, but frankly I'm just glad to have sorted it out! I'll leave it as an exercise to the reader.

So, with that taken care of, I can get back to writing the firmware. Again, DEC actually has a pretty good explanation of how their firmware works, so I'm going to try to get mine to behave similarly.


So Close

Friday, July 12 2013 at 2:21 PM PDT

kbd_mess-1024x768.jpg

I'm frustratingly close to getting data from the keyboard, but something is clearly not right.


Talking to the Keyboard

Thursday, July 11 2013 at 1:29 AM PDT

I've reached a great milestone tonight. For the first time, I'm actually sending data to the keyboard using the real communications protocol. I wrote a very simple demo program in AVR C to show off a few LED patterns and beep the speaker a few times. Video embedded below.

Now that I know the circuit works, I'm in full AVR C programming mode. Best of all, because the clock is fully implemented in hardware, I don't have to spend all my time worrying about tight timing conditions. I'll be pushing my code on Github just as soon as I remove some of the more embarrassing comments!


Switching Speed

Tuesday, July 9 2013 at 12:49 AM PDT

Just a quick note tonight about a hack I tried that failed. But first, here's the latest revision of my schematic.

vt100_keyboard_rev_d_color_sm.png

More About Timing

Sunday, July 7 2013 at 6:38 PM PDT

I've annotated a diagram from the VT100 technical manual to explain how that clock timing circuit works. It's pretty neat!

clock_generation.png

There's a lot going on in that diagram.

The clocks corresponding to LBA3 and LBA4 are CLOCK_B and CLOCK_C in my circuit, with periods of 4.0 uS and 8.0 uS, respectively. The intermediate square waves (I, II, and III) show the logical combination of the data and the clocks. Finally, the outputs labeled OUT and OUT represent the clock output on either side of the 7416 buffer/inverter (because the 7416 is an open collector output, it's safe to pull it up to +12V, which is what the interface expects)

I'm just thankful that DEC produced such marvelous documentation. Everything is explained in such great detail. It sure saved me from having to do any actual work, that's for sure! :^)


More Hardware, Less Software

Sunday, July 7 2013 at 6:28 PM PDT

The other night I went to bed frustrated with AVR programming. I was trying to come up with some perfect scheme that would allow me to generate PWM "the right way" so I wouldn't have to bit-bang, but it was janky at best. I wanted to use interrupts to drive the keyboard decoding, but there was no guarantee they'd get serviced in time. Then I looked into whether I could somehow hijack the AVR's USART to work with an external clock and still do 16-sample encoding/decoding (you can't). It was hard, and I could sense that I was setting myself up for a terrible month of debugging impossible timing issues.

And then it hit me. What if instead of all this software, I do it the old fashioned way? What if I use hardware?


Steal From The Best

Thursday, July 4 2013 at 8:54 PM PDT

One more thought for tonight before I call it an evening. How am I going to build the interface?

Lucky for me, DEC already built the interface 36 years ago and documented it thoroughly. In fact, here it is, straight from the schematics (enhanced for readability).

vt100_keyboard_interface.png

I've highlighted the bits I'm interested in stealing with a dashed green line. This is the electrical interface I described previously, the one that compares the output clock signal and data to the input from the keyboard and converts it into a TTL-level input for the UART.

Of course, in the real VT100 the clock is generated by video refresh circuitry (LBA3 and LBA4) and wire-AND'ed together with the data to generate the PWM signal. I won't have that luxury. I'll be using a Teensy 2.0 AVR development board, and while it does have a UART, it's not exactly TR1865 compatible! So I'm going to resort to bit banging. At 16 MHz, I'm hoping I can squeeze enough out of the Teensy to handle keyboard input, keyboard status update, and USB output. If not… well, I guess I can move up to the Teensy 3.0, which is a 48 MHz ARM Cortex monster. But that seems like absurd overkill to me! Let's hope we don't have to go there.


Curiouser and curiouser

Thursday, July 4 2013 at 7:22 PM PDT

Basic Function

I've been delving more into the wire protocol the VT100 keyboard uses to talk to the terminal. As you may recall from my first post in the series, communication is bidirectional, asynchronous serial over a single wire. The protocol uses three reference voltage levels (0, 6, and 12 volts) and makes each end sample its own output to see who's talking, which is… well, it seems weird to me, but I'm sure they had a good reason. So that leaves the actual signaling. How did they send the clock and data using those levels?


It's Harder Than It Looks

Tuesday, July 2 2013 at 3:01 PM PDT

I've been delving into the internals of the VT100, and it's an impressive piece of engineering. The terminal itself is a fairly sophisticated computer in its own right, built around an Intel 8085 processor. You might expect the keyboard to be a simple ASCII affair with a 7-bit interface, which was popular at the time, but it's not. Instead, it's a serial interface, like the later PC, AT and PS/2 keyboards we're all familiar with. Unlike the AT or PS/2 keyboards, though, the VT100 keyboard is bi-directional. The terminal manages the state of the LEDs and bell on the keyboard by sending status words to it.


RetroChallenge 2013

Sunday, June 30 2013 at 5:33 PM PDT

Egads, is it really July already? It's time for Summer Retrochallenge 2013!

Actually, I've left it right up to the last minute this year. So sorry! I was this close to just giving it a pass, but then a project idea literally figuratively fell into my lap.

Long story short, a couple of weeks ago I bought a VT100 keyboard to complete a keyboard-less VT100 terminal I've been trying to get working. The keyboard just arrived at my home, but the rest of the terminal is down at my storage. I'm far too lazy to go get it, especially in this heat. Solution: a way to plug the VT100 keyboard into my Mac and use it without the terminal!

Here is my beautifully artistic sketch of the idea:

vt100_converter.jpg
Figure 8: A VT100 to USB Converter

The little box will hold a Teensy development board. The VT100 keyboard will plug into the box through a standard 1/4" TRS jack, and a USB cable will trail out the other side.

It would be nice to supply power directly from USB, but unfortunately the VT100 keyboard is a +12V device so I'll also need a +12V power brick to feed it, and some logic external to the Teensy to interface to it. But that's part of the challenge, right?

This should be fun!

An Almost Perfect Forgery

Sunday, February 17 2013 at 2:14 PM PST

When I was about 16, I fell in love with books. Oh, I don’t mean reading — I was in love with reading long before then. I mean that I fell in love with books as objects, as vessels of information with their own form and function. In college I took a course on bibliography called The History of the Book, which only served to make the love stronger. In 2002 I studied bookbinding at the North Bennet Street School in Boston. So, when the 46th Annual California International Antiquarian Book Fair came to town, of course I had to visit. While I was at the fair, I attended a talk titled “Forging Galileo” by assistant professor Nick Wilding of Georgia State University, and it kind of blew my mind.


Retrochallenge WW Wrapup Video

Thursday, January 31 2013 at 9:20 PM PST

And now, the inevitable video.


Retrochallenge WW Wrapup

Wednesday, January 30 2013 at 11:43 PM PST

Well, the project is done, I've put down my soldering iron, I've stopped writing code, and I'm in the middle of editing a demo video (to be posted later, when I'm a little less tired).

I'm mostly happy with how things turned out this time around. I was successful with my project, I've met my goal of having usable tape storage. I should probably put the word usable in quotes, though, like this: "usable". Because, to be honest, it is somewhat flakey. I have about a 70% success rate with saving programs that can be read back later. I think my main problem is just how much noise my circuit injects into the signal. I really did not use best engineering practices: I have no ground plane, my cables are unshielded, my leads are too long, I'm just begging for noise. So, really, I'd say 70% success is not so bad, all things considered.

I learned a lot, especially about how the Apple II did things. I pored through Woz's code and really tried to understand what it was doing. I enjoyed the process.


PRESS PLAY ON TAPE

Tuesday, January 29 2013 at 12:39 PM PST

Good news! I tracked down my checksum bug last night, and just in the nick of time, everything is working. I can both LOAD and SAVE from EhBASIC, and my little SBC is happy. Finally, a Retrochallenge that I've completed successfully!


Still Flogging Away

Monday, January 28 2013 at 12:46 AM PST

OK, it turns out this is harder than I expected. I'm fighting a very strange bug in my LOAD code. It's complaining of a checksum mismatch, but there doesn't actually seem to be one. And, weirder, my program loads anyway, despite the fact that the checksum failure branches away from the code that is supposed to reset the BASIC program and variable space.

In short, it's failing where it's supposed to succeed, and it's succeeding where it's supposed to fail. Wait, what?!

Whatever the bug is, I still intend to squash it before the Retrochallenge deadline on Thursday. Plenty of time! (he said, over-confidently)


Down to the Wire

Sunday, January 27 2013 at 12:50 PM PST

Golly, I do like waiting until the last minute, don't I?

No, I haven't given up. I'm just finishing up the last few bits. I meant to get everything done yesterday, but got distracted by Real Life Matters. Oh well! But I have plenty of time today.

The very last thing I need to do is patch together my READ and WRITE routines into LOAD and SAVE BASIC commands. Since my little computer uses Enhanced 6502 BASIC, this will not be difficult. EhBASIC provides empty hooks for your own LOAD and SAVE code, so it's very easy to patch into.

By this time tomorrow, I hope to have a finished project ready to demo.


It Works!

Monday, January 21 2013 at 7:01 PM PST

Great! I can both save and load from tape now!

I'm not quite done yet. I want to add checksum code and get this integrated into Enhanced BASIC so I don't need to drop down into the monitor to save and load. Gotta make it user friendly, after all!


Getting Closer

Friday, January 18 2013 at 12:26 AM PST

Good progress tonight! I think the code to WRITE data to tape is fully complete. I'm not particularly impressed with my own 6502 assembly, but by golly it works.


Retrochallenge: The First Piece of Code

Monday, January 14 2013 at 10:29 PM PST

Alright, it's not much to look at, but it's a start.

This code generates ten seconds of 770Hz square wave, which is the tape header. It is both less compact and less elegant than the code that Woz wrote for the Apple 1 and Apple II, but for that I blame my inexperience (and the fact that Woz was a kind of 6502 savant who had no need for such niceties as assemblers). I hope that it is at least fairly easy to read and understand.

Next up is writing a sync bit, followed by shifting in data from memory and writing it to tape one bit at a time.

.alias IOA    $8001             ; 6522 ORA register
.alias DDRA   $8003             ; 6522 DDRA register

.alias TAPEST $40               ; Current tape state scratch area

.org $0300

INIT:   LDA     #$FF            ; Make all Port-A IO lines outputs
        STA     DDRA
        LDA     #$00            ; Initialize tape state scratch space
        STA     TAPEST

;
; Write 10 seconds of 770 Hz square wave to tape.
;
HEADR:  LDX     #$3C            ; 60 times thru inner loop
HEADR0: LDY     #$FF            ;   (60 * 255 = 15,300 half cycles)
HEADR1: LDA     #$7A            ; (122 * 5 uS) + overhead = 650 uS width
        JSR     DELAY
        JSR     WRTAPE
        DEY
        BNE     HEADR1          ; Inner Loop
        DEX
        BNE     HEADR0          ; Outer Loop

        ;; ----- END -------
        ;;  TODO: Write sync bit, then shift in data and write bit-by-bit.
        BRK
        ;; ----- END -------

;
; Delay for 'A' cycles ('A' * 5 clocks). Modifies the Accumulator.
;
DELAY:  SBC     #$01
        BNE     DELAY
        RTS

;
; Toggle the current tape output state. Modifies the Accumulator.
;
WRTAPE: LDA     TAPEST          ; Load current tape state
        EOR     #$01            ; Toggle it
        STA     TAPEST          ; Store back into tape state,
        STA     IOA             ;    and out to tape.
        RTS

Whither Java on the Desktop?

Saturday, January 12 2013 at 4:54 PM PST

symon_full.jpg

A little while ago I wrote the 6502 simulator pictured above, Symon, and released it as open source software. I wrote it because I was developing a small 6502 computer, and wanted a simulator that matched the hardware's memory map. I've always been interested in learning more about simulation, so it was a natural project for me to gravitate to. I've enjoyed working on it tremendously, but there is only one problem: I wrote it in Java.

Java is undergoing what seems to me to be a crisis of public opinion. The news is full of stories about another critical vulnerability, and vendors are rushing to disable Java in browsers by default. Users are being told to turn off Java wherever unless they really need it.

So why did I choose Java in the first place? For several reasons. First, I started this project a couple of years ago. When I first set out to write the emulator in 2008, Java was still owned by Sun Microsystems, still enjoyed widespread popularity, and wasn't yet considered as much of a security risk. Second, Java was a language that I knew extremely well, having worked on many Java projects in the past. I started writing Java in 1997, and it was the primary language used in my day job straight through 2007, so it was quite natural for me to fall back on it. Third, and maybe most importantly, I very much wanted Symon to be fully cross-platform. Although I use a Mac with OS X as my main system, I also have a Linux laptop and a Windows 7 PC that I spend quite a bit of time on. It was important to me that I'd be able to use Symon on all three platforms. Java gave me that feature for free.

But with the latest goings-on in the world of Java on the desktop, I have to wonder, will Java even have a viable consumer desktop runtime in the near future? Sure, it has tremendous support on mobile thanks to Android, and its position in the server market is assured after a decade and a half of Java as a web platform, but it never gained the kind of wide-spread support on the desktop that it has on the server. With more bad news coming out and more end users disabling Java how will people run Symon?

I feel like I'm left with a couple of options.

  1. Ignore the problems. Just keep updating the Java Symon code, and let things fall where they may.
  2. Give up multi-platform. Port Symon to a native OS X Cocoa version, and accept the fact that I won't be able to run the code on Windows or Linux.
  3. Find a new multi-platform runtime. But which one? Mono, an ecosystem that I know nothing about?

None of these is ideal. The easiest for me to do, of course, is the first, and this is likely what I will do for a while at least. But if my instincts are right, and Java has a very limited lifetime on the desktop, I'll have to pick one of the other two not too long from now.


How It Works

Friday, January 11 2013 at 8:46 PM PST

I've been pretty quiet over the past week. This is primarily because my day job has kept me busier than I'd like, compounded by the fact that I've come down with a cold. But I shall persevere and forge on ahead. The hardware is done, and I'm currently working on the software. But, how exactly does it work? That's what I hope to show in this post.


Comparator Success

Saturday, January 5 2013 at 12:37 AM PST

I put together the cassette input circuit tonight on a teeny-tiny little perfboard. It's not really much to look at, but happily, it works!

cassette_input-1024x768.png

Its sole purpose in life is to take the audio from a cassette and turning it into a useful digital signal. Here's a capture from my scope, showing the cassette input on the yellow trace, and the digital output on the blue trace. The input is showing 200mV per division, so it's a peak-to-peak of about 300mV. The output trace is showing 2V per division and it's peaking at about 3.9V, but that's because I forgot a pull-up resistor. I'll add that tomorrow!

ones_and_zeroes_annotated.png

I've annotated the screenshot to show how the data is encoded on the tape. This is actually from a copy of APPLE 1 INTEGER BASIC (the original, the one that Woz wrote!) that I downloaded as a digital audio file from Brutal Deluxe Software and then recorded to cassette myself. The Apple II used the same format. A “0” is encoded as one cycle of a 2 kHz signal (about 500µs wide), and a “1” is encoded as one cycle of a 1 kHz signal (about 1000µs wide). This seems like a fine format to use for my own project, so that's what I'll do.

I have a few minor tweaks to do to the hardware before I mount it into the project box next to my 6502 SBC, but I should have all the hardware done tomorrow. Then it's onto the hard part: the software.


Retrochallenge Update: Comparator vs. Zero Crossing Detector

Friday, January 4 2013 at 12:14 AM PST

I managed to get a bit of experimenting in last night, and the first thing I learned was that my decision to crib the cassette input circuitry from the Apple II was not going to work.

Here's the relevant bit of the Apple II schematics:

appleiicassette.png

This is a very simple op-amp configuration called a Zero Crossing Detector. Unfortunately, this kind of circuit relies on the op-amp having both a positive voltage and a negative voltage source (pins 7 and 4, respectively) in order for it to work. The Apple II has a -5V supply, but my 6502 SBC does not. I only have +5V available.

So, scratch that. I can't just use a zero crossing detector. But I can do something very close to that, and use an op-amp as a comparator. And it turns out there's a vintage 6502 system that did exactly that, the Synertek SYM-1. Here's how Synertek did it:

sym1cassette.png

At first glance this looks more complex than the Apple II circuit, but in reality there's not much more going on. The part before the primary decoupling capacitor (C16) is just a low-pass filter composed of R128 and C15, presumably to try to reduce tape hiss and high frequency noise from the cassette. Following that, R95 and R126 form a voltage divider that provide a reference voltage of +2.5V to the non-inverting input of the LM311 comparator, and (through R93) a +2.5V biasing for the audio input. CR28 and CR29 are just protection diodes to prevent too great a differential voltage from being applied to the LM311 inputs. When the inverting input is above 2.5V, the output of the comparator will be held low (close to ground). Conversely, when the inverting input is below 2.5V, the output of the comparator will be high (close to 5V). That's really all there is to it.

I don't happen to have an LM311 handy, but I do have a bunch of LM358s in my junk box. I did a little breadboarding tonight, and found that these should work just fine as comparators in this application. Tomorrow I'll throw a circuit together onto a little protoboard and wire it up to the 6522 on my SBC. I think that will largely take care of the hardware side of this project.


Retrochallenge Winter Warmup: Day 1

Tuesday, January 1 2013 at 9:41 PM PST

Happy New Year! It's January 1st, and that means it's the first day of the 2013 Retrochallenge Winter Warmup!

This year I'm going to be tackling a small project, something I know I can finish in a month. I want to add cassette mass storage to a 6502 Single-board computer that I built about a month ago. It's a nice little computer, but without any kind of storage system for programs it's kind of useless.

Naturally, the project will require both hardware and software. Today I've been doing research into how cassette storage worked on a few classic systems: The TRS-80 model 1, SYM-1, the AIM-65, the Apple I, and the Apple II. After briefly evaluating all of these, I think I'm going to just steal from take inspiration from the Apple II Cassette Interface. It has two big advantages: It's very well documented, and both the hardware and software are extremely simple. Of course it has some drawbacks, too. In part due to its simplicity, the Apple II Interface was finicky and required careful setting of the tape audio level on playback for everything to work right. I think I'm OK with that trade-off.

On the hardware side, the cassette interface should require very little. For I/O, I'll only need one pin on my 6522 VIA. Writing will be done directly, and reading will use an LM741 Op-Amp as a zero-crossing detector, just like the Apple II. Software will use polling and a counter to determine whether two logic level transitions are a one or a zero, just like the Apple II.

I suspect the hardest part of all of this will be getting the tape record and file format right. My goal here is NOT to be 100% Apple-II compatible, so that gives me some leeway.

Wish me luck!


Retrochallenge Step 0: Get Prepared

Saturday, December 15 2012 at 3:59 PM PST

In the spirit of fairness, I'm not going to start work on the Retrochallenge Winter Warm-Up until January 1st, but I did want to start laying the groundwork so I can hit the ground running on the first of the year. I took my first step in preparation today by buying the all-important cassette player, an old-school Panasonic RQ2102.

519AEVWPHVL-300x269.jpg

I chose the RQ2102 specifically because of its historical accuracy. Apple used to recommend this very model as the preferred cassette recorder for the Apple II — and yet, it's still made today. Remarkable!

Of course I don't strictly need a cassette recorder. Sure, I could use a PC or an iPad or something as an MP3 recorder. But honestly, where's the fun in that? So I want to use the real thing.


Retrochallenge Winter Warm-Up 2013

Friday, December 14 2012 at 3:34 PM PST

Following the rather disastrous non-completion of my PDP-11 restoration project for the Summer 2012 Retrochallenge, I have decided to bite off a much more realistic and completable project for the 2013 Retrochallenge Winter Warm-Up.


Know When To Fold Them

Sunday, September 16 2012 at 6:25 PM PDT

It's been forever since I updated here, hasn't it!

Well. This is hard for me to say, but I think it's time I officially give up on the 11/35 restoration. Wait, hear me out.

I've been poking at it over the last month or so, trying to make heads or tails out of what's going on. And, unfortunately, I can't. It has been exceedingly frustrating just trying to understand the problems with the startup status pulses, let alone repairing what looks like a completely flakey timing board, and possibly dead ROMs on the microword board.

When I received them, the board set was covered in rust and mouse piss. The IC legs (with the exception of the gold-plated ones, of course) were black, or red and spotted. I'm shocked I was even able to get the power supply back to life. So it's really no surprise that the logic repair is above my skill level. Would it even be repairable to a DEC engineer? Maybe. I don't know.

So tonight, I will regretfully put it back into the rack, clear off my workbench, and move on to some other projects. Maybe I'll come back to this some day, if I ever find a replacement set of KD11-A boards. I do know someone who has a set. But for now, it's time to move on.


New Theory

Monday, August 6 2012 at 1:09 AM PDT

I know I said I was going to take a few days off, but I couldn't help myself. I spent about two hours looking at signals on the PDP-11/35 today.


Red Herring

Saturday, August 4 2012 at 11:25 PM PDT

The 8881 was a red herring. As Ian pointed out in the comments, the output is an open collector, so it won't be high until BUS DC LO pulls it high. In fact that gate is only pulsed on power-off, not power-on. So that chip is probably just fine.

That said, I'm still completely lost. There is definitely something wrong with the power-on sequence, but I can't for the life of me figure out what it is. I'm going to step back and take a break for a few days and see if inspiration strikes me.

What I really wish I had was a known-good KD11-A to compare against, but that is very unlikely to happen, alas.


More dead chips

Friday, August 3 2012 at 11:12 PM PDT

It looks like an 8881 is bad on the STATUS module.

bad_8881-1024x450.png
Figure 15: Possibly bad 8881

Pins 5 and 6 are inputs, and pin 4 is the output of a NAND gate on the 8881. That sure looks like a bad part to me.

I've ordered a few spare Signetics N8881's off of eBay, but… I have to admit, I'm really down and disheartened about the project tonight. I didn't get more than an hour of debugging in tonight before I found this chip, and now I'll be high and dry for another week until my chips come in. And what will I find next?

I really think this might be a lost cause. I hate to think about giving up after all the time and money I've poured into this so far. There are other projects I'd like to be working on, but I've had this PDP-11/35 occupying my entire workbench for a month now and I don't feel like I've actually accomplished very much.

Well, maybe the feeling will pass. I'll give it one more go. If I continue to find as many dead parts after getting past the 8881, I'll reconsider whether it's worth it to continue.


What Makes A PDP-11/35 Tick?

Thursday, August 2 2012 at 12:09 AM PDT

This is what makes a PDP-11/35 or PDP-11/40 tick. It turns out to be 441 ICs. Impressive!


Retrochallenge Post Mortem

Wednesday, August 1 2012 at 1:24 PM PDT

Obviously, I did not finish my project in time for the conclusion of Retrochallenge. Of course I'm a little disappointed, but in retrospect there's not much that I could have done to make it come together successfully before August 1st.

A few things went wrong: I didn't get my chassis back from the powder coater until over a week into the month already, and then my power supply died just as I was getting started. But even so, given what I've discovered in the CPU so far I doubt that I would have made it by August 1st even without those problems. In fact, I predict this restoration will take several months more at least. I'm fully committed now, I'm not stopping until this thing works, even if I have to replace every single IC.

I'm counting this as a valuable learning experience, and I'll be back with some crazy new idea for the next Retrochallenge.


Output Drive

Wednesday, August 1 2012 at 10:27 AM PDT

A couple of comments here and over on the Vintage Computer Forum prompted me to pull out my copy of Don Lancaster's "TTL Cookbook" to verify my assumptions. As is so often the case, my assumptions were wrong.

The original TTL family used in the KD11-A, the venerable 7400 series, can drive a maximum load of 16mA per output, and consumes 1.6mA per input. The more modern (and cheap and easy to find) Low-Power Schottky 74LS00 parts on the other hand can drive a maximum load of only 8mA per output.

Well. Damn.

This doesn't mean I can't use 74LS00 parts as replacements, of course. But it does mean that I have to be very careful where I use them. I will have to be absolutely sure that I am driving NO MORE than 5 inputs from any output if I want to use an LS part.

The 74123 that I want to replace, for example, is safe. One of the outputs is driving three inputs, and the other output is driving only one.

The 7404 that I've already replaced, however, is no good. I will need to undo that fix immediately. One of the NOR gates is driving ten outputs! That's the maximum you can drive from TTL to TTL, and twice as many as you can drive from LS TTL to TTL.

So, more delay while I get some original TTL parts. There's a shop here in town that sells them, but I'll need to take a couple of hours off work to drive there. The things we do for our hobbies!


Serious Debugging Time

Tuesday, July 31 2012 at 1:06 AM PDT

Now that the power supply is straightened out (at last!), I've been able to start tracing logic and seeing what's up with the CPU.

First things first: It still doesn't run. Last week before the power supply died I mentioned that I thought it may have been due to low voltage. That was wishful thinking. Now that the voltage levels are good, the behavior of the CPU is roughly the same. It is time to go spelunking into the lair of the beast.

I wanted to tackle the HALT/ENABLE switch first. If the CPU is halted (switch set into the HALT position) it should be running the console loop, waiting for commands from the console switches, but I have no evidence that it is. I had already verified that the 7410's on the console were working correctly, so my investigation took me from there to the CPU itself.

Thanks to countless people around the world, a lot of DEC's documentation lives on in scanned form, including the KD11-A Maintenance Manual and Engineering Drawings. These have proven absolutely essential. It didn't take me long to trace where the HALT switch feeds into the CPU. It turns out it has several destinations: On the M7235 STATUS module it feeds into a 74H11 AND gate, and on the M7234 TIMING module it feeds into a 7474 flip-flop, a NOR on a 7402, an inverter on a 7404, and a NAND on a 7400.


On Spam

Sunday, July 29 2012 at 11:55 PM PDT

It's remarkable how much spam is directed at this little blog. In a given day, I'd say the Akismet plugin stops something like 5 to 8 spam comments from getting posted here. It's absolutely infuriating and ridiculous, especially for such a podunk little no-name blog like this. I can't imagine how many the big ones get!

On the other hand, it would be so much worse if the comments actually made it through. I should be grateful that Akismet is so good at stopping them (knock on wood).


Persistence Pays Off

Saturday, July 28 2012 at 10:03 PM PDT

Eureka!!

I replaced MPSA05 and MPSA55 transistors that I suspected of being reversed, and bingo, the power supply is working again. I'm still upset with myself that I put them in backward, but in the end no other damage was done. Thank goodness.

Now I have a good, stable 5V supply, and I've adjusted the output correctly. That means I can get back to the business of debugging the CPU and seeing why the machine won't run.


Transistors!

Friday, July 27 2012 at 10:37 PM PDT

Oh my God! I know what I did wrong with the power supply. Good heavens!

DEC used GPSA05 (NPN) and GPSA55 (PNP) transistors. I replaced two that were shorted out with MPSA05 and MPSA55's. They have completely identical specifications.

But guess what? THEY USE REVERSED PINS. Pin 1 is the emitter on the MPSA05/55's. It's the collector on the GPSA05/55's.

Lesson learned: ALWAYS CHECK THE TRANSISTOR ORIENTATION. Especially when you're 110% sure the parts are identical.

Ugh!

I will report back after I have fixed my mistake.


iCircuit

Friday, July 27 2012 at 12:56 PM PDT

Last night before bed I whipped up a circuit simulation of the 5V regulator using iCircuit running on OS X. It's a little buggy, and it's certainly no Spice, but the real-time feedback is fantastic.

iCircuit-Regulator-1024x903.png

The beauty of this is I can play with it and examine possible failure scenarios by shorting or opening various components to see what happens. I think I have a much better idea of how the regulator actually works, now, and I'm going to do a careful part-by-part check, from one end of the circuit to the other, and find out what's failed. My gut tells me I should check R50 (the potentiometer), R47, and the 2.4V reference zener. So I'm not giving up hope yet!


Continued Power Supply Problems

Thursday, July 26 2012 at 7:28 PM PDT

Things are certainly looking grim for my hopes of completing restoration before July is through. I have replaced every shorted part, and I still don't understand what's going wrong. I am letting my Retrochallenge friends down!

The problem really is that I am simply out of my league with the +5V regulator. I can fake my way through digital electronics quite well because much of it feels natural to me. And since everything I do is low frequency, I have the luxury of more or less ignoring capacitance and inductance, and I can pretend that transistors are nothing more than electrical switches. It makes life so easy.

Understanding and repairing this power supply, though, that's another matter. When it comes to analog electronics, I can understand a basic emitter-follower amplifier alright, but anything more complex than that leaves me scratching my head. Even with the circuit description in the manual (which is quite good) I don't really "get" it.

So far my understanding of the problem is that the regulator is not switching. It should be generating a sawtooth wave at high frequency, which eventually gets smoothed out to +5V by an LC network. But the switching isn't happening. I have now replaced every transistor in the circuit, and it is still not switching. I either screwed something up, or one of the other parts (possibly one of the diodes, or one of the zeners) that I THINK is good is not good. I don't want to go full-on shotgun and replace every component, that's ridiculous!

Still… I do have a backup plan up my sleeve. I located (and bought) a spare regulator board. I got a very good deal on it, only $45. I consider that a very reasonable price for my sanity. It should be here next week, and I'll keep it as a spare if I actually DO get this board working. And if I can't, at least I'll have a known good board to use in its place.

I'm a little down about it, but at least it's a learning experience.


One Step Forward, Two Steps Back

Tuesday, July 24 2012 at 5:04 PM PDT

You're probably wondering to yourself, "Self, why hasn't Twylo updated his PDP-11 repair journal lately? It's been days!"

I can sum it up with one schematic:

5v_circuit.gif
Figure 17: +5V Regulator Circuit

Intertwingly Little Lines

Wednesday, July 18 2012 at 11:44 PM PDT

enable_halt-1024x184.png

I've taken the initiative to dig into the KD11-A Maintenance Manual and the Engineering Drawings a little bit. To say I am intimidated would be a bit of an understatement. This is a very complex machine that many smart people with engineering degrees designed. I like to think that I am capable of screwing in a lightbulb without hurting myself, but I do not have an engineering degree. My electronics knowledge is 100% self-taught. So I feel, I think somewhat justifiably, like I may be a little out of my league.

On the other hand, there's a sense of freedom in not really knowing how much I don't know.


Time for the real work to begin

Tuesday, July 17 2012 at 9:13 PM PDT

Last night was the big moment. I fired up the 11/35 for the first time with the CPU installed.

I'm pleased to report that nothing popped, no fireworks went off, and no magic smoke got out.

On the other hand, it did not work correctly, either. The processor starts up, the RUN light comes on, random(-ish) data is displayed on the ADDRESS and DATA lights, and that's about all that I can make happen.

So now begins the really hard part, the logic debugging. I've started a thread over on Erik S. Klein's Vintage Computer Forum to discuss what I'm seeing, with the hopes that the very smart (much, much smarter than I) DEC fiends over there will be able to offer insight into how I should proceed with debugging.

I am armed with the KD11-A Processor Maintenance Manual, the PDP-11/40 System Engineering Drawings, an 8-channel logic analyzer, an oscilloscope, a multimeter, my brain, and the Internet. This will by no means be easy, but it will definitely be educational, and probably fun and frustrating in equal parts. Let's do this!


More Assembly

Friday, July 13 2012 at 9:47 AM PDT

Things really started to come together last night. I finished installing the cooling fans, dropped the power supply into the chassis, and connected the 9-slot backplane. No cards and no console, but I consider this my first "smoke test" of the fully assembled chassis and power subsystem. It works!

Exciting days ahead. I have to re-assemble the console, and then I'll drop in the cleaned-up CPU cards this weekend and see what happens. I'm a mite skittish about that.


Reassembly Begins

Sunday, July 8 2012 at 10:57 PM PDT

I spent this weekend getting started on the reassembly of all the little bits and pieces that I pulled out of the 11/35 while cleaning it. I'm super glad that I photographed everything and bagged and tagged all the screws and such when I pulled it apart, because it's made the process of putting it back together a lot easier than it otherwise would have been.

The last thing I did before reassembly was to head down to one of my favorite surplus shops, Excess Solutions in Milpitas, to pick up a bunch of machine screws. I dropped $20.00 and filled a bunch of bags with #4-32, #6-32, and #8-32 screws and lock washers to replace the parts that had been rusted out in the chassis (I'm not sure why, but almost all of the old lock washers were rusty, but only a few of the old screws were. I guess the old screws were zinc plated, but the lock washers weren't?)


Chassis: Before and After

Thursday, July 5 2012 at 10:59 PM PDT

I picked up the PDP-11/35 chassis parts from the powder coat shop this afternoon, and they are spectacularly well done. Total cost was $100.00, which I consider money well spent.

chassis_before_and_after-1024x425.jpg
Figure 19: Chassis: Before and After

I'm thrilled at how everything came out. There was some really deep pitting from rust, and of course some of the pitting is still there after the metal was sandblasted and powder coated, but at least now everything is protected from corrosion again. With proper care this chassis should last a very, very long time.

Now that I have everything back I will start piecing it back together. I want to get it all assembled this weekend, so I can start debugging logic by early next week.

Onward and upward!


And we're back in action!

Thursday, July 5 2012 at 10:04 AM PDT

The powder coater has my job done, so I'm heading up to South San Francisco this afternoon to pick it up. That means we're back in business, and I'll be able to start putting the 11/35 back together this evening. Woo!


BA11 Still Missing In Action

Saturday, June 30 2012 at 3:06 PM PDT

Now I'm getting worried. Retrochallenge starts tomorrow, and I still don't have my BA11-K back from powder coating. I'll have to call tomorrow and find out when the ETA is. I know the shop was really backed up, but it's been three weeks now, so I hope they'll have it done soon. Every day without it is one less day to get the 11/35 fixed up before Retrochallenge is over!


July 2012 Retrochallenge!

Tuesday, June 26 2012 at 8:37 PM PDT

Well, I'm still waiting for my powder coated parts to come back. I sure hope they get here this week, I need to get moving on this project because I've entered the July 2012 Retrochallenge!

If I have any hope of actually making the PDP-11/35 work, I'd better start getting things assembled for testing the first week of July. I don't know for sure, but I suspect I'm going to have to spend a lot of late evenings in the workshop with a logic analyzer and an oscilloscope or two. Forty-year-old TTL has a way of going bad!


Backplane pictures

Wednesday, June 20 2012 at 11:09 PM PDT

While I'm waiting (rather impatiently) for the chassis and bits to come back from powder coating so I can start assembling things, I've moved on and finished cleaning up the Unibus backplanes and front panel switches.

I thought I should preserve, for posterity, a "Before and After" shot of the Unibus slots. Nasty.

before_and_after-768x903.jpg

See? I wasn't kidding about how hard they were to clean.


PDP-11 Off At The Powder Coater

Monday, June 11 2012 at 5:06 PM PDT

Well, I dropped all the chassis bits off at the powder coater today. They'll get sandblasted and powder coated, except the front panel bezel, which is just getting sandblasted. I'll paint that white myself.

It's going to be gone for at least a couple of weeks, I think, since the shop is backed up with work. But that's fine, I'm patient.


PDP-11/35: Disgusting, Nasty, Dirty Unibus Backplanes

Sunday, June 10 2012 at 6:52 PM PDT

Tonight I moved on to a task I've been dreading: cleaning up the Unibus backplanes.

Electrically, they seem like they were probably in acceptable shape, but they are incredibly filthy. They were exposed to the elements in a shed for many years, face up and just waiting for God knows what to fall or crawl into them. The slots that did not have cards had become embedded with bits of fiberglass, dirt, spider webs, insect droppings, and probably a goodly dose of mouse piss. Some of the individual nooks and crannies (I don't know the technical term here - the individual slot openings where a single finger of one card edge connection is installed) had what I assume were insect or spider egg sacs in them, gripping the sides tightly.

All in all, I spent about an hour and a half on just one backplane, the four-slot DD11-A. My method for cleaning involved using a vacuum cleaner, a stiff-bristled brush, and a variety of toothpicks to get into the slots and worry out all the junk. Some of it was quite sticky and hard to get out. Spider and cobweb debris, I assume? It felt like it took forever, brushing, picking, vacuuming, brushing, picking, vacuuming…

When I felt like it just wasn't going to get any cleaner and all of the obvious bits and pieces had come out, I gave the whole thing a healthy dose of Deoxit contact cleaner spray, and worked a bus terminator card (dual height) gently in and out of the slots to clean the contacts. It looks pretty clean now. Maybe not "good as new", but less likely to cause a gag reflex at least.


Twinkly Lights

Saturday, June 9 2012 at 11:16 PM PDT

I started testing the LEDs on the KY11 front panel tonight. The process was simple: apply power to the panel, and ground each pin one by one.

There was only one dead LED, but several others were barely visible so I decided to replace them too. Unfortunately, the new LEDs are noticeably brighter than the old LEDs (though drawing the same current), so I ended up pulling and replacing ALL of them.

Normally I'd hate to do a wholesale replacement like that, but in this case I think it'll be worth it.


Repainting delayed a few days

Thursday, June 7 2012 at 5:46 PM PDT

I had hoped to get the BA11-B and H750 chassis in for sandblasting and repainting today, but the painter I called turned down the job. He is not used to dealing with sheet metal. I appreciate him turning it down rather than trying to do it and not doing a good job.

But that led to an interesting phone call. I called up a powder coat company located in South San Francisco and asked if they could do sheet steel. Unfortunately the owner, Warren, is out for the next few days, but the receptionist asked me for my information so he could give me a call back.

She asked what I wanted worked on. "Oh, it's an old computer chassis," I said. She asked what kind specifically, and when I said "a Digital Equipment Corporation PDP-11," she started laughing. "Oh! That's great, Warren used to work for a company that maintained and repaired those! He'll get a real kick out of this, I can't wait to tell him!"

So, I think I may have found the right guy for the job!


Where to from here?

Thursday, June 7 2012 at 12:41 AM PDT

Now that I have a working power supply, the first thing I'm going to do is put the machine back together, right?

Wrong!

I've gone the opposite route. I've taken everything even more apart than it already was. After doing my debugging, I stripped literally every part out of the H750, and removed all hardware from the BA11-B chassis. Tomorrow I'm taking everything in to get it sandblasted and repainted. I'm going to do this restoration right!

Look at all that hardware…

IMG_0148-768x574.jpg

Not pictured there are all the card rails, the fans, the power distribution cables, and all the other bits and pieces that go into the BA11-B chassis, but rest assured they are safe and sound and will be getting a thorough bath tomorrow.

I don't know how long it'll take to get everything back from the painter, but when I do I should be ready to start putting everything back together.


PDP-11/35 Power Supply Rides Again

Thursday, June 7 2012 at 12:31 AM PDT

Success! At long last I am thrilled to report that my DEC H750 power supply is fully operational. All the voltages check out, and both with and without load the waveforms show no ripple. It didn't come easily, of course, but I got really lucky and along the way I learned a lot about DEC's power supplies.

What follows is a bit long. Unless you're really interested in reading too much information about the process, please feel free to skip it and just say "Oh, that's nice, Seth got his power supply working. Jolly good!"


PDP-11/35 Restoration, Part 8

Wednesday, May 30 2012 at 7:25 PM PDT

As promised, I received my replacement H744 +5V regulator in the mail last Tuesday. I haven't tested it yet, but it looks brand new. Other than that I don't have any more progress to report on the PDP-11, but a big project at work is just winding down, and I'm taking several days off next week. That will give me some time to really start tackling the power supply. I'll post pictures and updates here as I work on it.


PDP-11/35 Restoration, Part 7

Friday, May 18 2012 at 7:24 PM PDT

Just a quick note. I'm not going to have much time to work on the PDP again until next weekend. But my plan is to disassemble the power supply completely at that point. The replacement H744 is on the way and I'll have it in my hands on Tuesday, that should go a long way to making things functional.

So, no, I'm not giving up. Not yet!


PDP-11/35 Restoration: The Nasty Power Supply

Sunday, May 13 2012 at 7:23 PM PDT

Today's activities were spent taking the H750 power supply out of the BA11-B chassis. I haven't found a scrap of documentation on the H750 or the BA11-B, so this was a little harder than it sounds. Luckily for me, DEC engineers of 40 years ago put everything together into a package that was fairly easy to figure out, so it didn't prove to be too difficult. Actually, probably the hardest part was getting the BA11-B out of the rack and onto the table without destroying my back. This thing is flippin' heavy.


PDP-11/35 Restoration, Part 5: Investigating the Diablo 30 Drive

Wednesday, May 9 2012 at 7:15 PM PDT

I got some guidance today on the classiccmp mailing list, and finally figured out how the AED 2200 Disk Controller and the Diablo 30 connect to the Unibus. So, with that fresh in mind, tonight I decided to de-rack the Diablo 30 and inspect it.

It came out easily enough, and I wiped it down with a moist cloth. It was startlingly filthy, but after a few passes with the cloth, it started to look like a disk drive again. And with the dust and dirt off the front panel, I was finally able to see inside. Yes, there's a disk pack in there. I don't know how bad that is - I'm pretty sure you're not supposed to move these drives with a disk pack inside, but I'm not sure. The head was obviously locked (there's a big "LOCKED" tab that is very clearly visible), so maybe it will be OK?

The screws that hold the top cover to the chassis were all badly rusted, but still came loose easily. Once inside I saw that things are mostly good looking. There's rust on some of the parts, but once again the PCBs and electronics look good, and the disk head looks OK. For now, I just buttoned everything back up and left it de-racked. I will get around to further inspection when I get to the point of trying to actually get it powered on. That will be a while.


PDP-11/35 Restoration, Part 4: The System Modules Come Out

Tuesday, May 8 2012 at 7:10 PM PDT

Big day today, restoration wise. I extended the 11/35 out on its rails until they locked, and flipped it up so I could get access to the underside. Like the top cover, the bottom cover of the 11/35 is missing - I assume ATARI got rid of it years before they scrapped the system. But the system modules (as the backplanes are called) seem to be relatively unscathed. The pins show signs of oxidation, but no severe corrosion. Electrical connections are probably OK, but I'll need to verify by tracing, once I've washed out the backplane slots thoroughly. Not tonight, however. For now, all I've done is remove the system modules and set them aside for future cleaning and testing.


PDP-11/35 Restoration, Part 3

Friday, May 4 2012 at 7:04 PM PDT

More vacuuming, and started using distilled water and clean rags to wipe up surface dirt on the chassis, front panel, and cables.

To switch gears a little and pulled the DSD-440 dual 8" floppy drive from the rack and and cleaned the chassis with a soft damp rag. Upon opening it up I discovered that the interior is almost pristene! Very little dirt inside. This bodes well.


PDP-11/35 Restoration, Part 2

Thursday, May 3 2012 at 7:00 PM PDT

More card pulling, but no washing. My main goal was just to get the chassis empty of cards, get all the cards photographed, and get them into antistatic bags. So far, only the first four cards have been washed. I think I'll probably end up finishing disassembly before I do any more washing, anyway.


PDP-11/35 Restoration, Part 1

Tuesday, May 1 2012 at 7:01 PM PDT

My first night of restoration! I started by getting hundreds of photos of everything from every angle, so I could document the original state as best I could. I also made note of the system configuration before I started to touch anything.

Next, I did a little gentle vacuuming of the surface dirt. There was plenty of it. Fiberglass insulation had become packed into some areas of the card cage, along with the remains of insects, some live spiders, and a few acorns. I sucked this out as best I could.

The original state, as seen here, is just disgusting, really.

card_cage_start-768x576.jpeg
Figure 22: Mouse-nest infested and very dirty BA11-D chassis

After some light vacuuming, I began to remove cards. I started with the four farthest to the right, the M7232, M7231, M7233, and M7235. Each card I pulled was photographed so I could know its original state, gently washed in warm soapy water, and rinsed with distilled water before being allowed to air-dry in front of a fan. Remarkably, the cards so far are in great condition! There's some corrosion and spotting here and there, but nothing so bad that I think the electronics won't work. Mainly it's bits of surface rust and discoloration on chip leads, nothing worse.


PDP-11/35 Details

Monday, April 30 2012 at 6:56 PM PDT

Here's a little more information about the PDP-11/35.

It came to me with the following peripherals:

  • ECCO Paper Tape Reader
  • Diablo Series 30 disk drive – compatible with DEC RK05
  • Applied Engineering 2200 Disk Controller for the Diablo Series 30
  • Data System Designs DSD 440 floppy disks – compatible with DEC RX02
  • DEC H750 Power Supply

There are three backplanes (or "System Modules", as DEC called them) installed. The first is a 9 slot KD11-A, the second is a 4 slot MM11-S, and the third is a 4 slot DD11-A. The MM11-S is interesting in that it suggests that the 11/35 originally came with the MM11 16KW core memory option, though somewhere along the line that was upgraded to MS11 MOS memory.

Here's the layout:

Slot Contents
01  
02  
03 M7232 - KD11-A 11/40 Micro Word Module
04 M7231 - KD11-A 11/40 Data Paths Module
05 M7233 - KD11-A 11/40 IR Decode Module
06 M7235 - KD11-A 11/40 Processor Status Module
07 M7234 - KD11-A 11/40 Timing Module
08  
09 M981 Jumper, M7800 Async Serial
10  
11 M7847-BD - MS11-EP 16KW RAM1
12 M7847-DJ - MS11-JP 16KW RAM
13 M920 Jumper
14 DSD 440 Floppy Controller
15 ECCO Paper Tape Reader
16 G772B, M7800 Async Serial
17 M9302 Terminator, G727A
  1. The MS11-JP module is normally an 8KW board, but this one has been field upgraded to 16KW of MOS RAM, minus parity bits on the upper 8KB.

Rescuing a PDP-11/35

Sunday, April 29 2012 at 4:00 PM PDT

On Sunday, April 28 2012, I picked up a PDP-11/35 from a friend who had been storing it in a shed for many years. The system has been home to generations of spiders and mice, and needs more than just a little bit of TLC.

cpu_disks-225x300.jpg
Figure 23: The PDP-11/35, dirt and all

The provenance of the machine is kind of interesting. The friend who gave it to me grabbed it from the loading dock at ATARI in Milpitas, California, when it was being scrapped. They were apparently using it in some kind of standards or verification engineering role, but it's not known what. He later moved to Washington state, where the machine was stored in a shed for some time. Unfortunately, the climate and the local wildlife took their toll.

I'll document ongoing progress on restoration here on the blog. Luckily, my initial inspection suggests that things are not as bad as they look. The electronics are in fair condition, with only very little surface corrosion on some IC leads. The metal chassis and power supply case have some bad surface rust, but can be stripped and re-painted. The front panel and switches are mechanically sound. I think it is definitely worth restoring!


Morse Code The Slow Way

Monday, September 12 2011 at 3:44 PM PDT

I've been doing this ham radio thing for just over a year now. Even though I don't talk very much, I still really enjoy listening and occasionally making long-distance (DX) contacts. One area of study I've been dragging my feet on for ages is learning Morse code. If you're not into ham radio, you may assume that Morse code died out with the telegraph, but the amateur radio bands are still alive with Morse code. Up until 2007, knowing "the code" was still an FCC requirement to obtain the highest level ham license, and before 1990 it was required of every license holder, regardless of level. Those of us who got our ham radio licenses after 2007 never had to experience the sweaty palms of an FCC Morse code exam!


Computer Journalism in the Dark Ages

Friday, July 1 2011 at 1:29 PM PDT

I've recently been reading Brian Bagnall's book On the Edge: The Spectacular Rise and Fall of Commodore. It's a good read, if a little rough in places and perhaps in need of more judicious editing.

But while reading it, I've also kept some source materials by my side. Thanks to modern technology, I have my iPad with a collection of Byte magazine from the late 1970s sitting next to the book, and it's been fun to go find the original articles that Bagnall sourced for his work.

This morning I was reading about the launch of the Commodore PET 2001 at the 1977 National Computer Conference in Dallas. The segment in Bagnall's work mentioned a positive review in Byte by Dan Flystra, so I looked it up. What struck me immediately was the date. The computer was ordered by Flystra in June, 1977. The review was written in October, 1977. And at long last, it was published in March, 1978.

This seems remarkable now. From product purchase to review in subscribers' hands: nine months, the length of time it takes to make a human being. Even disregarding the long lag time between order and delivery (vaporware is timeless, after all), we're left with five months between review and publication. In an age of Twitter and Facebook, this seems incredible, absurd. Yet, I remember these times. They occurred within my lifetime.

That makes me feel old.

How far we've come. Think about it the next time you watch an unboxing video of some new gadget on Youtube that was filmed an hour earlier, and just two days after the order shipped direct from Shenzhen, China.


New Call Sign

Wednesday, October 20 2010 at 10:39 PM PDT

Well, I finally have my new call sign. It showed up in the FCC ULS database on Friday, and I'm still getting used to it. Say hello to NF6Q!

It definitely feels a bit weird to have a new call sign. But I'm pleased to have a call that's easier to say and much more friendly to DX.

Now I'm working on a new QSL card. I got a very stock card for KJ6HZC, so I'd like something a bit nicer for NF6Q.


Going Mobile

Thursday, September 23 2010 at 10:55 PM PDT

My home location is unfortunately very poorly suited to ham radio. That's a subject for another post, but suffice it to say that if I want to get on the air I need to go portable. A lot of the time I adore going out and setting up on a park bench, putting on the headphones, and making QSOs. But other times I'd like to be able to just turn on the radio and get on the air without all that setup and tear-down fuss, you know?

Well, that's where Going Mobile fits in, I hope. Since my only HF radio at this time is made for portable and mobile use anyway, I've decided to do a proper mobile installation in my Honda Element. I've been inspired by KI6ZHD's excellent mobile install that bypasses the main car electrical system except to keep the radio batteries charged. I've just ordered a TG Electronics N8XJK voltage booster and West Mountain Radio Powergate PG40S to handle power distribution and charging. Once the wallet recovers a little, I'll head down to Ham Radio Outlet and inquire about the Little Tarheel II mobile HF antenna and a good mount.

Hopefully by the end of October I'll be getting on the air with a /M after my call sign. It's not exactly the DX-ing wonder of a home ham shack that I'd like, but it's a heck of a lot better than not being able to get on the air at all!


Vanity

Wednesday, September 22 2010 at 1:48 PM PDT

I spent a rather silly amount of time agonizing over what vanity call sign to pick. In the end, I chose a 2x1, and some backup 1x3's. I won't say yet what they are, but I should know in a few days which one I'm likely to get. To be honest any of them would be great, and they're all much less tongue-twisty than KJ6HZC is. Will I have a new call sign before Pacificon on October 15th? Maybe, but only three weeks to process a vanity application is pretty optimistic. Wish me luck!


Success!

Saturday, September 18 2010 at 11:08 PM PDT

After a couple of weeks of solid study, I drove to the Saratoga Fire House this morning and took the Amateur Extra upgrade exam. Boy was I nervous! After all this time, I still sweat every test like a Freshman in college. But I didn't have to worry. I got all 50 questions correct, didn't miss a single one. So as of 10:05 AM this morning, I'm KJ6HZC/AE.

Once my new license class shows up in the FCC database, I'm going to pick out a vanity call. Back when I started this whole process, I thought I'd be perfectly happy with whatever call the FCC gave me, but as it turns out KJ6HZC is just plain hard to say. Almost everybody gets it wrong the first time they come back to me on the air. And I don't blame them! I had trouble with it myself for about two weeks after I got my General. So it's time to get something short, sweet, easy to say, and DX-friendly. I'm thinking a 2x1, since 1x2s in 6 land are rarer than hens' teeth.

But for now, I'm just happy to get on the lower parts of the bands for the first time and see what's out there.


Time to Upgrade

Friday, September 10 2010 at 5:16 PM PDT

I have such a knack for ignoring this blog, haven't I? Well, nothing like a new post to help me break out of the habit.

These past few months I've been having more and more fun with amateur radio. Why on Earth didn't I get into this sooner? Well, I'll be honest, when I was younger I didn't have any interest at all in ham radio. It's not that I was /un-/intereseted in it. It's more that it simply didn't enter my mind. I gave it no thought. So of course I wasn't a ham. It wasn't until I indulged in a desire to pick up a short-wave radio in 2008 that the idea popped into my head to check out this ham radio thing.

I'm glad I did, of course. I've been enjoying the hobby tremendously since getting my license in May. In July I bought a Yaesu FT-857D radio and a Buddipole antenna, and I've been operating from a local park almost every weekend. Some weekends I make no contacts. Some weekends I only make three or four. But it's always fun!

There are three amateur license classes in the United States. The first, Technician class, grants quite a lot of privileges on VHF and UHF bands, but only very limited access to the HF bands. The next level up is the license I currently hold, the General class, which grants full privileges on a lot of the HF spectrum too. It's certainly good enough to do some DXing (that's what we hams call talking to folks in other countries), but it doesn't allow access to all frequencies, including some of the most used ones.

Well, now that I know that I'm here to stay, I think it's time to upgrade to the highest level license, Amateur Extra. It allows the most access to every amateur radio band. I've been studying hard, and I've finally picked a date. On September 18, I'll take the exam and, with luck, I'll pass on the first try. It'll be nice not to have to keep triple-checking to make sure I haven't accidentally let my VFO wander down below 14.225 before I transmit!

Next up is finishing the other task I've been working on for the past few months: learning CW (morse code). It hasn't been a requirement for the license since 2007, but it's not fading away. In fact, it seems to be regaining some popularity. There's no doubt that it's still incredibly useful, and one of the very best modes to use when doing DX! I can't wait until it's second nature for me. Unfortunately, for the time being it's still "painfully slow" rather than "smooth and easy".

Wish me luck!


Ham Radio

Friday, May 21 2010 at 11:26 AM PDT

Last Saturday I drove down to the Saratoga Fire Station and took the FCC amateur radio license exam. Well, actually I took two of them; one for the Technician class, and another for the General class. On Wednesday, I got my call sign, KJ6HZC.

I'm still surprised at how fast it went. I first got interested in ham radio in 2008, on a whim. I bought the ARRL Technician class exam study book and read the first two chapters, but then put it down when life took a couple of left turns. It wasn't until April of this year that I picked it back up and decided I really wanted to study and get my license. Within a few weeks I was comfortable enough with the Technician and General material to schedule my exam session, and just four days after the exam, my call sign was in the FCC database. Remarkable! I understand that in the "Good Old Days," when exams were given at FCC field offices by disinterested bureaucrats, it could take three months or more to get a license after the exam. That's right, it may be hard to believe, but apparently the Government is actually more efficient now, at least at the FCC.

I'm just dipping my toes in the water at this point. My only radio is a Yaesu VX-6r handheld (or HT, for "Handy-Talky") with a Diamond SRH77CA 2m/440 antenna, so I'm not going to be doing any DX'ing any time soon. But I do hope to pop up on some of the local 2m and 440 repeaters and talk nets from time to time.


Here we go again

Sunday, December 20 2009 at 4:10 PM PST

It has been almost five years since I maintained a weblog on anything like a regular basis. My attempts since then at making regular observations on day-to-day life have been spotty at best, and all have been aborted before they had a chance to grow.

I hope that this time, finally, I'll achieve the kind of momentum I need to keep writing. Will it work? Only time will tell.