In my monitor, I'm needing more accurate timing. Mainly for controlled delays and dealing with the 65C51 transmit bug.

I'm currently just doing a silly loop and that works. But, obviously, the amount of time is different when I switch back to 1 MHz or 8 MHz.

What I'd like is a way of delaying an arbitrary amount of time. I'm not sure what resolution I would need. A resolution of a millisecond would be ideal but that might be pushing it on a 1 MHz machine. It doesn't really matter what it is as long as it's the same on all clock speeds and reasonably fast to allow granular delays.

My first guess was to use the timers on the VIA but I've never done that before. A RTC is not out of the question (or even a 555).

What are your suggestions?

Thanks!

_________________
Cat; the other white meat.

A VIA timer uses the CPU clock for its timebase, which means it has the same problem as a software timing loop. But both the VIA and the software loop could be used in a way that accounts for whatever the clock rate happens to be. You could declare a value representing clock rate, and always refer to that value before setting up the timer or loop.

Remember a loop won't offer interrupt capability. But maybe that's not a priority for you.

Would an RTC offer enough resolution for your needs? I seem to recall they generally track time in increments no finer than 1/100 second. Other timer chips are available, though -- the 8254 being a very highly flexible example. And, unlike a VIA, it accepts its input clock on dedicated pins.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Some RTCs have a programmable clock output, also an 8-pin microcontroller (e.g. ATtiny) running off it's internal oscillator could be programmed to output - say - a 1Khz clock. you could simply poll that in software - however that would give you a delay from 1 to 2mS depending how you're sampling the output - that would be the minimum delay, for anything longer, counting pulses then it's more accurate, so for 100mS, then it would be a minimum of 100mS and a maximum of 101mS. Obviously interrupts would lengthen the delay, but that's usually not a concern. Or run the clock at 10Khz - still very "samplable" by a 1Mhz 6502.

Alternatively - what I did a while back, conditional assembly and copied wait code out of the Apple II monitor... On a 1Mhz Apple II that's good for 13µS to 166mS - although it's a bit chunky in the steps.

-Gordon

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

the problem is where getting the values from the RTC takes longer than the delay you're looking for.

If it's that important, a combination of the RTC and a VIA timer, or just loop counting. You can do a quick "benchmark" at startup to discern what values to use at runtime, and load constants in the system.

The monitor in the '265 does this, but it had two clock sources -- CLK and FCLK, FLCK is the "fast (XX Mhz)" clock, CLK is a 32768hz clock. It uses the slow clock to figure out how fast the fast clock is.

If you have access to a high enough resolution alternate clock (like an RTC), you could use that. But if you have to slurp in the RTC values via SPI, then getting the data can be "expensive" for high resolution timing.

_________________
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?

Assuming° you are using the regular 1.8432 MHz clock for your 6551 and no external RxC than that pin (5 on DIL) reflects 16x RxC. Feeding this into PB6 of a VIA and use the pulse counting mode you can even generate an interrupt (out of the VIA) that would occur after transmission is done.


EDIT(1): with 1.8432 MHz the RxC should not exceed 115.2 kHz which can safely counted by a 1 or more MHz driven 6522.

Thanks everyone for the suggestions!

That's a good idea on the ACIA clock. He stays the same no matter which main clock I have.

_________________
Cat; the other white meat.

There's quite a few different solutions that can be used to resolve the W65C51 xmit bug. None are truly ideal as all become a band-aid for a defective hardware device. Still, if you prefer to continue using the W65C51, then you can add some hardware to use the baud clock output and create an interrupt driven solution that will yield a timer/counter.

You can then leverage the timer/counter for accurate and consistent delays, albeit your resolution will be tied to the baud clock itself. A jiffy clock should be easy enough to implement and would result in a 10ms timing interval. You need to determine what resolution of timing you need for your application (beyond the delay timing for the W65C51 transmit). Just realize that the interrupt service routine will spend some number of clock cycles there to handle the interrupt. The slower the CPU clock, the greater percentage of the CPU's time will be spent there. The other concern is the CPU time processing the delay and any added time due to execution of instructions, which are dependent on the CPU clock.

For the W65C51, a timing delay between sending characters at 19.2K baud would be around 521 microseconds. I would probably increase that a bit for a safety margin. Also note that this assumes 8- data bits, 1-stop bit and no parity.

_________________
Regards, KM
https://github.com/floobydust

I'm only using the 65C51 because that's all I have at the moment. I'm building small modules to plug into my SBC so that I can write drivers for them. I'll finish the ACIA driver before I move on to the NXP. By then, I'll just have a PCB made. Unless I want to try wire wrapping it. I suppose I could...but I just wanted to get "something out the door" and the ACIA fit that bill.

Thanks

_________________
Cat; the other white meat.

_________________
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?

Thank you, Garth.

It looks like the 6522 could not count all pulses once their frequency is above PHI2/4 (assuming a duty cycle of 50:50). If that is true, 19200 baud would be (x16 = 307200 Hz) just a bit too fast. But this only means some pulses weren't count or the other way: it took a few more pulses to count down to zero. This causes the delay to be a little longer than necessary. If this is not a big deal...


edited: typos

Then tweak your cycle counting loops when you up your system clock, and rebuild. That's, what, 1? 2 lines of code?

That's your simplest, cheapest, most effective tack.

Especially if you're just going to yank the thing out as soon as practical.

The 28L92 has a counter/timer that can be driven from the 3.6864 MHz baudrate clock. It can go very slowly, especially if you use the divide-by-16 clock setting.
But if you need the delay for a 6551, that's going to be of no use to you, because the 28L92 would replace the ACIA completely.

Given that the 6522 can use an external clock source for its timers, and a 32kHz oscillator is often useful with an RTC (if you don't want to rely on a bare crystal), you could send the 32kHz signal to the 6522 as well. That would give you an independent timing source with sub-millisecond precision, while the RTC could be relied on to keep time to within 1 second.

Solution 1) As a part of your start-up fire off a one-shot (ls121, ls122 or ls123) and count the number of loops until the one-shot resets. Use this to calculate your timing. This would take 2 pins on your 6522.

Solution 2) PM me a mailing address and I will send you one of the 'magical' 65C51 chips I have. I recently ran one of these at 20mHz and as long as your /CE PD is tight, it should work for you too. I just ask that you pay for the shipping once you receive it. One caveat - I will be out of the country until March 4th and unable to send until then.

_________________
Bill