6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 9:38 pm

All times are UTC




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: Phase2 and bus signals
PostPosted: Sun Jan 13, 2013 11:48 am 
Offline

Joined: Sun Jan 13, 2013 11:13 am
Posts: 10
Hi, I'm new here but I've been lurking for a while.

I'm working on my own 6502 based SBC and I am not quite sure of the best way of handling the bus for some peripherals.

SRAM: Most people seem to gate Phase2 with the a decoded address line, to create a /CS, then either tie to /OE or leave /OE asserted. Is it valid to invert ph2 and send that to /OE instead? I would have thought using /OE for the ph2 might have been more efficient for some SRAMs, then it occurred to me the SRAM may get confused by invalid states of the address bus while ph2 is low? (As /OE likely only prevents asserting the data bus?)

ROM: Most EEPROMS have a /WE pin, and from datasheets I've read, it should be adequate to invert R/W and send it there. Is it a better idea to qualify a /ROMCS with R/W?

65C52: I'd like to have two serial ports and the 65C52 seems ideal. However I've noticed that unlike the 65C51 the '52 has no phase2 pin. Anyone have experience here? I'm guessing gating a /CS with ph2 should be adequate as I cannot see why the '52 shouldn't honor ph2. But if I don't need to, I'll save the gate.

Thanks!


Top
 Profile  
Reply with quote  
PostPosted: Sun Jan 13, 2013 4:21 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
You must have a way to make sure the RAM cannot be written when phase 2 is low. The address lines are not guaranteed to be valid and stable before the R/W goes low; so it is possible to write to unintended addresses if the WE\ or CS\ is not qualified by phase 2. (You don't have to qualify both, but at least do one of them. WE\ is the better one to do for higher speeds; but it may not matter since ROM is generally slower and more likely to be the speed bottleneck than RAM is.) Note that OE\ is not involved in this. This is covered in the address-decoding page of the 6502 primer. On the 6502, it is ok to let something put data out on the bus when phase 2 is low, but this is not true of the 65816 since it is putting the bank address out at that time, and there would be bus contention.

I have not used EEPROM myself, but note that it takes time to write. It is not as fast at writing to as RAM is. The WE\ polarity is the same as R/W\ though, so that would not need to be inverted. Low=write.

The 65c52 interested me too years ago, but I have never seen one. The 65c51 is being made today by WDC in 14MHz+. I've used the '51 a lot and never had any trouble with it, although I wish a couple of the controls had not been merged into one bit. Another option I've used is the more-capable 14-pin-DIP MAX3100 UART which is interfaced through SPI. I cover I/O ICs on the I/O ICs page of the primer, and in the circuit potpourri page.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 8:20 am 
Offline

Joined: Sun Jan 13, 2013 11:13 am
Posts: 10
Thank you for the response to this. I'm guessing from this that anything that can be written to should have a /CS (Not /OE) gated with phase 2, unless they are 65-series with a phase 2 input. I'm using a DS1511Y clock, as in BDD's POCv1, and that has write-able registers and some SRAM too, so I expect the same rule applies.

The 65C52 seemed easy enough to find on Ebay, I got a new R65C52P4 for a reasonable price and had expected it to be more popular. If it turns out to not play nice I'll fall back to the 65C51.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 9:24 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8513
Location: Midwestern USA
tet00 wrote:
Thank you for the response to this. I'm guessing from this that anything that can be written to should have a /CS (Not /OE) gated with phase 2...

Not recommended. You shouldn't gate any chip select with the Ø2 clock. With the 65C02, no address bus qualification is required other than to generate the correct chip selects according to the address on A0-A15. Assert /OE along with /CS if a read operation is going to occur, as the MPU won't actually sample D0-D7 until the fall of Ø2. Incidentally, be sure to carefully read the data sheet for each device to find out how to correctly use /OE and /WE (on writable devices). In some cases, internal chip logic may act in an undefined way if both /OE and /WE are simultaneously asserted. You can generate a correct /OE signal by inverting the MPU's RWB output.

Quote:
I'm using a DS1511Y clock, as in BDD's POCv1, and that has write-able registers and some SRAM too, so I expect the same rule applies.

As I said, gate /CS as soon as the address is valid. BTW, are you using the NMOS 6502 or the 65C02? I hope it's the latter—the former has some annoying behavior, such as double writes during R-M-W instructions, as well as generation of false addresses in the intermediate steps of some indexed instructions..

In my POC unit (which is stable at 12.5 MHz) Ø2 plays no role in qualifying chip selects, as doing so needlessly reduces the time available for a device to respond when selected. As the W65C816S has two outputs (VDA and VPA) that tell the system when the address bus is valid, I use those to determine when to select a device. 'Scoping the system shows that the address bus goes valid about 30 percent into Ø2 low. The 65C02 doesn't have these outputs, and doesn't need them.

Write operations require more detailed qualification. Succinctly stated, the data bus is not valid when Ø2 is low, which means /WE on the device being written must be qualified by Ø2. The logic is:

    !WE = Ø2 & !RWB

where & is logical AND and ! is logical NOT. Failing to heed this dictum, as Garth noted, will result in a wild write. Note that in the case of the 65C22 and 65C51, chip and register selection must occur before Ø2 goes high in order for the device to respond. More than a few people have stumbled over this little characteristic. Study the timing diagrams so you can see why this is so.

Quote:
The 65C52 seemed easy enough to find on Ebay, I got a new R65C52P4 for a reasonable price and had expected it to be more popular. If it turns out to not play nice I'll fall back to the 65C51.

Also as Garth noted, the 65C51's design is not at all optimal, and not just in the control area. You'd be better served by looking at non-65xx solutions for TIA-232 I/O. In my POC unit I used the NXP 2692 (later upgraded to the 26C92), which is a dual UART in a PLCC44 package. It can run both ports at 115.2Kbps CBAT. Of course, if the host system isn't fast enough that data rate won't be practical.

I guess the point that Garth and I are trying to make is to carefully consider all aspects of your design before choosing parts and heating up the soldering iron. Also, be sure to thoroughly peruse each device's data sheet so as to avoid being tripped up by some obscure characteristic. A basic 65xx SBC is not a complicated device. The complexity comes only when the Ø2 clock rate gets cranked way up and/or a more detailed memory management scheme is developed. Lastly, your best choice for glue logic in a first-time endeavor is 74AC or 74ACT (if TTL level inputs are needed). I do not recommend the older logic families, such as 74HC/74HCT or (especially) 74LS.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Mon Jan 14, 2013 9:38 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 9:33 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Hi BDD
are you saying that you use VDA and VPA as strobes to qualify the validity of address outputs on a nanosecond basis? I would have expected these signals only to obey the usual synchronous output behaviour, and be valid on a cycle basis.

as you say, one wants to qualify at least any write operation with something which limits the access to a period when the addresses and RnW line are both stable. It's surely conventional to do that with the phi2 clock: it comes a little later than it might, but it is late enough to do the job.

it has been said elsewhere that some old peripherals don't allow for that: they need inputs stable before rising phi2.

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 10:23 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8513
Location: Midwestern USA
BigEd wrote:
Hi BDD
are you saying that you use VDA and VPA as strobes to qualify the validity of address outputs on a nanosecond basis? I would have expected these signals only to obey the usual synchronous output behaviour, and be valid on a cycle basis.

All I'm doing is ORing VDA and VPA and using the product to tell the chip select logic when it is safe to assert /CE on the affected device. VDA and VPA are indirectly slaved to the Ø2 clock and one or both (depending on the instruction step being processed) are asserted during Ø2 low, which is when A0-A15 become valid (also at that time, D0-D7 will contain the bank address). This characteristic is specified by the tADS parameter in the '816 data sheet and is a maximum of 30ns at 14MHz. Extrapolation suggests that tADS drops to about 15-20ns at 20 MHz, which is why it's essentially impossible to operate the '816 at that speed using discrete logic—Ø2 low is only 25ns.

Quote:
As you say, one wants to qualify at least any write operation with something which limits the access to a period when the addresses and RnW line are both stable. It's surely conventional to do that with the phi2 clock: it comes a little later than it might, but it is late enough to do the job.

In all 65xx MPUs, D0-D7 is not valid unless Ø2 is high. So a write has to be contingent on the phase of the clock. Here's how I did it in POC V1:

Attachment:
File comment: 65xx Read/Write Qualification
wd_qual.gif
wd_qual.gif [ 32.3 KiB | Viewed 1229 times ]

This circuit is rock-solid at 12.5 MHz and in fact, has plenty of headroom at that speed. Total propagation time from when Ø2 goes high until the /WD signal is asserted is 12.5ns, worst case. Only 6.6ns elapse until /RD is asserted. These times could be cut in half using 74ABT logic. At 12.5 MHz, a Ø2 half-cycle is 40ns, so you can see that /RD and /WD are valid well before the end of the Ø2 high cycle.

Quote:
it has been said elsewhere that some old peripherals don't allow for that: they need inputs stable before rising phi2.

The 65C21, 65C22 and 65C51 require that chip and register selects be valid before the rise of Ø2. In general, such practice should be applied to all devices in a 65xx system. In the case of the above devices, they are slaved to the Ø2 clock so they will not read D0-D7 until Ø2 goes high, which means that the MPU's RWB should be directly connected to the device's RWB without interceding circuitry.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 4:12 pm 
Offline

Joined: Sun Jan 13, 2013 11:13 am
Posts: 10
Hm, it's late so I hope my cluelessness isn't going to start arguments. :?

BigDumbDinosaur wrote:
BTW, are you using the NMOS 6502 or the 65C02?

Using the 65C02 for now, but may switch up to the `816 for a subsequent SBC. It's on order.

BigDumbDinosaur wrote:
You shouldn't gate any chip select with the Ø2 clock.

I'm guessing that's desirable rather than mandatory, as I have seen I/O devices that only have a CS or E, and RWB. Directly attaching an HD44780 LCD to the bus :oops: is an example, where I wanted to preserve VIA pins. http://6502.org/mini-projects/optrexlcd/lcd6502.gif

I guess I was implying in my original post though, that for non-65* devices that don't have a Ø2 input, is it always mandatory to honor Ø2 for all devices that accept bus writes? Eg: a DS1511Y or HD44780, as well as SRAM.

BigDumbDinosaur wrote:
Write operations require more detailed qualification. Succinctly stated, the data bus is not valid when Ø2 is low, which means /WE on the device being written must be qualified by Ø2. The logic is:

    !WE = Ø2 & !RWB

So if I am reading it right: It is better to qualify RWB with Ø2, to avoid wild writes on devices that have no Ø2 input, and let address-decode generate CE. In general. The only issue there is that the device might try to assert the data bus while Ø2 is low, even though nothing cares what information is on it. I guess the 65C02 won't care about that enough (electrically) for it to be any concern?

BigDumbDinosaur wrote:
Note that in the case of the 65C22 and 65C51, chip and register selection must occur before Ø2 goes high in order for the device to respond.

That is why my old Datasheet for my R65C52P4 is a head-scratcher, it appears to have no Ø2 input yet has NC pins. I've searched high and low for a more recent datasheet to no avail. Yours and Garth's points regarding substituting a better UART are noted. It's just I have this part plugged into my breadboard right now. If I can get things running (and TBH I am not yet at the point of cutting code) I'll report any findings on the device for completeness sake. I have a 65C51 on order anyway, but promise I won't sully an `816 with it. :)

BigDumbDinosaur wrote:
I guess the point that Garth and I are trying to make is to carefully consider all aspects of your design before choosing parts and heating up the soldering iron. Also, be sure to thoroughly peruse each device's data sheet so as to avoid being tripped up by some obscure characteristic.

Thanks for your responses, I am still in the research phase and my iron is still cold. I had already taken your recommendations for 74AC parts while studying your POC pages. Starting out, my plan was to begin at 1MHz with a 65C02, 65C22, 65C52(51), 27C512, 61512, DS1511Y, and a HD44780 and improve from there while keeping it as simple as possible.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 4:18 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
(Yes, I find BDD often mixes in mandatory with advisory. Sometimes I ask for clarification.)


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 5:17 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8513
Location: Midwestern USA
tet00 wrote:
BigDumbDinosaur wrote:
You shouldn't gate any chip select with the Ø2 clock.

I'm guessing that's desirable rather than mandatory, as I have seen I/O devices that only have a CS or E, and RWB. Directly attaching an HD44780 LCD to the bus :oops: is an example, where I wanted to preserve VIA pins. http://6502.org/mini-projects/optrexlcd/lcd6502.gif

The theory behind not gating /CS with Ø2 is the 65xx bus cycle is a two-phase cycle with different activities during each phase. During Ø2 low the address is established and at that time the addressed device is supposed to be selected. When Ø2 goes high that's when reading or writing occurs. All of the "native" 65xx silicon, going back to the earliest devices in the family, works that way.

Quote:
I guess I was implying in my original post though, that for non-65* devices that don't have a Ø2 input, is it always mandatory to honor Ø2 for all devices that accept bus writes? Eg: a DS1511Y or HD44780, as well as SRAM.

I think you may be confusing the issue. The need to qualify the RWB output with Ø2 has nothing to do with the characteristics of the device being addressed. It has to do with the characteristics of the 65xx bus cycle. I'll repeat again (How's that for redundancy?): D0-D7 is not valid when Ø2 is low.

Quote:
So if I am reading it right: It is better to qualify RWB with Ø2, to avoid wild writes on devices that have no Ø2 input, and let address-decode generate CE.

Again, IT HAS NOTHING TO DO WITH THE ADDRESSED DEVICE. Qualifying RWB with Ø2 isn't "better." It's mandatory on write operations and highly recommended in all cases to avoid undefined device behavior.

Quote:
The only issue there is that the device might try to assert the data bus while Ø2 is low, even though nothing cares what information is on it. I guess the 65C02 won't care about that enough (electrically) for it to be any concern?

A selected device is not going to assert the data bus unless its /OE is asserted while it is selected. If you use the appropriate logic you will select the device during the Ø2 low cycle and assert /OE (read) or /WE (write) on Ø2 high. On the next fall of Ø2 you deassert /CS and /OE or /WE.

Quote:
BigDumbDinosaur wrote:
Note that in the case of the 65C22 and 65C51, chip and register selection must occur before Ø2 goes high in order for the device to respond.

That is why my old Datasheet for my R65C52P4 is a head-scratcher, it appears to have no Ø2 input yet has NC pins. I've searched high and low for a more recent datasheet to no avail.

I have no familiarity with the R65C52 and have not seen its data sheet, so I can't offer any help with that part.

Quote:
Starting out, my plan was to begin at 1MHz with a 65C02, 65C22, 65C52(51), 27C512, 61512, DS1511Y, and a HD44780 and improve from there while keeping it as simple as possible.

What is a 61512? Also, I'm not sure why you would be using the 27C512, which is a 64KB EPROM. For a basic system 8KB of ROM is adequate. I used a 27C256 in POC V1, but only because I had a number of them lying around. I'm only accessing the first 8KB of the device.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 6:58 pm 
Offline

Joined: Sat Oct 20, 2012 8:41 pm
Posts: 87
Location: San Diego
BigDumbDinosaur wrote:
You'd be better served by looking at non-65xx solutions for TIA-232 I/O. In my POC unit I used the NXP 2692 (later upgraded to the 26C92), which is a dual UART in a PLCC44 package. It can run both ports at 115.2Kbps CBAT.


I Agree, I have a 26C92 (it's a 40 pin dip), I'm using one of the uarts as a serial port for computer 232 connection and the other uart as a TTL serial port to a voice synthesizer. Plus there are some input and output ports, I used a few of those to generate an i2c port. There are also some counters for generating short time delays.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 14, 2013 7:32 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
I just looked at the timings on the '52, something I had never done before since I had never seen a '52. The falling edge of the CS\ latches the register-select and R/W\ signals; so those have to be in place by the time the CS\ edge falls. (The data sheet is at http://6502.org/documents/datasheets/ro ... _dacia.pdf, but I looked in my Rockwell data book.)

For the 65c22 and 65c51, the R/W\ line definitely has to be valid and stable well before phase 2 rises. For other I/O ICs that don't have a phase-2 input, you won't want them to be both selected and write-enabled before phase 2 rises. More precisely, the problem is not that the data won't be correct yet. It might still not be correct yet when phase 2 rises, but it will be correct in time to meet the device's set-up time before phase 2 falls. So that's not it. The problem comes in when the user uses an IC without a phase-2 input and he ignores the fact that the address lines and R/W\ take on their new state at the same time instead of address lines being valid and stable before R/W\ falls.

I said I've never had problems with the '51, but I should qualify that. I've never used the 6551 (NMOS) which definitely has a couple of major problems that were fixed in the 65c51 (CMOS) version.

I have 32KB of ROM on the workbench computer because my very full-featured Forth does not fit in 8KB and I didn't want to load it every time; so I can see a reason for more ROM. I have 16KB of RAM and it has always been plenty for programs, just not data when I would like to have many megabytes of arrays, something that won't be satisfied with a full 65c02 memory map anyway.

BDD has apparently found some ICs that cause problems if both WE\ and OE\ are asseted at the same time. I have not seen any. I'm not doubting that they exist, but see if the data sheet will let you get off the easy way. It seems like most will disable their outputs when you enable writing.

On the LCD: I've put one directly on the bus before, but it was not nearly fast enough to put it on the bus of my workbench computer at 5MHz. Look at its timing spec.s, and if it's too slow for your 65c02 bus, you will probably want to go through a 65c22. I show one way of doing this at http://wilsonminesco.com/6502primer/potpourri.html#LCD

I show a very basic 65c02 computer's full schematic at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU . The accompanying notes tell how to add more I/O, like more 65c22's and a '51 or two. The glue logic already shown there (a single 74xx132!) is adequate for the whole job.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 43 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: