Haha - problem solved! That's always good.

That's a little bit prematurely to say...

The JSR (ABS,X) does not jump to the desired target. The error that occationally crashed the jump table (and other locations too) has been fixed, but still problems with that instruktion. JSR to a JMP (ABS,X) works perfectly...

As it's newly built hardware everything may happen, but it runs AIM BASIC and FORTH correctly as far as I can notice. A marginal timing can be extremely hard to find, so there might still be something bad lurking somewhere...

Any test sequence to recommend that causes maximum timing stresses? I definitely not not feel absolutely confident my homebuilt hardware is working flawlessly.

Some hardware are definitely out of order...

I have one more never used until now MCU. Installed that and it fails to even boot. It's not completely dead, it addresses the VIA used to communicate with the USB PIC, but fails to load and run the software correctly.

My conclusion is that I have either a marginal timin, marginal levels or a bad MCU. It would be nice to have the failing MCU tested somewhere else before starting to look for problems. The question is just how?... It's a lot of work to wirewrap another simple unit only for that.

It has been running for days without any signs of instability exept for the JMP (ABS,X) problem.

My MCU's are old ones marked SA9906A. With that marking made when WDC was using the Sanyo fab. They are bought directly from WDC a long time ago, so definitely not china crap.

It could be that your board has a timing problem, and these things can be quite tricky to find.

For the analytical approach, can you share your circuit diagram, with particular attention to the glue logic? Are you sure the power supply is clean, has a good level, is well decoupled at each chip and at board level, and has good distribution?

For the experimental approach, do you have a logic analyser, or a 'scope?

I'm afraid I don't know of any especially stressful timing test. Running some well-known code, such as Klaus Dormann's test suite, is a useful test, but no single test will test everything. If you already have a test case, maybe best to continue using that.

If you are able to swap things, swapping the CPU or the RAM or the glue might help, but it doesn't feel well-motivated at present.

What's the most substantial code which runs OK? Can you run some benchmarks in a Basic for example?

As seen on the earlier picture, the card is completely covered with copper on each side. Bottom layer is GND and top layer +5V. It has a 100n ceramic at every IC. Power looks nice on the scope.

It has a hc245 and hc373 closest to the MCU, just as in WDC's data sheet. This first 245 is connected to PROM, RAM and another 245 that is off exept when addressing I/O or video RAM. The four lowest address lines and R/W are buffered by a 245. That also drives ph2 that has everything connected in parallel, the VIA, CRTC and quite a few gate inputs.

All I/O, CRTC and video-RAM are at high addresses. 0..512K is all RAM. The address decoder involved with code execution is built as per my ugly drawing. At startup the line labelled boot is driven high and reset released for a short moment while the primary boot loader is copied from PROM into RAM, Then reset is asserted, boot released and then reset. At this point it is ready to accept loading over the VIA.

Can You spot any potential timing problems in this setup?

Having the completely failing MCU tested will be one of the next steps, and also obtaining a couple of new 816.
I will work around the failing instruction and complete the program so that a readback of memory becomes possible. The error come when working with the incoming command blocks from the PC. Whatever the outcome will be, it will provide usefull information. That will take some time, unfortunately I have a lot other things that must be done before that.

I have no logic analyser, but a Philips PM3217 50MHz analog scope with delayed timebase. With special test software most things can be made repetitive and observable on that. As I'm disabled there are some difficulties clear out space for it where the PC and 816 are placed. I also have a locic pen, but that is only good for finding missing or erraneous connections.

I have only tried very simple things with the BASIC and FORTH, but seen no instability. Rhe AIM monitor and my own software except the JSR (ABS,X) has never appeared unstable.

Nice project! I like the idea of an '816-ified AIM!

Re troubleshooting, I have several comments, and of course I'm half guessing. But maybe I can raise some ideas that indirectly become helpful.

Maybe it's not the MCU that made the difference but just the act of changing it. Remember it's possible you disturbed a marginal connection between the socket and the MCU pins or between the socket and the wires connecting to it. As you say, it's newly built hardware and anything can happen.

Regarding the '245, HCT might be a better choice than HC. Some RAMs and PROMs -- including many modern CMOS ones -- don't output good CMOS levels, only TTL levels. (If you don't have an HCT245, you could experiment with pullup resistors on the memory data bus.)

This probably isn't necessary, at least with modern WDC parts (which have very strong outputs and don't require buffering). But there's no downside to buffering except for the added delay. And that won't matter unless your margins are slim (such as when pushing for a high clock rate). BTW, what is your clock rate? Regarding the possibility of marginal timing, have you tried switching to a lower clock rate?

Can you clarify regarding clocking, please. Is the CPU Phi2 input driven by the 245, or just the Phi2 for the other logic?

BTW, HC logic may be incapable of providing the fast rise and fall times which the CPU Phi2 input requires (at least according to the datasheet).

Readback of memory adds another layer to the equation, and may become a rabbit hole due to other gremlins not yet detected. How comfortable are you with the oscilloscope? You could use it for readback, as follows. Set up the jump table so that the JSR (ABS,X) should always jump back to itself. Then you can use the 'scope to observe what happens, cycle by cycle, as just one single instruction executes again and again. (This will trash the stack, so you may need to use emulation mode to contain the damage to page $01.)

Have fun and keep us posted!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Just to note: it is certainly possible that only one or a few instructions show a timing problem. It's good that the machine is generally stable.

Thanks for answer.

The MCU is most likely seated with good connection. When it failed I did a continuity check between it and one of the other chips. But that involves pushing with a probe on the pins...

All the 245's are HCT. All memory and VIA has TTL spec despite they are CMOS ...

Strong outputs on the WDC parts was new info for me. Clock rate is only 1MHz. An eventual timing problem is hardly releated to the repetition rate, an unmet hold time is the most likely.

All clocking are driven in parallel from a single 245 output. You are right about the rise time, with all that capacitance on an already slow signal the 5ns spec is not met, maybe causing an internal instability. I was not reading the data sheet througly enough Maybe using a separate buffer output for the MCU will make difference, or/and a 74AC245 in that position. They seems hard to obtain in DIL nowadays...

A loop test of the JSR (ABS,X) will not work as the target address is unstable. Maybe if filling rest of memory with a jump back and carefully select the address to f.ex. $EAEA so any entry point will work. Pulsing an output as trigger solves the jitter. But I still needs help to physically arrange the setup, not confortable with Corona raging wild.

> Clock rate is only 1MHz. An eventual timing problem is hardly related to the repetition rate, an unmet hold time is the most likely.

(But also: glitches, noise, slow edges!)

Yes -- good idea. The '245 has eight sections, so it's worth using one section to drive the MCU alone.

Yes, you could trigger the 'scope by having the test program pulse an output. But ideally you want the test program to be a short as possible, because shorter means easier to see on the scope. It also means less chance of other gremlins throwing you off course -- you want each test to focus on exactly one thing, and ideally exclude everything else !

Myself, I would make each test as simple as possible -- a loop of just 1 or 2 instructions. There are several different ways you can trigger the scope. On 6502 you could use SYNC, but for '816 VPA or VDA can be used. Or just choose an address line which you know will toggle as the instruction gets fetched.

Good luck!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Now I has tested to connect two hct245 inputs in parallel, using one output solely for MCU and the rest on the other, including the inverter leading to the bank address hc373.
The result was a general instability. In special the on board display gets garbage chars indicating problems writing to the VIA on high addresses. Video RAM also gets garbage, but suprisingly CRTC initialises correctly every time.

The JSR (ABS,X) now seems to fail every time, as far as I could test it.

Tomorrow I will try moving the inverter input for bank address and data buffer enable to the same clock buffer as the MCU.

A fair memory scope would come in handy here...

Maybe the '373 bank address latch isn't closing soon enough to meet it's hold time requirements.
Try advancing it's clock. Maybe connect it's inverter to the input of the '245 clock buffers.

I will try that tomorrow. It seems to be a very reasonable explanation of the problem.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Now I has tried to connect the inverter for address latch before the hc245 clock buffer. That restored function to the state before I begun making changes. The data buffer has it's own inverter, still connected to the system wide clock buffer.

The JSR (ABS,X) still misbehaves. I will try to use the scope today. If I place it upright on the floor then I may be able to do it without help.

If the buffer turn off is slow, there might be a short contention when bank addresses comes on. Maybe I can see what actually happens and stop guessing.

I used the exact design from the data sheet assuming that was an approved way to solve the critical timing. The diagram has a magic symbol, red marked in the picture, that I wonder what it is. Maybe resistors? Even fairly low values will cushion a hard contention conciderably.

My chips are old Sanyo, are there any known differences with the TSMC chips?