Something else... 8501 GATE-IN

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Something else... 8501 GATE-IN

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


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

hegedusis
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: [hidden email]
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


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Gerrit Heitsch
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: [hidden email]
> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

MiaM
In reply to this post by Gerrit Heitsch
Den Tue, 13 Mar 2018 16:49:11 +0100 skrev Gerrit Heitsch
<[hidden email]>:
> 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. :)

Well, if you add hardware to disconnect TED from RAM you could make a
circuit that syncs on hsync (I guess you'd need a sync separator for
that) and counts clock cycles and disconnects TED from RAM and forces
AEC high during those 5 cycles. :)

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

smf
Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

smf
On 14/03/2018 16:51, Mia Magnusson wrote:

> Well, if you add hardware to disconnect TED from RAM you could make a
> circuit that syncs on hsync (I guess you'd need a sync separator for
> that) and counts clock cycles and disconnects TED from RAM and forces
> AEC high during those 5 cycles. :)

If you're messing with timing then use ram that is rated at double the
speed of the CPU when the screen is off and interleave the CPU and TED,
forcing AEC high all the time. It will be simpler than trying to figure
out where the refresh cycles are and it will run fast even with the
screen on.

Timing sensitive software would fail, but it will also fail if you give
the CPU those extra 5 cycles per line.


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

hegedusis
In reply to this post by Gerrit Heitsch
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: [hidden email]
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: [hidden email]
> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Gerrit Heitsch
In reply to this post by smf
On 03/14/2018 06:24 PM, smf wrote:

> On 14/03/2018 16:51, Mia Magnusson wrote:
>
>> Well, if you add hardware to disconnect TED from RAM you could make a
>> circuit that syncs on hsync (I guess you'd need a sync separator for
>> that) and counts clock cycles and disconnects TED from RAM and forces
>> AEC high during those 5 cycles. :)
>
> If you're messing with timing then use ram that is rated at double the
> speed of the CPU when the screen is off and interleave the CPU and TED,
> forcing AEC high all the time. It will be simpler than trying to figure
> out where the refresh cycles are and it will run fast even with the
> screen on.

You can't leave AEC high all the time even if you run the RAM at double
speed compared to now. The 8501 will not take its address lines offline,
so when TED does an access, you will have to take AEC LOW to prevent bus
drivers in CPU und TED fighting each other.

  Gerrit


smf
Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

smf
On 14/03/2018 17:39, Gerrit Heitsch wrote:

> You can't leave AEC high all the time even if you run the RAM at
> double speed compared to now. The 8501 will not take its address lines
> offline, so when TED does an access, you will have to take AEC LOW to
> prevent bus drivers in CPU und TED fighting each other.
>
I was assuming you'd buffer them as part of the multiplexing and make
them think they were the only things connected to the RAM.

If you keep the CPU and TED clocked together then they will both start
their accesses at the same time, you'd then satisfy them both in the
same time the original dram would satisfy one.



Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

hegedusis
In reply to this post by MiaM
When display=off TED only uses the bus for the DRAM refresh. That is why it
switches back to single clock.
Although it seems to be a waste of time when using SRAMs I believe we should
not worry because of this. What could we win with those extra 5 CPU cycles
per scanline? Comparing to today's fast CPUs its nothing.

Istvan

-----Original Message-----
From: Mia Magnusson
Sent: Wednesday, March 14, 2018 5:51 PM
To: [hidden email]
Subject: Re: Something else... 8501 GATE-IN

Den Tue, 13 Mar 2018 16:49:11 +0100 skrev Gerrit Heitsch
<[hidden email]>:
> 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. :)

Well, if you add hardware to disconnect TED from RAM you could make a
circuit that syncs on hsync (I guess you'd need a sync separator for
that) and counts clock cycles and disconnects TED from RAM and forces
AEC high during those 5 cycles. :)

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


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Gerrit Heitsch
In reply to this post by smf
On 03/14/2018 07:01 PM, smf wrote:

> On 14/03/2018 17:39, Gerrit Heitsch wrote:
>
>> You can't leave AEC high all the time even if you run the RAM at
>> double speed compared to now. The 8501 will not take its address lines
>> offline, so when TED does an access, you will have to take AEC LOW to
>> prevent bus drivers in CPU und TED fighting each other.
>>
> I was assuming you'd buffer them as part of the multiplexing and make
> them think they were the only things connected to the RAM.
>
> If you keep the CPU and TED clocked together then they will both start
> their accesses at the same time, you'd then satisfy them both in the
> same time the original dram would satisfy one.

That will produce problems with CPU access to TED registers.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Gerrit Heitsch
In reply to this post by hegedusis
On 03/14/2018 07:47 PM, Hegedűs István wrote:
> When display=off TED only uses the bus for the DRAM refresh. That is why
> it switches back to single clock.
> Although it seems to be a waste of time when using SRAMs I believe we
> should not worry because of this. What could we win with those extra 5
> CPU cycles per scanline? Comparing to today's fast CPUs its nothing.

You'd gain about 78000 cycles per second.

(5 per scan line, about 312 scan lines in total, 50 frames/sec)

And yes, I know it wouldn't be a lot, that's why I put a ':)' behind it.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

MiaM
In reply to this post by Gerrit Heitsch
Den Wed, 14 Mar 2018 19:58:14 +0100 skrev Gerrit Heitsch
<[hidden email]>:

> On 03/14/2018 07:01 PM, smf wrote:
> > On 14/03/2018 17:39, Gerrit Heitsch wrote:
> >
> >> You can't leave AEC high all the time even if you run the RAM at
> >> double speed compared to now. The 8501 will not take its address
> >> lines offline, so when TED does an access, you will have to take
> >> AEC LOW to prevent bus drivers in CPU und TED fighting each other.
> >>
> > I was assuming you'd buffer them as part of the multiplexing and
> > make them think they were the only things connected to the RAM.
> >
> > If you keep the CPU and TED clocked together then they will both
> > start their accesses at the same time, you'd then satisfy them both
> > in the same time the original dram would satisfy one.
>
> That will produce problems with CPU access to TED registers.

I assume that the CPU can tolerate a slow-down of the clock until TED
is ready for access to it's registers.

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

Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

MiaM
In reply to this post by Gerrit Heitsch
Den Wed, 14 Mar 2018 20:08:56 +0100 skrev Gerrit Heitsch
<[hidden email]>:
> On 03/14/2018 07:47 PM, Hegedűs István wrote:
> > When display=off TED only uses the bus for the DRAM refresh. That
> > is why it switches back to single clock.
> > Although it seems to be a waste of time when using SRAMs I believe
> > we should not worry because of this. What could we win with those
> > extra 5 CPU cycles per scanline? Comparing to today's fast CPUs its
> > nothing.

Well, comparing with todays hardware there is no "need" to use old CBM
stuff at all. It's just a nice hobby. (Well, in theory for some people
it might be usable for learning 6502 assembler which still is a skill
that's requested by employers).

> You'd gain about 78000 cycles per second.
>
> (5 per scan line, about 312 scan lines in total, 50 frames/sec)
>
> And yes, I know it wouldn't be a lot, that's why I put a ':)' behind
> it.

I wasn't too serious either, it's just an interesting discussion
topic :)

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

Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Konrad B


14.03.2018, 20:23  Mia Magnusson <[hidden email]>:
(Well, in theory for some people
it might be usable for learning 6502 assembler which still is a skill
that's requested by employers).

I have never seen any job advertisement that would mention 6502...
Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Gerrit Heitsch
In reply to this post by MiaM
On 03/14/2018 08:22 PM, Mia Magnusson wrote:

> Den Wed, 14 Mar 2018 20:08:56 +0100 skrev Gerrit Heitsch
> <[hidden email]>:
>> On 03/14/2018 07:47 PM, Hegedűs István wrote:
>>> When display=off TED only uses the bus for the DRAM refresh. That
>>> is why it switches back to single clock.
>>> Although it seems to be a waste of time when using SRAMs I believe
>>> we should not worry because of this. What could we win with those
>>> extra 5 CPU cycles per scanline? Comparing to today's fast CPUs its
>>> nothing.
>
> Well, comparing with todays hardware there is no "need" to use old CBM
> stuff at all. It's just a nice hobby. (Well, in theory for some people
> it might be usable for learning 6502 assembler which still is a skill
> that's requested by employers).

Not surprising:

https://hackaday.com/2018/03/14/teardown-the-oregon-trail-handheld/

Seems to contain a NES-on-a-chip which means a 6502.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Groepaz
Am Mittwoch, 14. März 2018, 20:45:37 CET schrieb Gerrit Heitsch:

> On 03/14/2018 08:22 PM, Mia Magnusson wrote:
> > Den Wed, 14 Mar 2018 20:08:56 +0100 skrev Gerrit Heitsch
> >
> > <[hidden email]>:
> >> On 03/14/2018 07:47 PM, Hegedűs István wrote:
> >>> When display=off TED only uses the bus for the DRAM refresh. That
> >>> is why it switches back to single clock.
> >>> Although it seems to be a waste of time when using SRAMs I believe
> >>> we should not worry because of this. What could we win with those
> >>> extra 5 CPU cycles per scanline? Comparing to today's fast CPUs its
> >>> nothing.
> >
> > Well, comparing with todays hardware there is no "need" to use old CBM
> > stuff at all. It's just a nice hobby. (Well, in theory for some people
> > it might be usable for learning 6502 assembler which still is a skill
> > that's requested by employers).
>
> Not surprising:
>
> https://hackaday.com/2018/03/14/teardown-the-oregon-trail-handheld/
>
> Seems to contain a NES-on-a-chip which means a 6502.

6502 is still quite popular for toys in asia.

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

Never underestimate the bandwidth of a station wagon full of tapes hurtling
down the highway
<Andrew S. Tanenbaum>



Reply | Threaded
Open this post in threaded view
|

Re: Something else... 8501 GATE-IN

Konrad B
In reply to this post by Gerrit Heitsch
2018-03-14 20:45 GMT+01:00 Gerrit Heitsch <[hidden email]>:

> On 03/14/2018 08:22 PM, Mia Magnusson wrote:
>>
>> Den Wed, 14 Mar 2018 20:08:56 +0100 skrev Gerrit Heitsch
>> <[hidden email]>:
>>>
>>> On 03/14/2018 07:47 PM, Hegedűs István wrote:
>>>>
>>>> What could we win with those extra 5 CPU cycles per scanline? Comparing to today's fast CPUs its nothing.
>>
>> (Well, in theory for some people it might be usable for learning 6502 assembler which still is a skill that's requested by employers).
>
>
> Not surprising:
>
> https://hackaday.com/2018/03/14/teardown-the-oregon-trail-handheld/
>
> Seems to contain a NES-on-a-chip which means a 6502.

https://hackaday.com/2018/03/14/teardown-the-oregon-trail-handheld/#comment-4422988

Must be some unusual "NES on a chip" - or maybe this is how the
"NOAC-s" are designed now. We need to wait for the EEPROM contents
analysis.

Regards,
Konrad