Turbo Macro Pro, Overview

General Overview

The Turbo Macro Pro (TMP) toolset consists of several different but very similar versions, each one made for a specific machine/hardware config. The individual versions in the current TMP package are:

The tools also work on a c128, in c64 mode of course.

In addition to the actual assembler tools, there is also an emergency restore tool for each different configuration of extra memory. These tool are called 'jumpbackers' - they enable the user to detect existing instances of TMP in the extra memory banks of the REU, DTV, or PTV and retrieve that back into the c64's main memory, effectively re-entering the tool where it was last left off. The jumpbacker can be used in cases where a user is executing assembled code and the c64 main memory becomes corrupted or otherwise, preventing any built-in jumpback routine from working. See below for a more detailed explanation of how this fits in with the extra memory features of TMP.

Each version of TMP is entered in the same way, by jmp'ing to $8000 from inside a monitor or toolcart (e.g. Super Snapshot) or by executing from BASIC using 'sys 8*4096'. This starts the TMP program, which initializes various things and places you directly into the interactive editor. One important feature of TMP (and all versions of TA/TAM) is that re-entrance into the program does not initialize or erase your source code data; you can exit and re-enter the program multiple times and each time you are back to where you left off within the source code.

Extra RAM Concepts

While TMP offers a number of additonal features and bug fixes against the OriTAM, the most vital to understand is how TMP handles extra memory in the REU, R2, DTV, and PTV mods. Each of these mods adopts a 'bank' concept which treats the extra RAM as one or more 64k banks. TMP then assigns to each bank some role in the code-test-code cycle. These roles are:

Assembly: the assembly bank is where assembled code (the machine code output from the assembler) is placed.

Object: the object bank is a non-volatile storage bank for additional binary object data, such as data tables, bitmaps, or even pre-assembled code libraries. When a separate object bank is used, TMP will copy it into the assembly bank *prior* to assembling. The use of an object bank therefore allows a user to preload all the binary data necessary only one time, and then code and test repeatedly without having to reload the binary data each time.

Source: a source bank holds a complete instance of the TMP program with one specific source code. TMP allows a quick way to swap between source banks, effectively changing the source code that is currently active and editable. Hardware configurations with 512k of extra RAM actually allow six (6) separate source codes to remain resident in memory at a time. Only one is active (in the c64's main memory) at any given moment. Whatever source code is currently active is the one that will be assembled to the assembly bank. Once a source code is assembled the user is prompted to execute the code, and if they do, TMP swaps the assembly bank into the c64 main memory while the active source code is swapped out to the assembly bank. At that moment there are actually two identical copies of the source code in himem - one in the assembly bank and one in whatever source bank it was originally assigned to. After this swap, the assembled code is executed. TMP will by default store a short routine in memory which can be jmp'd to and which will re-swap the assembly bank back into c64 main memory and re-enter TMP, returning to the code editor where it was left off prior to assembling.

There are typically 4 different extra memory size configurations:

64k: Effective in the DTV mod. Because there is only one bank available, TMP treats it as a combined assembly/object bank. It is not possible to store and swap between other source codes, and obviously the object data is not separated into it's own non-volatile bank; but the extra bank still enables a rapid code-test-code cycle at least without being required to reload the assembler and code after each test run.

128k: Effective in the REU mod. Bank 0 is used as the assembly bank and bank 1 is used as the object bank. It is not possible to store and swap between other source codes, but the object data remains uncorrupted after each test run.

256k: Effective in the REU mod. Bank 0 is the assembly bank. Bank 1 is the default object bank but this can be altered to any bank 1-3. There are two extra banks available to hold up to two different source codes at once.

512k: Effective in the REU and PTV mods. Bank 0 is the assembly bank. Bank 1 is the default object bank but can be altered to any bank 1-7. There are six extra banks available to hold up to six different source codes at once.

Dual c64 Concepts

Our X2/R2 mods function essentially the same as similar 'dual c64' mods from the past which enabled development to occur on a primary or 'master' system and then transmit and execute code over a cable to a secondary or 'slave' system. X2 refers to a version of TMP geared for users with 2 c64 systems but no REU. R2 is a version unlike any Turbo mod before it, because it combines TMP+REU's powerful REU modifications with the capability to assemble the object code to the second c64 as well.

To use the X2/R2 mods, first install the 'x2rec' object code to the slave system - this code will run and wait to receive the assembled code from the master system. The source for the x2rec code, as well as a prebuilt binary located at $334, are included in the toolset. Once you have executed the code on the slave (e.g. jmp $334 for the prebuilt x2rec), then you are ready to perform a {back-arrow}+% command on your TMP instance running on the master system. Doing so sends the assembled object code across the X2 cable to the slave. When the xfer is complete, the code automagically starts on the slave. Assuming the x2rec code is not overwritten in the course of testing you may simply reset and rerun the x2rec code to prepare for another assemble and test run. Instructions on making the cable are included in the 'x2rec' source code file; it is really quite simple, straight wiring a few pins from each user port together.