ICL DRS

The ICL DRS was a range of departmental computers from International Computers Limited (ICL). Standing originally for "Distributed Resource System", the full name was later dropped in favour of the abbreviation.
During the mid-1980s separate Office Systems business units had produced a disparate range of products including IBM-compatible PCs such as the PWS (a PC/AT clone), small servers branded DRS, and various larger Unix servers sold under the Clan range. A rebranding in late 1988 pulled these together under the DRS brand, with a consistent mid-grey and peppermint-green livery.
The ICL division responsible for these systems eventually became part of the Fujitsu-Siemens joint venture.
DRS 20/100/200.
The original DRS was the DRS 20 produced in Utica, New York and launched in September 1981. This ran the proprietary DRX (Distributed Resource Executive) operating system. The basic 'intelligent terminal' (model 10/110/210) used 8-bit 8085 processors (workstation, application and network processors), each with between 32 KB and 128 KB of memory. The Model 210 also had an 80188 application processor with 512 KB to run CP/M. The larger models 20 and 40 had floppy disk drives. The floor-standing models 50, 150, and 250 had hard disks, from which diskless models booted. In early models, these were 8" floppy disks, and later 5¼" disks.
The diskless model, that partnered the DRS 20, was the DRS 10. It had 10 KB available for applications programs developed in CIS COBOL.
Up to 16 DRS 20/DRS 10 machines could be connected via LAN with the addresses being set by DIP switches on the rear of the unit. The LAN was formed via 93 Ohm coaxial cable in a bus formation running at 1.25 Mbps.
The final model 310 (styled like a DRS 300 module) had a second 80186 application processor with 1 MB RAM to run Concurrent DOS, emulating an IBM PC with a Hercules screen display.
DRS 300.
In the mid-1980s ICL developed the DRS 300 in Kidsgrove, and ran down Utica. Launched in 1986, DRS 300 was a modular system consisting of A4-sized units designed to be placed on an office bookshelf. Modules containing a power supply (Kx), processor (Ax), hard and floppy disks (Dx), streamer tape (Sx) etc. were connected by SCSI. Initial models used a 6 MHz 80286 processor (A1 module) with up to 1 MB memory. Later modules used an 8 MHz processor (A2) or 80286 with 80287 maths coprocessor (A3) with up to 4 MB, and ran Concurrent CP/M-86 and later Concurrent DOS. Although this could run code developed under CP/M, PC DOS or MS-DOS, in practice available applications were limited because many shrink-wrapped packages developed for the IBM PC made use of direct access to the (IBM) hardware. This was addressed through use of softclone technology to intercept such calls. However, this required the continual release of patches for new application versions.
The initial DRS 300 also ran ICL's implementation of Unix System V Release 2, DRS/NX V2, though that was never released commercially. Later an 80386 (A4) module was added, to run a 32-bit DRS/NX V3, based on System V Release 3.
DRS 400, DRS 500.
These brand names were applied to bought-in Unix boxes. The DRS 400 originated as the Clan 4, based on the Motorola 68020 running UniSoft's Uniplus Unix. This was later replaced by the DRS 400E, based on the Motorola 68030 running DRS/NX V3.
DRS 500 originated as the Clan 5, 6 and 7 based on the CCI Power 6/32. This was built in Irvine by CCI, which had been taken over by ICL's parent STC PLC. CCI was also the source of what became ICL's flagship OfficePower office application suite across the DRS range.
DRS 3000.
The successor to DRS 300, the DRS 3000 was an IBM-compatible, 80486-based, floor-standing model running SVR4. The P5 Pentium-based Level 656 was launched in September 1993.
DRS 6000.
The in-house (Irvine/Bracknell) developed DRS 6000 was launched in January 1990 as a washing machine-sized SPARC-based server, running ICL's implementation of Unix System V Release 4 (SVR4). It also had a 68020-based Central Service Module board (CSM), leading to sarcastic comments in the press that it was a DRS 400 in disguise. By 1992 there were desktop, slimline and full sized models, ranging from a single-processor desktop model rated at 29 MIPS (L240) to a 4-processor model rated at 116 MIPS (L644). Some models were sold by Fujitsu as the DS/90. ICL received the Queen's Award for Export Achievement for DRS 6000 in 1993.
The DRS 6000 competed directly with IBM's RS/6000, which was launched a few weeks later; originally planned to be called the DRS 600 it was renamed when it was found that IBM had decided on the RS 6000.
In 1994, the DRS range was superseded by the SuperServer (Ks (SPARC) and Ki (Intel)) and TeamServer (Es (1-2 SPARC CPUs), Hs (2-4 SPARC CPUs), Ei (1 x86 CPU), Hi (2 x86 CPUs)) ranges of SPARC and Intel-based machines, running DRS/NX Unix or Microsoft Windows NT.
DRS PWS.
In 1987, the DRS Professional Work Station (PWS) was ICL's first foray into IBM PC/AT compatible computing. The DRS PWS was initially released with MS-DOS 4.0 (not to be confused with the later public releases of IBM DOS 4.0 in July 1988 and MS-DOS 4.01 in November 1988). This was a real-mode pre-emptive multitasking version of MS-DOS 2.0 and was also the forerunner of OS/2. It was soon replaced with MS-DOS 4.1 when this became available; this was written especially for the DRS PWS, but was not finished for the launch. Microsoft agreed to write a custom version of MS-DOS 4.0 for ICL that would take advantage of the extra memory on the ICL computers. As a consequence, PWS users had a number of software compatibility challenges, although the PC Business Unit (PCBU) at ICL BRA04, in Bracknell, did patch some applications for larger customers.
The PWS was positioned to compete with the IBM Personal System/2 (PS/2) and the DEC Vaxstation 2000. In 1988, the DRS PWS and DRS PWS 386 were respectively rebranded as the DRS Model 60 and DRS Model 80.
The PWS hardware was a large desktop or floor standing tower chassis, running on an Intel 8 MHz 80286 processor that was later superseded by an Intel 20 MHz 80386 (DRS PWS 386). Memory expansion was via proprietary cards (1 MB or 4 MB cards, 16 MB total) and initially there was no support for 1.44 MB High Density (HD) floppy drives, although a hardware modification to the clock lines on the floppy disk controller meant that later versions of the PWS could be upgraded. The ENGA (EGA compatible video) controller, displayed standard EGA graphics and text with an additional line reserved on the bottom row for multitasking and communications task messages.
The PWS was capable of communicating with ICL departmental and mainframe services using a combination of Microlan2 and OSLAN (Open Systems Local Area Network) protocols. Microsoft and OSLAN network connectivity was supported via BICC OSLAN cards (OSLAN being ICL's implementation of OSI transport protocols over Ethernet). TCP/IP and DECnet support was implemented by third parties using packet drivers, as NDIS was not available at this time.
Development software.
Languages on DRS 20 under DRX included Microsoft BASIC, Micro Focus CIS-COBOL, Pascal, 8085 Assembler,
and application building packages including Userbuild and the Demon suite.
Languages on DRS 300 Concurrent DOS included Lattice C, CBASIC, Micro Focus Level II COBOL and
Digital Research languages including FORTRAN and Pascal.
Development software on the Unix-based DRS ranges (300 to 6000) included C, Micro Focus and RM COBOL, EPC C++, FORTRAN and Pascal, and relational databases including Ingres, Informix, Oracle, Sybase and Progress 4GL supplied by Progress Software.
During this period, ICL's software strategy was increasingly to make available on its own hardware popular software packages developed by third parties. Almost invariably this involved porting the source code, as there was insufficient compatibility between machines at the binary level. In order to reduce the cost of this activity, and the commercial disadvantage of not having as large a software portfolio as rival vendors, ICL invested strenuous efforts to improve cross-industry compatibility through initiatives such as X/Open.


Microsoft Connected Services Framework

Microsoft Connected Services Framework (CSF) is a discontinued service-aggregation SOA platform from Microsoft. Developed on the .NET Framework, CSF enables scalable, loosely coupled service-based solutions. The codice_1 is the core component of the framework involved in routing messages between participants (participants may be .NET components or web services). Complex Routing can be accomplished by external .NET or BizTalk driver services. CSF is not a replacement for BizTalk; rather, it simplifies orchestrations by removing service specific operations and allowing focus on business/process logic.


DeskLite

The DeskLite was a thin client launched in 1998 by Acorn Computers. It was designed to provide access to Microsoft Windows applications via Citrix ICA. It has been described as probably being the last product made by Acorn.
The design is a specialised Network Computer and was promoted to potential licensees for adoption. It was launched at the 1998 Thinergy conference in Orlando.
Specifications.
The DeskLite uses Cirrus Logic's CL-PS7500FE (a variant of the ARM7500 with a floating-point coprocessor) and runs .


DNIX

DNIX (original spelling: D-Nix) is a discontinues Unix-like real-time operating system from the Swedish company Dataindustrier AB (DIAB). A version called ABCenix was also developed for the ABC 1600 computer from Luxor. (Daisy Systems also had something called Daisy DNIX on some of their CAD workstations. It was unrelated to DIAB's product.)
History.
Inception at DIAB in Sweden.
Dataindustrier AB (literal translation: computer industries shareholding company) was started in 1970 by Lars Karlsson as a single-board computer manufacture in Sundsvall, Sweden, producing a Zilog Z80-based computer called "Data Board 4680". In 1978 DIAB started to work with the Swedish television company Luxor AB to produce the home and office computer series ABC 80 and ABC 800.
In 1983 DIAB independently developed the first UNIX-compatible machine, DIAB DS90 based on the Motorola 68000 CPU. D-NIX here made its appearance, based on a UNIX System V license from AT&T. DIAB was however an industrial automation company, and needed a real-time operating system, so the company replaced the AT&T-supplied UNIX kernel with their own in-house developed, yet compatible real-time variant. This kernel was originally a Z80 kernel called "OS8".
Over time, the company also replaced several of the UNIX standard userspace tools with their own implementations, to the point where no code was derived from UNIX, and their machines could be deployed independently of any AT&T UNIX license. Two years later and in cooperation with Luxor, a computer called ABC 1600 was developed for the office market, while in parallel, DIAB continue to produce enhanced versions of the DS90 computer using newer versions of the Motorola CPUs such as Motorola 68010, 68020, 68030 and eventually 68040. In 1990 DIAB was acquired by Groupe Bull who continued to produce and support the DS machines under the brand name "DIAB", with names such as "DIAB 2320", "DIAB 2340" etc., still running DIABs version of DNIX.
Derivative at ISC Systems Corporation.
ISC Systems Corporation (ISC) purchased the right to use DNIX in the late 1980s for use in its line of Motorola 68k-based banking computers. (ISC was later bought by Olivetti, and was in turn resold to Wang, which was then bought by Getronics. This corporate entity, most often referred to as 'ISC', has answered to a bewildering array of names over the years.) This code branch was the SVR2 compatible version, and received extensive modification and development at their hands. Notable features of this operating system were its support of demand paging, diskless workstations, multiprocessing, asynchronous I/O, the ability to mount processes (handlers) on directories in the file system, and message passing. Its real-time support consisted largely of internal event-driven queues rather than list search mechanisms (no 'thundering herd'), static process priorities in two classes (run to completion and timesliced), support for contiguous files (to avoid fragmentation of critical resources), and memory locking. The quality of the orthogonal asynchronous event implementation has yet to be equalled in current commercial operating systems, though some approach it. (The concept that has yet to be adopted is that the synchronous marshalling point of all the asynchronous activity "itself" could be asynchronous, ad infinitum. DNIX handled this with aplomb.) The asynchronous I/O facility obviated the need for Berkeley sockets "select" or SVR4's STREAMS "poll" mechanism, though there was a socket emulation library that preserved the socket semantics for backward compatibility. Another feature of DNIX was that "none" of the standard utilities (such as ps, a frequent offender) rummaged around in the kernel's memory to do their job. System calls were used instead, and this meant the kernel's internal architecture was free to change as required. The handler concept allowed network protocol stacks to be outside the kernel, which greatly eased development and improved overall reliability, though at a performance cost. It also allowed for foreign file systems to be user-level processes, again for improved reliability. The main file system, though it could have been (and once was) an external process, was pulled into the kernel for performance reasons. Were it not for this DNIX could well have been considered a microkernel, though it was not formally developed as such. Handlers could appear as any type of 'native' Unix file, directory structure, or device, and file I/O requests that the handler itself could not process could be passed off to other handlers, including the underlying one upon which the handler was mounted. Handler connections could also exist and be passed around independent of the filesystem, much like a pipe. One effect of this is that TTY-like 'devices' could be emulated without requiring a kernel-based pseudo terminal facility.
An example of where a handler saved the day was in ISC's diskless workstation support, where a bug in the implementation meant that using named pipes on the workstation could induce undesirable resource locking on the fileserver. A handler was created on the workstation to field accesses to the afflicted named pipes until the appropriate kernel fixes could be developed. This handler required approximately 5 kilobytes of code to implement, an indication that a non-trivial handler did not need to be large.
ISC also received the right to manufacture DIAB's DS90-10 and DS90-20 machines as its file servers. The multiprocessor DS90-20's, however, were too expensive for the target market and ISC designed its own servers and ported DNIX to them. ISC designed its own GUI-based diskless workstations for use with these file servers, and ported DNIX again. (Though ISC used Daisy workstations running Daisy DNIX to design the machines that would run DIAB's DNIX, there was negligible confusion internally as the drafting and layout staff rarely talked to the software staff. Moreover, the hardware design staff didn't use "either" system! The running joke went something like: "At ISC we "build" computers, we don't "use" them.") The asynchronous I/O support of DNIX allowed for easy event-driven programming in the workstations, which performed well even though they had relatively limited resources. (The GUI diskless workstation had a 7 MHz 68010 processor and was usable with only 512K of memory, of which the kernel consumed approximately half. Most workstations had 1 MB of memory, though there were later 2 MB and 4 MB versions, along with 10 MHz processors.) A full-blown installation could consist of one server (16 MHz 68020, 8 MB of RAM, and a 200 MB hard disk) and up to 64 workstations. Though slow to boot up, such an array would perform acceptably in a bank teller application. Besides the innate efficiency of DNIX, the associated DIAB C compiler was key to high performance. It generated particularly good code for the 68010, especially after ISC got done with it. (ISC also retargeted it to the Texas Instruments TMS34010 graphics coprocessor used in its last workstation.) The DIAB C compiler was, of course, used to build DNIX itself which was one of the factors contributing to its efficiency, and is still available (in some form) through Wind River Systems.
These systems are still in use as of this writing in 2006, in former Seattle-First National Bank branches now branded Bank of America. There may be, and probably are, other ISC customers still using DNIX in some capacity. Through ISC there was a considerable DNIX presence in Central and South America.
Asynchronous events.
DNIX's native system call was the "dnix(2)" library function, analogous to the standard Unix "unix(2)" or "syscall(2)" function. It took multiple arguments, the first of which was a function code. Semantically this single call provided all appropriate Unix functionality, though it was syntactically different from Unix and had, of course, numerous DNIX-only extensions.
DNIX function codes were organized into two classes: Type 1 and Type 2. Type 1 commands were those that were associated with I/O activity, or anything that could potentially cause the issuing process to block. Major examples were "F_OPEN", "F_CLOSE", "F_READ", "F_WRITE", "F_IOCR", "F_IOCW", "F_WAIT", and "F_NAP". Type 2 were the remainder, such as "F_GETPID", "F_GETTIME", etc. They could be satisfied by the kernel itself immediately.
To invoke asynchronicity, a special file descriptor called a trap queue had to have been created via the Type 2 opcode "F_OTQ". A Type 1 call would have the "F_NOWAIT" bit OR-ed with its function value, and one of the additional parameters to "dnix(2)" was the trap queue file descriptor. The return value from an asynchronous call was not the normal value but a kernel-assigned identifier. At such time as the asynchronous request completed, a "read(2)" (or "F_READ") of the trap queue file descriptor would return a small kernel-defined structure containing the identifier and result status. The "F_CANCEL" operation was available to cancel any asynchronous operation that hadn't yet been completed, one of its arguments was the kernel-assigned identifier. (A process could only cancel requests that were currently owned by itself. The exact semantics of cancellation was up to each request's handler, fundamentally it only meant that any waiting was to be terminated. A partially completed operation could be returned.) In addition to the kernel-assigned identifier, one of the arguments given to any asynchronous operation was a 32-bit user-assigned identifier. This most often referenced a function pointer to the appropriate subroutine that would handle the I/O completion method, but this was merely convention. It was the entity that read the trap queue elements that was responsible for interpreting this value.
struct itrq { /* Structure of data read from trap queue. */
 short it_stat; /* Status */
 short it_rn; /* Request number */
 long it_oid; /* Owner ID given on request */
 long it_rpar; /* Returned parameter */
Of note is that the asynchronous events were gathered via normal file descriptor read operations, and that such reading was itself capable of being made asynchronous. This had implications for semi-autonomous asynchronous event handling packages that could exist within a single process. (DNIX 5.2 did not have lightweight processes or threads.) Also of note is that "any" potentially blocking operation was capable of being issued asynchronously, so DNIX was well equipped to handle many clients with a single server process. A process was not restricted to having only one trap queue, so I/O requests could be grossly prioritized in this way.
Compatibility.
In addition to the native "dnix(2)" call, a complete set of 'standard' libc interface calls was available.
"open(2)", "close(2)", "read(2)", "write(2)", etc. Besides being useful for backwards compatibility, these were implemented in a binary-compatible manner with the NCR Tower computer, so that binaries compiled for it would run unchanged under DNIX. The DNIX kernel had two trap dispatchers internally, one for the DNIX method and one for the Unix method. Choice of dispatcher was up to the programmer, and using both interchangeably was acceptable. Semantically they were identical wherever functionality overlapped. (In these machines the 68000 trap #0 instruction was used for the "unix(2)" calls, and the trap #4 instruction for "dnix(2)". The two trap handlers were really quite similar, though the [usually hidden] "unix(2)" call held the function code in the processor's D0 register, whereas "dnix(2)" held it on the stack with the rest of the parameters.)
DNIX 5.2 had no networking protocol stacks internally (except for the thin X.25-based Ethernet protocol stack added by ISC for use by its diskless workstation support package), all networking was conducted by reading and writing to Handlers. Thus, there was no socket mechanism, but a "libsocket(3)" existed that used asynchronous I/O to talk to the TCP/IP handler. The typical Berkeley-derived networking program could be compiled and run unchanged (modulo the usual Unix porting problems), though it might not be as efficient as an equivalent program that used native asynchronous I/O.
Handlers.
Under DNIX, a process could be used to handle I/O requests and to extend the filesystem. Such a process was called a "Handler", and was a major feature of the operating system. A handler was defined as a process that owned at least one "request queue", a special file descriptor that was procured in one of two ways: with a "F_ORQ" or a "F_MOUNT" call. The former invented an isolated request queue, one end of which was then typically handed down to a child process. (The network remote execution programs, of which there were many, used this method to provide standard I/O paths to their children.) The latter hooked into the filesystem so that file I/O requests could be adopted by handlers. (The network login programs, of which there were even more, used this method to provide standard I/O paths to their children, as the semantics of logging in under Unix requires a way for multiple perhaps-unrelated processes to horn in on the standard I/O path to the operator.) Once mounted on a directory in the filesystem, the handler then received all I/O calls to that point.
A handler would then read small kernel-assigned request data structures from the request queue. (Such reading could be done synchronously or asynchronously as the handler's author desired.) The handler would then do whatever each request required to be satisfied, often using the DNIX "F_UREAD" and "F_UWRITE" calls to read and write into the request's data space, and then would terminate the request appropriately using "F_TERMIN". A privileged handler could adopt the permissions of its client for individual requests to subordinate handlers (such as the filesystem) via the "F_T1REQ" call, so it didn't need to reproduce the subordinate's permission scheme. If a handler was unable to complete a request itself, the "F_PASSRQ" function could be used to pass I/O requests from one handler to another. A handler could perform part of the work requested before passing the rest on to another handler. It was very common for a handler to be state-machine oriented so that requests it was fielding from a client were all done asynchronously. This allowed for a single handler to field requests from multiple clients simultaneously without them blocking each other unnecessarily. Part of the request structure was the process ID and its priority so that a handler could choose what to work on first based upon this information, there was no requirement that work be performed in the order it was requested. To aid in this, it was possible to poll both request and trap queues to see if there was more work to be considered before buckling down to actually do it.
struct ireq { /* Structure of incoming request */
 short ir_fc; /* Function code */
 short ir_rn; /* Request number */
 long ir_opid; /* Owner ID that you gave on open or mount */
 long ir_bc; /* Byte count */
 long ir_upar; /* User parameter */
 long ir_rad; /* Random address */
 ushort ir_uid; /* User ID */
 ushort ir_gid; /* User group */
 time_t ir_time; /* Request time */
 ulong ir_nph;
 ulong ir_npl; /* Node and process ID */
There was no particular restriction on the number of request queues a process could have. This was used to provide networking facilities to chroot jails, for example.
Examples.
To give some appreciation of the utility of handlers, at ISC handlers existed for:
ISC's extensions.
ISC purchased both 5.2 (SVR2 compatible) and 5.3 (SVR3 compatible) versions of DNIX. At the time of purchase, DNIX 5.3 was still undergoing development at DIAB so DNIX 5.2 was what was deployed. Over time, ISC's engineers incorporated most of their 5.3 kernel's features into 5.2, primarily shared memory and IPC, so there was some divergence of features between DIAB and ISC's versions of DNIX. DIAB's 5.3 likely went on to contain more SVR3 features than ISC's 5.2 ended up with. Also, DIAB went on to DNIX 5.4, a SVR4 compatible OS.
At ISC, developers considerably extended their version of DNIX 5.2 (only listed are features involving the kernel itself) based upon both their needs and the general trends of the Unix industry:
Features that were never added.
When DNIX development at ISC effectively ceased in 1997, a number of planned OS features were left on the table:


Surface Go 2

The Surface Go 2 is a 2-in-1 detachable tablet computer developed by Microsoft. It is the second generation of Surface Go and was announced alongside the Surface Book 3 on May 6, 2020 online. It was available for purchase starting May 12, 2020.
Surface Go 2 keeps the same thin, lightweight design, but with a larger 10.5-inch display, an improved battery life and an improved performance, one particular model performs 64% faster than the original. It is the first time that an Intel Core m processor is offered in this small device.
The device runs Windows 10 Home in S Mode. It features the same 5 MP front-facing camera, 8 MP rear camera and an infrared camera, same as the previous model. A NFC chip and a kickstand supporting an angle of up to 165° are also present.
With a bigger display also comes with a bigger 1920 x 1280 resolution at 220 ppi, while still maintaining the 3:2 aspect ratio.
The Surface Go 2 starts at $399.99 and goes up to $729.99. Its detachable keyboard with touchpad and stylus pen are sold separately.
Hardware.
The Surface Go 2 is the 5th addition to small Surface lineup. The Surface Go 2 is aimed toward children and students, it is also aimed for schools and the enterprise.
The Surface Go 2 features a bigger screen than its predecessor. It features a full-body magnesium alloy construction. The device features a new and fanless powerful processor, an Intel Core m3 8th gen processor inside. The cheaper models will have an Intel Pentium Gold processor inside.
The device contains USB C port with power delivery and a "Surface Connect" port. The front-facing camera contains an infrared sensor that supports login using Windows Hello.
The device's "Type Cover" uses an 8-pin connection which is compatible with the previous model. The keyboard is sold separately at $99.
Software.
Surface Go 2 models ship with a pre-installed 64-bit version of Windows 10 Home in S Mode and a 30-day trial of Microsoft 365. Users may only install software from Windows Store. Users can opt out of the S Mode of the OS and upgrade to Home for free or Pro for a fee and be able to install apps from outside the Windows Store.
Windows 10 comes pre-installed with Mail, Calendar, People, Xbox, Photos, Movies and TV, Groove, Your Phone, Office and Edge. The device also supports Windows Hello login using a biometric facial recognition.


Csplit

The codice_1 command in Unix and Unix-like operating systems is a utility that is used to split a file into two or more smaller files determined by context lines.
History.
codice_1 is part of the X/Open Portability Guide since issue 2 of 1987. It was inherited into the first version of POSIX and the Single Unix Specification. It first appeared in PWB UNIX.
The version of codice_1 bundled in GNU coreutils was written by Stuart Kemp and David MacKenzie.
Usage.
The command-syntax is:
csplit [OPTION]... FILE PATTERN...
The "patterns" may be line numbers or regular expressions. The program outputs pieces of the file separated by the patterns into files codice_4, codice_5, etc., and outputs the size of each piece, in bytes, to standard output.
The "optional parameters" modify the behaviour of the program in various ways. For example, the default prefix string (xx) and number of digits (2) in the output filenames can be changed.
As with most Unix utilities, a return code of 0 indicates success, while nonzero values indicate failure.
Comparison to split.
The codice_6 command also splits a file into pieces, except that all the pieces are of a fixed size (measured in lines or bytes).


William Martens

William Martens (born August 1964) is a computer engineer and magazine editor known for writing articles for the magazine Call-A.P.P.L.E., including the long running "Bytes from the A.P.P.L.E.", a product introduction article. His invention of The Library 1.1 allows A.P.P.L.E. to produce the software and document libraries in a matter of seconds covering the entire range of Apple computers.
Early life.
Bill's early years were spent traveling around the world with his father, Michael, a U.S. Army soldier. His early interests included Rocketry, space exploration, and flying. This may have been due to his stepmother, Betty Lou Miller, being a Westinghouse clean-room supervisor. From an early age, she began putting electronics kits, books on space and satellites and other science related items in his room. Bill built his first radio at age 9 from one of the kits Betty had provided.
Bill's first contact with a computer came in 1976 through a copy of Creative Computing, a popular hobbyist magazine at the time. When Bill moved to Germany with his father in 1977, the school had a DEC PDP/11-4 series computer which had several teletypes attached. This is where his true talents came through. By 1979, Bill was spending more than 5 hours a day in the computer labs at Nuremberg American H.S., working on anything computer related he could. Always seen with his box of computer tapes, it was apparent that this would be his life.
In 1980, Bill returned to the US and once again turned to the computers and by summer of 1981, was working for Apple Pugetsound Program Library Exchange.
A.P.P.L.E..
Bill joined A.P.P.L.E in Summer 1981. Under the expert tutelage of Michael Christensen and Joff Morgan, Bill began to take an interest in Pascal which was fast becoming the programming language of the modern programmer. In January 1982, Bill began work on the Pascal Anthology which became a mainstay product for A.P.P.L.E until 1988. In 1989, he moved to Japan to pursue his career in engineering. His first job in Japan was working for a Japanese electronics house designing and programming satellite transceivers for ships.
In 1985 he created a language which allowed formatting of text and allowed user interaction. File Control Language was only released in small numbers and was soon made obsolete by the introduction of HyperCard. The other thing which led to the quick demise of File Control Language was the fact that it was oriented around the Apple II Series computers and was not ported to any of the other computing platforms of the era.
In 1997, he invented the self producing web system for computer databases, The Library 1.1. This system was a mainstay of the MSCOM software library which has become the surviving system in A.P.P.L.E's efforts to create one of the largest Apple related software and documentation libraries on the internet today.
In 2001, he began to work on restoring A.P.P.L.E and Call-A.P.P.L.E. Magazine. By May 2002, this was a reality with the first newsletter/magazine issue since 1994. Today, the magazine has a distribution of about 14,000 copies per month and continues to enjoy a high percentage of readers who are Apple II specific readers. Bill currently serves as the President of A.P.P.L.E. and is in his second term as President separated by a one-year period in which Mike Pfaiffer was President.
Other.
William Martens is known in Japan as for his years as a football Player and as a television actor. As a Television actor, William has performed in numerous Japanese and Korean dramas, re-enactment dramas, Variety programs, commercials and promotional videos. He is currently starring in the Paul Carter directed film, "The Lost Man", which will be released fall 2006.
Football career.
William has played for several clubs over the past 17 years. He joined the Harajuku Indians in 1990 and played and coached with them until the team folded in 1997. After a 5-year retirement due to an injury sustained when he was joining the Tachikawa Falcons of the JPFF, he returned to the Tokrozawa Outlaws in 2007 where he played for 2 years. He is currently playing with the Unisys Bulls of the X-League top division.
Stats:
Ht: 6'4" (190 cm)
Wt: 260 lbs (118 kg)


Zelybron Micro Nina

The Zelybron Micro Nina is Zelybron's entrant to the Ultra-Mobile PC (UMPC) market and is aimed to provide a bridge between regular laptops and netbooks. The Micro Nina also is Zelybron's first OEM product.
Zelybron's "Micro Nina" is focussed towards business use and was introduced in November 2008 in Europe, it is available with Microsoft Windows or Zelybron's own FreeBSD variant pre-installed. But has at least since 12 jun 2009 ended shipping of ZelybronBSD.
The "Zelybron Micro Nina" was originally designed to become a low budget PC; its design was moved into a netbook-formatted device for professional use, the laptop compares to a regular PC in performance and capabilities. In the same line of production, Zelybron also released a low budget PC, thin client and server, all of which are currently only available in Belgium, The Netherlands and Germany, however, Zelybron has announced the opening of a new factory in Shenzhen, China and is planning for global distribution of its whole Nina series.
Features.
Zelybron created a netbook sized computer which compares to regular PCs. Zelybron was the first to create a laptop capable of doing regular day-to-day work with the mobility of a netbook and the capacity of a full PC.
Zelybron aimed to add all features to its Micro Nina line a daily laptop user would expect from his/her laptop. It comes with a nearly normal size keyboard for easier use, surround-sound audio, a 1.3 Megapixel Webcam, 2 USB ports, card reader, a VGA connector for connecting an external monitor and has an internal SATA controller for either connecting a harddisk or solid-state drive.
The Micro Nina has very low power consumption (15 W) and compares with power use and mobility to other UMPCs.
The Micro Nina is installed with either Windows XP or Windows Vista, but can optionally be configured with ZelybronBSD which provides a simplified interface comparable with the Asus Eee PC Xandros.
Availability.
Zelybron currently only sells the laptops directly to customers and has recently moved into a new office in Breda, The Netherlands; the laptops seem not to be available from other distribution channels as of this writing.
Zelybron currently is distributing its laptops worldwide by themselves; With the opening of a new factory in Shenzhen, China, Zelybron hopes to bring its full range of products to more people and gain more recognition around the world. With the opening of its new factory, Zelybron also tries to create an extra, self-controlled, distribution channel, as stated by a local newspaper in Breda.
Other 'Ninas'.
The "Zelybron Micro Nina" netbooks are also available in 178 mm (7"), 203 mm (8") and 229 mm (9") format on request, however, Zelybron does not actively market these, next to this, Zelybron also allows customizations of its products on a per product basis since February 2009, allowing customers to personalize their products in colouring and configuration.


Eben Upton

Eben Christopher Upton (born 5 April 1978) is a Welsh technical director and ASIC architect for Broadcom. He is also a founder and former trustee of the Raspberry Pi Foundation, and now CEO of Raspberry Pi (Trading) Ltd., the wholly owned subsidiary which runs the engineering and trading activities of the Foundation. He is responsible for the overall software and hardware architecture of the Raspberry Pi device.
Life.
Eben Upton was born in Griffithstown near Pontypool, Wales, where his mother is from; his father is language Prof Clive Upton. He lived in Lae in Papua New Guinea between the ages of eight weeks and two and a half years. He then returned to the UK to grow up in Leeds, Birmingham and Ilkley.
Upton completed a Bachelor of Arts degree in Physics and Engineering in 1999 at the University of Cambridge where he was an undergraduate student at St John's College, Cambridge. He went on to do the Cambridge Diploma in Computer Science graduating in 2001. After his diploma, Upton was a research student in the Computer Laboratory, University of Cambridge. After finishing his PhD degree, he took a Master of Business Administration (MBA) at the Cambridge Judge Business School while working in industry.
Eben Upton moved production of Raspberry Pi computers from China to the Sony UK Technology Centre (Sony UK TEC) at Pencoed, Wales in 2012, 15–20 miles from where he was born.
Career.
Before working at Broadcom, Upton was Director of Studies in Computer Science at St John's College, Cambridge, with responsibility for undergraduate admissions. During his academic career, he co-authored papers on mobile services, Human–computer interaction (HCI), bluetooth and data dependency graphs. He has been a visiting Researcher at Intel Corporation, Founder and Chief Technology Officer at Ideaworks3D and a software engineer at IBM.
Works.
Upton has published books including the "Oxford Rhyming Dictionary" with his father Clive Upton. With Gareth Halfacree he co-authored the "Raspberry Pi User Guide".
Awards and honours.
Upton has won a number of awards including the Innovators Under 35 (TR35) from "MIT Technology Review" in 2012 and the Royal Academy of Engineering Silver Medal.
Upton was appointed Commander of the Order of the British Empire (CBE) in the 2016 Birthday Honours for services to business and education.
In 2020, he was awarded the IEEE Masaru Ibuka Consumer Electronics Award.
Personal life.
Eben Upton is married to Liz, whom he met at university. They have two children, a daughter, Aphra, born 19 April 2017, and a son Christopher (Kit), born 7 May 2010.


Luit

luit is a utility program used to translate the character set of a computer program so that its output can be displayed correctly on a terminal emulator that uses a different character set. Whereas iconv converts the character set of strings or text files at rest, luit converts the input and output of programs running interactively.
Overview.
The main purpose of luit is to allow "legacy" applications that use character sets other than UTF-8 to work with contemporary terminal emulators.
luit may be required today when connecting to a "legacy" host that only supports an older encoding, such as ISO 8859-1. For example, instead of running "codice_1", a user may have to run "" to properly render French accented characters on a UTF-8 terminal.
luit is also used to properly render the output of applications that use ISO 2022 character set switching. ISO 2022 is an older standard that allowed an application to "switch" between different fonts, e.g., to mix line-drawing characters with text or to display text in multiple languages and character sets. UTF-8 itself does not support switching fonts; the encoding is stateless and gives each unique character (including line-drawing characters) its own numerical encoding. It can be used to translate between these two encodings.
Examples of programs that require translation to run correctly on a UTF-8 terminal include earlier versions of emacs/MULE, and programs that use ISO 2022 shift sequences in ANSI escape codes that switch to an alternate character set in order to draw line-drawing characters.
luit is invoked automatically by xterm when necessary to translate program output into UTF-8, for programs running on a local computer. When connecting remotely to another computer, the user must run luit directly.
luit interprets application output according to the locale's character set with ISO 2022 shifts and ECMA-48 escape sequences. If an application is speaking a different language than the locale's character set (one that may have matched the terminal emulator's expectations in the absence of luit), luit can misinterpret the application's output and produce corrupted output to the terminal.
History.
luit was written in 2001 by Juliusz Chroboczek, when major Linux distributions began migrating to the Unicode character set from "legacy" encodings such as ISO 8859-1. It has since become a widely installed base utility, present on more than half of all Linux computer systems by some estimates. It is also part of IBM's AIX.
Implementations.
There are two versions of luit: one maintained by Thomas Dickey as part of xterm, and another by Freedesktop.org. Linux distributions generally ship the latter version as part of their X11 utilities package. However, while migrating to GitLab, the latter fork was discontinued because it was unmaintained.


Lsof

lsof is a command meaning "list open files", which is used in many Unix-like systems to report a list of all open files and the processes that opened them. This open source utility was developed and supported by Victor A. Abell, the retired Associate Director of the Purdue University Computing Center. It works in and supports several Unix flavors.
Examples.
Open files in the system include disk files, named pipes, network sockets and devices opened by all processes. One use for this command is when a disk cannot be unmounted because (unspecified) files are in use. The listing of open files can be consulted (suitably filtered if necessary) to identify the process that is using the files.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
syslogd 350 root 5w VREG 222,5 0 440818 /var/adm/messages
syslogd 350 root 6w VREG 222,5 339098 6248 /var/log/syslog
cron 353 root cwd VDIR 222,5 512 254550 /var -- atjobs
To view the port associated with a daemon:
sendmail 31649 root 4u IPv4 521738 TCP *:25 (LISTEN)
From the above one can see that "sendmail" is listening on its standard port of "25".
One can also list Unix Sockets by using codice_1.
Lsof output.
The lsof output describes:
For a complete list of options, see the Lsof(8) Linux manual page


ZX Spectrum Contended Memory

Some of the ZX Spectrum's 64 KB addressable memory space is referred to as contended memory. With the rest of the memory, the Z80 microprocessor is the exclusive bus master, so it reads and writes operate at its full bus speed but contended memory space is shared between the ULA and the Z80, with the ULA having higher priority. Contended memory occupies addresses 0x4000..0x7FFF of the Z80 memory map. This is the first 16 KB of RAM in the 48 KB machine and the entire RAM of the 16 KB machine.
Contention occurs as a result of the ULA reading the display and attributes data in this RAM to produce the TV video display. Contention therefore does not occur during horizontal flyback, vertical flyback or during the screen border.
Accesses to I/O also contend if the ULA must read contended memory while the Z80 accesses a ULA I/O port. ULA I/O ports are those with an even address (address bit 0 is a 0).
The Z80 must wait whenever the ULA needs to access contended memory before proceeding with its own contended memory read or write. The effect to the user is that programs that make use of contended memory or contended I/O run slower than those that avoid it.
Snow Bug.
The ULA must wait for a Z80 read or write to complete before it can stop the Z80's clock and access the memory; it will stop the Z80's clock only during the first clock cycle of a machine cycle.
Early Spectrums make the assumption that at most one contended memory access will occur in a machine cycle: this isn't true in instruction fetch cycles if the programmer has configured the interrupt vector table to fall within the contended area. In that case the ULA will decline to load its video address and the video byte displayed will be whatever the processor was reading. The consequence of this is random noise on the display, or 'snow'.
Since this effect did not occur under normal operation — it required a programmer's deliberate intervention — it was very seldom seen, being used only in some games [] as a special graphical effect.
Later versions of the Spectrum, including all 128kb versions, correct the bug.
Circuit.
The ULA does not use the Z80's bus request/grant mechanism to become bus master during its contended memory accesses. Instead, it extends the high period of the Z80 clock input to stop all microprocessor activity. While this is less elegant than performing a bus request, it does gain contended memory access to fewer Z80 clocks. This removes any need for the ULA to read display data in advance, a benefit with the crowded circuitry in the full ULA.
The ULA connects directly to the memory system ICs while the Z80 connects to them through isolating series current-limit resistors. This allows the ULA and memory to drive each other while the Z80 is also driving the memory. Using resistors instead of tristate bus driver ICs reduces the expense of the circuit but does take a higher average I/O pin current from the Z80, ULA and memory ICs.


Amiga, Inc.

Amiga, Inc. is a company that used to hold some trademarks and other assets associated with the Amiga personal computer (originally developed by Amiga Corporation).
Early years.
In the early 1980s Jay Miner, along with other Atari, Inc. staffers, set up another chip-set project under a new company in Santa Clara, called Hi-Toro (later renamed to Amiga Corporation), where they could have some creative freedom. Atari, Inc. went into contract with Amiga for licensed use of the chipset in a new high end game console and then later for use in a computer system. $500,000 was advanced to Amiga to continue development of the chipset. Amiga negotiated with Commodore International two weeks prior to the contract deadline of 30 June 1984. In August 1984, Atari Corporation, under Jack Tramiel, sued Amiga for breach of contract. The case was settled in 1987 in a closed settlement. (See "Amiga Corporation".)
In 1994, Commodore filed for bankruptcy and its assets were purchased by Escom, a German PC manufacturer, who in turn went bankrupt in 1996. The Amiga brand was then sold to another PC manufacturer, Gateway 2000, which had announced grand plans for it. However, in 1999, Gateway sold Amiga to Amino Development for almost 5 million dollars. Gateway still retained ownership to all Amiga patents.
Dispute and settlement with Hyperion.
Amiga, Inc. licensed the rights to make hardware using the AmigaOne brand to a computer vendor based in the UK, Eyetech Group. However, due to poor sales Eyetech suffered substantial losses and ceased trading.
In 2007 Amiga, Inc. announced specs for a new line of Amiga computers: low end and high models. At the same time Amiga, Inc. sued Hyperion Entertainment, a company developing AmigaOS 4 for AmigaOne boards for trademark infringement in the Washington Western District Court in Seattle, USA. The company claimed Hyperion was in breach of contract, citing trademark violation and copyright infringement concerning the development and marketing of AmigaOS 4.0.
Also in 2007, Amiga, Inc. intended to become the naming-rights sponsor for a planned ice hockey arena in Kent, Washington, but failed to deliver a promised down payment.
Pentti Kouri, Chairman of the Board and a primary source of capital for Amiga, Inc., died in 2009.
On 20 September 2009 Amiga Inc and Hyperion Entertainment reached a settlement where Hyperion is granted an exclusive, perpetual, worldwide right to AmigaOS 3.1 in order to use, develop, modify, commercialize, distribute and market AmigaOS 4.x and subsequent versions of AmigaOS (including AmigaOS 5).
Licensing rights.
In 2010 Commodore USA announced they acquired the rights to the Amiga name and relaunch Amiga branded desktops running AROS
and Linux, which however Hyperion Entertainment promptly disputed, on the basis of a 2009 settlement agreement between Hyperion and Amiga Inc. After legal threats from Hyperion due to conditions in the Amiga Inc. settlement that they are now subject to as an Amiga licensee, Commodore USA later dropped their AROS plans and announced on their relaunched website, that they will create a new OS called AMIGA Workbench 5.0 (name changed to Commodore OS since Workbench was owned by Cloanto), which was later revealed will be based on Linux.
In 2011, Amiga Inc. licensed the brand name to Hong Kong based manufacturer IContain Systems, Ltd.
In 2012, Amiga Inc. completed transfer of copyrights to Cloanto.
Recent events.
Amiga Inc. is in dispute with Hyperion due to the release of Workbench 3.1.4 by Hyperion.
On 1 February 2019, Amiga Inc. transferred all Amiga-related rights to C-A Acquisition Corporation owned by Mike Battilana (director of Cloanto, company behind the Amiga Forever emulation package), later renamed to Amiga Corporation.


Versatile Laboratory Aid

The Versatile Laboratory Aid (VELA) is a 4-channel data logging tool that was created as part of a joint venture by Ashley Clarke, Keith Jones and David Binney of Leeds University and Educational Electronics. The VELA was designed to be used as a stand-alone data logger that could be used out in the field and it could then be taken back to the laboratory where it could be connected to a chart printer, oscilloscope or microcomputer for data analysis purposes.
The VELA was designed and built with the intention that it would be used in schools and Universities to monitor Physics and Chemistry experiments as it could be attached to all manner or analogue probes and sensors such as pH meters, temperature sensors, light gates, Signal generator and microphones. Each of the VELA's four channels can be independently set to record voltages in the ranges of +/-250mV, +/-2.5V and +/-25V allowing a range of different input devices to be connected simultaneously.
The basic VELA carries a single 4KB EPROM (ISL1 or ISL1*) which contains the basic input and output routines that handle the keyboard input and 8-digit LED display output together with seventeen user selectable programs which range from a 4-channel digital volt meter to a random event monitor which could be used with a Geiger Counter Probe to measure and log radiation levels from a source material.
In total, the VELA could record a maximum of 4096 data points either from one channel or split equally between the four channels depending on the selected monitoring program. In later versions of the VELA firmware (ISL1*), the number of data points was reduced by 7 bytes per data channel as these bytes were reserved for storing channel and program configuration data when transferring data to a microcomputer.
Hardware specifications.
The VELA went through at least two hardware revisions going from the Mark I to Mark II and subsequently the VELA PLUS but the ISL ROMs remained compatible between all three devices although the Mark I VELA required a daughter board to carry the extra ROMs that were developed after the VELA's initial release.
Mark I Specifications.
The VELA Mark I was based around the Motorola MC6802 central processor and carried 4KB of RAM. It shipped with the original ISL1 ROM fitted and has space for a further 2 ROMs to be fitted on board. The PCB of the Mark I was split into two parts which connected to each other through a ribbon cable. The ROMs were generally shipped on 2732 EPROM chips and they could be sent back to Educational Electronics to be updated with enhanced firmware when it became available.
Mark II Specifications.
The VELA Mark II was a refinement to the Mark I design and was based on the same processor and hardware. The Mark II PCB was condensed onto a single board and carried space for a further three EPROM's to be fitted in addition to the ISL1* EPROM that it shipped with. There were modifications to the connectors on the VELA Mark II with the addition of a 5V 70mA output and a revised power supply connector although early Mark II VELA's continued to use the original 3.5mm power supply plug socket as used on the VELA Mark I.
VELA PLUS Specifications.
The VELA PLUS was again a refinement on the Mark II VELA and the PCB carried alterations to the op-amps and circuitry associated with the channel inputs. The VELA front panel was also revised to make it clearer to understand as the usability of the VELA had been a source of issues amongst the teaching community.
With the advent of the VELA PLUS, the name Versatile Laboratory Aid" which was displayed on the front panel was changed to Versatile Laboratory Instrument" whilst retaining the VELA contraction.
Use in education.
The VELA was 50/50 subsidised by the DTI, an arm of the British Government to encourage take up within the education sector and many thousands of VELA units were sold to schools.
In 1986 an article in the Electronic Systems News Spring Journal stated "4000 teachers now possess a VELA, but it is suspected that more than half of these have never been used."
Connectivity.
The VELA was designed to be connected to three different types of device, being a chart printer, an oscilloscope or a microcomputer. Connecting the VELA to a chart printer allowed the captured data to be printed directly from the VELA for analysis and making a permanent record of the data captured. Connecting the VELA to an oscilloscope allowed users to have a real-time view of the data the VELA was recording or a playback view of pre-existing captured data. When connected to a microcomputer, the data captured could be stored and manipulated using a variety of different software applications that were available for the VELA.
Using the Digital Out port, the VELA can also be used as a control device using 8 of the 16 data lines provided.
Available Software.
Software was produced for several microcomputers including the Apple II, BBC Micro, Commodore PET, Commodore 64, Research Machines 380Z and early IBM-PC compatible. A partial list of known software titles is listed below.


With Open Eyes

With Open Eyes is a 1995 art gallery program developed by American studio The Voyager Company for Macintosh, Pippin, and Windows 3.x.


LGP-30

The LGP-30, standing for Librascope General Purpose and then Librascope General Precision, was an early off-the-shelf computer. It was manufactured by the Librascope company of Glendale, California (a division of General Precision Inc.), and sold and serviced by the Royal Precision Electronic Computer Company, a joint venture with the Royal McBee division of the Royal Typewriter Company. The LGP-30 was first manufactured in 1956, at a retail price of $47,000, .
The LGP-30 was commonly referred to as a desk computer. Its height, width, and depth, excluding the typewriter shelf, was . It weighed about , and was mounted on sturdy casters which facilitated moving the unit.
Design.
The primary design consultant for the Librascope computer was Stan Frankel, a Manhattan Project veteran and one of the first programmers of ENIAC. He designed a usable computer with a minimal amount of hardware. The single address instruction set had only 16 commands. Magnetic drum memory held the main memory, and the central processing unit (CPU) processor registers, timing information, and the master bit clock, each on a dedicated track. The number of vacuum tubes was kept to a minimum by using solid-state diode logic, a bit-serial architecture and multiple use of each of the 15 flip-flops.
It was a binary, 31-bit word computer with a 4096-word drum memory. Standard inputs were the Flexowriter keyboard and paper tape (ten six-bit characters/second). The only printing output was the Flexowriter printer (typewriter, working at 10 characters/second). An optional higher-speed paper tape reader and punch was available as a separate peripheral.
 The computer contained 113 electronic tubes and 1450 diodes. The 113 electronic tubes were mounted on 34 etched circuit pluggable cards which also contain associated components. Although 34 pluggable cards were used, there were only 12 different types of such cards. Card-extenders were available to permit dynamic testing of all machine functions. 680 of the 1450 diodes were mounted on one pluggable logic board.
The LGP-30 required 1500 watts when operating under full load. The power inlet cord was plugged into any standard 115 volt 60-cycle single-phase line. The computer contained internal voltage regulation against power-line variations of voltages from 95 to 130 volts. In addition to regulation of power-line variations, the computer also contained the circuitry required to permit a warm-up stage. This warm-up stage minimized thermal shock to tubes to ensure long component life. The computer contained its own blower unit and directed filtered air, through ducts, to tubes and diodes, in order to ensure component life and proper operation. No expensive air conditioning needed to be installed if operated within a reasonable temperature range.
There were 32 bit locations per drum word, but only 31 were used, permitting a "restoration of magnetic flux in the head" at the 32nd bit time. Since there was only one address per instruction, a method was needed to optimize allocation of operands. Otherwise, each instruction would wait a complete drum (or disk) revolution each time a data reference was made. The LGP-30 provided for operand-location optimization by interleaving the logical addresses on the drum so that two adjacent addresses (e.g., 00 and 01) were separated by nine physical locations. These spaces allowed for operands to be located next to the instructions which use them. There were 64 tracks, each with 64 words (sectors). The time between two adjacent physical words was about 0.260 millisecond (ms), and the time between two adjacent addresses was 9 x 0.260 or 2.340 ms. The worst-case access time was 16.66 ms.
Half of the instruction (15 bits) was unused. The unused half could have been used for extra instructions, indexing, indirect addressing, or a second (+1) address to locate the next instruction, each of which would have increased program performance. None of these features were implemented in the LGP-30, but some were realized in its 1960 successor, the RPC-4000.
A truly unique feature of the LGP-30 was the way it handled multiplication. Despite the LGP-30 being inexpensive, it had built-in multiplication. Since this was a drum computer and bits needed to be acted on serially as they were read from the drum, as it did each of the additions involved in the multiplication, it effectively shifted the operand right, acting as if the binary point were on the left side of the word, as opposed to the right side as most other computers assume. The divide operation worked similarly. It also had an integer multiplication but, because the accumulator had 32 bits while memory words had only 31 bits, only even integers could be thus represented.
To further reduce costs, the traditional front panel lights showing internal registers were absent. Instead, Librascope mounted a small oscilloscope on the front panel. It displayed the output from the three register read heads, one above the other, allowing the operator to "see" and actually read the bits. Horizontal and vertical size controls let the operator adjust the display to match a plastic overlay engraved with the bit numbers.
To read bits the operator counted the up- and down-transitions of the oscilloscope trace.
Unlike other machines of its day, internal data was represented in hexadecimal as opposed to octal, but being a very inexpensive machine it used the physical typewriter keys that correspond to positions 10 to 15 in the type basket for the six non-decimal characters (as opposed to the current practice of A – F) to represent those values, resulting in 0 – 9 f g j k q w, which was remembered using the phrase "FiberGlass Javelins Kill Quite Well".
ACT-III programming language.
The LGP-30 had a high-level language called ACT-III. Every token had to be delimited by an apostrophe, making it hard to read and even harder to prepare tapes:
ALGOL 30.
Dartmouth College developed two implementations of ALGOL 60 for the LGP-30. Dartmouth ALGOL 30 was a three-pass system (compiler, loader, and interpreter) that provided almost all features of ALGOL except those requiring run-time storage allocation. SCALP, a Self Contained Algol Processor, was a one-pass system for a small subset of ALGOL (no blocks other than the entire program), no procedure declarations, conditional statements but no conditional expressions, no constructs other than codice_1 in a codice_2 statement, no nested codice_3 declarations (nested calls are permitted), and no boolean variables and operators. As in ACT-III, every token had to be separated by an apostrophe.
Starting the machine.
The procedure for starting, or "booting" the LGP-30 was one of the most complicated ever devised. First, the bootstrap paper tape was snapped into the console typewriter, a Friden Flexowriter. The operator pressed a lever on the Flexowriter to read an address field and pressed a button on the front panel to transfer the address into a computer register. Then the lever on the Flexowriter was pressed to read the data field and three more buttons were pressed on the front panel to store it at the specified address. This process was repeated, maybe six to eight times, and a rhythm was developed:
 burrrp, clunk,
 burrrp, clunk, clunk, clunk,
 burrrp, clunk,
 burrrp, clunk, clunk, clunk,
 burrrp, clunk,
 burrrp, clunk, clunk, clunk,
 burrrp, clunk,
 burrrp, clunk, clunk, clunk,
 burrrp, clunk,
 burrrp, clunk, clunk, clunk,
 burrrp, clunk,
 burrrp, clunk, clunk, clunk.
The operator then removed the bootstrap tape, snapped in the tape containing the regular loader, carefully arranging it so it would not jam, and pressed a few more buttons to start up the bootstrap program. Once the regular loader was in, the computer was ready to read in a program tape. The regular loader read a more compact format tape than the bootstrap loader. Each block began with a starting address so the tape could be rewound and retried if an error occurred. If any mistakes were made in the process, or if the program crashed and damaged the loader program, the process had to be restarted from the beginning.
LGP-21.
In 1963, Librascope produced a transistorized update to the LGP-30 named the LGP-21. The new computer had about 460 transistors and about 375 diodes. It cost only $16,250, one-third the price of its predecessor. Unfortunately it was also about one-third as fast as the earlier computer.
The central computer weighed about , the basic system (including printer and stands) about .
RPC 4000.
Another, more-powerful successor machine, was the General Precision RPC 4000, announced in 1960. Similar to the LGP-30, but transistorized, it featured 8,008 32-bit words of memory drum storage. It had 500 transistors and 4,500 diodes and sold for $87,500. Weighed .
Notable uses.
Today, the RPC-4000 (along with LGP-30) is remembered as the computer on which Mel Kaye performed a legendary programming task in machine code, retold by Ed Nather in the hacker epic "The Story of Mel". The LGP-30 was also used by Edward Lorenz in his attempt to model changing weather patterns. His discovery that massive differences in forecast could derive from tiny differences in initial data led to him coining the terms "strange attractor" and "butterfly effect", core concepts in chaos theory.


Newbear 77-68

The Newbear 77-68 was a kit of parts from which a purchaser could construct a home computer based around a Motorola 6800 microprocessor. Because it was designed to be assembled by its owner at home, it was also a homebuilt computer. The 77-68 was designed by Tim Moore and was offered for sale by Bear Microcomputer Systems of Newbury, Berkshire, England from June 1977. It was among the first, if not "the" first, of British home computers and was featured in the launch edition of "Personal Computer World" magazine in February 1978.
The Newbear 77-68 was both a home computer and a homebuilt computer, since it was designed to not only be used at home (hence a home computer), but also be assembled at home by its owner (hence a homebuilt computer).
Description.
The basic 77-68 comprised an 8-inch square printed circuit board accommodating the microprocessor, Static RAM of 256 8 bit words and the bare essentials in terms of input/output and timing logic to make a working computer. The processor ran with an instruction cycle time of around 1.25 microseconds with most instructions executing in 3 to 7 microseconds.
In the short time for which the 77-68 represented an economic and reasonably current technology for home computing, an active user group distributed designs for additional components such as memory cards, video display cards and teletype interfaces which enthusiasts could, and did, construct themselves. It was even possible to run BASIC. All the components to build the basic machine could be bought for around £50 with additional elements added later. This was a sensible approach at a time when, for example, 16K x 1 bit dynamic memory chips cost £7 each and 8 chips plus a significant amount of support logic were required to build a memory card. Putting this in the context of the economics of the period, a hamburger or 10 gallons of beer cost less than £1 in the UK at that time.
Operation.
The 77-68 was programmed in its most basic form with toggle switches and LEDs. With the microprocessor's operation suspended in "HALT" mode, memory words could be accessed and their contents observed in binary. The word could then be modified directly using an additional 8 binary toggle switches to specify the data required. Once a complete program had been "toggled in" using this method, the "HALT" condition could be removed using another switch and the microprocessor would look for an address at which to start executing the program in the last two words of the address space.
This technique, called Direct Memory Access was typical for many early computers using volatile memory that did not retain its contents when the power was switched off. Even early mainframe computers required their operators to "toggle" or "dial" in a bootstrap program by hand to get things going on power-up.
Capability.
Although 256 words of memory seems extraordinarily small by contemporary standards, when "toggling in" programs by hand it seemed quite adequate. There was ample space to create programs that played music, sent and received morse code, operated data storage to media such as a cassette player and even offered game experiences (though these required significant imagination by the user).
Expanded with additional memory, the 77-68 was quite capable of running software such as the TSC BASIC interpreter and users wrote software that offered a wide range of applications at a time when even word processors were a novelty and spreadsheets were largely unknown.
User experience and legacy.
For many home computer pioneers, primitive machines like the 77-68 offered a thrill that is hard to describe to a generation that has grown up with technology many times more powerful all around. The sense of being able to construct something from inert basic components, write a program and see a set of components that had been separate "come to life" in concert to do something small but useful was very exciting. This was a time when it was quite possible for a non-specialist to understand every aspect of the computer they had built and machines like the 77-68 offered a generation the chance to own and experiment with one for the first time. While the number of kits sold and constructed and the number of systems still in operation is unknown, one of the systems illustrated in this article is now in the Museum of Computing, Swindon, England.


Resource Monitor

Resource Monitor, a utility in Windows Vista and later, displays information about the use of hardware (CPU, memory, disk, and network) and software (file handles and modules) resources in real time. Users can launch Resource Monitor by executing "resmon.exe" ("perfmon.exe" in Windows Vista).
The Vista and later Resource Monitor heavily leverages the Event Tracing for Windows (ETW) facilities introduced in Windows 7;
the counter setup (event tracing session) used by the Resource Monitor can provide logging as well.
Features.
The Resource Monitor window includes five tabs:


Tomy Tutor

The Tomy Tutor, originally sold in Japan as the and in the UK as the Grandstand Tutor, is a home computer produced by the Japanese toymaker Tomy. It was architecturally similar, but not identical, to the Texas Instruments TI-99/4A, and used a similar Texas Instruments 16-bit CPU. The computer was launched in Japan in 1982, and in the UK and the United States in the next year.
History.
Produced by Matsushita, the computer was released in Japan in 1982 under the name Pyūta.
Tomy described the Tutor, with 16K RAM, as good for games and education. The company stated that its documentation would let an eight-year-old child use the computer without adult supervision.
One of the major flaws pointed out with the Tutor was not its hardware, but its marketing: the Tutor was announced as a children's computer when in fact it was practically a cheap, evolved version of the TI-99/4A, even having a similar 16-bit CPU (the TMS9995, closely related to the TI-99/4's TMS 9900); other competitors in its price range still used 8-bit microprocessors.
The Pyūta Jr. was a console version of the Pyūta, released in April 1983, and similarly was only sold in Japan.
In Japan, Tomy set a sales target of about 90,000 units and ¥5 billion revenue for the first year by selling Pyūta to elementary and junior high school students as a "drawing computer", having nearly 40,000 units shipped in its first 4 months as of August 1982. However, sales fell sharply when Nintendo released Family Computer (later deployed as Nintendo Entertainment System) in 1983 as a cost-effective option. In February 1985, Tomy ceased its production and withdrew from the market. As of May 1984, a total of 120,000 units were shipped for domestic and export use in Japan.
In the other hand, the Tutor did not sell well against the ZX Spectrum in the UK and the Commodore 64 in other countries outside Japan. It ended up being removed quickly from the market and replaced the following year by the Pyūta mk2 with a standard mechanical keyboard instead of the original "Chiclet"-style keyboard. However, the new model seems to have been sold only in Japan, and even then only for a short period of time.


Game Over II

Game Over II (known as Phantis in Spain) is an action game developed and published by Dinamic Software in 1987 for the ZX Spectrum, MSX, MS-DOS, Amstrad CPC, Commodore 64, and Atari ST.
Gameplay.
"Game Over II" is a mix between a scrolling shoot 'em up game (similar to "R-Type") and a platform game (similar to "Turrican"). There are four "phases" with six levels each. Some versions of the game were split into two parts due to size restrictions.
Plot.
In the original Spanish version ("Phantis"), the player controls Commander Serena on a mission to rescue her expedition partner captured on Moon 4 of the SOTPOK System, better known as the world of Phantis. The English-language version ("Game Over II") takes place immediately after the events of "Game Over", where Arkos, the hero of the rebellion, is nowhere to be found. After it has been discovered that he has been imprisoned on the jail planet Phantis by the heirs of the empress Gremla, Major Locke is chosen for the rescue mission. Other than the graphical change of a female player character to a male player character, the game itself is largely identical in both versions.
Release.
Although originally released as an independent game under the title "Phantis", it was retitled as a sequel to "Game Over". The Atari ST version was never published in Spain and only exists with the "Game Over II" title. The game's promotion included an appearance of a model dressed up as Queen Gremla at the trade convention PC Show '88.
Reception.
The game was given generally mediocre reviews. It received the scores of 69% from "Amstrad Action", 55% from "Commodore User", 60-63% from "The Games Machine", and 62% from "Sinclair User". "Amstrad Computer User" gave it a 17/20.
Legacy.
A spiritual successor to "Phantis" featuring a modern take of the characters and setting, titled "Ultionus: A Tale of Petty Revenge", was released in 2014.


VEB Robotron

VEB Kombinat Robotron (or simply Robotron) was the biggest East German electronics manufacturer. It was based in Dresden and employed 68,000 people (1989). It produced personal computers, SM EVM minicomputers, the ESER mainframe computers, several computer peripherals as well as home computers, radios, television sets and other items including a kleingebäckpresse (cookie press).
Divisions.
Robotron managed several different divisions:
On 30 June 1990 the "Kombinat" Robotron was liquidated and the divisions were converted into corporations. In the 1990s these companies were sold, "e.g.", to Siemens Nixdorf, or also liquidated.
Robotron Datenbank-Software GmbH is a company which emerged from one of the former divisions of "Kombinat" Robotron It was newly founded on 23 August 1990, just before German reunification.
Rebranding activities.
Robotron printers were sold in Western Germany as "Soemtron" or "Präsident", and the West German branch of Commodore used some Robotron parts for their printers.
In East Germany, Epson printers were sold under the Robotron brand (but the technical description on the back side was with the "Epson" logo).


Rice Institute Computer

The Rice Institute Computer, also known as the Rice Computer or R1, was a 54-bit tagged architecture digital computer built during 1958–1961 (partially operational beginning in 1959) on the campus of Rice University, Houston, Texas, United States. Operating as Rice's primary computer until the middle 1960s, the Rice Institute Computer was decommissioned in 1971. The system initially used vacuum tubes and semiconductor diodes for its logic circuits; some later peripherals were built in solid-state emitter-coupled logic. It was designed by Martin H. Graham.
A copy of the machine called OSAGE was built and operated at the University of Oklahoma.
Memory.
Memory was implemented using a variety of technologies over the lifetime of the R1. Originally a cathode ray tube or "Williams tube" array, RCA core memory was introduced in 1966, followed by Ampex core memory in 1967. Following those two upgrades, the R1 had reached its full 32k word capacity, although the original electrostatic memory was soon decommissioned due to falling reliability in its old age.
Architecture.
The R1 had seven memory-mapped general-purpose processor registers, each 54 bits in size, in addition to a constant zero register. For memory addressing, seven 16-bit "B-Registers" were used. The program counter was also held in a writable "B-Register". See the table below for conventions and hardware-enforced usage of these registers.


Desmos (graphing)

Desmos is an advanced graphing calculator implemented as a web application and a mobile application written in JavaScript. It was founded by Eli Luberoff, a math and physics double major from Yale University, and was launched as a startup at TechCrunch's Disrupt New York conference in 2011. , it had received around 1 million US dollars of funding from Kapor Capital, Learn Capital, Kindler Capital, Elm Street Ventures and Google Ventures. In addition to graphing both equations and inequalities, it also features lists, plots, regressions, interactive variables, graph restriction, simultaneous graphing, piecewise function graphing, polar function graphing, two types of graphing grids – among other computational features commonly found in a programmable calculator. It can also be used in several different languages.
Users can create accounts and save the graphs and plots that they have created to them. A permalink can then be generated which allow users to share their graphs and elect to be considered for staff picks. The tool comes pre-programmed with 36 different example graphs for the purpose of teaching new users about the tool and the mathematics involved.
A modified version of the calculator has been used in standardized tests, such as the State of Texas Assessments of Academic Readiness test and the Virginia Standards of Learning (SOL). Moreover, activity modules for classrooms can be created through a teacher account, which allow instructors to view students' work and response in real-time.
Another peculiar use of the calculator involves the creation of graphic arts – which involves an elaborated use of curve modelling through equations and inequalities. As of April 2017, Desmos also released a browser-based 2D interactive geometry tool, with supporting features including the plotting of points, lines, circles and polygons.
The name "Desmos" came across the "Greek word Desmos that means link, or connection, or bond"


Amiga 2000

The Amiga 2000, or A2000, is a personal computer released by Commodore in March 1987. It was introduced as a "big box" expandable variant of the Amiga 1000 but quickly redesigned to share most of its electronic components with the contemporary Amiga 500 for cost reduction. Expansion capabilities include two 3.5" drive bays (one of which is used by the included floppy drive) and one 5.25" bay that can be used by a 5.25" floppy drive (for IBM PC compatibility), a hard drive, or CD-ROM once they became available.
The Amiga 2000 is the first Amiga model that allows expansion cards to be added internally. SCSI host adapters, memory cards, CPU cards, network cards, graphics cards, serial port cards, and PC compatibility cards were available, and multiple expansions can be used simultaneously without requiring an expansion cage like the Amiga 1000 does. Not only does the Amiga 2000 include five Zorro II card slots, the motherboard also has four PC ISA slots, two of which are inline with Zorro II slots for use with the A2088 bridgeboard, which adds IBM PC XT compatibility to the A2000.
The Amiga 2000 was the most versatile and expandable Amiga computer until the Amiga 3000 was introduced three years later.
Features.
Aimed at the high-end market, the original Europe-only model adds a Zorro II backplane, implemented in programmable logic, to the custom Amiga chipset used in the Amiga 1000. Later improved models have redesigned hardware using the more highly integrated A500 chipset, with the addition of a gate-array called "Buster", which integrates the Zorro subsystem. This also enables hand-off of the system control to a coprocessor slot device, and implements the full video slot for add-on video devices.
Like the earlier model, the Amiga 1000, and most IBM PC compatibles of the era, but unlike the Amiga 500, the A2000 comes in a desktop case with a separate keyboard. The case is taller than the A1000 to accommodate expansion cards, two 3.5" and one 5.25" drive bays. The A2000's case lacks the "keyboard garage" of the Amiga 1000 but has space for five Zorro II expansion slots, two 16-bit and two 8-bit ISA slots, a CPU upgrade slot and a video slot. Unlike the A1000, the A2000's motherboard includes a battery-backed real-time clock.
The Amiga 2000 offers graphics capabilities exceeded among its contemporaries only by the Macintosh II, which sold for about twice the price of a comparably-outfitted Amiga 2000 additionally equipped with the IBM PC Compatible bridgeboard and 5.25" floppy disk drive (which was important for real-world interoperability at this time). Also like the A1000, the A2000 was sold only by specialty computer dealers. It was originally announced at a price of
The A2000 was largely succeeded by the Amiga 3000 in 1990. The 3000 features fewer options for internal expansion than the 2000 models, so Commodore supplemented the Amiga 3000 with the Amiga 3000T in 1991.
Variants.
The Amiga 2000 was designed with an open architecture. Commodore's engineers believed that the company would probably be unsuccessful in matching the rate of system obsolesce and replacement then common in the PC industry, with new models every year or so. Commodore's approach was to build a single system architecture that could span different models. Commodore was so successful at this that Info magazine judged that the A2000 would not become obsolete "until well after the turn of the century" at the earliest.
The final design was the result of an internal battle within Commodore, which pitted the USA division, who wanted to build a system more like the Amiga 3000 (and 1000), against the German division, which was fresh from the successful introduction of the first Commodore PC-compatible systems and planned to include this capability in the Amiga 2000 from the start. The bottom-line practicality of the German design won out, and the final A2000 shipped with not only Zorro II slots, but a complement of PC standard (for the day) ISA slots.
This architecture was subject to major revisions. The original motherboard was based on the previous Amiga 1000 with the addition of expansion slots, and so suffered all the same limitations. This was soon replaced by the "B2000-CR" version designed by Dave Haynie and Terry Fisher (whose names are printed on the board), which was instead based on the Amiga 500's improved design. The practical differences are that the early 2000 motherboard only has 512 kilobytes of ram installed, cannot be upgraded with newer versions of the chipset, requires the original processor to be removed when installing a processor card, and cannot use a video slot mounted flickerfixer.
The original Amiga 2000 shipped with just a single floppy drive for storage. This was followed up fairly early by the Amiga 2000/HD, which bundled an Amiga 2090 hard drive controller and a SCSI-based hard drive. In 1988, Commodore shipped the Amiga 2500/20, which added the Amiga 2620 CPU card to the CPU slot, a 14.3 MHz 68020, a 68881 FPU, and a 68851 MMU to the A2000, along with 2 MB of 32-bit-wide memory. The A2000's original 68000 CPU remained installed on the motherboard of these machines, but is not used. In 1989 this model was replaced by the Amiga 2500/30, which added an Amiga 2630 CPU card: 25 MHz 68030 and the 68882 FPU with up to 4 MB of 32-bit memory. The A2630 card can also take a memory expansion daughter card, capable of supporting up to 64 MB of additional memory. Commodore built an in-house prototype of this, but never released one.
Amiga 1500.
In 1990, Commodore UK sold a variant of the A2000, the A1500, for £999. The model designation was not officially sanctioned by Commodore International. The A1500 shipped with dual floppy drives, and 1 MB of ChipRAM as standard. Initial units came with Kickstart 1.3 (and thus AmigaOS 1.3), though the Original Chipset onboard includes a later Agnus revision allowing the 1MB of ChipRAM. Early machines were bundled with a Commodore 1084SD1 monitor. Later machines came with the ECS chipset and AmigaOS 2.04. The second floppy drive replaces the hard disk drive. The A1500 has no hard disk drive as standard.
As the only significant difference A1500s could be upgraded into A2000/HDs by addition of a hard disk controller (and associated drive).
There was also a replacement case kit for the Amiga 500 made by Checkmate Digital and also called A1500.
Amiga 2500.
The Amiga 2500, also known as the A2500, similar to the A1500 is not a distinct model, but simply a marketing name for an Amiga 2000 with a different base configuration. The configuration of an A2500 included a Motorola 68020 or 68030-based accelerator card. The accelerator cards used by the A2500 (the A2620 and A2630) were also available separately as upgrades for the A2000. 68030 versions were referred to as A2500/30.<ref name="Amiga2500/30"></ref>
Because the A2500 has a Motorola 68000 on the motherboard that goes unused, the design is not very cost-effective. A project to replace it with a 68020 on-board began, intending to be a Zorro-II-based 68020 machine, but the project eventually became the Amiga 3000 when Dave Haynie sought to include his new Zorro-III bus.
The A2500 remained in production after the release of the A3000, primarily because the original Video Toaster will not fit in an unmodified A3000 case. Until the release of the Video Toaster 4000, the A2500 was the fastest computer available for use with the Toaster.
A further variant called the A2500UX was also available which was supplied with Commodore Amiga UNIX and tape drive.
Technical information.
The majority of A2000 systems shipped with Commodore's Original Chip Set and 1 MB of RAM (512 KB of "chip" RAM and 512 KB additional RAM) and either AmigaOS 1.2 or 1.3. Later revisions shipped with the improved Enhanced Chip Set, 1 MB "chip" RAM and AmigaOS 2.0.
The A2000 shipped with a Motorola 68000 CPU, running at 7.16 MHz (NTSC) or 7.09 MHz (PAL). The CPU can be upgraded to a 68010 by direct replacement. Official and third-party expansion boards, which fit in the CPU expansion slot, feature 68020, 68030, 68040 or 68060 microprocessors. Such upgrades may also accommodate additional RAM, FPUs, MMUs and even SCSI controllers.
Memory capacity varies according to the hardware revision. Certain revisions of the A2000 can be upgraded to accommodate 1 MB of chip RAM by installing an 8372A Agnus chip. Likewise, 2 MB can be accommodated by fitting an 8372B Agnus chip and adding extra memory. There is a practical limit of 8 MB of additional RAM without the use of a CPU expansion card, due to the 68000's 24-bit address bus.
The A2000 brought a new capability to the Amiga line, the Zorro II bus. This expansion bus allows installation of compatible hardware through the AutoConfig standard, such as, graphic, sound, and network cards and Parallel ATA, SCSI and USB controllers.
The ISA slots can be activated by use of a bridgeboard, which connects the Zorro II and ISA buses. Such bridgeboards typically feature on-board IBM PC Compatible hardware, including Intel 80286, 80386 or 80486 microprocessors allowing emulation of an entire IBM-PC system in hardware. The remaining ISA slots can then be used with industry standard hardware of the era, such as, network cards, graphics cards and hard drive controllers. In some A2000 models, the two 8-bit ISA slots can also be upgraded to 16-bit by fitting extension edge connectors.
The video slot presents clocks, all 12-bits of digital video, Genlock signals, and some control lines for use to add-on cards. This allows use of dedicated genlocks, display deinterlacers, and video-switching and effects systems such as NewTek's Video Toaster.


Developer Transition Kit

The Developer Transition Kit is the name of two prototype Mac computers made available to software developers by Apple Inc. The first Developer Transition Kit was made available in 2005 prior to the Mac transition to Intel processors to aid in the Mac's transition from PowerPC to Intel's x64 architecture. A second Developer Transition Kit was made available in 2020 prior to the Mac transition to Apple silicon as part of its initiative to transition the Mac away from Intel to Apple's ARM64-based Apple silicon.
Intel Developer Transition Kit (2005).
During Apple's 2005–2006 transition from PowerPC to Intel processors, the company made available the first Developer Transition Kit (DTK), a prototype Intel-based Mac computer for developers.
During Apple's 2005 Worldwide Developers Conference, then-CEO Steve Jobs emphasized the non-commercial nature of the prototype hardware: "This is a development platform only. This is not a product; this will never be shipped as a product. It’s just for you guys to get started in development. You actually have to return them by the end of 2006. We don’t want them floating around out there. These are not products."
The computer identified itself as "Apple Development Platform" (ADP2,1), and consisted of a 3.6 GHz Intel Pentium 4 processor, 1 GB DDR2 RAM, 160 GB SATA hard disk drive, and optical disk drive in a Power Mac G5 case slightly modified with an altered cooling system. Connectivity included USB 2.0, FireWire 400, and Gigabit Ethernet. Software included Xcode 2.1 and a version of Mac OS X 10.4.1 which runs on Intel's x86 architecture.
The Intel DTK was available to software developers on a loan basis, and Apple required developers to return the prototype computers to the company within a week of December 31, 2006. Apple required developers to be a Select or Premier Apple Developer Connect (ADC) member, with memberships starting at 499 per year and additional requirement to pay 999 to receive an Intel DTK. Apple surprised developers in the end by offering developers a free Intel iMac in exchange for sending back the DTK.
Apple silicon Developer Transition Kit (2020).
Specifications.
At its 2020 Worldwide Developers Conference, Apple announced another Developer Transition Kit (DTK) intended to assist software developers during the transition of the Mac platform to the ARM architecture. Described informally as "an iPad in a Mac Mini’s body," the DTK carries a model number of A2330 and identifies itself as "Apple Development Platform." It consisted of an A12Z processor, 16 GB RAM, 512 GB SSD, and a variety of common I/O ports (USB-C, USB-A, HDMI 2.0, and Gigabit Ethernet) in a Mac mini case. Support for wireless communication based upon Wi-Fi 5 (802.11ac) and Bluetooth 5.0 was included, while Thunderbolt 3 support, built-in to every Mac commercially available as of June 2020, was not included. It eventually appeared in the first three models of Apple silicon Macs, operating in Thunderbolt 3/USB4 mode. The DTK came preloaded with beta versions of macOS 11 Big Sur and Xcode 12.
Performance.
In an interview shortly after the introduction of the DTK, Apple’s SVP of Software Engineering Craig Federighi praised the DTK's performance and contributed to expectations of superlative performance of forthcoming commercial products based upon Apple silicon custom-engineered for the Macintosh platform: “Even that DTK hardware, which is running on an existing iPad chip that we don’t intend to put in a Mac in the future – it’s just there for the transition – the Mac runs awfully nice on that system. It’s not a basis on which to judge future Macs ... but it gives you a sense of what our silicon team can do when they’re not even trying – and they’re going to be trying.”
Conditions of use.
To receive a DTK, developers needed to sign up for a one year membership to Apple's Universal App Quick Start Program, at a cost of 500.
The membership to this program came with a couple of benefits, such as code-level technical support, access to one-on-one labs with Apple engineers and a license to use a DTK made available by Apple, effectively giving access to the DTK on a loan basis.
The device had to be returned to Apple one year after joining the Universal App Quick Start Program, "or as otherwise earlier requested by Apple".
Several conditions of use were attached, including restrictions against disassembling the computer, running unauthorized benchmark tests, or using it for work other than transition-related software development.
Controversy.
The terms of the Universal App Quick Start Program indicated that the program would run for the duration of one year counted from the moment the developer signed up for it, with an option to terminate it early without reason. Additionally, it had a specific provision regarding one of the benefits associated with the program, namely the DTK. The DTK was to be returned within 30 days after the end of the program itself or "as otherwise earlier requested by Apple". Apple had earlier communicated that the DTK was meant to prepare for the launch of the M1 Macs, thereby suggesting that the DTK would be available until the new M1 Macs would be available.
In February 2021 Apple emailed the developers regarding the return of the DTK while keeping the rest of the program and its benefits active until the original expiration of one year. Additionally, Apple indicated in their email that they would provide a discount code for a 200 discount towards the purchase of a Mac with M1 once the DTK was returned. This was an unexpected benefit of the Universal App Quick Start Program since it wasn't promised beforehand or part of the original agreement.
Some developers reacted with criticism to the email. Among them were developers that voiced their unhappiness about their DTK showing issues, making it "unusable", despite Apple's warnings beforehand that the "Developer Transition Kit [was] not fully tested and [was] to be used only for limited testing and development purposes" and that the DTK "may contain errors that could cause failures or loss of data". Others were under the impression that they could use the DTK for a full year, being caught in surprise by Apple's email indicating that they soon had to return the DTK. Many were also indicating that they were unhappy about the 200 discount code offered by Apple, comparing it to when Apple unexpectedly offered developers the option to exchange their Intel DTK for an iMac during the transition from PowerPC to Intel processors, seemingly expecting a similar surprise when joining the Universal App Quick Start Program.
On February 5, 2021, following developer backlash, Apple sent out another email that increased the discount code to US$500 and expanded the discount to be used on any other Apple devices. In addition, the code will now expire at the end of 2021, instead of May.


Microsoft Knowledge Base

Microsoft Knowledge Base was (as of 2020, almost all articles now produce the message : Sorry, page not found) a repository of over 150,000 articles made available to the public by Microsoft Corporation. It contains information on many problems encountered by users of Microsoft products. Each article bears an ID number and articles are often referred to by their Knowledge Base (KB) ID.
kbalertz.com was a website that provided email alerts of new articles, although Microsoft recently has provided a similar service.


Skypix

Skypix is the name of a markup language used to encode graphics content such as changeable fonts, mouse-controlled actions, animations and sound to bulletin board system. The system was written by Michael Cox on the Amiga in 1987, and first hosted on the Atredes BBS system, which was later renamed Skyline. Skypix allowed BBS sysops to create interactive BBS systems with graphics, fonts, mouse-controlled actions, animations and sound.
Skypix used an extension of the ANSI graphics system that added new instructions. The graphics were normally created using Skypaint, which could generate Skypix files directly from a familiar-looking paint program. The files could be placed in the system and any Skypix-enabled terminal program would notice the encoding and recreate the graphics.
The underlying BBS software could be programmed in the ARexx language (a variant of REXX for the Amiga). This resulted in an enthusiastic group of Skypix hobbyists.
Skypix was available only on the Amiga computer, hosted on the Skyline BBS and accessed using the Skyterm terminal emulator. Skypix support was later implemented in JR-Comm by Johnathan Radigan. At one time over a thousand Skyline systems were operating the world over. Amiga inventor Jay Miner himself ran a Skyline system for a time.
With the terminal program JR-Comm, other BBS software programs started to support Skypix. C-Net Amiga Pro BBS Software was one of them. Today there are several of these boards still alive using Telnet. One of these boards still offers Skypix graphics when using JR-Comm.
External links.
[[Category:Network protocols]]
[[Category:Amiga software]]


Verto Studio 3D

Verto Studio 3D is a computer graphics program for 3D modelling, targeted at mobile content generation for touch devices. It is written using the Cocoa Touch API for iOS and using Cocoa for Mac OS X. The product was initially released in 2011 for the iPad shortly after the device was released.


Nikon D2Hs