3 ms·

I love that each step further down in size has you thinking "nope, it won't get smaller". Here is a C64 version in 13 bytes: .pc=$7c loop: lda

I love that each step further down in size has you thinking "nope, it won't get smaller". Here is a C64 version in 13 bytes: .pc=$7c loop: lda $d012 ; content of $d012 into accumulator lsr ; shift accumulator right, moving lsbit into carry lda #$cd ; value of diagonal line into accumulator adc #0 ; add 0 + carry. if carry, accumulator will hold $ce, opposite diagonal line jsr $ffd2 ; call CHROUT in rom; outputs character in accumulator on device bcc loop ; branch to loop if carry is cleared; an effective branch-always which saves 1 byte from a jump I'm sure it can be golfed further with the illegal opcodes that I am not familiar with. EDIT: Shed one byte, added comments, moved the origin to $7c which means that adding 2 bytes of header will make it a runnable C64 PRG.

PythonicAlpha 12y ago
I'm sure it can be golfed further with the illegal opcodes that I am not familiar with. Possible. But not necessarily. Long time ago I reviewed the many illegal opcodes of the 6502. Many are simply doing nothing and most of them are not useful at all. The few that are useful give little benefits, because they can be used in very very few situations. I finally did not use them, since I don't wanted to break compatibility with 6502 successors (which where very few, finally).
- boomlinde 12y ago
  I mean "sure" only as a manner of speaking, not to say that I am absolutely certain. The challenge for me in using the illegal opcodes is internalizing them and recognizing the situations where they can actually be used effectively to save a byte or a cycle. When writing code for platforms with very little memory or harsh time constraints, they can certainly save you headaches. Something like LAX for example can be used to do an y-indexed load to the x register, which often times can save you an accumulator transfer when doing doubly indirect loads.
  - PythonicAlpha 12y ago
    Sorry for the inconvenience. I am not familiar with the details of English language, so sometimes I just understand things wrong. Yes, there are some interesting opcodes too, but I found their usage so limited, that it was not worthwhile to drop compatibility. Of course, with a fixed setting, where you need every byte .... but I must say, that for me today it is just academic, since I also do no embedded programming today. With computers of today, I still think, that optimizing is worthwhile, but not to that degree, that breaking compatibility makes sense.

PythonicAlpha 12y ago

I'm sure it can be golfed further with the illegal opcodes that I am not familiar with. Possible. But not necessarily. Long time ago I reviewed the many illegal opcodes of the 6502. Many are simply doing nothing and most of them are not useful at all. The few that are useful give little benefits, because they can be used in very very few situations. I finally did not use them, since I don't wanted to break compatibility with 6502 successors (which where very few, finally).

boomlinde 12y ago
I mean "sure" only as a manner of speaking, not to say that I am absolutely certain. The challenge for me in using the illegal opcodes is internalizing them and recognizing the situations where they can actually be used effectively to save a byte or a cycle. When writing code for platforms with very little memory or harsh time constraints, they can certainly save you headaches. Something like LAX for example can be used to do an y-indexed load to the x register, which often times can save you an accumulator transfer when doing doubly indirect loads.
- PythonicAlpha 12y ago
  Sorry for the inconvenience. I am not familiar with the details of English language, so sometimes I just understand things wrong. Yes, there are some interesting opcodes too, but I found their usage so limited, that it was not worthwhile to drop compatibility. Of course, with a fixed setting, where you need every byte .... but I must say, that for me today it is just academic, since I also do no embedded programming today. With computers of today, I still think, that optimizing is worthwhile, but not to that degree, that breaking compatibility makes sense.