Hi again, I was looking online for documentation of anyone connecting the Arduino UNO to the 6502. And I couldn’t...
If you were to look in my previous posts, I am planning on using it as a video output device. And since I’m using the library TVout, the pins 9 and 7 are going to filled. Could I use the Digital pins as input for the Arduino? And how should I go about this give me a general idea and I can most likely figure out the rest!

-EAS

_________________
I and my Daisy Bell

I'd suggest interfacing it using a Serial connection, and building a protocol on top of that.
Perhaps assume incoming bytes are ASCII text, unless there's been a command byte received. Standard ASCII is a 7-bit code, so it has a range of 0-127, but most serial interfaces(including the Arduino's) default to 8-bit bytes, so you have another 128 codes to play with for non-text stuff, if you are so inclined.

I wouldn't try to put it directly on the 6502's bus. The Uno doesn't have a lot of pins, and it's best to keep it simple.
If you don't have a UART or ACIA in your 6502 system, and you do have a VIA, you can probably arrange the Arduino to be an SPI slave, and either use the VIAs shift register or bit-bang SPI using a few of its GPIO pins.

the avr on an arduino uno is not fast enough to implement read/write

note the swinsid is a special case the avr is highly overclocked and the read is not implemented
the 6502 can only write in the swinsid (in the version I saw a few years ago)

but I guess you can do what you want with a propeller
I've created a vga ouput for a 6502 board (max 1Mhz)
3 cogs of the propeller generates a 80x25 or 40x25 black and white screen (vga output)
1 cog of the propeller implement the read
1 cog of the propeller implement the write

A virtual screen memory is mapped inside the 6502
this screen seen in the 6502 resides in the propeller

I didn't realize the SwinSID didn't implement reads. Yeah, people don't always get that. They don't understand why a 20, 80 or even 180 MHz micro-controller cannot "keep up" with a 1 MHz Commodore 64. Then they discover that it takes several instructions to do one thing and each one of those take several clock cycles at times (depending on architecture).

Anyway, I remember the L-Star does a similar thing by directly simulating RAM/ROM and I/O for a 65C02 using a Propeller. The issue was that it can't get much faster than 1 MHz. Which is fine if your target computer is an Apple 1 or similar.

I want to do a something similar. However, I'm torn from using a Propeller or going full Monty and using a CPLD or FPGA.

Looks like the P2 is a reality now and might actually be available soon. This will be a game-changer in my opinion. Not because it's so much better than an FPGA...but because it's much more hobbyist friendly. PASM is easier to learn (for many people) than HDL plus the tools are open source.

Good times!

_________________
Cat; the other white meat.

frankly, there are some other techniques to connect an avr to a 6502 bus
in some cases, to emulate some IO controller
it is possible to insert a CPLD between the 6502 bus and the avr
the set of registers of the controller are inside the cpld and available on the 6502 bus
a write on a register trigger an irq on the avr, the avr can read the register in the cpld process the content and
update the cpld registers...

for the propeller I'm not convinced it's easier have a fpga + vhdl
it took me less time to learn enough vhdl to design a vga signal from memory
than to do the same on a propeller

and Apparently it will be as difficult to solder a propeller II than a FPGA

in most of my project I try to use the MAX7000S PLCC 44 / 84 EPM7064S, EPM7128S, EPM7160S
they are easy to integrate on a 5v design and easy to solder (PLCC)

btw the easiest to connect is a z80 by using the wait pin
on the 6502 rdy only works for read
btw do you know if rdy was extended to read/write in the WDC version of the 6502
the documentation is not so clear...

Yes, all 6502s after the NMOS one will honour RDY going low for any cycle, read or write. (As will the '816.)

So at the cost of changing the 6502 by a more recent one,
it should be possible to interface an avr as easily as on a z80

So... There isn't really any documentation mostly because there is no "one way" to do it. Everyone does it their own way. Ask 12 engineers, get a bakers dozen answers ...

Here is my way...

I have interfaced an Arduino (actually an ATmega) to a 65C02 and 65128. It's part of my Ruby 6502 (and Ruby816) systems and roughly documented in an overview sort of way over at: https://projects.drogon.net/6502-ruby/

In essence:

There is no ROM on the 6502. The ATmega (it's a 1284p, so lots of IO pins), uses 8 pins for the data bus, another 8 for the lower 8 address lines and can control the 6502 reset, BE and Rdy signals. It also has /Rd and /Wr outputs to go into the SRAM. The top 8 address lines are pulled high via 10K resistors. another IO pin can signal an IRQ to the 6502. The top 256 bytes of RAM are shared between the ATmega and the 6502, but only ONE side can access it at a time.

There is a PAL for address decoding (more to save 2-3 TTL chips) and to turn RWB from the 6502 into /Rd and /Wr signals to the SRAM - which it can also tristate based on the BE output signal from the ATmega into the 6502.

So... Power on: The 6502 is held in reset, the ATmega boots. It lowers BE and holds the 6502 in reset. It then enables the data and address lines and at this point it can see the top 256 bytes of RAM. It writes a small boot program here and sets the vectors to point to $FF00. It releases itself from the RAM and un-resets the 6502.

The 6502 starts, fetches the reset vector and jumps to $FF00. This is about 200 bytes of bootstrap stage zero.

The boot code relocates (copies) itself to lower RAM ($400, but it's not that important) then communicates with the ATmega to pull in the rest of the OS which it loads starting at $C000 then it jumps into the main operating system.

Once booted the 6502 is effectively in control and the ATmega does what's asked of it by the 6502.

The communication mechanism works by the 6502 poking a set of commands and data into the top 132 bytes of RAM from $FF00 through $FF83 then issuing a WAI instruction. At this point the ATmega which has been polling the Rdy signal, "knows" that the 6502 has halted and can /BE the 6502, enable its address and data buses into the RAM, read the RAM, execute the command, using the 128 bytes from $FF00 through $FF7F as a transaction buffer. When it has done the command (which might be "print string") writes a "done" code into the RAM, and releases itself from the RAM, enables the 6502 (brings BE high), and sends an IRQ which causes the 6502 to wake up at the instruction after the WAI.

The ATmega can generate video - and it did in early incarnations. I had it creating a 320x240 pixel display, so 40x30 character display with an 8x8 font, or graphics. The 6502 can send commands to e.g. print a character, or draw a line, rectangle, circle, etc.

However - it proved too slow. Generating the video signal was taking up too much time inside the ATmega - some 60-70% of all CPU cycles, so I abandoned that idea. Now it's essentially a serial terminal and the graphics commands are passed through to the terminal program I use on my Linux workstation. It does other stuff too - acts as a floating point accelerator, a filing system (SD card), timer interrupt source and whatever else I can think of. The filing system is the important part now though.

So that's a brief overview of one way to interface an ATmega (or Arduino) to a 6502. This way with local RAM to the 6502 allows the 6502 to run at full speed with local RAM rather than have the ATmega single step the 6502 and provide emulated RAM and ROM which is another way to do it.

There is a little video demo of it here: https://www.youtube.com/watch?v=ci_70naIg_Q there is some graphics towards the end.

-Gordon
(also a baker)

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/