6502.org

"Quirky?" In what way?
It does update with the base clock (as per the initial Verilog code).
I have not, I'm not sure how this would actually help me. Using it as is, would not tell me if it was working or not, I need those other signals to generate something to see.

I would have no picture to go off of to see if it was still dropping out. (The sync light is very laggy and isn't a good indicator) The timings on the scope might say one thing, but the monitor I'm using could very well paint a very different picture. (No pun intended)

Further, I do need those counts to start at 0 on the visible section; along with all the other signals I'm trying to generate. Thus I would have to make significant changes to make it do what I need, likely breaking it back into the non functioning state.
Okay... I expected there would be things I need to optimize; however, I would rather get it working first before dealing with optimizing it.
Yes, please see the schematic; though a bit out of date now, but is still relevant.
Correct, and that's why I was checking to see what I was getting to the blanking signal. Effectively this is where the one offs are coming from. (I'll get more into that in a moment.)
Not sure how you would do that if you aren't outputting that to the rest of the circuit. >_<
Correct, I have sense as of the last posting looked this up and gained a bit more understanding of it.

In Verilog <= is an asynchronous assign. The cupl equivalent of:
= is a sequential assign, which guarantees the order and causing the statements there after to get the updated values.

I somewhat knew about this going into writing this thing, but was not totally clear on how it all fits together in the realm of Verilog, as such my first solution I came upon was to trigger on HC[0], though I highly doubt this is the correct way. (Works on the Arduino clock at human speeds, likely will fail when I speed it back up to 25.175MHz)
That is quite possible. (See above) It's all part of the learning experience right now.
That might be the better approach which I will explore.

Another idea I had was to effectively anticipate when those signals would actually change. I'm not totally sold on this idea though, I fear what that is making me do is second guess what the hardware might do, and that doesn't seem like a solid design.

My timing is correct. Yours isn't.
So, if it is stable and working. What are we asking here?
Looking at the circuit diagram you have provided, even you aren't using the blanking signal.

Near as I can tell my counts are fine, it's my understanding of how Verilog works that was off.

Going over your code in detail shows some rather odd things though, further adding to the confusion.

Yours Further: My code Mine (constant's subbed in)
Mine (constant's subbed in and offset to start at zero like you have) (Don't ask me why I elected to do that with a trinary operator instead of just negating it; IDK, probably too much C# in my life....)

My ending checks My testing shows on my scope that the signals I'm generating and the ones you are generating are close.

(Pixels here are calculated as time measured divided by 39.721946375372ns (or 25.175MHz))
(I should note that I figured out how to get much more accurate data out of my scope this time around.)

Yours: Mine: From tinyvga.com (for reference, not computed in my tests) (I'd kill for a table markdown.... >_<)

However, yours math's out to about 95 pixels in the sync pulse, as expected.

The total pixels per line are exactly the same. This is expected. We are both reaching the same net result.

You are incrementing always and then checking for 800. I am checking for 799 and incrementing only if I haven't reached that point.

There are however more lines per frame in your measurements, also as expected.
I believe I did say the image got much more stable prior to you suggesting my counts were off; I also specifically mentioned that I was pretty sure that I was sending pixel data during the blanking/syncing signals which is thowing off the black balance dection; and I even mentioned that displaying different characters seems to exacerbate the issue.

So in short, it's that BLANK signal that you left out that I'm pretty sure is the problem.
Very first post: Later post: That 74HC574 has sense made a reappearance. So yes, the circuit as I drew it at that time did not have the '574, but it is something I am periodically using and checking.

BUT those counts are in the schematic, so having them at zero is important still; regardless of the BLANK (or sometimes BLANKb depending on what I'm trying to test).

The CHAR_LD signal is also being used to signal to the shift register when it should load a line from the character ROM; that is also important, which in turn is also reusing the logic from the BLANK signal to know if it should even bother sending that signal at all. (Also mentioned in a previous post)

Glad you are all up and running.

Okay, after installing Verilator and checking my deisgn, I have worked out what was going on with that BLANK signal. Helps to pick good names for what you're using it for, I was tripping myself up with the name and how I was actually using it..... >_<

That sorted it seems like the other contributing factor was the rather dodgy connections with the dupont cables and my breadboards.

I've spent some time replacing most of those with actual cut wires and that has helped quite a bit. The image has stabilized greatly from that alone, though I do still get quite a bit of noise on the few that remain, I'll get to replacing them at some point soon.
I also set it up to pull characters from RAM.
The RAM is currently uninitialized so all I get right now is random garbage, but I can at least see the characters.

My next goal will be to adjust some of the counter outputs so the memory laid out in one continuous line to make the math on the 6502 easier; I will also be adding 4-bit color as well. The memory layout will be the same as text mode on the IBM PCs, as that is what I'm familiar with.

I also need to set it up so I can actually read/write to this memory. I'm still trying to work out how I'd like to to do this.

One idea was maybe to use the RDY to block the 6502 while the CPLD is accessing it. As the CPLD only really needs it for a grand total of 2 full resolution VGA clocks (one to get the character, and the other to get the color) this shouldn't present too much of a delay. However, my concern is that if the 6502 itself grabs the RAM first it could end up holding on to it for too long and thus throwing off the pixel timings.

Another thought would be to buffer the 6502 access through some additional latches or a FIFO, but that seems like it might get really complicated quickly.

Or Dual-Port RAM.... but where's the fun in that? (Famous last words)

One thing I was going to mention there is that when I'm making logic designs I almost always use positive logic, and have the signals be inverted at the input or output pins if that's the required electrical interface. I think I saw you were tracking an inverted blank signal in the code itself, which can make it harder to reason about the logical expressions it is part of. Or maybe I'm misremembering - just another tip, anyway!
These things can vary a lot, but individual wires are usually the most reliable so long as the gauge is fairly low. Higher gauges can give mixed results and then results probably depend on the quality of the breadboard itself. That said I've used all sorts of things on both cheap and expensive breadboards and one way or another the problems are generally possible to resolve with some rewiring if necessary.
It looks nearly perfect - you have the right number of characters (40x30 at 16 pixels square) and the characters look mostly artifact-free. I do see these issues which you may or may not care to deal with at this stage:

• The top scanline of VGA pixels appears to be coming from the bottom scanline of the first character row, rather than the top one
• The bottom scanline and rightmost column of VGA pixels appear to be missing
• The first character on each row seems to be struggling a bit with the scanline doubling

I would try adjusting the display up and left to see whether the bottom row and rightmost column are off the screen, or whether you're not outputting them.

For the top scanline and issues with scanline doubling down the leftmost column, I'd suspect these are caused by having your horizontal counters reset (and vertical counters increment) at the same point as the visible display area begins. It can lead to using the previous scanline's data for the first character of each row (including for example which character was read from RAM, for the top scanline of the character; I can imagine that the scanline-doubling issues could also be caused by something like this) You may be able to adjust the code to update the relevant signals one character earlier to get around this.

I have found that in some cases these kinds of artifacts seem to be caused by the monitor itself, and can't be fixed. For example I have a monitor that insists on delaying its very first scanline by one pixel; if I use the monitor controls to shift the display down a scanline, so that it is not on the first physical row of pixels the monitor has, then the artifact goes away. But usually they are issues with my signal which I can fix if I do the right diagnosis and have enough patience.
This can be more complicated than you might think when you are doing scanline-doubling or text-mode output, as you need to scan the same range of memory addresses multiple times on a range of scanlines - when you come to each subsequent scanline, you'll need to reset the address counters to the values they had at the start of the previous scanline, which is not going to be a nice round number. I've thought of a few ways to do this in the past (including of course just storing the right value and initialising the counters to that value on subsequent scanlines) but so far I have backed out from actually doing it because of the added complexity. Instead I embrace the possibility of having some room for horizontal scrolling, or failing that, just spare RAM for other purposes!

It might not be such an issue for you though if you have enough spare resources in the CPLD.
I've always avoided pausing the CPU clock. Most of my circuits have instead had it synchronised (i.e. driven by) the VGA clock, with careful timing so that any data written by the CPU arrives at the right time between reads by the video circuit. My most recent circuits have been asynchronous, however, capturing the CPU's write request in buffers and applying it to video RAM at the next opportunity, allowing the CPU clock to be independent of the video circuit.

Reading is harder to support than writing and you might consider just not supporting it.

There are a lot of options in any case, it'll be interesting to see what you pick!

Resetting the address counter is something the old machines like the PET have done in their original video circuit. And the principle is actually simple - latch the address at/after the last character of the previous charline and reset to that value at the end of a rasterline - except the last rasterline of the charline.

I have done an extensive analysis on my Youtube channel https://youtube.com/@8bittimes

André

Dual port for video data is certainly an easier solution. You can read and write any time leisurely and the CPLD can be small and cheap. The problem is cost of dual port RAM that limits the resolution/color of display. 4KB dual port RAM is inexpensive and good for mono text display, but color graphic displays require unaffordable large dual port RAM. You can build dual port RAM from regular RAM, but that needs CPLD with large number of I/O and more macrocells. It is a tradeoff.
Bill