Timeline for What are uses of the byte after BRK instruction on 6502?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 15, 2019 at 7:29 | comment | added | Mark Williams | "In fact, being a debugging tool, readjusting the PC to the original instruction address and replacing the instruction overwritten (*1) had to be done anyway.” I suspect this is the main reason. You want to be able to add and remove breakpoints on the fly. | |
| Sep 13, 2019 at 9:02 | history | edited | Raffzahn | CC BY-SA 4.0 | added 70 characters in body |
| S Sep 12, 2019 at 10:46 | history | suggested | psmears | CC BY-SA 4.0 | Improve wording and grammar |
| Sep 12, 2019 at 10:17 | review | Suggested edits | |||
| S Sep 12, 2019 at 10:46 | |||||
| Sep 12, 2019 at 8:43 | history | edited | JeremyP | CC BY-SA 4.0 | spelling mistake |
| Sep 11, 2019 at 23:15 | history | edited | Raffzahn | CC BY-SA 4.0 | added 3 characters in body |
| Sep 11, 2019 at 21:36 | comment | added | Raffzahn | @CurtJ.Sampson Well, having BRK dump into monitor is exactly what it's meant for. When debugging with the monitor, one writes 00 into wherever a stop is needed, hits go and ends up in monitor again when the stop is reached. Now, having BRK to enter some routine (like Sweet16) may save a byte on each call, but wastes a lot of cycles to handle address fetch and return. So it's always up to what specific optimization goal is higher prioritized. In general I'd go for cycles, as memory isn't that limited. | |
| Sep 11, 2019 at 13:16 | comment | added | cjs | Regarding Sweet 16, Woz used JSR in the Apple II, presumably because BRK was already used to enter the monitor (IRQ at $FA86), but he explicitly suggests in the BYTE article, "You may wish to handle the break instruction as a SWEET16 call, saving two bytes of code each time you transfer into SWEET16 mode." | |
| Sep 11, 2019 at 12:38 | comment | added | cjs | I've also added footnote ³ to clarify what I mean by "unintentional." In this context, that extra byte appears, from your description, indeed to have been unintentional. | |
| Sep 11, 2019 at 12:25 | comment | added | cjs | "BRK isn't a 1-byte instruction interrupted by IRQ, but rather an instruction working like IRQ." No misunderstanding here; this is exactly what I meant. That's why I said "an IRQ interrupting any other 1-byte instruction." Thanks for your explanation of the implementation of BRK; I had suspected it was something like this that led to the "spare byte." | |
| Sep 11, 2019 at 11:22 | history | edited | Raffzahn | CC BY-SA 4.0 | added 144 characters in body |
| Sep 11, 2019 at 11:16 | history | answered | Raffzahn | CC BY-SA 4.0 |