Geoffrey.Welsh@isishq.FIDONET.ORG (Geoffrey Welsh) (10/09/88)
Running a Commodore 64 at 1200 Baud
-----------------------------------
If you thought that the only modification necessary to
operate your C64 at 1200 was to say:
OPEN5,2,0,CHR$(8)
Instead of:
OPEN5,2,0,CHR$(6)
Then you have another think coming. I thought this
originally, until I started to do some experimentation.
These experiments started with a call to DATAPAC's 1200 baud
line at 868-4100. I noticed that I wasn't receiving very
well, so I tuned locations 665 and 666 to give me the best
"reception". I couldn't explain why I had to "turn up" the
port speed, but it appeared to work, until I tried to
transmit that is. Not only was DATAPAC having a terrible
time receiving what I was sending, but the Hayes Smartmodem,
in command mode, would no longer hear me. Everything was
fine if I set the port speed back to "normal", but now I
couldn't receive error free.
A call to Commodore Canada the next day revealed that
because the C64 simulated an ACIA (the 6551) in software,
higher baud rates lean heavily on NMI. This wouldn't be so
bad if it weren't for the fact that the receive routines are
affected more than the transmit routines. Great, now I was
left with a machine that would transmit at 1200 baud and
receive at 1160 baud. I went away grumbling to myself about
how stupid Commodore was not to put in a proper ACIA.
It then dawned on me that if I could alter the Kernal so
that the transmit speed could be tuned independantly of the
receive speed, I could lick the problems. I knew it was
possible to download the Kernal into the RAM beneath it, and
once there, I could do anything I wanted to it. The only
drawback to this is that if you switch the Kernal ROMs out,
you must switch the BASIC ROMs out too, and this means you
have to waste 16K of RAM. I deemed this to be a non-
solution.
With some help from Dan Nelson (author of VIP Terminal), I
quickly found out where the transmit speed was set. After an
hour or so of disassembling ROM, I discovered that was
accomplished in the CHROUT routine. This was marvelous, for
CHROUT is RAM VECTORED and can be put where ever you like. I
needed only copy about 200 bytes of the code to somewhere
else in RAM and vector CHROUT to it.
Did it work? Like a charm, but there was still one other
glitch to overcome. I put the BBS up with this modication
and designed things so that if someone called in at 1200
baud, the bit counts governing the transmit and receive port
speeds were altered to suit. 300 baud mode continued to work
flawlessly, but at 1200, users could receive everything
fine, but the board couldn't hear them. I just couldn't
understand it, so I set to work trying to find out the
difference between my board and the terminal program I did
the initial tests on.
I found it; two locations, supposedly not supported in the
Commodore 64, even though the PRG says they are, turned out
to be critical. These were locations 661 and 662, the non-
standard baud rate counters. Unlike 665 and 666, which must
be loaded with a number equal to the clock frequency devided
by the baud rate, 661 and 662 must be loaded with a number
equal to:
INT(CF/BUADRATE/2-100)
Where CF is the clock frequency; 1,022,730 hz for North
American C64's.
With all these problems finally solved, the BBS was put up
with automatic 300/1200 capabilities. Similar modifications
have been made to my terminal program, and they too operate
at 1200 baud, smack on. Downloading occurs at a rate of 21
blocks per minute and is just a joy to watch.
If you'd like further information about these modifications,
contact me at the board number between 11AM and 5PM, though
I'm not always in.
Steve Punter : 29-Oct-84
--
Geoffrey Welsh - via FidoNet node 1:221/162
UUCP: ...!watmath!isishq!Geoffrey.Welsh
Internet: Geoffrey.Welsh@isishq.FIDONET.ORG