Commander X16

5 hours ago, Sandmage said:

I've just noticed that the Ulitmate1541 has a builtin modem now. I've been surfing BBSs the last hours, it's working great. It should be possible to hook the address- and databus to the cartridge. The Expansion ports expose the whole Address and Databus. Of course the cartridges software will not work, but it can be controlled via telnet, so that shouldn't be necessary.

That won't work. The memory map on the Commander is completely different, and the 8MHz clock would also necessitate an intermediary. By the time you're done, you'd have spend more time and effort building an interface adapter than just building a new I/O unit. The Ultimate should be able to work as an IEC disk drive, but you won't have access to the RAM expansion, SIDs, or Swiftlink modem.



I think the way to go for serial is to simply build a 6551-based Swiftlink clone. There are several people making them for the Commodore 64 and 128, so adapting that to the Commander should not be too difficult. The current implementations are interrupt-driven and can deliver 38.4K on a 1MHz 6510. So we should be just fine using that for up to 115K on an 8MHz 65C02. 



At one point, I was also going to write a serial library for the User port. It looks like I'll be re-visiting that plan, as well. I don't really want to write a 2-wire RS-232 driver, since that's slow and requires exact timing. Instead, I'll build a parallel version that uses all of the GPIO pins on the User port. Since it's supposed to be Centronics compatible, we'll have at least 12 bits plus a clock line, and that's enough for what I have planned. (3 control lines and an 8 bit data bus.)

Actually using a 6551 is not a good idea. The modern in production 6551s have a serious hardware bug. You are better off using a more modern UART. There are lots to choose from.


Sent from my iPhone using Tapatalk

7 hours ago, Lorin Millsap said:

Actually using a 6551 is not a good idea. The modern in production 6551s have a serious hardware bug. You are better off using a more modern UART. There are lots to choose from.





Sent from my iPhone using Tapatalk

We've had that conversation, too: the send data status register bit is defective on WDC units, and that is not a problem with other manufacturers' units. Just buy a different brand, and it's all good. 

Since this is the chip used in the Swiftlink cartridge and the clones, it's the easiest one to adapt for the CX16 - there's already tons of software out there that uses it, and we wouldn't need to re-write the serial I/O routines. We can just adapt an existing circuit and existing code to make it work.

Here's an example of a Swiftlink clone with an ESP32 to show what I mean... it's a super simple board:





https://www.lemon64.com/forum/viewtopic.php?t=75130



 

 

 

We've had that conversation, too: the send data status register bit is defective on WDC units, and that is not a problem with other manufacturers' units. Just buy a different brand, and it's all good. 
Since this is the chip used in the Swiftlink cartridge and the clones, it's the easiest one to adapt for the CX16 - there's already tons of software out there that uses it, and we wouldn't need to re-write the serial I/O routines. We can just adapt an existing circuit and existing code to make it work.
Here's an example of a Swiftlink clone with an ESP32 to show what I mean... it's a super simple board:


https://www.lemon64.com/forum/viewtopic.php?t=75130

 
 
 

The problem is that other brands are not really an option as they are not in active production and the vintage ones don’t have the speed rating.

The other modern UARTs are better in pretty much every way. They have larger buffers, they can handle greater speeds, they don’t have hardware bugs, and they are way less expensive. There are a couple reasons we don’t have it. Personally I wanted a UART but the reasons for not including it were legitimate and it can be added via expansion card. The system will still have onboard capability, just not as fast.


Sent from my iPhone using Tapatalk

I'm perfectly happy with networking with one of those offboard widgets that emulates a modem, which kind of narrows the CX16 side to serial support. I don't know how fast the User Port can do bit-banging serial, but if it uses the serial shift register to receive that might make for fewer dropouts.



As far as a cheap serial interface card, the Max3107 has a built in oscillator, 128 byte buffers, and IIRTDC (if I read the datasheet correctly) hardware flow control support. It's a tiny surface mount part, but that's not an issue for a built board. (No, I don't know if it's active or obsolete and selling the stock out, last I saw it in a parts list, it was awfully cheap, $2-$3 Qty1, so that could have been the last run on their way out the door. The Maxim3140 was a lot more expensive, nearly $10 Qty1.)

Why it wouldn't be an option for the CX16 main board is in addition to being surface mount, it's a SPI/I2C part (at that scale pins cost more money than the silicon to include slave serial buses), so with Vera having no pins to use for multiple selects to share with the SD card bus, it just doesn't fit for the reference design.

As far as being an SPI/I2C part, Andre Fachet did a 6502 bus SPI 4-device bus master on FPGA about a decade ago, so until I hear of a fatal flaw with that design, I'm going to keep my eye open for inexpensive SPI chips to bundle into a single expansion port build.

I'm perfectly happy with networking with one of those offboard widgets that emulates a modem, which kind of narrows the CX16 side to serial support. I don't know how fast the User Port can do bit-banging serial, but if it uses the serial shift register to receive that might make for fewer dropouts.

As far as a cheap serial interface card, the Max3107 has a built in oscillator, 128 byte buffers, and IIRTDC (if I read the datasheet correctly) hardware flow control support. It's a tiny surface mount part, but that's not an issue for a built board. (No, I don't know if it's active or obsolete and selling the stock out, last I saw it in a parts list, it was awfully cheap, $2-$3 Qty1, so that could have been the last run on their way out the door. The Maxim3140 was a lot more expensive, nearly $10 Qty1.)
Why it wouldn't be an option for the CX16 main board is in addition to being surface mount, it's a SPI/I2C part (at that scale pins cost more money than the silicon to include slave serial buses), so with Vera having no pins to use for multiple selects to share with the SD card bus, it just doesn't fit for the reference design.
As far as being an SPI/I2C part, Andre Fachet did a 6502 bus SPI 4-device bus master on FPGA about a decade ago, so until I hear of a fatal flaw with that design, I'm going to keep my eye open for inexpensive SPI chips to bundle into a single expansion port build.

Yes I’m aware if the SPI master. However it’s based on an off language for an obsolete chip.

There is no reason to try to use an I2C or SPI here. It makes sense on microcontrollers that don’t have exposed buses and IO is precious. But here it doesn’t make much sense. And yes, existing RS232 dongles should work fine. The onboard should work fine. We don’t know what speeds it can do yet, but 56kbps doesn’t seem unreasonable. That’s almost 8k per second.


Sent from my iPhone using Tapatalk

4 hours ago, Lorin Millsap said:

 The onboard should work fine. We don’t know what speeds it can do yet, but 56kbps doesn’t seem unreasonable. That’s almost 8k per second.

That seems awfully optimistic ... the best the C64 could do with bit banging its CIA GPIO was 2400bps, and 56K is 23 times faster. If true it's even better, since using the serial shift registers of to 6522's will be two to four times faster than bit banging their gpio lines.

As far as the rest, you'll pardon me if I not not prepared to take on faith that the VHDL source for an older Xilinx CPLD cannot be ported to a newer generation CPLD.

That seems awfully optimistic ... the best the C64 could do with bit banging its CIA GPIO was 2400bps, and 56K is 23 times faster. If true it's even better, since using the serial shift registers of to 6522's will be two to four times faster than bit banging their gpio lines. As far as the rest, you'll pardon me if I not not prepared to take on faith that the VHDL source for an older Xilinx CPLD cannot be ported to a newer generation CPLD.

It was possible to achieve 9600 baud on the c64. Im pretty sure that is using shift registers.  On the legacy CPLD SPI interface, the problem isn’t that it can’t be done. The problem is a lack of pros. A parallel bus interfaced UART is going to way outperform an SPI one. It will cost less too and require fewer supporting components.  Reality is that the UART was removed from the design because we simply don’t have the resources for it and we need to move the project forward. We can easily implement a functional equivalent using the hardware we already have.

On 7/9/2020 at 8:28 AM, Lorin Millsap said:

It was possible to achieve 9600 baud on the c64. Im pretty sure that is using shift registers.



On the legacy CPLD SPI interface, the problem isn’t that it can’t be done. The problem is a lack of pros. A parallel bus interfaced UART is going to way outperform an SPI one. It will cost less too and require fewer supporting components.

(1) How fast you could achieve using the CIA shift registers is pretty much immaterial if you don't have a pair of VIA shift registers to use. The best that bit banging the CIA GPIO on the User Port could do was 2400bps, so assuming that you can bit bang at 8 times higher clock speed and get over 20 times better performance is what I was referring to as quite optimistic ... if there aren't any hidden gotchas, 8 times the system clock would map to 19.2Kbps.

It seems likely one of the cheapest ways to replicate the third party C64 9600bps serial interface at 4-8 times the speed would be a single VIA and a ribbon cable tapping into the free shift register from the User Port. For a TTL header, it would be a single chip board with a 38.4Kbps-76.8Kbps throughput, plus a second EPP parallel port interface as a bonus.

(2) A parallel bus interfaced UART isn't going to "way outperform" an SPI when a post-indexed copy loop only needs a single NOP to be properly paced for a PHI2/2 synchronous serial bus. A parallel bus interfaced UART is going to be within 100%-120% of the performance on the system side, with performance in many circumstances on the port side more determined by FIFO size.

Either an SPI or a 8 bit Intel bus UART needs one supporting component on the CX16 bus side and identical supporting components on the RS232C / TTL header side, but the supporting component for SPI costs more, and supports four devices. On the other hand, other than VLIO bus UARTS, the 8bit parallel UARTs are getting a bit long in the tooth.

Clipped the inside baseball.

We do have shift registers available. The 65c22 shift registers do in fact work properly.


Sent from my iPhone using Tapatalk