The 6502 and the Propeller are connected via a few glue-logic chips. The Propeller has 32 digital I/O pins and they are all in use; many of them are used in more ways than one. The Propeller controls the 6502, and enables the SRAM memory chip.
The Propeller generates the clock pulses for the 6502, at a maximum rate of 1MHz. During the first half of each clock pulse, the 6502 doesn't use the data bus, so the Propeller can use this time to enable two 74HC244 octal buffers to connect to the address bus. It can use the address to make decisions about what to do during the second half of the clock pulse, for example if the 6502 is in the process of writing a byte into the screen buffer, the Propeller can catch this write and put the byte in its own memory to show a character on the screen.
Signals such as interrupts and Reset can be generated by the Propeller by using a 74HC574 octal D flipflop. During the first half of the clock pulse, the Propeller puts the signals on the pins that are connected to the '574 and clocks the flipflops so that the updated signals will be sent to the 6502 continuously even though the Propeller only updates them once per clock pulse.
The RAM chips is connected to the data bus and address bus of the 6502 and its Chip Select line is permanently active; however the two pins that control whether the RAM reads or writes a byte from or to the data bus are under direct control of the Propeller. When the 6502 accesses a memory area that's mapped into the Propeller (such as a video buffer), the Propeller just needs to make sure that the RAM chip doesn't get activated at the same time.
The 6502 has to boot from a memory area that's initialized with data before the 6502 starts. This can be done in two ways: The first way is to simply map the ROM area into the Propeller. The second way is for the Propeller to write the ROM image to the SRAM chip before starting the 6502. However, the Propeller doesn't have direct control over the address bus and the 6502 can't start until there's something in memory.
This problem is solved by a clever algorithm that generates a Reset or NMI on the 6502. The 6502 retrieves a pointer to a location to start executing a Reset or NMI handler, and the Propeller intercepts the retrieval of that pointer to send the 6502 to a location where the code needs to be stored. During the first half of each clock pulse (when the 6502 isn't using the data bus but an address is already available), the Propeller puts the byte to store onto the data bus, and enables the Write line on the RAM chip to store the data. Then during the second half of the clock pulse, it disables the RAM chip and generates dummy instructions for the 6502. So the 6502 thinks that it's busy doing nothing to handle the Reset or NMI, but the Propeller is storing data into memory behind the back of the 6502.
At the time of this writing, the download algorithm hasn't been totally debugged yet, but I've been successful in setting up an emulator for the Apple 1 and mapping Ken Wessen's Krusader ROM into 6502 memory which makes it possible to write programs in Assembly language or Basic. See http://youtu.be/8BCoQepmyYU for a demo. This is just the first emulator of an existing system. More emulators for other systems will follow, and of course it's possible to design a new system that's not based on any pre-existing hardware at all. Furthermore it's possible to use an expansion bus to connect hardware that might be too difficult to emulate with the Propeller.