Re: Something else... 8501 GATE-IN

Hi Gerrit,

Yes, please send the screenshots. I am collecting all info to improve 
FPGATED.

Thanks
Istvan

-----Original Message----- 
From: Gerrit Heitsch
Sent: Wednesday, March 14, 2018 1:42 PM
To: cbm-hackers@musoftware.de
Subject: Re: Something else... 8501 GATE-IN

On 03/14/2018 09:27 AM, Hegedűs István wrote:
> 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.

That's what I thought as well when I saw how the R/W signal looked with
GATE-IN disabled.

If anyone wants the screenshots from the scope, mail me.

  Gerrit





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