Bill, thank you so very much. I'm seeing a solution to this problem is now possible, and feasible! Thank you for your help and insight.

Attached is my changes to the schematic. Is this what you are thinking about?

I decided to put those on the CLK, H1, H2, H4, and then also /CLK. That makes two stages of these series resistors. I did not include it on anything like /LATCH or other lines.

So I did some more reading on this, especially now that I have the correct words to search for. I see some folks use 68 ohm resistors instead, is this normal? I'm sure 68 or 75 doesn't change much overall. But I also now see WHY it helps, at least I think I do. The resistor slows the edge down, exactly where it would be bouncing/reflecting. So bounce + slow-down resistor = equalized signal.

Lastly, I already started changing the layout of the chips on the board, in particular so that the H1 & H2 & H3 = /LATCH logic is VERY CLOSE to the '161 counter now. Also, /LATCH has a shorter distance to travel to the '377. I was looking at my current board, and measuring trace lengths, and yeah, they are super long. The 3" per nanosecond rule sounds like a good guide. It seems my H1, H2, and H4 lines were travelling about 9" each, then /LATCH travelled 9" back! Definitely some issues there that I could easily eliminate.

Again, thank you so much Bill. This has been so very helpful. Have a wonderful day!

Chad

Chad,
I don't think you need to terminate H1, H2, H4. I was worried about the race between AND of H1/H2/H4 and clock but reading your schematic again I see I've missed the 'bar' over CLK driving clock input of 74HC377. ~LATCH is clocked on the falling edge of clock so H1/H2/H4 are stable so no need to terminate H1/H2/H4. You should terminate the output of U9D (pin 8) because that's PHI2 clock that goes everywhere. If you bring the 25MHz oscillator closer to U9, you don't need to terminate output of the 25MHz oscillator but you should terminate output of U9F because ~CLK also goes everywhere. So all you need are two 75ohm series termination resistors close to pin 8 and pin 12 of 74HC04.

The series termination resistor is not about slowing down the rise time of clock but rather absorbing the reflected clock signal. 75ohm is a guess as follow; your 2-layer PCB's characteristic is around 125ohm (a guess); the HC04 source impedance is maybe 50 ohm (another guess), so 75 ohm termination plus 50 source impedance matches the PCB's characteristic impedance. Hopefully it is close enough to absorb most of the reflected energy. There are lots of guess work here so I don't have problem with 68ohm resistor which may or may not be a better guess. I personally use 100 ohm quite often because CPLD has strong drive (i.e., lower source impedance) so higher series resistor value with lower source impedance to match the PCB's characteristic impedance.
Bill

Edit:
Signal integrity is complicated subject. For retrocomputing we can work around the problem by having solid power/ground distribution, terminating clock, using slow parts, and reducing the size of pc board. Signal integrity can raise its ugly head when you have fast parts like W65C02, W65C22, 10nS RAM, ACT logic and compact flash disk. In Z80 and 68000 worlds I hardly paid attention to signal integrity other than around CF disk but in 6502 world I've learned to pay attention to W65C02--it is a real noise maker.

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

Thank you for this Bill, again. Very detailed response with good explanations. It makes much more sense now.

So I eliminated the resistors on H1, H2, and H4. I also added one to PHI2.

But now I have a question: Would this reflecting signal change the characteristics of the '161? So, going back to the schematic, I have CLK input, and then H1, H2, and H4 output. Everything else is tied high or an NC output. So the ONLY thing that could change this '161s behavior would be CLK. On the PCB, CLK goes from the oscillator to the '161 very quickly. CLK also travels to the '590s pretty quickly, but takes forever to get to the '04. If CLK were to ring enough to make the '161 tick twice, I'd have MUCH bigger issues then a little flicker. Let's do some analysis:

CLK leaves the oscillator, hits the '161, which then changes H1, H2, and H4. Meanwhile CLK finally hits the '04 making /CLK. H1, H2, H4 start travelling to the '10 NAND logic, and outputs /LATCH. /CLK now travels to the '377, but is affected being high-to-low. /LATCH travels to the '377 and the '166s and stabilizes. Later the oscillator inverts CLK, traveling to the '04, making a new /CLK, and then to the '377, where it finally latches.

So let's say that the '161 was much faster than what it typically is, as that is the current thought. That means that H1,H2,H4 arrive even earlier, we get /LATCH even earlier, but still the '377 waits for /CLK rising edge. I don't see how it would have changed anything by being faster than expected. Though H4 inverted is PHI2, so perhaps PHI2 comes out faster than expected. But that part was not affected, the 6502 was running everything just fine.

It was only a flicker on the screen, which really comes down to the VGA color output. Backtracing: Color Resistors <- Shift Registers (controlled by /CLK and /LATCH) <- Video RAM (PHI2 on /OE) <- '590s (again PHI2 on /OE) <- CLK. So if it were the shift registers, perhaps they were getting hit with an extra /CLK (causing an extra black pixel) at times, but that's not affected by the '161. If /LATCH got to the shift registers too early, it would still have to wait for /CLK. Ultimately a faster '161 makes /LATCH faster, but it always waits on /CLK. A faster '161 could also make PHI2 faster, but that seems unaffected on the processor side, and that wouldn't cause flicker. Video RAM and '590 /OE lines are on PHI2, so if those happen faster than expected, I could get weird results on the color-data bus. But again those shift registers are waiting for /CLK. The other thing that could possibly change is a tiny bit of glue logic for /WRITE for the Video RAM, but I would have to be actively writing to the Video RAM to affect that, and the flicker was happening regardless of that (I write and then infinite loop essentially).

I am not seeing how a faster '161 would affect anything. A slower '161 could mess up all kinds of things, but physical experiments point to that it was not too slow, but too fast.



Thank you Garth, I appreciate the help, and the math! So, what I'll do is put a <= symbol next to the 75 ohm resistor silkscreen, because technically is running with 0 ohm resistors right now.

I think one of the bigger things I could do is make a better IC layout, make these particular signals as short as possible. And that is what I'm doing now. I actually did a proto-test with the VCC/GND lines, and then ran auto-router, and it finished in almost 30 minutes, which is amazingly fast (for the program I'm using). This means the new board layout is pretty good.

I'll keep this bad '161, and will test it on the next revision, but if it does or doesn't work with the added series termination resistors and better board layout, I am going to keep going forward and no longer worry about it, regardless.

Thank you Bill and thank you Garth. I appreciate all of the help here.

Chad

I agree finding the impedance of a physical network as implemented on 2-layer PC board without power/ground planes is difficult. Without good tools it is just educated guess. Nevertheless we do know there is an impedance and its value is relatively high, certainly higher than the source impedance of the driver so adding a series terminating resistor be it 68 or 75 or 100 ohm will help attenuate the reflection. Fortunately this is digital system so it is not about "matching" the impedance but more about "attenuating" the reflection. Success is when the amplitude of reflection is reduced below the logic threshold. This gives a lot of room for arm waving and also starts lots of arguments!



Signal travels on FR4 pc board about half of the speed of light or about 6" per nanosecond. With retro technology propagation delay of circuit trace is insignificant compare to logic gate delay unless there is a race between two signals. Your analysis of signal propagation as gated by CLK and /CLK are good analysis, ASSUMING CLK and /CLK have no glitches or reflection. The integrity of clock tree is absolutely critical in synchronous design. As an remote observer I don't know the specific of your flickering problem but your description of the problem feels like a glitchy signal somewhere that manifests when circuitry or operating condition are fast but goes away when slowing down.
Bill

First off, thank you for all of the help Bill. I appreciate it and will be keeping this on my mind while I continue through the next board revision.

So, I've been re-tooling my address decoding logic for the next board revision, and I've been hesitant to post it yet as it is still fairly early in development. But perhaps I could get some helpful thoughts on this new direction:

Attached are some pictures and my new schematics of my re-workings, of the address decoding in particular. The reasoning is that what I am missing from my current board is the ability to read Video RAM. This led me to find a new way to distribute what I'm already using, and with the addition of a single 74HC02, was able to really fine-tune my memory map.

$0000-$01FF = Zero/Stack
$0200-$02FF = I/O (with the VIA at $0200-$020F in particular)
$0300-$3FFF = ~15KB "Low" RAM, unbanked, general purpose
$4000-$FFFF = ~48KB Banked RAM or ROM, 8 banks each (16 total).
$8000-$FFFF = 32K write-only Video RAM, unchanged.

The idea is that I typically would be in say ROM Bank1, with the System Monitor, Assembler/Disassembler and other little programs I made for it. I could switch to another ROM Bank (as I already do for the 16-color bird demo picture) to run games or whatever else I might have. Because ROM is read-only, the Video RAM acts as write-only, so I double the usefulness of that area. But then I could also switch to RAM banks instead, which I figure would be helpful if I were loading a big program from the SD card or something. With the 16K Low RAM available, that is plenty of common ground between switching.

When I have a RAM bank selected, and I write to Video RAM, it would auto-duplicate in the selected RAM Bank, so now I could easily read what's on the screen without having to do weird coding workarounds. On top of that, I implemented CA2 as a "write-enable" for the Video, so it only really writes to the screen when CA2 is high, thus I can decide to use the RAM from $8000-$FFFF for other purposes if I wished.

I calculated that this would give me exactly 400KB of RAM possible with a 512KB RAM chip. Similar for the ROM. That seems pretty hefty!

I guess I'm wondering if you think this setup is useable. Feasible, sure, but is it practical? Could you see something that could change for the better? For example, earlier in my re-tooling, I only had 8KB of Low (Unbanked) RAM. I thought that was probably too small, so I reconfigured it for 16KB instead.

Thoughts? Comments? Anything is welcome.

Thank you everyone!

Chad

Since video memory consumes 32K, it is a good idea to overlay multiple banks of memory to make it read/writable. I can see multiple banks containing multiple sprites that you read, move, write back, and fill in the void left behind. It is also a good idea to disable the write to the video memory so the bank can be used as regular program memory. I do think when you are dealing with so many banks of memory, you should think about using 65816. Another observation is your logic decode is getting fairly complex so SPLD like GAL22V10 may be helpful to speed it up and reduce chip count, pc board size, and cost. GAL is inexpensive and can be programmed with your TL866 programmer. WinCUPL is a pain to use but there are a number of proficient users here on 6502.org (however, I refuse to use WinCUPL myself). You can also double your 6502 clock to 6MHz using SPLD.
Bill

Another alternative for mapping your video memory is to use a small window & a register.
The window could be from $300 to $3ff in CPU space. Currently only 128 bytes is required to map a whole row. Allocating 256 bytes leaves room for future expansion of the row size & is the maximum the 6502's indexed addressing modes can use.
The register controls which row the window maps to.
This actually simplifies the video routines a little. Acol_!.zip contains a sample.

The 65816's built-in bank address handling can simplify dealing with many mapped memory sections.
Whole 64kbyte banks can be assigned to each of the RAM & ROM & video RAM sections, so they're always addressable without adjusting mapping.
Loading or storing a byte of data in another 64k bank can be done in a single instruction using the absolute long addressing modes.
Calling a routine in another bank can be done with the JSL & RTL instructions.

Thank you leepivonka, good suggestions. And thank you for the code demo. Bill, I read your post a long time ago and have been thinking it over. Thank you as well.

It seems both you and Bill are thinking the 65816 is the future here. I do agree, but I am hardly trained and qualified to use that processor, as of yet. I will be considering it though, thank you.

As for the $0300-$03FF range for video, I was actually thinking of that very thing last night. It would free up a lot of room for general purpose RAM for sure. Thing is, it would be harder to read from video memory that way, as far as I can tell. I had at one time set up a bi-directional bus to the video RAM, but in the end I dropped it because the logic was getting very cumbersome. Still, I will be considering that. Thank you.

Thank you both!

Chad

To throw my own 2 cents into the mix, i also thought the 65816 would be way above my skill level, but after programming with it for a short while it just kinda clicked and i went "huh, it's just a 6502, but more".
You can use macros to deal with the "m" and "x" flags, and manually keeping track of the register widths is much easier than you might think.
it's the same with the Program and Data Bank. Unless you have some massive >64k Program, deal with multiple programs at the same time, or artifically split your program onto multiple banks, it's likely you'll just jump to some bank after powerup and just sit in there until the program is done.
and if you set up a C environment with Calypsi C or WDC's Compiler, then there is even less low level stuff to worry about, unless you start writing assembly functions that are supposed to be called from C.

so overall i'd say that if you're proficient enough with the 65C02 to be writting your own Monitor and Graphics API/Functions, then you're definitely ready to try out the 65816.
but obviously, no pressure. if you personally don't feel ready for the 65816 yet, then just wait until you do.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Previously:
On the usefulness of 65816 as a 65C02 alternative

Thank you all for the suggestions on the 65816. It would make the banking structure easier for sure.

An update: Inspired by Agumander's GameTank Emulator (here https://github.com/clydeshaffer/GameTankEmulator), I made my own little "Acolyte Simulator" program in C. It is slower than mud, does not have full functionality, and is lacking a TON of basic and required stuff... but it ran this little demo program, just as expected.

Agumander used the embedded mos6502 emulator (here https://github.com/gianlucag/mos6502), which is probably 50 times better than what I'm doing. I eventually would want to do something similar.

Overall this has been a half-a-day's long project, and I'm impressed with the results so far. It would at least save me from pulling the ROM chip each and every time.

My latest parts from Mouser just arrived, and I'm about to send off the next revision's board to be printed. Don't expect an update for a while, life events will be happening that will keep me from soldering for a long while. Other than that, thanks everyone!

Chad

Another update on the emulator/simulator:

Attached is a much better simulator for the Acolyte 6502 Computer! It has a fully functioning keyboard, all of the color modes, and is much faster than mud now.

I went with Agumander's version of the "mos6502" library, which already included the 65C02 commands. Thank you Clyde! Gosh, that took a whole 5 minutes to implement, wish I would have done that earlier.

I'm including my C++ code, as well as my big "Bank1" assembly code. It worked right off, I haven't changed anything in the ROM and it's working as expected.

I'll be altering this to make it closer to Rev3 now, with it's own banking system and whatnot. I don't know how well I can simulate the VIA, so I probably won't attempt that for now. This isn't a replacement, just a helper tool so that I don't need to keep taking the FlashROM in and out of the socket each time.

Thanks everyone!

Chad

Glad to hear it was helpful!