Second Steps (Building R0)

[GARTHWILSON]

I'm watching this with interest, wanting to know what really happens. I have a 65c02 fixture for checking logic states at each half cycle, and I could modify it for an '816, but I can't take the time now. I have too much on my plate.

Terminology is causing some confusion here though. cr1901, note that pulling RDY low is just slow memory telling it, "Hold on-- I'm not ready yet. I need more time. Please hold the current state longer." So asserting it means pulling it up, meaning, "Ready! No need to delay further. I got the data out. Move on!" Pulling RDY down means negating it, not asserting it.

[cr1901]

I wish WDC offered technical support for ambiguities in their datasheet. God knows enough of them accumulated over the years.

[GARTHWILSON]

WDC recommends this website and forum, but I wonder if anyone there reads it regularly. I doubt it.

[Michael]

GARTHWILSON wrote:

I'm watching this with interest, wanting to know what really happens. I have a 65c02 fixture for checking logic states at each half cycle, and I could modify it for an '816, but I can't take the time now. I have too much on my plate.

I wonder if my PIC based test jig was similar in function? Lacking an oscilloscope or logic analyzer, I hooked up the address lines, data lines, and control lines to the PIC and sampled the various signals at 62.5-nsec intervals during each half clock cycle. Collected data was dumped to Hyperterminal over the PIC serial port. The information gained from those tests would lead to a method that allows the PIC to push/pull instructions and data to/from the 65C02 over the data buss for the "blind loader" in my little three chip pocket computer. I can't imagine why you couldn't do something similar on a 65C816.

Regards, Mike

[GARTHWILSON]

Michael wrote:

I wonder if my PIC based test jig was similar in function.

I made mine to work with my 6502 workbench computer. Rather than trying to catch data while the processor is running at speed in its own system, it interfaces to only the processor and makes the processor think it's in a computer system while really it's all being faked, and it's slowed down so the workbench computer executes many, many instructions (potentially thousands) for each half cycle of the processor being tested. The workbench computer decides when to give it the next clock edge, pull down or release IRQ\, NMI\, RST\, RDY, etc.. The status of every signal pin is printed for every half cycle. Obviously it would need a CMOS processor that won't lose info if stopped. I did it years ago to check details that weren't in the data sheet.

[cr1901]

A small diversion:

chessdodger... In light of Joachim's computer using only discrete components, I may cave and buy a PLD, since the motivation to do pure discrete components has faded a bit. What type of programmer do you use, and was it expensive (triple digits or more)? I just in general cannot justify the cost of a programmer, and unlike for microcontrollers, the protocols to program them, and CPLDs aren't really documented.

As FPGAs and microcontrollers are often reprogrammed/bootstrapped, these protocols are better documented (usually a variant on SPI/start-stop or some sort).

[Dr Jefyll]

I wrote:

The text fails to be explicit on this point.

cr1901 wrote:

Page 53 of WDC's current datasheet (Caveats):
7.6 DB/BA operation when RDY is Pulled Low
When RDY is low, the Data Bus is held in the data transfer state (i.e. PHI2 high). The Bank address
external transparent latch should be latched on the rising edge of the PHI2 clock.

Thanks -- I overlooked that. Posting too close to bedtime, I guess. But the caveat seems more contradictory than clarifying.

Quote:

ARGH!

Yes, exactly!

GARTHWILSON wrote:

I have a 65c02 fixture for checking logic states at each half cycle

Straight from the horse's mouth, eh? I'd much rather have experimental data, since the datasheet is so murky.

The test fixture sounds ideal, but dedicated hardware isn't necessary in this case. Anyone who has an '816 running in an existing machine could run the experiment. It'd be easiest if the RDY pin is presently unused. Jumper it to an output taken from a pin on your 6522/whatever, then run code that pulls the 6522 pin low. The resulting wait-states repeat forever, so you can examine the waveforms at your leisure.

[chessdoger]

cr1901 wrote:

A small diversion:

chessdodger... In light of Joachim's computer using only discrete components, I may cave and buy a PLD, since the motivation to do pure discrete components has faded a bit. What type of programmer do you use, and was it expensive (triple digits or more)? I just in general cannot justify the cost of a programmer, and unlike for microcontrollers, the protocols to program them, and CPLDs aren't really documented.

As FPGAs and microcontrollers are often reprogrammed/bootstrapped, these protocols are better documented (usually a variant on SPI/start-stop or some sort).

Hi

I have both of these programmers ..G540 and wellon vp290 .. can get both from china .. I got the vp290 from darkwire
http://www.darkwire.com.au/html/device_programmers.html

G540 is cheaper $70's Au..should program plds ..found VP290 much better but about $170 or so ..
I know that VP does work with atmel 24pin din chips .. so if you can spare the money go for them ..although I know some other people have used the g540 ..however they used the lattice chips which I think require different type of compiler software.

Pld software like wincupl is not the easiest ..but once you get the idea there is not much to them.

Anyway if you ever need a hand in future ..let us know ..happy to help ..

I usually post the pld files on the website ..so you can see the code .. and from that it is not that much different if you require to say alter the address range .. and make up your own ...etc

mike

[cr1901]

Ty for chessdoger... I may take you up on that .

In any case, I hope someone with a '816 design can test. I really do not have provisions to test a prototype circuit, and until I can figure out what the behavior is, the project is once again at a standstill.

The devil is in the details with this chip. Designs with '816 are moderately more involved than an equivalent '02 design- and yet I still underestimated the difficulty (there are other issues re: the datasheet that I wish to discuss later) .

[cr1901]

I created a circuit that attaches to the GPIO/I2C bus of my Raspberry Pi that probes the bus of the 65816, making sure to switch bus direction between PHI2 low and PHI2 high. There IS bus contention in my circuit for a short period when the bus switches from read data back to write bank, but so far I haven't had any issues doing probing with my setup.

Control signals PHI2, RDY, RWB, VDA, VPA, and RESB are attached to the Raspberry Pi GPIO port.
The bank/data bus is connected to PCF8574 I2C I/O expander. It has push-pull output (whatever that means), and output is as simple as writing the required value to the device. Input is implemented by writing a logic 1 to each pin for the I/O device. It's up to other devices, in this case the Bank/Data bus, to drive the bus when the I/O expander is in input mode. I only switch the I/O expander's direction to output (CPU read) when PHI2==1 and RWB==1, and switch it back to input when PHI2==0.

I wrote a program on my Raspberry Pi to monitor the data bus and control signals, toggling the PHI2 GPIO to simulate single-stepping to probe the bus. My Pi runs NetBSD (that's a discussion for another time), so unless some of you use that instead of Linux, my program isn't exactly ready to be used by others who want to experiment . Therefore, I'll hold off on the circuit diagram/source code for now.


The answer to my question conclusively: The 65816 does NOT drive the bank address while RDY is low. Therefore, there must be some means to prevent a new garbage bank address from accidentally being latched. The big hint for me is that the I/O expander sees the value 0xFF when RDY==0 and PHI2==0. This indicates the bus is not being driven, so the I/O expander goes into pullup mode (or whatever the equivalent is for push-pull).

If RDY is driven low during PHI2 high, the '816 will NOT drive a bank address onto the bus during the next PHI2 low.

If RDY is driven low during PHI2 low, a read during PHI2 high will occur as normal, and during the same situation as above applies. Have not tested writes yet.

If RDY is driven high during PHI2 high, the '816 WILL drive a new address onto the bank bus during the next cycle. Obviously, the I/O device better in fact be ready, and have some breathing room to satisfy setup time. Otherwise it is probably best to drive RDY high while PHI2 is low.

If RDY is driven high during PHI2 low, a read during PHI2 high will occur as normal, and the '816 WILL drive a new address onto the bank bus during the next cycle.

Here is some sample output. RDY changes directions before PHI2 is toggled on any line with an 'r':

Code: Select all

PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: E8
r
PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: FF
PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: E8
r
PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0
PHI2 1, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: 0
r
PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: E8
PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: FF
r
PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: E8
PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0

Something else is bothering me about my setup however... according to what I'm seeing from my program, NOP is in fact 4 cycles on the '816, not 2! o.0; And I don't think it's an error either, b/c other Implied address mode instructions, such as INX (see above- 0xE8), are 2 cycles in length. Something's very wrong... or something very interesting is happening.

EDIT: Ignore the above paragraph- I miswired/swapped D2 and D1... so 0xEA (NOP) was in fact 0xEC (CPX absolute) XD. Taking that into account, the behavior I saw (4 cycles, emulation mode) makes sense. Above results are not affected since D2==D1==0 in 0xE8.

[BigEd]

Thanks for doing the experiment and letting us know!

[Dr Jefyll]

BigEd wrote:

Thanks for doing the experiment and letting us know!

Yes, indeed -- thanks, cr1901! Good to have the doubt removed.

[cr1901]

BDD's solution will work for fixing RST, but I'm trying to determine whether I can't reduce the prop-delay from his implementation to keep 14MHz operation with discrete components.

Thinking about buying a GAL programmer. I'd like to do a design without using GALs, but again, since Joachim's design of his first SBC proves 14MHz operation is possible with 74xx glue logic, I feel less obligated to do that now.

Additionally, fun fact: I do not have the funds for an EPROM programmer either. If it weren't for a generous donation from a professor back in 2011 (Needham's PB-10 ISA card- currently in my 286), I wouldn't have an EEPROM programmer, and would have to find some makeshift solution to program EEPROMs or something. Making my own GAL programmer doesn't seem all that appealing either.

If I decide to go this route for the time being, would someone be willing to program a few GALs for me if I give them a design (chessdoger... I live in the US, so I'm not sure how much it would cost to mail a letter or manila envelope with GALs inside)? Payment is offered for your trouble/reduced stock .

[nyef]

cr1901 wrote:

Thinking about buying a GAL programmer. I'd like to do a design without using GALs, but again, since Joachim's design of his first SBC proves 14MHz operation is possible with 74xx glue logic, I feel less obligated to do that now.

Note that Joachim's design uses 74F logic, which is old, power-hungry, and fast. As in, worst-case prop times lower than ACT, and power usage measured in mA rather than uA.

[BigDumbDinosaur]

cr1901 wrote:

BDD's solution will work for fixing RST, but I'm trying to determine whether I can't reduce the prop-delay from his implementation to keep 14MHz operation with discrete components.