6502.org

Based on the scope photo, I'm not sure which cyle is which. I would need to know, where does the instruction begin? (Which cycle is the opcode fetch?) Maybe we should wait until you can post a photo that also shows a second trace to act as a timing reference. EDIT: many scopes have a Z-Axis (intensity) input which can be very useful -- almost like having a three channel scope.

Speaking more generally, troubleshooting can take two possible approaches. Both can be useful, and you may even wish to alternate.

One way is speculative. For example, you could try replacing the 'hct245 with 'ahct245, or try rerouting the clock signal for less propagation delay. I'm not saying you should -- I'm just inventing examples where you're acting on Best Practices and maybe a hunch -- not on specific evidence.

The other way is analytical, where you first try to observe the problem in detail... then later ask "why" you're seeing what you're seeing (so you can fix the problem).

Your scope traces are analytical, of course.

For these and for ALL your tests I encourage you to simplify as much as possible. I can't teach you this -- it's a philosophy! -- but here's an example. For a scope trigger, you mentioned addressing one of the unused I/O-addresses in the instruction before. Instead, can't you trigger from the 816's /Vector Pull pin? Another option, usable in some circumstances, is to trigger from VDA or VPA, or from an address line which you know will toggle as a test loop executes.

Speaking of loops, this one is a simple as it gets -- just one instruction! In a previous post I explained how to use pullup and pulldown resistors to ensure your machine executes an endless series of JSR(abs,X).

-- Jeff

Another test would be to use resistors to put $AF on the bus. This'll cause the machine to endlessly execute LDA using Absolute Long address mode (opcode $AF). And the effective address will be $AFAFAF, which of course is not in Bank 0.

You'll end up with a repeating, 5-cycle sequence, and one of those cycles will access Bank $AF. This should give you a good opportunity to examine the bank-switch on the scope!

Here we go again, this time with new chinese scope probes and a marker on the other channel to incontrovertible identify the machine cycles. The marker is an unused output of the IO address decoder. The signal shown is bank/data 0. As can be clearly seen, the op, stack and jump table location accesses bank0. Then the internal op cycle and the following read of the low indirect address goes to bank1, the high indirect is read from bank0. The internal should be PBR and the two indirect parts just MUST be from the same bank.

This MCU does something completely wrong. Almost unbeliveable, but that is what happens. Any explanation?
The supply is perfectly smooth and within tolerances. The only questionable signal is dv/dt at PHI2, but it works for anybody else with just an ordinary driver. I have also tested with a separate 245 output just driving the MCU input with no result.

It feels uneasy not to know what is going on and I'm too curious to just PEA @+5, JMP (ABS,X) and be happy with that.

Great traces! Still very unexpected, to me. Have you got another '816 to swap in? Usually "faulty cpu" is one of the last hypotheses, especially when it's 99% working, but this is odd enough to consider it. Unless someone else has an epiphany.

There was good reason to be cautious about the conclusion it's 99% working. For example, newly build hardware can have errors; also, there's an issue with tests such as the one that relied on a software post mortem to try to determine where the faulty JSR landed (because of the possibility the post mortem itself isn't behaving properly).

But this hardware-based test is quite simple and specific -- a real eye opener! As Ed says, Have you got another '816 to swap in?

( In case anyone's interested, here's a bit more detail, taken from the November 09, 2018 edition of the W65C816S datasheet. I've highlighted the cyles with the unexpected Bank address. )

-- Jeff

If I had another MPU on hand, it would of cource already had been tried. I have two on order since a week or so from Mouser. Hopefully I get them before the big holidays that are coming up now. They will almost for sure also be made at the Sanyo plant. If those too fails in the same way, I will order a couple of QFP made at TSMC and adaper boards for them. But that will take some time and some cost...

There are of cource no guarantees all other instructions are working, but so far so good. No strange lockups at all. Validating everything in all modes and from different banks is too big for me and things may still be marginal.

Maybe a silly question, but has You or any other of You tried the JSR (ABS,X)? I can think it's used quite seldom and if magic effects shows up then a workaround is very easy. The PEA/JMP f.ex. imposes very little penalty and the problem will be gone. Hopefully...

> any other of You tried the JSR (ABS,X)?

Dave/hoglet was kind enough to find one in a trace of BBC Basic (816 version) which has recently been ported from Acorn's Communicator: it seems to be a regular part of the interpreter, and it works fine. This will be running on a relatively recent WDC '816, I think.

Oops, hang on: that's in native mode. And I think you said you are in emulation mode?

(Do you happen to have used this instruction in emulation mode, BDD? It's just possible that that's the crucial thing.)

As can be seen on my first test to find out where the JSR "landed", that was done in native mode with wide A and short indexes. The problem was still present.

The actual bank settings may have an effect. My program is running from bank0 with all new registers left in reset conditions. As my hardware happens to be built, testing from bank $F8 is impossible. BA 4 to 7 are don't care, but BA 3 is I/O select. The address decoder is wired with VDA and VPA to only accept data R/W, so running code in PGRAM is not possible. This was needed to minimize glitches from disturbing the video display.

My MPU is ink marked with "W65C816S8P-14", "SA9906A". It was bought directly from WDC around 2003.

According to a text found in the thread about fake chips, all 816 DIL's up to right now are Sanyo. I first tried to order from Coltek, but they was out of stock with new ones coming in. Maybe those will be from TSMC.

"W65C816S6T - 2006 - PLCC and QFP devices are in production. PDIP parts are still W65C816S6PG-14 devices using Sanyo .6u wafers (Most of these parts in the wild have a date code of 1023, 0627 laser marked or 0435 ink marked). We just sent out some TSMC wafers for PDIP packaging so there will be some W65C816S6TPG-14 devices with date codes starting with "20"."

Actually I did. When POC V1.0 first came off the block it was running in emulation mode. The monitor was using JSR (<addr>,X) to "dispatch" the MPU depending on the function being used. I continued to run in emulation mode for about eight months. Had there been some sort of problem with JSR (<addr>,X) I'm sure I would have seen it at some point.


What you have is an MPU that was produced in February 1999 from a Sanyo 0.8µ wafer and packaged in PDIP40. If you can get one, you should try out your system with a 65C816S6 or 65C816S6T MPU (the most recent part number in PDIP is W65C816S6TPG-14). The smaller die geometry of the newer product confers some timing improvements that may benefit your machine.

Getting back to JSR (<addr>,X), I haven't fully followed this topic but I assume you do know that the vector for JSR (<addr>,X) must be in the same bank as the instruction using it. That is, if your JSR (<addr>,X) instruction is in bank $04 then <addr> must also be in bank $04. Also, the program counter will wrap around if the expression <addr>+X would cross bank boundaries.

Edit: Fix wording concerning end-of-bank behavior.

Thanks BDD. So we're seeing that several systems happily run this opcode. (Hoglet has done a further test today.)

As a general point, I think if an instruction were broken, many others would have discovered it, and there would be some kind of record of those discoveries and debates about what was going on.

So it feels like there's something unique here: either a uniquely defective part, or something in the system under test. Jeff's earlier suggestion to strip it down to a hard-wired single opcode with no other chips is a good one: you'd get a periodic situation which would be easy to analyse with the scope. (However, it would be in emulation mode.)

Testing with a hardwired $FC just takes 8 resistors, but I don't want to force those into the sockets and risk damage.

There will soon be another MPU available and that will be the next to try.