Building a 6502 peripheral - timing

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

Building a 6502 peripheral - timing

silverdr@wfmh.org.pl
On the wave of the recent 6509 / 6502 discussion... when building or connecting a peripheral that would allow both reading and writing, what is basically needed are the following signals:

* _CS (from address decoder)
* R_W (from 6502)
* D[0..7]
* possibly some low address bus lines A[0..3] for example
* some chips take PHI2

http://archive.6502.org/datasheets/mos_6500_mpu_nov_1985.pdf

shows timing diagrams. I wonder what would be the required timing for a peripheral without PHI2 clock input. I suspect something similar to what SRAM chips specify. Any hints as where to put attention? Like relations between _CS, R_W, ... ?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

MiaM
Den Wed, 14 Mar 2018 23:35:35 +0100 skrev [hidden email]:

> On the wave of the recent 6509 / 6502 discussion... when building or
> connecting a peripheral that would allow both reading and writing,
> what is basically needed are the following signals:
>
> * _CS (from address decoder)
> * R_W (from 6502)
> * D[0..7]
> * possibly some low address bus lines A[0..3] for example
> * some chips take PHI2
>
> http://archive.6502.org/datasheets/mos_6500_mpu_nov_1985.pdf
>
> shows timing diagrams. I wonder what would be the required timing for
> a peripheral without PHI2 clock input. I suspect something similar to
> what SRAM chips specify. Any hints as where to put attention? Like
> relations between _CS, R_W, ... ?
 
Somewhere on the net I've seen schematics of using 16550 UART's on a
C64. Although the 6510 differs slightly from a 6502, it could probably
be used as some kind of guide.

16550 has Intel timing, it's just a fancier 8250 UART which is part of
the 82** family of peripheral ICs that are ment both for 8080/8085 and
8088.

For the Intel style peripherals I think you should be careful so they
don't get a short read before and/or after a write. One way to generate
the required read/write signals is to feed R/_W, PHI2 and maybe other
signals to a 74*128/74*138 3-to-8/dual 2-to-4 decoder.

It would be easier to answer if you specify some example of what you
want to hook up.

(SRAMs is afaik never affected by spurious short reads, so with those
you might get away with timing that don't work well with various I/O
stuff).


--
(\_/) 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: Building a 6502 peripheral - timing

Jim Brain
On 3/14/2018 5:59 PM, Mia Magnusson wrote:
>
> Somewhere on the net I've seen schematics of using 16550 UART's on a
> C64. Although the 6510 differs slightly from a 6502, it could probably
> be used as some kind of guide.
16550 is easy (Intel bus interface)

~WR = !(!(R/!W) * PHI2)
~RD = !(R/!W * PHI2)

Obviously, depending on your choice of logic, you can reduce that down,
but the gist is there.

64NIC and other options implement the above.
>
As to the general question, I have sigrok here with the LWLA1034, and I
could run a timing pull of the various signals through some steady state
timing period, to show the relationships, when I next test the 6509
emu.  But, I'd want someone to consider where to pull the signals and
work with me.  If I have to spend lots of cycles trying to determine
where to test signals, it's likely to not happen.

Jim

--
Jim Brain
[hidden email]
www.jbrain.com


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

silverdr@wfmh.org.pl
In reply to this post by MiaM

> On 2018-03-14, at 23:59, Mia Magnusson <[hidden email]> wrote:
>
>> On the wave of the recent 6509 / 6502 discussion... when building or
>> connecting a peripheral that would allow both reading and writing,
>> what is basically needed are the following signals:
>>
>> * _CS (from address decoder)
>> * R_W (from 6502)
>> * D[0..7]
>> * possibly some low address bus lines A[0..3] for example
>> * some chips take PHI2
>>
>> http://archive.6502.org/datasheets/mos_6500_mpu_nov_1985.pdf
>>
>> shows timing diagrams. I wonder what would be the required timing for
>> a peripheral without PHI2 clock input. I suspect something similar to
>> what SRAM chips specify. Any hints as where to put attention? Like
>> relations between _CS, R_W, ... ?
>
> Somewhere on the net I've seen schematics of using 16550 UART's on a
> C64. Although the 6510 differs slightly from a 6502, it could probably
> be used as some kind of guide.
>
> 16550 has Intel timing, it's just a fancier 8250 UART which is part of
> the 82** family of peripheral ICs that are ment both for 8080/8085 and
> 8088.
>
> For the Intel style peripherals I think you should be careful so they
> don't get a short read before and/or after a write. One way to generate
> the required read/write signals is to feed R/_W, PHI2 and maybe other
> signals to a 74*128/74*138 3-to-8/dual 2-to-4 decoder.
>
> It would be easier to answer if you specify some example of what you
> want to hook up.

Actually I want to "build" a CPLD based peripheral chip. Let's say a port like 6526 but with single port and preferably without feeding it with PHI2.

> (SRAMs is afaik never affected by spurious short reads, so with those
> you might get away with timing that don't work well with various I/O
> stuff).

Sorry for being ignorant here, but what exactly are "spurious short reads"? Something like reading chip's own output from the bus?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

silverdr@wfmh.org.pl
In reply to this post by Jim Brain

> On 2018-03-15, at 00:09, Jim Brain <[hidden email]> wrote:
>
>> Somewhere on the net I've seen schematics of using 16550 UART's on a
>> C64. Although the 6510 differs slightly from a 6502, it could probably
>> be used as some kind of guide.
> 16550 is easy (Intel bus interface)
>
> ~WR = !(!(R/!W) * PHI2)
> ~RD = !(R/!W * PHI2)

What (exactly) ~WR and ~RD mean? Other that "something" write/read related? And what about _CS?

> As to the general question, I have sigrok here with the LWLA1034, and I could run a timing pull of the various signals through some steady state timing period, to show the relationships, when I next test the 6509 emu.  But, I'd want someone to consider where to pull the signals and work with me.  If I have to spend lots of cycles trying to determine where to test signals, it's likely to not happen.

Please bear with me, I am not sure if I make myself clear on that. The general questions are something like "How a peripheral chip should react timing-wise to the incoming signals[*], so that causes no 6502/6510 interfacing problems?". "When should it start driving databus and when to stop doing it on read cycle?". "When should it latch the data bits on write cycle?". "What should be the relation between _CS and R_W?" ...


* - I take that there has to be some delay of the _CS edge due to address decoding.
--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

Jim Brain
In reply to this post by silverdr@wfmh.org.pl
On 3/14/2018 6:10 PM, [hidden email] wrote:
> Actually I want to "build" a CPLD based peripheral chip. Let's say a port like 6526 but with single port and preferably without feeding it with PHI2.

Here's a start (copied from working code, but I removed clock, so no
guarantees on first time working):

module silverdream(input _reset, input _cs, input r_w, input address,
inout [7:0]data);

wire [7:0]ddr;
wire [7:0]port;

assign data = (_cs & r_w ? (address ? port : ddr) : 8'bz);
ioport io(_reset,!_cs & !address & !r_w, ddr, !_cs & adddress & !r_w,
port, data);
endmodule

module ioport(input reset,input [7:0]data_in,input we_ddr,output
[7:0]ddr,input we_port,output [7:0]port,inout [7:0]signals);

register  reg_ddr(!reset,we_ddr,data_in,ddr);
register  reg_a(!reset,we_port,data_in,port);

assign signals[0] = (ddr[0] ? port[0] : 'bz);
assign signals[1] = (ddr[1] ? port[1] : 'bz);
assign signals[2] = (ddr[2] ? port[2] : 'bz);
assign signals[3] = (ddr[3] ? port[3] : 'bz);
assign signals[4] = (ddr[4] ? port[4] : 'bz);
assign signals[5] = (ddr[5] ? port[5] : 'bz);
assign signals[6] = (ddr[6] ? port[6] : 'bz);
assign signals[7] = (ddr[7] ? port[7] : 'bz);
endmodule

module register(reset, enable, d, q);
parameter WIDTH = 8 ;
parameter RESET = 0 ;

input clock;
input reset;
input enable;
input [WIDTH-1:0] d;
output [WIDTH-1:0] q;
reg [WIDTH-1:0] q;
initial q = RESET;

always @ (posedge enable, posedge reset)
   begin
   if(reset)
         q <= RESET;
   else
        q <= d;
   end
endmodule



Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

Jim Brain
In reply to this post by silverdr@wfmh.org.pl
On 3/14/2018 6:26 PM, [hidden email] wrote:

>> On 2018-03-15, at 00:09, Jim Brain <[hidden email]> wrote:
>>
>>> Somewhere on the net I've seen schematics of using 16550 UART's on a
>>> C64. Although the 6510 differs slightly from a 6502, it could probably
>>> be used as some kind of guide.
>> 16550 is easy (Intel bus interface)
>>
>> ~WR = !(!(R/!W) * PHI2)
>> ~RD = !(R/!W * PHI2)
> What (exactly) ~WR and ~RD mean? Other that "something" write/read related? And what about _CS?
~RD means "active low on this signal means a read activity".  ~WR is
similar.  _CS is a separate signal on Intel ICs, so no need to worry
about it here.  It operates the same as with 65/68XX stuff.
>
> Please bear with me, I am not sure if I make myself clear on that. The general questions are something like "How a peripheral chip should react timing-wise to the incoming signals[*], so that causes no 6502/6510 interfacing problems?". "When should it start driving databus and when to stop doing it on read cycle?". "When should it latch the data bits on write cycle?". "What should be the relation between _CS and R_W?" ...
In general, all addressing and activity signals should be stable before
PHI2 goes high.  The 64 violates this and some things behave badly.  A
while back, it was discussed on list why the EasyFlash and the Swiftlink
use a 7474 to shorten the phi2 cycle to fix this.

Assuming PHI2 is the last thing to change, one should place data on the
bus during a 65XX/68XX read cycle no sooner than PHI2 going high, and
remove after PHI2 goes low
Same for write.  The system should latch the data at the end of the
cycle (when PHI2 falls).

Jim

Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

MiaM
In reply to this post by silverdr@wfmh.org.pl
Den Thu, 15 Mar 2018 00:10:38 +0100 skrev [hidden email]:

>
> > On 2018-03-14, at 23:59, Mia Magnusson <[hidden email]> wrote:
> >
> >> On the wave of the recent 6509 / 6502 discussion... when building
> >> or connecting a peripheral that would allow both reading and
> >> writing, what is basically needed are the following signals:
> >>
> >> * _CS (from address decoder)
> >> * R_W (from 6502)
> >> * D[0..7]
> >> * possibly some low address bus lines A[0..3] for example
> >> * some chips take PHI2
> >>
> >> http://archive.6502.org/datasheets/mos_6500_mpu_nov_1985.pdf
> >>
> >> shows timing diagrams. I wonder what would be the required timing
> >> for a peripheral without PHI2 clock input. I suspect something
> >> similar to what SRAM chips specify. Any hints as where to put
> >> attention? Like relations between _CS, R_W, ... ?
> >
> > Somewhere on the net I've seen schematics of using 16550 UART's on a
> > C64. Although the 6510 differs slightly from a 6502, it could
> > probably be used as some kind of guide.
> >
> > 16550 has Intel timing, it's just a fancier 8250 UART which is part
> > of the 82** family of peripheral ICs that are ment both for
> > 8080/8085 and 8088.
> >
> > For the Intel style peripherals I think you should be careful so
> > they don't get a short read before and/or after a write. One way to
> > generate the required read/write signals is to feed R/_W, PHI2 and
> > maybe other signals to a 74*128/74*138 3-to-8/dual 2-to-4 decoder.
> >
> > It would be easier to answer if you specify some example of what you
> > want to hook up.
>
> Actually I want to "build" a CPLD based peripheral chip. Let's say a
> port like 6526 but with single port and preferably without feeding it
> with PHI2.

Aha! I guess that you need PHI2 or use external logic for the
combinations of PHI2 and R/_W as Jim described.

> > (SRAMs is afaik never affected by spurious short reads, so with
> > those you might get away with timing that don't work well with
> > various I/O stuff).
>
> Sorry for being ignorant here, but what exactly are "spurious short
> reads"? Something like reading chip's own output from the bus?
 
I don't know if there is any established term. I'm refering to a
situation where select/enable signals are active when R/_W changes
state. That should ideally not happen but could anyway happen with
imperfect circuits.


--
(\_/) 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: Building a 6502 peripheral - timing

silverdr@wfmh.org.pl
In reply to this post by Jim Brain

> On 2018-03-15, at 00:38, Jim Brain <[hidden email]> wrote:
>
>>> ~WR = !(!(R/!W) * PHI2)
>>> ~RD = !(R/!W * PHI2)
>> What (exactly) ~WR and ~RD mean? Other that "something" write/read related? And what about _CS?
> ~RD means "active low on this signal means a read activity".  ~WR is similar.

So those are separate lines, right?

>  _CS is a separate signal on Intel ICs, so no need to worry about it here.  It operates the same as with 65/68XX stuff.

The reason I worry is because I don't fully understand how a chip with no PHI2 input doesn't "get confused" whether _CS going low means a read or write cycle. What happens when _CS goes low with R_W remaining high and THEN going low, as it seems to be the case with SRAM, when _CS comes first and then comes R_W due to external combination waiting for PHI2? Isn't this what Mia called "spurious short reads"?

>> Please bear with me, I am not sure if I make myself clear on that. The general questions are something like "How a peripheral chip should react timing-wise to the incoming signals[*], so that causes no 6502/6510 interfacing problems?". "When should it start driving databus and when to stop doing it on read cycle?". "When should it latch the data bits on write cycle?". "What should be the relation between _CS and R_W?" ...
> In general, all addressing and activity signals should be stable before PHI2 goes high.  The 64 violates this and some things behave badly.  A while back, it was discussed on list why the EasyFlash and the Swiftlink use a 7474 to shorten the phi2 cycle to fix this.
>
> Assuming PHI2 is the last thing to change, one should place data on the bus during a 65XX/68XX read cycle no sooner than PHI2 going high, and remove after PHI2 goes low
> Same for write.  The system should latch the data at the end of the cycle (when PHI2 falls).

That would imply feeding the chip with PHI2. But memory is not fed with it and still works correctly.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

silverdr@wfmh.org.pl
In reply to this post by MiaM

> On 2018-03-15, at 01:31, Mia Magnusson <[hidden email]> wrote:
>
>> Actually I want to "build" a CPLD based peripheral chip. Let's say a
>> port like 6526 but with single port and preferably without feeding it
>> with PHI2.
>
> Aha! I guess that you need PHI2 or use external logic for the
> combinations of PHI2 and R/_W as Jim described.

If I connect PHI2, this becomes clearer but there are chips working perfectly well without PHI2. Although in such cases the R_W needs to be combined with PHI2, which leads us down...

>>> (SRAMs is afaik never affected by spurious short reads, so with
>>> those you might get away with timing that don't work well with
>>> various I/O stuff).
>>
>> Sorry for being ignorant here, but what exactly are "spurious short
>> reads"? Something like reading chip's own output from the bus?
>
> I don't know if there is any established term. I'm refering to a
> situation where select/enable signals are active when R/_W changes
> state.

... here. Because this is *exactly* one of the main reasons I asked the question in the first place! What happens in such situation. When I have a SRAM chip with R_W activation waiting until PHI2 rises, then this should cause the situation you describe. Namely, _CS is already low for some time when R_W goes low. Or am I completely wrong here (can't check it empirically as I am out of my place).

> That should ideally not happen but could anyway happen with
> imperfect circuits.

So how could this be avoided / dealt with?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

Jim Brain
In reply to this post by silverdr@wfmh.org.pl
On 3/14/2018 7:33 PM, [hidden email] wrote:
> So those are separate lines, right?
Yep.
> The reason I worry is because I don't fully understand how a chip with no PHI2 input doesn't "get confused" whether _CS going low means a read or write cycle. What happens when _CS goes low with R_W remaining high and THEN going low, as it seems to be the case with SRAM, when _CS comes first and then comes R_W due to external combination waiting for PHI2? Isn't this what Mia called "spurious short reads"?

In that case, if the CS line goes low with R/W high a read) and *THEN*
goes low, you need to treat it as two operations.  a read and then a
write.  If the read cycle (cs low and read high) meets the timing
criteria, the read will happen, followed by the write.
>
> That would imply feeding the chip with PHI2. But memory is not fed with it and still works correctly.
Yes, in the Intel space, the WR/RD lines are the defining item. They
should be strobed last and finish first.  Most of the time, if a chip
uses PHI2, internally it is just doing:

CSinternal = CSexternal * PHI2

putting the clock in the IC was the Motorola/MOS way of synchronizing
the inputs to some known reference.  It is not absolutely needed.

Jim

>

--
Jim Brain
[hidden email]
www.jbrain.com


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

Gerrit Heitsch
On 03/15/2018 01:56 AM, Jim Brain wrote:
>
> putting the clock in the IC was the Motorola/MOS way of synchronizing
> the inputs to some known reference.  It is not absolutely needed.

It also allowed putting timers into the IC.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

Gerrit Heitsch
In reply to this post by silverdr@wfmh.org.pl
On 03/15/2018 01:33 AM, [hidden email] wrote:
>
> That would imply feeding the chip with PHI2. But memory is not fed with it and still works correctly.

Yes, but if the memory in question is DRAM, then you have /RAS and /CAS
signals that are timed correctly and they implicitly 'contain' PHI2.

And if you use SRAM, then you need to use PHI2 in the decoding logic to
make sure that /WE on the RAM can only go low as long as PHI2 is HIGH.
Otherwise you don't need to care much since a read from the wrong
address does no harm to the RAM contents. With a peripheral it might
though, on some of them status registers change state on read.

  Gerrit




Reply | Threaded
Open this post in threaded view
|

RE: Building a 6502 peripheral - timing

Baltissen, GJPAA (Ruud)
Hallo Gerrit,


> ... to make sure that /WE on the RAM can only go low as long as PHI2 is HIGH.

IMHO the CS input of a SRAM already does take care of that.


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org








De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

silverdr@wfmh.org.pl

> On 2018-03-15, at 08:48, Baltissen, GJPAA (Ruud) <[hidden email]> wrote:
>
> Hallo Gerrit,
>
>
>> ... to make sure that /WE on the RAM can only go low as long as PHI2 is HIGH.
>
> IMHO the CS input of a SRAM already does take care of that.

No, it can't. PHI2 is nowhere to connect to there so it has to be taken care of externally.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

silverdr@wfmh.org.pl
In reply to this post by Gerrit Heitsch

> On 2018-03-15, at 08:44, Gerrit Heitsch <[hidden email]> wrote:
>
> On 03/15/2018 01:33 AM, [hidden email] wrote:
>> That would imply feeding the chip with PHI2. But memory is not fed with it and still works correctly.
>
> Yes, but if the memory in question is DRAM, then you have /RAS and /CAS signals that are timed correctly and they implicitly 'contain' PHI2.

True. That explains good part of the confusion.

> And if you use SRAM, then you need to use PHI2 in the decoding logic to make sure that /WE on the RAM can only go low as long as PHI2 is HIGH. Otherwise you don't need to care much since a read from the wrong address does no harm to the RAM contents.

That's known but [why] doesn't this lead to those "spurious short reads" Mia wrote about?

> With a peripheral it might though, on some of them status registers change state on read.

All in all, it seems like giving it PHI2 input, even if I don't plan any timers, is the safest bet, right?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

silverdr@wfmh.org.pl
In reply to this post by Gerrit Heitsch

> On 2018-03-15, at 08:38, Gerrit Heitsch <[hidden email]> wrote:
>
> On 03/15/2018 01:56 AM, Jim Brain wrote:
>> putting the clock in the IC was the Motorola/MOS way of synchronizing the inputs to some known reference.  It is not absolutely needed.
>
> It also allowed putting timers into the IC.

Also true. But I don't need any timers there. That's why I was thinking of skipping the clock altogether as I know there are chips that go without it.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

Gerrit Heitsch
In reply to this post by Baltissen, GJPAA (Ruud)
On 03/15/2018 08:48 AM, Baltissen, GJPAA (Ruud) wrote:
> Hallo Gerrit,
>
>
>> ... to make sure that /WE on the RAM can only go low as long as PHI2 is HIGH.
>
> IMHO the CS input of a SRAM already does take care of that.

No, it doesn't unless you add it to your decoding logic. If your
decoding logic only uses address lines (Like just using A15 as /CS when
using a 32K SRAM), the RAM will become active quite a bit before PHI2 is
HIGH.

The 'approved way' (tm) to do it is to use PHI2 only in the generation
of the /WE signal for the RAM so that /WE can only go low as long as
PHI2 is HIGH.

  Gerrit




Reply | Threaded
Open this post in threaded view
|

Re: Building a 6502 peripheral - timing

Gerrit Heitsch
In reply to this post by silverdr@wfmh.org.pl
On 03/15/2018 09:07 AM, [hidden email] wrote:
>
>> On 2018-03-15, at 08:38, Gerrit Heitsch <[hidden email]> wrote:
>>
>> On 03/15/2018 01:56 AM, Jim Brain wrote:
>>> putting the clock in the IC was the Motorola/MOS way of synchronizing the inputs to some known reference.  It is not absolutely needed.
>>
>> It also allowed putting timers into the IC.
>
> Also true. But I don't need any timers there. That's why I was thinking of skipping the clock altogether as I know there are chips that go without it.

Yes, there are, like the 6529B in the 264 series. But I think there PHI2
is hidden in the PLA equations for the output that controls /CS for this
chip. After all, in this system the PLA generates PHI2...

  Gerrit

Reply | Threaded
Open this post in threaded view
|

RE: Building a 6502 peripheral - timing

Baltissen, GJPAA (Ruud)
In reply to this post by silverdr@wfmh.org.pl
Hallo Patryk,


> No, it can't. PHI2 is nowhere to connect to there so it has to be taken care of externally.

I meant: the moment you disable CS, the state of WE doesn't matter anymore. In my designs I always make sure that PHI2 is part of CS selection circuit. Using R/W could be dangerous: what if WE becomes (H) before CS? In that case a bus clash can occur, even it is just a very short time.

Regarding the use of Intel and Zilog ICs: I always use a 74LS139 to create the needed /RD and /WR signals using PHI2 and R/W as inputs.


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org







De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617


123