Most cartridge Paks for the Coco are almost completely empty. Open one up, and you will find a small circuit board about 1.5 by 2 inches, just large enough to hold a single ROM chip. The goodies are all in the software on the ROM.

These Paks developed for the Coco 1 are addressed via the cartridge port. Historically, only the Disk Basic addresses
$C000 - $DFFF were used and the largest ROM was 8K, although 4K sized programs were common. Actually even on a Coco 1, the addresses $C000 - $FEFF were available, so the ROMs could be as large as 16K.

With the advent of the Coco 3, which can be set for 32K external ROM, a Pak could now be 32K and addressed from
$8000 - $FF00. I don’t know of any cartridges using this addressing scheme but there probably were some.

Greg L. Zumwalt pushed the trend for larger ROMs to the economic limit with a 64K ROM addressed as four bank switched 16K ROMs and RoboCop and Predator came to the Coco in the Super Program Pak (SPP). The SPP supported 64K by 8-bit or 128K by 8-bit ROMs. In the June, 1990 issue of Rainbow, Zumwalt promoted the SPP II designed to provide 512K by 8-bit ROMs. I believe this latter device was never marketed.

Can the software in these ROMs be transferred to a hard disk and therefore be used on an emulator, or are they doomed to be forever trapped inside a Pak? The answer depends on the manner in which the programs were coded. Copy protection schemes aside, the contents of a Pak can easily be transferred to disk and then loaded into RAM memory. As long as the ROM program does not assume it can use both 16K of ROM and 16K of high RAM or comes from an SPP, the program will work from disk as well as it does from a Pak.

There are two classes of ROM Pak excluding the SPP; manual start and auto start. When a Pak connects the cartridge port lines Q and CART, the Pak will auto start. This must be prevented if we want the chance to copy the code to disk or tape. There is a second problem if a Multi-Pak is not present in the system. Without a Multi-Pak, you can’t have both a disk and Pak connected to the Coco at the same time. While it is possible to remove a Pak and connect a disk controller to a Coco with the power on, that is a recipe for disaster. It is the fastest way known to destroy a Coco short of pouring soda through the cooling slots.

First, you need to ensure that the Pak will not auto start. This is best done with the Pak open; easily done by removing one case screw and prying the clam shell case apart. For reference, the +5V trace is normally slightly shorter than all others on the edge connector. This is done to prevent shorts if the Pak is bumped. The +5V pin is pin #9 and all odd numbered pins are on one side of the circuit board with the even numbered pins on the other side. Locate edge pins 7 (Q) and 8 (CART). Either apply tape to pin 8 or cut the connection between pin 7 and 8. This will disable the auto start.

Turn off your Coco, insert a non-auto starting Pak into the cartridge port, connect a tape recorder to CASS, and turn everything on. To be safe, we will assume that all program Paks are 16K Paks. Of course if you know yours are smaller, you won’t need to transfer as much data.

Make sure that the Coco is in RAM/ROM mode. This will be true for the Coco 1 or 2 but not for the Coco 3. To set a Coco 3 into RAM/ROM mode, you must issue a POKE &HFFDE,0 command. Since this will prevent any Coco 3 commands from functioning, you must be in WIDTH32 mode before issuing the poke command.

Save the Pak contents to tape with CSAVEM "filename",&HC000,&HFDFF,&HC000. That will transfer 16K of data, use &HC000,&HDFFF,&HC000 for 8K or &HC000,&HCFFF,&HC000 for 4K.

Turn off your Coco, remove the Pak, connect your disk and controller, and turn the system on. You must now load the program from tape (CLOADM "filename"). However, remember that the program was saved from the addresses used by Disk Basic. The simplest CLOADM command will try to load the program to it’s original addresses and trash Disk Basic if in RAM mode. We need to offset load the program to low memory CLOADM "filename", &H7000 which will load the program at $3000. If the program was written with relocatable code it can now saved to disk with a SAVEM "filename",&H3000,&H6FFF,&H3000. To use the program just LOADM and EXEC.

Unfortunately, not all Paks are written in relocatable code so these must be loaded to $C000. This will require some machine language programming so that your disk system and the Pak can coexist. You must also ensure that your Coco is in all RAM mode, true for a Coco 3 but not a Coco 1 or 2. This will require a short machine language program as follows:

1         ORG    $7000
2 START   ORCC   #$50    TURN OFF INTERRUPTS
3         LDX    #$8000  POINT TO THE BEGINNING OF THE ROM
4 LOOP    STA    $FFDF   FORCE ROM MODE
5         LDD    ,X      COPY THE ROM CONTENT TO REG.D   
6         STA    $FFDE   FORCE RAM MODE
7         STD    ,X++    STORE THE ROM COPY TO RAM
8         CMPX   #$E000  ARE WE PAST THE END OF THE COCO 1&2 ROMS?
9         BNE    LOOP    IF NOT KEEP COPYING
10        ANDCC  #$AF    RESTART THE INTERRUPTS
11        RTS            RETURN TO BASIC STAYING IN ALL RAM MODE
12        END    START

10  REM ROMRAM
20  LI=80
30  FOR M=&H7000 TO &H7016 STEP10:SUM=0
40  FOR I=0TO9:READA$:VA=VAL("&H"+A$):SUM=SUM+VA:POKE M+I,VA:NEXT
42  READ CHK:IFSUM<CHK THEN PRINT"ERROR IN LINE"LI:END
50  LI=LI+10:NEXT
60  EXEC &H7000
70  END
80  DATA 1A, 50, 8E, 80, 0 , B7, FF, DE, EC, 84, 1404
90  DATA B7, FF, DF, ED, 81, 8C, E0, 0 , 26, F1, 1670
100 DATA 1C, AF, 39, 00, 00, 00, 00, 00, 00, 00, 260

You also need a short program to transfer the Pak code to its final destination at $C000 before it can be executed.

1 ORG $7000
2 START  ORCC  #$50    TURN OFF INTERRUPTS
3        LDX   #$3000  POINT TO CURRENT LOCATION OF PAK CODE
4 LOOP   LDD   ,X++    COPY THE DATA
5        STD   $8FFE,X STORE THE DATA AT $C000 UP
6        CMPX  #$7000  HIGHEST DATA LOCATION
7        BNE   LOOP    IF NOT FINISHED, LOOP
8        JMP   $C000   EXECUTE THE PAK CODE
9        END   START
Basic only users should run the following which will save the program Transfer to disk. It can be loaded and executed as needed from disk after a LOADM of the Pak program.

10 REM TRANSFER
20 LI=80
30 FOR M=&H7000 TO &H7012 STEP10:SUM=0
40 FOR I=0TO9:READA$:VA=VAL("&H"+A$):SUM=SUM+VA:POKE M+I,VA:NEXT
42 READ CHK:IFSUM<CHK THEN PRINT"ERROR IN LINE"LI:END
50 LI=LI+10:NEXT
60 SAVEM "TRANSFER",&H7000,&H7012,&H7000
70 END
80 DATA 1A, 50, 8E, 30, 0 , EC, 81, ED, 89, 8F, 1178
90 DATA FE, 8C, 70, 0 , 26, F5, 7E, C0, 0 , 00, 1107

If you are lucky enough to own an MPI, you won’t need to use a tape recorder as an intermediate. Plug your Pak into MPI slot 1 and the disk controller into slot 4 and you are ready to transfer. Again it will be necessary to make use of machine language programming to handle slot selection and data transfer. What is nice about this method is auto starting Paks do not need to be disabled.

1        ORG   $7000
2  START PSHS  CC
3        ORCC  #$50    KILL INTERRUPTS
4        LDA   $FF23
5        ANDA  #$FE    TURN OFF THE CARTRIDGE INTERRUPT BIT
6        STA   $FF23   RESET THE PIA
7        LDA   $FF7F   READ THE MPI SETTING
8        PSHS  A       SAVE ON STACK
9        CLRA            SLOT 0
10       STA   $FF7F   POINT MPI TO SLOT 0
11       STA   $FFDE   GO TO ROM MODE
12 * THE NEXT TWO LINES ARE FOR THE COCO3 AND DO NOTHING ON OLDER COCOS
13       LDA   #$84    COCO1, NO DRAM, STANDARD SCS
14       STA   $FF90   RESET GIME
15       LDX   #$C000  POINT TO PAK
16 LOOP  LDD   ,X++    COPY DATA
17       STD   -$9002,X        STORE DATA FROM $3000 UP
18       CMPX  #$FF00  THE MAXIMUM DATA POSSIBLE
19       BNE   LOOOP
20       PULS  A       RECOVER MPI SETTING
21       STA   $FF7F   RESET MPI
22       STA   $FFDF   FOR COCO3 ONLY !!!!!!! RETURN TO RAM MODE
23       PULS  CC,PCR  RETURN TO BASIC
24       END   START

10  REM TRANSFER
20  LI=80
30  FOR M=&H7000 TO &H7032 STEP10:SUM=0
32  REM REPLACE 30 WITH 33 FOR COCO1 OR 2
33  REM FOR M=&H7000 TO &H702F STEP10:SUM=0
40  FOR I=0TO9:READA$:VA=VAL("&H"+A$):SUM=SUM+VA:POKE M+I,VA:NEXT
42  READ CHK:IFSUM<CHK THEN PRINT"ERROR IN LINE"LI:END
50  LI=LI+10:NEXT
60  SAVEM "TRANSFER",&H7000,&H7032,&H7000
70  END
80  DATA 34, 1 , 1A, 50, B6, FF, 23, 84, FE, B7, 1200 
90  DATA FF, 23, B6, FF, 7F, 34, 2 , 86, 0 , B7, 1225 
100 DATA FF, 7F, B7, FF, DE, 86, 84, B7, FF, 90, 1890 
110 DATA 8E, C0, 0 , EC, 81, ED, 89, 6F, FE, 8C, 1578 
120 DATA FF, 0 , 26, F5, 35, 2 , B7, FF, DF, 35, 1307 
130 DATA 81, 00, 00, 00, 00, 00, 00, 00, 00, 00, 129 
140 REM REPLACE LINES 120 AND 130 WITH 150 ON COCO1 OR 2
150 REM DATA FF, 0 , 26, F5, 35, 2 , 35, 81, 00, 00, 775

I have not described the various copy protection schemes or special requirements of some ROM Paks. The readers will have to find these for themselves. A hint is to look for and remove any code which attempts to write to a ROM address within the ROM program; a technique used in MegaBug.

Readers familiar with ml programming should consider tacking the transfer program onto the ROM Pak code to simplify the loading process.

Not all ROM Paks will work with a Coco 3! If a ROM Pak expects to make use of the address from $FE00-$FEFF and
$FF90 - $FF9F, it will not work with a Coco3. If a ROM Pak tries to make use of most of the semigraphics modes available on a Coco1, it won’t work on a Coco3. If a ROM Pak makes use of artifact graphics, it will run but may not be useful with RGB monitored Coco3s.