Maximum RS232 speed on C64 user port

[LoneWolf33]

Hi All,

I've did some research recently, and found that the control register assigned to the RS232 communications
would allow 19200 bps serial transfer speed setting. The contents of the control register can be set with either OPEN
or POKE commands. The control register is located at decimal address 659, and bits 0 to 3 are assigned to
the speed control (the lower half of the register).
It would be nice to hook up serial devices to the user port faster than 2400 bps speed, using O/S routines.

Did someone has already experimented with this?
Is there any known limiting factor? The "O/S emulated" RS232 solution maybe?

[LoneWolf33]

Update:
I've performed some tests in regard of serial line speed, and it seems the transfer speed
can't be increased above 2400bps, when trying it from Basic. The "mark" pulses on the oscilloscope
are not getting thinner using the same time base, despite the higher speed setting in the
transfer speed register.

The following picture was taken with 2400bps speed setting:

[BenjaminLumen]

Hmmmmm,

Have you tried the commodore schematic? 6526 CIA... Hmmm, how to get that puppy moving??? The 2Mhz version of the 6526 would accept max bit rates of 500Kb/Sec.... Hmmm, Test it against a C128.... The 6526 is also used for Parallel coms.... 2400bps.......

As configured in the Commodore 64 and Commodore 128, the CIA's timing was controlled by the phase two system clock, nominally one MHz. This meant that the timers decremented at approximately one microsecond intervals, the exact time period being determined by whether the system used the NTSC or PAL video standard. In the C-128, clock stretching was employed so the CIA's timing was unaffected by whether the system was running in SLOW or FAST mode.


If you placed the C64 in PAL mode will it go higher?? Probably not, don't know!!!

Hmmm, it could be multiplexing (correct term?) and that is why you can't get the ... It is also used for the User Port and 2 Controller Ports, and in a Von Neuman setup it may be looking for all of it, so its 19,200 is divided by 4 and your back to 2400bps.. which may explain it... Its doing a lot in the C64... If the Computer had a dedicated 6526 for every port then you could probably get the 19.2Kbps you were looking for but still, there may be a way to do it..

Oh there it is , its the Keyboard, and 2 controller ports... Its always looking for keyboard input, you may look for a way to halve or quarter the amount of time it looks for keyboard input and then type and execute the program...

If the 6526 only spends 1/4 of its usual time looking at the controller ports or keyboard ports you may get to 4800, 9600bps on the serial...

Okay sooo look at the keyboard timming routines and the controller port routines...

[LoneWolf33]

Hmmmmm,

Have you tried the commodore schematic? 6526 CIA... Hmmm, how to get that puppy moving???

Hi, yes I did it actually. We got two puppies, and the focus is now on the second one.

The 2Mhz version of the 6526 would accept max bit rates of 500Kb/Sec....

Well yes, but since the C64s and lot of C128s were equipped with the 1MHz version, so...
It might not relevant in our case.

Hmmm, Test it against a C128....

That was came into my mind as well, then I've checked the C128 schematics...
Even the versions equipped with the 2MHz capable 6526A are driving the CIAs with
same 1MHz clock speed, therefore no significant differences are expected,
nor in C128 fast mode.

The 6526 is also used for Parallel coms.... 2400bps.......

Indeed. The goal would be break the serial 2400bps barrier with the same hardware.

As configured in the Commodore 64 and Commodore 128, the CIA's timing was controlled by the phase two system clock, nominally one MHz. This meant that the timers decremented at approximately one microsecond intervals, the exact time period being determined by whether the system used the NTSC or PAL video standard. In the C-128, clock stretching was employed so the CIA's timing was unaffected by whether the system was running in SLOW or FAST mode.

Agreed, Wiki says exactly the same The C-128 related part confirms that, there would be no difference
in speed compared to the C64.

Hmmm, it could be multiplexing (correct term?) and that is why you can't get the ... It is also used for the User Port and 2 Controller Ports, and in a Von Neuman setup it may be looking for all of it, so its 19,200 is divided by 4 and your back to 2400bps.. which may explain it... Its doing a lot in the C64... If the Computer had a dedicated 6526 for every port then you could probably get the 19.2Kbps you were looking for but still, there may be a way to do it..

Oh there it is , its the Keyboard, and 2 controller ports... Its always looking for keyboard input, you may look for a way to halve or quarter the amount of time it looks for keyboard input and then type and execute the program...

If the 6526 only spends 1/4 of its usual time looking at the controller ports or keyboard ports you may get to 4800, 9600bps on the serial...

Okay sooo look at the keyboard timming routines and the controller port routines...

I think we need to separate things here. The second 6526 doesn't have to deal with the keyboard or the controller ports,
it's (almost) fully available to the user, this chip is in the focus. The first 6526 is responsible for the things you mentioned, but
since the controller ports lines and some of the keyboard matrix lines are connected together, the scan of keyboard and control
ports is done simultaneously: e.g. when you press key "2" on the keyboard that changes the state of the control port#1 as well
(@ decimal address 56321, even without joystick connected) and vice versa: changing the control port status with the joystick
affects the keyboard matrix state. As far as I can tell no extra cycles/time sharing needed for the keyboard and control port
handling, so I guess this might not the root cause.

Meanwhile I've started to scrutinize the ROM routine starting at $EED7. In this routine the state of RS-232 control register (@ decimal 659)
mentioned in the first post is being read and processed. Since the last post I got a bit overloaded at work, so I didn't get too far with it.

Anyway, thank you for sharing your thoughts, while writing these lines I got some new ideas regarding how to get around this
limitation with a machine language program which uses some of the original ROM routines.

All the Best!

[gsteemso]

The very impressive Steve "AgentFriday" Davison of PDXCUG has written a very effective machine language routine that does 38.4 kb/s, in bursts while the VIC-II is not active (i.e., while the VIC-II is drawing the top and bottom borders or doing vertical blanking). I think he wrote a blog post about it, probably on CommodoreServer.com, though I do not have the link saved.

[LoneWolf33]

It's been awhile since the last update, but finally I can present some results.

I've searched to Agent Friday's work mentioned by gsteemso, but no luck unfortunately.

After testing the built-in RS-232 send routine, it's became clear that there
are port timing issues present above 300bps speed, therefore I decided to write my own
send routine from scratch, and try to keep the routine as simple as possible.

First I wanted to determine that is there any speed limitations in CIA chip's data port.
To find this out I wrote a small machine language program which toggles one bit of the
data port as fast as possible. The expected result was a square wave on the oscilloscope.
Any distortions on the square wave would mean that the CIA chip is not fast enough
to keep up with the quick port line change requests. A PAL version C64 was the test
subject, and it produced a 178 kHz square wave signal with this small program.

If someone is interested I can post an oscilloscope screenshot later.

So it seems there's no port speed limitations on the CIA side, and the theoretical
maximum transmit speed is around 356 kbps, because one Hz (one cycle between low
and high levels) represents two bits in this case.
This square wave can be considered as a start bit + 8 data bits (carrying
85 decimal value) + a stop bit.
Of course this speed can't be reached in the real life, since processing the input
string (bytes to series of bits) will consume considerable amount of CPU time.

After this promising result I wrote an experimental ML send routine which can be called
from BASIC with SYS command like this: SYS16192,A$ or SYS16192,"string to be transmitted".
For accurate timing the CIA chip's internal timer was used. This send routine doesn't
have extra features like speed, data bit number or parity setting. Transmit speed setting can
be changed by modifying two bytes in the code (thus loads different values in the CIA
timer registers).
The code is capable to send 255 characters at once, just like the factory O/S routine,
this limitation is inherited from the string variable.

Unfortunately the results were disappointing: the output waveform produced by the
routine is also showing timing inaccuracies. At 1200 and 2400 bps speeds the code
produces better results than the built-in one, but from 4800 bps bit errors are
appearing in the output waveform. IMHO it seems I've ran into the same CPU processing
bottleneck, which may explains why the speeds above 2400 bps are not implemented in
the built-in send routine.
For faster transmit speeds the code should be able to change the Tx line output state
less than 100 nanoseconds during the byte to bits processing, which requires extra tricks.

Please note: the display Wasn't disabled during the tests.

Dear Commodore fans, I would like to wish you a Merry X-MAS !

[rbernardo]

You may have to e-mail Steve directly. If you wish, send me a private message, and I could give you his info.

Merry Christmas,

[LoneWolf33]

Hi All,

A year has passed since the last post, so I thought it's time to update the topic...
Thanks to Robert I've contacted Steve, and we've exchanged a few e-mails in December of 2015 and January of 2016.
He created a cycle accurate code to achieve 38.4kbps.

In my last post I've mentioned the screen wasn't disabled during the tests. Well... disabling it drastically changed the results.
Even without using the timer interrupts generated by CIA2, the bit-times became very accurate up to 9600 bps transmit speed.
So it was time to perform some communication tests between the C64 and a listener device.
Thanks to my colleague Alex, an Arduino Uno was the [first] test subject (with a small LCD), because no voltage level conversion
is needed, so it can be connected directly to the User Port. But no luck...
Usually nothing was displayed, sometimes garbage. At this point I wanted to try a true RS232 device (PC or a real terminal) since
the oscilloscope readings still seemed to be OK at the User Port side.
I've managed to get a VT520 RS232 terminal and a MAX232 PCB.
The outcome can be viewed in this video: https://www.youtube.com/watch?v=kEmYx5N1ipM

Maybe later I'll modify / rewrite the code to use the interrupts generated by the CIA chip (which was also suggested by Steve).
But for now I'm satisfied with the results.

Dear Commodore fans, I would like to wish a happy new year !