Ted's Tidbits
About Archive Photos Replies Reading Tweets Also on Micro.blog
  • Happy 30th anniversary to Dave Winer’s Scripting News!

    → 7:55 PM, Oct 7
  • Dallas Morning News front page today

    → 3:46 PM, Nov 2
  • VGA Followup

    I need to remember how valuable writing is as a thought tool. The other night I was truly stumped as to how to solve my VGA problem.

    As I was finishing writing my previous post, I began to get an idea of where to start debugging my problem. I even said so in the post:

    Remember, there’s a break at the end of every line. This means that I need to start loading the character data for the start of the next line at the end of this blank period. There’s also a longer break at the end of each screen. This means that I need to load the data for the first character of the screen at the end of this blank period.

    I think this is where the bug is. All the characters in the first column are one half-line (at 320x240) lower than the rest of the screen. My best guess is that I need to start the data load a little sooner during the blank period.

    So, I looked for the code that calculates which row of pixels to load, and I found this:

    wire [11:0] rom_adr = { pattern_num, vga_vpos[3:1] };
    

    This line says, “the location in ROM is composed of the pattern_num (i.e. the ASCII character) and bits 3, 2, and 1 of the current line”. Apologies to anyone still reading this that isn’t familiar with binary numbers, but those details don’t really matter. What matters is what I put in bold above. We are using the value of the current line to calculate the value of the next character. This works for every character in a row, except for the first character.

    When we read the font data for the first character in a row, we are using a value based on the previous row. We need a special case for when we read the first character.

    This is what I ended up with

    wire [10:0] rom_adr = { pattern_num, (display_on ? vga_vpos[3:1] : next_rom_row) };
    

    Basically this says that if the display is on, use the current line position. If the display is off, (i.e. the blank period at the end of the line) use the next line position.

    There was some other work I had to to do calculate that value properly, but it works now!

    Monitor showing text. The first column is properly aligned with the rest of the columns.
    → 4:58 PM, Jul 2
  • Debugging a VGA Issue

    I’m building an 8-bit computer. I should probably write an overview of the project, why I decided to do it, how I got started, etc, but today I have a problem to solve.

    Take a look at the following image:

    LCD Monitor with text on a messy desk with a breadboard full of wires and chips

    This shows a VGA monitor displaying text at a resolution of 40 columns x 30 rows. Each character is an 8x8 block, giving an overall screen resolution of 320x240 pixels.

    Now, what’s the problem?

    Look closely at the first column. Does it look a little off to you? It did do me, which caused me to zoom in.

    text on a monitor, with a yellow line under the second row to show the character in the first column is lower than the rest

    The first column is one half-line lower than all the following columns.

    How can this be?

    It’s time to talk about how this is supposed to work.

    I have an FPGA that is acting as a video processor (like the VIC II in the Commodore or the ANTIC/GTIA combo in the Atari). I have a character font stored in ROM. There’s also a section of RAM that stores the ASCII values of the characters to display on the screen in order. The first byte in this section of RAM controls the character in the top-left corner of the screen. The last byte controls the character displayed in the bottom-right corner of the screen.

    In order to control a VGA monitor, the video processor sends the pixel data (either on or off in my case) for each pixel on the display starting at the top-left, one line at a time, moving left-to-right. This happens at a constant rate, with a fixed-length break at the end of each line, and a slightly longer break at the end of each screen. This process happens 60 times every second.1

    In order to display the expected values on the screen, the video processor must do the following:

    1. Load the next character from RAM.
    2. Combine the value from RAM with the vertical position on the screen to look up the font data from ROM. (Remember each font is 8 lines tall, so we need to know which line of the font to draw.)
    3. Send the font data out one pixel at a time.

    As you can imagine, the timing of these operations is critical. We need to load the next character from RAM and the font data from ROM while we are in the process of sending the pixel data to the monitor for the last character.

    Oh yeah, one other thing. VGA doesn’t technically support a screen resolution of 320x240, but it does support 640x480. So I’m drawing every pixel twice per line, and drawing every line twice.2

    When the processor is outputting the 5th pixel for a character, it starts loading the data for the next character. This seems to work just fine for almost the entire screen, except for the first column.

    Remember, there’s a break at the end of every line. This means that I need to start loading the character data for the start of the next line at the end of this blank period. There’s also a longer break at the end of each screen. This means that I need to load the data for the first character of the screen at the end of this blank period.

    I think this is where the bug is. All the characters in the first column are one half-line (at 320x240) lower than the rest of the screen. My best guess is that I need to start the data load a little sooner during the blank period.


    1. For a much better explanation of how VGA works, I recommend Ben Eater's excellent video.↩︎
    2. I want a 320x240 screen size because my 8-bit system doesn't have enough memory to support a 640x480 size screen.↩︎
    → 1:23 PM, Jul 2
  • Layoffs Will Continue Until Morale Decreases

    Cory Doctorow:

    The tech worker layoffs are best understood as an all-out war on tech worker morale, because that morale is the source of tech workers' confidence and thus their demands for a larger share of the value generated by their labor. The current tech layoff template is very different from previous tech layoffs: today’s layoffs are taking place over a period of months, long after they are announced, and laid off tech worker is likely to be offered a months of paid post-layoff work, rather than severance. This means that tech workplaces are now haunted by the walking dead, workers who have been laid off but need to come into the office for months, even as the threat of layoffs looms over the heads of the workers who remain. As an old friend, recently laid off from Microsoft after decades of service, wrote to me, this is “a new arrow in the quiver of bringing tech workers to heel and ensuring that we’re properly thankful for the jobs we have (had?).”

    → 1:55 PM, Apr 14
  • Five Dallas Council Members Call for Independent Study of I-345 Removal

    Matt Goodman:

    That’s the difficulty in this debate. It’s about the city’s future, a generational chance to trade eight elevated lanes of highway for an eventual new neighborhood. The members who added their names to the memo have expressed more interest in analyzing the opportunities removal could present; after all, traffic data cannot account for changes in technology and behavior, both of which inform how frequently people drive. As Councilwoman Willis asked last year, what happens if the city’s economic development plan creates jobs in southern Dallas so residents there no longer have to drive as far to get to work?

    → 9:10 AM, Apr 11
  • This just came in the mail. It’s about time I started trying to understand computers! 😜 📚

    → 11:44 AM, Apr 5
  • I’m finally learning how to solder. I think I’m doing pretty good.

    → 5:00 PM, Apr 1
  • I just started reading: The Apple II Age by Laine Nooney. This is going to be an interesting read.📚

    → 9:21 PM, Mar 28
  • I really enjoyed reading this interview with Cory Doctorow.

    → 12:43 PM, Dec 6
  • Have you ever wanted to start composting, but have been too lazy? Do you have gutters? Are you equally as lazy about cleaning your gutters? I may have some good news for you.

    → 4:07 PM, Dec 4
  • Things they don’t tell you about owning a home: you will periodically need to sweep your roof.

    → 3:51 PM, Dec 4
  • In the early days of Twitter, all people posted about was Twitter. We have now come full-circle.

    → 12:16 AM, Nov 18
  • I just got A Women’s Lectionary for the Whole Church: Year A by Wilda C. Gafney. I’m looking forward to using this to plan our Advent lessons. 📚

    → 7:14 PM, Nov 14
  • I haven’t given up on Twitter yet, but I’ve noticed several people I follow have started using Mastodon. My blog speaks Mastodon, so you can follow me at ted@tidbits.tedchoward.com

    → 5:31 PM, Nov 14
  • Robin Rendle doesn’t believe in sprints. I find myself agreeing with this position more and more over time. www.robinrendle.com/notes/i-d…

    → 11:14 AM, Oct 10
  • I want one of these! www.retrokits.de/index.php…

    → 10:35 AM, Oct 10
  • Global Temperature Over My Lifetime

    → 9:54 AM, Aug 10
  • How Traffic Studies Perpetuate a Traffic Congestion Obsession

    → 11:49 AM, Jul 28
  • TXDOT intends to spend $25 billion widening highways in cities. What if we tore then down instead?

    → 9:41 AM, Jul 20
  • Three Cheers for Socialism: Christian Love and Political Practice

    → 5:01 PM, Jul 15
  • The Spaghetti Warehouse Streetcar Is Taken Back by Pieces to the Neighborhood it Birthed - Dallas Observer

    → 11:21 AM, Jun 17
  • What We Really Lose When Highways Destroy Historic Neighborhoods - D Magazine

    → 5:31 PM, Jun 15
  • Why We Should Pay Dallas City Council Members More www.dmagazine.com/frontburn…

    → 4:36 PM, Jun 8
  • I built a computer on a breadboard!

    → 10:13 PM, May 16
Page 1 of 14 Older Posts →
  • RSS
  • JSON Feed
  • Surprise me!