Wow, lots of good stuff here Gordon, thank you!

1) Yes, that's the setup. The Arduino is only a USB serial adapter. Correct.

2) I could use a dedicated USB serial adapter, but I don't have one right now and I was just wanting to test this out. The Arduino is easy to manipulate with C++ code too.

3) EXCELLENT idea to have it act as the UART instead. Hm! So, the Arduino reads the serial data, and outputs parallel data. Genius!

4) I forgot about interrupts!!! Yes, indeed. What I could do is turn off /IRQ and then make /NMI count down on the delay timer some preset amount. It will not be pretty by any means. Hm, maybe the serial-to-parallel is the best idea for that then.

I'm not sold on the Arduino, I just got one and wanted to test some things out with it. I actually got it for my Serial VGA Module, which I'll be testing later this weekend, but I figured it was neat to have my PC talk to my SBC in the meantime.

Thank you for the suggestions!



Then I am thinking correctly. I'm guessing the best way to know the resistor value is by testing it and seeing what works best? Like you said, bare minimum.

Thanks!

Chad

Depending on the Arduino - it has a USB serial adapter built in.

If it's NOT a Leonardo (or anything with a 32U4), but a classic Uno then you're good to go. You need to upload a sketch that disables the Tx and Rx ports on the ATmega (don't load/use any serial and set pins 0 and 1 to input with the pull-ups off). Then you can use pins 0 (Rx) and 1 (Tx) on the Arduino headers as a TTL serial output to the SBC.

This works because the USB goes into a USB to serial adapter on the board (sometimes it's a genuine FTTD chip, sometimes a 32U2, but it's the same effect) and as long as you don't use those pins on the ATmega then you can use them for external use without running anything on the ATmega other than the dummy sketch... If the ATmega is in a socket (rare on new boards these days as they all use the SMT part) then you can just pop it out of the socket.

I use an ATmega as the serial adapter on my Ruby board, however it's interfaced in a somewhat interesting way, (mutually exclusive shared RAM), BUT you could use it directly to the SBC however it's not going to be fast enough to emulate a proper bus peripheral (unless your CPU clock is < 1Mhz), but you can use it as an 8-bit parallel device off a port on the VIA. You need to use a few more bits as handshake but it's very possible. Write a byte to the VIA, which sends the strobe signal out CAx the ATmega picks up the strobe, reads the data, sets the reply Ack which is read on CAx (I forget which way round they go) that's great for serial data out of the SBC - to get data IN, you need a bit that the SBC can read from the ATmega to say "I have data", then you turn the port direction round and read the byte and so on. I've been experimenting with something like this for another application and it can be very fast. It's a bit like a very very cut-down SCSI...

I run the serial port on my ATmega at 115200 baud - more than fast enough for my graphics terminal use. I can also send data to the ATmega faster than it can clock it out so there is a nice bit of overlap possible too with careful buffering and interrupt driven sending on the ATmega side.

For development, I actually use a little adapter from Pololu which has both a serial port and an SPI programming port so I can program the ATmega with just one cable going back to my (Linux) desktop. No need to do it this way if you want to keep the serial bootloader in the ATmega though.

There is the whole dilemma of using a relatively modern MCU to host a retro project though, but I'll leave that for you to decide if it's appropriate for your system

Cheers,

-Gordon

Ps. Picture of my system with the USB serial adapter at the very bottom. The grey ribbon cable is the ATmega programming SPI cable, the coloured one is the serial port. (The other coloured ribbon is going to an LCD display connected to the VIA at the top-right of the photo) The bottom most 40-pin IC is the ATmega 1284p.

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

My Arduino is socketed, so I could just pull it. But ultimately I wasn't really wanting to use the Arduino exclusively, I just was using it because it has TX and RX pins and connected via USB. In theory, any adapter or some such would work, I am just choosing something easy for me to grab at the moment to test it.

So I didn't start this topic because I was ultimately going to use an Arduino, no way. I was ultimately looking for some easy way to access the serial data. You brought up excellent points about interrupts, which I'm currently working through in my mind. Likewise my code babysits the /SO line which gives it very limited usage. Like Bill is hinting at, I *am* always looking for minimalist designs, adding more and more hardware is not my goal. It's a balancing act for me.

Good info here, thank you Gordon.

Chad

Right - so if you pull the Atmega then you get a zero additional cost USB TTL serial adapter that you can use without bothering with any code for the ATmega - for now - and that will let you experiment with serial/bit banged solutions on the 6502 side of things. You ought to be able to simple connect the Rx pin on the headers directly to the /SO pin on the 6502 to get the same result. (Remember the Rx pin, pin 0 is Rx into what would be the ATmega - now it's the Rx into the 6502 via a jumper wire).

Cheers,

-Gordon

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

Video games, generally not. The basic loop is: 1. read inputs; 2. update models; 3 generate frame; 4. repeat. Once you've updated your models, you don't care what the inputs are until you've finished generating the next frame since those inputs can't change anything about the frame you're already commited to generating.

BTW, I was just mentioning over here that a USB serial FIFO looks like an interesting option, and perhaps a lot easier than using a UART because, though it presents a standard USB serial interface to the host computer, it presents a simple parallel interface to the device to which it's attached.

_________________
Curt J. Sampson - github.com/0cjs

Nice, but harder to solder in 32QFN format though.

-Gordon

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

Indeed. I paid a couple of extra bucks to buy development boards (three for under $20, including shipping).

I am guessing that the crystal resonator is there because this board is configured to run on bus power, rather than USB power, and has a jumper for 3.3V or 5V Vcc. (IIRC, the datasheet said that an external crystal is necessary if you run below 5V Vcc.)

BTW, plasmo mentioned that he's had very good experiences with these. (I knew I couldn't be the only one who'd come up with this idea.)

_________________
Curt J. Sampson - github.com/0cjs

Interface to FT245 is so simple you can bootstrap a ROM-less 6502 using FT245. A simple 6502 computer is possible with RAM, 6502, two TTL, and FT245. This is how I build a self-programming 6502-based programmer
https://www.retrobrewcomputers.org/doku ... og65r2home
Bill

Very nice indeed Bill!