Dirty tricks 6502 programmers use • Hacker News Board

Re: Dirty tricks 6502 programmers use

#31

Post by ddingus » Mon, Aug 19, 2019, 5:00 AM UTC

vidarh wrote: post #25

kazinator wrote: post #21

My first 6502 program was self-modifying; I wrote it just before reading the book chapter on using registers for indexing relative to a base address. That book was Programming the 6502 by Rodney Zaks. I have some 1986-dated 6502 assembly code of mine in hard copy (on dot matrix paper with the "holes" intact). I'm going to scan it one day and post.

A lot more 6502 code was self modifying than necessary - I know a lot of people (myself included) did not pick up zero-page indexed indirect/indirect indexed address modes and instead kept using absolute x/y indexed and modified the absolute part for larger loops. A large part of the reason why I didn't learn about it until fairly late was that I mostly saw absolute x/y indexing in the code I looked at to learn. It's…

Raises hand. Yeah, me too.

When I first got zero page, I thought it looked like up to 128 address registers, with only a couple cycle penalty.

But, like you, a lot of code self modified the easier a solute indexed address mode instructions.

And it was right there, easy to see.

Re: Dirty tricks 6502 programmers use

#32

Post by ddingus » Mon, Aug 19, 2019, 5:05 AM UTC

LarryMade2 wrote: post #6

There can be a significant trade-off on size vs speed, the more tricks you do to shave down bytes usually adds to the complexity of the iterations. So assembly programmers may go for the more kludgy looking code as the execution far outpaces the optimized byte count version. Ive heard of such things in video timing and game loops.

Screen blitting is a frequent unroll for speed case, often combined with self modifying code to make compiled sprites.

Re: Dirty tricks 6502 programmers use

#33

Post by fulafel » Mon, Aug 19, 2019, 5:25 AM UTC

Gibbon1 wrote: post #15

Zelphyr wrote: post #3

What, if any, modern products still use the 6502? EDIT: That’s not a dig against the 6502. I still fondly remember leaning BASIC in my C64 and wish now I had ventured into Assembly with it. By today’s standards it seems to have a simpler and more approachable instruction set so I’m wondering if there aren’t products I could hack on to learn Assembly with it. Or maybe I should just break out my old Commie.

I'm unsure but I think 6502's are available as cores for semi and full custom IC's. Where the the processor core and memory is fully laidout. Bonus runs with a GHZ clock which gives you the ability to twiddle bits like mad. So outside of retro computing you won't see a 6502 IC in the wild. But they likely are buried deep in nondescript IC's

http://www.6502.org/commercial lists some of these.

Re: Dirty tricks 6502 programmers use

#34

Post by stjo » Mon, Aug 19, 2019, 5:54 AM UTC

saagarjha wrote: post #23

rusk wrote: post #14

>Entries were posted as Twitter replies and DMs, containing only the PRG byte-length and an MD5 hash of the PRG file. This is clever. So basically rather than getting bogged down reviewing submissions you just pick a winner and then validate post-hoc! (because when you win the hash of your code has to match the one you submitted)

I wonder if you could brute force a particular solution with that information.

I would say no. 34 bytes is 256^32=7588550360256754183279148073529370729071901715047420004889892225542594864082845696 combinations, and even if you could easily narrow it down to only valid programs you would still need to simulate it, which is way slower than computing a hash.

Re: Dirty tricks 6502 programmers use

#35

Post by saagarjha » Mon, Aug 19, 2019, 6:14 AM UTC

stjo wrote: post #34

saagarjha wrote: post #23

Earlier quoted context omitted.

I wonder if you could brute force a particular solution with that information.

I would say no. 34 bytes is 256^32=7588550360256754183279148073529370729071901715047420004889892225542594864082845696 combinations, and even if you could easily narrow it down to only valid programs you would still need to simulate it, which is way slower than computing a hash.

Only a fraction of those would be reasonable programs, and you can test almost all of them immediately by computing a MD5 hash.

Re: Dirty tricks 6502 programmers use

#36

Post by NieDzejkob » Mon, Aug 19, 2019, 6:53 AM UTC

saagarjha wrote: post #23

rusk wrote: post #14

>Entries were posted as Twitter replies and DMs, containing only the PRG byte-length and an MD5 hash of the PRG file. This is clever. So basically rather than getting bogged down reviewing submissions you just pick a winner and then validate post-hoc! (because when you win the hash of your code has to match the one you submitted)

I wonder if you could brute force a particular solution with that information.

I guess one should use something more expensive to compute, like a KDF.

Re: Dirty tricks 6502 programmers use

#37

Post by stevesimmons » Mon, Aug 19, 2019, 6:56 AM UTC

ddingus wrote: post #29

bcook wrote: post #9

Earlier quoted context omitted.

Why is it your favorite?

I am not the OP either, but 6502 and 6809 are my faves. 6502 was first. It is simple. And that makes it a lot of fun. 6809 is beautiful. I think it is the most powerful and elegant of the 8 bit CPUs. But that spoils a person too. 6502 is like whittling computing down to some useful nubs. There are enough subtleties to make it interesting too.

6502 on a Vic20 was where I really learned to program. As a 12 year old in 1982, I quickly outgrew Basic (with 3583 bytes of free memory) and its 22x23 char screen. I saved my pocket money to buy the assembly language cartridge.

My two most memorable 6502 assembly projects were:

- Text-to-speech - GUI for entering rules to generate phonemes for a text-to-speech system

- 3D graphics - Switching the Vic-20's characters set from ROM to RAM so I could do high-resolution pixel-addressable graphics. I wrote a full set of 3D primitives to draw lines, circles, do perspective and rotations from 3D to 2D, all in 6502 assembly.

One summer holidays I transcribed the entire Vic-20 ROM disassemby into old exercise books, so I could learn how it worked. I remember a sense of victory after reverse-engineering the floating point format and how the transcendental math functions worked.

Happy days!

Re: Dirty tricks 6502 programmers use

#38

Post by NikkiA » Mon, Aug 19, 2019, 6:59 AM UTC

ddingus wrote: post #30

pvg wrote: post #28

Earlier quoted context omitted.

8-bits at a time It's a detail that doesn't always come up in these threads but it's worth remembering how belligerently 8-bit a 6502 is. Not only are there next to no general-purpose registers but they're 8 bit and there are no pretend-two-registers-are-one-16-bit-register instructions at all. You can't put an address in a register. Compared to even other popular 8 bit CPUs of the time, that's a bit metal.

It is. There is always 6809 for a bit more civilized fun, IMHO.

Personally I preferred the 6800 family (6800, 6802, 6805) over the 6502, but the 6809 always felt a little too far.

Re: Dirty tricks 6502 programmers use

#39

Post by ddingus » Mon, Aug 19, 2019, 8:29 AM UTC

NikkiA wrote: post #38

ddingus wrote: post #30

Earlier quoted context omitted.

It is. There is always 6809 for a bit more civilized fun, IMHO.

Personally I preferred the 6800 family (6800, 6802, 6805) over the 6502, but the 6809 always felt a little too far.

I like the 6800. Two accumulators and a 16 bit index register is a good alternative. Totally understand your preference. The 6805 seems too cut down.

I have not written much 6800 code, but have read a fair bit. Had it been more available to me, I would definitely enjoyed it

The 6809 is the Cadillac of 8 bitters. That is what makes it fun. One can pack a ton of features into small spaces and doing reentrant, relocatable code is very well supported.

Stack abuse gets one a really fast memory to memory move too.

Re: Dirty tricks 6502 programmers use

#40

Post by jacquesm » Mon, Aug 19, 2019, 8:45 AM UTC

NikkiA wrote: post #38

ddingus wrote: post #30

Earlier quoted context omitted.

It is. There is always 6809 for a bit more civilized fun, IMHO.

Personally I preferred the 6800 family (6800, 6802, 6805) over the 6502, but the 6809 always felt a little too far.

The 6809 is an amazing little processor, you can run multi-tasking and relocatable code on it with relative ease. And with some bank switching magic you can even do that with appreciable amounts of RAM for each task. It is also one of the few instruction sets that is very predictable, if you know some base formats then you can 'compose' instructions and they usually exist as a valid opcode.