I purchased two W65C134S8PLG-14 to find out whether it can run 14MHz or more. This is a test board for it. It is W65C134 surrounded by a CPLD and an external RAM. I'll start off with configuration similar to W65C134SXB, the evaluation board from Western Design. I see whether it will boot by itself first then go from there.
Bill

So I tried 3.68MHz and see the sign-on message at 14400 bps. Then I tried 14.7MHz and see the same sign-on at 57600 bps, then I tried 16MHz and see somewhat corrupted sign-on at 57600 (16MHz translate to 62700bps, about 8.8% error from 57600, so that's about right). It won't boot at 18.432MHz. So I guess the top frequency running with internal flash is about 16MHz.
Bill

Good to see one going, but ... Hm. Odd.

At boot-time the internal ROM tries to calculate the main clock speed then uses a look-up table to set the baud rate. It knows about these speeds:



Any xtal speed outside this will/should result in garbage... But it's most odd that you get 14400 with the 3.6864 Mhz oscillator.

The code sets a timer going on the 32K crystal then runs software loop and uses the count from the loop to index a table with a set of pre-computed values for the loop time it then uses this idex to get one of those values which is then uses to index into a set of tables to get the values to put into the timer that controls the ACIA.

If it doesn't find a match then it assumes it has a 2.4576 Mhz crystal.

That may explain why you get 14400 baud - that's 1.5 * 9600 and 2.4576 * 1.5 is 3.6864 so somehow it's not able to detect the frequency and defaulting to speed 2.

The 32K xtal you have - is it actually running? I don't see the load resistors or capacitors there... It must be doing something as it's required to boot the internal ROM, but at what frequency?

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I can measure 32.8KHz at the CLKOB output with scope, but I've notice the crystal needs a few seconds to reach stable frequency. That probably screwed up the initial ACIA calculation. However, manual reset after the crystal has stabilized still resulted in the initial 14400 bps solution. I've designed the 32.768KHz circuit based on W65C134 databook, but now I noticed the SXB board design is different than the databook. There may be sufficient differences in the 32.768KHz designs to cause calibration problems. I'm settling down to 14.7MHz operation which has 57.6K serial communication that's sufficiently fast.

My original plan was to abandon the on-chip ROM and use compact flash to bootstrap to external 128K RAM with four 32K banks, so I've not studied the SXB design. Now it boots with internal ROM, I'll work with it to get familiar with the internals of 65134, but that's just a stepping stone to the external memory solution.
Bill

Edit: measured the time against a kitchen timer over a minute. It is too slow by about 7%, so that's the reason for failed ACIA calibration. The crystal circuit needs an exclusion zone all around.

As I understand it, you have to pull BE low before (or at) the time you pull Reset low. Then B has to remain low for a number of cycles after Reset comes high.

However there seemed to be some ambiguity as to how long you keep BE low for - but as I abandoned the '134 at that point (Before I did my TinyBasic thing when I thought it might make a nice little system - the main point of contention for me was the ZP usage by hardware), I never took it further. My Tiny Basic system boots by writing the magic sequence into EEPROM at $8000:



When the on-board ROM detects this (Specifically the "WDC") it JMPs to $8004 and you go from there.

-Gordon



Or maybe just a separate can oscillator for the 32K one..

Here is a close-up of the WDC65c134-sxb board - not sure it helps though:



Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I’m very surprised to hear of something crystal controlled being 7% off - have I misunderstood?

It is my fault. crystal is high impedance and drive circuit is typically 100K or greater so it is susceptible to noise. The design normally calls for ground plane or exclusion zone around the circuitry. Well, I didn't do the shielding and that's why it is so badly off.
Bill

It is good to have the built-in monitor to explore 65134. So yes, it uses quite a bit of ZP space, but the "WDC " at $8000 is a good way to swap out the built-in monitor. I placed a 32K bank of RAM at $8000-$EFFF and another at $100-$7FFF. An intermediate solution is to load applications in high RAM and write "WDC " at $8000 to swap out the built-in monitor. I actually have to disconnect everything and ground the power/ground to erase the "WDC " signature from $8000.

ZP $30-$3F is assigned to chipselect 0 which is an easy way to add 16 bytes of I/O to ZP. Similarly $100-$11F is assigned to chip select 1 and $120-$13F to chip select 2. These are mechanism to assign small block of memory-mapped devices. Since I plan to bootstrap from CF, ZP $30-$37 are assigned to CF's 8 registers. I now have CF storage.
Bill

An update on the oscillator circuit. I know, through actual experiences, that it is important to shield the 32768 crystal circuit of DS1302 real-time clock or else the clock will drift significantly. However, the drift is in the order of 1%, so 7% for 65134's oscillator seems way off. There are two address lines running next to the oscillator so I cut off both lines and rerouted them. That made absolutely no difference in oscillator drift!

After good bits of cursing and hand wringing, I discovered I've made two mistakes in silk screen of the resistor/capacitor so they are swapped. It is a miracle the crystal even oscillate at any frequency! Fixed the mistakes and the clock is now accurate over a 4-minute interval. The serial port now boot to 9600 bps with 3.68MHz clock.
Bill

That's a good explanation and fix!

After playing with 65134 a bit, I like it. It is 65C02 capable of 14MHz operation (I clocked it at 14.7MHz); it has a serial port, 4 timers and large number of discrete I/O. It is like 65C02+6551+2x6522+4K_ROM. My prototype board surrounded the 65134 with a CPLD which is an overkill. I built another board without CPLD and wired in (without glue logic) 32K RAM from $100-$7FFF using 65134's chip_select_6 as RAM decode. Alternatively with a 64K RAM and a OR-gate combining chip_select 6 and 7, it can have RAM from $100-$FFFF. This is makes an I/O-rich, simple and fast 6502 computer for experimentation.
Bill

It certainly has fewer chips than my current design

Neil

What I'm settling down is a simpler W65C134 design without CPLD and CF. It has an OR-gate implemented with 2 Schottky diodes and a resistor. One input of OR is 65134's chip_select_7 and other input is chip_select_6 so that maps memory $100-$FFFF to RAM. RAM's active high chip select is wired to voltage supervisor so RAM is write-protected when voltage dropped below 4.5V.

The approach is using the factory ROM to load the new monitor into RAM. Write "WDC " to $8000 to disable factory ROM. RAM contents should be protected from corruption during reset or brief power cycling, but there will be a checksum routine to verify. The new monitor is the active monitor but need to be reloaded after a complete power cycle or when the application program trashed the monitor.

The approach is not very different than the factory 65134SXB board, but this has more RAM and higher 14MHz operation.
Bill

You can also write this 'signature' at $0200 - when the ROM will then JMP to $0204.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/