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

[BruceMcF]

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?

[BruceMcF]

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.

[Andre]

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.

[Andre]

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

[TomXP411]

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.)

 

[BruceMcF]

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.

[TheUnknownDad]

On 7/6/2020 at 4:21 PM, Lorin Millsap said:

Since ROMs can’t be easily put in the expansion bus there are several methods for handling the driver.



[...]



Method 3 which adds complexity to the card, is that a microcontroller on the card could do a DMA operation and inject code into system memory. During this operation the CPU is inhibited while the microcontroller accesses system memory. While this may sound like an appealing plug and play option it has drawbacks. Firstly making sure it’s code injection plays nice with other hardware and that it doesn’t use memory reserved for other purposes. Also if something does go wrong it’s possible for the card to lock up the system. In reality this method would likely be a real-time compiler so that the generated code could be relocated. It can be made to work, it’s just in my opinion more complex and more likely to cause issues versus loading the driver from the SD card. If it becomes corrupted it would be harder to fix.



 

Since I don't have access to any development information right now - is that already "set in stone" that expansion cards are not able to provide their own ROM "on the card"? Is method 3 the only work-around that does not involve adding drivers manually to the kernal or kernal infrastructure? I also haven't looked into that design either - is there public information on that available? Could it be sent to me? I sign NDAs too, if needed... ?

[BruceMcF]

22 hours ago, TheUnknownDad said:

Since I don't have access to any development information right now - is that already "set in stone" that expansion cards are not able to provide their own ROM "on the card"? Is method 3 the only work-around that does not involve adding drivers manually to the kernal or kernal infrastructure? I also haven't looked into that design either - is there public information on that available? Could it be sent to me? I sign NDAs too, if needed... ?

Given that the main memory map appears to be finalized, it does indeed appear to be set in stone that there is no ROM window that puts ROM on a card into the address space, unless a 32byte window in the I/O page will suffice.



There will, however, be User segments available in the flash ROM, so if some card makers want to collaborate on a technique to window into a ROM through one of the 32byte device address spaces and copy code into a RAM bank, then a single ROM image could contain the routines required to do that.

[TheUnknownDad]

23 minutes ago, BruceMcF said:

Given that the main memory map appears to be finalized, it does indeed appear to be set in stone that there is no ROM window that puts ROM on a card into the address space, unless a 32byte window in the I/O page will suffice.



There will, however, be User segments available in the flash ROM, so if some card makers want to collaborate on a technique to window into a ROM through one of the 32byte device address spaces and copy code into a RAM bank, then a single ROM image could contain the routines required to do that.

That sounds interesting. Will there be a kernel function to step through the expansion slots I/O memory areas and check whether there is a card and let that initialize itself (with maybe even copying a ROM into RAM, patching BASIC vector, stuff like that? That would make expansion slot extensions a lot more flexible and would not bother users to manipulate SD card content. It could even be that there is an address to be jumped at per JSR and that byte holds RTS but could actually contain a small boot code?

We could check whether 32 bytes can make nice init function for expansion cards...

Kernel could check if there is a magic number in I/O space and then hand over execution of code. It should be possible to deactive this expansion card initialization either via keypresses on reset or via menu/system config. Manual starting of this should also be possible then.

[TheUnknownDad]

I keep editing that post, so here a new post with a new idea:

To make this also a tinker's dream, let me build an expansion card with some SPI interfaces, some I2C, even I2S, some simple shift registers and even direct I/O.

You would want to have a nice interface for that, right? Be it some BASIC expansion that abstracts most of the protocol things away. Cool enough? But - why bother the user to install anything besides that card? Things get complex by themselves, so why not keep some things simple?

Obviously this is a more user convinience driven point of view. But I hope this computer is having its share, it should be overly complex to use - in my opinion. I couldn't really get an answer on what the design philosophy is regarding ease of use/user convenience. Most decisions seem to have a more technical reason so far...