Re: 7501/8501 R/W gate in

From: Francesco Messineo <francesco.messineo_at_gmail.com>
Date: Sun, 30 Aug 2020 19:33:57 +0200
Message-ID: <CAESs-_z0=ExqRGwg1dHcvfM9-e117bLCG+u=G5XVDi8PQHZDVA_at_mail.gmail.com>
On Sun, Aug 30, 2020 at 4:44 PM Gerrit Heitsch
<gerrit_at_laosinh.s.bawue.de> wrote:
>
> On 8/30/20 3:57 PM, Francesco Messineo wrote:
> > Hi all,
> > maybe this has been discussed before, but I really can't get all
> > informations together.
> > We all know the 7501 is a crippled 6510 (I say crippled because they
> > needed to get rid of either NMI or PHI2 pins to have this gate-in
> > signal fit in the 40 PIN dip package, while adding also an additional
> > port bit I/O, which is fine).
> >
> > Now, reading the 264 timing and documentation (it's on zimmers), it appears
> > that gate_in is a latch enable for the R/W signal, meaning R/W will be
> > held in its
> > previous state when gate is low.
>
>  From what I see on the scope, the Gate IN signal only allows R/W to
> change state with the rising edge of MUX.

change state as in HI/LO or also change from driven to hi-z?

>
>
> > This gate_in input is driven by MUX output from the TED chip. Basically MUX is
> > a signal for driving the DRAM address multiplexers, it's high in the /
> > RAS address
> > phase to the DRAMs and low in the /CAS address phase. So by gating R/W with
> > MUX, they prevented it to change during the later phase of a CPU Cycle.
> > Now my questions:
> > 1) why on earth would R/W change halfway a CPU cycle (phi2 high), that
> > can't happen as far as I know on a 6502/6510 system
>
> Don't forget that a 264 system changes the CPU clock between normal and
> double clock unless you set the right bit in TED. With the Gate IN, the
> R/W=LOW part of a write cycle is the same length no matter what the CPU
> clock.

hm so a RAM cycle lasts the same time regardless of the CPU clock? I
don't get this, how is that useful? You can't use the phi-low
phase for refresh then? What am I missing again?

>
>
> > 2) How can a 6510 (that doesn't have any gate_in input) work apparently fine
> > as a 7501 replacement (there're people doing that, it's documented).
>
> Probably because the circuit is a bit more robust than thought. If I
> disable GateIN, I get an aborted R/W=LOW where it shouldn't be. I can
> send the captures from the scope to whoever wants them. I used a 4
> channel scope to capture R/W, PHI0, MUX and, on one set, AEC at the same
> time.

yes, I'd like those scope traces where I can understand what could go
wrong without gate_in.

>
> > 3) Why on a C64 there was no need for this R/W latch? What main difference
> > exist between a C64 DRAM access and a C16 DRAM access (that I don't get)?
>
> Changing CPU clock speed probably.

I still don't get it, if you change clock speed, the read/write cycle
should lengthen or shorten accordingly.

>
>
> > 4) Why they didn't simply latch the R/W signal externally
> > absolutely needed and just re-use a 6510 die with an additional port
> > pin bonded out and just leave out only one of PHI2 or NMI)?
>
> The goal was to save on discrete chips. Remember Bil Herd had to fight
> for a simple 555 for the reset circuit.

I assume making a different cpu costed less than using one more ttl
chip... Not intuitive.


Frank
Received on 2020-08-30 20:00:22

Archive generated by hypermail 2.3.0.