Neon6502 - Compact Replica of Acolyte

[sburrow]

No no, PHI1-out and PHI2-out have stopped, but PHI2-in (or as Ive been calling it, PHI0) has not stopped. I thought it must have issued a STP command, however that would stop address lines from changing which is not happening. The thing is still humming along, but after reset PHI1-out and PHI2-out have stopped.

I believe Im not reaching code because of PHI1-out is tied to addressing logic. If that doesnt change, but PHI0 is changing, Im definitely going to have logical inconsistancies.

Of course I could try to bodge in a dead-bug inverting logic gate or something, but I would also have to cut some traces and Im just not ready for that yet. Sure, using PHI1 is weird, sure it isnt *promised* to work, but as also stated there would be no reason the die would have been changed in the past 2 years, and it DOES work, but only in reset. So what gives?

Thank you.

Chad

[gfoot]

I was going to suggest bodging in some inverters too. You could bend the 65C02's PHI1out and PHI2out pins so they don't fit in the socket, perhaps, rather than cutting traces. (Edit - ah I see it's not socketed, ignore that then!)

Did you verify that PHI1out and PHI2out are really not cycling? I wondered about STP as well but don't know whether it affects these outputs or whether it just prevents the clock from reaching the rest of the chip.

Trying to think of things that would be different after the reset, I wondered whether you have some bus contention that's leading to a virtual short circuit. Maybe check the 65C02's VCC level after the reset.

The other thing I wondered was whether somehow PHI1out and PHI2out are themselves running into contention with something else; maybe through a bridged solder joint for example.

[leepivonka]

Are all of the VDD & VSS pins on the 6502 connected?
Is RDY confirmed always hi?
Is SYNC running?

[barnacle]

I may have missed: did you change the 65c02 for a known-good part? Or at least, a different part?

Neil

[BigDumbDinosaur]

sburrow wrote:

No no, PHI1-out and PHI2-out have stopped, but PHI2-in (or as Ive been calling it, PHI0) has not stopped...

Hitting an inadvertent WAI (opcode $CB) in your code perchance?  I actually don’t know if the two output clocks are affected by WAI, so my suggestion qualifies as a WAG.

[sburrow]

gfoot wrote:

Maybe check the 65C02's VCC level after the reset.

After reset the VCC level dips a tiny tiny bit. I think that would be expected since it would be 'running' then, right?

gfoot wrote:

Trying to think of things that would be different after the reset

I'll be thinking more, thank you George.

leepivonka wrote:

Are all of the VDD & VSS pins on the 6502 connected?
Is RDY confirmed always hi?
Is SYNC running?

1) On my PCB, yes, and when I inspect the soldering, yes it appears so.
2) Yes, I have it pulled high.
3) After reset it does run for a bit of time, then it stops running.

I saw that I had included a pull-up resistor on SYNC for some odd reason, so I removed that, but no changes. Good ideas though!

barnacle wrote:

did you change the 65c02 for a known-good part?

I got it from Mouser, so it should be new and working

BigDumbDinosaur wrote:

Hitting an inadvertent WAI (opcode $CB) in your code perchance?

It could hit all kinds of opcodes. There is currently bus contention on the data line because PHI1 shuts down. I look at the data line and there's definitely issues there right now. However, that is only after PHI1 shuts down.

Because SYNC shuts down, perhaps it could still be a STP command somehow? I'm at a loss. But I'd rather know than just say "oh well the PHI1 just shouldn't be used!" No, there should be some reason for all of this.

Thank you everyone.

Chad

[sburrow]

Did a little bit more testing with the scope.

1) When SYNC stops operating, so does PHI1-out and PHI2-out.

2) Upon reset, VP works as expect. SYNC, PHI1-out, and PHI2-out work for some time afterwards, but eventually stop.

3) Using VP, I find that it is indeed grabbing the reset vector at $8000 as expected. Or, at least it's trying.

4) When SYNC shuts down the RDY pin is still high. However it takes just the tiniest little dip when SYNC shuts down. No way that it's logically affecting something though. Just an observation.

5) The amount of time it takes for SYNC and PHI1 to shut down changes between each reset. I believe it's hitting random 'code' in RAM.

6) IRQ and NMI do not affect this at all. I am triggering them at regular intervals and there no effect from them, nor do I see PHI1 change when an interrupt occurs.

How could SYNC suddenly stop? How could PHI1 suddenly stop?

Chad

EDIT:

More testing. I rewrote my code to basically hit a STP command almost immediately. And sure enough SYNC and PHI1 shut down consistently almost immediately. It appears that STP is indeed the reason why things are not working. My original code did not have a STP command, so why did it trigger? Somehow there must be databus contention of some kind. Will keep testing. Thank you!

[Dr Jefyll]

sburrow wrote:

I rewrote my code to basically hit a STP command almost immediately.

Good idea!

Quote:

there must be databus contention of some kind.

Perhaps more apt to say "there must be invalid data of some kind." Contention is one possibility, but it could also -- just one example -- be an unencumbered fetch but from the wrong address in the memory IC.

You said the amount of time it takes for SYNC and PHI1 to shut down changes between each reset. When results aren't stable, I wonder about floating inputs. Just something to think about...

-- Jeff

[sburrow]

Dr Jefyll wrote:

I wonder about floating inputs.

It is a possibility I suppose. Propagation delays between BE and OE signals could lead to something like that. I have been noticing when BE goes high that it takes a goodly amount of time for the data to stabilize. I'd say around 25ns or so there is a dip momentarily in some of the data lines, but because that data is latched into the 6502 on the falling edge of PHI2-in it shouldn't make a difference. Thank you Jeff.

I have been looking and testing things all over. I'm telling you, my logic is all working at expected. The video side always seems alright (as long as PHI1 is running), but the 6502 side is what is messing up. It has enough that it can read off some reset vectors and reach a STP about 2 instructions in, so that's something. So it does "work" but it doesn't do it consistently. Even in an infinite loop in ROM it is constantly jumping to RAM for some reason [ that is, the 6502 does, the video is always jumping to RAM ].

I did some experiments without bodges and powered the whole thing from around 3.7V from a spare LiPo battery I had. I don't know what exactly is happening there, but PHI1 continues to run the entire time. With this code I didn't issue a STP command, but I can't see any activity from the 6502 at all. Even a basic "write $00 to video RAM" isn't working. I know writes to RAM work because when the code goes haywire it's definitely visible when it is changing video RAM. So, I figured with lower voltage I could slow things down. But it's like the 6502 gave up now?

My biggest guess right now about the whole thing is that when PHI2 falls the data changes and the 6502 doesn't latch the correct opcode/operands. One stray bit and it dashes off into loopy-land or something. All video circuit timings and latches are right on.

Thank you everyone.

Chad

[AndrewP]

Neither really here nor there but the datasheet for the '816 says 25ns for BE to valid Data. And that matches exactly what you're seeing so it could be legit. The fly in the ointment is I measured this years ago and it was much, much faster. Like 3ns or something. (hopefully someone can be more precise than me and mention which line/bus they were probing). I also have a vague memory that BE doesn't affect data reads; again hopefully someone with real experience can comment on this.

sburrow wrote:

My biggest guess right now about the whole thing is that when PHI2 falls the data changes and the 6502 doesn't latch the correct opcode/operands.

Not much to say here either other than that I found the '816 latched what was on the data bus very fast after PHI2 fell. I didn't need to hold it for the 10ns tDHW from the datasheet.

If you can: scope your data lines and see if something is pulling them to odd levels. But even so STP (11011011) is a bit of a weird instruction to just randomly be there. Maybe check your power line too, it could be noisy. I dunno, this is proper strange.

[sburrow]

AndrewP wrote:

Like 3ns or something.

Correct. Every time I've done this with BE, it was almost instantaneous. That's why it's weird to see the data lines do a little spike 25ns after BE rises.

AndrewP wrote:

I didn't need to hold it for the 10ns tDHW from the datasheet.

Correct again. My last builds that used this system had no delays for holding data. Logically this is identical to my previous Acolyte boards which worked great.

Reasons why I think something is up with my W65C02:

1) The 25ns delay after BE rises. There is nothing else logic-wise going on at that exact time.
2) The (supposed) failure to latch in time. Because the ROM is switching addresses when PHI2 goes low, could a 70ns ROM chip be faster than the 6502?
3) Using 3.7V makes the clocks function but the 6502 itself doesn't seem to do anything.

Weird theory: As previously suggested, what if one of my VCC or GND lines isn't properly connected for some reason? A decrease in overall voltage might put the 6502 into a weird sleep mode essentially, and the reason it's acting so slow is because it thinks it's supposed to run at lower voltage? Really, it doesn't make sense, but nothing else is making sense so... ? I'm at work now, but I intend on triple checking those things when I get home. Any other suggestions are welcome! Thank you.

Chad

[sburrow]

Small updates:

I found no disconnections between VCC or GND pins on the 6502. Everything seems fine. I checked for resistance between pads and voltage levels when running, everything checks out.

The reason why the video runs at 3.7V without issue, and the 6502 seems to do nothing, is because of my MCP-130 which won't let the 6502 out of reset. Because it is held in reset, it lets PHI1 run as usual because it has not yet hit a STP command. So that solves that mystery.

EDIT: I also stopped all interrupts from triggering, and nothing has changed.

I'm not ready to bodge things yet, I still feel like something else is going on. Heck, I don't even know what I would bodge! It feels like the timing is off somehow, but I cannot see where.

Fun thought: If I would have started with Arduino's or PIC's or any other microcontroller, I would have not had to go through this sort of thing for over a year or two. This sort of thing is what makes the 6502 both challenging but rewarding. If this were happening in microcontroller-land, I would just change my C code accordingly, the end. THIS, however, is a challenge!

[ And my interest is quickly waning nevertheless... ]

Crazy question: Could I have a dud / canary 6502? A long while ago I had a 74HC161 that was acting up, and when I replaced it my video circuit worked. Jeff had suggested I keep the chip because it was marginal, a 'canary' to tell me if my timing was marginal or not. Could I have a similar SMT W65C02 by chance? And I just 'got lucky' with my DIP-40's a long while ago?

Thank you everyone!

Chad

[sburrow]

"It freakin' works!" - Adrian Black

Please excuse my workplace mess... as I display some Mandelbrot! [ See attached. ]

First, a short story: I was sitting at the desk, staring at the schematics, back to the other desk, probing whatever I could with the 'scope, all in futility. My daughter came into the room, and I said, "Hey, this board isn't working, what is wrong with it?" holding it up for her to see. She looked at it and said, "I think it's a connection problem." I looked at one of those chips I had to bend the pins to make fit the footprint, and it *looked* fine to me. Hm. I had to leave to go to Wed night church. I came home, turned on the soldering iron, and after 5 minutes of reglobbing that beautiful tin/lead mixture all over the place, BOOM, it now works! I brought my daughter in to see it, told her that she helped me, and asked her what she wanted as a reward for helping me fix it. Without hesitation, she said, "I want a Switch 2!" Uh oh!

Yep, so that 'dip' in the data lines was an improper soldering job on improperly fitting chips on an improperly sized footprint with improperly small pads. Go figure.

I swear, the next time things just don't make sense, its because of something like this. Mark my words!!!

One issue: The picture is just dirty. It's not flickering, but it has major streaks and discoloring. I wanted light blue and orange, but I got dark blue and red. Not sure if that's a resistor issue, a power issue, or a 74HC166 issue, or what. [ Probably a solder issue!!! ] I'll have to play with it a bit.

So this is a bodge-less design! That's neat I DO want to bodge one tiny thing for the buttons, but it is purely aesthetics, not required.

Thanks for putting up with me everyone. That was one trippy few days. Next up is a 3D printed case and then Tetris!

Chad

[barnacle]

Check the resistor through which you are routing the green signal. Too much red instead of orange/yellow and too much blue instead of cyan/light blue is not enough green (assuming you have an RGB signal at some stage).

Neil

[gfoot]

I'm glad it's working now - subtle connection issues can be hard to diagnose!

For the resistors, I presume you have one channel connected to R through a 510ohm resistor, another connected to B through a 510ohm resistor, and both channels connected to G through 1k resistors? The white levels do look good though. Bear in mind that the signal is 50-ohm terminated at the receiving end, so the output voltage will be 5V * 50 / (510+50) which is only 0.44V. The peak level ought to be more like 0.7V, as far as I know. Around 350ohms would probably be better for R and B, and 2x700ohms for G.

However the horizontal banding makes me think that the levels aren't consistently black during the blanking period. Is it possible your "visible" signal is unstable? I'd look closely at that, and the output signal levels during blanking (especially the green signal).