I could, but the board's logic cannot be drastically altered, it's not a breadboard or anything. If I do end up finding something I'll let y'all know. Thank you.



Thank you Bill, I appreciate the advice. I'll think it over, and I can certainly post a lengthy explanation of everything here. Still, to improve morale, I've already been working from a working board and just changing some of the 'features' on it to better suit what I'm used to at this point.

Will keep y'all updated. Thank you.

Chad

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

I had a look at your schematic and didn't see any obvious way to get contention on the data bus (I assume you're talking about the lines labelled D0-D7?).
So it's possible you have a short circult somewhere or the circuit as built doesn't match the schematic in some way.
Is it all data lines which have the contention issue or just one? How long does the 2.5V persist if you examine it with a scope?

I think there is another problem with the circuit though. If the processor performs a write to RAM, the \WE line to RAM is asserted one gate delay after PHI2 goes high. However the BE line is asserted one gate delay after \PHI2 goes low, which in turn will be a propagation delay (from PHI0 to PHI1 on the W65C02) after PHI2 goes high. Thus \WE is asserted before BE. If you look at the data sheet for the RAM chip, it requires the address to be stable before \WE is asserted (setup time given as 0). You probably need to delay the assertion of \WE to maybe the second half of the PHI2 high phase to ensure correct operation.

Another slight oddity is that the R/W line from the CPU is actually left floating when BE is low. I'm not sure if that's a problem - capacitance should retain the previous state, but if there is coupling from other signals then maybe it could cause issues.

Then JLCPCB messed something up. I think it's strange that I have had the same type of signal on two separate boards though. They were of similar design, so that part isn't strange to me.



THAT is good reasoning! Still, I don't think that would cause what I see happening. I would send a picture of the scope, but it's getting late now. On the previous board I had it qualifying the /WE signal to the second half of PHI2 high, but then again my BE logic was messed up on that board and I was getting similar results. *shrug*



Yes, I was told that it wouldn't matter, and I purposely make my logic to account for that as well.

To BDD, thank you and yes. I do plan on doing a summary statement here, pictures and stuff. I'm waiting on a few parts first though, I want to try to replace something and see if that helps. I have a couple of ideas, but in the end I am not very hopeful.

On the flip side:

I have altered my existing monitor and BASIC code for my previous board that actually works. And it runs smoothly on that board! I flashed a ROM chip and stuck it in, and it indeed runs well. I figured out a way to have vertical scrolling from write-only video RAM: Duplicate it somewhere else. I have a terribly wasteful subroutine handling it, but it does work at least.

Another thing I find puzzling is that my BASIC is terribly inefficient! My simulator must be running too fast, because I stuck it into my 3.14 MHz board (the one in question here is only 1.57 MHz), and it is SLOW. SLLOOOWWWW. I find that it's slowness is fitting to such a design!

Whelp, there's the update. When I get more parts in and do some tests and pictures, I'll let you know more. Thank you all very much, I appreciate the help and support.

Chad

Just spent 4 hours probing this thing. I believe I found the databus contention.

Attached is the picture of the '245. The /CE line is connected directly to /BE, which means that it is active as long as the processor is active on the address bus. Cool.

What is not cool is that the C databus from the RAM is sometimes floating during that time when ROM is enabled but RAM is disabled. So the '245 is forcing a floating value (whatever it feels at the time) onto the D databus when the ROM is also pushing data onto the D databus.

How I found this was that I removed everything besides 6502, ROM, and clock stuff and it worked fine. NOP test ran perfectly. I put the RAM back in, and it still worked, but when I put the '245 back in it was not working. I changed out the '245 with another one and same results. And I put all these chips back into my working board and it's fine. So:

- Chips are good.
- Logic seems messed up.

I tried to bodge-wire some logic to fix it, but I must have shorted some other signal because the whole thing ain't working now. And my back and eyes hurt and I've run out of patience.

I'm already starting to design the next board. I will make sure this transceiver problem won't happen again. There's the update. Thank you all.

Chad

\CE on the HC245 should only be low if BE is high and A15 is low, i.e. the CPU is accessing RAM. So you need some more gates - unfortunately it doesn't look like you've got any spares on the existing chips, so you'll need to add another chip to the board, probably bodged on 'dead bug' style.

It works, it works!!!

Attached are some pics. The board had locked up because my PHI2 was touching /PHI2 with my bodge wires. I thought 2.5V on that line was strange!

Anyways, the *main* change was that transceivers /CE now is only selected when PHI2 is high AND /ROM is high. That is, only when the RAM is being selected does the '245 send data through. I made other changes to the PHI2 and BE timing, but I doubt that really made a difference.

So, some things I have learned:

1) Put a through-hole testing area on the board, VERY easy to solder some additional chips on there, dead-bug style is way too hard for me.

2) Don't assume that a floating value is, well, anything you want it to be.

3) 1.57 MHz is too slow. If you see in the pics, the first letter is always cut off. The reason for this is because the ROM sync signals I use are just spread too thin, divided down too much. The VGA monitor is also complaining because it is saying it is 59 Hz, instead of the 60 Hz it should be. I've never had issues running the ROM sync signals at 3.14 MHz though.

Thank you VERY MUCH to Bill (plasmo) for the behind-the-scenes emails. He really pushed me to keep going and figure it out. And I am so happy that I listened to his advice. I hated every minute of it, but I learned so much and that was the most important thing. So, thank you Bill.

The next revision is already being designed. Still lots of double checking left to do, but *now* it is looking promising.

Thanks everyone, have a most wonderful day. I know I will!

Chad

Persistence pays off! Well done! And yes, great to hear about behind-the-scenes support.

Chad,
I have goose bumps hearing about your success! Most excellent work! Debugging is part of the design process; some of my best design ideas came out of lesson-learned from debugging sessions. I will also tell you debugging is the hardest skill to learn, whether it is hardware, software, or car repair.

I like this version of Acolyte very much; it has that feel of disciplined simplicity. I hope you’ll revisit it again.
Bill

Congrats on getting it working!
If you move the position of the horizontal sync pulse by 1 character (the period of your 1.57MHz clock is equal to 16 VGA pixel times, which is 1 character position in your set up, as far as I can see) would that not correct the missing character at the beginning of the line?
Also, the monitor complaining about wrong refresh rate seems a bit suspicious. Surely if your pixel clock is correct and your division ratios for horizontal and vertical timing (800 total pixels horizontal, of which 640 are visible; 525 total lines vertical, of which 480 are visible) the refresh rate should be as expected?

Thank you! Yes about shifting the character over. But that's yet another sign that it is not working properly.

I use a ROM for all of the video sync and reset signals. Obviously it's working, but because I'm dividing it down 16 times, the resets and all that are just barely off. The missing character demonstrates that indeed those values are just slightly off. I could try to adjust my ROM, that was my first guess, but I went back over it recently and found it... exactly as I figured would work.

None of this happens when running it at 3.14 MHz of course, so that's my next board's goal. Also, running it at 3.14 MHz allows for 80-column mode, which this board is simply incapable of doing.

Thank you again!

Chad