How does TRS-OS work?
TRSDOS 6.3.1 runs on Radio Shacks TRS-80 Model 4. To my knowledge, TRS-OS is first platform that executes TRSDOS SYS 1– SYS 13 unchanged (versions 6.3.1) as an guest other than original TRS-80 hardware. This is done by both simulation and emulation of original hardware.
Since eZ80 is nearly a complete SOC (system on chip) little external support circuits are needed. As a programmer, hardware I/O and operation is standardized across platforms using SOC;s. You can load the load file in most any device using eZ80 as a processor provided first 1MB is mapped as RAM.
The unregistered version provides you with two 360k RAM drives & 64k RAM main storage. These drives are referred to as VOLUMES in TRS-OS. Files created using Misosys DiskDisk, on any TRS-80 emulator or real machine can be loaded directly into RAM. Hence reverse is possible & RAM content can be saved to a file then directly loaded by a emulator or real machine with DiskDisk.
Preloaded in one VOLUME is Misosys operating system known as TRSDOS. To my knowledge Roy Soltoff of Misosys holds copyright to this material. It is being distributed here free of charge for experimentation and education. Any redistribution should carry Roy Soltoff notice of copyright.
TRS-OS works by supplying all needed services and functions to TRSDOS needed for it to run on eZ80 based SBC's. TRSDOS could be rewritten to use new hardware directly but my goal was to execute SYS1-13 unchanged from original TRSDOS disks. Term eZ80 encompasses an entire series of eZ80 processors (ez80f91, eZ80f92, eZ80f93 etc). Due to specifics of each differing version of eZ80, each version will require it's own BIOS & initialization code. Currently this project supports eZ80F91 Acclaim series.
Bank memory is not supported. Goal is to run TRSDOS on Zilogs embedded processor series eZ80. eZ80 can be considered a self-contained SOC (system on a chip). In order to support bank memory external hardware would be required and something I highly desire in future. However since eZ80 series has 24 bit addressing, important drivers and new code is written to run above 64k barrier. This frees up RAM in original 64k space. In fact LOWCORE requirements in driver region may be reduced in future releases compared to original TRSDOS requirements. With 24 bit addressing space, new doors are open to programmers and developers for accessing extended memory space.
File Space: Drivers for RAM VOLUMES (RAM DRIVES) are in included in same drivers that support DiskDisk format files. Using Misosys utility DiskDIsk, VOLUMES can be created or read on original TRS-80 hardware or emulator. DiskDisk files can be loaded directly in RAM. Total space for RAM VOLUMES has been increased past DiskDisk capacity to a full 13 MB. Space larger than DiskDisk capacity is managed by TRSDOS 6.3.1 FORMAT and other DOS commands. One driver basically manages both DiskDisk files and acts as floppy/hard disk with capacity up to 13.x MB. Upon mounting a VOUME TRS-OS logs the VOLUME and reads it DCT information thus conforming to original format. Future releases I hope to move to named VOLUME space spanning mediums other than RAM (SD, IDE, FLASH etc). RAM VOLUMES must be loaded and saved from hardware by some development loader (example eZ80f91 development kit ZDS software).
Video: As a system on chip we have no external video controller or separate video memory. TRS-OS simply lowers TRSDOS HIGH$ to block 1920 bytes of HIGH memory for video. This original space for video under TRSDOS and TRSDOS has no way of knowing if it is real dual port RAM attached to a video controller or if it is simply a block or RAM used to contain video page. TRSDOS original video drivers can be allowed to run in their native modes and none is wiser actual video hardware does not exist. TRSDOS I/O design supports device linking and routing. Since this SOC supports video via attached terminal, this external terminal is simply linked with original video driver. All original video functions will take place under TRSDOS as they always have. RAM memory starting @00F800h will contain exact original video image. Test release of TRS-OS supports linking UART0 to TRSDOS video driver.
System clock & interrupts: TRS-OS and its guest OS, TRSDOS is running inside a SOC, supporting external or internal interrupts would require changing TRSDOS memory maps. eZ80 SOC has a complex means and requires a large table for handling interrupts. Later releases will alter original TRSDOS memory map slightly and support eZ80 interrupt structure. No worries for now in this test release, tradeoffs are small. We are losing some of TRSDOS multitasking functions however eZ80 series provides RTC date/time in hardware. Thus system always has accurate date and time provided to DOS on demand. TRS-OS provides BIOS utilities to set and maintain clock.
Keyboard support: Like video, no physical keyboard is attached and available via memory mapping. Original TRSDOS keyboard driver is present and is linked with external terminal. External terminal keyboard inputs are easily linked to TRSDOS keyboard driver. Technical problems yet to be solved are key mapping. Appropriate standards for mapping terminal keyboard to support TRSDOS keyboard must be developed.
Printer support: TRSDOS supports native routing of devices. Since no physical printer is attached to this SOC, printer output is simply routed to a file on RAM VOLUME. This file can then be imported to a PC or real TRS-80 and printed using standard print tools.
Serial port: UART0 is used to support systems console. UART1 is represented in TRSDOS as *CL. Driver was written to make UART1 emulate original TRS-80 COM driver as closely as possible. Interrupts are not supported but since eZ80 at 50 MHz is equivalent to 200 MHz Z80, most common communication speeds are supported without overrun.
Sound: Sound is simulated using bleeps and bloops of terminal's bell function. This will alert to original TRSDOS sound functions.