Page 2 of 3
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 6:39 pm
by BigEd
Do you have a similar LED monitor for the data lines, so you can see if the JMP was fetched? I think you must have, or you wouldn't know that the NOPs are fetched... Can you also monitor the R/W line?
As you probably know,
this is the expected behaviour:
Code: Select all
cycle ab db rw Fetch pc a x y s p
0 0000 4c 1 JMP Abs 0000 aa 00 00 fd nv‑BdIZc
0 0000 4c 1 JMP Abs 0000 aa 00 00 fd nv‑BdIZc
1 0001 00 1 0001 aa 00 00 fd nv‑BdIZc
1 0001 00 1 0001 aa 00 00 fd nv‑BdIZc
2 0002 00 1 0002 aa 00 00 fd nv‑BdIZc
2 0002 00 1 0002 aa 00 00 fd nv‑BdIZc
3 0000 4c 1 JMP Abs 0000 aa 00 00 fd nv‑BdIZc
3 0000 4c 1 JMP Abs 0000 aa 00 00 fd nv‑BdIZc
4 0001 00 1 0001 aa 00 00 fd nv‑BdIZc
4 0001 00 1 0001 aa 00 00 fd nv‑BdIZc
5 0002 00 1 0002 aa 00 00 fd nv‑BdIZc
5 0002 00 1 0002 aa 00 00 fd nv‑BdIZc
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 6:49 pm
by Mercury1964
No, the address lines pass through the LEDs. Each diode is pulled to ground. The output voltages are well within proper CMOS high and low levels.
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 6:51 pm
by Mercury1964
That is the behavior I was expecting. I currently don't have a data line monitor.
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 6:58 pm
by BigEd
Could you swap things around and monitor the LSB of the address and also the databus? It might shed some light!
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 6:59 pm
by BigEd
Quick question: do you have resistors in line with the LEDs? If not, the LEDs will hold the address lines low because they take too much current.
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 7:02 pm
by Mercury1964
Sure, I'll give it a shot right now. Also, the resistors are in lines with the LEDs.
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 7:20 pm
by GARTHWILSON
WDC's pin drivers are very, very strong; but one reason I asked about the current-limiting resistors in series with the LEDs is that high LED currents, when switching on and off, will produce a large ground bounce on a solderless breadboard, and the resulting voltages and ringing can make the supposedly single-cycled clock input appear to toggle several more times after each clock edge, and possibly at too high of a frequency for everything to operate correctly. I would set the LED current to the lowest level that leaves the LED brightness still practical to read.
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 7:33 pm
by Mercury1964
Now I'm really confused. The address LEDs show that JMP is retrieved properly, but either the LSB or HSB operands are not zeroing properly.
Also, I'll try to lower the LED current.
Re: Weird JMP problem
Posted: Sat Mar 02, 2013 7:45 pm
by BigEd
If you run a PHP instruction, you should see a write to page 1, and if you run a series of such instructions, you should see the page 1 address decrementing. That should prove that opcode fetch is actually fetching the opcode you think it is. Similarly with JSR of course.
Cheers
Ed
Re: Weird JMP problem
Posted: Sun Mar 03, 2013 1:19 am
by Mercury1964
Seems that the data LEDs were causing some of the zeroing problems. Now it's back to where it was before.
The random jumping seems to go away if I speed through cycles. If I only end up using the board at 1MHz (my master plan), will this issue be worth fixing?
Re: Weird JMP problem
Posted: Sun Mar 03, 2013 6:27 am
by BigEd
Perhaps not: it's sounding like a glitch from your single-stepping - is that consistent with what you see?
Cheers
Ed
Re: Weird JMP problem
Posted: Sun Mar 03, 2013 7:29 am
by clockpulse
The clock is a monostable multivibrator made from a 555 timer with a transistor to invert the signal.
It might be that the transistor inverter circuit has a slow rise time, what's the pullup resistor value?
It would be best to use a single inverter from a 74ACT04 (or an inverting gate) since that would have a totem pole output for a fast rise time.
Re: Weird JMP problem
Posted: Sun Mar 03, 2013 2:00 pm
by Mercury1964
Okay, I'll give that a shot. Would a 74HC14 work?
Re: Weird JMP problem
Posted: Sun Mar 03, 2013 4:27 pm
by GARTHWILSON
The 14 would be better than the 04 in this case, because it will make sure the output slew rate (rise time) is fast even with a very slow input slew rate, and its hysteresis will keep its output cleaner as the input slowly goes through the area that is neither a valid zero nor a valid one logic level. 74AC or 74ACT will be about three times as fast as HC and would be better for the clock signal on this IIRC, but if HC is all you have, using that would still be a step in the right direction.
Re: Weird JMP problem
Posted: Sun Mar 03, 2013 8:39 pm
by BigDumbDinosaur
The 14 would be better than the 04 in this case, because it will make sure the output slew rate (rise time) is fast even with a very slow input slew rate, and its hysteresis will keep its output cleaner as the input slowly goes through the area that is neither a valid zero nor a valid one logic level. 74AC or 74ACT will be about three times as fast as HC and would be better for the clock signal on this IIRC, but if HC is all you have, using that would still be a step in the right direction.
Given that the time source (555) is a relaxation oscillator and thus has a substantially finite rise and fall time, it seems logical (!) to use it to drive a flip-flop, whose output slew rate is independent of input pulse rate and rise/fall time. A 74AC74 would work well in this application. Only thing of course, is the generated Ø2 frequency would be half of the 555's rate. BTW, a comparator can be used as an adjustable time source with a very clean square wave output.
I tend to agree with the notion that false clock states may be generated in this circuit, which would majorly mess up bus timing and states. Also, as Garth noted, 74HC(T) switching rates are much slower than 74AC(T). You want the sharpest possible rise and fall time on your Ø2 clock.