It depends on what the designers intended to mark a valid bus cycle, which is the 'leading' signal for decoding. In a more general way, it's the design view of the bus.
The 8080 way - Marking a cycle by a one of several (*2) dedicated signalsignals marking the type of cycle as well as it'sits validity. RD and WR mark a read or write cycle as well as the validity of all other signals.
The 6800 way - A dedicated signal marks the validity of an access cycle, putting all other in context. VMA (Valid Memory Address) is used to indicate a cycle. R/W defines the direction of this cycle.
The 6500 way - Each and every clock cycle is a valid access cycle. No dedicated signal is needed, the clock signal can be used for this purpose. R/W defines the direction.
So while there is a basic difference in the way a bus is viewed between the 8080 and 6800 way, both need two signals to create a valid cycle and direction. The 8080 solution is more simple to decode in peripherals, especially if buildbuilt up from general TTL, while the 6800 got a more abstract view. Both have the advantage that I/O and memory does not need to be clocked. And both do as well offer support for DMA/bus-sharing, as well. The 8080 maybe more so than the 6800, as it includes a bus request protocol, while the 6800 only supports bus separation by tristating its signals.
The 6500 way is a simplification of the 6800 bus design (*3). By making each and every clock cycle a bus cycle (and having the CPU output a valid direction and address during that), one pin on the CPU could be saved. On the downside, non-6500 peripherals had to incooperateincorporate the clock signal into their enable decoding (*4). Then again, the laterlatter isn't as much of an issue as it also hits the other schemes at some point as well, depending on the peripheral used.
Even more cumbersome is the fact that this simplification made DMA/bus-sharing real hard hard, requiring external buffers and logic (*5).
It may be worth to notenoting that there wherewere many more variations that these three - as there wherewere many more microprocessors.
(For everyoneseveryone's sanity I skip the bus state controlled cycles of an IntelsIntel 8008 :))
From a historic point of view the,the 6800 way is the most versatile and found in similar ways inmethods are found many mini computers as well as other microprocessors - like TI's 9900 (here called MEMory ENable).
The Signetics/Valvo/Philips 2650 was somewhat similar, but featured in addition to a valid address line (ADRess ENable) a WRitePulse line, only triggered during write cycles - which where as well anouncedwere also announced by a R/W being high. So to some point a kind of mixture of 6800 and 8080 - satisfying both protocols for most parts. The CPU also featured as well a quite fine tuned-tuned framework for bus sharing.
Nationals SC/MP takes this a step further by using a multi master-master bus protocol by default. Only when the bus is granted a bus cycle is indicated by NENOUT, followed by an address strobe (NADS) and then followed by a write or read strobe (NWDS/NRDS) (*6). Using -this, and taking the many internal cycles without bus access into account, two SC/MP could be coupled in a system with almost no performance penalty.
Speaking of weird, the RCA/Intersil CDP1802 does feature a bus design somewhat like the 8080, with seperateseparate read and write lines (MRD/MWR), but; these do not validate other signals, but only indicate direction ... and to some extend 'alert' components ahead of time - 5 cycles for read and two for write. The transfer itself is initiated by the TPB signal validating the lower address half - which at that point is already valid for more than 3 cycles.
Even Zilog's Z80 isn't as simple as many assume. Where the 8080 signaledsignalled the type of a bus cycle during the first clock of each machine cycle (marked by SYNC), did the Z80 offeroffers separate signals to framemain memory (MREQ) or I/O access (IORQ), resulting in 4 pins dedicated to framing and signalingsignalling where 3 would have done been sufficient. Looks like a less than optimal middle way to keep 8080 compatibility.
In this context Intel's 8085 does as well changechanges/simplifysimplifies the 8080 bus, as now IO/M is a dedicated signal to be decoded during RD or WR. No more 8224/8228 combination needed. It's eventually the most simple form of the 'two signal' variation. Except now the address bus is multiplexed and a latch for half transferedtransferred on the data bus (and signaledsignalled by ALE) is to be added. 40 is a fricking low number of pins anyway.
The 8086 then continued along that way, combining both worlds: Separate RD/WR/IOM signals and multiplexed address bus with the multiplexed status signals of the 8080 ... plus even more creative encoding in maximum mode.
Bottom line, there waswere way more than just two ways to access memory (and even more for I/O).
*3 - The 6500 development history becomes quite clear when looking at a minimum 6800 system, here Motorola suggests to combine PHI2 and VMA to create a generic Enable signal. With the 6500 design as a simplified, cost reduced 6800 focused on embedded application, having this combination already by default and saving a signal to be outputedoutputted was a clear plus - not at least by freeing up pins to make the integrated clock generator work and save even more.
*4 - On the plus side, complex 6500 I/O units will have a clock signal already present, which comes handy for any kind of timer/counter application.
*5 - Something various later spin offsspinoffs eased - all the way ofto the WDC65C02 reintroducing a 6800 compatible interface.
*6 - Unlike in the question implies, it's only as simple as with the 8080, when there is no other bus user and the CPU gets it always gets its way ... and even on its own, there's the multiplexed bus and NWDS/NRDS being non overlapping-overlapping with the NADS address strobe.