Take a 20MHz clock and apply it to an HC393 input. (3v3 supply)

Ignore Q0, AND Q1 and Q2.

Guess how long the false pulse caused by the overlap across the ripple counter is? 16ns... grrr.

Time for a rethink

Neil

That's longer than I'd expect! But yes you really need to sample those kinds of combinational logic circuits at a clock edge. The same edge that drives the counter is usually OK for me as there's enough delay in the counter that the transition occurs away from the edge. Even if the counter doesn't ripple, there are still issues with the logic gate's response to signals that are transitioning, and the transition takes some time too.

I think it's because of the 3.3v supply rather than the usual five. (And I meant 'OR' not 'AND').

A shame, it means an extra counter - 163, probably.

Neil

Well the initial divider works much better with a '163 instead of half a '393, but...

It seems I need to find a new logic family, or have a serious rethink.. this logic isn't happy at 3v3. I'm trying to generate a half-cycle at 20MHz (so 25ns) but the rise and fall times of the 74ahc74 are just too slow to let the signal get to proper levels (not helped by other delays through an inverter)...

Ignoring all the bouncing (no decoupling on this proto board except on the oscillator chip), the '74 is set every clock cycle, and reset on the rising edge of the yellow signal. At five volts, it's a lot healthier; at 3v3 it's a disaster.

Looks like the 165 is not the way to go, then, let's have a look at a '166

Neil

Hmm... well, I haven't seen the layout you're using. But your second statement makes me uneasy about the first.

As for '165 vs '166, I think you'll have smoother sailing with the latter.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

It's less of a layout and more of a rat's nest[0]. But it only had three chips on it... however, this works better: an ahc138 being driven by the 163, enabled by the clock.


The yellow trace drives BE at a 1:3 ratio; ph0 is a square wave in phase with BE. The idea there is that the processor gets access to the bus some time before ph0 rises, so that a 65c22 might work in the system. 65c02 clock speed is only 2.5MHz.

The video subsystem has access to the memory data and address via resistors, so if nothing else is driving the bus (e.g. the STM32 DMA system during video blanking) it can read the video data. It should get latched by the blue trace - '2' from the '138 (though thinking about it, as it's an async load, better one clock earlier during the access, not a problem with the 138). The memory is 45ns so there ought to be time. Need to do the sums on capacitive load, though, to make sure it switches fast enough. Might stick some bus couplers in there instead of the resistors...

Neil

edit: why 165 instead of 166? I was unsure, and ordered some of each, except that I <cough> accidentally ordered the 165s twice and no 166s. So 165s are what I've got

[0] the other reason I hate proto boards...

As mentioned elsewhere, I found a couple of HC166s - it's amazing what you find when you're clearing up for a house move!

From much perusal of the datasheets, both the 165 and 166 both suffer from having a combined load/shift pin, but the difference as far as I can see is that the 165 requires a short pulse within one dot period (i.e. without any coincident edges) to latch new data asynchronously while the 166 latches data on the rising edge of the clock, and so the load signal needs to be active across or synchronous to a clock edge.

For my SVGA, the video address will be active during counts 0 and 1 of a divide by eight with BE disabling the 6502 outputs. BE wakes up for counts 2-7 and phase 0 at count 4.

• Current design: 165; a 163 counter and 138 decoder gives a load signal during the latter half of count 1 (so 75ns for the video memory access)
• Option 2: 166, a 163 counter and 138 decoder to give a load signal either during count 1 or count 2 (not sure which yet but likely 1)
• Option 3: 166, a 163 counter preset to 0b1000 to count up and give a load signal during the TC count
• Option 4: 166, half a 393 counter, and a 138 decoder to give the load signal (as option 2)

Option 1 is already on the board, but it needs redesigning anyway; a couple of other things have had to change in the video timing. Option 2 is easy, just a rewire of the 138 inputs. Option 3 saves the 138, but would need to reset at 0b1110 (which might be easiest with the 138 anyway). Option 4 does away with the 163 and uses half a 393 which is currently unused...

The whole issue is down to the 65c22 on board which I am led to believe wants the 65c02's data bus active prior to phase 2 becoming active, hence just using counts 0 and 1 for video circuitry memory access. It would certainly be simpler to ignore this requirement and simply hope it works; in that case, option 5 exists: use the 393 counter, with bit 3 inverted as phase 0, and a 138 to generate a load pulse on count 4...

Neil (frustrated at the moment)

The 6522 can't care about the data bus before phase 2 because the 6502 doesn't drive it unless PHI2 is high. The 6522 does need its chip selects and other control signals to be correct when PHI2 rises though so you do need to reassert BE before then.

I get around this by not using BE and adding my own extea transceivers instead.

For the shift/load input on a 166, I don't think you really need much hold time, and your existing logic should be delaying things so that there's enough delay after the pixel clock before shift/load ends.

Yes, that was my thought: the video gets one quarter of a cycle, then the second quarter enables the 6502 busses so any early address decoding and control signals can happen to keep the 6522 happy, then the last half is all ph2 high and busses active.

(Unless the STM is doing DMA with the processor clocks turned off during video blanking).

Neil

edit: corrected 'phase' to 'cycle' for clarity

Hmm, don't know if I had a dodgy chip or a dodgy proto board, but I couldn't get the 166 to behave. Puzzling.

But I've also just realised I need to delay my line blanking or I'm going to be chopping the last character in half.

Neil