CRC816, a modified CRC65 to host W65C816 CPU

[plasmo]

Now I've had a little experience with W65C816, it occurred to me that the existing CRC65 can be modified slightly to host a W65C816:
1. CRC65 has 128K RAM, but only 64K is used. A16 is currently tied to VCC. I can cut the trace to VCC and connect the latched data 0 to A16 resulting in 128K of RAM.
2. I remember the discussion about VDA & VPA where access to I/O needs to be qualified with VDA. So 65816's VDA output needs to be a part of the serial port decoding logic.
3. CRC65 CPLD has two pins that currently are allocated to I2C's SDA and SCL signals. I'll reassign these two pins as VDA and A16.
4. Pin 3 of CPU is unconnected currently. In W65C816 it is ABORT input, so it needs to be pulled up with a resistor.

I think that's all I need to change. Have I missed anything else?

Attached is schematic of CRC65, currently with W65C02.

Bill

[Dr Jefyll]

plasmo wrote:

I think that's all I need to change. Have I missed anything else?

The pin that used to be SOB (an input) will, on '816, become MX (an output). But I see you're driving SOB with nothing stronger than a pullup, so you're in the clear there.

Quote:

CRC65 CPLD has two pins that currently are allocated to I2C's SDA and SCL signals. I'll reassign these two pins as VDA and A16.

Hmmm, would you prefer to avoid reassigning CPLD pins? I don't have an easy answer for A16, but VDA is a signal you can consider simply ignoring. VDA does make for a nice, care-free coding environment, and for some folks that's that's a valuable consideration. But if, for you, conserving CPLD pins is more important, then fine -- adopting a few simple coding precautions will be sufficient protect you from the 816's dead-cycle behavior (which, after all, is no worse than that of the NMOS 6502). Both choices* are valid, IMO (I mean using VDA as opposed to exercising caution with your coding).

ETA: * depending on what I/O devices are present, you may in fact require neither.

-- Jeff

[plasmo]

Since I2C protocol comes in pair, once a signal is reassigned to latch D0 to form address 16, the other signal is not usable, at least not for I2C purpose. It may be repurposed to drive LED, possibly ws2812b LED. Having said that, I would like to know more about software practice to avoid the effects of dead cycle. My understanding is a dead cycle is a perfected formed read or write cycle except VPA and VDA are both low. I'm not worry about RAM, but the I/O I'm worrying about is the ACIA emulation inside the CPLD which has data and status registers that read-destruct, so a dummy read can cause data drop out. What coding practice may I use to avoid dead cycle to I/O registers?
Bill

[Dr Jefyll]

plasmo wrote:

What coding practice may I use to avoid dead cycle to I/O registers?

6502 "dead cycles" come in various flavors, most of them innocuous. For example, PLA, PLX, PLY etc have a dead cycle that reads from the next available (ie, unused) stack location before reading the desired value. But this particular dead-cycle foible, like most, is unlikely to disturb I/O.

By far the #1 cause of trouble is the dead cycle that can occur during indexed addressing. If a page crossing occurs, a Partially Formed Address (PFA) can appear on the bus. It's partially formed in the sense that the low byte of the address is correct, but the high byte doesn't yet account for the carry that needs to occur. Thus, the dead cycle can spuriously read from an address that's $100 below the one that was intended... and, where certain I/O devices are concerned, reads can be destructive.

The solution is simple enough. Just avoid indexed addressing of an effective address that's $100 above your I/O. If you're afraid you might forget that rule, you can leave that space unused, or fill it with something that won't get indexed into.

The other foibles are arguably quirkier, but understanding them is arguably less important because they're far less likely to cause trouble. For example, a Read-Modify-Write instruction accesses the target address on three consecutive cycles, and you'd expect two reads followed by a write... but 6502 will do a read, then write the unmodified value back, then write the modified value. I don't think any 65xx-family I/O devices will be bothered by this, but as I recall someone here got bitten while using a non-65xx I/O device that wasn't okay with being written to on two consecutive cycles -- its specs called for some intervening recovery time. The remedial coding practice is, don't use R-M-W instructions on I/O devices.

Sorry I have not provided a comprehensive list, but I personally am comfortable with being on the lookout for this sort of thing. But if I'm wiring up an '816 and it's easy to make use of VDA (and often it is *VERY* easy) then I'll do so.

For more on the causes of dead cycles, see the document here.

-- Jeff

[plasmo]

Thanks you for the detailed explanation of the dead cycles. I did decided to use VDA to qualify the I/O access because I'm concerned about how third-party software deals with dead cycles. Good thing about CPLD is I can easily reprogram it and reuse the VDA signal for other purpose.

Because I need to cut traces underneath SMT RAM, I built up a new board for CRC816. The required modifications are minor and I'm able to run W65C816 in emulation mode passing memory diagnostic and run mandelbrot benchmark in EHBasic.

This will be a good platform for me to learn W65C816 in native mode.
Bill

[plasmo]

The discussion about "strange W65C816 outputs" give me an opportunity to explore 65816 using CRC816. While in 65816's native mode, the instruction REP #$30 will drive MX output low and the instruction SEP #$30 will drive MX output high. So MX output can be bit banged with these two instructions. An application where timing is not too critical is bit banging the serial transmitter. Since CRC816 is running at 14.7MHz it is easy to bit bang serial transmit at 115200 baud. The program is already described in this posting. Below is a photograph of 2nd serial port transmit hooking up to pin 38 (MX) of W65C816.

Coming up next is bit banging WS2812 which is more challenging because of the tight sub-microsecond timings.

Bill

[plasmo]

In this posting Sheep64 talked about using 65816's MX or E output pins to drive WS2812. I've had previous experience bit bang WS2812 with Z80, but only recently became familiar with few extended 65816 instructions that dealt with MX and E. In previous post I was successful bit bang serial transmit with MX. In this post I'll describe how to bit bang the WS2812 with MX output.

Each WS2812 needs 24 pulses where first 8 pulses represent the intensity of the green LED; next 8 pulses represents red LED; and last 8 pulses represents the blue LED. When multiple WS2812 are cascaded (1st WS2812's Dout connects to 2nd WS2812's Din, or in general, n's Dout connects to n+1's Din), each WS2812 consumes 24 pulses and passes remaining pulses to the next WS2812.

Each of the 24 pulses is nominally 1200nS long where '0' is represented by 400nS high and 800nS low pulse and '1' is represented by 800nS high and 400nS low pulse. Another word, "0" is 33% duty cycle while "1" is 67% duty cycle of 800KHz pulse train. The pulse duration is not too critical, the datasheet calls for +/150nS over nominal values.

CRC816's system clock is 14.7MHz, so each clock is 68nS. 400nS equals 6 clocks so there are not much time to decide whether to turn on or turn off pulses. Fortunately the pulse duration is not too critical so this sequence of code generates "0" pulse of 340nS high duration and "1" of 800nS high duration.

Code: Select all

	ROL A		;MSB first
	SEP #$30	;first 6 clocks is always high
	BCS bit7Hi
	REP #$30
	NOP
	NOP
	NOP
	BRA showBit6
bit7Hi:
	NOP
	NOP
	NOP
	REP #$30
	NOP
showBit6:

	REPEAT THE ABOVE CODE 7 MORE TIMES 

Attached is the test program that drives the cascaded WS2812 8x8 matrix in the picture.

[plasmo]

Merry Christmas!

[BigEd]

Merry Christmas! A nice use of an RGB panel!