Re: Hardware emulation of 6509 using 6502?

Den Mon, 26 Feb 2018 01:04:16 -0600 skrev Jim Brain <brain@jbrain.com>:
> On 2/25/2018 5:08 PM, Jim Brain wrote:
> > On 2/25/2018 4:09 PM, Segher Boessenkool wrote:
> >>
> >> After the rising edge of Phi2 you still have Tmds (the setup time),
> >> something like 75ns on a 2MHz part, before the data bus is stable.
> >>
> >> You're supposed to read the data bus at the *falling* edge of Phi2
> >> (and you have at least 30ns there; Thw, the hold time).
> > I understand what I am supposed to do, but the 1650 is showing me 
> > otherwise.  Maybe the HP1650 is too old and takes more than 30nS to 
> > sample the pins on a falling edge.  I have a 34 channel USB LA
> > here, and I can see about hooking it up.
> >
> > If I sample at falling edge on the 6509, I *also* see the $96 on
> > the databus at step 24 (sta $96), when it should be $06 on the bus
> > If I switch to rising edge, I see $06 (and the later $91/$b1 stuff)
> >
> > No matter where I sample on the 6502, I get $96 at that point on
> > the databus.  The data lines are directly connected from the 6502
> > to the 6509 socket, so the CPLD is not involved.  In fact, at this
> > point, the CPLD is not doing anything.
> >
> > Jim
> >
> I did some more testing tonight.  I set up yet another LA on some
> pins on the CPLD, and programmed this:
> 
> 
> assign test[0] = (address_cpu == 16'h0096) & (data_cpu == 8'h06)
> & !r_w & _reset;
> assign test[1] = _reset;
> assign test[2] = phi2_6502;
> assign test[3] = r_w;
> 
> With this in place, ignoring the clock for LA purposes, I do indeed
> see the $06.  It happens for the first 62.5ns of the $0096 write
> cycle, but then is lost (must be replaced by the $96).  My suspicions
> are the RDY or AEC or some other signal forcing the bus to go
> tristate, but I am not yet able to test that.

I'd use an oscilloscope to look at the timing.

If you have a digital two channel oscilloscope, you could use external
trigger to trig on the R/_W signal and watch the clock and a pin on the
data bus using the two channels. As $06 turns to $96 I'd check D4 and
D7 which is the two signals going from 0 to 1.

I would first make sure that this is a real problem and not just the
logic analyzer showing incorrect data. You might want to add a 74S74
and hook its set/reset inputs to different outputs of the 74S299 (make
sure you don't load any output too much) and use it's output to
clock/trigger the logic analyzer. This way you get much finer grain.
Adding a dip clip on onto the 74S299 and using really short test leads
to feed the inputs of a 74S74 lets you change the timing without any
soldering or similar.

The fact that $06 turns into $96 might just be a matter of capacitive
coupling between the data bus signals and other parts of the pcb, i.e.
D4 and D7 having less capacitance so the inherent pull-up on each TTL
input discharges the pcb trace capacitance slightly faster on D4 and D7
than the other data bus signals, just enough for them to have flipped
to ones at the sampling point.

IMHO it would probably help to replace Kernal with an eprom emulator
containing test code (or the more tedious way, burning eproms/eeproms
with test code) just to make sure what's really happening, i.e. for
example writing debug data to the I/O ports.

-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

       Message was sent through the cbm-hackers mailing list