Using a 6532 at 1 Mhz for 9600 baud software serial- the bit delay seems fine for the loop but unless I up the start bit delay to 203 cycles-ish it doesn't work.. Is something wrong with my math?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Could be right. If you start timing from the leading edge of the start bit, you will ideally wait 1.5 bit times before sampling the first data bit, so you get it in the middle of the bit. And then every 1 bit time, to keep hitting the middle of each bit.

But I haven't checked the maths.

That’s what I’m going for but my math says the 1.5 bits should be 156 cycles but for some reason it only works with 203 cycles which seems waaaay off.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

"shortloop" seems to only delay 6 cycles per iteration. I don't know what READTDI does in hardware though, if it's an automatic hardware timer then I guess the loop length doesn't matter so much.

If you can set the state of output pins then maybe you can use an oscilloscope to test your delay routines with various numbers and see what's going on - or compare them against VIA timers if you have them.

It's possible that the additional delay up front is compensating for time to process each bit being too fast (which accumulates over the 8 bits).

Some of the cycle times you have in the comments are incorrect. For example LSR A and LDA # are both 2 cycles, not 5 cycles and 3 cycles.

I would also suggest re-writing your delay_short loop without using external hardware. i.e. make it a pure software delay loop. Then it's easier to count cycles, without having to make assumptions how the external hardware works.

Dave

I came to the same conclusion this morning. I'm compensating for the timer not delaying what I expect.

What's actually going on is probably delay_short being "off by one" - when it hits 0 the timer exits even though it hasn't triggered, so it's always 8 cycles less delay.

21 + ((WTD8DI - 1) * 8) cycles along with the incorrect cycle times should fix it.

Thanks for the help.. Time to test!

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Because your loop is 6 cycles, it will round the delay up to a multiple of 6 as well, with some bias that depends on the hardware. So 21 plus ((WTD8DI-1)*8 + N) rounded up to a multiple of 6. It's kind of complicated. An accumulator-based delay loop using SEC and SBC #1 should be eight cycles as desired, I think, so would work well with your existing code.

I don't think that's quite right The 6 cycles you are referring to should only be counted exactly once, since the other times the hardware timer the hardware timer hasn't counted to 0.
When we set WTD8DI on the 6532 it starts counting down and until it reaches 0 we keep looping - it shouldn't matter how many times we loop.



Cycles for the timer routine = (A - 1) * 8 + 21

Am I missing something G?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

But the CPU is only sampling the READTDI register once every 6 cycles. For reference here's your code:



It will execute like this, for example, entering with A=2 - I've shown cycle numbers in the left column relative to the write for clarity:


Note that it will read from READTDI on cycles 3+6*n relative to the cycle when the write operation took place, the "bne" is always at 4+6*n for some n, and the "rts" is at 6*(n+1). Changing the value of A on entry can only offset this by a multiple of six one way or the other.

I think that makes sense!
If I throw a NOP in there it will sample every 8 cycles and the sampling will be even and simplify the math, right?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Yes I think so. You do also need to ensure the branch is not crossing a page boundary otherwise it costs an extra cycle.

But by this point the hardware timer is not really helping you as you're having to cycle-count anyway - you can instead just have A be a multiple of 5 and do:



Or move the "sec" into the loop and have A be a multiple of 7, or... lots of options of course!

The vdelay project at GitHub has some nice routines that perform precise delays of any duration above about 30 cycles: https://github.com/bbbradsmith/6502vdel ... ay_short.s

All that said, one case where the hardware timer will work in your favour is if you set can it up during the start bit and have it automatically count down again from just the right value for subsequent bits - it removes some sources of accumulated drift during the byte and means you don't need to carefully cycle-count your byte reading loop, you just need to start the timer at the right time. If the hardware timer doesn't have VIA T1-like latches that you can use for automatically setting it to a new value when it hits zero, then you could maybe reset it with the correct bit-to-bit gap after each bit - however you lose a lot of the benefit.

Another option - if supported by the hardware - is to set the timer up as you are already doing for the start bit, but then just let it tick down through negative numbers after the start bit, without resetting it. Now you want to read the second bit when the timer reaches -13, the third when it reaches -26, the fourth at -39, etc - just subtracting 104/8 with each time. This is probably my favourite as it once again removes all possibility of drift during the course of a byte.



waitforbit is an 8-cycle loop. The bit read timing may be off by +/-8us, but that should be OK and it won't lead to accumulated drift over the course of the byte. (Edit - it's probably less important for it to be an 8-cycle loop in this case as we've removed the need for precise cycle counting except between the interrupt and the point the timer register is loaded.)

(Another edit - by the way, a nice trick for shifting in exactly 8 bits is to initialise the target memory location with $80, then ROR the bits into it, and after each ROR, if the carry is clear, loop back for another bit. That single set bit will make its way along the byte, and ultimately terminate the read loop, without needing to also manipulate an index register.)

If I read the data sheet for the 6532 correctly it essentially disables the divisor when hitting 0 and switches to system clock so we can count cycles since interrupt was triggered - but the 6507 doesn’t have an IRQ pin so I’d have to poll a pin for interrupts manually - that’s a whole different thing.

Using the timer made more sense when I was only going for 4800 baud - less precision needed and the timer simplified things.

At this point I’m just trying to get a better understanding of the 6532 - cycle by cycle.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

What is your bit-bang transmitter routine looks like? Transmitter is more visible (observable with scope), so you can see the effects of instruction timings. My first 6502 design had hardware receiver but bit-bang transmitter so I just wrote a software delay loop and tweak the loop counter and watch with scope until I have the right timing. THEN I read about the instruction timings and annotated the software accordingly. It was a cart-before-the-horse approach but there were so much 6502 to learn initially.
Bill

Things are working now - if I hammer my keyboard I can still induce bit errors, but that's probably just my main loop that's too long (just blinking an LED) - it should probably just be waiting for serial
In the TX routine the cycles I count and measure seem to be off by 2 - I would change a NOP to a LDA ZP if I knew for sure the bit time is now 103 instead of 104 or 105.





Yup! That'll come in handy!!

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Thank you all so much for the help debugging!
It turned into my new video about the serial bootloader for the 65uino.

https://youtu.be/nOmQd3y3pDw

Thanks again!

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1