AIM-65 homebuilt semi-replica

[Dr Jefyll]

Marta wrote:

Assuming the measurment shows a JSR (ABS,X) executed in bank 0, what is Your conclusion?

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

[Dr Jefyll]

Dr Jefyll wrote:

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

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!

[Marta]

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.

Code: Select all

00173 0b100  24 45      indadr  .da $4524

00237 0b33a  af 04 40 08irq     lda via2.t1cl           clear irq flag
00238 0b33e  a2 ff              ldx #$ff                restore stack
00239 0b340  9a                 txs
00240 0b341  58                 cli                     allow irq's
00241 0b342  a9 00              lda #00                 initial conditions
00242 0b344  a2 66              ldx #102
00243 0b346  8f 00 80 08        sta $88000              marker
00244 0b34a  fc 9a b0           jsr (indadr-102,x)      here we go...


1 PBR,PC          OpCode
2 PBR,PC+1        AAL
3 0,S             PCH
4 0,S-1           PCL
5 PBR,PC+2        AAH
6 PBR,PC+2        IO
7 PBR,AA+X        New PCL
8 PBR,AA+X+1      New PCH

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.

[BigEd]

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.

[Dr Jefyll]

BigEd wrote:

Usually "faulty cpu" is one of the last hypotheses, especially when it's 99% working, but this is odd enough to consider it.

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

[Marta]

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

[BigEd]

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

Quote:

Here's a trace fragment from SPHERE running on Basic816:

0 fc O 1 ?
1 e7 P 1 ?
2 51 D 0 ?
3 57 D 0 ?
4 50 P 1 ?
5 f8 I 1 ?
6 52 P 1 ?
7 52 P 1 ?
memory write: 0001e0 = 51
memory write: 0001df = 57
F85155 : FC E7 50 : JSR (50E7,X) : 8 : A=F2F2 X=0012 Y=00FF SP=01DE N=1 V=0 M=1 X=1 D=0 I=0 Z=0 C=0 E=0 PB=F8 DB=F8 DP=1A00

0 18 O 1 ?
1 f8 I 1 ?
F85252 : 18 : CLC : 2 : A=F2F2 X=0012 Y=00FF SP=01DE N=1 V=0 M=1 X=1 D=0 I=0 Z=0 C=0 E=0 PB=F8 DB=F8 DP=1A00

0 08 O 1 ?
1 f8 I 1 ?
2 b0 D 0 ?
memory write: 0001de = b0
F85253 : 08 : PHP : 3 : A=F2F2 X=0012 Y=00FF SP=01DD N=1 V=0 M=1 X=1 D=0 I=0 Z=0 C=0 E=0 PB=F8 DB=F8 DP=1A00

The order of the cycles is a bit unexpected, but matches the data sheet.

It certainly doesn't jump off into the weeds.

[BigEd]

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

[BigDumbDinosaur]

Marta wrote:

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

WDC hasn't shipped any microprocessors with Sanyo wafers since 2006—2004 is when the switch from Sanyo to TSMC began. Anything you may be getting from Mouser's stock should have a TSMC die in 0.6µ geometry, designated by 6T in the part number. There should be no functional difference between 0.6µ dies produced by either of the foundries.

That said, at the clock speeds you are running it won't matter if your 816 has a 0.6µ or 0.8µ die. The 0.8µ die will run fine at 14 MHz—I have successfully booted POC V1.2 on an 0.8µ 816 at 15 MHz (V1.2 runs at 20 MHz with a 0.6µ 816).

Quote:

Maybe a silly question, but has You or any other of You tried the JSR (ABS,X)?

I have used JSR (<addr>,X) without any problem.

[BigEd]

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

[Marta]

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

[BigDumbDinosaur]

BigEd wrote:

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

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.

Marta wrote:

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

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.

[BigEd]

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

[BigDumbDinosaur]

BigEd wrote:

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.

This seems to be an excellent example where a NOP generator would be useful. The one mod that would need to be made to Lee's design to work with the 65C816 would be the use of Schottky diodes to avoid contention during Ø2 low when the MPU emits the bank bits.

[Marta]

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.