As I'm designing my SBC, I want to test individual parts of it. Such as the VIA's and ACIA sections.

I'm using Daryl's SBC2.5 as a reference (minus the MAX232) and decided to build a prototype ACIA card for my Apple IIe. The Apple will give me a great platform to test on and it reminds me of how the Apple 3, Lisa and Mac were all designed with Apple II's driving them at first.

Anyway, I wrote a quicky BASIC program to poke some values into slot 4 and I got my "Hello World" on my other computer. Victory!

The wiring is a complete mess but this is just a prototype to test with anyway.

Not bad for a New Year's Day build.

_________________
Cat; the other white meat.

Sometimes I wish there were a "Like" button to express my pleasure without cluttering the forum with an otherwise useless post like this one!

_________________
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?

Excellent first light! Always good to hear about concrete progress.

Agree Garth, but also posting to indicate the same!

(Other than time and money, enthusiasm is the other vital resource for making project progress - I think encouragement can help with that. It's good to know that you have an appreciative audience, even if they don't have anything technical to offer at the time. I suppose there's a point where there are too many such messages, but I think we're a long way from that here.)

Wasn't there an issue with 65xx peripherals on Apple because the /DEV signal was qualified with PHI2 using 74ls138 and hence was asserted after PHI2 went high? How did you address this?

Something I've done sometimes, but not nearly often enough, is to send a PM to accomplish the purposes.

_________________
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?

Congrats on getting the 65C51 operating. I noticed you have the WDC part and as much as I can make out from the photo, it's the newer chip recently released which also has the Xmit bit problem. As you've been using poke statements from BASIC to send out characters, the timing seems to add enough delay. Just be aware that you start writing a driver to run the chip, you'll need to manage the transmit with a timing loop.

_________________
Regards, KM
https://github.com/floobydust

Thanks for the kind words everyone. I may try to take it further and put a Max232 chip on there but I haven't found that I need it.



Hmm. I'm not aware of the issue you're talking about. Do you have a reference for it?

This isn't the first 65xx card I've built for the Apple IIe. In the past, I built a Mockingboard clone using two 65C22's and they worked fine.

Regarding the 65C51, all I really did was tie one of the chip selects to /IOSEL from the Apple IIe. Oh, I also tied the PHI2 pin of the 65C51 to pin 39 of the 6502. On the prototype card, it's called "T1". There's also a "T0". So I believe that's the slightly delayed phase 1 output from the CPU. So, maybe that's how it worked?



You are correct. I remember looking this up a while back and determined I do, in fact, have the "defective" chip. I also believe you're correct in BASIC is slow enough that I was able to get away with simply poking values.

Now, for those that are interested, I did notice that it wasn't 100% reliable. I ran my program that sent "HELLO WORLD " to my host computer and that's it. I did it probably 50 times before I posted this and I swear it worked every time.

However, shortly after that, it would send HELLO W" or "HELLO WORL". Sometimes it would chop off a few characters and replace with garbage. So, I realize what I did wasn't a proper driver. I had the speed set to 19200 so that may be way too fast for BASIC.

But that's OK. I just wanted a test bed to prototype the chip.

However, it's sparked enough interest that I may try to write a true driver in ASM. I don't really *NEED* this card considering I have the excellent SSC. It's all just fun and games.

_________________
Cat; the other white meat.

Just use a 6522 VIA timer in one-shot mode, and re-start it every time you send a byte to the ACIA. Then you don't need a timing loop in software, and the computer can do something useful while waiting.

_________________
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?

The TIA-232 speed affects the bit rate per datum sent or received on the (serial) wire, and has no direct relationship to how often you can process a datum. If you only write one datum per second it will still be serialized and transmitted at the rate of 19,200 bits per second, which is an interval of approximately 52 microseconds per bit. Assuming 8-N-1 format, 19.2Kbps is effectively 1920 bytes per second, amounting to approximately 521 microseconds per byte sent.

Where the data rate does become a factor is when the particular UART being used has no receiver (RxD) or transmitter (TxD) buffering, which is the case with the 65C51. In this case, you must immediately read RxD when the UART indicates a datum is present, and of course, you cannot write a datum to TxD until the UART indicates that it can accept it. Failure to immediately read RxD when a datum has been de-serialized will result in its loss should another datum arrive before the present one is read—an overrun error.

In the case of transmission, writing to TxD before the UART can serialize and send the datum will result in corruption or loss. All UARTs indicate to the microprocessor in some way when they can accept a datum for transmission. Unfortunately, that function is broken in the WDC 65C51. Hence a timing kludge has to be introduced to pace writes to TxD at a rate that is somewhat slower than the theoretical maximum for the serial data rate being used. Although BASIC's POKE statement is relatively slow-executing, it is likely the Apple II can write to the 65C51 faster than the latter can serialize and transmit, even at 19.2Kbps, which would explain the dropped characters.

This interesting experiment of yours is yet another case of highlighting the primitive and outdated nature of the 65C51. The 65C51's ancestry is that of the NMOS 6551 developed in the mid-1970s at a time when chip manufacturing was very limited compared to today. Much better UARTs exist—even the contemporaneous Motorola 6850 is a better device, and that's not saying much. Since those days, UARTs have incorporated much faster bus interfaces, have acquired features to reduce the likelihood of overrun and framing errors, don't demand as much processing as the old units to generate data flow, are much more adaptable to different applications, and support very high data rates. While I like working with the relatively ancient technology of the 65C02 and 65C816 (which is not to say that x86 technology is any less ancient—it's traceable in some ways to the Intel 8080), my interest doesn't extend to hobbling the system with antiquated and bug-prone I/O hardware.

Slightly OT, but not too much, is something I've been intermittently working on, which is a white paper on how to adapt NXP's 28L92 dual UART to a 65C02 or 65C816 system, the 28L92 being what I use in POC V1. It supports standard serial speeds up to 230.4Kbps, non-standard speeds up to 921.6Kbps, has 16-deep FIFOs (a big help in reducing the volume of IRQs), full CTS/RTS handshaking, programmable I/O pins, and a precision counter/timer, the latter which is the time base for POC V1 vi a 100 Hz jiffy IRQ. The 28L92 can be used with either 3.3 or 5 volt systems, with no loss of performance on 3.3 volts. My paper will include example interrupt-driven driver code that has been derived from what I have running on POC V1 and in use on Lordbubsy's MARC2 65C816 computer, which has a 26C92, the 8-deep FIFO predecessor of the 28L92.

NXP also makes a single channel version of the 28L92 called the 28L91, which is also adaptable to the 65C02 and 65C816. The 28L91 is functionally identical to the 28L92, except for having only one serial channel. My white paper will cover its use as well, in case anyone is interested.


—————————————————
EDIT: Attached data sheets.
—————————————————

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I will be very interested. I bought two of the bugged ACIAs(one for internal system use, and the other as a general-purpose serial port), thinking that the bug would be easy enough to work around. Not so. In the only routine I've written that uses it, I'm using a SEI/WAI to pick up the VIAs T2 interrupt, but I have to account for the fact that it could be something else the user has set up. That got ugly quick.

Given that it's not likely to go away anytime soon(given what I've heard), I think I'll try going to one of the NXP parts in the next iteration of my build, probably the dual-port one.

I expect that it would. A different kludge would have the VIA timer interrupt telling the UART driver that it is safe to load another byte into the transmitter. Doing so, of course, means you are using two devices to do the work of one, which is annoying, to say the least.


Problems with the WDC 65C51 were discovered in June 2013, and were reported at that time to WDC. Later on, the specific errata, the stuck TxD status bit, was identified, and also reported to WDC. Here it is, three-and-one-half years later, and a fix apparently isn't forthcoming. I predict that there will be no fix for this problem.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Especially if you have two or more VIAs, you're likely to have a spare timer to do the job, so it's not too bad. When the timer has expired, you know you can feed the '51 another byte without having to also poll the '51 (which would be fruitless anyway).

_________________
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?

Right. I envision the workflow would sort of follow this:

1. An initialization function would be called that would do the following:
   
   
   • Set up the VIA timer in one-shot mode.
   • Load the timer registers with the value required to properly pace the transmitter. That value would depending on how fast Ø2 is running and the data rate of the UART. For example, at 19.2Kbps with 8-N-1 data format, the minimum interval between byte transmissions would be ~520 microseconds. So the timer should be set to underflow at about 600 microsecond intervals to provide a margin of safety.
   • Configure the VIA to interrupt when the timer underflows.
   • Set a flag somewhere in RAM to indicate that the timer is set up but not running (more on this below).
   • Initialize the transmit FIFO (circular buffer) indices. Generally that entails setting the "put" and "get" indices to $00. FIFO management is something discussed in Garth's interrupt primer—I won't go into it in this little writeup.
   
   The driver is ready for use.
   
   
2. Following initialization, the foreground part of the driver does the following to transmit data:
   
   
   • Check that the byte can be added to the FIFO. If not, the driver can either block (what my NXP driver does) or return and indicate to the caller that the FIFO is full.
     
     
   • Add the byte to the FIFO and adjust the "put" index as required.
     
     
   • Check the "timer is stopped" flag. If the flag is set, meaning the timer is not running, do the following:
     
     
     • Clear the "timer is stopped" flag.
     • Start the timer.
     
     
   • Exit. There will be a delay equal to the timer time-out period before the first byte is transmitted. This delay will most likely be inconsequential. If more than one byte is in the FIFO waiting for transmission, transmission will be continuous at the rate determined by the timer interval.
   
   
3. After being started by the foreground, the timer will eventually underflow, stop and cause an interrupt. The interrupt part of the driver (the ISR) does the following:
   
   
   • Check the transmit FIFO to determine if there is anything to transmit. If the FIFO is empty the ISR does the following:
     
     
     • Set the "timer is stopped" flag.
     • Exit. There is nothing else for the ISR to do.
     
     
   • If the FIFO is not empty, the ISR will do the following:
     
     
     • Copy the byte at the head of the FIFO into the transmitter and adjust the FIFO "get" index as necessary.
     • Start the timer.
     • Clear the "timer is stopped" flag.
     • Exit.

Regarding the "timer is stopped" flag, that would be best implemented with bit 7 of the chosen location being set to indicate the timer is not running. The condition of the flag can be conveniently tested with the BIT instruction. Setting and clearing the flag can be done with the TSB and TRB instructions, respectively, if you are using a 65C02 or 65C816. These two instructions also report the state of the flag prior to modifying it.

It's all so simple! Basically, much of the above mimics in software what a properly functioning UART would do in hardware.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!