SD-card cartridge#


Perhaps the most elegant solution for loading CAS files into your P2000T is via a cartridge that hosts an SD-card slot. Even the smallest SD-cards have enough capacity to store the complete P2000T tape archive. Reading from such an SD-card is non-trivial and requires both a hardware solution to interface with the I/O port of the P2000T as well as a software solution to navigate through the files hosted on a FAT32 partition. This page explains both parts in more detail.


The SD-card cartridge uses I/O port 0x60-0x6F and requires a P2000T which has this port available. There are a number of other expansion cards which also use this port and such cards are mutually incompatible with the SD-card cartridge.


This page contains a lot of technical details which can in principle be skipped by the non-interested reader. To get started working with the SD-card cartridge, head over to one of the sections below:

There is also a manual available in Dutch which can be found via this link.

Cartridge details and features#

In Figure 33, the schematic of a SLOT2 SD-card interface is provided. This schematic is fairly complex and we will break it down into several independent components.


Fig. 33 SD card cartridge schematic. Click here to download the schematic.#

Parallel to serial conversion#

Communication with SD-cards proceeds via the SPI protocol. The SPI-protocol is inherently a serial protocol, yet the Z80 uses a parallel interface. One way for the Z80 processor to communicate with the SD card is via a process called bit banging. This is rather inefficient as we basically use only 1 out of the 8 bits every time the Z80 executes an instruction. More efficient would be to use the full 8 bit databus every time an instruction is executed. To accommodate this, we make use of one parallel-in-serial-out (PISO) and one serial-in-parallel-out (SIPO) shift register (74HC165 and 74HC595, respectively).

When communicating with the SD-card over the serial connection, we need to be able to transfer or receive 8 bits of information in the same time it would normally take to complete one instruction on the Z80. Thus, the parallel to serial interface needs to operate at a much higher clock frequency than the Z80. In this implementation, we make use of a timer circuit driven by a 16 MHz oscillator (which frequency is halved via a 74HC163 counter chip) to drive both the shift registers as well as the CLOCK signal of the SPI interface. Herein, the shift registers are fed the inverted CLOCK signal which is delayed by half a clock cycle with respect to the regular CLOCK signal. The SD-card receives the regular CLOCK signal, ensuring that the SD-card is half a clock cycle ahead of the shift registers.

The SPI protocol is a synchronous protocol, so essentially bits of data are exchanged between the host device (master) and the SD-card (slave). In our implementation, this becomes effectively 8 bits or 1 byte at a time. To transfer a byte from the Z80 to the SD-card, first the byte is transferred to the PISO register after which a timer circuit is started that exactly emits 8 clock pulses, transferring the byte from the PISO register to the SD-card. Simultaneously, the SIPO register receives 8 bits from the SD-card and stores them. The Z80 can then retrieve the byte of data by reading from the SIPO register. This synchronous protocol implies that when the Z80 only needs to receive data from the SD-card, e.g. when it receives a block of data, it still needs to keep sending new bits of data to the SD-card. The elegancy of this design is that the Z80 can keep on doing stuff (e.g. loading the next instruction) while the SD-card circuitry is running in parallel.


The implementation used in the schematic above is based on this source. It should be mentioned that a 74HC123 multivibrator has been added to add a little delay to avoid ‘double-triggering’ of the timer circuit.

I/O selection#

The SD-card cartridge hosts a number of devices and chips which all require their own I/O address for efficient communication. By means of two 3-to-8 line decoders (74HC138), the lower byte of the I/O address is used to interface with at most 16 devices. Note that only 11 of the 16 lines are being used. All are wired to I/O ports 0x60-0x6F and the upper byte is being checked by means of a 74HC85 chip. An overview of all the port numbers is provided below.

Port number




Serial read/write



Start clock circuit



Set MISO pull-up/down



Set/unset CS on SD-card






not used



not used



not used



Lower address byte



Upper address byte



Bank register ROM



Bank register RAM



ROM chip



RAM chip



not used



not used


Interfacing with the devices proceeds via the IN and OUT instructions. For example, to send 0xFF to the SD-card and read back the resulting byte, one would use:

ld a,0xFF
out (0x60),a     ; set all ones
out (0x61),a     ; start timer circuit, value in register a is not used
in  a,(0x61)     ; receive result from SD-card

RAM and ROM chips#

The SD-card cartridge uses a SST39SF010 and a 62128 as the ROM and RAM chips, respectively. Both these chips have a capacity of 128kb. The ROM chip is used to store the launcher (more information on this later) and the RAM chip is used for intermittent storage of the CAS programs. As the I/O interface of the Z80 only allows us to use 8 bits at a time, the addresses for these chips are stored in two 8-bit registers (74HC273) and one 2-bit register (74HC74). The former two chips store the lower and upper byte of the address and the latter chip is used for banking. Each bank thus corresponds to 64kb of memory. Note that both the ROM and RAM chip share the 16-bit address registers which in practice does not result in any difficulties.

Reading from the ROM and RAM chips proceeds in a fairly equivalent fashion. The bank is set by writing a 0 or a 1 to address 0x6A for the ROM chip and 0x6B for the RAM chip. Next, the 16-bit address is set by writing the lower byte to 0x68 and the upper byte to 0x69. After setting the address, one can read from either 0x6C for the ROM chip or from 0x6D for the RAM chip. For example, reading a byte at address 0xAA55 from the ROM chip would look as follows.

ld a,0x00
out (0x6A), a    ; set first bank (bank 0)
ld a,0x55
out (0x68), a    ; set address lower byte (0x55)
ld a,0xAA
out (0x69), a    ; set address upper byte (0xAA)
in  a,(0x6C)     ; read from chip address 0xAA55

Writing to the RAM chip is fairly easy and only requires an OUT instead of an IN instruction. An example where the value 0x00 is written to address 0xAA55 is provided below.

ld a,0x00
out (0x6B), a    ; set first bank
ld a,0x55
out (0x68), a    ; set address lower byte (0x55)
ld a,0xAA
out (0x69), a    ; set address upper byte (0xAA)
ld a,0x00
out (0x6D), a    ; store byte in A into RAM chip at 0xAA55

Writing to the ROM chip is a bit more involved and requires a sequence of instructions. More details on this sequence can be found in the datasheet of the SST39SF0x0 family of chips.


Below, an image of the PCB (backside, unpopulated and populated) is shown. As can be readily seen, there is not much free space left on this PCB. At the center, one finds the SST39SF010 chip seated in a PLCC32 socket while directly above the 128kb RAM chip is found. On the right top, the 16 MHz oscillator is located. On the left top, a SD-card interface board is mounted. This board does the level shifting between the 5V lines on the PCB and the 3.3V lines on the SD-card. Directly to the right of the PLCC32 socket, the 2x74HC273 buffer chips are found which store the address bus for both the ROM and RAM chips.



Using the hardware set-up as explained above, we can interface with our SD-card. Communication with an SD-card proceeds via sending a series of command words to the SD-card upon which the SD-card responds. These command words are sent via the I/O port.

The exact procedure is provided in the (official) document “Physical Layer Simplified” which can be found via this page. Referring to Figure 4-2 in this document, the process of initializing an SD-card such that we can read blocks from it goes as follows.

  1. Set CS to low on the SD-card

  2. Send at least 74 pulses of 1 to the SD-card

  3. Send CMD0 to the SD-card ({0|0x40,0,0,0,0,0x94|0x01}) to put the card in SPI mode and check for a valid R1 response.

  4. Send CMD8 to the SD-card ({8|0x40,0,0,0x01,0xaa,0x86|0x01}) to send the interface condition (argument 0x1AA) and check for a valid R7 response.

  5. Send CMD55 to the SD-card ({55|0x40,0,0,0,0,0x00|0x01}) for an application specific command and check for a valid R1 response.

  6. Send ACMD41 to the SD-card ({41|0x40,0x40,0x00,0x00,0x00,0x00|0x01}) to send the host capacity support information (argument 0x40000000) and check for a valid R1 response.

  7. Keep on repeating steps 5 and 6 until a response of 0x00 is being received. This typically takes roughly 2-3 calls.

  8. Send CMD58 to the SD-card ({58|0x40,0,0,0,0,0x00|0x01}) to read the OCR register and read the R3 response.

  9. The card is now ready to receive CMD17 commands which request 512 byte blocks from the card.


The whole procedure is quite involved and I can warmly recommend to read upon this excellent guide when one is interested to implement such an interface yourself.

FAT32 file system#

The SD-cards used for this cartridge utilizes the FAT32 protocol for file storage. To navigate through the folders and access the files, we need to understand how this storage protocol works. Luckily, FAT32 is relatively simple and well-documented. We will not provide a detailed explanation of the storage format (see also the tip below if one is interested), yet suffice with a brief overview of how files are retrieved from a FAT32 filesystem.

  1. The first 512 bytes of the SD-card, i.e. the master boot record (MBR), is loaded. The MBR contains information on the partitions.

  2. From the MBR, the logical block address (LBA) of the first partition is read.

  3. From the partition table, the number of bytes per sector, the sectors per cluster, the reserved sectors, the number of FATs, the sectors per FAT, and the LBA of the root directory are read and stored for later use.

  4. Once the LBA of the root directory is established, we can start reading the metadata that describes the files and subdirectories that reside in the root directory. For files, these provide links to the actual file data. For subdirectories, these provide a reference to where the metadata for the content that is stored in that subdirectory.

  5. Based on the file metadata, a sequential list of clusters can be constructed which contain the actual file data. These clusters are traversed and all the sectors for each of these clusters is being read and transferred to the P2000T.



The SD-card cartridge works very similar as compared to the data cartridge. A modified BASICNL cartridge is prepared that loads a LAUNCHER program from the ROM chip on the SD-card cartridge into memory. Next, this launcher program is executed which interfaces with the SD-card. To set-up this infrastructure, one needs to prepare a SLOT1 cartridge with the modified BASICNL rom and one needs to flash the launcher program on the ROM chip of the SD-card cartridge.


The data cartridge also uses a modified BASICNL ROM, however this modified BASICNL ROM is a different one and the two types are not interchangeable.

Summarizing, the following is required to start working with the SD-card cartridge.

  • A SLOT1 cartridge with the modified BASICNL application.

  • A SLOT1 cartridge with the flasher application.

  • The SD-card cartridge with a FAT32-formatted SD-card and the launcher application flashed to its internal ROM.

Creating the SLOT1 cartridges#

First, we need to construct two SLOT1 cartridges, being the modified BASIC cartridge and the flasher. The BIN files for these two cartridges can be obtained via the links below:

Upload these two BIN files to different ROM slots on the ZIF cartridge. A detailed guide on the procedure can be found on the page describing the ZIF cartridge.


Make a note which slot you have used for which cartridge file.

Flashing the launcher onto the ROM chip#

Next, we need to prepare an SD-card and place the LAUNCHER.BIN on this SD-card in its root directory.


The SD-card cartridge only works with FAT32 formatted SD-cards. When formatting the SD-card, it is highly recommended to use default settings for the cluster size.

If the SD-card is not yet formatted, format the SD-card using a FAT32 filesystem. Place the LAUNCHER.BIN file in the root directory of the SD-card. The latest version of the LAUNCHER.BIN file can be downloaded via the link below.

Insert the SLOT1 cartridge with the flasher and the SD-card cartridge in SLOT2 and turn on your P2000T. Hit any key to start interfacing with the SD-card and search for a file called LAUNCHER.BIN. If such a file is found, the file will be copied to the internal ROM chip of the SD-card cartridge. Any previous data corresponding to previous versions of the launcher will be automatically wiped. After copying the file to the ROM chip, a CRC-16 checksum is automatically generated and used for verification purposes.

a a
b b
c c
d d

Fig. 34 (a) Opening the SD-card Flasher utility; press any key to start. (b) Program checks whether a file called LAUNCHER.ROM is found. (c) LAUNCHER.ROM file is copied to the internal ROM chip. (d) CRC-16 checksum is being generated for verification purposes. ** Note that these images correspond to an earlier version of the Flasher, but the procedure remains very similar across different verisons of the Flasher utility.**#


  • Since version 0.5.0, you no longer have to verify the checksum for yourself, this is now done automatically by using a self-signing checksum. The Flasher will inform you if the checksum validation has passed successfully or otherwise show an error message.

  • If you are however running a version prior to version 0.5.0, always check whether the CRC-16 checksum as calculated by the flasher matches the one as provided in the launcher-checksum.txt file!

Launching CAS programs from the SD-card cartridge#

Programs can be loaded from the SD-card and executed using the launcher. To load the launcher into memory, the P2000T requires a modified BASICNL cartridge (see the instructions under preparation on how to prepare such a cartridge) in SLOT1. This modified BASICNL cartridge will copy the launcher from the internal ROM chip on the SD-card cartridge to memory and run it.

Loading a program from the SD-card is fairly easy. There are only three commands one needs to be know: ls, cd and run. cd is used to navigate to (sub)directories. ls is used to show a listing and run is used to start a program. Per directory, all items inside the directory have a number (called an index) which starts at 1. On execution of a ls command, these indices are shown. To change directory, type cd followed by the index number. For example, cd 4 will go to the fourth entry. If that entry is a subdirectory, the launcher jumps to that folder. To run a program, one types run followed by the number. For example, run 107 will run the 107th entry in the folder. In the example shown in Figure 35, this corresponds to the Tetris program.


Users familiar with Linux or MS-DOS operating systems are used to writing the actual filename or directory name when using commands such as cd and run. A different approach using indices was intentionally chosen to save upon typing but also to save upon more complex (and large in size) routines in the launcher application.

a a
b b
c c
d d

Fig. 35 (a) Opening the SD-card launcher. (b) The user went to subdirectory item 4 and runs ls to get a listing of the subdirectory contents. (c) The user runs item 107 (Tetris) and the program is transferred from the SD-card to the external memory chip. (d) All sectors have been transferred and the program is ready to be executed or alternatively, its CRC-16 checksum can be validated (after which the program can still be executed)#


Instead of ls, one can also run lscas. The difference is that the latter command will also read the headers of the .CAS files and mention the name of the tape and the number of blocks.

Cartridge commands#

Below, an overview of the commands is provided.




List contents of current folder


List contents of current folder, listing contents of CAS files

cd <number>

Change directory

run <number>

Run .CAS file

hexdump <number>

Performs a 96-byte hexdump of a file

fileinfo <number>

Provides location details of a file


Performs a quick test on the read/write LEDs