It appears life takes us full-circle. I stopped doing 6502 assembly roughly 20 years ago. Recently I've run into a situation where I need to clean-room an EPROM implementation for a 65c02/6522 embedded controller. The boards aren't copyrighted or protected so I can refab those. The code on the EPROM (27C256) is though.

I'm thinking of doing all this in C for maintenance purposes if I can find an development environment that can do the trick. I don't want to be the guy that maintans this forever.

Anyway, any advice from the citizens of this board to get me started would be most helpful.

Hopefully C will produce binaries that actually fits in the ROM you're aiming to use. If not, be aware that it is entirely possible to write extremely maintainable assembly language as well. The trick is to factor your code ruthlessly, even at the expense of performance (heck, C won't come close to the full performance of the CPU either). Optimize *only* those parts of the code that are speed-sensitive, and when you do, be sure to include the *equivalent* non-optimized code in the form of source comments.

When coding in assembly language, don't limit yourself to 6 letter labels. That artificial limitation was a hold-over from when it was convenient to hash symbols into 8-byte chunks of memory, two bytes held the value, and the remaining six was the label's name. On modern assemblers, this limitation doesn't apply -- use long and descriptive symbol names. You might think that symbols like getcmdproc are plenty descriptive enough. But, as you indicated above, you needed to revisit the 6502 some 20 years after your last experience with it. I'm willing to bet you, someone else will probably need to revisit your code at a later time as well. Use GetCommandProcedure instead. The next maintainer will thank you profusely for it.

Literally, code what is to be done, not how to do it. With proper design, the how will evolve naturally from the what. THis is a kind of declarative programming style, and if you've experience with Forth, you probably already have been exposed to this kind of programming. It also helps alleviate the need for comments in the source as well, thus helping to bring the product to market sooner (why write the same thing twice?).

Test prior and during the coding of the production software, not after. Every time there is a bug discovered, write a test to reproduce the bug first. Then code just enough to fix the bug. Unimplemented features are, by definition, bugs, so treat them the same. Apply this liberally and repeatedly -- over time, the result will be a product that is bug free within the scope of the given specifications. You'll notice it'll take you 3 times longer (more or less) to develop the production code this way. However, compared to traditional "code and debug" cycles, the productivity loss is a wash compared to the time spent in a debugger. Also, the more experience you gain with this methodology, the faster you become.

If you are coding by yourself, utilize top-down design, but bottom-up implementation. Make sure the foundations are bug-free before moving to the next level up. Apply logic and algebraic thinking liberally in this effort -- unit testing, as described above, plus formal methods is an unbeatable combination for writing top-quality code in a timely manner.

Run your unit tests repeatedly. Don't go home at the end of the day until 100% of the unit tests pass. If you wrote something that doesn't satisfy the unit tests prior to your day ending, scrap the code and start over again in the morning. Undoubtedly, you'll end up thinking of a different solution that is better anyway.

Write your subroutines to be as small and as simple as possible. Write them so that they cannot fail (use formal methods if it helps). Obviously, this won't always be possible, but you'll be amazed at how often it is. Handle errors as close to their source as possible.

I can't think of anything else to offer at this time. But those should be able to get the juices flowing. Whether you're coding in C or assembly language or Forth, it doesn't matter.

I've got a few decades development experience and I'm an avid TDD and agile advocate, so what you're saying I attempt to instill into all my engineers on a fairly regular basis anyway. I've been doing strictly enterprise computing for the last 20 or so odd years, so this is a bit of a trip down memory lane. Fortunately, I found my old 6502 books out in the storage boxes.

I was really hoping for some advice on choosing a development suite, to be honest. A fully operational debugger and simulator will more than pay for themselves. The one from WDC seems to do everything I need it to. Anyone have any opinions on that or others?

As for the size of the executable, that is something to consider. It's really doing nothing more than reading signals on the input ports of the 6522 and generating outputs on same. This device has no other purpose. I don't expect the execuatable to be very big at all, so a bit of slop from the C compiler will probably be acceptable. In addition, none of the other engineers here have ANY assembly experience, so if it gets written in assembly it stays on my plate which isn't going to be workable for a number of organizational reasons.

Probably the biggest effort in all this is creating a test environment that simulates the machinery this thing will read and drive. But, that's another story.