Hi Guys:

Just wondering what you think about using an 8-pin PIC microcontroller as a general purpose CPU and ACIA clock source for home-brew projects? I imagine that using a PIC which needs to be programmed could be a deterrent for some. On the other hand, it's a relatively inexpensive device (92¢, single quantity @ Mouser) and it's a relatively small circuit, using about the same amount of board space as a half-size crystal 'can' oscillator.


Theory of Operation

The 12F1501 device contains a PWM module which can be used to generate a 1-MHz or a 2-MHz square wave from the 16-MHz oscillator frequency, as well as a pair of CLC (Configurable Logic Cell) modules which can be configured as D Flip-Flops and used to generate an 8-MHz signal (using a single CLC flip-flop) or a 4-MHz signal (using both CLC flip-flops) from the 16-MHz oscillator frequency. The 12F1501 firmware uses the PWM module when a 1-MHz or a 2-MHz clock output has been selected, or it uses the CLC1 module configured as a D flip-flop for an 8-MHz clock output, or it will use both the CLC2 and CLC1 modules as cascaded D flip-flops for a 4-MHz clock output.

The PIC 12F1501 also contains an NCO (Numerically Controlled Oscillator) with a 20-bit Phase Accumulator and a 16-bit Increment register. While 32-bit Phase Accumulator and Increment registers would be better, accuracy should be good enough to use as a 16X baud rate clock for a 6850 or similar ACIA device with a very respectable ~0.2% bit error rate. Unfortunately, the Phase Accumulator and Increment register bit widths limit us to an upper NCO output frequency of ~500-kHz which means we can't really use the NCO to produce a 16X bit rate clock for any "standard" baud rate above 19200 baud (bummer!).

Quick-n'-Dirty Summary

I'm working on 12F1501 firmware now and I hope to post some code soon (if anyone is interested). If you have a PIC programmer that supports the 12F1501 and you're interested in this project, you might want to order some 12F1501 (8-pin) and 16F1503 (14-pin) samples to have on hand.

Cheerful regards, Mike

Michael:

Couldn't determine the upper frequency limit from your description; downloaded the datasheet and noted that the NCO's phase accumulator is 20 bits rather than 24 bits as described. From that, I can see why the upper NCO output is 500 kHz = 16 MHz * (65,536/1,048,576) / 2.

I've used NCO's in place of the normal dividers in my own UART designs in the past. A 16-bit phase accumulator is just fine in most cases. Microchip's implementation would have been much better if they allowed the phase increment value to be shifted left. (A little PRNG noise in the LSBs of the phase accumulator would also be nice to have. )

As it stands, the NCO provides fine frequency resolution (~15.258 Hz @ 16MHz), but limits the upper frequency as you indicated. I would find a 19200 bit rate a bit too limiting. All in all, a very interesting little peripheral function for an inexpensive microcontroller.

Thanks for pointing it out.

_________________
Michael A.

I've just this afternoon finished debugging something very similar using a PIC 12F1822 which I hope will get my W65C134 project moving again.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Sorry for the confusion... Thanks for pointing out my error which has been corrected in the original post...

I look at this sort of thing as a time tradeoff situation. Is the time spent on getting the PIC to generate the desired frequencies less valuable than the time required to squeeze an extra can oscillator onto the PCB?

Aside from the mechanics of the situation, can you live with the limited baud rate clock (BRC) frequency? I know I couldn't. I'm currently running both serial ports on POC V1.1 at 115.2Kbps, and have tested channel B at 230.4Kbps. These speeds are achievable only by driving the clock input to the DUART at 3.6864 MHz.

For developmental purposes, being able to fiddle with the Ø2 clock rate via software is interesting and useful—if done right, you presumably wouldn't have to reboot the machine just to change Ø2. So in this respect, using the PIC as the Ø2 generator seems logical. Being able to do the same with the BRC doesn't seem to be all that useful. There's usually no compelling reason to run a non-standard BRC, since TIA-232 devices operate with fairly strict timing deadlines. I do know that deviating significantly from the 3.6864 MHz clock will cause the 26C92 to misbehave, as its state machines are slaved to that clock.

I built both POC versions with a separate can oscillator for each function. The BRC is fixed, so that oscillator can be soldered directly to the PCB. I did socket the Ø2 oscillator, though, so I could try different frequencies while "shaking down" the unit. It's currently 20 MHz (driving a flop), and I haven't changed it in over a year.

Speaking of POC V1, UARTs and such, I'm considering doing one more design iteration to V1 before I put in on the shelf, and that is to use an NXP 28C94 QUART in place of the 26C92 DUART in the current unit. The 28C94 is functionally two 26C92s in one PLCC-52 package and will give me four high speed TIA-232 channels, three of which will be available for external communications purposes.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I've been playing with this approach to minimize component count. With one 8 pin PIC I can eliminate two crystals (plus the supporting resistors and caps) and have the equivalent of an econo-reset.

I don't need high speed serial so letting the W65C134 derive its UART clock from 4/8 MHz is fine (and exactly what the WDC reference design does).

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Yes, but a half-size can oscillator takes up no more room than a crystal and requires no other components, other than a bypass cap.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Good point, but, time spent was a fun learning exercise for me.


I think 9600 baud or 19200 baud will work fine for the one or two projects I have in mind. While digging around through my old inventory I found an old 200-nsec Xicor 32Kx8 EEPROM, a 68A50 ACIA chip, an Apple NMOS 6502, and a couple 15-nsec 32Kx8 SRAM chips so I thought it might be fun to make a copy of Grant's recent "minimal" BASIC computer design.


This tiny 12F1501 based sub-system isn't for everyone. Admittedly, the main design goals are cost and squeezing as many features as possible into a relatively small amount of board space.


That's pretty neat. I've enjoyed studying your POC design.


Cool! I'm sure I'm not the only here who would love to see the next incremental POC design.

Cheerful regards, Mike

Hi Andrew:

I understand where you're coming from. I really enjoy optimizing designs (and code), too.

I hope you'll let us know how your W65C134S project progresses. Perhaps your efforts will help me figure out why I can't get my W65C134S project running.

Cheerful regards, Mike

I’m not familiar with PIC’s, but an ATtiny2313A (€0,95). has a dedicated system clock out pin which passes through the provided full clock speed or divided by 2,4,8..256. Having a crystal of 14,7456MHz, you can create various desired clock speeds like 14,7456 / 7,3728 / 3,6864 / 1,8432 / 0,9216 MHz. However, I’m not sure of the quality of the derived square wave.

Besides reset, it should also be possible to achieve a single-step, single-cycle and CPU-halt functionality. (using the SYNC signal on an external interrupt pin)

IMHO using a microcontroller for such tasks depends on the situation. If an AVR (or the like) is already used on the system, why not get the most out of it? Another advantage, you don’t have to keep that much different crystals / oscillators in stock.

_________________
Marco

You'd have to use a very fast micro-controller to be sure of catching the signals. Its probably easier to use a GAL containing the run/stop/stepping logic under the control of a slower micro-controller which interprets the bus and control signals.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

You’re right, I only tried successfully a CPU-STOP on the VIC-20 running at ~1MHz. while the AVR was running at 16MHz. So nothing with higher speeds than 1MHz, I see your point…

_________________
Marco

I agree, though I don't think I'd put SYNC on an interrupt. Instead, I would add <run/stop> and <step> push button switches to the PIC, along with a jumper to select either 'single-cycle' or 'single-instruction' mode and I would connect the SYNC signal to a plain old PIC input pin. Pressing the <run/stop> push-button switch would toggle a flag which would indicate either "run" mode or "stop" mode. While in "run" mode, the PIC supplies a full speed PHI0 clock via the PIC PWM module. When the PIC program detects a change from "run" mode to "stop" mode, I would set the PWM duty cycle to 100% to temporarily hold the PHI0 output pin high, then I would switch over to manual control of the PHI0 output pin. While in "stop" mode, each new press of the <step> push button would output a single PHI0 clock (single-cycle jumper setting) or output multiple PHI0 clocks (single-instruction jumper setting) until detecting the SYNC signal. Also, while in "stop" mode, it would be relatively easy to read the 65C02 address and data bus into the PIC at the appropriate time within each PHI0 cycle and output the values to a display or terminal. Finally, when another <run/stop> push button press puts us back into "run" mode, I would return control of the PHI0 output pin back to the PIC PWM module and set the duty cycle to %50 to resume full speed PHI0 output.

Regards, Mike

In theory perhaps you and I are right, and if I’m not mistaken, for a 1MHz system that would likely work if the AVR or PIC is running fast enough(16 or 20MHz). However, I believe what BitWise is saying, is that a PIC or AVR isn’t fast enough to detect and react on the 6502 / W65C134S BUS signals. With a faster system it simply wouldn’t work.

So a GAL or CPLD would be the way to go because they are fast enough.

_________________
Marco

A 16MHz PIC would have only two instruction cycles per half cycle of a 1MHz 6502, probably not enough to do anything useful. A one-word forward conditional branch on a PIC takes two of these instruction cycles (8 clocks), and a longer one takes two instructions and three instruction cycles (12 clocks); so if the PIC has to watch for a condition on even a single bit and branch on it, it's already out of time before doing anything useful.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?