Acolyte 6502 Schematic Video

[sburrow]

Dr Jefyll wrote:

Oh, the data bus. Sorry -- my suggestion about the 590's made no sense (because they drive the address bus).

Still, I think you have the skills to sort this out. Contention means there's more than one device driving the bus in question. So, in context of the data bus, ask yourself, what are the prospective suspects? CPU, obviously. RAM. ROM. I/O. And maybe other stuff, if there's a wiring error.

One possible approach is to use your 'scope. See which devices are enabled when this 2.5V level is observed.

-- Jeff

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.

plasmo wrote:

Chad,
One good way to debug your circuit is to explain it to another person who presumably don't know anything about it. It forces you to take a few steps back and explain your assumptions (why you think these assumptions are correct?) and other parts of logic (surely these logic have nothing to do with current problem, or do they?) and force you to explain the logic in simpler, possibly different terms (tiresome task of sketching out the details that are already proven, or are they?). I've sat in design reviews said absolutely nothing but watched the designers solved their own problems because they were forced to go back explaining the assumption and details they thought are already proven and working. A "second pair of eyes" sometimes mean a different way for YOU to look at the problem.

So start from the beginning; post your latest schematic, circuit board design, pictures of your assembled board, and explain the problems you are seeing.
Bill

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

[BigDumbDinosaur]

sburrow wrote:

...the board's logic cannot be drastically altered...

Who says? You’d be amazed at how you can alter the logic using flush cutters, “blue” wire (I don’t actually know if it is blue, that’s what I’ve heard) and a small-tipped soldering iron. In POC V1.0, I tripped over a significant logic error that was giving me grief with trying to read/write the DUART. I ended up using those aforementioned three items to change the I/O decoding logic, which fixed the problem. My fix was kind of ugly, but electrons don’t know they’re going through bodge wire.

plasmo wrote:

One good way to debug your circuit is to explain it to another person who presumably don't know anything about it.

Exactly what I would recommend. You probably need to spend more time on the cerebral aspect of designing computer hardware, and not be too quick to slap parts together hoping for positive results.

[kernelthread]

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.

[sburrow]

kernelthread wrote:

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?

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.

Quote:

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.

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*

Quote:

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.

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

[sburrow]

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

[kernelthread]

\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.

[sburrow]

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

[BigEd]

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

[plasmo]

sburrow wrote:

It works, it works!!!

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

[kernelthread]

sburrow wrote:

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.

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?

[sburrow]

Quote:

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