I have an 'unusual' constraint on enjoyable computing - INTERACTIVITY. Retrocomputers provide a good start - my Apple //c has a BASIC interpreter, a machine language monitor with a disassembler, and even a mini-assembler. However, I've become spoiled by enormous video monitors, windowing editors, interactive symbolic assemblers and fast hard drives. I don't know what tools you use for developing code for your 6502 machines, but I thought I'd show mine.

HazMat is an interactive collection of tools providing:
-Interactive control of the Apple over a serial link
-Interactive symbolic assembler
-Non-invasive environment (I can still type on the Apple //c's keyboard as if nothing is connected).

Here is a screenshot demonstrating a simple session (click to enlarge):

The left screen is an editor that I rigged to output the current line of text when <CTRL><ENTER> keys are pressed (I can also select and send a block at once).

The right screen is a session manager for the Apple //c. It maintains a serial link, and shows the data going to and from the Apple. Note that Apple's output is green, keystrokes from the toolchain are white, and comments are olive.

The idea is simple. I get to use my modern editor to enter and save code (or copy snippets from the Internet). I can bang lines of text into the Apple's serial port to simulate typing on its keyboard. I can also interpose a symbolic assembler in-between, allowing me to build sophisticated applications while maintaining full interactivity.

There are three components in play:
1) The editor (slightly modified SCiTE) allows me to send lines or blocks of text to stdout;
2) The session manager establishes a link with the target and separates communication layer from everything else;
3) The assembler takes lines of text from stdin and outputs assembled code in Apple monitor format to stdout.

I invoke the contraption like this (a real tool chain!):

hed is the editor invoked to edit the file called mycode.6502;
its output is piped into hm6502, the assembler;
assembled code output is redirected to 'toApple', a named pipe maintained by the serial session manager.

The serial link was always problematic. In the past, when my code on the Apple crashed, I would have to shut down and restart my toolchain and re-establish the serial link, which is not trivial. By separating the serial session manager, I have a completely separate link - I can restart the toolchain while the link is up, or if the Apple crashes, simply restart the link without having to save and restart the toolchain.

This incarnation supports 6502 assembly, but I've written a variety of similar tools for embedded development on 68K, x86, MIPS, AVR, PIC, PIC24, PIC32, ARM7 and Thumb/Thumb2 with assemblers and Forth-like experiments. I have to admit I like my current 6502 Apple setup the best so far

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Very nice. We had a discussion on this kind of thing in Hardware --> PC port interface hardware, and I put a couple pictures of my monitor and some description there, at viewtopic.php?f=4&t=1368&p=8049#p8049 and another one three posts down from there. The nice thing is instant turn-around, with no special software at all on the PC. For crash recovery on my workbench computer, I added a choice in the reset routine: you can either start over with everything, or keep the Forth dictionary pointer where it was to keep all the old material, or go further and execute the word whose address is in the INIT-AP variable to set the hardware up again and get the program going again, so a crash followed by pressing the reset button may have things down as little as about three seconds. The choice between these three options is made at the keypad. Most crashes don't write garbage into memory but instead just get caught in a loop whose exit conditions will never be met, or something like that, so re-starting without re-loading anything works ok. I also have an ABORT button which causes an NMI to get the processor's attention no matter what it's doing and re-start a process without resetting the timers and interrupts and so on, but I haven't really been using it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Nice.
The Apple //c has an unfortunate tendency to start up in 300bps mode, and needs to be set to 115200bps in software. In addition I want to echo to the Apple screen as well as redirecting the output to the serial line. This 3-minute process (requiring much typing on different keyboards and resetting the PC terminal speed) used to drive me crazy.

Give me DIP switches, please! Apple //c was the beginning of the end, unfortunately.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut