Commander X16

Do you have a link to the known bugs for the wc65c51 chip?


Sent from my iPad using Tapatalk

It’s on the 6502 groups. I don’t have a link offhand. Basically the main one deals with the IRQ not properly clearing which basically means you have to sit there and pull the chip.
I don’t know why people keep bringing the 6551 up though. There are parallel bus compatible chips that are faster, cheaper, and have more features that are in active production. They are not readily in a DIP package unfortunately, but you can get them in PLCC which means you can get a through hole socket.


Sent from my iPhone using Tapatalk

On 7/4/2020 at 6:32 PM, Arpman said:

Do you have a link to the known bugs for the wc65c51 chip?

 

http://www.westerndesigncenter.com/wdc/documentation/w65c51n.pdf

It is not really the interrupt that is broken.  Instead, it is the Transmitter Data Register Empty status bit itself.  So you can't even poll the chip to know when it is safe to write new data.  You have to know the baud rate and pace writes using a software loop or other means.

See the descriptions for "Transmitter Data Register Empty", pages 8-10.  WDC could have been more intellectually honest about this bug, instead of writing "This feature of the W65C51N works different from earlier 6551 designs". [emphasis mine]

http://www.westerndesigncenter.com/wdc/documentation/w65c51n.pdf
It is not really the interrupt that is broken.  Instead, it is the Transmitter Data Register Empty status bit itself.  So you can't even poll the chip to know when it is safe to write new data.  You have to know the baud rate and pace writes using a software loop or other means.
See the descriptions for "Transmitter Data Register Empty", pages 8-10.  WDC could have been more intellectually honest about this bug, instead of writing "This feature of the W65C51N works different from earlier 6551 designs". [emphasis mine]

Ok. Thanks for clarifying that. Regardless the point of a UART is it is supposed to reduce CPU overhead. If you have to time your loops that isn’t going to give much gain versus the properly working 6522.


Sent from my iPhone using Tapatalk

http://www.westerndesigncenter.com/wdc/documentation/w65c51n.pdf
It is not really the interrupt that is broken.  Instead, it is the Transmitter Data Register Empty status bit itself.  So you can't even poll the chip to know when it is safe to write new data.  You have to know the baud rate and pace writes using a software loop or other means.
See the descriptions for "Transmitter Data Register Empty", pages 8-10.  WDC could have been more intellectually honest about this bug, instead of writing "This feature of the W65C51N works different from earlier 6551 designs". [emphasis mine]

Well, thanks for that info. I have a dev board on the way and I’ll look into this issue. Maybe I will find another UART to use...any suggestions?


Sent from my iPad using Tapatalk

Well, thanks for that info. I have a dev board on the way and I’ll look into this issue. Maybe I will find another UART to use...any suggestions?


Sent from my iPad using Tapatalk

ST16C550 should work fine. It’s one choice out of many.


Sent from my iPhone using Tapatalk

Ok. So just to sum up where the RS232 serial (not to be confused with the IEC serial) is at, it is implemented as part of the user port and is implemented via one of the 65c22 chips. A lot of that is not set in stone as the routines haven’t been written yet. But that is the functional RS232 serial on the main board.  Faster RS232 can be implemented via an expansion card. Such a card will probably have more to it than just a UART. I would imagine that it would have a modern UART chip, the voltage shifting and a 9 pin serial port. Then connected to that it would make sense that it had an ARM Cortex based interface that handles the higher level web interfaces and emulates AT Hayes protocol and it would have both an ethernet port and Wifi. This would use existing open source options. It just wouldn’t make sense to make such a card unless it was more than just a UART.  Since ROMs can’t be easily put in the expansion bus there are several methods for handling the driver.  Method 1 is that the KERNAL interface software is put on the SD card and the BOOT file loads the patch in during startup. This would make such cards usable in BASIC.  Method 2 is that you don’t automatically load the driver at all. But rather software that uses RS232 could load the driver when it’s needed. A suggested method for that is to place the files in a directory such as /drivers/rs232/ and software that uses it can search for an executable in that directory path and run it.  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.   Sent from my iPhone using Tapatalk

23 hours ago, Lorin Millsap said:

It’s on the 6502 groups. I don’t have a link offhand. Basically the main one deals with the IRQ not properly clearing which basically means you have to sit there and pull the chip.

I don’t know why people keep bringing the 6551 up though. There are parallel bus compatible chips that are faster, cheaper, and have more features that are in active production. They are not readily in a DIP package unfortunately, but you can get them in PLCC which means you can get a through hole socket.





Sent from my iPhone using Tapatalk

People bring up the 6551 because this is the chip used by the Swiftlink and compatible serial cartridges for the Commodore 64. This design is simple, only needs a few components, and the code is already out there to support this chip. Someone could port a terminal program from the C64 to the Commander very quickly by just modifying the screen output code and the I/O address for the serial port. 



At first, I was against using the WDC 6551, due to the register bug, but as long as is this is only on the transmit register, it's not actually a problem: programs just need to wait for 10 baud units of time before writing another byte to the data register. There are several ways this can be done, including using a programmable timer on one of the VIA chips.



I have written code for the 16550 UART as well, although it's been 20+ years. However, there aren't any public, baseline designs we can draw from when building interface cards, like there are with the 16550. The 16550 is not designed for the 6502 bus, and so it will require additional hardware to couple to this CPU. 

 

 

 

The required hardware is already present. The YM-2151 and the SAA chip aren’t designed for it either. The requirements are minor.


Sent from my iPhone using Tapatalk

6 hours ago, Lorin Millsap said:

The required hardware is already present... The requirements are minor.

...which makes it all the harder to understand why a 16C550 was not included as a standard feature.

15 hours ago, Lorin Millsap said:

The required hardware is already present. The YM-2151 and the SAA chip aren’t designed for it either. The requirements are minor.





Sent from my iPhone using Tapatalk

Can that hardware address devices in the expansion slots, or just the YM and SAA chips?