Timex Command Cartridges
"Solid" Software

(under development)

TS1000/1500 Cartridges:

Timex made the TS1510 cartridge player to add the command cartridges to the TS1000 and TS1500 computer. This cartridges are incompatible with the TS2068 cartridges.

The TS1000/1500/ZX81 use the signal /ROMCS to disable the internal ROM. The cartridge works by pulling this low and placing its own ROM in this range. The Spectrum 48K and IF2 also works in this way.

TS2068 Cartridges:

TCC or Timex Command Cartridges are a solid state technological achievement. Like a video game cartridge, they easily plug into TS2068 in Dock port to instantly meet diferent needs. The tiny Timex Command Cartridges actually add up to 56K of additional ROM memory to the computer. They can contain any kind of program (games, business programs, word processors,...)

1º - Turn off TS2068
2º - Open Dock port and insert cartridge with label facing up
3º - Close Dock port
4º - Turn on TS2068

Now the software in cartridge will start to work.
Caution: Never remove or insert a cartridge with the computer on!

Types of TS2068 Cartridges:

Actually exists 3 types of cartridges: LROS, AROS and ROMs.

LROS takes control of the computer, the internal ROMs are not used;
AROS uses BASIC interpreter;
ROM is simply a ROM chip. In TS2068 to a ROM work, you must type OUT 244,3 to "page" the DOCK port.

ROM extensions mapped into the DOCK bank are mostly implemented as LROS (Language ROM Oriented Software) and AROS (Application ROM Oriented Software). LROS programs are mapped at address 0 in the DOCK bank and they must be written in machine code. AROS programs are mapped at address 32768 in the DOCK bank, and may be either in machine code or in BASIC (The Timex BASIC interpreter allows the running of BASIC programs from the DOCK bank). LROS programs always have autorun and they will be started after initialization of the Timex computer is finished (an example of such software is Zebra OS_64). AROS programs may be or may not to be autorun programs. Both type of programs have a short header at the beginning which contains the necessary informations (start address etc.) for their execution.

DCK FILES - Used by Warajevo emulator

DCK files keeps information about memory content of various Timex memory expansions, and information which chunks of extra memory are RAM chunks and which chunks are ROM chunks. Such files have relatively simple format. At the beginning of a DCK file, a nine-byte header is located. First byte is bank ID with following meaning:

0: DOCK bank (the most frequent variant)

1-253: Reserved for expansions which allow more than three 64 Kb banks

254: EXROM bank (using this ID you may insert RAM or ROM chunks into EXROM bank, such hardware units exist on real Timex Sinclair)

255: HOME bank (mainly useless, HOME content is typically stored in a Z80 file); however, using this bank ID you may replace content of Timex HOME ROM, or turn Timex HOME ROM into RAM

This numbering of banks is in according to convention used in various routines from Timex ROM.
After the first byte, following eight bytes corresponds to eight 8K chunks in the bank. Organization of each byte is as follows:

bit D0: 0 = read-only chunk, 1 = read/write chunk

bit D1: 0 = memory image for corresponding chunk is not present in DCK file, 1 = memory image is present in DCK file

bits D2-D7: reserved (all zeros)

To be more clear, these bytes will have following values:
- 0, for non-existent chunks (reading from such chunks must return default values for given bank; for example, #FF in DOCK bank, and ghost images of 8K Timex EXROM in EXROM bank)

- 1, for RAM chunks, where initial RAM content is not given (in the emulator such chunks will be initially filled with zeros)

- 2, for ROM chunks

- 3, for RAM chunks where initial RAM content is given (this is need to allow saving content of expanded RAM; also this is useful for emulating non-volatile battery-protected RAM expansions) After the header, a pure image of each presented chunk is stored in DCK file. Some examples will help understanding of such organization. 16 Kb long LROS program needs header 0,2,2,0,0,0,0,0,0 in front of pure binary image of this program. 24 Kb long AROS program needs header 255,0,0,0,0,2,2,2,0 in front of binary image of it to become a valid DCK file. 64 Kb DOCK RAM disc cartridge (64K of empty RAM) may be described as only 9-byte long DCK file with content 0,1,1,1,1,1,1,1,1. 32 Kb EXROM RAM disc cartridge mapped at address 32768 may be described also using 9-byte long DCK file with content 254,0,0,0,0,1,1,1,1. If you put a 9-byte header 255,2,2,0,0,0,0,0,0 in front of binary image of standard ZX Spectrum ROM, you will get DCK file which will replace Timex HOME ROM with ordinary Spectrum ROM (e.g. you will achieve Timex Computer 2048). At the last, if you put a header 255,3,3,0,0,0,0,0,0 in front of binary image of Timex HOME ROM, you will allow writing in the HOME ROM!

That's all if only one bank is stored in DCK file. Else, after the memory image, a new 9-byte header for next bank follows, and so on.

The Spectrum Emulator Cartridge:

This cartridge made by Timex of Portugal, contains a ROM image of TC2048. I think that this isn't a ROM cartridge, but a LROS cartridge, because it is simply plugged to TC2068 and it starts automaticaly. Many American Timex Sinclair 2068 users made a cartridge with a ROM chip of a ZX Spectrum and because of this, they have to type the OUT 244,3 command.

Cartridge Software Overview

The TS2068 supports two basic types of Cartridge or ROM-Oriented Software designated as LROS (Language ROM-Oriented Software) and AROS (Application ROM-Oriented Software) which pluq into the cartridge connector. They are identified via overhead bytes at Location 0 for an LROS or 32768 (8000H) for an AROS. The fundamental difference is that an LROS contains Z80 machine code in memory chunk 0 and is in total control of the TS2068 hardware including the RESTART implementation and Interruption Mode setting and handling, while an AROS is dependent on the System ROM or an LROS for these functions if needed. An AROS written in BASIC, which may also include machine code accessed via the USR function, is supported from the System ROM BASIC Interpreter and is mapped beginning in memory chunk 4. An AROS may also be written entirely in Z80 machine code. An AROS written in any other high-level language would require an LROS supporting that language and would have to be integrated with the LROS in a single cartridge.

BASIC AROS Support

BASIC Application Cartridges are supported by special code in the Home ROM. A program line is copied from the cartridge to a buffer in the Home RAM (ARSBUF) and is then executed from there by the BASIC Interpreter. When a READ command is executed, the line containing the appropriate DATA statement is also copied from the cartridge to the RAM. The cartridge memory is enabled only fur search and copy operations for both program lines and DATA statements, and when executing a USR function, otherwise the entire Home Bank is enabled while executing in the BASIC Interpreter. There is no support for User-Defined Functions which insert the expanded definition parameters directly into the program and then require search of the program area to find these parameters whenever a function is invoked.

Cartridge Software/Hardware

LROS

An LROS is identified by the following overhead bytes:

Interruption Mode 1 has been set by the TS 2068 and interruptions are enabled prior to passing control to the LROS starting address, therefore the LROS must contain appropriate code at location 56 (38H) to cover the case where the interruption occurs after Chunk 0 in the Dock Bank has been enabled, but before any action by the software cartridge to disable the interruption has been taken. Once control is transferred, the LROS may then disable the standard TS 2068 interruption by setting bit 6 of Port FFH, mask the interruption by executing a DI instruction, or set a different Interruption Mode. It may change the location of the Machine Stack. It may also change the memory selection by writing to Port 0F4H with each bit set to 1 for the corresponding chunk to be enabled in the Dock Bank (high active format) or 0 to be enabled in the Home Bank. Thus, an LROS may contain code in Chunk 3, but it should be enabled after the OS RAM code has finished execution. Now that your LROS is in the driver's seat, you are on your own! Some important points to remember when,, mapping your Dock Bank memory and doing bank switching are:

1. The Display RAM is in Home Bank Chunk 2 for the primary display file and Chunk 3 for the second display file. This memory is accessed independently by the video hardware. The software only needs to enable it when actually reading or writing it.

2. The Dock Bank and Extension ROM Bank are mutually exclusive since they share the Horizontal Select Register in Port F4H. You will need a routine in the Home Bank RAM to do any switching between the two. You must also be careful to have the appropriate Home Bank Chunks enabled which are referenced by the Extension ROM code, e.g. the System Variables in Chunk 2 or possibly the bank switching code in Chunk 3.

3. Some interesting switching routines can be constructed by having parallel code in shadowing chunks of memory to take advantage of the"instant" switch in execution from one hank to another when the memory selection is made. E.g. a routine in the Dock Bank ROM in Chunk 6 could push a Home Bank address on the stack, write to Port F4H enabling Chunk 6 and any other desired chunks in the Home Bank (by deselecting them in the Dock), and have code at the next sequential instruction address in Home Bank RAM Chunk 6 to continue the path. A Return instruction, for example, would pass control to the address on the stack. Code to switch memory back to the Dock Bank could be mapped in a similar way.

4. If you plan to use any of the System software routines, unless you know otherwise it is probably necessary to maintain the contents of Home Bank Chunks 2 and 3 intact (and Chunk 7 if the OS RAM routines have been relocated). The system routines rely heavily on the System Variables and assume that any pointers in them are pointing to the Home Bank. See Section 3.3.4.1 for details on using the RAM Interruption Handler and Section 6.0 for known corrections when using System S/W.

5. If you design an LROS implementing a higher-level language and want to support an AROS application, you must design your own initialization code to detect the presence of such an AROS. The TS 2068 will not look for the presence of an AROS if an LROS is present, therefore there will be no entry for the AROS in the System Configuration Table. Note that since there is only one cartridge connector, such an AROS would also have to be integrated with the supporting LROS in a single cartridge or cartridge board.

AROS

An AROS is identified by the following overhead bytes