The thing to understand here is that phi2 is being used as a convenient timing reference, to delay the write action for long enough that the right data will be written to the right device. More, to be sure that a write action is only taken when a write is intended.

As Garth says, for a one-chip glue logic, phi2 is the best and simplest choice. But there's nothing special about phi2 - if you had good reason, you could use a signal which demarcates just the final quarter of the clock cycle, or demarcates more than half(*).

Maybe if we ask Jeff nicely he'll draw up a rubber-band diagram to illustrate RnW and CS for a write cycle. See
viewtopic.php?f=4&t=2909

Cheers
Ed

(*) Assuming a 16-bit 6502-like system. In a 24-bit '816 system, phi2 is important: it signals the two uses of the databus.

Emphasis added. We agree that letting the RAM get a head start is or may be an advantage. Therefore in the absence of any conflicting considerations it's logical to preserve that advantage.

I don't see instructing beginners as a conflicting consideration. The circuit below uses a single IC (albeit 16-pin, not 14-pin). It preserves the potential "head start" advantage, but IMO sacrifices nothing in terms of clarity and instructive value.
Of course I heartily applaud your tireless efforts, Garth -- and I know you solicit suggestions for improvements to your tutorials. In that constructive spirit, I take issue with your stance that, as a default decision, one should qualify the RAM's /CS with phase 2. I believe this muddies the water from the newbies' POV. IMO the clearest thing you can teach them is that addresses and Chip Selects are part of the setup for a transaction, whereas /WE and /OE are the culmination of the transaction.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

That's similar to a circuit I suggested for inclusion in "the primer". Also, don't Xicor and similar EEPROMs require mutually exclusive /RD and /WR signals if you want to be able to program them in-circuit? If so, wouldn't that 74xx139 circuit meet those requirements?

May I ask if there might be any advantage using a Ø2 qualified SRAM chip select? For example, could I expect reduced power consumption when using Ø2 to select a power hungry 15-nsec SRAM?

Regards, Mike

Yes, reduced power is one possible factor in favor of qualifying an SRAM chip select with Ø2. Another possible factor is simply the gates the one happens to have available (assuming discrete SSI logic). But IMO the best starting point, the default choice for a design, is not to. For brevity I've omitted some other considerations that support my position. For example, if we assume the chip-select decoder doesn't wait for Phase 2 then there's no difficulty attaching to 65xx devices such as the VIA, which require /CS to be valid in advance of Phase 2.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Oops! I see I should have qualified that question. In this case the Ø2 signal is separate from the address decoder logic. That is, the Ø2 signal drives the active high SRAM chip select input (on an 8K or 64K SRAM) while the address decoder logic drives the active low chip select and /OE inputs.

I apologize for any confusion...

I recall that there was one SRAM I looked at while designing POC V1.0, in which the truth table clearly showed that /OE and /WE were not to be simultaneously enabled. Obviously, one needs to carefully peruse the data sheet to be sure.

As it worked out, producing separate /RD (read data) and /WD (write data) signals from RWB gated by Ø2 was trivial, so I decided to strictly observe the rule of not simultaneously asserting /OE and /WE on any device, whether it was permissible or not. Incidentally, I discovered that simultaneously asserting RDN (read) and WRN (write) on the 26C92 would result in WRN being ignored. Also, simultaneously asserting the DMA read and write control inputs of the 53CF94 SCSI controller I am using is prohibited.

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

The '139 circuit above lacks the address decoding for the I/O, and also a Schmit-trigger gate for reset. A small modification would give 16K of RAM, 16K of ROM, plus I/O, but not 32K of RAM or ROM, let alone reset. The 74AC132 circuit gets everything into one IC. I don't know of any other way to do all that, even with programmable logic (since it won't do the timed reset, with debouncing). The circuit at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU shows the entire computer with 5 ICs:

• 74HC132
  
• µP
  
• RAM (16KB will be used)
  
• ROM (32KB)
  
• VIA

using the µP's onboard clock generator with just a resistor and a capacitor if you don't need crystal accuracy or high clock speeds, or hanging a 1MHz crystal right on the µP's pins. (WDC no longer tests the characteristics of the part of the circuit used for onboard clock generation, but it's all still there.) Many more I/O ICs can be added with no additional address-decoding circuitry.

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

Normally I apologize for reviving 10 year old threads, but I thought it was relevant. I know the advice of "don't write RAM (or read ROM, in the case of '816) when PHI2 is low". I just wanted to understand "why" that was the case and have others help me work through my verbal description of the "why" I had in my head (see: viewtopic.php?f=4&t=511#p37020).

Don't apologize. There's a reason the archives are kept, and sometimes picking up the discussion in the same place again prevents wasted repetition and cluttering the forum. I sometimes go through years-old material and remind myself of some good stuff that's still just as true. (I also find typos in things I wrote years ago, and I correct those, or I find links that have gone dead and need to be updated, or find that it's appropriate to add a new link for others who will come along later and read the archives.)


Are you satisfied? If the explanation needs to be further improved for when the next guy comes along with the same questions, I want to clarify or expand on it or do whatever it needs. I'm also always looking for more-efficient ways to do things, both hardware and software.

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

Mostly satisfied . The elaboration definitely helps me to visualize what's going on. I do have a question re: '816 qualification however. You mention on the address decoding section of the primer:



Is that actually necessary? I thought the purpose of the bank latching circuit that WDC recommends (to demux the Bank Address and Data Lines) was to prevent the rest of the computer from having to deal with the repurposed data bus (i.e. the other side of the latching circuit "looks like a 6502 with 24 address lines"). Or are you referring to a design where one deliberately excludes the latching circuit and the peripheral IO/ROM/RAM chips have logic to ignore the bus when the Bank Address is present on the Data Bus?

When phase 2 is low, the '816 makes its data pins to be outputs, and puts the bank address byte on the data bus, regardless of whether you're latching or using the bank byte or not. You can add the bus transceiver and disable its output during that time if you like.

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

But in WDC's recommended latching circuit, the transceiver which separates the multiplexed data and address bus from the data bus is disabled when PHI2 is low- so there's no bus contention if, for instance, a ROM outputs data early.

I guess you're not working under the assumption that the latching circuit is "mandatory" when working with the '816?

Yes, but it's an extra part. I have not examined the details and built an '816-based computer. I plan to, after I catch up on some other related projects.


Right. The only "816" I've worked with is the 65802 in my workbench computer, which is made to drop into an '02 socket and only gives access to bank 0. It still gives loads of advantages over the '02 though.

Do make sure you've gone through the topic at viewtopic.php?f=4&t=2438.

[Edited, because haste made waste.]

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

As a general rule, a chip's write-enable input should not be asserted on Ø2 low with any 6502 MPU, not just the '816. The reason for this is the data bus is never valid when Ø2 is low with the 6502 or 65C02, and when Ø2 is low during a valid memory cycle, the data bus is being driven by the 65C816 with the bank bits (A16-A23). Write-enabling a device during that time on a 65(c)02 machine will cause random data to be written into the device, or will cause the bank bits to be written on a 65C816 machine. In some cases, this behavior will cause an I/O device to malfunction, as the bit pattern on D0-D7 won't be stable while /WE is asserted.

It is recommended that a device's output-enable also be gated by Ø2, as no member of the 6502 family reads the data bus when Ø2 is low. In the case of the 65C816, devices MUST NOT be output-enabled during Ø2 low, as that is when the '816 is driving the bank bits on to D0-D7. This requirement may be met by gating write-enables with Ø2 or by using a bus transceiver (e.g., a '245) to isolate the data bus during Ø2 low. Failure to do so will likely cause bus contention and interfere with the 65C816's ability to emit the bank bit pattern.

Note that RWB, chip selects and register selects for the 65C21, 65C22 and 65C51 should not be qualified by Ø2—all of these inputs on these devices must be stable before the rise of Ø2.

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

I wouldn't worry about that part though. The write data isn't guaranteed to be valid anyway until tMDS after the rise of phase 2, tMDS being 30ns or more, depending on the column of speed and voltage in the table. As long as you're not writing to a wrong address, you'll do fine as long as the data is correct for the set-up time of the device (RAM or I/O IC) before the fall of phase 2 (for 65xx I/O ICs) or the device's CS\ or WR\ is taken false (for RAM or non-65xx I/O ICs).

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