danielbooneamerica
Experienced Member
we have been pretty good trying to document this project as it goes. That being said I want to post first couple pages of project objectives. Note some of these objectives are new and others were already part of TRSDOS history.
I also want to thank ldkraemer for rescuing some 30-40 year old files making this project faster. He has expert knowledge in drives and recovered some files that speed this project up.
Please do not take these first couple of pages as gospel. This document is growing and under edit but I wanted to give an idea what I am working on. There is plenty of editing mistakes to be corrected so thanks for being patience.
I have added a login process to TRS-OS to authenticate users before they are allowed to access system resources.
------------->
TRS-OS design objectives
Design for cooperative multiprogramming.
Provide real-time preemptive multitasking for small tasks.
Focuses on portability, connectivity & security.
Supporting Zilog Z80 family of processors including Z80, Z180 & eZ80.
Supports 256 X 32k bank memory (8000h - FFFFh).
Higher level languages for both applications and OS development.
Goal of recoding needed libraries & utilities in C.
TRS-OS easily interfaces to widely varied storage devices while maintaining media compatibility across all storage devices. TRS-OS supports multiple types of hardware for storage. Example, volumes may reside in RAM, FLASH, IDE based hard drives, SCSI drives or storage located on another computer. Storage is divided by slicing.
Slices are divisions of mass storage or large blocks of RAM/FLASH & defined by tables. Normally TRS-OS accesses volumes residing in slices of mass storage.
Files reside in volumes. Volumes are referenced as a number between zero and seven (0-7) and interfaces with TRS-OS using VCT$ (volume code tables).
Files residing in volumes may be made to appear as a volume by mounting & dismounting software.
Filenames are up to eight characters & have up to three character extension. Mechanism to make files appear as a volume's is transparent to users.
Volumes internal storage is divided into blocks. Blocks are further fractioned into fractions. Fractions supported are lengths of 256, 512 or 1024 bytes and is where actual file/directory content resides.
*BB (bit bucket) is a null device and contains an unlimited amount of space to copy what ever you want.
As example, *BB is convient for testing. Its always ready, always returns sucessful reads and always has sucessful writes. There is no limit to *BB storage.
Drivers for storage devices;
*FD flash memory disk driver.
*RD RAM disk driver.
*CF storage card driver.
*ND Network drive driver.
*HD Physical hard drive driver.
*BB bit bucket driver (some similaraties to storage).
*CL Driver for serial port 0.
*C1 Driver for serial port 1.
Volume 0 is software and hardware write protected. Hardware write protection is under control of a keyswich located on front panel. No changes to OS can be made while WP is in its normal position of WP PROTECTION ON.
Users/operators with physical posession of key for protection switch, can enable writing to volume 0. Updates, changes, patches or customization of OS code on volume 0 can only take place when keyswitch is active.
Volumes 1 - 6 are normally configured for read/write but can be defined for each user as software WP or not. But each user must have at least one read write volume mounted.
These volumes may be shared, private or both with other users or applications. Normally these drives contain data for applications used by this user or shared by other users or applications.
Volume 7 is defined specifically for each user. This volume runs with write protection OFF and contains read/write data for this user.
Configuration for volume 1-6 is defined via tables.
Perhaps one user has volumes 1-6 containing logs of battery charge from solar panels. Another user login loads volumes on login that has to do with billing for solar power generated and sent over lines.
Various permissions detail what a user can or cannot do while logged in.
For example, ALLOW COMMAND(s)? Y/N: flag defines if the user is allowed to type commands into DOS or only use menu items.
User defined menus. This defines which menu if any, user is displayed and files for sub menus. These may be customized for each individual user or shared menus among groups or all users.
Define user access and privileges to devices / files.
Each user can execute multiple tasks in background. Multiple applications or tasks can be kept in background and brought to foreground on demand by user.
Extensive job control language.
Robust utility package. Utility package comes preinstalled on flash drive (*FD). Goal to recode needed libraries & utilities in C.
English like command structures coupled with error trapping, using English style error messages.
I also want to thank ldkraemer for rescuing some 30-40 year old files making this project faster. He has expert knowledge in drives and recovered some files that speed this project up.
Please do not take these first couple of pages as gospel. This document is growing and under edit but I wanted to give an idea what I am working on. There is plenty of editing mistakes to be corrected so thanks for being patience.
I have added a login process to TRS-OS to authenticate users before they are allowed to access system resources.
------------->
TRS-OS design objectives
Design for cooperative multiprogramming.
Provide real-time preemptive multitasking for small tasks.
Focuses on portability, connectivity & security.
Supporting Zilog Z80 family of processors including Z80, Z180 & eZ80.
Supports 256 X 32k bank memory (8000h - FFFFh).
Higher level languages for both applications and OS development.
Goal of recoding needed libraries & utilities in C.
TRS-OS easily interfaces to widely varied storage devices while maintaining media compatibility across all storage devices. TRS-OS supports multiple types of hardware for storage. Example, volumes may reside in RAM, FLASH, IDE based hard drives, SCSI drives or storage located on another computer. Storage is divided by slicing.
Slices are divisions of mass storage or large blocks of RAM/FLASH & defined by tables. Normally TRS-OS accesses volumes residing in slices of mass storage.
Files reside in volumes. Volumes are referenced as a number between zero and seven (0-7) and interfaces with TRS-OS using VCT$ (volume code tables).
Files residing in volumes may be made to appear as a volume by mounting & dismounting software.
Filenames are up to eight characters & have up to three character extension. Mechanism to make files appear as a volume's is transparent to users.
Volumes internal storage is divided into blocks. Blocks are further fractioned into fractions. Fractions supported are lengths of 256, 512 or 1024 bytes and is where actual file/directory content resides.
*BB (bit bucket) is a null device and contains an unlimited amount of space to copy what ever you want.
As example, *BB is convient for testing. Its always ready, always returns sucessful reads and always has sucessful writes. There is no limit to *BB storage.
Drivers for storage devices;
*FD flash memory disk driver.
*RD RAM disk driver.
*CF storage card driver.
*ND Network drive driver.
*HD Physical hard drive driver.
*BB bit bucket driver (some similaraties to storage).
*CL Driver for serial port 0.
*C1 Driver for serial port 1.
Volume 0 is software and hardware write protected. Hardware write protection is under control of a keyswich located on front panel. No changes to OS can be made while WP is in its normal position of WP PROTECTION ON.
Users/operators with physical posession of key for protection switch, can enable writing to volume 0. Updates, changes, patches or customization of OS code on volume 0 can only take place when keyswitch is active.
Volumes 1 - 6 are normally configured for read/write but can be defined for each user as software WP or not. But each user must have at least one read write volume mounted.
These volumes may be shared, private or both with other users or applications. Normally these drives contain data for applications used by this user or shared by other users or applications.
Volume 7 is defined specifically for each user. This volume runs with write protection OFF and contains read/write data for this user.
Configuration for volume 1-6 is defined via tables.
Perhaps one user has volumes 1-6 containing logs of battery charge from solar panels. Another user login loads volumes on login that has to do with billing for solar power generated and sent over lines.
Various permissions detail what a user can or cannot do while logged in.
For example, ALLOW COMMAND(s)? Y/N: flag defines if the user is allowed to type commands into DOS or only use menu items.
User defined menus. This defines which menu if any, user is displayed and files for sub menus. These may be customized for each individual user or shared menus among groups or all users.
Define user access and privileges to devices / files.
Each user can execute multiple tasks in background. Multiple applications or tasks can be kept in background and brought to foreground on demand by user.
Extensive job control language.
Robust utility package. Utility package comes preinstalled on flash drive (*FD). Goal to recode needed libraries & utilities in C.
English like command structures coupled with error trapping, using English style error messages.