AIM-65 homebuilt semi-replica

[Marta]

What a silence... Have even Yours ideas on how to continue dried up? Game Over? No, absolutely not. This thing just have to be made working, even if it will need some programmable logic for a clock sequencer, but I'm not there yet.

The ordinary way of doing it has worked for so many, so let's find out what is wrong here! Any comments to the schematic or the fact that the low indirect address byte is completely disregarded by the CPU?

I have now replaced the plain source of the test routine in the earlier posting with an assembly listing.

[BigEd]

Thanks for the listing - hopefully that will help:
viewtopic.php?p=79905#p79905

[Marta]

Does the 65816 drive the data bus during phi2 high when in reset mode? I have tried to find something about this in the data sheet, but found nothing. I did beleive it was in tristate during that period during reset, but CPU and HC245 runs warm if left in reset.

Maybe the BE and /RESET should be connected together and a pull-up on R/W to preserve RAM during reset? The clock is running all time.

The JSR (ABS,X) problem still remains stuck where it was.

[BigEd]

I would not expect reset to stop driving the bus, so if that's important to you, yes you might need a bit of glue.

I have no idea what might be going on with the JMP (ABS,X) but the likelihood is that it's not the instruction as such, it that this instruction (and maybe others) exposes some marginality in the design: perhaps timing, perhaps noise.

[Marta]

The reset problem is a minor issue.

More important, there has been progress with the JSR. The apparent random low address is fetched from the intended 16-bit address, but from bank1...

That means the address latch captures a wrong level. It must happen when Phi2 goes from low to high. The Phi2 is buffered and I has already tried to take the latch signal before the buffer. No change except the bank address starts with a glitch. The latch was using it's own inverter during that test, making the latch a HC245 delay earlier relative both MPU and buffer.

Sh*t my disabilities prevents me from setting it up for a check with the scope. I almost lost balance and felt last time and don't want to take that risk again. That would have tell how the timing is and give a hint of what needs to be done. It would also reveal the highly unlikely case that the MPU is erraneously outputting a solid bank one address...

The whole thing feels magic. If bank address capture was marginal, it should have prevented it from running for days without locking up. The JMP (ABS,X) works flawlessly. According to data sheet, event sequence are the same, except for the stack writes that takes place two cyckles before the critical one.

Just this part of the design is made as the data sheet describes. Is WDC giving crap advices?

[BigEd]

> there has been progress with the JSR. The apparent random low address is fetched from the intended 16-bit address, but from bank1...

Progress indeed! Much better to have some kind of explanation. It seems you've built a design which very nearly works. But I think it's believable that a timing marginality or a noise problem could show up only in very specific circumstances.

You had an earlier problem and fix:
> found the reason, the wire was not soldered to the cards power plane
Is it possible there are any more construction problems hiding?

Thanks for your schematic posted here
viewtopic.php?p=79908#p79908
Is it possible that you have implemented something very slightly different? It might be worth double-checking.

The glitch on the falling edge of an address line in your trace here
viewtopic.php?p=79910#p79910
is somewhat worrying. Presumably many address lines are changing all at the same time, and we're seeing cross-coupling effects or possibly ground noise effects.

[Dr Jefyll]

BigEd wrote:

Thanks for your schematic posted here
viewtopic.php?p=79908#p79908

For what it's worth, I edited that diagram to improve its clarity (at least I find it more clear now).

-- Jeff

[BigEd]

It might be worth a look at this (current) topic where it's pointed out that gate delays can cause glitches. So, it's not just a question of whether the logic is logically correct: it can be a bit more than that.

• 65C816 board glue logic issues?

[Marta]

Thanks for the link.

I see that like there are concensus in the group that WDC's adviced circuit can be regarded as crap?

In the actual case it's a read cycle that fails. That means the MPU goes to hi-z after bank address. Then it must be the 245 that causes the latch to capture a bad value. But as mentioned before, it has been tested with a latch enable one 245 delay earlier with no result.

Next action will be to measure what is going on. I will rearange my crap ^H..^H devices so the scope can be left on the table. Would take a healthy person 20min, with my disabilities one or two days. Until then I make no changes. There will be some space on the card for one or two more sockets. That's the big advantage with wire wrap.

I also needs other scope probes. Noticed there was large variatins in the ringings whith my only hand holding around the connector. Chanses are the severe ringings are false and just the result of a broken probe.

Here are new schematics of the actual part of the design. More will come later with the ports and video.
Also an image of the card. Hope it's not too large. The wire wrap card hac copper on both sides. Bottom side is GND an top +5V.

[BigEd]

Thanks for the update. I think we can agree that WDC's documentations offer some guidance, rather than everything we might like.

It will be interesting to see what you see once you've got your workspace rejigged.

[GARTHWILSON]

This topic should help: "Managing the 65816 multiplexed bus." Several pages into it, I propose a possible solution at viewtopic.php?p=35113#p35113 .

[BigEd]

Thanks Garth. A couple more signposts over here.

[Marta]

Here comes the scope picture. An interrupt timer is running producing a 1kHz IRQ that does the JSR (ABS,X) into an area filled with $1A, that is the INC A instruction. The monitored signal is pin33, D0. 1µs/5V each square.

As can be clearly seen, there are two back to back cycles with a steady 1 level. This is impossible when executing that instruction from bank 0. My interpretation is that the CPU misbehaves.

I'm very surprised with the result. The only off-chip reasons I can think of is that it wants more dv/dt on PHI2. or an excessively noisy +5V. The power seems perfectly smooth on the scope and other people here does not seems to had problems with rise time, so what is going on???

Any comments, please?

[Dr Jefyll]

Marta wrote:

there are two back to back cycles with a steady 1 level. This is impossible when executing that instruction from bank 0.

Probably those two cycles are fetching data (rather than fetching instructions to execute). If instructions were being fetched then very probably you'd have more than just two bytes.

[Marta]

The picture shows the last activity before a very long 0 level. It's taken with delayed time base and I'm very convinced it shows just the JSR (ABS,X). When I get one more working probe I will repeat the test with a marker by addressing one of the unused I/O-addresses in the instruction before. With that on the other channel there will be no doubts left.
Another MPU is also on order. Will be interesting to try that.

I belive it's the discarded cycle when adding the index internally, followed by reading the low address byte from the jump table, that goes into bank 1. There are no intentional addressing of that bank in the code, so in any case the first 500ns of each cycle have to be 0. All code is bank 0 and I/O is bank 8.

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