Jeff, you're correct. No multiplexer. Instead, the address/data are provided by hardware/software combined emulation in 2 steps.
The 74LS138 decoder with its address selection lines connected to pins Phi2, R/W and A0 depending on what's happening on the bus will select output pins that drive DS1685 control signals: ALE, /WR and /RD. So for example when the A0 is low and the CPU is in the write cycle (R/W=0, Phi=1), the 138 decoder will drive line Y1 low and through inverter it will drive line ALE on DS1685 high latching the value that is currently on data bus in the internal DS1685 address register.
This is how we provide address for the internal register and write value to it:
RTC=$C100
WRADDR=RTC
WRDATA=RTC+1
...
LDA #InternalRegAddress
STA WRADDR ; write address of reg. to RTC: A0=0, R/W=0, access phase Phi=1, DS1685 will latch the #InternalRegAddress (ALE=1)
LDA #SomeValue
STA WRDATA ; write value to register address latched previously, A0=1, R/W=0, Phi=1 -> Y5=0 (/WR=0 on DS1685)
...
Now if we want to read a value from an internal DS1685 register, we need to make 138 to latch address of register first using above technique and drive /RD ping of DS1685 low:
...
LDA #InternalRegAddress
STA WRADDR
LDA WRDATA ; A0=1, R/W=1, Phi2=1 -> Y7=0 (/RD=0 on DS1685, will put data on the bus, which we get in Acc.).
...
I hope this explains the theory of operation. So, I am not surprised this works, a rather clever circuit by Chris Ward. I am stunned why it does not work connected on the CPU bus side. It looks like my I/O bus interferes here somewhat, but I see no reason why?
FYI - there was another technique to use DS1685/1687 chip on non-multiplexed bus, which required almost identical software driver coding that I figured out independently before and then I also found on the internet here:
http://www.waveguide.se/?article=ds1685-rtc-on-the-motorola-busThis also worked on my I/O side of bus, but not on the CPU side. Also that circuit was sensitive to propagation times. E.g. when I modified my I/O bus circuit to gate the data bus with extra signal A10 (thus adding 2 gates on the way of I/O selection signal in my glue logic), it also did not work on the I/O side.
Suspected here is a tight timing requirement of the DS1685 chip, which on the multiplexed bus simply loads address and data in a single data access cycle, which here I emulate by software.
Since I encountered this problem I made several revisions of my design as I found and corrected following errors:
* I have been using Phi2 in my address decoding scheme. I consulted the literature and found that this is not proper technique. The system worked though.
* I have been enabling I/O bus for full range of I/O, instead of $C400..$C7FF, which caused bus contention on the CPU side if I tried to use I/O device in range $C000..$C3FF connected on CPU bus side.
* I have not been using Phi2 signal to enable/disable data signals buffer between CPU bus side and I/O bus side, creating possibility for data contention or corruption.
Still no luck with the RTC. I wonder if using PIA chip (e.g.: MC6821) to drive DS1685 would help me to better emulate the multiplexed bus timing. Sure it would complicate software driver a bit, but perhaps I would get consistent operation out of the darn thing (assuming there is no error in my buffered I/O design, which seems to work fine for my UART circuit).
Login
Register
FAQ
Search
