mirror of
https://github.com/wwarthen/RomWBW.git
synced 2026-02-06 14:11:48 -06:00
Wayne Warthen
GitHub
@@ -104,7 +104,7 @@ The `ASSIGN` command supports "stacking" of instructions. For example,
|
||||
two slices of IDE 0 and will unassign E:.
|
||||
|
||||
When the command runs it will echo the resultant assignments to the
|
||||
console to confirm it's actions. It will also display the remaining
|
||||
console to confirm its actions. It will also display the remaining
|
||||
space available in disk buffers.
|
||||
|
||||
## Notes
|
||||
@@ -158,7 +158,7 @@ should only be specified for hard disk devices (SD, IDE, PPIDE).
|
||||
Only one drive letter may be assigned to a specific device/unit/slice
|
||||
at a time. Attempts to assign a duplicate drive letter will fail and
|
||||
display an error. If you wish to assign a different drive letter to a
|
||||
device/unit/slice, unassign the the existing drive letter first.
|
||||
device/unit/slice, unassign the existing drive letter first.
|
||||
|
||||
Be aware that this command will allow you to reassign or remove the
|
||||
assignment of your system drive letter. This can cause your operating
|
||||
@@ -235,8 +235,8 @@ confusing that ZPM3 is in the file called CPM3.SYS, but it is normal
|
||||
for ZPM3.
|
||||
|
||||
For the purposes of booting an operating system, each disk slice is
|
||||
considered it's own operating system. Each slice can be made bootable
|
||||
with it's own system tracks.
|
||||
considered its own operating system. Each slice can be made bootable
|
||||
with its own system tracks.
|
||||
|
||||
`SYSCOPY` uses drive letters to specify where to read/write the system
|
||||
boot images. However, at startup, the boot loaded will require you to
|
||||
@@ -246,7 +246,7 @@ to a drive letter so you will know what to enter at the boot loader
|
||||
prompt. By way of explanation, the boot loader does not know about
|
||||
drive letters because the operating system is not loaded yet.
|
||||
|
||||
If you want to put a a boot system image on a device and slice that is
|
||||
If you want to put a boot system image on a device and slice that is
|
||||
not currently assigned to a drive letter, you will need to assign a
|
||||
drive letter first.
|
||||
|
||||
@@ -466,7 +466,7 @@ control is fully functional (end to end).
|
||||
The `XM` application provided in RomWBW is an adaptation of a
|
||||
pre-existing XModem application. Based on the source code comments, it
|
||||
was originally adapted from Ward Christensen's MODEM2 by Keith
|
||||
Petersen and is labeled version 12.5.
|
||||
Petersen and is labelled version 12.5.
|
||||
|
||||
The original source of the application was found in the Walnut Creek
|
||||
CD-ROM and is called XMDM125.ARK dated 7/15/86.
|
||||
@@ -661,7 +661,7 @@ After startup, the application provides the following options:
|
||||
| `R)aw` | will read the minute/second of the RTC clock iteratively every time the space key is pressed. Press enter to end. |
|
||||
| `L)oop` | will read the full date/time of the RTC clock iteratively every time the space key is pressed. Press enter to end. |
|
||||
| `C)harge` | will enable the battery charging function of the RTC. |
|
||||
| `N)ocharge` | will disable the battery charging functino of the RTC. |
|
||||
| `N)ocharge` | will disable the battery charging function of the RTC. |
|
||||
| `D)elay` | allows you to test the built-in timing delay in the program. It is not unusual for it to be wrong. |
|
||||
| `I)nit` | allows you to enter a date/time value for subsequent programming of the RTC using the S)et option. |
|
||||
| `G)et` | allows you to read the value of a non-volatile register in the RTC. |
|
||||
@@ -683,7 +683,7 @@ bypassing HBIOS.
|
||||
|
||||
## Etymology
|
||||
|
||||
The `RTC` application was originally written by Andrew Lync as part of
|
||||
The `RTC` application was originally written by Andrew Lynch as part of
|
||||
the original ECB SBC board development. It has since been modified to
|
||||
support most of the hardware variations included with RomWBW.
|
||||
|
||||
@@ -922,7 +922,7 @@ for the hardware found. If no hardware is detected, it will abort with
|
||||
an error message.
|
||||
|
||||
On Z180 systems, I/O wait states are added when writing to the sound
|
||||
chip to avoid exceeding it's speed limitations. On Z80 systems, you
|
||||
chip to avoid exceeding its speed limitations. On Z80 systems, you
|
||||
will need to ensure that the CPU clock speed of your system does not
|
||||
exceed the timing limitations of your sound chip.
|
||||
|
||||
@@ -939,7 +939,7 @@ By default the application will attempt to interface directly to the sound
|
||||
chip. The optional argument `--hbios` supplied after the filename, will
|
||||
enable the application to use the HBIOS sound driver.
|
||||
|
||||
The HBIOS mode also support other switch as desribed below.
|
||||
The HBIOS mode also support other switch as described below.
|
||||
|
||||
| Switch | Description |
|
||||
| ----------- | ------------------------------------------------------ |
|
||||
@@ -1012,9 +1012,9 @@ speed will actually work on the current hardware. Setting a CPU
|
||||
speed that exceeds the capabilities of the system will result in
|
||||
unstable operation or a system stall.
|
||||
|
||||
Some peripherals are dependant on the CPU speed. For example, the Z180
|
||||
Some peripherals are dependent on the CPU speed. For example, the Z180
|
||||
ASCI baud rate and system timer are derived from the CPU speed. The
|
||||
CPUSPD applicastion will attempt to adjust these peripherals for
|
||||
CPUSPD application will attempt to adjust these peripherals for
|
||||
correct operation after modifying the CPU speed. However, in some
|
||||
cases this may not be possible. The baud rate of ASCI ports have a
|
||||
limited set of divisors. If there is no satisfactory divisor to
|
||||
|
||||
@@ -246,7 +246,7 @@ memory starting at location xxxx.
|
||||
protocol.
|
||||
|
||||
If the monitor is assembled with the DSKY functionality,
|
||||
this feature will be exclude due to space limitions.
|
||||
this feature will be exclude due to space limitations.
|
||||
|
||||
|
||||
## NOTES:
|
||||
@@ -624,7 +624,7 @@ Feedback to the ROMWBW developers on these guidelines would be appreciated.
|
||||
|
||||
## Notes:
|
||||
All testing was done with Teraterm x-modem, Forcing checksum mode using macros was found to give the most reliable transfer.
|
||||
Partial writes can be completed with 39SF040 chips. Other chips require entire flash to be erased before before being written.
|
||||
Partial writes can be completed with 39SF040 chips. Other chips require entire flash to be erased before being written.
|
||||
An SBC V2-005 MegaFlash or Z80 MBC required for 1mb flash support. The Updater assumes both chips are same type
|
||||
Failure handling has not been tested.
|
||||
Timing broadly calibrated on a Z80 SBC-v2
|
||||
|
||||
@@ -190,7 +190,7 @@ Portions of RomWBW were created by, contributed by, or derived from
|
||||
the work of others. It is believed that these works are being used
|
||||
in accordance with the intentions and/or licensing of their creators.
|
||||
|
||||
If anyone feels their work is being used outside of it's intended
|
||||
If anyone feels their work is being used outside of its intended
|
||||
licensing, please notify:
|
||||
|
||||
> $doc_author$ \
|
||||
@@ -198,7 +198,7 @@ licensing, please notify:
|
||||
|
||||
RomWBW is an aggregate work. It is composed of many individual,
|
||||
standalone programs that are distributed as a whole to function as
|
||||
a cohesive system. Each program may have it's own licensing which
|
||||
a cohesive system. Each program may have its own licensing which
|
||||
may be different from other programs within the aggregate.
|
||||
|
||||
In some cases, a single program (e.g., CP/M Operating System) is
|
||||
|
||||
@@ -182,7 +182,7 @@ not know anything about what is being loaded (the image is usually an
|
||||
operating system, but could be any executable code image). Once the Boot
|
||||
Loader has loaded the image at the selected location, it will transfer
|
||||
control to it. Assuming the typical situation where the image was an
|
||||
operating system, the loaded operating system will then perform it's own
|
||||
operating system, the loaded operating system will then perform its own
|
||||
initialization and begin normal operation.
|
||||
|
||||
## Application Boot
|
||||
@@ -207,8 +207,8 @@ the previously running operating system starting at $0100. Note that the
|
||||
program image contains a full copy of the HBIOS to be installed and run. Once
|
||||
the Application Boot program is loaded by the previous operating system,
|
||||
control is passed to it and it performs a system initialization similar
|
||||
to the ROM Boot, but using the image loaded in RAM. Once te new
|
||||
HBIOS completes it's initialization, it will launch the Boot Loader
|
||||
to the ROM Boot, but using the image loaded in RAM. Once the new
|
||||
HBIOS completes its initialization, it will launch the Boot Loader
|
||||
just like a ROM boot.
|
||||
|
||||
The Application Boot program actually contains two other components
|
||||
@@ -228,7 +228,7 @@ they have a small hardware bootstrap that loads a chunk of code from a
|
||||
disk device directly into RAM at system startup.
|
||||
|
||||
The startup then proceeds very much like the Application Boot
|
||||
process described above. HBIOS is installed in it's operating bank
|
||||
process described above. HBIOS is installed in its operating bank
|
||||
and control is passed to the Boot Loader.
|
||||
|
||||
# Driver Model
|
||||
@@ -245,7 +245,7 @@ layout expected by the operating system and application.
|
||||
Drivers do need to be aware of the bank switching if a buffer address
|
||||
is being used in the function call.
|
||||
|
||||
* If the buffer address is in the lower 32K of RAM, then the memroy
|
||||
* If the buffer address is in the lower 32K of RAM, then the memory
|
||||
it points to will be from the User Bank, not the HBIOS bank which
|
||||
is now active. In this case, the driver must use an inter-bank
|
||||
copy to access the data.
|
||||
@@ -363,7 +363,7 @@ HBIOS functions. Most function calls will return a result in register A.
|
||||
| -1 | undefined error |
|
||||
| -2 | function not implemented |
|
||||
| -3 | invalid function |
|
||||
| -4 | invalid unit numberr |
|
||||
| -4 | invalid unit number |
|
||||
| -5 | out of memory |
|
||||
| -6 | parameter out of range |
|
||||
| -7 | media not present |
|
||||
@@ -617,7 +617,7 @@ Returns the driver specific Status (A) of the specified disk device unit
|
||||
The return value in register A is used as both a device status and a
|
||||
standard HBIOS result code. Negative values (bit 7 set) indicate a
|
||||
standard HBIOS result (error) code. Otherwise, the return value
|
||||
represents a driver-specific device status. In call cases, the value 0
|
||||
represents a driver-specific device status. In all cases, the value 0
|
||||
means OK.
|
||||
|
||||
### Function 0x11 -- Disk Reset (DIORESET)
|
||||
@@ -1619,7 +1619,7 @@ Status (A) is a standard HBIOS result code.
|
||||
| E: 0x04 | HL: Ports |
|
||||
| | DE: Ports |
|
||||
|
||||
This subfunction reports detailed device informatoin for the specified
|
||||
This subfunction reports detailed device information for the specified
|
||||
Sound Unit (C).
|
||||
|
||||
Driver Identity (B) reports the audio device type. Ports (HL & DE)
|
||||
@@ -1652,7 +1652,7 @@ the duration, the actual duration is applied in the SNDPLAY function.
|
||||
If the Duration (HL) is set to zero, then the SNDPLAY function will
|
||||
operate in a non-blocking mode. i.e. a tone will start playing and the
|
||||
play function will return. The tone will continue to play until the next
|
||||
tone is played. If the Duration (HL) is greater than zero, the the
|
||||
tone is played. If the Duration (HL) is greater than zero, the
|
||||
sound will play for the duration defined in HL and then return.
|
||||
|
||||
**\*\*\* Function Not Implemented \*\*\**
|
||||
@@ -2024,7 +2024,7 @@ lookup.
|
||||
|
||||
Return the value of the global system timer Tick Count (DEHL). This is
|
||||
a double-word binary value. The frequency of the system timer in Hertz
|
||||
is returned in Frequncy (C). The returned Status (A) is a standard HBIOS
|
||||
is returned in Frequency (C). The returned Status (A) is a standard HBIOS
|
||||
result code.
|
||||
|
||||
Note that not all hardware configuration have a system timer. You
|
||||
@@ -2197,7 +2197,7 @@ Wait States (E) will be set if possible. The value of Memory Wait
|
||||
States (D) is the actual number of wait states, not the number of wait
|
||||
states added.
|
||||
|
||||
Some peripherals are dependant on the CPU speed. For example, the Z180
|
||||
Some peripherals are dependent on the CPU speed. For example, the Z180
|
||||
ASCI baud rate and system timer are derived from the CPU speed. The
|
||||
Set CPU Speed function will attempt to adjust these peripherals for
|
||||
correct operation after modifying the CPU speed. However, in some
|
||||
@@ -2389,7 +2389,7 @@ are not reported to the console.
|
||||
|
||||
If the diagnosis level is set to display the diagnosis information, then
|
||||
memory address, register dump and error code is displayed.
|
||||
A key differance with the PANIC error is that execution may be continued.
|
||||
A key difference with the PANIC error is that execution may be continued.
|
||||
|
||||
Example error message:
|
||||
|
||||
|
||||
@@ -133,7 +133,7 @@ contributions are very welcome.
|
||||
#### Distribution Directory Layout
|
||||
|
||||
The RomWBW distribution is a compressed zip archive file organized in
|
||||
a set of directories. Each of these directories has it's own
|
||||
a set of directories. Each of these directories has its own
|
||||
ReadMe.txt file describing the contents in detail. In summary, these
|
||||
directories are:
|
||||
|
||||
@@ -529,7 +529,7 @@ ROM Applications:
|
||||
|
||||
To start a ROM application you just enter the corresponding letter at
|
||||
the Boot Loader prompt. In the following example, we launch the
|
||||
built-in Micrsosoft BASIC interpreter. From within BASIC, we use the
|
||||
built-in Microsoft BASIC interpreter. From within BASIC, we use the
|
||||
`BYE` command to return to the Boot Loader:
|
||||
|
||||
```
|
||||
@@ -620,7 +620,7 @@ Boot [H=Help]: 4
|
||||
|
||||
Booting Disk Unit 4, Slice 0, Sector 0x00000800...
|
||||
|
||||
Volume "Unlabeled" [0xD000-0xFE00, entry @ 0xE600]...
|
||||
Volume "Unlabelled" [0xD000-0xFE00, entry @ 0xE600]...
|
||||
|
||||
CBIOS v3.1.1-pre.194 [WBW]
|
||||
|
||||
@@ -660,7 +660,7 @@ Boot [H=Help]: 4.3
|
||||
|
||||
Booting Disk Unit 4, Slice 3, Sector 0x0000C800...
|
||||
|
||||
Volume "Unlabeled" [0x0100-0x1000, entry @ 0x0100]...
|
||||
Volume "Unlabelled" [0x0100-0x1000, entry @ 0x0100]...
|
||||
|
||||
CP/M V3.0 Loader
|
||||
Copyright (C) 1998, Caldera Inc.
|
||||
@@ -720,7 +720,7 @@ The 'R' command within the Boot Loader performs a software reset of
|
||||
the system. It is the software equivalent of pressing the reset
|
||||
button.
|
||||
|
||||
There is generallhy no need to do this, but it can be convenient when
|
||||
There is generally no need to do this, but it can be convenient when
|
||||
you want to see the boot messages again or ensure your system is in
|
||||
a clean state.
|
||||
|
||||
@@ -735,7 +735,7 @@ Restarting System...
|
||||
Your system can support a number of devices for the console. They may
|
||||
be VDU type devices or serial devices. If you want to change which
|
||||
device is the console, the ***I*** menu option can be used to choose
|
||||
the unit and it's speed.
|
||||
the unit and its speed.
|
||||
|
||||
The command format is ```I <unit> [<baudrate>]```
|
||||
|
||||
@@ -823,11 +823,11 @@ The messages you see will vary depending on your hardware and the
|
||||
media you have installed. But, they will all have the same general
|
||||
format as the example above.
|
||||
|
||||
Once your your system has working disk devices, they will be accessible
|
||||
Once your system has working disk devices, they will be accessible
|
||||
from any operating system you choose to run. Disk storage is available
|
||||
whether you boot your OS from ROM or from the disk media itself.
|
||||
|
||||
Refering back to the Boot Loader section on "Launching from ROM", you
|
||||
Referring back to the Boot Loader section on "Launching from ROM", you
|
||||
could start CP/M 2.2 using the 'C' command. As the operating system
|
||||
starts up, you should see a list of drive letters assigned to the disk
|
||||
media you have installed. Here is an example of this:
|
||||
@@ -1071,7 +1071,7 @@ PROGRESS: TRACK=4F HEAD=01 SECTOR=01
|
||||
```
|
||||
|
||||
Since the physical format of floppy media is the same as that used
|
||||
in a standard MS-DOS/Windows computer, you can also physicall format
|
||||
in a standard MS-DOS/Windows computer, you can also physical format
|
||||
floppy media in a modern computer. However, the directory format
|
||||
itself will not be compatible with CP/M OSes. In this case, you
|
||||
can use the `CLRDIR` application supplied with RomWBW to reformat
|
||||
@@ -1091,7 +1091,7 @@ after inserting a new floppy disk.
|
||||
|
||||
Under RomWBW, a hard disk is similar to a floppy disk in that it is
|
||||
considered a disk unit. However, RomWBW has multiple features that
|
||||
allow it's legacy operating systems to take advantage of modern
|
||||
allow its legacy operating systems to take advantage of modern
|
||||
mass storage media.
|
||||
|
||||
To start with, the concept of a hard disk in RomWBW applies to any
|
||||
@@ -1340,7 +1340,7 @@ B>stat e:dsk:
|
||||
```
|
||||
|
||||
It is critical that you include "dsk:" after the drive letter in the
|
||||
`STAT` command line. The important line to look at is labeled "32 Byte
|
||||
`STAT` command line. The important line to look at is labelled "32 Byte
|
||||
Directory Entries". In this case, the value is 1024 which implies that
|
||||
this drive is located on a modern (hd1k) disk layout. If the value
|
||||
was 512, it would indicate a legacy (hd512) disk layout.
|
||||
@@ -1543,7 +1543,7 @@ image that you write to your hard disk media. You can use additional
|
||||
slices as long your media has room for them. However, writing the disk
|
||||
image will not initialize the additional slices. If these additional
|
||||
slices were previously initialized, they will not be corrupted when you
|
||||
write the new image and will still contain their prvious contents. If
|
||||
write the new image and will still contain their previous contents. If
|
||||
the additional slices were not previously initialized, you can use
|
||||
`CLRDIR` to do so and optionally `SYSCOPY` if you want them to be
|
||||
bootable.
|
||||
@@ -1774,7 +1774,7 @@ less likely to encounter compatibility issues.
|
||||
|
||||
#### Boot Disk
|
||||
|
||||
To make make a bootable CP/M disk, use the RomWBW `SYSCOPY` tool
|
||||
To make a bootable CP/M disk, use the RomWBW `SYSCOPY` tool
|
||||
to place a copy of the operating system on the boot track of
|
||||
the disk. The RomWBW ROM disk has a copy of the boot track
|
||||
call "CPM.SYS". For example:
|
||||
@@ -1790,7 +1790,7 @@ call "CPM.SYS". For example:
|
||||
|
||||
* `SUBMIT.COM` has been patched per DRI to always place submit
|
||||
files on A:. This ensures the submitted file will always be
|
||||
properlly executed.
|
||||
properly executed.
|
||||
|
||||
* The original versions of DDT, DDTZ, and ZSID used the RST 38
|
||||
vector which conflicts with interrupt mode 1 use of this vector.
|
||||
@@ -1822,7 +1822,7 @@ via the NZ-COM adaptation (see below).
|
||||
|
||||
#### Boot Disk
|
||||
|
||||
To make make a bootable Z-System disk, use the RomWBW `SYSCOPY` tool
|
||||
To make a bootable Z-System disk, use the RomWBW `SYSCOPY` tool
|
||||
to place a copy of the operating system on the boot track of
|
||||
the disk. The RomWBW ROM disk has a copy of the boot track
|
||||
call "ZSYS.SYS". For example:
|
||||
@@ -1900,7 +1900,7 @@ configured in the most basic way possible. You should refer to the
|
||||
documentation and use `MKZCM` as desired to customize your system.
|
||||
|
||||
NZCOM has substantially more functionality than CP/M or basic
|
||||
Z-System. It is important to read the the "NZCOM Users
|
||||
Z-System. It is important to read the "NZCOM Users
|
||||
Manual.pdf" document in order to use this operating system effectively.
|
||||
|
||||
#### Documentation
|
||||
@@ -2122,7 +2122,7 @@ some other distributions, this implements a native p-System
|
||||
Z80 Extended BIOS, it does not rely on a CP/M BIOS layer.
|
||||
|
||||
The p-System is provided on a hard disk image file called
|
||||
psys.img. This must be copied to it's own dedicated hard
|
||||
psys.img. This must be copied to its own dedicated hard
|
||||
disk media (CF Card, SD Card, etc.). It is booted by
|
||||
selecting slice 0 of the corresponding hard disk unit at
|
||||
the RomWBW Boot Loader prompt. Do not attempt to use
|
||||
@@ -2276,7 +2276,7 @@ default FAT partition.
|
||||
You can confirm the existence of the FAT partition with `FDISK80` by
|
||||
using the 'P' command to show the current partition table. Here is an
|
||||
example of a partition table listing from `FDISK80` that includes the
|
||||
FAT partition (labeled "FAT16"):
|
||||
FAT partition (labelled "FAT16"):
|
||||
|
||||
```
|
||||
Capacity of disk 4: ( 4G) 7813120 Geom 77381010
|
||||
@@ -2290,7 +2290,7 @@ Nr ---Type- A -- Start End LBA start LBA count Size
|
||||
If your hard disk media does not have a FAT partition already defined,
|
||||
you will need to define one using FDISK80 by using the 'N' command.
|
||||
Ensure that the location and size of the FAT partition does not
|
||||
overlap any of the CP/M slice area and that it fits within the szie
|
||||
overlap any of the CP/M slice area and that it fits within the size
|
||||
of your media.
|
||||
|
||||
Once the partition is defined, you will still need to format it. Just
|
||||
@@ -2315,7 +2315,7 @@ If your RomWBW system has multiple disk drives/slots, you can also just
|
||||
create a disk with your modern computer that is a dedicated FAT
|
||||
filesystem disk. You can use your modern computer to format the disk
|
||||
(floppy, CF Card, SD Card, etc.), then insert the disk in your RomWBW
|
||||
computer and access if using `FAT` based on it's RomWBW unit number.
|
||||
computer and access if using `FAT` based on its RomWBW unit number.
|
||||
|
||||
## FAT Application Usage
|
||||
|
||||
@@ -2403,7 +2403,7 @@ Copying...
|
||||
SAMPLE.TXT ==> 4:/SAMPLE.TXT Overwrite? (Y/N) ... [OK]
|
||||
SAMPLE2.TXT ==> 4:/SAMPLE2.TXT ... [OK]
|
||||
|
||||
2 File(s) Copiedd
|
||||
2 File(s) Copied
|
||||
```
|
||||
|
||||
# CP/NET Networking
|
||||
@@ -2848,7 +2848,7 @@ boot. To customize this file, you use the ZCPR ALIAS facility. You
|
||||
will need to refer to ZCPR documentation for more information on the
|
||||
ALIAS facility.
|
||||
|
||||
p-System has it's own startup command processing mechanism that is
|
||||
p-System has its own startup command processing mechanism that is
|
||||
covered in the p-System documentation.
|
||||
|
||||
## ROM Customization
|
||||
@@ -2884,7 +2884,7 @@ built into the ROM.
|
||||
# UNA Hardware BIOS
|
||||
|
||||
John Coffman has produced a new generation of hardware BIOS called
|
||||
UNA. The standard RomWBW distribution includes it's own hardware
|
||||
UNA. The standard RomWBW distribution includes its own hardware
|
||||
BIOS. However, RomWBW can alternatively be constructed with UNA as
|
||||
the hardware BIOS portion of the ROM. If you wish to use the UNA
|
||||
variant of RomWBW, then just program your ROM with the ROM image
|
||||
@@ -2984,7 +2984,7 @@ occurred.
|
||||
|
||||
Similar to using the Flash utility, the system ROM can be updated
|
||||
or upgraded through the ROM based updater utility. This works by
|
||||
by reprogrammed the flash ROM as the file is being transfered.
|
||||
by reprogrammed the flash ROM as the file is being transferred.
|
||||
|
||||
This has the advantage that secondary storage is not required to
|
||||
hold the new image.
|
||||
@@ -3158,7 +3158,7 @@ Portions of RomWBW were created by, contributed by, or derived from
|
||||
the work of others. It is believed that these works are being used
|
||||
in accordance with the intentions and/or licensing of their creators.
|
||||
|
||||
If anyone feels their work is being used outside of it's intended
|
||||
If anyone feels their work is being used outside of its intended
|
||||
licensing, please notify:
|
||||
|
||||
> $doc_author$ \
|
||||
@@ -3166,7 +3166,7 @@ licensing, please notify:
|
||||
|
||||
RomWBW is an aggregate work. It is composed of many individual,
|
||||
standalone programs that are distributed as a whole to function as
|
||||
a cohesive system. Each program may have it's own licensing which
|
||||
a cohesive system. Each program may have its own licensing which
|
||||
may be different from other programs within the aggregate.
|
||||
|
||||
In some cases, a single program (e.g., CP/M Operating System) is
|
||||
|
||||
Reference in New Issue
Block a user