More serial questions...

[cbmeeks]

This is a followup to a previous question I asked a while back. It was concerning connecting a homebrew SBC to a Mac.

Things have changed a little. I no longer use a Mac but that's not really relevant. Anyway, I have a USB to serial adapter that I use to program my Propeller micro-controllers. (LINK: https://www.parallax.com/product/32201)

I'm starting to build my first real SBC and I'm trying to keep things minimal. Also, I have to work with the parts that I actually have on hand.

I have a few WDC65C02's, WDC65C22's, some SRAM's, EEPROMS, etc. Plus many "glue" IC's.

So I was thinking...why not just take a '02, a 32K SRAM (70ns), an 8K EEPROM and perhaps a '22 as well.

I have a computer then, right? Well, assuming I put the Woz monitor on the ROM and get my address decoding correct.

But the part that I'm struggling with is still the serial part. Seems like every example I see recommends using a 6551. Well, I don't have one of those on-hand.

I have an idea for using a Propeller (micro-controller) for serial communication from my PC but I want to save that for SBC2. I figure the above design is as old-school as you can get without using NMOS/DRAM chips.

Anyway, I'm rambling.

Can the 65C22 be used to communicate with my computer via the USB/serial adapter I listed above? Or, is there something else I'm missing?

Thanks again.

[floobydust]

Well, Yes, take the pieces you have, glue them up and you have a SBC, add some code and it will likely do something. While the 6551 is an easy hardware and software addition, the current WDC parts are basically broken and you would need to band-aid the transmit code to make them work. Other options are find some older Rockwell R65C51 chips which can be had pretty cheaply (I bought 10 back in 2014 IIRC from UTsource). Other serial options would be the NXP chips which BDD uses on his POCv1 board.

Beyond this, the 65C22 could be used to provide serial but would be software based, as Commodore did this on the Vic-20. You can find the source code kicking around for the Vic as well which would help. Another option is to use the FTDI FT245RL USB to FIFO chip interfaced to a 65C22. This would simplify the coding and give you some pretty fast speeds without configuring the SBC side for baud rate.

Many others out here, including myself, have made some basic monitor code available which will allow a quick and easy hardware test. I have a nice small BIOS that will run a 65C51 and 65C22 with full IRQ support for transmit/receive on the 65C51 and dual timer support on the 65C22 and is extendable as well. I also have a decent monitor that uses the BIOS. The new version is less than 2900 bytes of code and the BIOS fits in just 756 bytes.

[GARTHWILSON]

There's a topic at viewtopic.php?t=2063 on bit-banging 57,600 bps on a 1MHz 6502.

For the WDC 65c51, if you want to use an interrupt to tell you when it's ok to feed another byte to the transmit register, you can use a VIA timer (T1 or T2), and then the processor can do something useful while waiting. This is from the topic at viewtopic.php?f=4&t=3347, "Serial fun with the 6551." I get the idea that most people here under-use the VIA's timers. Using one to get around the new 51's bug would be a good application of one.

Edit, 2/8/19: I think GaBuZoMeu has the best solution yet: Use the 51's pin 5 (if in DIP), the x16 clock, as an output to drive a VIA's PB6 for its T2 to count pulses and generate an interrupt. The T2 latch value does not need to change with Φ2 rate nor with baud rate. viewtopic.php?f=1&t=5482&p=66433#p66433

[cbmeeks]

Thanks for the ideas.

However, I don't have a 6551 in my parts bin. I'm going to order one soon. I try to save my Mouser orders for when I have several items to get so that I'm not paying shipping multiple times.

In the meantime, I tried to search for 6502 code that would send/receive data over the 65C22. I'm not having much luck. But that's probably because I'm just using the wrong terms (never written driver to handle serial protocols).

So I started thinking...what is it I'm trying to do?

Well, initially, I want to boot up my SBC, open up a serial terminal on my Windows machine, and get a command prompt from the SBC. Type in a few little commands (i.e., like the Woz monitor) just to see that the RAM on the SBC is being altered. Etc.

Then I thought, "why not save the 65C22 for other things like a general purpose I/O device and use a MCU for the serial terminal communication with my PC?"

OK, if I did that, then perhaps I could do the following:

1) Use a micro-controller (Arduino or Propeller) that is connected to my PC with a USB/serial adapter I already have. This is easy. I send/receive data to MCU's all the time.

2) Wire the MCU to a certain I/O address of the 65C02. When the 65C02 STA's a value at this address (send buffer), capture that with the MCU. Then, relay that value out to the serial port to my PC. Set some status flag to "received".

3) When I type on my Windows keyboard (i.e., send data TO MCU), trigger an interrupt on the 65C02 and store the value in SRAM to a different address (rec buffer).

4) Interrupt on 65C02 would copy that value from the receive buffer to a slightly larger "keyboard buffer". 65C02 would detect if one of those keys was a RETURN, etc. It could also detect crude commands like "SHOW $D000", etc.

A VERY crude version of the Woz monitor.

The more I think about it, the more I think I want to create my own monitor. Maybe not as clever as Woz's. But something.

What do you think of this approach? Should I just skip all of this and wait for the 6551? Should I use a PIA that the Apple I used and just use the Woz monitor?

Suggestions appreciated.

Thanks!

[BigDumbDinosaur]

cbmeeks wrote:

So I started thinking...what is it I'm trying to do?...1) Use a micro-controller (Arduino or Propeller) that is connected to my PC with a USB/serial adapter I already have. This is easy. I send/receive data to MCU's all the time.

2) Wire the MCU to a certain I/O address of the 65C02. When the 65C02 STA's a value at this address (send buffer), capture that with the MCU. Then, relay that value out to the serial port to my PC. Set some status flag to "received".

3) When I type on my Windows keyboard (i.e., send data TO MCU), trigger an interrupt on the 65C02 and store the value in SRAM to a different address (rec buffer).

4) Interrupt on 65C02 would copy that value from the receive buffer to a slightly larger "keyboard buffer". 65C02 would detect if one of those keys was a RETURN, etc. It could also detect crude commands like "SHOW $D000", etc.

It's a lot easier with a real UART. What you are describing is, in my opinion, using dynamite to break open a piggy bank.

[cbmeeks]

BigDumbDinosaur wrote:

It's a lot easier with a real UART. What you are describing is, in my opinion, is using dynamite to break open a piggy bank.

No, booting up one of my many 8 bit computers (Commodore, Atari, Apple, etc.) would be a lot easier.

I'm not building a 6502-based computer because I enjoy easy.

I just have to work with what I have available.

[GARTHWILSON]

cbmeeks wrote:

Then I thought, "why not save the 65C22 for other things like a general purpose I/O device and use a MCU for the serial terminal communication with my PC?"

or have more than one '22. Another possibility is Daryl's 65SPI chip. If you have an SPI port, you can connect it to many things at once. Whether you bit-bang the SPI or go through Daryl's chip, you can use the 14-pin MAX3100 UART, or the 28-pin MAX3110 which is the same thing plus the line drivers and receivers. Bit-banging SPI is much, much easier than bit-banging RS-232, because SPI has no timing requirements; in fact, you can even service an interrupt in the middle of a byte transaction without fouling anything up.