I have a home rolled VGA controller going. The video memory is achieved with a IDT7134 dual ported SRAM chip. As far as I can tell from the datasheet, one can treat each "side" of the chip with complete disregard for what going on on the other "side". Obviously trying a read when the other side is mid write would not be ideal, but in my application, that's not a big deal. The screen memory gets read 60 times a second, so the occasional conflict of timing would just look like a flicker. As it is, I have no flicker anyway.

Anyway, it works, except I get scattered garbage on the screen along with my intended text. Often, the garbage is composed of segments of the text I wrote to other parts of the screen, so some sort of addressing issue seems a possibility.

My computer build uses the exact decoding scheme that is in the Garth's primer for 16k RAM, 32 ROM.

Currently, for ease of debugging, I am decoding the video ram with a 74HC688 magnitude compariter. Video RAM is at $6000

The following four signals are sent to the 688.

phase 2 clock. Its P pin is set LOW
A15. Its P pin is also low
A14. Its P pin is held HIGH. A14 signifies I/O memory, as per Garth's circuit in the primer
A13. Its P pin is held HIGH. A13 signifies VRAM space.

The other 4 P/Q pairs are all set LOW, as is the enable.

I have the active LOW output of the 688 going to the OE and CE of the computer side of the RAM chip.

It works, other than the random garbage on the screen. I tried setting the phase2 P pin HIGH just for fun. NO difference. I also tried pulling my 1 MHz clock out of the computer, and running at a slower speed from a signal generator. Didn't help.

I've been thinking its a code problem, but following it in a debugger (kowlaski sim), I can find no flaw. There is a lot going on on the software side. Scrolling code, and what not. I basically have a ring buffer in system memory, and I send it to VRAM.

So, ignoring software for now, is there any obvious issue with my decoding setup?

If you see stray writes, and your code is OK, there's a good chance you are still writing when the address lines change - perhaps at the beginning of a legitimate access, perhaps at the end. It's also possible (depending on your decode logic) that you are briefly accessing the chip at other times.

Can you post a photo of a hand-drawn schematic of your decode logic? That might be easiest.

This may seem obvious, and you may have done it, but have you run a basic memory test on the 2K (?) of SRAM? I'm wondering that, if the RAM is fine, maybe you have a couple of the address lines shorted or intermittent?

How is the system made? Breadboard, perfboard, etc. ?

(more questions than answers, sorry)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

If I'm understanding you right, it sounds ok, except that phase 2 needs to be high. You'll get the video RAM at $6000-7FFF, which was VIA1 territory, so you'll move that to where VIA2 was, 2 where 3 was, etc. instead, per the comments under the diagram in approximately the middle of the 6502 primer's address-decoding page. Do a search for:
Otherwise writes to VIA1 will step on video RAM (and vice versa!).

_________________
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?

Sounds like it could be a scanning issue on the display side. A picture of the on-screen garbage might help. What’s the screen resolution? The 7134’s only a 4kB chip. The screen might repeat if it's bigger than the memory size.

_________________
http://www.finitron.ca

I assume the 688 is too slow compared to the very fast IDT. When /CE is deasserted the data to be written may already has vanished.
Perhaps you can generate a "qualified" /WE for the IDT using some fast gates?

OK, I'll answer a few questions. About to do my taxes, so it will be a bit before a proper schematic can be posted.

First, Yup, that was a typo. Phase 2 is being decoded for HIGH, not LOW as I first wrote. It doesn't seem to matter though...Same result, for better or worse.

No VIA installed. Only I/O is a 6551 that resides at $5000, and the video RAM chip.

RAM chip is big enough Its 4k, and I only need 3200 bytes for 80x40 characters. Actual resolution is 640x480, but my controller's character generation scheme only requires ASCII to do its thing. Also, I can arbitrarily write to any screen location, its just the extra random characters showing up that's an issue.

Very intrigued by the notion of a speed mismatch between the faster IDT chip, and the 74HC decoding logic. How would I handle this? If I'm understanding, I need R/W to go high quicker so that it isn't waiting for the 688 to de-assert? It's currently run straight to the R/W pin on the CPU. I only just started suspecting hardware last night, so I haven't really looked at anything on the scope yet.

I guess my next move is to look at the timing of relevant signals on the scope, and look at the address lines on the logic analyzer.

I'll post a schematic of my decoding scheme in a little bit after I do the tax stuff. I've been slowly chewing away at this homebrew video controller for months and I at the cusp of success! It basically works other than this problem!

Here is a decoding schematic, and a scope shot. In the scope shot, the VRAM CE is in yellow. The R/W line is in blue. The PH2 line is in magenta. They are labeled on the scope too. Probed with a hideously long ground lead, so the signals are probably alot cleaner than they look. The CE on the IDT chip has clearly faster edges than everything else, so I guess 74HC is faster than the 6502's edges?

The only thing missing from the decoding schematic is a 6551 that uses A12, and the I/O CE from the schematic for its cs0 and CS1 lines respectively. I can see no way for a conflict there.

Any thing else that might be useful? Everything accept the pulse generation and character generation circuitry is on 2 bread boards. The two things mentioned are on a 4 layer PCB I had made mid project to clean things up. Obviously everything is destined for a PCB. I will check my address lines on the analyzer next. If any are mirroring each other, or otherwise misbehaving, that would explain stuff.

EDIT:My schematic is wrong. It shows That I send the output of the NAND that has both inputs tied to A15 to the 688. I actually send A15 itself. My scope shot confirms that I saelect VRAM when PH2 is HIGH.

Your address decoder should *only* be decoding /CE, ideally. /OE and /WE should be generated directly from Phi2 and R/W, using two NAND gates and an inverter (which could just be a third NAND gate with the inputs tied together). That way there's precisely one gate delay between the clock edges the CPU is sensitive to and the control signals the RAM is sensitive to. You can reuse the same /OE and /WE signals across all typical RAM and ROM devices, without needing to further qualify them with you decoded /CE lines.

As it presently stands, your /CE line is being deasserted slightly *after* /WE, which when coming directly from the CPU tends to change state about the same time as the address does, some time after Phi2 goes low. That's because your address decoder isn't nearly as fast as a single NAND gate would be. So your VRAM is more likely to see an unstable address at the end of its write access than your SRAM, which has /CE qualified by Phi2.

A good point, and an interesting one. In theory, switching off CE should be just as effective in avoiding stray writes as switching off WE. But in practice, CE will have a larger logic depth than WE, which could be a single gate - all writeable chips can share the same WE, and it just needs clock and RnW.

With a very simple production of WE, it will be fast, and will be able to disable writes before the address bus starts to change at the beginning of the next cycle.

When it doesn't matter whether your 688 compares PHI2 to HI or to LOW than this IS important - because it shouldn't be. And you (we) should be able to explain what happens in either case.

But before digging into this dirt - are these "errors" (random characters, wrong characters, correct chars in wrong position?) reproduceable? Can you e.g. wipe the screen then writing say dot from top left down to bottom right and always ever the same malfunction shows up? In what way you address your memory? I think about false accesses when using indexed addressing with page crossing.

Regards,
Arne

The false accesses should have a suppressed write signal, so they appear as ignored reads, shouldn't they?

The garbage is pretty repeatable. Same bad characters in same places.

I wouldn't read too much into that. I think your faulty decoding logic is just producing timings that are wrong enough for your VRAM to misrespond to reliably. Meanwhile your SRAM (and thus the machine in general) works properly because the timings are better. My advice would be as follows:

1: Remove Phi2 from *all* of your device selection logic. Re-introduce it only for any specific devices that don't have separate /OE or /WE signals.

2: This means your SRAM /CE should be a direct feed from A15, and your I/O /CE stays the same.

3: Generate /OE as (Phi2 ~& R/W), and /WE as (Phi2 ~& ~R/W) - that's three 2-NAND gates total. Make sure the Phi2 input goes to the last gate in the chain. You can run these signals direct to any /OE or /WE pins without further qualification, except for any devices with no separate /CE. Do not involve any address lines in producing /OE or /WE.

4: Your VRAM address comparator appears to effectively calculate ~(A15 & A14 & A13 & Phi2) for that /CE, selecting addresses $E000-$FFFF. You can replace that whole messy '688 setup with a 3-NAND gate taking A13-15 as inputs.

5: Perhaps I missed something, but I don't see any ROM. Normally that would occupy the high addresses noted above for your VRAM.

(That seems very clear and simple. But just a thought: both UARTs and VIAs can have state-changing reads, I think, so stray reads would be a problem with these chips.)