Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dirty tricks 6502 programmers use

nurpax.github.io

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Dirty tricks 6502 programmers use

#41

Post by jonsen »

jacquesm wrote: post #40
NikkiA wrote: post #38

Earlier quoted context omitted.

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.

“UniFLEX is a Unix-like operating system ... for the Motorola 6809”:

https://en.m.wikipedia.org/wiki/UniFLEX

Re: Dirty tricks 6502 programmers use

#42

Post by gpderetta »

jwr wrote: post #10
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.

This really depends on the specific architecture and the application. In some cases, you will want to optimize mostly for size, so that your hotspots fit entirely into I-cache. Modern CPUs spend most of their time waiting for data (or instructions) to become available, so often computations are essentially free.

the average IPC over a variety of loads is, IIRC, estimated to be ~1. So no, most modern cpu do not spend most of their time waiting for data.

Re: Dirty tricks 6502 programmers use

#43

Post by scarface74 »

joezydeco wrote: post #19
teh_klev wrote: post #4

Not to belittle the article, because it's definitely interesting. But as an ex-BBC 6502 programmer, my nitpick here would be that the title should really be named "Dirty tricks C64 6502 programmers use". On the beeb we had our own set of tricks specific to the memory layout and ROM of our beloved beige and black machines.

Yeah the moment they introduced a ROM call to optimize the routine, I kind of lost interest.

Why? The memory layout of the text page would have also been c64 specific.

Re: Dirty tricks 6502 programmers use

#44

Post by tom_ »

scarface74 wrote: post #43
joezydeco wrote: post #19

Earlier quoted context omitted.

Yeah the moment they introduced a ROM call to optimize the routine, I kind of lost interest.

Why? The memory layout of the text page would have also been c64 specific.

It's a grid of 24 rows (or is it 25?) of 40 bytes, top to bottom, left to right, one byte per char... not exactly uncommon for character mapped displays.

Re: Dirty tricks 6502 programmers use

#45

Post by [deleted] »

pvg wrote: post #28
fortran77 wrote: post #26

Earlier quoted context omitted.

I think it's because it was my first. And it is simple. Yes there are many addressing modes (like zero-page, and "absolute indirect", and "indexed indirect") but there's only 56 instructions and you can learn it in one afternoon. And doing something useful with 56 instructions, 8-bits at a time, is like solving a puzzle.

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.

[deleted]

Re: Dirty tricks 6502 programmers use

#46

Post by FartyMcFarter »

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.

One way to work around that is to allow authors to include comments in the code that gets hashed.

(I'm not sure if this particular competition did that)

Re: Dirty tricks 6502 programmers use

#47

Post by scarface74 »

tom_ wrote: post #44
scarface74 wrote: post #43

Earlier quoted context omitted.

Why? The memory layout of the text page would have also been c64 specific.

It's a grid of 24 rows (or is it 25?) of 40 bytes, top to bottom, left to right, one byte per char... not exactly uncommon for character mapped displays.

That wasn’t how the Apple II stored characters. The memory didn’t map contiguously to screen positions where you could calculate the character position using $400+x+y*40.

Re: Dirty tricks 6502 programmers use

#48

Post by janekm »

saagarjha wrote: post #35
stjo wrote: post #34

Earlier quoted context omitted.

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.

Or, you could evaluate whether said program draws the crossed lines in an emulator. Might not take that much longer than calculating the hash... That makes this kind of an interesting "Genetic Programming" challenge... The solution space is "only" 29 bytes long...

Re: Dirty tricks 6502 programmers use

#49

Post by [deleted] »

pvg wrote: post #28
fortran77 wrote: post #26

Earlier quoted context omitted.

I think it's because it was my first. And it is simple. Yes there are many addressing modes (like zero-page, and "absolute indirect", and "indexed indirect") but there's only 56 instructions and you can learn it in one afternoon. And doing something useful with 56 instructions, 8-bits at a time, is like solving a puzzle.

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.

[deleted]

Re: Dirty tricks 6502 programmers use

#50

Post by cbm-vic-20 »

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.

There is still a very active 6502 hacking forum at

http://forum.6502.org

(No SSL/TLS, unfortunately).

Lots of people build homebrew computers out of these things, there are a few open source OS and build chains available, etc.

Post reply on HN