65816 and RDY problems

[fachat]

Hi there,
I have built my Micro PET and I wanted to switch from stretched phi2 clock to RDY-based wait states, so the VIA timers count a regular clock, not the stretched clock.
It runs fine with RDY output, and stretched clock - only when I switch stretched to normal clock, it stops working.

My assumptions / understanding from the datasheet:
- RDY is sampled shortly before the falling edge of Phi2
- My RDY is defined at the rising edge of phi2 when the access should be delayed, and released after the following rising edge of phi2 (in the code it's the inverted of wait_int_d)
- So RDY covers the fully Phi1
- When I stretch the clock, I simply OR phi2 with the inverted RDY (ie wait_int_d)

you can have a look at the attached screenshots of the code and the scope shots.

The change in "phi2_out" is the _only_ change, and phi2_out is _only_ used to create the phi2 output (while phi2_int is the stretched clock and is used internally for all the accessed)

Code is found on github: https://github.com/fachat/MicroPET/blob ... LD/Top.vhd

I am really running out of ideas. Any help is appreciated!

Thanks
André

Edit: in the code, the "test" signal is an input I have jumpered constant high, as memclk is a clock net and can not be assigned to an output (and the optimized tries to optimize everything trivial away)

[BigDumbDinosaur]

fachat wrote:

I have built my Micro PET and I wanted to switch from stretched phi2 clock to RDY-based wait states, so the VIA timers count a regular clock, not the stretched clock.
It runs fine with RDY output, and stretched clock - only when I switch stretched to normal clock, it stops working.

My assumptions / understanding from the datasheet:
- RDY is sampled shortly before the falling edge of Phi2
- My RDY is defined at the rising edge of phi2 when the access should be delayed, and released after the following rising edge of phi2 (in the code it's the inverted of wait_int_d)
- So RDY covers the fully Phi1
- When I stretch the clock, I simply OR phi2 with the inverted RDY (ie wait_int_d)

you can have a look at the attached screenshots of the code and the scope shots.

I'm a little confused here. Why have a stretched clock if you are using RDY?

We have had discussion around here on the clock-stretching method as a complete alternative to using RDY to wait-state the MPU. There are several issues with use of RDY for that purpose, especially with the 65C816, the theory behind which I presented a while ago. Note that these clock-stretching methods are based upon discrete logic, but can be implemented entirely in a CPLD if that is your source for the Ø2 clock (which is not something I would do).

Jeff's discussion on clock-stretching.

My discussion on clock-stretching.

[fachat]

BigDumbDinosaur wrote:

I'm a little confused here. Why have a stretched clock if you are using RDY?

The main reason is that the system should be able to act like a 6502 Commodore PET running at 1 MHz. So in 1MHz mode I am stretching the internal ~8MHz clock across 8 cycles, to achieve 1MHz clock frequency, although very asymmetrical.

I still have an 8MHz clock internally, to get the memory accesses fast enough to produce the video output. At 1MHz there is enough space to interleave video access to memory with CPU access.

Quote:

We have had discussion around here on the clock-stretching method as a complete alternative to using RDY to wait-state the MPU. There are several issues with use of RDY for that purpose, especially with the 65C816, the theory behind which I presented a while ago. Note that these clock-stretching methods are based upon discrete logic, but can be implemented entirely in a CPLD if that is your source for the Ø2 clock (which is not something I would do).

Phi2 is indeed generated by the CPLD. At full speed I actually want to run the "system" at 8MHz straight, and then use RDY to steal cycles from the CPU. The reason here is that the VIA timers then count proper 8MHz clock cycles and are not impeded by clock stealing. However, I still need to steal cycles from the CPU to display for displaying video output. See here https://www.youtube.com/watch?v=egORnK1ZwBg
Unfortunately, it is not working as described above.

Quote:

Jeff's discussion on clock-stretching.

My discussion on clock-stretching.

Thanks for the links, I'll have a look!

[BigDumbDinosaur]

fachat wrote:

Phi2 is indeed generated by the CPLD...

A problem with using PLD outputs as a clock source is most of the available PLDs generate TTL levels on their outputs. WDC's clock specs require a CMOS-compatible Ø2 signal, so the potential exists for malfunction.

[fachat]

BigDumbDinosaur wrote:

fachat wrote:

Phi2 is indeed generated by the CPLD...

A problem with using PLD outputs as a clock source is most of the available PLDs generate TTL levels on their outputs. WDC's clock specs require a CMOS-compatible Ø2 signal, so the potential exists for malfunction.

That's been taken care of. There is an application note for Xilinx CPLDs how to drive 5V signals: push high until the CPLD notices that same pin as high input, then let a pull-up resistor do the rest. The system runs fully reliable with that. You see the Phi2 result on the scope shots above.

André

[BigDumbDinosaur]

fachat wrote:

You see the Phi2 result on the scope shots above.

Question aside from the clock signal. I see you are photographing the 'scope display. Doesn't Rigol offer a way to output the display through a port as some sort of image you can store on a computer?

[fachat]

BigDumbDinosaur wrote:

fachat wrote:

You see the Phi2 result on the scope shots above.

Question aside from the clock signal. I see you are photographing the 'scope display. Doesn't Rigol offer a way to output the display through a port as some sort of image you can store on a computer?

Yes it can. IIRC it is overly complicated and/or involves some Windows software that I don't use. I did it one time at least...: http://www.6502.org/users/andre/icaphw/ ... index.html

I should probably try this at some point: https://github.com/rdpoor/rigol-grab

[fachat]

Btw, some update. I still haven't got the RDY stuff working - most likely it needs a pull-up resistor similary to phi2 to create a good quality signal (interestingly the data bus that presents data read from memory does not seem to need this). I'll probably check that over the weekend if I get the time.

However, I managed to get the VIA timer running at proper speeds while the CPU is waiting for slow memory / read conflicts with video, using a split phi2 clock. I.e. CPU gets a stretched phi2, VIA gets a normal phi2.

I got the idea from your discussions, so thank you!

[BigDumbDinosaur]

fachat wrote:

Btw, some update. I still haven't got the RDY stuff working - most likely it needs a pull-up resistor similary to phi2 to create a good quality signal (interestingly the data bus that presents data read from memory does not seem to need this). I'll probably check that over the weekend if I get the time.

I am convinced that the 65C816's control inputs are CMOS-compatible, but the data bus is TTL-compatible. This is based upon my observations of my POC units, which use ROM and SRAM whose outputs are TTL-level. The current version of POC, V1.2, runs at 20 MHz using a 27C256 EPROM and an ISSI 128KB SRAM, both devices whose outputs are TTL-level. There are no pull-up resistors on the data bus. I doubt stable operation would be possible if the 65C816 insisted on having the data bus driven to CMOS levels.

PLDs generate TTL-level outputs, but RDY won't think it's at a logic 1 unless driven to around 4 volts minimum (per the data sheet—the threshold seems to be around 3.6-3.7). BTW, don't forget RDY is bi-directional and should not be solidly driven to Vcc at any time. A series Schottky diode and pull-up will assure proper operation.

[fachat]

BigDumbDinosaur wrote:

fachat wrote:

Btw, some update. I still haven't got the RDY stuff working - most likely it needs a pull-up resistor similary to phi2 to create a good quality signal (interestingly the data bus that presents data read from memory does not seem to need this). I'll probably check that over the weekend if I get the time.

I am convinced that the 65C816's control inputs are CMOS-compatible, but the data bus is TTL-compatible. This is based upon my observations of my POC units, which use ROM and SRAM whose outputs are TTL-level. The current version of POC, V1.2, runs at 20 MHz using a 27C256 EPROM and an ISSI 128KB SRAM, both devices whose outputs are TTL-level. There are no pull-up resistors on the data bus. I doubt stable operation would be possible if the 65C816 insisted on having the data bus driven to CMOS levels.

Indeed that seems to be the case. Using a pull-up and the same logic as used with Phi2 on RDY work to run the CPU with 1 MHz, on an 8MHz phi2, with slowdown using RDY. (as explained above, CPLD pulls up (fast) until it notes the input of the same signal as high, then goes high-Z and let the pull-up do the rest. Looking at the scope also reduces ringing considerably)

Quote:

PLDs generate TTL-level outputs, but RDY won't think it's at a logic 1 unless driven to around 4 volts minimum (per the data sheet—the threshold seems to be around 3.6-3.7). BTW, don't forget RDY is bi-directional and should not be solidly driven to Vcc at any time. A series Schottky diode and pull-up will assure proper operation.

Good point. I think I will be going with stretched / split clock here, and consider RDY as in output signal of the CPU only, to avoid any hassle (and reduce number of parts, pull-up and diode as you mention).

Thanks again
André

[BigDumbDinosaur]

fachat wrote:

Good point. I think I will be going with stretched / split clock here, and consider RDY as in output signal of the CPU only, to avoid any hassle (and reduce number of parts, pull-up and diode as you mention).

VPB on both the 65C02 and 65C816 can be useful as well. With advanced logic, VPB could be use to tell the logic to escalate privileges due to an interrupt being serviced, much like the supervisor mode of the MC68000.

[Chromatix]

VPB can also be used to inject the address of a specific IRQ handler onto the bus, for use with interrupt controllers that recognise distinct IRQ inputs. That can potentially reduce IRQ latency since the handler no longer needs to search through all possible IRQ sources for one that is active.

[Dr Jefyll]

BigDumbDinosaur wrote:

[...] the data bus is TTL-compatible. This is based upon my observations of my POC units, which use ROM and SRAM whose outputs are TTL-level.

Unlike vintage 65xx CPU's such as Rockwell, whose inputs are specifically tailored to receive TTL levels, modern WDC CPU's have inputs which make no accommodation for being driven at TTL levels. A quick comparison of Rockwell and WDC specs confirms this, as do the results of some controlled experiments which I'll write up soon. Edit: done.

BigDumbDinosaur wrote:

I doubt stable operation would be possible if the 65C816 insisted on having the data bus driven to CMOS levels.

This reasoning would be logical only if we were certain your EPROM and SRAM fulfill the spec for a TTL high without exceeding it. But in fact it's entirely routine for ROM and SRAM to exceed that spec, and that's what enables the '816 in your POC to function -- it actually requires the other chips to exceed the TTL spec. And of course that's not guaranteed -- the amount of undocumented leeway may be as small as zero.

Noise immunity is sharply or even fatally reduced, as compared to using a truly TTL compatible '816 (were one available * ). Thus your success depends on luck and circumstances -- much the same theme you yourself invoked in a different context here:

BigDumbDinosaur wrote:

if it's a production item you need to design for worst-case. If it's a hobby unit, you can design less conservatively, knowing there may be a case where it won't work.

-- Jeff

Edit: * - apparently GTE produced such an animal back in the day. But modern WDC parts are a horse of a different color.