Re: How do you debug your 6502/65C02 code?
Posted: Tue Nov 30, 2021 12:44 am
I've used various ones of the ideas posted above. I just added the following to the "65816 EMU Pin and WS2812B Digital LEDs" topic. I got the idea from one of the electronic industry magazines' "Ideas for design" sections.
--------------------------------------------------
Here's a diagram to add to my post above, about using as little as a single pin to output status bytes from a microcontroller with extremely limited I/O. The pin could even be one that's being used for something else as long as you can let it go for short periods for the purpose. For example, you might have the pin driving an indicator LED and it won't hurt anything to have if flicker when you're outputting data during development; or even a pushbutton input, as long as you don't need to push the button while you're outputting the data. I've done this with PICs having as few as 8 pins (the PIC12's). There are others even in SOT-23 packages with only 5 or 6 pins [power, ground, and 3 or 4 I/O pins] (although I have not used those, so far). This is copy-and-pasted from the comments in the source code for a work project I did a few years ago. The clock speed is not important, only the relative lengths of the high and low pulses.
I'll leave the actual program code out since it's not 65xx, unless someone asks for it. It's in PIC assembly language with a lot of macros.
--------------------------------------------------
Here's a diagram to add to my post above, about using as little as a single pin to output status bytes from a microcontroller with extremely limited I/O. The pin could even be one that's being used for something else as long as you can let it go for short periods for the purpose. For example, you might have the pin driving an indicator LED and it won't hurt anything to have if flicker when you're outputting data during development; or even a pushbutton input, as long as you don't need to push the button while you're outputting the data. I've done this with PICs having as few as 8 pins (the PIC12's). There are others even in SOT-23 packages with only 5 or 6 pins [power, ground, and 3 or 4 I/O pins] (although I have not used those, so far). This is copy-and-pasted from the comments in the source code for a work project I did a few years ago. The clock speed is not important, only the relative lengths of the high and low pulses.
Code: Select all
; ┌───────────────────────────────────────────────╖
; │ OUTPUT STATUS (for troubleshooting) ║
; ╘═══════════════════════════════════════════════╝
;
; This status reporting is only for debugging. It's not needed in the production units.
; Reporting by serial bit stream will be on PC4. We'll start with a 1.5ms high pulse as a start bit, followed by a 1.5ms low
; time, and then each 0 after that will be .5ms hi + 1ms lo, and each 1 will be 1ms hi + .5ms lo, so a bit starts every 1.5ms,
; on a schedule. There's an extra 1.5ms low time between bytes. Interrupts will need to be turned off temporarily to avoid
; jitter that would make it difficult to see the pattern repeating on an analog 'scope, as well as making sure short pulses
; don't get too long.
; To make it easier to see where the start bit of a multi-byte report is with a dual-trace 'scope, PC3 (pin 14) is pulsed low.
;
;
; low 1.5ms to make Start then ┌────────── example 01001011, or $4B ──────────┐ ┌── start next byte
; start bit visible─┐ 1.5ms 1.5ms
; │ high low 0 1 0 0 1 0 1 1 0 0
; ───────┐ V ┌────────┐ ┌─┐ ┌───┐ ┌─┐ ┌─┐ ┌───┐ ┌─┐ ┌───┐ ┌───┐ ┌─┐ ┌─┐ ┌─ . . .
; (PC4 pin 15)───────┴────────┘ └────────┘ └───┘ └─┘ └───┘ └───┘ └─┘ └───┘ └─┘ └───────┘ └───┘ └───┘
;
; (PC3 pin 14)────────────────┐ ┌─────────────────────────────────────────────────────────────────────────────────────────
; (for triggering) └────────┘
; └──┬──┘
; └────────┬───────┘ │
; └─start bit 1.5ms extra between bytes───┘
;
;
; Since it is not always desirable for the the status report to run every time OUTPUT_STATUS is encountered in the program, it
; will look at PC5, pin 16, which has a passive pull-up. If the switch to ground is open, it won't report.
; If you want it to keep reporting continually, you'll have to call it from a loop.
; Byte at RAM address REPORT_ARRAY is sent first. Bytes are sent msb-first.
; To use OUTPUT_STATUS, put the bytes you want to output in REPORT_ARRAY, and put the number of bytes to report in REPORT_COUNT.
; REPORT_COUNT will get decremented to 0 during the reporting, so the program must re-initialize it before each call.
; ══════════ NOTE !! If you call OUTPUT_STATUS repeatedly in a loop, you must re-init REPORT_COUNT every time! ══════════
I'll leave the actual program code out since it's not 65xx, unless someone asks for it. It's in PIC assembly language with a lot of macros.