Commander X16 Community Forums
https://cx16forum.com/forum/
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.
10 hours ago, Lorin Millsap said:
Are you guys opposed to an SPI UART?
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.
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.
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.
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
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.
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... ?
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.