Re: 7501/8501 R/W gate in

On 8/30/20 7:33 PM, Francesco Messineo wrote:
> 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?

High-Z is determined by AEC and if the CPU has been taken off the bus, 
TED will drive R/W to HIGH.


>>> 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?

You're missing that TED clocks the CPU only on double clock if it 
doesn't need the bus itself for display data or DRAM refresh. So during 
the 5 refresh cycles per scan line, the CPU is on single clock, no 
matter if display is on or has been turned off, refresh always happens.

Also how is this useful? That is simple. If the RAM cycle is always the 
same length, you don't need to change any of the RAM control signals 
which are generated by TED.



>>> 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.

Ok, I'll mail them to your address.


>>> 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.

It doesn't on a 264 system, /RAS and /CAS timings don't change when the 
CPU clock changes.

  Gerrit