6502.org

Hi guys,

I hope you can advise me on a problem I am having with my design.

My 6502 based general-purpose system is build around a mother board with 2-sided bus, which has a CPU side and buffered I/O side, both separated with 74LS245 transceivers.
I gate the buffer that separates data lines with signals:
Phi2, A10
and
/IO, which is a signal from my address decoder, active low in range c000-c7ff (8 I/O slots 0..7, 256 bytes each).
The direction of the buffer is driven by R/W signal from CPU.
The remaining buffers for address lines and CPU control signals have fixed direction from CPU to I/O side and are gated by /IO signal only.
My whole I/O range is c000..c7ff, however I designated only slots 4..7 to be the expansion slots of my system (with connectors on the mobo) and wanted to use range of I/O 0..3 (c000..c3ff) for other (internal) purposes, like RAM bank register, RTC/battery backed SRAM, general purpose I/O with PIA or VIA chip (that's why A10 line is used to gate the data buffer, to open it only in C400..c7ff range).
I wanted to have ability to connect the I/O devices designated for internal purposes on the CPU bus side, while the expansion cards (I/O 4..7) will be connected only on the other (buffered I/O) side of the bus.
This design I think is correct and it works (I tested my UART card on both sides of the bus, CPU and buffered I/O and worked in both cases), however I have a problem with my RTC circuit, which will only work on the I/O expansion side but will not work on the internal CPU bus side.

I believe that by using Phi2, A10 and /IO signals to gate the data buffer I eliminated the possibility of contention on the CPU bus side coming from the data signals of the buffer chip, so why is this still not working?
I suspect some tight timing issue, the DS1685 is a multiplexed bus type after all.
Unfortunately I don't have oscilloscope or logic analyzer to take a closer look at this problem (I hope to have one soon, should be already on its way from China).

PS:

Credits where due - my RTC circuit is based on Chris Ward's work.

Circuit diagrams:


CPU card: https://onedrive.live.com/redir?resid=1 ... hoto%2cbmp
CPU bus:: https://onedrive.live.com/redir?resid=1 ... hoto%2cbmp
I/O bus::: https://onedrive.live.com/redir?resid=1 ... hoto%2cbmp
UART::::: https://onedrive.live.com/redir?resid=1 ... hoto%2cbmp
RTC:::::: https://onedrive.live.com/redir?resid=1 ... hoto%2cbmp

Looks to me as if that RTC circuit is incomplete -- no multiplexer. I don't wonder why the card fails on the internal bus side; I wonder why it works on the I/O expansion side -- or appears to work. Is it possible your test is less than exhaustive? I suspect you've been misled by a result that's actually a fluke.

The schematic for the RTC card seems to show the RTC chip's bus, AD7 - AD0 (multiplexed Address-Data lines) connecting to D7 - D0 of the 6502 data bus. (Is that right? I'm still on my first cup of coffee here!) That RTC chip is not getting any (valid) address information latched into it. IOW you have no control over which internal RTC register gets accessed.

Multiplexed address-data lines are used to reduce pin count on some CPUs (for example 8031, and 8085 IIRC). Peripherals intended for use with these chips can attach directly. But extra circuitry is required when attaching a non-multiplexed peripheral to a multiplexed CPU -- or vice versa, as you are doing.

-- Jeff

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 ... torola-bus
This 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).

The stupidest thing caused the RTC problem on CPU bus - the connection issue.
I have been connecting the RTC circuit built on the breadboard to my mobo with cables to slot B2 on the CPU bus. That particular slot had a connection
issue on pin A25 (data pin D3) - which simply did not have an electrical connection (bad solder point).
No wonder RTC was getting garbage on that side. If by chance I connected my circuit with cables to connector B1, I would not have discovered this issue.
I must check my motherboard connections again very thoroughly.

Yes it is. It's slower than if a multiplexer were used, but the tradeoff is clearly a win since RTC accesses are usually few and far between. Glad you found the source of the trouble!