cbmlink
release notesThe cbmlink
utility is based on prlink
,
which was developed from 1994 to 1998 by Marko Mäkelä and Olaf Seibert.
The first version of cbmlink
was developed by Marko
Mäkelä in 2001-2002.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.
pc64
)prlink
a.k.a. prlink48
)prlink88
, prlink48
,
transnib
)x1541
)em1541
,
emul1541
)kontros
)c64net
)cbmlink
executableThis document describes the cbmlink utility, a program package that lets you to transfer data over a parallel connection or an RS-232 connection between a Commodore 8-bit computer and a bigger system (Amiga, PC, Apple, Unix workstation).
The utility is based on a daemon, or a memory resident IRQ handler wedge running in the Commodore end of the cable. You always issue the link commands from the other side. This implementation saves you from needing a server process on the bigger computer.
Currently daemons are available for the following Commodore systems:
For some computer and cable combinations, there exist several alternatives, either for supporting a memory expansion or an alternative loading address or cassette interface.
The client program has been written in such a way that it should compile on most C compilers with minor modifications. The programs were originally written for GNU/Linux. The are Intel 8086, 80286 and 80386 optimised transfer routines for parallel cables. Also the Amiga version is partially optimised in 68000 machine language. The software should work at least on the following systems:
The idea of the transfer utility package is that a daemon runs on the Commodore side in an interrupt routine, without affecting the computer's performance. Invoked by the periodic system timer interrupt, it checks if the other side wants to send a command, and executes the commands when needed. The protocol includes commands for memory transfers and for starting a machine language routine or a BASIC program. The latter two commands deinstall the daemon for maximum compatibility.
With the current protocol, it is possible to make useful applications that run on the other end, like disk and file copiers, and possibly a remote debugger. It is convenient to develop Commodore programs on the other side and to transfer them over to test them out. On the Commodore 128, you can use a boot sector, so that the daemon will be loaded and started automatically when you start the computer. On the Commodore VIC-20, the daemon can make use of the cartridge auto-start signature.
Until a binary distribution for your platform is available, you will have to compile the source code for your system, as described in Section 4.1.
Patches and precompiled binaries are welcome.
For your convenience, we have included precompiled Commodore
binaries in the software distribution. The cbmprg
and
cbmc2n
subdirectories are described in Section 4.2.
The C2N232 is a small RS-232 interface that can be plugged to the cassette port of an 8-bit Commodore computer:
The RS-232 end of the interface can be connected to any computer for which the following are available:
The device consists of two integrated circuits: a micro-controller and an RS-232 line driver. The parts cost something between 10 and 20 €, which can be slightly more than the parts for a passive parallel cable. However, compared to passive cables, the C2N232 is
The C2N232 emulates tape transfers at a fairly low level, relaying pulse streams consisting of square waves of three configurable frequencies.
The driver program c2n
transforms between the raw
Commodore cassette format, which consists of 192-byte blocks and
arbitrary-size program blocks, and these pulse streams.
The conversion utility cbmconvert
supports the raw
Commodore cassette format. In order to use the cassette drive
emulation to load a program via a C2N232 connected to the serial port
/dev/ttyS0
, you can apply the following
steps:
cbmconvert -C file.c2n file.prg
c2n -c /dev/ttyS0 file.c2n
Of course, it does not make sense to load long programs in this
way, since standard cassette loading is slow. Rather, you can load
the appropriate cbmlink
server in this way and then use
it for further transfers.
For your convenience, the cbmlink
distribution
includes the C2N232 server programs in the Commodore cassette format.
To bootstrap the cbmlink
server for the Commodore 64, you
may type something like c2n -c /dev/ttyS0
cbmc2n/c64/plain.c2n
.
If you do not currently have any possibility to transfer data to
your Commodore 8-bitter from other computers, don't worry. In the
file loader.txt, there is a bare-bones BASIC
implementation of the cbmlink
daemon with which you can
download the real daemon to your Commodore. Just type it in and save
it on tape or disk before starting it.
On a PC, the PC64 cable is recommended, because newer on-board enhanced bidirectional printer interfaces may have problems with the prlink cable. The PC64 cable is the safest choice. The X1541 and 64NET cables are supported only for the sake of completeness.
On the Amiga, there is one native cable, which works with all supported protocols except the Commodore serial bus protocols. For the bootstrapping you can only choose the 4-bit/8-bit protocol, but you can use any protocol after you have transferred the desired daemon to the 8-bit Commodore side. Furthermore there is the transnib protocol, which works over both TransNib and prlink cables. The most efficient protocol is prlink88, which transfers 8 bits at a time in both directions.
Start the bootstrapper program on your Commodore. On the big
computer
, execute the cbmlink
program with the
desired protocol to transfer the desired daemon to the Commodore,
e.g.: cbmlink -c pc64 0 -l cbmprg/pc64/c64/plain.prg
.
Now you should see a list of addresses and byte values scroll by.
If not, the connection does not work properly. Ensure that the cable
is properly connected and you have typed in the appropriate lines of
the BASIC listing, so that it is adapted for your hardware. Also, if
you are using a PC, you may have chosen the wrong printer port. Try
the -c
parameter with different device numbers (from 0 to
3). Also note that the Linux version requires super user (root)
privileges. Remember to install the software as root, or use
chown root
and chmod u+s
on the
binaries.
If everything seems to run correctly, replace the
print
statement on line 2050 with poke
. Now
the daemon will be really loaded to your computer. Once the program
has been transferred, save it using your favourite method (an assembly
language monitor is usually easiest). The addresses it occupies are
printed by the basic program.
Alternatively, if you have a disk drive, you can start the daemon and use an appropriate command to copy the daemon to a Commodore disk.
Start the 6502 side by giving the command
SYS [start address]
where [start address] is the first byte of the program.
The server will hook itself in the timer interrupt handler chain
and you should get a READY
prompt back immediately. Now
you can use the cbmlink
program.
To make the 6502 side remove itself from the interrupt chain, give
the command
SYS [start address + 3]
.
Note that the default VIC-20 version loads at 16384 ($4000). This
means that you need at least 16 kB of expansion memory to use the
program. If you want to use cbmlink
with an unexpanded
VIC, you have to recompile the executable, as explained in Section 4.2.
The Commodore 128 tries to load a boot sector from device 8 in its
startup routine. With our special boot sector, it is possible to
start the server on the C128 automatically. It not only starts the
cbmlink
server for the C128; it can also switch to C64
mode and start the server there.
There are two variants of the boot sector:
cbmutils/c128/bootsect.bin
cbm128
or cbm64
, depending on
the selected mode.cbmutils/c128/bootsect-pia.bin
By default, the boot sector loads the server for C128 mode. You can change this behaviour by holding a key down while the boot sector is being started. Remember not to press the STOP or C= keys down too early, or the C128's startup routine doesn't load the boot sector. The keys and their functions are as follows:
Key pressed | File to load | Mode |
---|---|---|
STOP | (none) | C128 |
Q | (none) | C64* |
(none),<-,1,2 | cbm128 or cbm1028 |
C128 |
CTRL | cbm128 |
C128 |
C= | cbm64 or cbm2564 |
C64 |
SPACE | cbm64 |
C64* |
* Note that drive 8 will be issued the
U0>M0
command in this case. (Effectively, a 1571
drive will be reset to 1541 mode.) Also, the 40/80 key sense line
will be zeroed. (This line can be used for selecting the KERNAL ROM
for the C64 mode. When the line is zero (or the key is down), the
standard KERNAL is selected. When the line is high, a KERNAL ROM
extension, such as JiffyDOS, can be active.
You have to copy the servers for the modes you use. For instance, if you have a PIA expansion and a REU in your C128, and you are using the PC64 cable, you need to copy the following files:
PC or Amiga file name | C128 file name |
---|---|
cbmprg/pc64/c128/plain.prg |
cbm128 |
cbmprg/pc64/c128/piareu.prg |
cbm1028 |
cbmprg/pc64/c64/plain.prg |
cbm64 |
cbmprg/pc64/c64/piareu.prg |
cbm2564 |
In addition, you need to copy
cbmutils/c128/bootsect-pia.bin
to track 1, sector 0 on
drive 8 by using the cbmlink
switch -dw0
bootsect-pia.bin
.
It is possible to change the default behavior of the boot sector.
As you can see from the source code in
cbmutils/c128/bootsect.s
, a default value will be loaded
if none of the special keys is being pressed during the boot. By
changing the default value, you can create a boot sector that e.g.
automatically switches to C64 mode and loads the appropriate
server.
The cbmlink
interprets and executes its command line
from left to right, one switch at a time. If an error occurs, the
rest of the command line is ignored, and the program exits with a
nonzero status.
Typically, every cbmlink
invocation starts with the
switch -c protocol device
switch,
which specifies the hardware protocol and the device address to be
used for communications. The device name is protocol-specific:
/dev/ttyS0
or COM1
.0x3bc
or
0
.Probably the most frequently used features of cbmlink
are loading a program to memory and invoking it. But
cbmlink
can also be used for copying files and entire
disks.
If cbmlink
has been compiled with debugging support,
you may prepend the protocol name with debug_
in order to
get a listing of transmitted and received data.
The file-to-memory and memory-to-file transfers of
cbmlink
support memory expansions and banked memory
access on the Commodore.
The -b
switch is used for overriding the default bank,
which is 1 for the Commodore 610, 710, 620 and 720, and 0 for all
other Commodores.
Bank numbers 0 to f are for internal memory. The two lowmost bits are for specifying the MMU mapped memory bank on a C128. In other words, MMU mapped memory banks on the C128 are numbered from 0 to 3. On unexpanded C128s, the banks 2 and 3 are the same than banks 0 and 1.
The bits 2 and 3 of the bank number specify the PIA mapped expanded memory bank on a C128 or a C64. So, the 64kB banks of a C128 with 1 megabyte of internal memory are numbered from 0 to 15. On a 512kB-expanded C128, the unique bank numbers are 0, 1, 4, 5, 8, 9, 12 and 13, as there are only two MMU banks. For instance, the banks 11 and 9 are equivalent. On a 256kB-expanded C64, or on a PIA-expanded C128 in C64 mode, the bank numbers 0..3, 4..7, 8..11 and 12..15 are the same, so there are 4 different banks.
Bank numbers from 16 to 255 are for REU memory banks, i.e. the banks of a 512-kilobyte-REU are numbered from 16 to 23.
On a stock C128, memory will be accessed through the FETCH ($2a2) and STASH ($2af) subroutines. Due to their design, there's a bug: any data read between 0x0 and 0x3ff will be fetched from bank 0. The version for the PIA expansion does not have this bug.
It is possible to load Commodore program files as well as raw binary files to the Commodore memory space, at most 64 kilobytes at a time, by using one of the following options:
-l file.prg
-lb file.prg
-lo address file.bin
-lr address file.prg
Note that the file to be loaded may not overwrite the server code or I/O register space. If this happens, the transfer may hang.
The Commodore memory space may be copied to a program file or to a raw binary file, at most 64 kilobytes at a time, by using one of the following options:
-s address1 address2
file.prg
address1
up to but
excluding address2
in the specified bank to a
program file. Write address1
to the first two bytes
of the file.-so address1 address2
file.prg
address1
up to but
excluding address2
in the specified bank to a
binary file.You may find indirect addressing useful. In order to save a BASIC
program in a Commodore 64, try -s @0x2b @0x2d
file.prg
.
Note that dumping the I/O register space may hang the transfer.
It is possible to remotely invoke both BASIC and machine language programs. Before starting a program, the server deinstalls itself in order to achieve maximum compatibility.
The -r
switch performs the BASIC RUN
command. This switch is typically used at the end of a command line,
e.g. cbmlink -c c2n232 /dev/ttyS0 -l Elite.prg -r
.
The -j
switch invokes a machine language program.
Again, indirect addressing may be useful: -j @0xfffc
performs a soft reset.
Normally, switching cartridge games is a little annoying, because
you would have to physically remove and install ROM cartridges, or to
power the computer off until a RAM expansion cartridge has forgot the
a0CBM
auto-start code in BLK5.
With cbmlink
, playing Commodore VIC-20 cartridge games
becomes more convenient. The -jc
(jump cartridge) switch
installs a small machine language program that modifies the cartridge
reset vector. When the reset button is pressed, the computer resets
itself and installs the cbmlink
server again.
This arrangement works notably well if the server resides at $4000
(BLK3, the default) and the option is invoked with -jc
20000
. The parameter specifies a SYS
address that
can be used for restarting the same cartridge game.
Typical usage of the switch is: cbmlink -c c2n232 /dev/ttyS0
-l "Pole Position-6000.prg" -l "Pole Position-a000.prg" -jc
20000
.
There is a collection of Commodore 64 music files on ftp.funet.fi at /pub/cbm/c64/audio/Vibrants. These modules use a common format. They must be initialized with a call to $1000, and the music will be played by calling $1003 once per picture frame.
As there are loads of these files, I didn't want to transfer them
first to my C64, but I wanted to play them easily with a simple
cbmlink
command. So, I created a simple player that also
reinstalls the cbmlink
daemon.
The player is very simple. By default, it will compile to $c800, and it assumes that the prserver daemon starts at $cc00.
Assume that you have the player
(cbmutils/c64/playtune.prg
) and Toccato (/pub/cbm/c64/audio/Vibrants/Deek/14toccat.prg)
in the current directory. To start playing the music on the C64, you
may use the command cbmlink -c c2n232 /dev/ttyS0 -l playtune.prg
-l 14toccat.prg -j 0xc800
. Alternatively, you can load
playtune.prg
and the tunes separately. To change the
tune, you may omit playtune.prg
: cbmlink -c c2n232
/dev/ttyS0 -l playtune.prg -l 14treasu.prg -j 0xc800
.
Beware that there are some musics with different init and play addresses. If you keep hearing the same piece after loading a new tune, make sure that the new tune starts at $1000.
The file cbmutils/c64/tod.prg
measures the time spent
in an interrupt in hours, minutes, seconds and tenth of seconds, as
read from the Time of Day clock register. It assumes that the power
frequency is 50 Hz. The times will be displayed on the screen, if
they are at least two tenths of a second.
The utility was developed in order to measure cbmlink
performance. It also works on the Commodore 128. Start it with
SYS12288
after starting the server, and see how much time
a 64-kilobyte transfer (-s 0 0 file
) will consume on
your equipment.
The file transfer commands use standard KERNAL routines. This means very slow speed, but it also guarantees maximum compatibility. For instance, disk transfers support any disk geometry for up to 999 tracks consisting of up to 1000 sectors.
Note that these transfer commands only work with disk drives or pseudo drives, like the REU ram disk. The commands might work with sequential files stored on tapes, but not with program files. (This has not been tested.) Bad news for those who use a Commodore serial bus cable: As you cannot use serial devices while the daemon is running, you won't have much use for these commands.
The switch -d drive[,secondary]
overrides the default device number (8) and secondary address (0 for
reading and 1 for writing files). The secondary address cannot be
overridden for other disk operations.
As the file names are not translated between PETSCII and ASCII, it is best to use upper-case file names on the local system, which correspond to lower-case Commodore file names.
There may be some random problems with file and disk transfers on the C2N232 cable on some platforms. Please report any bugs you encounter with it.
The file-read extension can be used through several command-line switches:
-fr file
...-dd pattern
$pattern
and display it on the
standard output as a directory listing.-ds
-dc command
UJ
command will probably hang the system. To reset
the drive, use UI
instead.There is only one switch for using the file-write extension:
-fr file
...It is best to rename the files to upper case before copying, as
cbmlink
won't strip directory delimiters or translate
file names from ASCII to PETSCII.
By default, the disk transfer commands refer to drive unit 0. The unit can be specified as an additional parameter.
-dr[0|1] file
-dw[0|1] file
When the file given to the -dw
option is shorter than
the disk capacity, the rest of the disk is left uninitialised.
All media sizes are supported. The only requirement is that the first track is 1 and the first sector on each track is 0. Tracks and sectors increment up to 999.
It is possible to load and save a disk drive's memory space. These
functions are based on the M-R
and M-W
disk
commands.
-dmc address1 address2
file.prg
address1
up to
but excluding address2
in a dual disk drive's
controller address space to a program file. Write
address1
to the first two bytes of the file.
Note that the drive may act strangely once this command has been
issued. Thanks to William Levak and Wolfgang Günther for providing
the information needed for implementing this option.-dmco address1 address2
file.prg
address1
up to
but excluding address2
in a dual disk drive's
controller address space to a binary file. Note that the drive may
act strangely once this command has been issued.-dml file.prg
-dmlo address file.bin
-dmlr address file.prg
-dms address1 address2
file.prg
address1
up to
but excluding address2
in the disk drive's
main address space to a program file. Write
address1
to the first two bytes of the
file.-dmso address1 address2
file.prg
address1
up to
but excluding address2
in the disk drive's
main address space to a binary file.The cbmlink
utility requires either the C2N232 device
or a special cable that is connected to the parallel port of an Amiga
or PC (also known as the printer port or the Centronics port). The
other end of the cable must be connected to the Commodore user port,
with the exception of the X1541, Frodo and Emul1541 cables, which
connect to the IEC bus (serial bus).
The PC64 cable is the cable used by the no longer developed Personal C64 emulator written by Wolfgang Lorenz. It uses 4 independent data lines for both directions. If you are using or are planning to use this emulator, then you are best off using this cable.
The prlink cable allows 8-bit data transfers from the PC to the C= side, and 4 bits from the C= to the PC. It uses four bidirectional lines on the PC. Beware that these lines are no longer bidirectional on some newer enhanced parallel ports. Be prepared to build the PC64 cable if this cable does not work.
The software also supports the X1541 cable, a cable designed for connecting a Commodore disk drive to your PC. The transfer is slow, 1 bit at a time. As the X1541 cable uses the serial bus for the transfers, the transfer daemon might get confused by any disk activities. This means that you cannot copy files or disks via this cable.
On the Amiga, there are three cables: the native 8-bit cable that
works with most protocols supported by the Amiga version, and two
different cables for the IEC bus connection. Also, if you have built
the cable for the TransNib software, cbmlink
will work
with it, although slower.
Note that we disclaim any warranties, so you are using these instructions at your own risk. Do not insert the plug to the user port the wrong way around, or you'll blow your printer port on the PC with the 9 volt signal as Marko did.
Note that the lower user port connections are named ABCDEFHJKMMN, skipping G and I.
On the Amiga 1000, pin 25 is not GND so Olaf picked 22 instead which should be GND on all Amiga models. On the PC, all pins from 18 to 25 should be GND.
pc64
)PC | Pins | C= | Comment |
---|---|---|---|
GND | 25---A | GND | Ground |
D7 | 9-->B | FLAG | Handshake signal |
ERROR | 15<--C | PB0 | Data from C= to PC |
SEL | 13<--D | PB1 | " |
PE | 12<--E | PB2 | " |
ACK | 10<--F | PB3 | " |
D0 | 2-->H | PB4 | Data from PC to C= |
D1 | 3-->J | PB5 | " |
D2 | 4-->K | PB6 | " |
D3 | 5-->L | PB7 | " |
BUSY | 11<--M | PA2 | Handshake signal |
prlink
a.k.a. prlink48
)PC | Pins | C= | Comment |
---|---|---|---|
GND | 25---A | GND | Ground |
D3 | 5-->B | FLAG | Handshake signal |
STROBE | 1<->C | PB0 | Bidirectional data lines |
AUTO | 14<->D | PB1 | " |
INIT | 16<->E | PB2 | " |
SELECT | 17<->F | PB3 | " |
D4 | 6-->H | PB4 | Data from PC to C= |
D5 | 7-->J | PB5 | " |
D6 | 8-->K | PB6 | " |
D7 | 9-->L | PB7 | " |
BUSY | 11<--M | PA2 | Handshake signal |
prlink88
,
prlink48
,
transnib
)Amiga | Pins | C= | Comment |
---|---|---|---|
GND | 22---A | GND | Ground |
POUT | 12-->B | CA1 | Handshake signal (strobe/flag) |
D0 | 2<->C | PA0 | Bidirectional data lines |
D1 | 3<->D | PA1 | " |
D2 | 4<->E | PA2 | " |
D3 | 5<->F | PA3 | " |
D4 | 6<->H | PA4 | Data from Amiga to PET |
D5 | 7<->J | PA5 | " |
D6 | 8<->K | PA6 | " |
D7 | 9<->L | PA7 | " |
BUSY | 11<--M | CB2 | Handshake signal (ack) |
On the PET, Olaf chose to use CB2 even though that pin is normally connected to a speaker. He did this because it makes the cable identical to the 64 and VIC cable, and allows you to use a single-sided connector. Make sure though that it does not connect the top and bottom fingers! Also you can hear nicely when the transfer is going on.
The Amiga cable allows for two protocols: the prlink compatible 4-bit/8-bit transfer, and a full 8-bit transfer, the option prlink88. In addition, the Amiga software supports a third protocol, the one for the TransNib cable. TransNib is an older transfer system for Amiga and C64. Its cable has only 6 Centronics data bits connected:
The Amiga cable is downward compatible with the TransNib cable, so you can use it with the TransNib cable protocol, but of course it is slower.
If you need to make a cable there is no reason to not make the full pramiga cable; The transnib protocol is provided for people who made a cable for TransNib V1.00 devised by Matt Francis.
x1541
)PC | Pins | C= serial bus | Comment |
---|---|---|---|
GND | 22---2 | GND | Ground |
STROBE | 1-->3 | ATN | not used |
AUTOFD | 14<->4 | CLK | Bidirectional data/handshake line |
SELECT | 17<--5 | DATA | Bidirectional data/handshake line |
As you may note, not all lines of the original X1541 cable are
required. The loop from D0 (pin 2) to ERROR (pin 15) is missing, as
well as the connection from INIT (pin 16) to RESET (pin 6). The ATN
line is not required either, but it is required by other transfer
programs that use this cable. cbmlink
will work with
these additions installed, so you don't need to modify your existing
X1541 cable.
em1541
,
emul1541
)The description below is, slightly modified, taken from the Frodo
documentation. The exact cable as used by Frodo (see
Aminet:misc/emu/Frodo*
), however, is also usable by
cbmlink
. Even though it wires the ATN line as an output,
we can use the cable since we don't use the ATN line. You can also use
the cable used by Emul_1541 (see
Aminet:misc/emu/Emul1541v11.*
). There is even a third
variant of this sort of cable which differs by having no inverters or
pull-ups at all. This is in fact the sort of cable that Olaf
tested.
If you are building a cable and won't need to use it for any of these other programs, you can safely leave out the connections to the ATN line.
The cable with inverters, as shown below, is called
emul1541
. The cable without inverters is called
em1541
.
Building an IEC cable is fairly simple, it connects the parallel port of the Amiga with the round 6-pin connector on the C64 devices.
Parallel port IEC connector Amiga 1541 DSUB, 25-pin DIN, 6-pin Pin Name Name Pin 14 +5V ------------*--*--+ | | | 7406 |¯||¯||¯| (74LS05) | || || | 1k each |_||_||_| 2 /|1 | | | 5 PB3 ----O |-----*--+--+------- ATN 3 \| | | | | 3|\ 4 | | 6 PB4 ----| O--*-----*--+------- CLK 4 |/ | | | | 5|\ 6 | | 7 PB5 ----| O--+-*------*------- DATA 5 |/ | | | | 8 PB6 ---------+ | | 9 PB7 -----------+ 22 GND -------------------------- GND 2
The 7406 (a 74LS05 will do as well) must be connected to +5V and GND of course. The trained technician will notice that this is the same circuit found inside the real C64 (except that the inverter on ATN is inverted so ATN can be used for output).
[Important note: If you plan to build and connect such a cable, please remember that you do it on your own risk. Olaf will not take any responsibility if there is blue smoke coming out from the back of your computer!]
kontros
)The alert reader may have noticed from the source code that
cbmlink
supports yet another cable, a buffered parallel
cable designed by Frank
Kontros. As he is still working on yet better solutions
(involving automatic handshaking), he requested me not to publish the
schematic diagram of this cable. The interface works with VIC-20
(with a small modification), Commodore 64 and Commodore 128. E-mail
Frank if you are interested in his super-fast interface and software
(for MS-DOS).
c64net
)The 64NET cable pin-out won't be listed, as the 64NET documentation claims that it is copyrighted. (It is a bogus claim, since copyright does not cover ideas, but only the expression of them.) Besides, including it would be a waste of space, as other cables allow more efficient protocols.
For some reason Olaf had weird problems with his 64 when using the prlink88 protocol. He might be the only one suffering from this, but if you too get hung transfers when transferring from the 64 to the Amiga, try to run the transnib protocol. It is slower but generally causes less hung transfers.
To get more technical: When the data lines are changed by the 64, the handshake line from the 64 sometimes starts bouncing, causing the Amiga side to get so confused that the computers get too much out of sync. Olaf doesn't know if it's a problem with his cable (perhaps it is a bit long), his 64, or his Amiga, or any of those in general.
Because of this, we have included bounce detection for the
prlink48
and prlink88
cables in the
following cases:
If you wish to turn off the bounce detection, you can do this by
changing some flags. For the 6502 side, edit the file
c64common.s
and change the definition of
ciadebounce
to 0. For the Amiga side, change
DEBOUNCE
in prlink48.c
and
prlink88.c
to 0. Next you need to recompile and test if
the transfer still works correctly.
If the transfer hangs, you can stop the server on the Commodore side with STOP & Restore. The AmigaDOS or Linux client can be stopped with normal means, i.e. Ctrl-D on the Amiga, and Ctrl-C on Linux. The MS-DOS clients can be stopped by pressing Esc.
cbmlink
executableTo compile cbmlink
for AmigaDOS or Linux, you need GNU
Make, GNU Compiler Collection (tested with 2.5.8, 2.6.2 and 2.95.4;
any later version should do) and related tools.
On UNIX systems, you should be able to use the native
cc
or gcc
.
32-bit console-mode executables for Microsoft Windows best generated with gcc targeted for Minimalist GNU for Windows, running either on Linux or Windows.
It should be possible to compile the MS-DOS executables with Microsoft C/C++ v8.00, which is part of Microsoft Visual C++ v1.5.
The software supports several different cables. The transfer routines for
the different cables are in the comm
subdirectory.
The extensions for copying files and disks are located in the
ext
subdirectory. The 6502 source code for the
extensions is in ext/asm
; they can be compiled with the
Bourne shell script ext/asm/cgen.sh
.
In principle, compiling is as easy as typing
cd src
make
make install
In practice, it may be a bit more complicated. In order to use the
parallel port on Linux, the cbmlink
program must be run
with the super-user privileges (chown root cbmlink; chmod u+s
cbmlink
).
If you like to modify or to recompile the Commodore binaries, you need to retrieve DASM from ftp.funet.fi as /pub/cbm/programming/unix/dasm21204.zip.
The source code for the Commodore server programs is located in the
cbmsrc
subdirectory. There are two main
files,
server.s
and c2n.s
, both of which act as
entry points to server.s
, which uses include files from
the subdirectories. The Bourne shell script build.sh
takes care of building all cbmlink
server binaries.
There are three major variations for the Commodore servers, reflected by the include file subdirectories:
cable
)host
)mem
)plain
. Other
configurations are:
pia
(c64, c128)piabase.s
.reu
(c64, c128)piareu
(c64, c128)cart
(vic20)a0CBM
auto-start signature. The server is installed automatically
on reset. This configuration cannot be used for loading
cartridge games.port2
(pet3001, pet4001)The cbmprg
subdirectory contains a subdirectory for
each supported protocol. Each protocol subdirectory contains a
subdirectory for each supported computer type, which in turn contain
programs for each supported variation.
The cbmc2n
subdirectory contains the contents of the
cbmprg/c2n232
directory in the raw Commodore cassette
format, usable with the c2n
utility.
In order to change the start address of a server, have a look at the
appropriate include file in the host
directory.
The Action Replay cartridge by Datel occupies all of the address space at $de00-$dfff. Nevertheless, it is possible to use a Commodore REU simultaneously with an Action Replay cartridge, if the REU registers are modified to be write-only:
/o-------+ -I/O2 ----o/ | (from C64) o->|----+--- -I/O2 (to REU) | R/-W --------->|----+ 1N4148 | diodes < > 4k7 < resistor > | --+--
When the switch is in its upper position, the REU will operate as
previously, i.e. it won't work with the Action Replay cartridge. When
it is in the lower position, the Action Replay cartridge will work,
but you will most probably have problems with any software that uses
the REU (except cbmlink
). Thus, whenever you want to use
anything that supports the REU, you must disable the Action Replay
cartridge and then move the switch to the upper position.
To allow cbmlink
to access the REU when its registers
are write-only, set actionreuplay=1
in
reubase.s
.
If you also modify Action Replay so that its -I/O2 gets disabled when R/-W is low, you won't need the actionreuplay option. But this modification cannot be implemented with diodes and resistors. Instead, you would need an IC (quad NAND or something), which may be difficult to fit in the Action Replay case.
The ancestor of cbmlink
, prlink
, was
originally programmed for Linux and C64/C128/VIC-20 by Marko Mäkelä.
Olaf Seibert joined the project and ported prlink
to
Amiga and the PET 3000 and 4000/8000 series. Since then, Marko has
ported the code to MS-DOS and to other Commodore platforms, and
improved the program structure greatly.
Marko would like to express his thanks to all transfer program
writers and everyone who has shown interest towards
prlink
or cbmlink
or offered help, mostly by
supplying either documentation or hardware.
The disk copiers could be speeded up. Currently they read or write
sectors with interleave 1. It could try to find the (maximum) number
of sectors on a track by reading the first track with interleave 1,
and read further tracks should with a more efficient interleave. The
interleave factor control should be implemented in the
disk.c
end, because the optimal factor depends on the
load on the bigger computer.
Custom transfer routines would dramatically speed up the transfer with 1541 compatible disk drives. Unfortunately we do not have the time to reverse engineer good routines such as the Action Replay fastloader, so documented and freely usable source code is more than welcome.
It could be useful to integrate a modified version of the Gunzip.c64
decompression program to cbmlink
in order to speed up the
copying of 1541 or 1571 disk images.
The primary distribution site of cbmlink
is
http://www.funet.fi/pub/cbm/crossplatform/transfer/C2N232/.
Binary distributions may be out of date (or nonexistant), because the author has limited access to non-Commodore hardware. Contributions of patches and compiled binaries are welcome.