Jump to content
BruceMcF

What's the state of play with serial port support?

Recommended Posts

NMI is reserved for PS/2. Technically you could snag it. Basically there are 2 6522s. The first one handles the PS/2 ports, joysticks, and the IEC bus. This VIA has its IRQ wired to NMI because we found that PS/2 was not working on all keyboards due to timing issues largely caused by IRQ handling delays. By moving it to NMI that eliminated audio, video, and other events from the IRQ and allows the KERNAL to assume that the only NMI events are keyboard or mouse related. If you enable a TIMER in VIA 1 it could be used as a watchdog. You’d just have to hook into the NMI loop.

Are you guys opposed to an SPI UART?


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
Posted (edited)
9 minutes ago, Lorin Millsap said:

NMI is reserved for PS/2. Technically you could snag it. Basically there are 2 6522s. The first one handles the PS/2 ports, joysticks, and the IEC bus. This VIA has its IRQ wired to NMI because we found that PS/2 was not working on all keyboards due to timing issues largely caused by IRQ handling delays. By moving it to NMI that eliminated audio, video, and other events from the IRQ and allows the KERNAL to assume that the only NMI events are keyboard or mouse related. If you enable a TIMER in VIA 1 it could be used as a watchdog. You’d just have to hook into the NMI loop.

Are you guys opposed to an SPI UART?


Sent from my iPhone using Tapatalk

Now you don't tell me that if you move the mouse while loading a file breaks the IEC bus (as this is big-banged and allergic to NMI)?

I'm not opposed to SPI, or SPI UART, in fact I think an SPI interface with potentially multiple devices on it is a nice thing - given that SPI is not bit-banged but using a real shift register. I've done USB-over-SPI on the Commodore PET userport using the VIA shift register, and can use a USB mouse on the PET just fine. But it required a) VIA shift out via SR, and b) a 74 series TTL serial-to-parallel shift register to shift in the data at the same time as SPI does. And it VIA can only handle SPI mode 3 "out of the box". See my solution here: http://www.6502.org/users/andre/csa/spi/index.html

Edit: the userport USB is here: http://www.6502.org/users/andre/cbmhw/cbmusb/index.html

Edited by Andre
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

In fact _my_ dream computer nowadays would just have a number of SPI-based module ports, and no parallel bus connector anymore. You could plug in SPI modules for serial, USB, memory, Ethernet, whatever you dream of.

And btw run your main computer on any fast speed as you like, as there is no external bus to take care of.

Edited by Andre
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
3 hours ago, Andre said:

Absolutely agree. A couple of cycles is ok, but if it gets more, the driver should back up and e.g. enable interrupt, if only to be able to break out of the wait loop and not maybe hang indefinitely. (does X16 have an NMI key?).

 

My experience has been that with a single tasking system and a decent buffer, polling the serial port uses fewer cycles and is more reliable than interrupt driven I/O. And it's certainly less code. But I don't see the harm in designing the implementation so that it can be polled or interrupt driven...

What I don't want to see is an interrupt-only system, since I want to retain the simplest possible I/O API for programmers - especially when using BASIC (as Commodore BASIC has no ON COM keyword.)

Since this actually has some peoples' interest, I'll work up a Google Doc for this, including the suggestions people have made.

I think we have the beginning of a workable specification; once I'm done moving, next month, I can grab a WDC prototype board and we can test this on a real VIA and an Arduino. 

https://docs.google.com/document/d/1HwHCv2txDu91l3uozRH8hwBrq6Fw06lmrQl3kidKQ1c

 

Edited by TomXP411
  • Like 1

Share this post


Link to post
Share on other sites
On 7/17/2020 at 4:02 AM, BruceMcF said:

The latter is what an EPP interface would rely on ... as far as I can tell, CA1 set to 0 and CA2 set to 001 so both are independent negative edge detects would be fine for an EPP protocol ... especially since what connects to EPP are typically ISA bus speed devices, so being unable to keep up with the CX16 would rarely be a problem.

Whether CA1 should trigger an IRQ or not depends on whether you want an interrupt driven routine or want to poll.

However, as the User Port is most recently specified, would require a little rewiring of the standard block header to parallel port connector so that /Reset is on a spare GPIO. WIth a jumper setting, the same cable could be used for a standard parallel port and for an EPP.

A custom parallel port protocol could indeed be faster by relying on the hardware handshake to allow you to read or write a packet with very little delay.
 

So I'm rethinking the pins to take your suggestions into account. The problem is that I don't know if there's a way to directly read CA1/CA2. Can I read those pins with a PEEK? Otherwise, I need a separate ACK line, since ACK is currently tied to CA1, which is also the interrupt pin. (And I don't want the board triggering an interrupt when I do a read cycle.)
 

Share this post


Link to post
Share on other sites
Posted (edited)
6 hours ago, TomXP411 said:

The problem is that I don't know if there's a way to directly read CA1/CA2. Can I read those pins with a PEEK? Otherwise, I need a separate ACK line, since ACK is currently tied to CA1, which is also the interrupt pin. (And I don't want the board triggering an interrupt when I do a read cycle.)

I'll leave this here, since it's still relevant to programming a software serial port.

(1) Either CA1 or CA2 or both can be used to trigger an IRQ, depending on the setting of the Interrupt Enable Register ... CA1, CA2, CB1 and CB2 IRQ enable are four of the seven interrupt enables in the VIA (the other three are two timer underflows and the serial shift register has completed 8 bits).

(2) As inputs, CA1 and CA2 can ONLY detect edge transitions, they cannot detect levels. The only really convenient way to detect both edge transitions without constantly resetting the CA&CB mode register is to tie them together and have one set to detect positive edges and the other set to detect negative edges. Then they will detect any edge transition since the last Read/Write of Port A. Having Centronics ACK tied to a GPIO makes more sense ... similar to the way that have external device Initialize under program control instead of tied to the CX16 system reset via the reset signal sent to the VIA makes more sense, but now unless Port B pin 6 and 7 are available to perform those functions, we are starting to run out of pins.

(3) By contrast, CA2 as /Interrupt detect, and then read the status to find out the cause of the interrupt would work fine ... CA1 really only has two states, for detecting positive or negative edge transitions and is ALWAYS reset after a Port A Read/Write, but CA2 can be used as an independent interrupt, so even if you are polling for the interrupt, you won't lose it because there was a Port A Read/Write in between the interrupt trigger and the poll.

(4) Both the Interrupt Flag Register and Interrupt Enable Register can be PEEKed or POKEd.

Edited by BruceMcF
  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, Andre said:

Absolutely agree. A couple of cycles is ok, but if it gets more, the driver should back up and e.g. enable interrupt, if only to be able to break out of the wait loop and not maybe hang indefinitely. (does X16 have an NMI key?).

The EPP is not a timing sensitive handshake, so it would be safe to have IRQ enabled, as long as all of the IRQ users respect the state of the handshake. In a fully IRQ driven I/O system, you can add that to your watchdog timer tasks.

In single tasking, if the busy loop is branch OUT on success, decrement X and branch back on nonzero, you can set a timeout and return with read/write failed.

Share this post


Link to post
Share on other sites
On 7/13/2020 at 11:43 AM, Lorin Millsap said:

Most of the pins on the second VIA are free and are mapped to the user port. This includes the shift registers.

To confirm, this "most of" means that PB6 & PB7 are in use?

Share this post


Link to post
Share on other sites
Posted (edited)
10 hours ago, Lorin Millsap said:

Are you guys opposed to an SPI UART?

If it's that SPI UART that is available in the +5v through pin package, I'm all in favor, whether it is because there is ONE free pin on Vera to enable a second SPI select (though in that case, it wouldn't be USING the +5v / through pin version, but I'd still want to be using that one, due to the expansion slot possibilities for re-using the same driver code) ...

... or because something is done to provide an SPI bus on the motherboard ... in the second case, bringing out SCLK, MOSI and MISO through block jumpers on the User Port would make the CX16 User Port a distinct step up from the C64 User Port.

But I've already made it clear the throughput available on a SPI UART is fine by me, I guess the question is directed to everybody else.

Edited by BruceMcF

Share this post


Link to post
Share on other sites
16 hours ago, BruceMcF said:

I'll leave this here, since it's still relevant to programming a software serial port.

(1) Either CA1 or CA2 or both can be used to trigger an IRQ, depending on the setting of the Interrupt Enable Register ... CA1, CA2, CB1 and CB2 IRQ enable are four of the seven interrupt enables in the VIA (the other three are two timer underflows and the serial shift register has completed 8 bits).

(2) As inputs, CA1 and CA2 can ONLY detect edge transitions, they cannot detect levels. The only really convenient way to detect both edge transitions without constantly resetting the CA&CB mode register is to tie them together and have one set to detect positive edges and the other set to detect negative edges. Then they will detect any edge transition since the last Read/Write of Port A. Having Centronics ACK tied to a GPIO makes more sense ... similar to the way that have external device Initialize under program control instead of tied to the CX16 system reset via the reset signal sent to the VIA makes more sense, but now unless Port B pin 6 and 7 are available to perform those functions, we are starting to run out of pins.

(3) By contrast, CA2 as /Interrupt detect, and then read the status to find out the cause of the interrupt would work fine ... CA1 really only has two states, for detecting positive or negative edge transitions and is ALWAYS reset after a Port A Read/Write, but CA2 can be used as an independent interrupt, so even if you are polling for the interrupt, you won't lose it because there was a Port A Read/Write in between the interrupt trigger and the poll.

(4) Both the Interrupt Flag Register and Interrupt Enable Register can be PEEKed or POKEd.

Just a simple addition:

(5) the IFR with the interrupt flags - and thus edge detection - can be read even when the interrupts themselves are disabled. CPU interrupts are only enabled if the IFR register bit _AND_ the corresponding IER (interrupt enable register) are set. Pls. have a look at the VIA datasheet for more details.

Share this post


Link to post
Share on other sites
14 hours ago, BruceMcF said:

If it's that SPI UART that is available in the +5v through pin package, I'm all in favor, whether it is because there is ONE free pin on Vera to enable a second SPI select (though in that case, it wouldn't be USING the +5v / through pin version, but I'd still want to be using that one, due to the expansion slot possibilities for re-using the same driver code) ...

... or because something is done to provide an SPI bus on the motherboard ... in the second case, bringing out SCLK, MOSI and MISO through block jumpers on the User Port would make the CX16 User Port a distinct step up from the C64 User Port.

But I've already made it clear the throughput available on a SPI UART is fine by me, I guess the question is directed to everybody else.

What about SSOP? It's not through-hole but better to solder than TQFP. E.g. this one https://datasheets.maximintegrated.com/en/ds/MAX3107.pdf (Note: haven't used it myself, just quickly googled it)

Or this one seems to be available in 14 pin DIP: https://docs.rs-online.com/ec74/0900766b80811942.pdf

  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, BruceMcF said:

I'll leave this here, since it's still relevant to programming a software serial port.

(1) Either CA1 or CA2 or both can be used to trigger an IRQ, depending on the setting of the Interrupt Enable Register ... CA1, CA2, CB1 and CB2 IRQ enable are four of the seven interrupt enables in the VIA (the other three are two timer underflows and the serial shift register has completed 8 bits).

(2) As inputs, CA1 and CA2 can ONLY detect edge transitions, they cannot detect levels. The only really convenient way to detect both edge transitions without constantly resetting the CA&CB mode register is to tie them together and have one set to detect positive edges and the other set to detect negative edges. Then they will detect any edge transition since the last Read/Write of Port A. Having Centronics ACK tied to a GPIO makes more sense ... similar to the way that have external device Initialize under program control instead of tied to the CX16 system reset via the reset signal sent to the VIA makes more sense, but now unless Port B pin 6 and 7 are available to perform those functions, we are starting to run out of pins.

(3) By contrast, CA2 as /Interrupt detect, and then read the status to find out the cause of the interrupt would work fine ... CA1 really only has two states, for detecting positive or negative edge transitions and is ALWAYS reset after a Port A Read/Write, but CA2 can be used as an independent interrupt, so even if you are polling for the interrupt, you won't lose it because there was a Port A Read/Write in between the interrupt trigger and the poll.

(4) Both the Interrupt Flag Register and Interrupt Enable Register can be PEEKed or POKEd.

 

Thanks. That ties in with what I've been thinking... let's discuss this in more detail on the new thread. (I think you'll find I've anticipated this answer and have added interrupt handling to the spec.)

 

  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, Andre said:

What about SSOP? It's not through-hole but better to solder than TQFP. E.g. this one https://datasheets.maximintegrated.com/en/ds/MAX3107.pdf (Note: haven't used it myself, just quickly googled it)

Or this one seems to be available in 14 pin DIP: https://docs.rs-online.com/ec74/0900766b80811942.pdf

Yes, the MAX3100, that's the one that is still available in through hole packaging and 5v power. AFAICT, all of the later ones in the series are only 3.3v, surface mount. Mouser carries that one ... Digikey doesn't carry it ... they have 95 of the $7 (Q1) in stock, and list a six week factory lead time for larger orders.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use