I hope it works soon! One thing that always puzzled me is how you would get the on-screen character data from the RAM into the character ROM and then into the shift registers to be displayed. To me, you have the RAM setup time, THEN you have the ROM setup time, THEN you finally hit the shift register. So, using 55ns SRAM and even 70ns ROM with some 10-20ns setup time on the shift register, that would be around 140ns or so, almost half of your 25.175 MHz divided by 8. Of course you would still need to access that RAM to input new data, so that's gotta be included too. You can see why I get scared at using a character ROM instead of just bypassing that entirely and sending RAM data directly to the shift registers (bitmap style).

But if you get something going, even if it's garbage on the screen, consistent garbage still tells a story! Would love to see a schematic of what you are doing sometime, but no rush. Thanks for the updates!

Chad

I think the notion is that you have an entire byte's worth of time (while the shift register is shifting) to get the next byte out of ram, over to the char ROM, and the dots from the char ROM out onto its data lines. It should be ready and waiting when the shift register is done shifting and clocks in the next byte. The "terminal count" pulse that signals the shift register to load the next byte will also be the one that tells the ram scan to move onto the next character (probably with a little bit of delay to make sure the shift register has time to snag the waiting byte before its wiped out). It helps that there's no color, so pixels and bits are fungible. In theory anyway!

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

As requested, random ROM junk:

I think this one is an early version of the SYNC signal generator ROM.

Here's Blue April's system firmware ROM (the first 256 bytes of it, anyway):




Edit: one thing to notice here is that you see each byte twice. This is what I would expect, because I tied the "character ROM" (i.e., random junk) address lines to the sync ROM's address lines. This means that the "character ROM" incriments whenever the sync ROM does, which is every 16 pixels. However, the output stage is running on the character clock, so it loads every 8 pixels.

This is with a 74hc166 (synchronous load) shift register.

Because the counters start in an unpredictable state, right now the output can be off by up to 7 pixels when I first power up. To fix that, I made a little reset circuit to synchronize all the counters. Right now it's just a push-button; I will need to convert it to a power-on reset circuit for the finished thing. But it does work! When the system is on and pixel 1 is where pixel 6 goes (or whatever) you can push the button, and everyone jumps over to where they belong.

I've been evolving this a piece at a time by building it on breadboards, so the "schematic" exists only in my head. You are right though; I should draw it all out. It's starting to get fairly hairy.

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

I would like to see a schematic so that I can duplicate it for myself! Thank you for doing the heavy lifting I was scared of.

So are you interfacing this through a RAM as well? Counters -> RAM -> Char ROM -> Shift Register -> VGA output?

Is it brighter at the bottom just because of the camera? Or is that in real-life too?

Looks really good, I like how clear it is coming in. And nice green tone, very retro

Very well done, thank you for the update! Love the progress.

Chad

I am interfacing through RAM in the sense that there's a 12ns 32k SRAM on the breadboard for use as video RAM. It's not hooked up to anything yet, though. One "layer" (as it were) away is the ROM that's just spitting out junk right now, but could be spitting out character pixel data. I'm a little stuck on the counters for the RAM scan, because it has to repeat each line 10 times (or 16 times, or whatever the height of a character is). This is where the magic of the CRT controller would come in handy...

I was thinking one thing I might could do is just chicken out on all the complex counting, and have the hardware just dump the RAM in order. I could leave it up to the firmware to make sure the pixel data from the character ROM gets to the right point in RAM. I'm not sold on the idea though, because I like the idea of an ASCII frame buffer.

It is brighter at the bottom because the LCD is an old one with a viewing angle that isn't great. The camera does exaggerate it too. One of these times I'll show the other test monitor (a big ASUS one). It photographs much better, but it has to sit on the floor because there's no room for it on the bench!

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

I made a little bit of progress today. I thought pretty hard about how to make a linear address generator and couldn't come up with anything simple. I'm reluctant to go back to the 6845 for various reasons (one of which is that I just don't like to give up on something until I've figured it out). So, I decided to use row / column addressing. That makes the counting problem considerably more simple to solve, at the expense of some wasted RAM.

So I started building some timer circuits. The first one was easy; I need a 0 - 15 scan line counter to tell the character ROM which line of a 16-pixel tall character we're on. It will count 0 - 15 one time for each line of characters, 30 times for a whole frame. I can use a 74HC163. It, by nature, counts from 0 to 15 over and over again.

To get the row part of the RAM address I need to count from 0 - 29. That takes 5 bits, which is more than a '163 can do without cascading, but I have some more '590s. I used a few AND gates and a NAND gate to detect "29" and issue a reset signal. I set up some LEDs to test it, and it worked fine.

Then I moved on to the column part of the RAM address: 0 - 79. I made exactly the same circuit as for the row counter, except that I needed to gate 7 bits to generate the reset instead of 5. This one didn't work. I did a lot of troubleshooting. I added a bunch of LEDs, used a slow clock, etc. No matter what I tried, it would reset as soon as bit 6 went high. I thought maybe it was crosstalk, or ground bounce, or parasitic capacitance, so I added a bunch of bypass caps and ground return loops. No change. It would reset, even though the LED on the reset pin never went out! So, I added a flip-flop to latch the reset signal, and that fixed it.

I'm not sure what to make of this. The row counter is identical, except for gating two extra bits to detect the reset condition. Maybe I should add a latch to that one too, just in case...



On the left:

74HC163, 74HC590, 74HC00, 74LS08, 74LS08.

On the right, my trouble lights, 74HC590, 74HC74.

All those loopy jumpers must be pretty noisy. I wonder if I could get by without the flip-flop if I replaced them all with nice flat wiring.

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

The '590 has an asynchronous reset, so any glitch on the reset input as logic is settling, e.g., due to logic hazards, could cause the counter to reset. Logic can be designed 'hazard free', however the latch you used is an appropriate and simple solution. I would think it's a good idea to use a latch for the row counter reset too, as it's possible it would suffer similar problems under some operating conditions.

I've been trying to write this post for a while, but I keep being interrupted! Holidays are a busy time for a musician. Anyway, a while ago Chad requested a photo of the character generator ROM in action. Here it is!



This is proof of concept, more or less. The 'B' is being decoded and displayed the way it really will be in the final version. The differences are that, for the moment, instead of a RAM frame buffer, I have an EEPROM with 0x42 stored at address zero and all the address lines tied low; and that to get stable vertical output I have all the counter reset pins tied to the VBLANK signal.

Here's the big mess o' wires:



I will continue to tidy it up as I work; there are some floating inputs I need to tie off, and I'll gradually replace all those big Dupont wire loops with cut-to-order lines. This has, on the whole, turned out to be much easier than I thought it would be.

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

Nice B's! I'm an type-A person myself, har har

I'm impressed, very good! The display is crystal clear, very good!

Are there intentional spaces between characters that are hard wired? Or are those gaps in the software/ROM?

My biggest concern is the timing. Not to press you, but I would be cool to see the the RAM -> ROM -> VGA.

Your mess o' wires is lovely work. It's funny that you are doing all of this without a schematic, all in your mind!

Great job, thanks for the update! Looks really good.

Chad

I don't think there's any space that isn't part of the glyphs; the "white" space (as it were) above and below each line is present in the character generator ROM (the glyphs are 16 lines tall, but the characters are shorter than that). The space between the 'B's (AAAAH! NOT THE Bs! AAAAH! THEY'RE GETTING IN MY EYES!) is also part of the glyph; I think it's one pixel fore and aft.



I almost had it today! Well, ROM -> ROM -> VGA. I had stable video for about 10 seconds using the row / column counters, and reading from the ROM framebuffer. There are just too many long wires though, and the clock signals are suffering. I'm going to have to consolidate onto fewer breadboards and rebuild a few areas. I think part of the problem might be that I had to use some LS gates, and their signals are pretty weak and bumpy, even with pullup resistors. When my next Digikey order gets here I will be able to swap them out for HC parts, and also reduce the chip count a little (using 4 input gates instead of 2).



Thanks! I don't know if it's such a good thing that I don't have a schematic. It's sort of like evolving a video card... I can't quite see how the whole thing works, but I know how parts of it work, and I can make and individually test those parts! I imagine that if I were good enough to make a schematic, I could probably design the whole thing all at once, have a few people check it for errors, build it, and have it work straight away. Evolving it on breadboards is kind of fun though, and I'm learning quite a bit. I'm almost to the point where I can wire up '163 counters from memory.

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

Haha!



My worry (from the beginning, for myself, not necessarily your design) is that the timing for RAM and then ROM and then the shift register is just too much for the very fast VGA to keep up. That's why I haven't attempted it (and why you are attempting it for me!).

If you say it's the LS chips and longer wires, good, because those are fixable. Keep me/us posted for sure!

Thanks for the updates, it's good to see progress.

Chad

This guy's long wires don't seem to have caused him any problems! (Slightly different approach to the same problem; but he is using a 25.175 oscillator and HC logic on breadboards!)

I think I have a logic error (I mean a thinking one) in my control signals. I did briefly manage to get decent output out of a 150ns ROM frame-buffer, so I am encouraged that the timing will be forgiving there!

I'm consolidating / rebuilding on a roomier breadboard setup so I don't have so many different "platforms" connected by flying wires. I was thinking I might make some little custom cables for the counters that drive the buses too, with some ground wires rolled in. That might increase signal integrity.

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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I already do most of that, but I am continually adjusting my breadboarding technique . One thing I don't usually do is put the bypass caps over the ICs; normally I trim the leads off and put them across the rails just by vcc. This particular time I'm doing as you suggest, and straddling them over the ICs. I have noticed, though, that on breadboards the bypass caps often don't do much after the first one, and can sometimes make the ringing *worse.* I guess there's already plenty of capacitance in a breadboard... What does make a HUGE difference is a robust ground return network, like you describe in the "avoiding AC performance problems" page of the Primer.



I have 50 yards of Cat6 with 23 AWG solid core on the way; I know Radical Brad *untwists* the twisted pairs to get the wire for his crazy Vulcan computer. I figure I won't have to untwist them.

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

Migration in progress:



The sync generator still works; that's a good sign! I got too impatient to wait for my CAT6 to get here, so I rolled my own. Maybe I will replace those chunky clock wires, but they're working fine for now.

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