7 ms·
Dirty tricks 6502 programmers use
- fortran77 7y agoThanks! 6502 is still my favorite architecture, even though I've done assembly language programming (professionally!) on many platforms in the past 35 years.
- bcook 7y agoWhy is it your favorite?
- eej71 7y agoI'm not the OP, but I always liked its simplicity. There's just enough space to do something interesting without getting bogged down in too much complexity.
- kgwxd 7y agoI only know 6502 in the Atari 2600 programming context. It's such a great pair because the 2600 hardware is very unique, so it gives you fun problems in that domain as well.
- xxs 7y agoSimplicity? - it has some many addressing modes. Pretty much forced into zero page+Y, but zero page is so limited. Direct code modification, i.e. counters within the code was the next most common. Of course division was an art. That being said I enjoyed it alot and still know quite of the opcodes (hex) by heart + the clock count of many instructions.
- fortran77 7y agoI 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.
- pvg 7y ago8-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.
- ddingus 7y agoIt is. There is always 6809 for a bit more civilized fun, IMHO.
- NikkiA 7y agoPersonally I preferred the 6800 family (6800, 6802, 6805) over the 6502, but the 6809 always felt a little too far.
- ddingus 7y agoI 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.
- jacquesm 7y agoThe 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.
- ddingus 7y agoI 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.
- stevesimmons 7y ago6502 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!
- Zelphyr 7y agoWhat, 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.
- LarryMade2 7y agoToys - and some of those have minimal RAM.
- reaperducer 7y agoSpecifically the 6502, or its successors like the 65C816? The 65C816 is still being made, so someone must use it for something.
- eej71 7y agoI believe the Tamagotchi toys used the 6502. https://hackaday.com/2013/05/24/tamagotchi-rom-dump-and-reverse-engineering/ https://hackaday.com/2013/05/24/tamagotchi-rom-dump-and-reve...
- forinti 7y agoThey were used a lot in cars. I'm not sure if that is still the case.
- Gibbon1 7y agoI'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
- fulafel 7y agohttp://www.6502.org/commercial http://www.6502.org/commercial lists some of these.
- teh_klev 7y agoNot 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.
- reaperducer 7y agotitle should really be named "Dirty tricks C64 6502 programmers use". In that case, probably Dirty Tricks 6510 Programmers Use would be even better.
- vidarh 7y agoWhile that may be technically correct, the programmer-visibile difference between the MOS 6502 and the MOS 6510 is totally incidental in this case - the 6510 has a a built in 6/8-pin IO port (partially used for bank switching the ROMs in the C64). Unless you touch the IO ports, they should behave identically, down to the cycle timings of instructions and the same behavior of undocumented opcodes. In this case, the real C64 specific tricks are not 6510 specific, but depending on the specific initialization done by the C64 ROM and calling C64 ROM routines.
- tenebrisalietum 7y agoA real "dirty trick" is reading the actual RAM in memory locations 0 and 1 on the 6510 (and not the I/O port values).
- joezydeco 7y agoYeah the moment they introduced a ROM call to optimize the routine, I kind of lost interest.
- scarface74 7y agoWhy? The memory layout of the text page would have also been c64 specific.
- LarryMade2 7y agoThere 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.
- jwr 7y agoThis 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.
- gpderetta 7y agothe 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.
- ddingus 7y agoScreen blitting is a frequent unroll for speed case, often combined with self modifying code to make compiled sprites.
- rusk 7y ago>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)
- saagarjha 7y agoI wonder if you could brute force a particular solution with that information.
- stjo 7y agoI 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.
- saagarjha 7y agoOnly a fraction of those would be reasonable programs, and you can test almost all of them immediately by computing a MD5 hash.
- janekm 7y agoOr, 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...
- IcePic 7y agoI don't think that would be this quick either. Since the code might/will mess up zeropage and/or other dataareas in use by the C64 basic, you would have to wipe it to a known state for each test, which almost means "boot up the KERNAL and let it run complete INIT". Not that even this have to take a long while on a 3GHz computer running full speed, but doing it 2^272 times ...
- kazinator 7y agoMy 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.
- vidarh 7y agoA 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 interesting how many bad habits you'd see in code like that, given e.g. the C64 ROMs were extensively dissected and documented and published, and they used zero page all over the place.
- ddingus 7y agoRaises 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.
- js2 7y agoSorta related, some 6502-based demos: https://hackaday.com/2018/12/05/apple-ii-megademo-is-countin-cycles-and-takin-names/ https://hackaday.com/2018/12/05/apple-ii-megademo-is-countin... Apple II, but in the comments are links to a C64 demo, a IIGS demo, and a ZX spectrum demo (which is Z80, not 6502, but same era).