Dirty tricks 6502 programmers use(nurpax.github.io) |
Dirty tricks 6502 programmers use(nurpax.github.io) |
On the beeb we had our own set of tricks specific to the memory layout and ROM of our beloved beige and black machines.
In that case, probably Dirty Tricks 6510 Programmers Use would be even better.
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.
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'm not sure if this particular competition did that)
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.
6502 is still my favorite architecture, even though I've done assembly language programming (professionally!) on many platforms in the past 35 years.
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.
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.
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.
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).
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.
From the wdc65xx link:
> The W65C02S is a low power 8–bit microprocessor utilized in a vast array of products for the Automotive, Consumer, Industrial, and Medical markets. This chip features a full external data (8–bit) and address (16–bit) bus for easy integration with 8–bit peripherals and memory.
Digging in the about page:
> Through the last 30+ years as one of the most popular microprocessor architectures of all time the 65xx brand is estimated to have over six billion embedded 65xx processors shipped and is growing by hundreds of millions of units per year, provided by WDC and its licensees. The following is a partial list of high volume applications that have been successful in using 65xx processors:
> ...
> · Toys
> · Automobile dashboard
> · Appliance controllers
> · Industrial controllers
> · Embedded heart defibrillator’s
> · Pacemakers
[1] https://8bitworkshop.com/v3.4.0/?=&file=examples%2Fbrickgame...
The 65C816 is still being made, so someone must use it for something.
(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.
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
https://hackaday.com/2013/05/24/tamagotchi-rom-dump-and-reve...
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!
Remember, that at the end of the day, you still have to have actual working code …
I'm assuming here that the hashed string is the source code rather than the machine code.
Not that even this have to take a long while on a 3GHz computer running full speed, but doing it 2^272 times ...
And doing something useful with 56 instructions, 8-bits at a time, is like solving a puzzle.
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.
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.
If the article was more about hidden opcodes or instruction set side effects, that's great. But if the key to shaving 8 bytes out of the routine was calling a 120-byte function that's free in the ROM, there's no real trick to 6502 programming being revealed.
It's the equivalent of a blog post titled "I wrote a web server in 3 lines of code!" and the author calls .start() in some imported framework that contains 250,000 lines of code.
The Apple //e would have had a text scrolling function in ROM.
FWIW, if I were actually doing this I’d run it in a emulator and “save” the initial state to restore for the every test.
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.
Combine that with the Apple I and II, and the 6502 was a major player, and the 6800 didn't have any massively compelling benefits.
The 6809 did have benefits over the 6502, and did get some design wins, including Commodore's SuperPET (which bizarrely had both a 6809 and a 6502), but I think the 6809 was too late - on the low end cheap machines like the VIC-20 and then C64 completely trounced the 6809 based machines, and so it just didn't get enough mindshare, and just a few years later it was effectively too late for it to get any traction in the home computer market.