Thanks Exxos!
That's right, the counter that's addressing the RAM that's being read (twice) gets the 32MHz clock, and the counter for the RAM that's being written gets the clock divided by 2.
I'll post the schematic later and you can have a look.
Thanks Exxos!
I don't think there's actually a way for the mod to know for sure when the RGB cycle is... That's an unsolved problem for now. But I don't think the screen artefacts that I'm seeing are related to RGB lines settling - in all cases I'm seeing pixels intended to be displayed at one location appearing earlier or later in the scanline, which you can see when moving the mouse around the screen.
Have you checked signals like RW on your scope to make sure simply noise on that line causing the issues ?Smonson wrote: ↑Mon Apr 08, 2019 12:30 pm Thinking on what you said about latching, I added a latch on the RGB lines coming out of the RAM when generating video, and that improved it a bit. So that's defeated my line of thinking about how it was more likely to be appearing at the write stage. Clearly, there are noticeable glitches appearing at read time.
You need a synchronous counter in that case.. The asynchronous counter you are using is where each clock will have a delay to the next flip flop. The synchronous ones drive all the clocks from one pin so you do not get the delay..Smonson wrote: ↑Mon Apr 08, 2019 12:30 pm One thing about this design is that I'm driving those 4040 binary counters way too fast. And when the RAM's being read to generate the scanlines, it's double the speed of the one doing writing, so it does make sense that issues would show up there.
I used SN74HC4040PWR, and looking at the datasheet, I can't expect them to work at 32MHz. Possibly it's all down to that reason. And the more I think about it, the more likely it seems, since those counters are made up of a string of flip-flops and there's a propagation delay between each bit, with the most significant bit changing last.
I agree. Like you say, a lot has been learned from this board and it is totally possible for the project to work. So that is great news a huge step forward!Smonson wrote: ↑Mon Apr 08, 2019 12:30 pm What I can do is go up to the next bigger CPLD package (100 pin) on the next revision and generate those counters in there. That would, at the least, remove the settling time delay of the ripple counter. Depending of course on whether it will fit OK on the board. I've kept it to the dimensions of the shifter's metal box.