Technical Info:

What follows is technical information for users who want to know more about the emulator or want to develop support programs for the emulator or new software for the TRS-80 running on the emulator. Nothing contained here is required to use the emulator.

Return to contents: 

Technical info - DMK type virtual disks:

This information on what has become known as the DMK virtual disk format is provided for users wanting to better understand the operation of the emulator and for programmers writing their own emulators wanting to add support for this format and/or the creation of PC utilities to work with the DMK virtual disk format.

This virtual disk format is as close to the way data on a real disk is stored as possible. There is very little added overhead and the data is easily examined and edited using PC based hex editors. The actual design is really quite simple and enables support of ALL the WD-1771 and WD-19xx controller functions and formats. While the design is simple however the programming requirements for this format are much more extensive then for the JV1/JV3 formats.

Disk header:

Virtual disks have a 16 byte disk header which is initialized when the user creates a new virtual disk. This header may be modified before or after a virtual disk has been formatted to change some of its characteristics. 

Track header:

Each side of each track has a 128 (80H) byte header which contains an offset pointer to each IDAM in the track. This allows a maximum of 64 sector IDAMs/track. This is more than twice what an 8 inch disk would require and 3.5 times that of a normal TRS-80 5 inch DD disk. This should more than enough for any protected disk also.

These IDAM pointers MUST adhere to the following rules.

• Each pointer is a 2 byte offset to the FEh byte of the IDAM. In double byte single density the pointer is to the first FEh.
• The offset includes the 128 byte header. For example, an IDAM 10h bytes into the track would have a pointer of 90h, 10h+80h=90h.
• The IDAM offsets MUST be in ascending order with no unused or bad pointers.
• If all the entries are not used the header is terminated with a 0000h entry. Unused entries must also be zero filled..
• Any IDAMs overwritten during a sector write command should have their entry removed from the header and all other pointer entries shifted to fill in.
• The IDAM pointers are created during the track write command (format). A completed track write MUST remove all previous IDAM pointers. A partial track write (aborted with the forced interrupt command) MUST have it's previous pointers that were not overwritten added to the new IDAM pointers.
• The pointer bytes are stored in reverse order (LSB/MSB).

Each IDAM pointer has two flags. Bit 15 is set if the sector is double density. Bit 14 is currently undefined. These bits must be masked to get the actual sector offset. For example, an offset to an IDAM at byte 90h would be 0090h if single density and 8090h if double density.

Track data:

The actual track data follows the header and can be viewed with a hex editor showing the raw data on the track. If the virtual disk doesn't have bits 6 or 7 set of byte 4 of the disk header then each single density data byte is written twice, this includes IDAMs and CRCs (the CRCs are calculated as if only 1 byte was written however). The IDAM and sector data each have CRCs, this is just like on a real disk.

Modification should not be done since doing so without updating  the CRCs would cause data errors. Modification could be done however to create protected tracks for importing protected disks to virtual disk format. Examples of disks created using this technique are "Super Utility+ 3.0" and "Forbidden City".

Return to contents: 

Technical info - JV1/JV3 type virtual disks:

This emulator is capable of reading and writing to JV1 and JV3 type virtual disks. Support for this type of virtual disk is limited by both the limits of the format type and this emulators support of it.

The emulator supports read sector, read address and write sector commands to the JV1 type virtual disk. JV1 disks are single density only and can be up to 254 tracks long and always have a protected directory track at track 17. Read track and write track commands are not supported for this disk type. This disk  type can be write protected from the "virtual floppy disk selection screen" but the write protect status will always default to off when ever a JV1 disk is opened.

The emulator supports read sector, read address and write sector commands to the JV3 type virtual disk. JV3 disks are single/double density and can be up to 96 tracks long. Read track and write track commands are not supported for this disk type. This disk  type can be write protected from the "virtual floppy disk selection screen" but the write protect status will always default to what ever status is in the the JV3 virtual disk file (byte 21FFh) when the disk is opened, the write protect status is not updated. The density and CRC error flags are also supported but not updated. DAM types FB/F9 report FB and F8/FA report F8. Sector writes that change the DAM type from what is in the virtual disk file are not supported. This will not cause problems unless you try to change the protection status of a directory track. Standard IBM sector sizes are supported of 128, 256, 512 & 1024 bytes. A second sector header block is not supported.

Return to contents: 

Technical info - REAL TRS-80 floppy disks:

This emulator is capable of reading, writing and formatting REAL TRS-80 floppy disks in compatible PC floppy drives. Support for this is limited by both the limits of the NEC type floppy disk controller and this emulators support of it.

Depending on compatibility of your PC you should be able to read/write single density & double density 5.25" and 3.5" disks in 360k and 720k PC floppy drives (commonly known as low/double density drives, DD). You should be able to read/write double density 5.25" and 3.5" disks in 1.2meg and 1.44meg PC floppy drives (commonly known as high density drives, HD).

Eight fixed sector length REAL floppy specification virtual disks are supplied to read/write 256 byte/sector floppies in a PC's A: and B: drives.

Eight variable sector length REAL floppy specification virtual disks are supplied to read/write 128-1024 byte/sector floppies in a PC's A: and B: drives. These specification disks are slower than the fixed length ones and should only be used on disks un-readable with the fixed length specification disks.

Because of the limitations of the PC's NEC type floppy disk controller the PC cannot read most protected disks. The emulator does not support the track read commands with REAL floppies. Because of limitations of the PC's controller most disk zap utilities (like Hyperzap and Super Utility) cannot work with REAL floppies. Also the write track command has to translate format data to the PC's controller form and is therefore unable to format anything but standard sectors. Because of the translation for PC disk I/O, access to real TRS-80 disks is apt to be slow, formatting in some cases can take as long as 8 seconds/track. This is unavoidable and should not present problems since REAL disk support is mainly for importing your existing TRS-80 disks and transferring data and programs to the TRS-80. If your PC has a hard time reading your TRS-80 disks then use the emulator to format a disk on the PC and then copy the disk on the TRS-80 to the PC formatted disk, this should correct most problems.

Some PC's cannot read SD TRS-80 disks and still others cannot read any TRS-80 disks without errors. This is a compatibility problem with different PC controllers and not a problem with the emulator. Try using a different brand of PC or an older model PC. If you are still unable to read your disks and really need the data converted, e-mail me and maybe I can convert the disk for you (my PC has been able to read every disk I've tried so far).

Return to contents: 

Technical info - Virtual hard disks:

This information on what are known as the HDV virtual hard disks is provided for users wanting to better understand the operation of the emulator and for programmers writing their own emulators wanting to add support for this format and/or the creation of PC utilities to work with the HDV virtual disk format.

These emulators support the existing HDV format and have extended the format to support 1024 cylinder hard drives using the WD1010 hard drive controller emulation.

Disk header:

Virtual hard disks have a 256 byte disk header which is initialized when the user creates a new virtual disk. This header may be modified before or after a virtual disk has been formatted to change some of its characteristics. 

Return to contents: 

Technical Info - Enhanced Z80 instructions

The emulator has a set of enhanced Z80 instructions. These instructions allow TRS-80 programs to interface with the PC's disk drives, ports, memory and other hardware. These instructions also add high level math functions to the Z80 instruction set.

NOTE: These instructions are only available in the emulators.

The following links contain a list of the enhanced instructions and documentation for each instruction.

Enhanced Instruction Documentation (on-line)

Enhanced Instruction Documentation (Microsoft Word 123k)

Return to contents: 

Technical Info - Port mapped PC I/O commands

In addition to the enhanced Z80 instructions described above the emulator can also interface with the PC using port mapped commands. These commands provide an easier to use interface when writing programs in BASIC or other high level language eliminating the need for machine language calls.

The port mapped I/O commands allow access to the 13 I/O functions between 30h and 3Fh as defined in the Enhanced Instruction Documentation. These port mapped I/O commands also allow access to the PC's I/O ports. The Z80 ports 50h to 57h can be mapped to any of the PC's I/O ports.

Port 70h is used execute commands, define which data register or PC port, port 71h points to and read the status of the previous command.

Outputting a value of 30h to 3Fh to port 70h executes the corresponding enhanced Z80 instruction. The status of the command can be checked by a read to port 70h. In most cases a non-zero value indicates an error condition.

Outputting a value of 40h to 43h to port 70h defines which register port 71h points to. The registers are:

40h = DE register
41h = HL register
42h = BC register
43h = AF register

After outputting a value to port 70h the LSB of the register is available at port 71h, the value can be read or written. After accessing port 71h the MSB of the value will be available and can be read or written. After a second I/O to port 71h the LSB value will be available again. The data available at port 71h toggles between the LSB & MSB values of the defined register each time you access it. For example, to load a register HL with 3C00h you could use the following BASIC program:

10 OUT 112,65 : REM DEFINE HL REGISTER, BASIC WANTS DECIMAL NUMBERS
20 OUT 113,0  : REM LOAD L WITH 00H
30 OUT 113,60 : REM LOAD H WITH 3CH

Reading the register is done the same way except using INP(113) instead. Once the registers required by the desired 30h to 3Fh command are loaded, an output of that command to port 70h is done. The returned data, if any, is then available in the same registers.

Outputting a value of 80h to 87h to port 70h defines which PC port, Z80 ports 50h to 57h point to. After outputting a value to port 70h the LSB of the PC port number is available at port 71h, the value can be read or written. The data available at port 71h toggles between the LSB & MSB values of the defined port each time you access it. For example, to point Z80 port 53h to the PC game port at 201h and then read port 201h you could use the following BASIC program:

10 OUT 112,131 : REM DEFINE PORT 53H, BASIC WANTS DECIMAL NUMBERS
20 OUT 113,1   : REM LOAD LSB WITH 01H
30 OUT 113,2   : REM LOAD MSB WITH 02H
40 A=INP(83)   : REM READ Z80 PORT 53H WHICH POINTS TO PC PORT 201H
50 PRINT A     : REM A CONTAINS THE JOYSTICK STATUS FROM PC PORT 201H

Some program listings of BASIC programs are available as examples of using the port mapped I/O commands:

BASIC Examples

Return to contents: 

Technical info - Keyboard maps:

The TRS-80 emulators support two keyboard maps. These files determine the relationship between the PC keyboard and the TRS-80 keyboard. Each key on the PC keyboard can be mapped to a key on the TRS-80 keyboard. More than one PC key can be mapped to the same TRS-80 key (ex. Backspace & left arrow are both mapped to left arrow on the TRS-80 keyboard).

Each keyboard map file contains 512 bytes which are organized in pairs. The first 128 byte pairs are unshifted keys the last 128 are the same keys shifted. The PC communicates with its keyboard using scancodes. Each PC key has a scancode and each scancode has a matching 2 byte value in the keyboard map. For example the 'ENTER' key has a scancode of 28, therefore the 2 keyboard map values at 2 times 28 plus 1 (57), contains the TRS-80 keyboard value for an unshifted 'ENTER' key. The map values 2 times 28 plus 257 (313), contains the TRS-80 keyboard value for a shifted 'ENTER' key.

Below is a graphic of a standard PC keyboard layout showing the scancodes for each key. All the scancodes shown correspond to a keyboard map entry. The PC key's table entry can be found by multiplying the scancode by 2 and adding 1 for unshifted values or adding 257 for shifted values.

Note: The scancodes for the cursor keys are not the actual scancodes but the scancode plus 32 because the actual scancodes are the same as for the number pad. The PC prefixes these keys with a special code. The emulator adds 32 to these prefixed scancodes so they can have their own keyboard map entries.

As said before each scancode points to a two byte pair. The second byte is the entry type, it has the following values:

The following table is to be used to find the first byte of the keyboard map value for entry type 0. The values in this table are in hex.

For example. If you look at the PC scancode graphic you will see that the 'ESC' key has a scan code of 1. If you look at the 3rd byte of the PC80, PC81 or PC83 keyboard map file you will see a value of 38 (26 hex). Looking at the able above shows a value of 26H represents the TRS-80 'BREAK' key. The 'BREAK' key is in row 6 column 2 for the TRS-80 keyboard matrix.

The 4th byte of the keyboard map file is a zero. This means the key is unshifted. If this value was 1 then anytime 'BREAK' was pushed the emulator would also push the TRS-80's shift key. This features allows keys that are not shifted on a PC keyboard to be shifted on the TRS-80 keyboard (like '=') or shifted keys to be unshifted (like "@").

The following table is to be used to find the first byte of the keyboard map value for entry type 1. The values in this table are in hex.

For example. If you look at the PC scancode graphic you will see that the '= +' key has a scan code of 13. If you look at the 27th byte of the PC80, PC81 or PC83 keyboard map file you will see a value of 85 (55 hex). Looking at the able above shows a value of 55H represents the TRS-80 '- =' key. The '- =' key is in row 5 column 5 for the TRS-80 keyboard matrix.

The 4th byte of the keyboard map file is a one. This means the key is shifted. When this key is pushed the TRS-80 will be sent the '- =' key along with a shift key.

Most of the PC keys mapped to the TRS-80 layout in the first half of the keyboard map will have an entry type of 0 since this section is used when neither of the PC shift keys are pushed. Most of the PC keys mapped to the TRS-80 layout in the second half of the keyboard map will have an entry type of 1 since this section is used when either of the PC shift keys are pushed. Also, in most cases the first byte of a key entry in the first half of the map will be the same as the one in the second part of the map since it is just the shifted value of the other. Some of the PC keys however will have very different values in each half of the map (like' = +') for example because of the differences between the PC and TRS-80 keyboard layouts.

I hope this documentation will give users the information needed to create custom keyboard layouts.

I want to thank Knut Roll-Lund (from Norway) for his help in documenting the keyboard map files. You can see how he made his own keyboard layout and download it at: http://knut.one/~kr-lund/emul-kbd.htm

Return to contents: 

Technical Info - Emulator port/memory maps:

The Model 1 emulator memory map is as follows:

The Model 1 emulator port map is as follows:

The Model III/4 emulator supports the TRS-80 Model 4 port map as follows:

Both the Model 1 and Model III/4 emulators support a TRS-80 enhanced port map as follows:

Return to contents: