OK, good to know!

This is awesome! Thank you so much, Bill!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

15 x 9 seems like a pretty common glyph size. I went with 16 x 8 because it made counting scanlines and loading pixel data a little more simple, but it seemed like there were fewer typefaces to choose from.

I'm curious, in your design how would you do the frame-buffer counters? When I was first learning about this I read "The CRT Controller Handbook" by Gerry Kane. He mentioned that you can have a linear framebuffer (all screen locations contiguous in RAM) or an X,Y framebuffer (screen locations on the same line are contiguous, but there's empty RAM between one line and the next). He doesn't give details for how to implement the two systems, however. I went with X,Y counters, because I couldn't see a way to make the linear counters. They have to count from 0 - 79 16 times, then count from 80 to 159 16 times, and so on, for 30 lines.

Now that I have a little more experience, I can think of a way to do it, using loadable counters and/or a couple of ROMs but it gets pretty complicated. Is there a simple way to do a linear frame-buffer?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

It would have been 8x15 for sure in my case, not 9. Standard VGA 80x25 text mode font is about 14 scanlines I think, in a 640x350 mode or something like that.

I'm pretty sure I picked 15 because it evenly divides 525. It looks like my sync ROM takes units of 16 pixels horizontally, and two pixels vertically as iirc the vsync is meant to be two scanlines. Though I've sent four scanlines in the past without problems. I'm not entirely sure though how I planned to get the vertical reset to occur at the right time, since the sync ROM lacks the ability to output something unique on scanline 15 of a character. That said it looks like I'm resetting the scanline counter to zero instead of one for the first row of the screen, so maybe that was a trick to mean that at the end of the frame the vertical reset occurs on scanline 14 instead of 15? Or maybe that's a fluke, I'm afraid I don't remember at all!


Microcomputers certainly used linear addresses when I was growing up - memory was precious! And chips like the 6845 only really support linear addressing, they internally reset the output address at the start of each scanline within a character row.

I think trying to do linear addresses with more discrete parts is more trouble than it's worth though - as you say, you really need an extra set of registers to hold the start-of-line reset address and presentable counters.

Apart from one of my designs, I've always had separate vertical and horizontal counters instead and live with the wasted memory. In the design I posted above you can see the framebuffer RAM being indexed by the low bits of the horizontal and vertical counts, and I guess I'm relying on blanking in non-visible areas where these addresses would wrap.

Schematic:

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Looks good I think. You probably don't need the inverter before the D flipflop, you can just use its inverted Q instead. Also I think for the address counters you might be able to avoid using CLK_P to drive CPR, as you don't really care much about the latency. As my circuit grew, the amount of load directly on the oscillator started to cause problems, so it could be worth using other signals for things that don't need to be synchronised to the pixel. For example, the vertical one could probably use the inverted HSYNC signal for CPR.

You can also just connect CPR to CPC and accept a full cycle of delay. You probably won't even notice it except during MRC or if you use RCO!

Good point! That's the kind of thing I miss when evolving one step to the next on breadboards.



Interesting. I haven't noticed any problems with that, but its certainly worth keeping in mind. Thanks, George!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Since "finishing" this project, I haven't done much with it. It was sitting in a tub in my workshop collecting dust while I worked on other projects (mostly Blue August). It still had some messy wiring, and the way it was "installed" was that it had some ad hoc address decoding on one of Blue April's project boards.

Well, since I had so much fun with this project I thought I would rebuild the VGA board using the same construction method. I also took the opportunity to rearrange the layout a bit to make the wiring better. Here it is with the power grid wired up: And here it is all finished: And here it is installed in the blue breadboard computer!

A while ago someone asked me to make a video of it working; I think it was George (gfoot) but it might have been Chad (sburrow). Anyway, I did that too. Sorry it took so long! Here's a short demo: https://www.youtube.com/watch?v=i76deH8oiyQ I shot it with my phone, which actually has a very nice camera, but it's kind of hard to operate it with one hand while typing, so the video is a little blurry I'm afraid. My video BIOS is very rudimentary so far, but I can clear the screen and output characters, so that's enough to show WOZMON working.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad