6502 + ARM micro controller = I don't understand clock cycle

[tactif-cie]

I tried several scenarios, the last one in pseudo code is

Code: Select all

set DATABUS in input mode // 6502 drives the bus
if flag
 set PHI2 HI
 get RW
 get ADDR
else
 if RW == READ
   set DATABUS in output mode // Micro controller drives the bus
   write DATABUS with value from ADDR   
 else
   read DATABUS and store in ADDR
 end
 set PHI2 LO
end
flag = !flag

So when I set PHI2 to LO, the DATABUS have the right value

This code is called by a timer interrupt

[BigEd]

Ah, looks like there's next to no gap between setting up the value on the databus and then dropping phi2.

I'd be inclined to check RW in your first section, where you set phi2 high, and therefore are half-way through the cycle. If RW is low, start driving the databus with the right value.

[tactif-cie]

That's what I tried before and got no result

Like in

Code: Select all

set DATABUS in input mode // 6502 drives the bus
if flag
 set PHI2 HI
 get RW
 get ADDR
 if RW == READ
   set DATABUS in output mode // Micro controller drives the bus
   write DATABUS with value from ADDR   
 else
   read DATABUS and store in ADDR
 end
else
 set PHI2 LO
end
flag = !flag

In this scenario I write ASAP to the databus, so might be ok, BUT I think I read too soon from the DATABUS

So I tried my last idea, writing soon and reading late

Code: Select all

set DATABUS in input mode // 6502 drives the bus
if flag
 set PHI2 HI
 get RW
 get ADDR
 if RW == READ
   set DATABUS in output mode // Micro controller drives the bus
   write DATABUS with value from ADDR   
 end
else
 set PHI2 LO
 if RW == WRITE
   read DATABUS and store in ADDR
 end
end
flag = !flag

When executing "set PHI2 LO" the previous HI cycle should left a value on the DATABUS for what I understand from the specs

But still no result...
Could be a mistake in the real code, with the micro-controller input output ports direct access.

But do you think that the last pseudo code is ok ?

[BigEd]

Somewhere you need to set the DB back to input mode...

[GARTHWILSON]

How do your timings compare to what's in the data sheet?

[tactif-cie]

BigEd wrote:

Somewhere you need to set the DB back to input mode...

I do, setting the DB in input mode is the first line of my ISR routine

GARTHWILSON wrote:

How do your timings compare to what's in the data sheet?

Unfortunately I don't know. The Teensy 3.6 is a fast micro controller and I have no solution to know how to achieve nano seconds delays.
I asked on the Teensy forums, how many NOPs could achieve, let say, 10ns wait but the only answer I got was "You need to check with a good oscilloscope", which is a tool I don't own.

But, I've found many many articles on the web about interfacing an Arduino or even a Teensy with 6505,65C05,6509 - And they achieved good results without being tight on timings at all, and sometimes very basic code.

My best guess is that I'm doing something wrong.

But just to know : are there a lot of counterfait or broken 6502 on the market ? I bought the 6502 and G65SC02 from the same reseller, a quite old electronic shop (a real one) around 7/9 €
What are the chances to have a deffective cpu ?

[BigEd]

tactif-cie wrote:

BigEd wrote:

Somewhere you need to set the DB back to input mode...

I do, setting the DB in input mode is the first line of my ISR routine

Ah yes, so you do. But you're doing it before setting Phi2 low. So, you stop driving the databus just before the clock edge which the 6502 uses to sample the bus. This might be fine, but I would suggest you move this statement to after the one which drops Phi2.

It is possible to bit-bang a 6502 bus, especially if you're controlling the clock, but you may need to draw a diagram to see what the ordering of events will be in and after a read cycle and a write cycle. You are timing everything off the clock edges, but you have a chance to do things just before or just after those edges. That might be enough. Or it might be that some tens of nanoseconds of delay will be needed: you can figure that a NOP is 1 clock cycle, I think. Or 2.

What really helped us with the PiTubeDirect case was setting up a tell-tale I/O signal and using a scope to inspect the clock and the tell-tale, to see how much delay is happening from the bit-banging code.

[drogon]

tactif-cie wrote:

But just to know : are there a lot of counterfait or broken 6502 on the market ? I bought the 6502 and G65SC02 from the same reseller, a quite old electronic shop (a real one) around 7/9 €
What are the chances to have a deffective cpu ?

There are a few but when you can get brand new ones directly from e.g. mouser then there's no need to use ebay, etc. at all..

-Gordon

[Chromatix]

I think chips labelled as NMOS or CMD CMOS parts are likely to be legit. Most of the counterfeits out of China seem to be marked as Rockwell or WDC. The CMD chips will probably be a bit slower, hungrier and more finicky than a modern WDC part, but less so than an NMOS part.

[tactif-cie]

BigEd wrote:

Ah yes, so you do. But you're doing it before setting Phi2 low. So, you stop driving the databus just before the clock edge which the 6502 uses to sample the bus. This might be fine, but I would suggest you move this statement to after the one which drops Phi2.

Oh yeah, I see what to mean ! I'll give it a try, if I still can't make it running then the problem is somewhere else, timing or databus management


@Gordon & Chromatix

So, 99% chances that this cpu is ok - Good to know

[hoglet]

Would you mind posting your actual code, rather than just pseudo code?

There is I think something going on here that's not apparant from the pseudo code.

Dave

[AdaL]

Strangely enough, I have seen this weird sequence of reads to $FFFE-FFFF, with some $0000 and $017F randomly appearing, on my very first attempt at moving a breadboard design to perfboard. After days of messing with it and not getting it to properly reset, I concluded the 6502 must have been damaged during soldering, pulled it from the board, put it back into a test rig -- only to see it reset perfectly. I think it may come from an electrical problem, maybe a short somewhere (though I measured no spurious continuity between pins), a brownout from the power supply or a signal path so bad that it distorted the clock beyond any recognition. I don't have an oscilloscope to check anyway.

The CPU was a modern WDC 65c02 from Mouser. Unfortunately I still have no idea what this problem came from. But hey, that's two of us, which makes it a known and documented failure mode, right?

[CaptainCulry]

I agree with BigEd. Your problem is likely in the timing or order of events when you are trying to put the data on the bus for the 6502 to read. If you are using a WDC W65C02, you can even slow your clock down more to loosen up your timings a bit, throw a handful of nops in your routine to make sure you leave your data on the bus for long enough for the cpu to see it, or at the time the cpu is looking for it, and perhaps stretch things out for your cheap logic analyzer to be able to spy on the timings to see what's going on. I think you said you had a cheap LA up earlier in the thread. If you're not using the WDC part, its not fully static and there's a limit to how slow you can run the clock.

[GARTHWILSON]

AdaL wrote:

I concluded the 6502 must have been damaged during soldering, pulled it from the board, put it back into a test rig -- only to see it reset perfectly.

The chance of damaging the IC with soldering-iron heat is just about zero. In a job I worked in 1984-85, I sometimes used an infrared microscope to thermal scan power transistors' uncovered dice (ie, the actual chips) operating under extreme loads, and I've seen them actually operating (not just in storage or in soldering, but operating) at over 350°C. I don't know how far over, because I wasn't allowed to get calibration data any higher. Granted, they would not have lasted long, but it did not cause catastrophic failure.

[Dr Jefyll]

AdaL wrote:

I still have no idea what this problem came from. But hey, that's two of us, which makes it a known and documented failure mode, right?

Welcome AdaL There are folks here who'll be happy to assist with your project.

Please don't assume your problem is the same as tactif-cie's. Possibly it is, but certainly that's a very tenuous assumption, and it could easily result in disappointment and wasted time.

Experience has shown it's best to begin by presenting as much info as possible, preferably including a more detailed history and photos and a schematic. Once this is provided we can begin to make progress.

Cheers,
Jeff