Do You Want To Build an FPGA? Part Two

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.

The Blank Slate

We left off looking at a blank slate, an empty project.

Empty Project

This is always the most intimidating part of any project. What do we want to do?

The next step is to define a top-level design file. From the menu. select FileNew…, and you will be presented with a list of components. Select Block Diagram/Schematic File from the list.

New Block Diagram

Next, click FileSave As… from the menu, and save the new top level design file as flashy.bdf.

We won’t get very far with just a blank design file. We need a Verilog Module to define the behavior we want from our counter, so next, choose FileNew… from the menu, and select Verilog HDL File. This will open up a blank Verilog file, ready for your input.

New Verilog

The Verilog “counter.v” Module

Verilog is a language that defines how our FPGA is to behave. It’s tempting to think of it as a programming language, but it’s dangerous to fall into this trap. It’s not a programming language, it’s a hardware definition language.

What’s the difference? A programming language describes linear process that implements an algorithm step-by-step. A hardware definition language, on the other hand, describes how a digital circuit should behave using words. It is not implementing an algorithm, it’s implementing a circuit!

The distinction can seem very subtle. When you’re describing how hardware behaves, it can certainly look very much like a program or an algorithm. But it’s not, and it’s always very important to keep that in mind. So, we want to design a circuit that will take a 50 MHz clock signal as input, and count down on the 8 LED outputs forever.

Here’s our Verilog module to describe that behavior. Save this file as “counter.v”:

Verilog Module

It’s short and sweet. The top-level module definition has two arguments, clk_50, which we will map to our 50 MHz clock signal, and leds, which we will map to our LED outputs.

Internally, there are two registers: an 8-bit register named leds, and a 21-bit register named counter. These are used to latch state in the circuit. Because we’ve named one of the registers the same as one of the outputs, they will be automatically connected for us.

The critical part of the circuit description is the always @(posedge clk_50) block. This describes what happens at the positive edge of a clock trigger on the clk_50 input. It says that we decrement our counter register, and if the counter happens to be all 0’s, we latch the state of the LEDs plus one into the leds register. We’re using the internal counter register as a delay to slow down the rate at which we update the LEDs.

You may be confused at this point, because I said our circuit was going to count down, but clearly we’re incrementing the leds register. What’s that about? Well, it turns out the BeMicro CV uses LEDs that are active low, meaning that they light up when the corresponding output is grounded. The end effect is that if you want all the outputs lit, you write 00000000 to the output. In other words, when we count up with our leds register, it looks like the LEDs are counting down. If you wanted the LEDs to count up, you could just invert the output. I’ll leave that as an exercise to the reader.

Adding the Verilog Module to the Project

We’ve described a simple circuit here. Now we need to tell Quartus how to connect the inputs and outputs of our circuit. To do that, we’ll first need to make a circuit diagram symbol for our module.

Right-click on the “counter.v” file in our project, and select Create Symbol Files for Current File

Symbol File

Quartus should compile your file. If you get any errors, double-check to make sure there are no typos! After it’s compiled, you can close the Compilation Report tab, and then return to the flashy.bdf tab.

Right-click anywhere inside the flashy.bdf tab, and select InsertSymbol… from the context menu.

Insert Symbol

You should be presented with a dialog like this. Select the counter symbol from the Project folder, click OK, and then drop the symbol anywhere into the flashy.bdf tab.

Counter Symbol

Now we have a symbol placed into our project, but we still need to map its inputs and outputs. Right-click on the symbol you’ve just placed, and select Generate Pins for Symbol Ports from the menu.

Generate Pins

There, now things look a little more complete. We can see that we have some pins named clk_50 and leds[7..0].

Pins

Connecting The Pins

Although our symbol now has inputs and outputs, those inputs and outputs are not yet connected to the real physical BeMicro hardware! To do that, we’ll need Quartus’s help.

From the menu, select ProcessingStartStart Analysis & Elaboration. This step will analyze our top-level schematic and figure out how many inputs and outputs we’ll actually be using on our FPGA chip.

Start Analysis

The module will compile, and Quartus will analyze it. Depending on your hardware, this may take a minute or two. You should eventually see a compilation report letting you know the analysis was successful. You can close the compilation report once you’re done reviewing it.

Analysis Report

Now comes the critical part: We can map our circuit’s inputs and outputs to real FPGA pins!

From the Assignments menu, select Pin Planner

Pin Planner Menu

You should be presented with the Pin Planner. This dialog allows you to map the flashy inputs and outputs to the FPGA’s pins. You’re actually looking at a real map of all 484 pins on the FPGA, but don’t worry — we’re only going to be using nine of them!

This is where we have to turn to the BeMicro’s documentation for help. We want to figure out what input the 50 MHz clock is on, and what outputs the LEDs are on. I’ll save you some time and pain by just putting the information here, because it turns out that the BeMicro CV documentation is wrong. Their mapping of LED pins is out of order. Oops!

Here’s how the BeMicro CV actually maps its pins:

FPGA Pin Voltage BeMicro Mapping
H13 1.8V 50 MHz Clock
Y3 3.3V LVCMOS LED 7
AA2 3.3V LVCMOS LED 6
AA1 3.3V LVCMOS LED 5
W2 3.3V LVCMOS LED 4
U2 3.3V LVCMOS LED 3
U1 3.3V LVCMOS LED 2
N2 3.3V LVCMOS LED 1
N1 3.3V LVCMOS LED 0

We need to map these using the Pin Planner. In the end, your Pin Planner should look like this:

Pin Planner Mapped

It’s safe to close the Pin Planner window now, and you’ll notice that the symbol has changed somewhat, to show that the inputs and outputs have been mapped.

After Mapping

Now you’re ready to compile the whole project. From the Processing menu, select Start Compilation. Compiling should take a minute or two, depending on your hardware.

Once it’s all done, congratulations! You’ve built your first FPGA module! Now all you need to do is actually load it onto the FPGA and start it running. We’ll cover that in our next and final blog installment.

Rural Cable Expectations

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.

Here’s a picture of where I grew up. It’s in rural Connecticut, about a half hour east of Hartford. The whole “neighborhood” (if you can call it that) had cable TV as of 1988. Please note, too, that many of the homes you see to the north weren’t built until the late 1990s and early 2000s, so the area was even less dense then than it is now.

Rural Connecticut

Cable broadband came to this area later, of course. It wasn’t installed there until about 2000, when the infrastructure was upgraded to allow DOCSIS. My aunt lives there now, she has great 25 Mbit broadband through Cox. So, yes, frankly, I did expect that cable could be here.

And what about now, today, in Washington State? Here’s another satellite view of part of Kitsap county, the county I live in.

Less Rural Washington

Here is where it gets weird. Notice the fairly dense neighborhood to the north of the highway? That area is completely unserviced. Comcast’s internal maps, which I have seen, show that the whole neighborhood is wired with Comcast cable. But, in reality, it’s not. There’s no cable there, Comcast has no customers there.

Meanwhile, the road to the south, which is more rural, with a mix of houses on 5 acre lots and farm land, is fully wired for Comcast.

So, yes, I did expect that cable would be a thing that this part of the county could do. It is not that unusual here. In fact, the neighborhood to the north is an exception, not the rule.

But all that should not distract from the core problem, here: Comcast told me that my address was already serviced. That is what I relied on, not some mystical third eye that could show me underground Cable TV infrastructure.

Do You Want To Build an FPGA? Part One

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?

The Tools

Altera FPGAs are programmed with the Quartus II suite of software. There are versions for both Windows and Linux available. For this Tutorial I’m using the Windows version because it felt like the path of least resistance.

If you’re used to developing software with an IDE, it’s not too dissimilar at first glance, but don’t be fooled! It’s more like an IDE on steroids. The Quartus II download is massive, weighing in at roughly 5.2GB for the full package. Given my current broadband woes, I visited a nearby coffee shop to download my while I sipped on a tasty beverage.

Downloading Quartus II

This is perhaps the most annoying step. I think it’s time for Altera to accept that hobbyists are using their tools, and make the process a lot easier.

The Quartus II Web Edition is totally free to download and use for your hobbyist projects, but in order to do so you’ll have to register with Altera and create a user profile, complete with a lot of information that really only applies to companies.

To download Quartus II, follow this link.

By default, you’re downloading the entire package with files for all sorts of different Altera devices. If you’re on a slow connection or you would like to save a little bit of disk space, you can choose to download only the files necessary for the BeMicro CV board by selecting the Individual Files tab, and under Devices, de-selecting everything except Cyclone V device support. (Remember, the BeMicro CV is a Cyclone V, so you need that!)

You’ll be prompted to register for an account when you try to download. I won’t walk you through this, it should be fairly self-explanatory. Use your best judgement here to decide what you need to enter when it comes to things like company name and company data.

When you’re done and logged in, go back to the download page and continue to download the software. It’ll take a while. Enjoy some quality time with coffee or tea.

Setting Up Quartus II

Once everything is downloaded, double-click on the installer and follow the instructions. I just used the defaults throughout the installation.

After Quartus II is installed, double-click the Quartus II icon to get started.

Quartus II Icon

The first time you run Quartus II, you’ll have to click through a dialog box to let it know you want to run the software without buying a license:

Quartus II first launch

Finally, you should be greeted by something of a blank slate, ready to create a new project.

Quartus II New Project

Your First Project

We’re going to walk through a very simple project. The goal of this exercise is to get the 8 user-programmable LEDs on the BeMicro CV counting down in binary from 11111111 to 00000000 forever, in an infinite loop. It should be fast enough to look cool, but slow enough for you to see it actually happening. I’m calling this project “Flashy”.

To get started, click on the New Project Wizard link in the middle of the IDE. This wizard will go through the steps of setting up our project.

At the first dialog, enter a location and name for your project. I’ve named my project flashy, and put it into a folder on my Desktop, under C:\Users\Seth\Desktop\Projects\flashy. Then, click Next.

New Project - Name

On the next dialog, click Empty Project, then click Next again.

Empty Project

The next dialog asks if you’d like to add any files to the new project. We don’t, so just click Next.

Add Files

The next dialog is critical! It asks us to pick which device we’re going to target. To narrow down the choices, select the following from the pull-down menus:

  • Family should be Cyclone V (E/GX/GT/SX/SE/ST)
  • Devices should be Cyclone V E Extended Features
  • Package should be FBGA
  • Pin count should be 484
  • Core Speed grade should be 8
  • Finally, under Available Devices, select 5CEFA2F23C8

Be absolutely sure that 5CEFA2F23C8 is selected! This is the exact device used by the BeMicro CV, it must match the chosen device. Then click Next

Device Selection

The next page in the Wizard is the EDA Tool Settings page. The only thing we need to change here is the Simulation Format. Pull down the menu and select Verilog HDL, then click Next.

flashy_6

The final page just asks you to verify everything. Make sure the Device is 5CEFA2F23C8, then click Finish.

Confirmation

Congratulations, your shiny new blank project is set up and ready to start working on!

In our next entry, we’ll look at how to write your first Verilog module and compile it.

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

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

Jump to the FAQ

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.

January 29, 2015

This was our first interaction with Xfinity. Earlier in the month we had placed a separate order with Comcast Business for stand-alone Business Internet, but they said they couldn’t provide us with service, so they cancelled the order on us. They suggested that we contact Xfinity and get consumer TV and Internet instead. That sounded like a fine idea to us, we like TV! So that’s what we did.

We ordered our service on January 29th. We went with the Digital Starter package and the “Blast 105” Internet service with a 2-year contract, very standard. They told us that we would have a tech visit us to do the install on January 31st between 10 AM and 12 PM.

January 31, 2015

The tech came out as scheduled. The first thing he expressed to us was surprise that we didn’t already have a Comcast box on the side of the house. We searched the property, and in fact, there was no Comcast box anywhere. Now, there is a coax utility box, but it wasn’t Comcast’s. That originally confused both of us, but on further inspection, the utility box with coax running into it used to be hooked up to a satellite system on a pole near the house (with the dish now removed), so it wasn’t CATV at all.

The tech told us that in order to get service, we’d need to have coax run from the road to our house, which would probably also involve installing a new service pedestal along the way. He called to set that up for us, and told us he was going to do something called a Drop Bury Request to bring in service. He filed a ticket and went on his way.

February 3, 2015

Not having heard anything from Comcast, we called them on the 3rd to confirm the Drop Bury Request. They gave us a ticket number (#027246726) and promised us that someone would call or email us about it.

February 6, 2015

We hadn’t heard anything from Comcast, so I placed a follow-up call to their support line. We were told nothing. The support person couldn’t even look up our ticket number for us, so we ended the call.

I decided to call back a few hours later and spoke with someone named “Walter”. They were also no help. So I called back a third time and spoke with “Leila”, who scheduled another tech visit to come out and see what was going on on February 9th.

Around this time, we had an un-expected and un-scheduled visit from a technician, before the 9th. Regrettably, I didn’t write down his name or the exact date of the visit. He just appeared out of nowhere and asked us where our cable box was. We explained that we didn’t have one, but that we did have a Drop Bury Request in place. He looked perplexed. He told us that there was no way a Drop Bury Request could possibly get us hooked up, we were too far away from the cable infrastructure. We asked him to contact someone at Comcast to get things resolved, and he left.

Februrary 9, 2015

The scheduled tech dropped by on the 9th, as promised. Just like the previous two techs, he had absolutely no notes on his work order about any Drop Bury Request, any pedestal, or any construction. He just showed up expecting to hook up a cable box and go on his way.

We explained, yet again, that we did not have cable service to the house, and that we were trying to find out how to get it serviced. He couldn’t help us, but he promised to escalate the issue to Comcast Engineering.

Well, that sounded extremely promising. He said that Engineering would be able to get things moving, and then he left.

February 12, 2015

On the 12th, I called and spoke with a Comcast salesperson named “Lee” to ask about progress. There were two big issues on my mind. First, what does “serviceable” mean? All along every step of the process, Comcast kept promising us that our property was “serviceable”. What precisely does that mean? The Comcast support agent told me that “serviceable” meant that there was a cable run to the house.

That was a bit of a stunner. I explained, very clearly, that there was no cable run to our house at all. How can our property be called “serviceable” if there’s no cable here? They didn’t really have an answer for me.

But, more importantly, the second issue I wanted to know about was the progress on the Comcast Engineering request. I was put on a brief hold, and the support agent came back to tell me that they were working on it. His exact words were, “They assured me that they will bring you service.”

That was good enough for me, I figured things were moving along fine.

February 13, 2015

I just wanted to follow up on the Engineering Request and get more information, so I called again on Friday the 13th to find out what the next step was. I spoke with a sales support agent named “Jessica”. I explained the history of my requests, and she looked at all the notes on my account. At this point she put me on a lengthy hold to “speak with Engineering”.

She came back onto the line and told me that things were progressing just fine. Good news! They’re just in the process of pulling permits for construction, which can take a long time. She said they might have some more information in about a week.

Well, I was overjoyed. I figured that was that, the wheels were finally moving. Little did I know.

February 17, 2015

Again, I wish I had written down the exact date, but another tech came by unannounced. Just the same as the other techs, he had no knowledge of any engineering request, no knowledge of any Drop Bury Request. And, just the same as the other techs, he thought he was just going to install a cable box and go on his way. Needless to say, there was nothing he could do, so he left.

We had a second visit shortly after that from a site surveyor, who said he was just looking for the nearest cable node. He wasn’t there to bring us service, just do surveying. He mumbled something about how it was going to be a very expensive job, then left.

February 20, 2015

So, I gave it about a week. I called back on the 20th to find out what progress had been made. I spooke with “Matt” in Sales.

Matt looked at my notes, and said he couldn’t find anything about an engineering request. He said that engineering doesn’t necessarily update your notes anyway, so it wasn’t that surprising, but there was a bigger problem: He said that my order had “timed out” because it sat so long. He would need to re-order service for me.

I was floored. “Timed out?” How can that even happen?

Anyway, I took the opportunity to upgrade my order to an even more expensive plan, hoping that “greasing the wheels” of capitalism would make the process move a little faster. I asked for the works—The Digital Preferred bundle with TV, Internet, telephone, HBO, HD, the whole shebang, with a two-year contract. Couldn’t hurt, right?

“Matt” then told me that in cases like this, Comcast can often do a “temporary drop” to get service started while waiting for construction. Well, awesome. I didn’t actually expect a temporary drop to work, but I figured it was worth trying. So he scheduled a tech to come out between 8AM and 10AM on the 21st.

February 21, 2015 – Morning

The tech showed up at about 9 AM. The very first thing he said was, “I hate to tell you this, but I don’t think you have cable!”

Wow. Really? Do you think?

Just like each and every tech that had come out before, this one had absolutely no notes on his work order about our situation. He was just there to hook up cable. He said there was no way he could do a temporary drop because we didn’t have cable run to the house. He left.

February 21, 2015 – Afternoon

At this point I called Sales again to figure out what my status was. I spoke with “Pat”. What Pat said shocked me. According to her notes, the work was done. On the 17th, she claimed, the survey work was done. Then, on the 21st (the same day) the installation was done. So, according to her, we now had service.

I explained that no, we did not have service. No outside work had been done. No construction had been done. No engineering work had been done.

To move forward, we had to open a whole new order for service, same as before.

And what about that Engineering request? Well, Pat couldn’t find any reference to an Engineering request. She saw nothing in my notes to indicate that any Engineering request had been made.

She opened a new “ER-1” Engineering ticket (#027574739) for me and promised that I would be called or emailed within 24 hours.

February 22, 2015

I gave them their 24 hours and heard nothing, of course. I called back and spoke with “Mark” in Sales. He looked over my notes, and told me that the ER-1 ticket had been closed as an “invalid ticket” because it did not involve a Drop Bury Request.

To his credit, Mark seemed pretty shocked at how I had been treated. I explained that we’d been visited by six techs so far and all of them had said the same thing. I explained that we’ve been trying to get new construction. I explained how frustrated I was.

I think this was the most productive call I’ve had so far, because I finally got the clear picture of what’s going on. Somewhere in Comcast’s system, there’s a check box that says that I already have cable service to the house. Every time I call to ask about new service, someone looks at this checkbox and concludes that I don’t need construction. Whenever a ticket is opened in regards to construction, it’s closed automatically because the system believes it’s not necessary. So I am literally in a Catch-22.

Mark did give me a good lead. He gave me the phone number for the Comcast New Construction Department (1-866-772-2281) and told me that I should give them a call on Monday. They deal with new home construction, subdivisions going up and so forth, so they may not be exactly the correct department to call, but hopefully they will have more information than Sales has.

Mark also claims that he has opened a New Serviceability Check request. I anticipate that nothing will come out of that.

February 25, 2015

This has been a very interesting week.

On Monday, this very blog post made its way to the Comcast planning office via a follower on Twitter who (and I promise I did not know this) works for Comcast. They called me almost immediately and were very apologetic about the entire situation, on a personal level.

This led to a serviceability engineer coming out to measure the exact distance from our house to the nearest Comcast plant. It turns out to be approximately 2500′.

I was given a very rough initial estimate of $20 per foot to do the line extension work. Now, that sounds high to me. I don’t know what will come of this, but at least there’s some movement going on, and that’s more than I could have dreamed possible a few weeks ago.

The next step will be for their engineering department to work out exactly how the cable would run, via what poles, how much is underground, etc., and come up with a final price.

February 26, 2015

Oh, this is fun. I got a call from a generic Comcast call center this morning asking me why I cancelled my latest installation appointment. Insult to injury, they started to up-sell me on all the great things I’d be missing out on if I didn’t reschedule! I just hung up.

I don’t anticipate this had anything to do with the line extension. It was just what happens whenever you cancel an installation, I guess. Still, I cursed under my breath.

March 2, 2015

It’s now been 34 days since the saga began. Right now, things are in a holding pattern. I’m still waiting to hear back from Comcast about what the total cost for a line extension will be, and I’m sure it could take a few more days (at least) to get the results from Engineering.

In the meantime, I have done a tremendous amount of research about CATV infrastructure, and learned more than I ever really wanted to know about it. In addition, I requested and obtained a copy of the franchise agreement between Kitsap County and Comcast so I could better learn about my rights and Comcast’s obligations in providing new service.

I think the take-away of this whole thing so far can be summed up in two bullet points:

  • Never trust Comcast Sales when they tell you that service is available. Verify if yourself, and if that means you need to spend two weeks studying up on CATV infrastructure so you know exactly how to spot trunk line, line extenders, taps, and HFC nodes, then do it.
  • Know your rights. Always request a copy of your CATV franchise agreement and read it thoroughly. They’re usually quite long, and full of legalese, but it’s worth it.

March 12, 2015

It’s been a while since an update, but there’s just not a lot of news right now.

Last Thursday, the 5th, two engineers from Comcast (Robert and Ken) came out to do another survey in preparation for a final engineering design. I’ve been warned that the initial, pre-survey price estimate was between $56,000 and $60,000 for the extension. Now, I wouldn’t have to pay all of that out of pocket — Comcast is supposed to pick up part of the cost, but I don’t know how much.

I haven’t heard anything else from Comcast since March 5th, and I don’t know what the final estimate will be. I don’t know how much I’ll have to pay out of pocket, and I don’t know how long it will take. So, that’s where we stand.

In the mean time, we’ve started to look at excavators who could do the trenching work for us. If it would be cheaper for us to do the trenching rather than Comcast, I’d rather go that route. It might save a significant amount, I don’t know.

There is still so much left unknown. The waiting is the hardest part.

March 20, 2015

This is a hard update to write.

We got bad news on Wednesday, the 18th. At about 3:45 PM, Robert called and told me that Comcast will not do the extension. No ifs, no ands, no buts, they just won’t do it. They wouldn’t even give me the chance to pay for it. Too much effort on their part.

I’m devastated. This means we have to sell the house. The house that I bought in December, and have lived in for only two months.

I don’t know where we go from here. I don’t know if there’s any kind of recourse. I do know that throughout this process, Comcast has lied. I don’t throw that word around lightly or flippantly, I mean it sincerely. They’ve fed me false information from the start, and it’s hurt me very badly.

This whole thing would have been avoided if only Comcast had said, right at the start, that they didn’t serve this address. Just that one thing would have made me strike this house off the list.

I don’t know exactly how much money I’m going to lose when I sell, but it’s going to be substantial. Three months of equity in a house isn’t a lot of money compared to sellers fees, excise taxes, and other moving expenses.

So, good bye dream house. You were the first house I ever owned, I’ll miss you.

Frequently Asked Questions

I wanted to address a few FAQ’s about this post, this seems like a fine time to make some clarifications.

  1. Q: Why Didn’t you check this before you moved?

    A: Oh, but I did. Having broadband of some kind was an absolute requirement for our new home. Before we even made an offer, I placed two separate phone calls; one to Comcast Business, and one to Xfinity. Both sales agents told me that service was available at the address. The Comcast Business agent even told me that a previous resident had already had service. So I believed them.

  2. Q: Why didn’t you get this serviceability status in writing?

    A: I tried. When I asked for serviceability in writing, I was told it just wasn’t something Comcast could do, that they have no process for it. We were simply assured, verbally, that there was service here. And, besides, they clearly did believe that I was serviceable, or they wouldn’t have sent six techs out to hook me up.

  3. Q: Didn’t you even check to see if the house was wired yourself?

    A: We did. The house is actually loaded with coax. There’s a coax drop in almost every room, in fact. Moreover, on the side of the house is an unmarked grey box that feeds the coax into the house. From this box, two coax cables disappear underground. So, to our (at the time) untrained eyes, this sure looked like CATV infrastructure.

    It turns out, though, that this was satellite. Years ago, a previous owner had satellite TV, and the underground coax used to feed a dish that is no longer there, on a pole next to the driveway.

  4. Q: Shouldn’t you have expected that your rural property didn’t have cable? Why were you surprised?

    A: I’ve addressed this question in a whole new post

  5. Q: What about other options? Have you looked at DSL?

    A: You bet we have! Our local provider here is CenturyLink. I called them almost immediately after the first tech said we didn’t have service. We were told “No problem! We’ll get you hooked up right away.” The very next day, they called me back and corrected themselves. “Actually,” they told me, “it turns out your area is in ‘Permanent Exhaust’, so we can’t add new DSL customers. No, we have no plans to upgrade anything. So sorry, and bye!”

    Needless to say, we were not happy.

  6. Q: Lots of places have fixed point-to-point wireless. What about that?

    A: We also looked into this very quickly. In fact, there is a wireless provider that serves much of Washington (StarTouch). I called them to inquire about pricing, but was stopped short. “I’m very sorry. We used to serve your area, but last year somebody built a building between our tower and Poulsbo. We lost a lot of customers. There’s nothing we can do for you.”

  7. Q: What about wireless networking with a neighbor?

    A: We haven’t ruled this out yet, but a couple of things make this very challenging. First, our terrain makes it pretty difficult. We have trees here, big trees. To establish a clear line of sight to any location with broadband would require us getting above the tree line, which is about 100 feet (30 meters). We’d need to build a large tower just for that. Second, point-to-point wireless is degraded in the rain. We live in Washington. It rains here a lot. And finally, it may be difficult to find a neighbor willing to work with us. All that said, it is absolutely still worth investigating.

  8. Q: Well, what about Satellite?

    A: The TV service would be just fine, but it carries a huge penalty for broadband. I work remotely full-time, and I require a VPN to access the main office. Satellite does not guarantee any support for VPN use (though I have heard a few anecdotal reports of people having success). The monthly bandwidth caps are also a killer, giving very little leeway in overage situations.

  9. Q: How are you getting any work done right now?

    A: I’m living off of a Verizon JetPack mobile hot spot. It’s frightfully expensive and has a 30GB per month cap, but it allows me to get my work done, at least. I spend all day on a VPN back to company HQ and use close to a gigabyte a day, so I bump up against the 30GB cap every month. That means I have to be pretty careful with my data use. No streaming, no games, nothing fancy.

    When I want to download a big file, like an OS update or a VM image for work, I go to the local Starbucks. Their Wifi is great.

The 1993 Social Network

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.

Compared to a lot of other schools, Cornell’s UNIX cluster was small and under-powered. Resources were scarce. The whole campus had to share four DECstation 5000s running ULTRIX with home partitions mounted over NFS, so they actively discouraged new users. I don’t remember the specs (you can use your imagination) but I do remember how laggy things got when there were 30 or so users logged into each system. We called this cluster “The Cruxen”, because the systems were named crux1, crux2, crux3, and crux4.

The thing that made this cluster special was not the hardware or the software; it was the community that formed around it. By mid-1993, a great many of my friends had accounts on the Cruxen, and it didn’t take long for the cluster to become a place to meet, talk, share ideas, and kvetch. One of the most common ways to talk to each other was the UNIX utility write, which allowed you to send a short one or two line message to a user logged in on another terminal—long before the term ‘instant messanger’ had been coined, we were doing it on UNIX. We used last and finger to see when someone had last logged in, and to watch for them to log in again. For more immediate, longer-form communication, we used talk to connect two terminals together and watch each other type back and forth. And of course there was always e-mail, and Usenet, a global network of hundreds of computer bulletin boards covering every subject under the sun. The Cruxen were a social network, as surely as Facebook is today.

Really, it was more than a social network. It was a Social Network++, a fully programmable social network. Interesting projects sprang up on the Cruxen. It was easy to share scripts and coding projects back and forth when everyone had access to the same filesystems, programming languages, and tools. Of course sometimes disasters happened, but they were rare. Once, a friend built a distributed queue manager for POVray rendering, so that all the Cruxen could render an animation frame in parallel. He did not leave enough idle time, and ended up taking down the whole system. I myself once almost took it down by seeing what would happen if I created a .forward file that forwarded email to myself (discovery: it formed an infinite loop and quickly filled up the mail spool, bringing upon me the wrath of the admins). It was immense fun, and we felt like we were on the cutting edge.

But the fact is, we were late to the game. This scene had already been played out many times and in many places. From the late 1960s onward, big multi-user computer systems were places where people could form communities, whether running MULTICS or TOPS-20 or ITS or UNIX or VMS. This sort of thing was common-place in those environments. By the time we found the Cruxen in the early 1990s, the timesharing experience was already on the wane. By 2000, it was largely a thing of the past. Desktop computers that could do everything the UNIX cluster could do were cheap and readiliy available, and there was no need for a shared environment any more. Each of us now computes alone.

Is there any way to recapture this sort of experience? Yes! One of the oldest and best known is the SDF Public Access UNIX System. They’ve been in business since 1987, so they have considerable experience providing a UNIX cluster environment to thousands of users.

More recently, Paul Ford (@ftrain on Twitter) created an accidental phenomenon when he launched tilde.club, a place to build and share web pages on a plain-old UNIX box, just like we did back in the ’90s when the World Wide Web was young and new and we ran with Perl scissors.

And, finally, there’s my own brand new project, RetroNET, whose goal is to give a Cruxen-like experience to hackers and tinkerers and makers.

We can never go back to the days when we had to use a cluster to get our work done, nor would I want to. But we can still recapture some of the feel of that time, and I think we can still do good things with it here in the 21st century. So, whether you’ve used a UNIX system before or not, whether you lived through that time or you didn’t, I encourage you to at least give it a try. You never know who you’ll meet, or what you’ll learn.

Retrochallenge: The Final Entry

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.

Integrating with BASIC

I didn’t start this project thinking I’d tackle BASIC integration, but as Retrochallenge drew to a close, it seemed like it might be the best use of my precious time. What I mean by “Integration” here is simply having my ROM monitor code live side by side with BASIC and provide the underlying I/O functionality needed for BASIC to talk to the terminal and get input, plus the ability to take over and run in the foreground when the user wants it.

If you’ve ever used an Apple II, you may recall that it, too, has a built in ROM monitor, and it can be reached by typing CALL -151 into Apple BASIC. Well, when running Enhanced 6502 BASIC with my monitor, you can get the same thing by typing CALL -1239. Once you’re in the ROM monitor, you can quit back to BASIC just by typing Q. Like so:

BASIC Interop

It actually turned out to be fairly simple to get the integration working.

The first thing I had to do was re-organize my memory usage so as not to conflict with EhBASIC’s memory map:

There’s not much room left in Page Zero after EhBASIC gets done with it, but the locations $DE thorugh $E2 are free, so I made use of them. Page Two is similar, so I stuck my variables all the way up at $02A0 and on.

After that, I had to change the implementation of CIN a little bit, because EhBASIC requires that it not block. Instead, it expects this routine to return immediately and set the Carry flag if a character was read, and clear the Carry flag if no character was read. The new routine looks like this:

It’s a little ugly and could easily be optimized at the expense of readability, but hey, it works!

So that’s it. With just those changes, I was pretty much able to integrate the monitor into EhBASIC in just a few hours. As always, all of my code is available on GitHub for your viewing pleasure.

I’d also like to add that this has been a fantastic Summer Retrochallenge. There were so many amazing projects, I can’t even pick a favorite. I’ve really enjoyed reading what everyone else has been up to, and I’m already looking forward to January. Onward and upward, everyone!

State of the Retrochallenge

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

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

So I decided I’d reserve 20 bytes of memory in page 0 to hold the tokenized, converted data.

  • Byte 0 stores the number of arguments entered, not including the command itself
  • Byte 1 stores the command, for example “E” for Examine or “D” for Deposit.
  • Bytes 2 and 3 store the first argument, which is always a 16-bit address value.
  • Bytes 4 and 5 store the second argument, which is sometimes a full 16-bits, and sometimes only 8-bits occupying byte 4.
  • Bytes 6 through 20 are always 8-bit values.

Each implemented command then knows how to use this parsed data to fulfill its operation.

[An aside: Using page zero for this is controversial in my mind — 21 bytes is a lot of space to use, and page zero is precious, so I will move it to page 2 at a later date. But it will work the same, just a change in addressing mode from Zero Page,X to Absolute,X would be required.]

How It’s Implemented

The implementation is fairly straightforward. Here’s a very rough flowchart with some details elided:

flow

In general, the idea is to start at the beginning of IBUF, the input buffer, and scan until the start of a token is found. This location is then stored in TKST. Next, we continue scanning until the end of the token is found. The end is stored in TKND. Once it is, we walk the token backward, one character at a time, converting it from a hexadecimal ASCII representation into a number. Once we’ve reached the start of the token (or we’ve done 4 characters, whichever comes first), we know we’re done with the token. We jump back to TKND and start the process over again.

We do this until either:

  • The buffer is exhausted, or
  • We’ve scanned 17 arguments, total

whichever comes first. At that point, we fall through and start executing whatever command has been decoded.

The code is below.

Examining Memory

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.

Here’s the entry point, where the CPU jumps after being reset:

The code starts by making sure interrupts are disabled, then clears the Decimal Mode flag and sets the stack pointer to $01FF (it could be anywhere when the processor starts up!). Following that is the IO initialization routine, which is probably pretty familiar by now. We just set up the ACIA for 9600 baud 8-N-1 communication.

Then things start to get more interesting:

Here, we’re clearing the entire contents of Page 2 ($0200 to $02FF) in order to use it for scratch space. I’m using page 2 to store whatever the user types on the command line, which I’m referring to as IBUF (the Input Buffer). I’ve named this entry point HRESET, in case I want to be able to jump to it directly in a future version of the monitor.

Next, we welcome the user and start looping on input, parsing one line at a time.

There’s kind of a lot going on in this code, so let’s take it a little bit at a time.

At the very start, we print out a message (using our STR macro) that welcomes the user. Then, we print a “*” prompt, do some housekeeping, and finally wait for input. It looks like this when it’s running:

Running

EVLOOP is the main Eval Loop that takes a line of input and handles it. The NXTCHR block is the meat of this code. Every time a key is pressed, the character is appended to the IBUF input buffer, located at $0200. We’re using the Y register as a pointer into the buffer.

If the user ever presses the backspace key, there’s a separate routine that handles that. It decrements the Y pointer and echoes the backspace character to the terminal.

And when the user presses ENTER (which generates a Carriage Return/Line Feed combo), we jump immediately to the PARSE parsing code to handle the command.

And this is where I totally cheat:

This is a lot to take in, I know. But basically, it parses the command into two parts: A one-letter command, and a one- to four-letter operand.

The idea is that a user should be able to enter a command like this:

and be able to see the contents of memory address (“examine”) $01FF. I’m cheating because I totally ignore the value of the first letter, the “E” — right now, ONLY the examine command is implemented, you could use any letter in place of E. Ssshhhhh, don’t tell anyone. I’ll fix that later. Really.

But the rest of the code is not cheating. It works by using two pointers, Y and X, to walk the input buffer until the operand is found. When it is, Y will point at the start of the operand. Then we increment the second pointer, X, until it’s pointing at the end of the operand. At that point, we start taking the operand backward, one character at a time, and convert it from hex to binary. The value is stored in page zero in locations OP1H (high byte) and OP1L (low byte). If the input is malformed or isn’t hexadecimal, we abort by printing “?” to the console and then jumping back to the EVLOOP entry point.

When the operand has been decoded, we call another routine, PRADDR, to print the address, followed by a colon and space. Then, finally, we use PRBYT to print the contents of the memory at the desired address. Whew, that’s a lot of code. I haven’t shown the implementation of PRADDR or PRBYT here, but the source, as always, is up on GitHub. Feel free to dig through it if that’s your thing.

When running, it looks like this:

In Use

That’s plenty for one day. I hope to refactor this code a little and clean it up tomorrow, so I can start adding more commands.

Getting Input

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.

Recall the ACIA’s addresses:

To read in a byte of data, we’ll first need to check the IOST status and see whether bit 3 is a 1. If it is, there’s data to read. On the other hand, if it’s a 0 the ACIA doesn’t have any data for us. We can just loop checking that status. This is a technique called polling, and it’s the same technique we used for writing to the ACIA.

Here’s what the code looks like:

Pretty straightforward. Now we can use this in conjunction with COUT to just read in keyboard input, and echo it back out to the console.

But for my monitor, I want to do something a little bit more. I want to convert all lower-case letters to upper-case, primarily so later on when I’m parsing input, I know everything will be in the same case. Turns out we can do that with a pretty simple AND mask. But we only want to do it if the character is a-z, inclusive, so we’ll need a little branching magic.

Here’s my change:

Now if the character is < 'a' or >= ‘{‘ (which comes right after ‘z’ in ASCII land), we’ll skip the mask. But if it’s between ‘a’ and ‘z’ inclusive, we’ll apply a mask of $5F to it, which will strip off bit 5 and convert lower case to upper case.

That’s it for today. Tomorrow we’ll tackle saving input to memory and parsing it for commands.

Oh, and if you’re in the United States, have a happy and safe Independence Day!