Re: Something else... 8501 GATE-IN

From: Hegedűs István <hegedusis_at_t-online.hu>
Date: Wed, 14 Mar 2018 09:27:26 +0100
Message-ID: <6702D687F4E2491BA5D5950689D87081@emea.hpqcorp.net>
Hi,

Bil Herd already talked about this signal but I don't remember where 
exactly. He said GATEIN is a transparent latch holding the R/W signal's 
state internally to synchronize CPU cycles to DRAM cycles.
Based on this description I have written the 8501 shell around the 6502 FPGA 
code in my FPGATED project (C16 implementation). It works well with real 
dram chips.
When GATEIN is high, RW signal coming from 6502 core (going out of 8501 
module) is allowed to change, otherwise when it is low then RW's value from 
6502 core will not change (keeps its previous value).
Most probably without this signal the C16/Plus4 would run normally for a 
while but there can be rare occasions when it would cause data corruption. 
Probably it depends on the dram chip type used.

Best Regards
Istvan

-----Original Message----- 
From: Gerrit Heitsch
Sent: Tuesday, March 13, 2018 4:49 PM
To: cbm-hackers@musoftware.de
Subject: Something else... 8501 GATE-IN

Hello,

lets go back to the topic of the list.

I was talking to someone via email about the 8501 CPU in the 264 series,
he's currently trying to reverse engineer the purpose of the GATE-IN
signal on that CPU.

That got me to do some further checking, buying that 4 channel scope did
come in handy...

Things I found out:

1) The system will run fine with pin 23 of the CPU (GATE-IN) removed
from the socket. That means whatever is in there is some kind of latch
and not a flipflop.

2) The system will not run with GATE-IN pulled to GND, so it's low
active and there is an internal pullup.

3) With GATE-IN (MUX, from TED) present, the R/W line of the CPU only
changes after the rising edge of the MUX signal.

4) Without GATE-IN present, on double clock, R/W changes a bit earlier,
just before MUX is rising but otherwise looks the same.

5) Without GATE-IN on normal clock (sharing the bus with TED), R/W tries
to go LOW right after the falling edge of PHI0, but is then overruled by
TED (via AEC probably) and pulled high again. This is only for about
100ns about 100ns after PHI0 goes LOW. It finally goes low for the CPU
write cycle after PHI0 goes high.

6) When set to display=off, TED runs the CPU at double speed all the
time (AEC constantly HIGH), except for 5 consecutive refresh cycles each
scan line. With my C16 converted to SRAM (*), too bad this cannot be
disabled. :)

7) When set to display=off and single clock (65299 bit 1), TED will no
longer keep AEC HIGH all the time but run dummy cycles like VIC does in
the C64. Was probably simpler to implement than add complexity to the
state machine for just this case.


The only reason I can see why GATE-IN is there at all is 5), maybe there
were some problems in the early design with RAMs that somehow took this
as a write cycle since RAS and CAS do not go HIGH in sync with PHIO
going low but about 100ns later. TED using slightly different DRAM
timing than the C64.

(*) simpler to do than in a C64.

  Gerrit
Received on 2018-03-14 22:44:02

Archive generated by hypermail 2.2.0.