Jump to content

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


BruceMcF
 Share

Recommended Posts

With the ACIA dropped from the design, I gather that the plan is that the foundation serial port option is bit banging the VIA on the User Port. The C64 bit banging the CIA on a 1MHz bus was used to support Commodore's 1200baud mode, and that approach could be pushed to 2400 baud, but not further, while using the serial shift registers allowed operating at 9600baud.

Presuming the equivalent of the enhanced bit-banging routines are used, that implies somewhere between 9600 and 19200 baud on a bit-banging serial port, while a VIA dual serial shift register approach could hit the maximum landline modem speed of 5600baud.

Of course, without hardware flow control and with no hardware FIFO, the faster you go the more risk of dropped data, so just as a guesstimate perhaps 4800-9600baud reliably with bit banging and 19200-38400baud reliably with the VIA serial shift registers.

That suggests the simplest serial card would be a card with a 3rd VIA on it, and splitting off the serial shift register from the User Port onto a separate block pin header from the parallel port, so a ribbon cable from the card to the existing VIA#2 serial shift register lines would support a VIA hardware serial port.

Of course, even taking the remaining serial port  handshaking lines from Port B of the expander card VIA, there would still be plenty of lines to support a second EPP parallel port (which fortunately doesn't require as many lines as a original parallel port).

References:
UP9600 code: https://github.com/bozimmerman/Zimodem/blob/master/cbm8bit/src/up9600.asm

Example 9600 interface (UK): https://www.simulant.uk/shop/Commodore64-Commodore128-User-Port-to-rs232-Adaptor-C64-C128-to-9-Pin-Serial

Example 9600 WiFi modem: http://www.codingkoala.com/kc64wifi/

Edited by BruceMcF
Link to comment
Share on other sites

The ACIA was never in the design because CIA chips haven’t been made since the C64/Amiga days.

 

The VIA has a working shift register. However it has to be compatible with real legacy devices so if still has to follow the timing rules. So it really doesn’t matter what the theoretical speeds are. In theory you can go faster with custom routines in both devices.

 

For networking you probably aren’t going to want to use the serial port. There will be software supported lines on the user port for RS232. Alternately you can use a proper network interface card which should be capable of 128kbps or higher.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

13 minutes ago, Arpman said:

It seems to have serious bugs that make it unusable. Similar, bug free, chips are no longer manufactured. Bugs me too, it would be the ideal solution. There will probably be addon cards, or kits eventually. I will most probably make one based on that chip.

Link to comment
Share on other sites

3 hours ago, Lorin Millsap said:

The ACIA was never in the design because CIA chips haven’t been made since the C64/Amiga days.

The VIA has a working shift register. However it has to be compatible with real legacy devices so if still has to follow the timing rules. So it really doesn’t matter what the theoretical speeds are. In theory you can go faster with custom routines in both devices.

For networking you probably aren’t going to want to use the serial port. There will be software supported lines on the user port for RS232. Alternately you can use a proper network interface card which should be capable of 128kbps or higher.

It's not clear what the status of the CIA, the MOS 6522 Complex Interface Adapter ... the version of the MOS 6522 family that fixed the bug in the MOS 6522 VIA ... would have to do with the status of the Asynchronous Communication Interface Adapter, the 6526, where the currently available cmos wdc65c26 version has a bug of it's own in its hardware flow control.

It's also a little obscure what the second remark means to say, as the constraint on the speed of the bit banged serial user port was bus speed and processing power. It would be remarkable if "being compatible with real legacy devices" did not permit it to be two to four times faster. Obviously real legacy devices exist with speeds of 9600baud, 19200baud, 38400baud and the landline telephone bandwidth cap speed of 56000baud. Those are all quite common RS232C data transmission rates.

And as for networking? I do indeed want to use the serial port and a Wifi232 type WiFi interface ... there's no way I am going to buy a CX16 specific internet card when I can readily get something that will work with any retro system with a serial port that supports Hayes AT command syntax. That flexibility is one of the features that makes them so popular.

The reference to the ACIA 6526 was a reference to the earlier description that the system would be including it as a serial chip, which went by the wayside due to its bug and whatever toing and froing y'all did over it behind the scenes ... which happily with this project isn't done in public so I don't worry about. It wasn't lamenting that the ACIA was not going to be included.

But CX16 the system is not all that well endowed with GPIO, and a card that provided a serial port by using the free serial shift register in the User Port and a third VIA would not only be really cheap, but also bring the usable amount of GPIO up to a much more respectable level.

Edited by BruceMcF
Link to comment
Share on other sites

It's not clear what the status of the CIA, the MOS 6522 Complex Interface Adapter ... the version of the MOS 6522 family that fixed the bug in the MOS 6522 VIA ... would have to do with the status of the Asynchronous Communication Interface Adapter, the 6526, where the currently available cmos wdc65c26 version has a bug of it's own in its hardware flow control.
It's also a little obscure what the second remark means to say, as the constraint on the speed of the bit banged serial user port was bus speed and processing power. It would be remarkable if "being compatible with real legacy devices" did not permit it to be two to four times faster. Obviously real legacy devices exist with speeds of 9600baud, 19200baud, 38400baud and the landline telephone bandwidth cap speed of 56000baud. Those are all quite common RS232C data transmission rates.
And as for networking? I do indeed want to use the serial port and a Wifi232 type WiFi interface ... there's no way I am going to buy a CX16 specific internet card when I can readily get something that will work with any retro system with a serial port that supports Hayes AT command syntax. That flexibility is one of the features that makes them so popular.
The reference to the ACIA 6526 was a reference to the earlier description that the system would be including it as a serial chip, which went by the wayside due to its bug and whatever toing and froing y'all did over it behind the scenes ... which happily with this project isn't done in public so I don't worry about. It wasn't lamenting that the ACIA was not going to be included.
But CX16 the system is not all that well endowed with GPIO, and a card that provided a serial port by using the free serial shift register in the User Port and a third VIA would not only be really cheap, but also bring the usable amount of GPIO up to a much more respectable level.

There is no currently available 6526. If you look in their list of chips, the 6526 is absent.

The constraint on the IEC bus speed is limited by the processing power of the legacy devices. Sure in theory the x16 can do higher speeds, but only if it was talking to a device that was as fast as the x16. Since no such device exists, what’s the point?

Because of the way the IEC is wired there really isn’t a way to use it differently.


Sent from my iPhone using Tapatalk
  • Like 1
Link to comment
Share on other sites

It seems to have serious bugs that make it unusable. Similar, bug free, chips are no longer manufactured. Bugs me too, it would be the ideal solution. There will probably be addon cards, or kits eventually. I will most probably make one based on that chip.

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


Sent from my iPad using Tapatalk
Link to comment
Share on other sites

On 7/5/2020 at 12:57 AM, Lorin Millsap said:

There is no currently available 6526. If you look in their list of chips, the 6526 is absent.

The constraint on the IEC bus speed is limited by the processing power of the legacy devices. Sure in theory the x16 can do higher speeds, but only if it was talking to a device that was as fast as the x16. Since no such device exists, what’s the point?

Because of the way the IEC is wired there really isn’t a way to use it differently.

Sorry, brain fart, the ACIA is of course the 65c51.

I wasn't discussing adding another IEC bus port, I was referring to adding a serial port.

I know that the IEC bus is a serial bus, but it would be utterly confusing to talk about the IEC bus as "adding a serial port". And since the IEC is a daisychain bus, there's no point in adding another one when what is missing is a regular serial port.

Since an RS232C serial port can be provided at 9600bps using the C64 user port and the Serial Shift Registers from both of the C64 CIA's on a 1MHz bus, I don't think it is at all unreasonable to hope that if the free 65c22 VIA serial shift register from the User port is added to  both parallel ports and the serial shift register from an expansion card 65c22 VIA, the serial port might support 38.4K or 56K on an 8MHz bus, for one serial port and two EPP capable parallel ports, one compatible with the original PC parallel port.

One serial port and two parallel ports may well do me.

Link to comment
Share on other sites


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
  • Like 1
Link to comment
Share on other sites

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]

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • Super Administrators
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. 

 

 

 

Edited by TomXP411
  • Like 1
Link to comment
Share on other sites

  • Super Administrators
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?

Link to comment
Share on other sites

38 minutes ago, TomXP411 said:

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

MaxLinear also has Motorola bus 8bit UARTS, but their 8bit UARTS other than the VLIO bus parts seem to be getting long in the tooth, so it you wanted a dual serial port 8bit bus UART from Maxlinear with 64+ FIFIO on both receive and transmit, you'd want to be flexible about accepting the Intel/Motorola bus versions.

MaxLinear's datasheets for their Intel/Motorola 8bit bus UARTS give the circuit. It seems like it would be possible from a single glue logic chip.

I don't have that circuit in front of me, but it seems like you could do it with a dual two bit pull down encoder, chip select and R/W to one encoder, two of the four outputs are /Read and /Write, chip select and ground to the other encoder, one of the outputs is /CS, so it's synchronous with  /Read /Write rather than leading it.

Similarly there's a quad logic gate that supports a similar circuit.

My idea was the absolute cheapest expansion card that gives you a second parallel/GPIO port and a serial port faster than just big banging a VIA. if you borrow the serial shift register already available on the User port, I think there's nothing going to beat a VIA and a MAX232 for drop ship price.

Link to comment
Share on other sites

6 hours ago, LIV2 said:

There's also the SC28L92 DUART which is still produced by NXP & TI that several of us are using over on 6502.org. very simple to interface in "Motorola" mode

I do like that I/M pin, that is more convenient than needing a circuit to generate /Read and /Write from R/W and /CE ... and I also see that you can use a Motorola R/W flag with the 8088 bus cycle.

I wonder whether the bus timings are OK for 8MHz operation at +5v, or whether use of the RDY line is needed to stretch the register access operations by a cycle (which would in effect be an actual Motorola bus interface).

Link to comment
Share on other sites

I do like that I/M pin, that is more convenient than needing a circuit to generate /Read and /Write from R/W and /CE ... and I also see that you can use a Motorola R/W flag with the 8088 bus cycle.
I wonder whether the bus timings are OK for 8MHz operation at +5v, or whether use of the RDY line is needed to stretch the register access operations by a cycle (which would in effect be an actual Motorola bus interface).

It will work just fine.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

  • Administrators

There is currently no support for RS232 in the X16 KERNAL.

  • Initially, the VIC-20/C64 software 6551 emulation was still in the source, but never working, because it needs tight integration with a timer on the 6522 and NMIs.
  • When VERA got an RS232 port integrated, the emulation was replaced with a VERA driver
  • When VERA removed the RS232 port again, that driver was removed from the KERNAL.

So we don't currently have any support for RS232 in the KERNAL.

That said, I'd love to have a software implementation, but it should be based on something like UP9600 rather than Commodore's VIC-20/C64 code. Pull request, anyone?

Link to comment
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.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use