6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Apr 26, 2024 5:08 pm

All times are UTC




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Mar 29, 2023 6:07 pm 
Offline

Joined: Sun Mar 19, 2023 2:04 pm
Posts: 137
Location: about an hour outside of Springfield
Sean wrote:
wayfarer wrote:
floobydust wrote:
Let's try this a different way.... from your response, it's apparent you don't understand much of the terminology that's being used, and/or what many of these I/O devices actually do or how they work.

Im not sure why you are getting that impression.
Some of what I am looking at, especially from GARTHWILSON, is that the 6522 is also used as intermediary between some ICs and the 65xx.


I think that's because when the IC's aren't conveniently able to be put directly on the bus (because of speed, pinout, etc.), or connected via a protocol that a bus-capable chip (UART, SPI, etc.) can communicate with, the 6522 can be used as an intermediary.


it seems pretty useful for where the target device cannot take parallel communications.
I think trying to directly do serial communication from the cpu would be a pretty weird use of a pin.
the 6522 seems to be especially suited for handling this and other tasks, that is the 6522 seems like its a lot more than just a parallel to serial converter.

so far, no one has brought forth any real replacement for the 6521/6522. It is shown you can run a 65xx without one for specific tasks.
I will do some searches on digikey and mouser for ICs that use those same x86 or 6500 'modes' or protocols for control, as some of them may also function by directly interfacing with the 65xx, as was mentioned for the 'good DUART' thats not around anymore and the alternatives that have been stated to work without a 6522. I am slowly compiling a short list of 3-4 common chips, DUARTS etc that are used with or without the 6522, more without.

Id also like to break down the protocols/types of devices that each of the Chips can perform well.
I am aiming to get a list or chart that says "I one is trying to do X or Y, then options Q or M are good and J is ill advised."


Top
 Profile  
Reply with quote  
PostPosted: Wed Mar 29, 2023 7:27 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
To clarify something from a few posts up for any readers who aren't very familiar with the popular serial protocols:

SPI sends one bit per SPI clock pulse, regardless of timing.  The clock signal is always generated by the master.  It is called "SCLK" or variations like "SCK" for "serial clock," and is entirely separate from, and independent of, the processor's clock.  With each clock pulse, one bit is sent from master to slave, and one from slave to master.  These are on two wires, each one being unidirectional, which are referred to as MOSI (master-out, slave-in), and MISO (master-in, slave out).  If the data in one of the directions is not needed, it can be dummy data, and is ignored.  The receiving end (both master and slave) accepts and locks-in a bit on one edge of the clock signal, and the sending end changes its data output to the next bit on the opposite edge of the clock signal.  Bit-banging the SPI master does not require timing anything at all.  You can insert any amount of delay you want, anywhere, even interrupting a byte, even mid-bit, like for the processor to service an interrupt, and it will resume without a problem when the processor gets back from servicing that interrupt.  (This goes for I²C as well.)

This is in huge contrast to UARTs and any asynchronous serial (which includes RS-232, RS-422, RS-485, some of the old tape modem protocols, and probably more I'm forgetting), because these have strict timing requirements, because that's the only way for the receiver to know it's supposed to be accepting any particular bit of a frame.  For example, at 9600bps, a bit time is 104.2µs.  The frame is started by a start bit, and the leading edge of that bit starts the receiver's timer.  The middle of that bit time is 52.1µs later, and the middle of each bit following is an additional 104.2µs after.  When receiving, the simplest UARTs (probably most of them) sample their RxD (receive data input) at these times, once per bit.  Others may take multiple samples around that time and "take a vote," to minimize the possibility of corruption from electrical noise picked up on the line.  Once a frame has started, you cannot interrupt it or you'll get data corruption.  Interruptions can only happen between bytes.  A frame consists of a start bit, usually 7 or 8 data bits, and a stop bit, and sometimes (rarely) a parity bit before the stop bit.  Obviously the transmitter and receiver have to agree on the speed as well, because timing is so critical.

Anyway, you can see why bit-banging SPI is so much more friendly than bit-banging a UART.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Mar 29, 2023 8:14 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1076
Location: Albuquerque NM USA
I have about 6 pcb designs and 3 prototypes with 6502 and/or 65816, none of them use 6522/6521. Most of designs use CPLD instead. Some designs are capable of video/ keyboard and work with CP/M like operating system, so they are not trivial designs. W65c22 plus W65c02 is $20 in small quantity. Commercial products are extremely cost sensitive.
Bill


Top
 Profile  
Reply with quote  
PostPosted: Wed Mar 29, 2023 8:51 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8143
Location: Midwestern USA
wayfarer wrote:
floobydust wrote:
Let's try this a different way.... from your response, it's apparent you don't understand much of the terminology that's being used, and/or what many of these I/O devices actually do or how they work.

Im not sure why you are getting that impression.

In reading what has been posted so far, I am getting the same impression that flooby is getting.

The field of digital electronics is vast, with countless thousands of devices that can do everything short of cure cancer. Even those of us who have been doing this stuff for many years don’t know about the full extent of what is available.

In my opinion, the route you are taking is not helping you. You need to define some achievable, clear-cut goals and then design a circuit at the block diagram level. With that done, you will begin to see what sort of I/O your hypothetical machine will need, which will guide you toward suitable hardware.

Looking at chips before working out a basic circuit is like looking at rivets before designing an airplane.

floobydust wrote:
A UART on the other hand, natively supports the serial protocol based on asynchronous standards that have been around for decades.

I should also note all of the NXP “industrial” UARTs, 28L92 et al (and the TI and Exar equivalents), support TIA-422 and TIA-485. TIA-485 is very robust and can be used to fashion a point-to-point network that can stretch for thousands of feet (nb: TIA-422, which is sort of a dumbed-down version of TIA-485, was the basis of the old Appletalk network).

It is also possible to program the 28L92 et al to operate in bi-synchronous mode, something that was once a feature in some IBM systems (can’t recall anymore where bi-sync was used). :D

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Mar 29, 2023 11:35 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1373
Ah, Bisync... haven't heard that term in ages. When I was in the field ('77 - '84) I had a handful of customers that used Bisync and SDLC. These were usually on leased line end points provided by Ma Bell. Bisync was used with 3270 terminals at remote locations for either 360 mainframes or System/3 Mod 15 midrange systems. Pretty sure all of my SDLC customers were on System/34 or System/38 machines connecting two sites with secure dedicated communications... kinda like a VPN between two networks, albeit 4800 - 9600 baud rates. I also had a couple customers that were using dial-up RS-232 on conditioned lines from Ma Bell... oh, the good 'ole days.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 30, 2023 1:05 am 
Offline

Joined: Sun Mar 19, 2023 2:04 pm
Posts: 137
Location: about an hour outside of Springfield
GARTHWILSON wrote:
To clarify something from a few posts up for any readers who aren't very familiar with the popular serial protocols:

SPI sends one bit per SPI clock pulse, regardless of timing.  ...

This is in huge contrast to UARTs and any asynchronous serial (which includes RS-232, RS-422, RS-485, ...
Anyway, you can see why bit-banging SPI is so much more friendly than bit-banging a UART.


This is an excellent post, I am going to copy this to the first page!
________________________________________________________________________________________________
BigDumbDinosaur wrote:
wayfarer wrote:
floobydust wrote:
Let's try this a different way.... .

Im not sure why ...

In reading what has been posted so far, I am getting the same impression that flooby is getting.

The field of digital electronics is vast, with countless thousands of devices that can do everything short of cure cancer. Even those of us who have been doing this stuff for many years don’t know about the full extent of what is available.

absolutely.
one of the guys in my old lab was William V. Stoecker, he has been using computer vision to identify skin cancer for over 30 years.
back in the "Top Gun" days, he used the same tech to spot melanomas.
We were using computer vision for everything from skin to pancreatic cancer.

The more I have learned in the years I have been to college, it is how little I really know. ;)

Quote:
In my opinion, the route you are taking is not helping you. You need to define some achievable, clear-cut goals and then design a circuit at the block diagram level. With that done, you will begin to see what sort of I/O your hypothetical machine will need, which will guide you toward suitable hardware.

Looking at chips before working out a basic circuit is like looking at rivets before designing an airplane.

so I totally get what you mean, and I will be making a thread for that. this is a reference thread that goes over the basics for myself and other people that search for those terms. The reserved second post is for the MAX3100, the 16550 and why people dont like it, a few other chips like that the Intel PIC looks interesting, and a section on mcu for these tasks. Ill be updating the posts over time as I learn new information.

I absolutely agree with what you are saying about a specific project and application; this however, is homework.

Quote:
floobydust wrote:
A UART on the other hand, natively supports the serial protocol based on asynchronous standards that have been around for decades.

I should also note all of the NXP “industrial” UARTs, 28L92 et al (and the TI and Exar equivalents), support TIA-422 and TIA-485. TIA-485 is very robust and can be used to fashion a point-to-point network that can stretch for thousands of feet (nb: TIA-422, which is sort of a dumbed-down version of TIA-485, was the basis of the old Appletalk network).

It is also possible to program the 28L92 et al to operate in bi-synchronous mode, something that was once a feature in some IBM systems (can’t recall anymore where bi-sync was used). :D

very interested in the RS-4xx serial stuff. Ill be reading more later.

Could I ask, what can the 6551 do that a common UART cannot or vice-versa?
Any other good parallel protocol chips to review for starters?


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 30, 2023 2:00 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8143
Location: Midwestern USA
wayfarer wrote:
Could I ask, what can the 6551 do that a common UART cannot or vice-versa?

Compared to later UARTs, the 6551 is primitive. The only UART that immediately comes to mind that is less capable is the MC6850, whose design lacks a bit-rate generator (however, the serialization/deserialization circuitry is more capable than the 6551). If you elect to use the 6551 you are employing mid-1970s technology. UART performance and capability substantially improved in the 1980s, leaving the 6551 and 6850 far behind. The current WDC incarnation is unfortunately hobbled by its stuck transmitter status bit, which significantly complicates the transmission side of the driver.

In my book, the chief negative associated with the 6551 design is its lack of a receiver FIFO. That omission sets a hard deadline on when the receiver must be read during continuous data inflow. In a system using IRQs to handle TIA-232 data flow, the interrupt handler must perform with considerable alacrity at high data rates. Otherwise, an overrun error will occur, permanently corrupting the data stream.

Another 6551 deficiency is the lack of flexibility. Back when the 6551 was designed (c. 1976), cost was more a concern than flexibility, and some design decisions based on the former negatively affected the latter. I no longer recall the things I’d consider show-stoppers by today’s standards (some had to do with handshaking features), but I can say in all these years I only used the 6551 in one project, a serial interface for a Commodore 128DCR. Shortly afterward, I learned about NXP (then Philips Electronics) UARTs, and never looked back—that was 33 years ago.

Quote:
Any other good parallel protocol chips to review for starters?

To which protocol are you referring?

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 30, 2023 3:27 am 
Offline

Joined: Sun Mar 19, 2023 2:04 pm
Posts: 137
Location: about an hour outside of Springfield
BigDumbDinosaur wrote:
wayfarer wrote:
Could I ask, what can the 6551 do that a common UART cannot or vice-versa?

Compared to later UARTs, the 6551 is primitive. ... I can say in all these years I only used the 6551 in one project, a serial interface for a Commodore 128DCR. Shortly afterward, I learned about NXP (then Philips Electronics) UARTs, and never looked back—that was 33 years ago.

Quote:
Any other good parallel protocol chips to review for starters?

To which protocol are you referring?


agree on the 6551, it seems like GARTHWILSON has a lot of use for them and knows their nuances. I would say, for specific 65xx things and integration they appear to be good on the surface, I am more interested in other chips myself.

Parallel protocols like the x86/8080 and 6800 control stuff for the chips like intel 8259/a, the national semiconductor USBN9603/USBN9604, and several others such as the Sitronix ST7528 lcd driver.
From the TL28L92 data sheet
Quote:
Pin Programming Selects 68xxx or 80xxx Bus


those, I think, you can drive a lot of those from the 65xx with "bit banging" as direct connections. Like you could that DUART or the 6522, you do not need an intermediary controller/adapter/etc. a 65xx rather needs an I/O chip if you want to do much with it I think. Some chips bridge or implement a protocol or system.

I am looking at identifying those chips and functions that can go closest to the 65xx, to act as the, or one of the, primary I/O chips up to and including replacing the 6522. several duart chips exist, an interrupt priority queue and an lcd controller. Maybe a USB or such, or a variety of mcu. not a lot of things 'take the place of' the 6522.


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 30, 2023 8:24 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
wayfarer wrote:
GARTHWILSON wrote:
To clarify something from a few posts up for any readers who aren't very familiar with the popular serial protocols:

SPI sends one bit per SPI clock pulse, regardless of timing.  ...

This is in huge contrast to UARTs and any asynchronous serial (which includes RS-232, RS-422, RS-485, ...
Anyway, you can see why bit-banging SPI is so much more friendly than bit-banging a UART.

This is an excellent post, I am going to copy this to the first page!

To show the serial data transfer, I took this diagram from the Microchip SST26VF064 SPI flash memory IC data sheet and edited it a bit since what they showed left out some detail that anyone who's new to SPI might want.  The transaction begins with the CE\ line falling, and then it's showing the sending of the instruction ($35) meaning "Send me the contents of the configuration register" (during which the flash is silent), followed by the flash sending whatever byte was in the configuration register (and the master has no more need to send anything during that time, nor will the flash even listen if it did):
Attachment:
26VF064readConfig.gif
26VF064readConfig.gif [ 32.25 KiB | Viewed 8765 times ]

This shows operation in SPI mode 0, and with the dotted lines, mode 3. There's also mode 0 and mode 2, changing the clock polarities.  I usually don't know what mode I'm in.  I just do what the data sheet says, and it always works.

SPI can send a bit in each direction with each clock pulse, both directions at once; but in most cases I've worked with, you're only concerned with one direction at a time, and the other direction just has dummy data.  I picked this diagram from the data sheet because it was much simpler than other operations where you send it a 24-bit address and then read or write multiple bytes of data for example.  The instruction is sent asking for information, and then the information is sent.

The diagram shows clock edges that are equally spaced in time.  This isn't necessary though.  In fact if you're bit-banging, they will almost definitely not be equally spaced, especially the clock-high versus clock-low times, and if you service an interrupt before you're done with the SPI transaction, you could put a vertical cut the diagram and stretch the two (or more) sections as far apart as you like, and it won't corrupt the transfer, only delay its completion.

Such is not the case with UARTs though.  The following diagram shows a UART's output when sending a byte.
Attachment:
UART-timing-diagram.gif
UART-timing-diagram.gif [ 5.45 KiB | Viewed 8765 times ]

The bit time must be rather precise, because since there's no clock line, the time is all the receiver has to go on to know when to sample the line for the next bit.  A frame is typically ten bits, ie, a start bit, eight data bits, and a stop bit.  Let's say you're running at 9600bps.  From the time the start bit begins (which starts the receiver's clock), to the middle of the last previous data bit is 885.4µs, and from there to the transition from the previous or next bit (which is the stop bit) is only 52.08µs, which is less than 6%, even if there were no jitter or noise.  If the transmitter speed is off by 3% in one direction and the receiver speed is off by 3% in the other direction, you'll have errors.  Normally a crystal oscillator is used for accuracy.  A ceramic resonator is normally accurate enough too, but an RC oscillator will be trouble.  If you bit-bang, you'll have to carefully count cycles and not allow interrupts in the process.  ...And after all that, the data transfer will be pretty slow compared to how fast you can bit-bang SPI.

I will reiterate that I don't think a FIFO was needed on the '51, because it was usually mated to a 6502 which has excellent interrupt performance compared to many other processors.  Let's say it's 1980, and your 6502 is running at 1MHz, and you're receiving data over RS-232 again at 9600bps.  The processor will experience over a thousand clock cycles, approximately 250 instructions, in the time it takes to receive a single byte.  Obviously it's not pressed for time.  Let's go five or ten years later, and let's say you're receiving at 115,200bps, and running a 65c02 at 4MHz.  The processor will experience over 347 clock cycles, approximately 87 instructions, in the time it takes to receive a single byte.  Still no challenge, and that's almost the fastest the '51 is guaranteed to work.  Now if it were a 68000, then you bet, it would need a FIFO, because according to page 2 of this article, the maximum interrupt latency for a no-wait-state 68000 system is a whopping 378 clock periods!  So yes, the 68K would need a FIFO, and would want to handle a lot of bytes with each interrupt.  Otherwise you would definitely get overruns.

The Wikipedia article on UARTs has a list of models at https://en.wikipedia.org/wiki/Universal ... ART_models .  The '51 is there, with a link to another article about it.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 30, 2023 3:29 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
FWIW, in recent discussions about an SBC design we looked into the question of available UARTs, and I have some notes (by @hoglet) from that time, shared with permission:
Quote:
My summary would be:

1. Having a UART that supports automatic-RTS with a programmable threshold is not essential. This is because the mini MOS UART driver needs to be interrupt driven with a buffer, otherwise escape detection won't be possible. And so that driver can manually control RTS (as the current MC6850 Mini-MOS driver does) based on the driver receive buffer threshold. This is better anyway, as that buffer will be larger (256b). So really the main purpose of any buffering on UART itself is just to overcome any interrupt latency. So 4 bytes or more is sufficient, and you could possible get away with less.

2. Looking at the currently available Dual Channel UARTs, they fall into just the following three families:

  • "type 16", for example TL16C2552 (descendents of the 16550)
  • "type 92", for example Exar XR88C92/XR88C192 / NXP SC28L92 / TI 28L28) (descendants of the SCC2692, SC26C92, SC2N681
  • "type 681", for example Exar XR68C681 (descendents of the MC68681)
One key difference is the "type 92" and "type 681" both have a general purpose counter/timer, which the "type 16" lacks.

None are available in DIP, and in fact PLCC-44 is the most hobbyist friendly package still in common use.
The "type 16" seems to be the most popular / widely available, and is consequently a bit cheaper, but you would need a separate device like a 6522 for timer interrupts. Or use an I2C RTC and interface with something like a PCF8584.

We then dug a little deeper, and it turns out the "type 92" and "type 681" have compatible pinouts, and very similar register sets, so could be easily supported by a common driver. The only real difference is the bus interface: the "type 681" can be more easily interfaced to a 68K. But for interfacing to a 6809 there is little difference.

So the conclusion was probably to go with the 92 or 681, in a PLCC44 package, e.g.


For me, one important point is the discovery that some modern UARTs also have timers and GPIO, which means the UART can also serve as a VIA: one peripheral chip instead of two. And we also thought a dual UART (DUART) could be useful if one channel is for user access and the other for debug, or for a serial-connected subsystem such as storage, or display.

Although the project in question is for a 6809 system, everything applies to 6502 equally well.


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 30, 2023 5:16 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8143
Location: Midwestern USA
wayfarer wrote:
Parallel protocols like the x86/8080 and 6800 control stuff for the chips like intel 8259/a, the national semiconductor USBN9603/USBN9604, and several others such as the Sitronix ST7528 lcd driver.

Your terminology is not correct. What you are talking about are bus protocols, not parallel protocols. Things do not necessarily occur in parallel with many microprocessors. For example, during a write cycle, the 6502 will place an address on the address bus before it will place data on the data bus. This skew between the address and data buses is illustrated in the timing diagrams. This behavior is especially true with the 65C816, which places the A16-A23 address component on the data bus during Ø2 low and then switches the data bus to data mode during Ø2 high.

Quote:
From the TL28L92 data sheet
Quote:
Pin Programming Selects 68xxx or 80xxx Bus

those, I think, you can drive a lot of those from the 65xx with "bit banging" as direct connections.

No sir. There is no bit-banging involved. Data is written into or read from the 28L92 a byte at a time. A register is selected by placing a bit pattern on the address pins and asserting chip select. In that respect, a 65xx MPU accessing an 28L92 is like accessing a 6522. The only thing that is different is the manner in which the 28L92 is told about the bus cycle.

The selection of the 68K or x86 bus only changes the nature of the bus cycle expected by the 28L92. In x86 mode, separate read and write inputs on the 28L92 tell it when to emit or accept data. The read and write signals are derived from the 65xx R/W signal, which is gated by Ø2 so read/write is only valid when Ø2 is high.

In 68K mode, read/write is connected to the MPU’s R/W output (high = read, low = write) and it is the chip select that is gated according to the clock. The 65xx family partially implements the Motorola-style bus sequencing, but not to a level where best performance can be achieved. For that reason, I recommend in my writeups about interfacing the 26... series UARTs with the 65xx family that the x86 mode be used.

BTW, my experimenting with the NXP 26... series UARTs in 65xx systems goes back to 1991. My POC V1.3 unit, 65C816-powered, has two 28L92s, providing four high-speed TIA-232 ports. All four ports can simultaneously run at 230.4 Kbps in both directions.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 11, 2023 10:15 pm 
Offline

Joined: Wed Aug 21, 2019 6:10 pm
Posts: 217
Proxy wrote:
wayfarer wrote:
So to be clear, the 6522 does give you SPI and I2C on it's own?

the 6522 doesn't have hardware SPI or I2C as the datsheet never mentions that.
but anything can become an SPI/I2C controller if it has programmable IO pins, which the 6522 has. so you just have to implement the interfaces in software. ...


Note, though, the 6522 can provide hardware support over just bit banging.

(1) First, you can bit bang the output and use the serial shift register for input by connecting MISO to CB2 and SCLK to CB1 and putting the serial shift register into operation mode 011 (bits 2 through 4 in Auxilliary and Shift register control at VIA+$0A). The shift register mode 011 shifts after the rising edge on CB1, so that is for Mode0 or Mode 3 ... you would need to invert the SCLK line to do this with Mode1 or Mode2.

(2) Second, with the 65C02, you can use the write hardware handshaking pulse mode, mode 101 in CA2 control, bits 1-3 in PCR at VIA+$0C (in Port A, since the pulse mode uses either CA2 or CB2, and the serial shift register uses CB2), to generate a Mode3 SCLK pulse on CA2. Wire PA7 to MOSI, write the data into Port A, then do a series of seven "ROL PORTA" operations to pulse the SCLK line eight times. The 65C02 "Read-Modify-Write" operations appear on the bus as Read-Read-Write, so with only one Write cycle, the ROR operation and the 6522 pulse mode work together correctly. (IIRC, the NMOS6522 does a write on the bus during the modify phase, and if that is correct, then an NMOS 6502 would requite "LDA PORTA : ROL : STA PORTA").

Mode 0 can be done with a two-input AND gate, with inputs from CA2 and one of the PB lines as an output GPIO and CA2. Putting 0 in the GPIO before selecting the Mode 0 device pulls the clock line low. Then the data is written to the output port, and then the GPIO is set high, which raises the SCLK line, followed by the series of seven "ROL PORTA" operations.

This leaves 7 GPIO on the VIA PortB, for SPI selects, or 5 if two are reserved for a bit-banged two-wire interface.

Also note that if you have a faster board, the 6522 pulse mode has a pulse of a single clock cycle, so if you have an 8MHz board, the pulse will require an SPI device that can accept a 4MHz or faster SCLK.

Also note that with a 4 gate, 2 input NAND, you can use this to generate all four Mode serial clocks lines side by side, making mode selection a matter of which SCLK line you connect to which device. Connect CA2 and CB1 directly together, so that internally your MOSI and MISO registers are running in Mode3. Use one NAND gate with a PBn output to generate an inverted Mode 0 serial clock, which is SCLK_Mode2. Use the second Nand gate as an inverter to generate SCLK_Mode3, and use the third Nand gate as an inverter to convert the baseline Mode3 input into Mode1.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 20, 2023 11:38 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
BruceRMcF wrote:
(2) Second, with the 65C02, you can use the write hardware handshaking pulse mode, mode 101 in CA2 control, bits 1-3 in PCR at VIA+$0C (in Port A, since the pulse mode uses either CA2 or CB2, and the serial shift register uses CB2), to generate a Mode3 SCLK pulse on CA2. Wire PA7 to MOSI, write the data into Port A, then do a series of seven "ROL PORTA" operations to pulse the SCLK line eight times. The 65C02 "Read-Modify-Write" operations appear on the bus as Read-Read-Write, so with only one Write cycle, the ROR operation and the 6522 pulse mode work together correctly.

I'm surprised that worked. I would have thought "ROL PORTA" would send three clock pulses - one for each read cycle and one for the write cycle - and mess everything up. When I've done this in the past I've taken care to only perform one operation per bit.


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 21, 2023 10:31 pm 
Offline

Joined: Wed Aug 21, 2019 6:10 pm
Posts: 217
gfoot wrote:
BruceRMcF wrote:
(2) Second, with the 65C02, you can use the write hardware handshaking pulse mode, mode 101 in CA2 control, bits 1-3 in PCR at VIA+$0C (in Port A, since the pulse mode uses either CA2 or CB2, and the serial shift register uses CB2), to generate a Mode3 SCLK pulse on CA2. Wire PA7 to MOSI, write the data into Port A, then do a series of seven "ROL PORTA" operations to pulse the SCLK line eight times. The 65C02 "Read-Modify-Write" operations appear on the bus as Read-Read-Write, so with only one Write cycle, the ROR operation and the 6522 pulse mode work together correctly.

I'm surprised that worked. I would have thought "ROL PORTA" would send three clock pulses - one for each read cycle and one for the write cycle - and mess everything up. When I've done this in the past I've taken care to only perform one operation per bit.


In the write handshake mode, the 6522 pulses the data available pin on every write. It ignores reads. But that did not give a single pulse on ROL in the NMOS 6502 and family (like the NMOS 6510 in the C64), since the "modify" in a "read-write-modify" operation was a write ... but the 65C02 changed that to a read on the modify.

But do note that it is not a "wire-only" system ... as noted above, you need a clocked d-latch (eg, one gate on a 74x74) to lag the pulse from CA2 to CB1 by a half phase, so that CB1 is pulled down on the rising edge of PHI2 and pulled up on the following rising edge of PHI2, and since the datasheet notes that the data must be valid one full clock cycle after the rising edge of the CB1 external pulse, then you need a transparent d-latch that latches when a Mode0 or Mode3 SPI serial clock rises ... which means if the latch enable is active low as with the 74x75, you need to invert the SPI serial clock to get the d-latch enable. So half of two dual bit latches and an inverter.

And since this is a Mode3 system, to control a Mode0 SPI device you need to be able to hold the serial clock on the SPI bus low while the master serial clock is idle high. If you have a spare AND gate, you can dedicate a VIA GPIO to that task, fed into the AND with the internal serial clock, and the output taken as the SPI bus serial clock. For Mode0 operation, the GPIO is taken low before pulling the select low, then after the first bit is output, the GPIO is taken high. Then when the SPI output byte has been sent and input byte received, the GPIO is taken low again.

A handy way to do this is to store the Mode0 state with a TSB/TRB bit flag for the GPIO that controls the Mode0 phase shift. Then the state for Mode3 is to just store a #0 in the CPOL status location, and "LDA CPOL : TRB VIA_PORTB" will take the GPIO low if the appropriate bit is set in the CPOL byte, and just be an eight clock NOP if CPOL is zero.

It is handy if PB6 or PB7 is used for that phase shift bit, since then you can test if CPOL is set up for Mode3 with a BIT instruction and the S or V flag, and handle the first bit in a side routine if the SPI bus is working in Mode3.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 38 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: