TTL 6502 Here I come

[Drass]

BigDumbDinosaur wrote:

During the momentary period when the address bus is in a state of flux the wrong UART register might be selected, followed by selection of the correct register.

Having had some time to ponder it, I believe you're right. The address lines may indeed stabilize at the same time, but there is no telling what intermediary values might appear on the bus prior to that. For the UART, a read of the MR register is as destructive as a write (in the sense that a change is made to the device) and so it stands to reason we should qualify reads with PHI2 exactly as we do with the writes. Unfortunately, it's not really feasible to patch the current board, so it will have to go on the list of board revisions. I may in fact order rev 2 of the SBC along with the other CPU boards if I can manage to figure out how to panelize the design. (And thank you for taking the time to look at the SBC schematics BDD!)

Now, having said all that, I have done more testing with the SBC as it is and it seems stable using absolute addressing. I can also duplicate the problem at will by reverting to indexed addressing. Stepping through the code, I can see the UART MR register address $8000 on the bus in the dead cycle prior to the write of the STA $8000,Y operation. Running the test several times to confirm produced the same result. I tried Jeff's suggestion of reducing the base address by one and incrementing the index (STA $7FFF, Y with Y=1) and the problem went away, exactly as expected. Finally, I tried also indirect addressing, both with and without a page crossing, and did NOT see any partial addresses on the bus with either of these operations. So far as I can tell, the issue only arises with absolute indexed addressing.

My hypothesis is that momentary values on the address bus are not in fact the culprit in this case, but rather that it is a partial address generated during the dead cycle, despite what the datasheet says. Still, I may be botching up the tests and reading the bus values incorrectly, so I don't think I can know definitvely until I make the required mod to qualify reads on the SBC and see if the problem with indexed addressing persists. In the meantime, I'm happy to report the SBC is performing well despite these uncertainties and XMODEM file transfers are now working. Here is a pic of a program that has been uploaded from my PC to the SBC making a BIOS call to print some text on the screen (in the example shown, the Minimon commands "U" and "G" default to address $0400, which is the start of USER RAM on the SBC) ...

[BigDumbDinosaur]

Drass wrote:

(And thank you for taking the time to look at the SBC schematics BDD!)

You're welcome.

Quote:

Now, having said all that, I have done more testing with the SBC as it is and it seems stable using absolute addressing...So far as I can tell, the issue only arises with absolute indexed addressing.

Interesting. It seems as though the behavior is similar to what I was encountering with POC V1.0 before I patched it to qualify addresses with VDA and VPA. It has to make you wonder how "safe" <addr>,X and <addr>,Y addressing is with read-sensitive hardware.

Quote:

My hypothesis is that momentary values on the address bus are not in fact the culprit in this case, but rather that it is a partial address generated during the dead cycle, despite what the datasheet says. Still, I may be botching up the tests and reading the bus values incorrectly, so I don't think I can know definitvely until I make the required mod to qualify writes on the SBC and see if the problem with indexed addressing persists.

You mean qualify reads, eh?

Quote:

In the meantime, I'm happy to report the SBC is performing well despite these uncertainties and XMODEM file transfers are now working.

The ability to successfully complete a data transfer is telling, in that it indicates you have a clean-running serial connection. How fast are you running the connection?

[Drass]

BigDumbDinosaur wrote:

It has to make you wonder how "safe" <addr>,X and <addr>,Y addressing is with read-sensitive hardware.

I'm almost sure that's the issue here, although I do agree that the unqualified /OE signal is also a problem. I'll be making the correction on the Rev2 board.

Quote:

You mean qualify reads, eh?

Yes, thanks. I'll edit the post to clear it up.

Quote:

How fast are you running the connection?

115.2K Baud rate and 16MHz system clock with wait-states enabled. The wait-state logic fails after that. I'm going to see if I can fix it for rev2 also. I sure would like the UART to work when the machine is clocked at 20MHz! Not sure if that's possible in the current design. We'll see.

Beyond that, I'd love to pause here and have some fun writing software but I best press on. I do want to have the CPU built during my lifetime!

[dwight]

At 20 MHz, you can emulate a UART.
You can add a little hardware if you want to minimize
the code.
You'd just need a timer you can read, a single bit port and
a XOR on an interrupt to catch transitions.
Dwight

[BigDumbDinosaur]

dwight wrote:

At 20 MHz, you can emulate a UART.
You can add a little hardware if you want to minimize
the code.
You'd just need a timer you can read, a single bit port and
a XOR on an interrupt to catch transitions.
Dwight

Sounds like a great application for a real UART.

[dwight]

If I understand the problem correctly, just adding phase2 of
the clock is not going to fix the problem, you are seeing.
If it is putting $8000 on the address lines, it will see that on the
phase2 as well.
Still during transition of addresses, there is nothing to qualify
the value of the address.
I'm not sure how tight your read timing is. You might make sure
that you have enough delay on the phase2 for reads that the processor
doesn't miss that data on a fast device. The processor is using
phase2 to capture the reads as well.
If you tap the phase2, for read VA, at the same location as it is
used to latch the read in the processor, it should ensure it can't
race. If you tap someplace earlier, you my create an undesired
race.
Just a thought
Dwight

[Drass]

dwight wrote:

If I understand the problem correctly, just adding phase2 of
the clock is not going to fix the problem, you are seeing.
If it is putting $8000 on the address lines, it will see that on the
phase2 as well.

Thanks for the comments Dwight! I agree ... to be clear, I am implementing both BDD's suggestion of qualifying reads AND also dr Jefyll's suggestion of forcing a page crossing. The first deals with address lines fluctuating while the second avoids the partial address being placed in the bus during "dead" cycles. All my testing suggests absolute indexed addressing re-reads the PC address during the "dead" cycle if a page is crossed. I'm not sure quite what you mean by tapping phase2 ... I'm using PHI2 as output from the clock generator as the system clock for all purposes.

[Drass]

I was thinking about using RDY to implement the wait-state circuit for Rev 2 of the SBC. Since I have Rev 1 to use for debugging the TTL CPU, Rev 2 can dispense with a lot of complexities and just focus on speed - no need for single-cycle or step clocks. That should make for a faster wait circuit to handle a 20MHz clock.

Clocking a "divide by two" flip-flop wth PHI2 seems to be enough to generate the right timing for RDY. But for touchy peripheral ICs, it seems /WE and /OE must also be kept low throughout the wait-cycle even as PHI2 rises and falls. Otherwise, the peripheral will "see" two short read/write operations rather than one long one. It seems that if /OE and /WR are left qualified only by PHI2, either the minimum pulse width requirements would be violated or spurious reads and writes would be made. Either way, the wait-state would fail.

I'm thinking the solution is to derive /OE and /WE from PHI2', where PHI2' = (PHI2 OR /RDY). That should keep the read and write enable signals low for the extra cycle and give peripherals enough time to respond.

Do I have this right?

[BigDumbDinosaur]

Drass wrote:

I'm thinking the solution is to derive /OE and /WE from PHI2', where PHI2' = (PHI2 OR /RDY). That should keep the read and write enable signals low for the extra cycle and give peripherals enough time to respond.

Do I have this right?

Almost.

RDY is it is a bi-directional signal. If the MPU executes a WAI instruction it will also pull RDY low until the interrupt comes. Hence your logic has to know whether RDY is low because of a wait-state or because of a WAI instruction.

Rather than try to explain everything, attached is a copy of the glue logic for POC V2, which includes wait-state generation.

glue_logic.txt

CPLD Source Code w/Wait-State Generation

(16.71 KiB) Downloaded 84 times

[Dr Jefyll]

Drass wrote:

dr Jefyll's suggestion [...] avoids the partial address being placed in the bus during "dead" cycles.

Uh, nope!

Drass wrote:

All my testing suggests absolute indexed addressing re-reads the PC address during the "dead" cycle if a page is crossed.

Yes.

My suggestion avoids the read-before-write of a fully-formed address. I think that's what you meant but you were just typing too fast. To be clear, "partial address" refers to the situation where the low byte of an address is valid but the high byte is 1 less than it ought to be. (The high byte needs to be incremented because addition performed on the low byte has produced a carry. IOW a page-crossing has occurred.)

AFAIK the 'C02 never places a partial address on the bus -- I believe they *did* entirely eliminate that particular misbehavior. In every case where the NMOS chip would've produced a partial address, the CMOS chip will place PC on the bus instead -- I've seen no evidence to contradict this. But this doesn't cover the situation mentioned upthread, namely an indexed STA without a page crossing. An NMOS chip will immediately present the complete address, first reading from it then writing to it. And Drass discovered the CMOS chip does the same! My suggestion avoids this because it ensures a page crossing. So, we get a read via PC then a write to the fully-formed address.

Drass wrote:

I was thinking about using RDY to implement the wait-state circuit for Rev 2 of the SBC. Since I have Rev 1 to use for debugging the TTL CPU, Rev 2 can dispense with a lot of complexities and just focus on speed

Hey, wait a minute! Recently you said you were resisting the urge to develop new software because it would distract you from the main project -- the TTL 6502. But now you're getting distracted with new hardware!?

Drass wrote:

I'm thinking the solution is to derive /OE and /WE from PHI2', where PHI2' = (PHI2 OR /RDY). That should keep the read and write enable signals low for the extra cycle and give peripherals enough time to respond.

I like the PHI2' idea but I'd generate it differently. If I understand correctly your method gives OE and WE pulses which endure for 1.5 cycles -- they begin very soon during the 2-cycle period devoted to the access. It'd be better to increase the address setup time seen by the peripheral by having the OE and WE pulses endure for only half of the 2-cycle period.

Posted below are the original wait-state circuit discussed elsewhere and a revised version with added logic to generate PHI2'. Extra sets of eyes welcome -- I'm up past my bedtime!

BigDumbDinosaur wrote:

your logic has to know whether RDY is low because of a wait-state or because of a WAI instruction.

Darn! -- I overlooked that. But after blinking my eyes for a while I concluded you must be getting sleepy, too, BDD. The logic we're talking about is in charge of generating OE and WE for the slow peripheral. And WAI doesn't address the slow peripheral. WAI's bus activity only involves code memory.

However, you're right about RDY being bidirectional, which means a resistor as shown may be desirable to limit current flow. Details of this are hashed over in the post I linked to.

-- Jeff

simple wait-state generator.gif (4 KiB) Viewed 1165 times

wait-state generator with OE + WE.png (8.2 KiB) Viewed 1165 times

[GARTHWILSON]

I'd recommend putting a 22pF capacitor across that resistor to get rid of that pole that would otherwise cause some delay.

[ttlworks]

@Garth:
Resistor with a 22pF capacitor in parallel sounds good.
The question now is: how big the resistor should be to make sure that the WAI instruction still works.

Inside the TTL CPU, a 74ACT125 (IC5C) tries to pull RDY low through a 470ohm resistor (R48) in case of a WAI instruction.
Would be interesting to know, how much current a W65C02 would sink from the RDY pin to GND in case of WAI,
because the WDC datasheet doesn't seem to go too deep into detail here.

Hmm... when placing a 2.7kOhm resistor between the output of a gate\flipflop and the RDY input of the TTL CPU,
the WAI instruction still might work...
but I'm not sure about what resistor value would be good for the W65C02, somebody would have to check.

;---

@Jeff:
That's a nice schematic, and I think this will work. //wait-state generator with OE + WE.png

Downside of this approach is, that there _always_ would have to be a wait state for generating the PHI2' signal,
even if the CPU is running at 1MHz in "slow mode".

But the only peripheral which needs /OE and /WE generated from PHI2' is the UART.
There won't be too much read/write cycles for the UART, so I think a little loss of speed there won't hurt...

Would say, that having waitstates for the ROM even if the CPU is in "slow mode" would simplify
the wait state generator circuitry for the SBC a lot... if Drass could live with this.

Edit: Dang !
If everything but the RAM would have a wait state, the 6522\6526 would have a wait state, too...
and I think this would generate two successive read cycles (or write cycles) to the same address on the chip.
This probably would give us _another_ problem.

[dwight]

Just a little thinking out side of the box.
Why use the processors wait. Why not just stall the
clock for both the processor and the peripheral.
Dwight

[Dr Jefyll]

dwight wrote:

Just a little thinking out side of the box.
Why use the processors wait. Why not just stall the
clock for both the processor and the peripheral.
Dwight

Yeah, definitely worth mentioning, Dwight -- that approach may require less logic than using RDY. There are downsides as well as upsides. Suspending the entire system distorts the timekeeping of devices which use PHI2 as a timebase, such as the timers in a 6522 VIA. But of course not all systems include such devices.

Another consideration: using RDY means the extra access time can only be an integer number of cycles. So if you needed 1.5 extra cycles, for example, you'd be forced to round that up to 2 cycles. By contrast, if you suspend the entire system you can do whatever you want. And here's another example where a fractional delay would've been desirable.

The circuit I posted allows, after the bus is stable, extra time before the peripheral's OE and WE go true, and it allows extra time for the actual period during which they are true. But I'd be happier if it also allowed extra time after OE and WE go false. Dunno if Drass's UART requires this extra time, but other vintage chips might (you need to consult the datasheet). Regarding OE it's plausible that the vintage peripheral won't let go of the data bus promptly when OE goes false. If the delay is large enough there'll be bus contention during the cycle *following* the peripheral access. And -- more critically -- the peripheral has a minimum spec regarding how long the data bus and the address bus must remain valid after WE goes false.

I didn't address this issue of delay after WE and WE go false. With many chips it won't matter, and finding out for certain requires some datasheet diving. Otherwise, seat-of-the-pants rules! If there's any issue then probably a fractional-cycle delay would be perfect. Just stick in an extra half-cycle after OE and WE go false. Of course an entire extra cycle would do the trick, but that's more of a performance hit.

ttlworks wrote:

@Garth:
Resistor with a 22pF capacitor in parallel sounds good.
The question now is: how big the resistor should be to make sure that the WAI instruction still works.

Hmm, if the capacitor is included then the resistor value is not so critical. I'm beginning to think this needs more thought (ie; a low value is still desirable). But without the cap you'd definitely want the resistor value to be quite low -- low enough to charge the capacitance of the RDY pin within the time available.

Garth, would you mind suggesting some actual part numbers of suitable capacitors? For some reason caps in the pF range seem to be quite esoteric and expensive.

-- Jeff

[GARTHWILSON]

For this application, even Z5U dielectric is acceptable. You don't need NP0 or anything else special. In thru-hole, Jameco has one for eight cents each in qty 10, and in SMT, down to one cent each for 4,000 (!). Mouser has them down to ten cents each in singles, and SMT ones down to six cents each in singles and $.007 (0.7¢) each for 10,000. It looks like Digi-Key is a little more expensive in singles. Still, most people on this forum probably won't be buying more than ten, so it's two or three bucks max, or well under a buck minimum.