text:
Tandy 2000

The Tandy 2000 is a personal computer introduced by Radio Shack in September 1983 based on the 8 MHz Intel 80186 microprocessor running MS-DOS. By comparison, the IBM PC XT (introduced in March 1983) used the older 4.77 MHz Intel 8088 processor, and the IBM PC/AT (introduced in 1984) would later use the newer 6 MHz Intel 80286. Due to the 16-bit data bus and more efficient instruction decoding of the 80186, the Tandy 2000 ran significantly faster than other PC compatibles, and slightly faster than the PC AT. (Later IBM upgraded the 80286 in new PC AT models to 8 MHz, though with wait states.) The Tandy 2000 was the company's first computer built around an Intel x86 series microprocessor; previous models used the Zilog Z80 and Motorola 6809 CPUs.

While touted as being compatible with the IBM XT, the Tandy 2000 was different enough that most existing PC software that was not purely text-oriented failed to work properly.

The Tandy 2000 and its special version of MS-DOS supported up to 768 KB of RAM, significantly more than the 640 KB limit imposed by the IBM architecture. It used 80-track double-sided quad-density floppy drives of 720 KB capacity; the IBM standard at the time of the introduction of the Tandy 2000 was only 360 KB.

The Tandy 2000 had both "Tandy" and "TRS-80" logos on its case, marking the start of the phaseout of the "TRS-80" brand.

History
The introduction of IBM's Model 5150 Personal Computer in August 1981 created an entirely new market for microcomputers. Many hardware and software companies were founded specifically to exploit IBM's and Microsoft's new presence as a standard-setter for small computers, and most other established manufacturers shifted focus to it as well.

By this date Tandy/Radio Shack had been in the small-computer market for four years, since its August 1977 introduction of the TRS-80 Model I. The new computer division followed in October 1979 with the TRS-80 Model II—a high-end business-oriented system. In 1983 the TRS-80 Model 4 succeeded the Model III (which itself had replaced the Model I) in the consumer and educational markets. In the business segment the TRS-80 Model 12 and Model 16 succeeded the Model II, adding higher-end features. Thus far Tandy/Radio Shack's computer lines occupied their own niches in the market because of their proprietary system software and applications. Tandy attempted to monopolize software and peripheral sales by not offering third-party products in company stores. Until the IBM PC was introduced, the nearest thing to an industry standard in small computers was CP/M-80; no single manufacturer dominated.

By 1983 the IBM PC, and Tandy's discouraging of third-party products, had halved the company's market share and stopped profit growth. Tandy's motive for moving into the new MS-DOS domain was twofold: to capitalize on the new market, and to leverage sales opportunities afforded by their solid position in small computers. Marketing management believed that many Tandy customers would prefer to stay with Tandy products when (inevitably, it seemed) they made the jump onto the burgeoning IBM/Microsoft bandwagon; it was figured that the company was well-positioned in this regard because of its large base of customers in both the consumer and business markets (with its Z80-based TRS-80 Models I/III/4 and 68000-based Models 12 and 16, respectively). Tandy's large presence as a computer retailer, with several thousand Radio Shack stores throughout the US, was deemed an advantage as well. All other PC manufacturers, especially IBM, relied mainly on sales to corporate accounts, not consumer retail as did Tandy/Radio Shack. Thus the company would become the market leader offering the hottest new trend—affordable 16-bit computers running MS-DOS—directly to the computing public.

Therefore, Tandy would have to produce an IBM-style computer running the emerging industry-standard MS-DOS. The company decided to distinguish it from similar products by producing a better computer. The new machine would be aimed at the mid-price market between high-end consumers and low-end businesses. This was deemed prudent in order not to seriously cannibalize their current product lines serving both market segments. Most other big-name computer manufacturers made the same leap into the PC/MS-DOS market:

Shortly after IBM's introduction of its 286-based PC/AT, one reviewer remarked, "The bottom line is that the Tandy 2000 is still one of the hottest single-user machines on the market, and a full year after its introduction, its superiority remains unchallenged."

Applications software compatible with the MS-DOS operating system would run properly on the Tandy 2000. This means that the software had to access the computer's hardware (particularly the video display) strictly through calls to the operating system's BIOS. However, programs written to run under the similar PC DOS operating system on an actual IBM PC computer often bypassed calls to the operating system because the IBM BIOS was poorly designed and implemented. To function with adequate speed of execution, and to perform operations not provided for by the IBM BIOS, applications programmers often coded their programs to directly address the hardware of the IBM PC. Therefore any computer such as the Tandy 2000 that had hardware that differed in its details from an IBM PC would not execute programs the same way, which most often manifested incorrect results by those programs.

Tandy engineers tested one hundred of the most popular PC programs and half were found to be incompatible with the 2000's hardware. Tandy's marketing department failed to appreciate that similar non-compatible computers from DEC, TI and Eagle were not successful. Its strategy of offering a high-performance PC was the origin of the Tandy 2000's technical specifications. Some of the rival computers improved the PC hardware and matched the Tandy 2000 in one or two dimensions, but none offered across-the-board enhancement. Except as noted, they ran MS-DOS but were incompatible with the IBM PC at the hardware level. The copycat computers competed primarily on lower pricing and, like Tandy, exploiting their installed customer bases.

Tandy described the 2000 as having a "'next generation' true 16-bit CPU", and with "More speed. More disk storage. More expansion" than the IBM PC or "other MS-DOS computers". While admitting in 1984 that many MS-DOS programs did not support the computer, the company stated that "the most popular, sophisticated software on the market" was available, either immediately or "over the next six months".

Two models of Tandy 2000 were introduced: a dual-drive floppy-only model for US$2750 and the 2000HD with a single floppy drive and a half-height 10 MB hard drive for US$4250. The dual-floppy model had 128 KB RAM and the hard-drive-equipped 2000HD had 256 KB. For comparison, at this time the low-end TRS-80 Model 4 with two floppy drives cost US$1999 and the high-end Model 16 with two floppy drives cost US$4699.

Tandy executive Ed Juge said that within six months Tandy realized that it had erred with the 2000. By early 1985 InfoWorld reported that Tandy introduced the Tandy 1000 because it "found that the market prefers true PC compatibility" to the 2000's incomplete compatibility. The Tandy 2000 received a lukewarm welcome by the market and the computer press because of its inability to run most popular MS-DOS applications. This was not anticipated by Tandy because, at the time, it was accepted practice for new software to be created for each new computer that came to market. This is also why so many of the other PC-style computers by other manufacturers were not hardware-compatible with the IBM PC. Though the company supported the machine with hardware add-ons and software tailored specially for it (including bestsellers like Lotus 1-2-3 Release 1A and AutoCAD), the computer failed to gain popular acceptance and was never developed further. It would not be until late 1986, with the introduction of the Tandy 3000, that Tandy offered a PC-style computer with performance comparable with the Tandy 2000.

The Tandy 2000 was marketed through early 1988 with continual price cuts. Eventually they were closed out for $999 and the remaining unsold computers were converted into Radio Shack store operations terminals (which, coincidentally, had been one of the backup plans for the original TRS-80 Model I).

Specifications

 * 8 MHz Intel 80186
 * 128 KB RAM (expandable to 256 KB on CPU board with two banks of type 4164 DRAMs)
 * One or two 720 KB $5 1/4$-inch floppy drives
 * 10 MB MFM hard drive (upgradable to two 32 MB hard drives, or two 80 MB drives with ROM modifications and third-party software)
 * 8-pin DIN monochrome monitor port
 * DB-25 RS-232 serial port
 * Proprietary parallel printer port (required adapter cable to connect to a Centronics-port printer)
 * Optional 8087 math coprocessor board plugged directly into CPU board

Four card slots on the back could accept expansion boards without any need to open the case, using a rail system. Available expansion boards/cards included:
 * 256 KB RAM card (one or two could be added for 768 KB total; each card had two 128 KB banks of nine 64 KB DRAM chips, type 4164)
 * Monochrome Graphics Card with optional color graphics expansion (must occupy bottom slot; Tandy monochrome VM-1 or color CM-1 monitor required)
 * Serial I/O expansion board providing four RS-232 ports (proprietary driver software required)
 * Hard disk controller card with two ribbon cables to an outboard hard drive up to 35 MB capacity
 * External 10 MB Disk Cartridge System
 * Mouse/Clock controller, including mouse controller and battery-backed real-time clock
 * ViaNet Network card (ARCNET BNC)

Compatibility issues
The Tandy 2000 was nominally BIOS-compatible with the IBM XT, so well-behaved DOS software ran on both platforms. However, most DOS software of the time bypassed the operating system and BIOS and directly accessed the hardware (especially video and external ports) to achieve higher performance. This rendered such software incompatible with the Tandy 2000.

Graphics
The base-model Tandy 2000 supported only a text-mode display in monochrome. The Tandy VM-1 monitor used the 8-pin DIN video port on the computer's rear panel. The text-mode address space was in a different location but third-party memory-resident software hacks remedied this by copying the PC-compatible text-mode memory to the Tandy 2000's text space at a rate of 5–10 times per second. This sometimes caused some choppiness in the display. It produced a fast text display rate—often too fast to read—but the 'HOLD' key on the keyboard could be used to pause text output.

The bit pattern for each text character's raster image was maintained in RAM and could be modified by the user. With clever programming the display's ability to present fine lines provided by the 640x400 screen resolution could be accessed in text mode even without the optional graphics board.

The display was upgradable to support pixel-addressable graphics via the Tandy 2000 Graphics Adapter, a circuit board that fit into an expansion slot. It had its own connector for the monochrome VM-1 monitor; the video connector in the rear-panel cabinet was disabled when this expansion board was installed. The graphics resolution was 640x400 and supported high intensity pixels.

Color capability was provided by the Color Graphics Option, which was a set of chips that were inserted into the empty sockets on the monochrome Graphics Adapter provided for this purpose. Resolution for the color board was the same 640x400, non-interlaced, and eight colors out of a palette of sixteen available colors were displayable on the Tandy CM-1 monitor (~$799). This was a particularly high-resolution and colorful display for its day. The CM-1 accepted, as input from the color graphics board, digital RGBI signals (indicating separate Red, Green, and Blue signals with an Intensity bit). CGA compatibility was hit-or-miss.

There were only three non-Tandy monitors that worked with the Tandy 2000 graphics card, all of which are long out of production. These were the original (1986–88) Mitsubishi Diamond Scan, and the NEC Multisync and Multisync GS (grayscale). The required horizontal scan frequency for the Tandy 2000 is 26.4 kHz. Modern flat-panel multisync computer monitors cannot sync at frequencies below 30 kHz. The CM-1 monitor is also digital RGB; all modern CRT monitors are analog-only.

Media
The Tandy 2000 used quad-density 5.25" floppy disks formatted at 720k. This format (80-track disks at the double-density bitrate) was not used by PC-compatibles, although some CP/M machines and the Commodore 8050/8250 drives had them. Normal PCs of the time had 40-track double-density floppy drives and could not read quad-density due to the drive heads being too wide to read the narrower tracks. 1.2 MB 5.25" drives (introduced on the IBM AT) could read quad-density disks because they were 80-track and had thinner heads. Various utility programs for DOS existed that could read nonstandard formats such as the Tandy 2000's disks. Much like 1.2 MB drives, the Tandy 2000 had problems reliably writing 360k PC disks due to the smaller heads not completely erasing the tracks and causing 40-track drives to become confused by residual magnetic signals on the outer edge of the track. Tandy distributed the computer with a utility called PC-Maker that would read and format 40-track disks in the 2000s 80-track drives, and were readable in drives on ordinary PCs.

The floppy controller on the Tandy 2000 is compatible with 3.5" double-density 720 KB floppy drives.

As of May 2019, there is an abandonware site (winworldpc.com) that has available for download a disk image for the latest version of MS-DOS for the Tandy 2000. It includes instructions for using the IBM 1.2 MB 5.25" disk drive (80-track) to create a system disk bootable in the Tandy 2000 5.25" drive. This procedure can also be used to create a bootable 3.5-inch system disk using an ordinary 720 KB 3.5-inch PC drive; this will boot a Tandy 2000 if its 5.25" boot drive has been replaced with a double-density 720 KB 3.5 inch PC drive.

Keyboard
The keyboard was a new design made for the Tandy 2000. It would later be the same keyboard shipped with the Tandy 1000 and its successors.

The arrangement of the function keys was changed from that of the IBM PC/XT, which had ten on the left side of the keyboard in two columns of five. Tandy was among the first PC manufacturers to change this to the modern arrangement of twelve function keys arranged horizontally across the top. IBM gave a nod to the new standard by using this arrangement for the Model M keyboard.

Serial port
The serial port hardware was completely different from the PC/XT's. PC-compatible terminal emulation software had to either access the serial hardware strictly through BIOS or use a FOSSIL driver, a software wrapper that virtualized the serial hardware (see also DEC Rainbow), to run on a wider variety of hardware.

Several terminal programs were available for the Tandy 2000, making it possible to log in on BBSes, e-mail, and other remote systems.

Operating system
The Tandy 2000 required a specific version of MS-DOS that would run only on this machine. Standard MS-DOS or PC DOS (for generic IBM-compatibles) would not run on a Tandy 2000. It was standard practice and Microsoft's expectation at the time that a customized version of MS-DOS would be prepared for each different machine, with I/O drivers designed for the hardware of that model. The highest version of DOS that Tandy Corporation released for the Tandy 2000 was 2.11.03, with a few minor third-party patches after the fact. A modified version of Windows 1.0 was able to run on the Tandy 2000.

MS-DOS for the Tandy 2000 resided entirely in RAM, unlike on IBM PCs where the BIOS portion of the OS resided in ROM. The complete MS-DOS system (BIOS and BDOS) occupied about 53 KB of RAM. This means that the RAM required to run applications on the Tandy 2000 was a little greater. However, the Tandy 2000 fared better in comparison to the later IBM PC-AT in that the AT was required to run MS-DOS version 3.x in order to operate its 1.2 MB floppy drives and hard drive. Version 3 of MS-DOS was rather larger than Version 2.x running on the Tandy 2000. It also proved advantageous that the Tandy 2000's OS resided entirely in RAM and therefore could be updated and hacked with rather less effort.

The Microsoft BASIC interpreter was supplied with the computer. It was highly customized for the Tandy 2000 hardware, particularly its high-resolution color graphics. Although IBM produced the Enhanced Graphics Adapter a little more than a year later (October 1984), the Microsoft BASIC interpreter would not support its greater color and resolution capabilities until 1988.

Tandy/Radio Shack produced print advertising featuring Bill Gates of Microsoft extolling the superior performance of the Tandy 2000 and how it was advantageous in Microsoft's development of Windows 1.0.

Software
Software packages that were released for the Tandy 2000 included WordPerfect 4.2 (WP5.1 could work with software patches), Lotus 1-2-3, Ashton-Tate's Framework, DBase, MultiMate, Pfs:Write, AutoCAD, Lumena (from Time Arts) shareware office programs, and the complete line of Microsoft language products. Microsoft released a version of Xenix for the Tandy 2000 (used with Western Digital's ViaNet network card, distributed by Tandy).

Better BASIC for both the Tandy 2000 and the PC was used to write BBS software for the Tandy 2000 and later ported to the IBM PC. Radio Shack's DeskMate was also used with the Tandy 2000 and the Tandy 1000.

MicroPro's Wordstar (versions 3.3 and 4.0 only) would run on the Tandy 2000 provided the user ran the WINSTALL installation utility and, when prompted for the type of video display to be used, selected "ROM BIOS". While this would result in a functional installation, none of the T2000's special features would be operative (except for increased speed and storage).

The only version of Lotus 1-2-3 offered for the Tandy 2000 was Release 1A. This was customized to take advantage of the unique hardware of the computer, including its full 768K of RAM, high resolution color graphics, and two extra function keys.

Release 1A's executable code was about 60 KB smaller than the later Release 2, which provided greater macro programming facilities. This extra space for data, with the additional 128 KB of RAM available to a fully expanded Tandy 2000, made it possible to construct larger worksheets than later PCs running Release 2 (until the advent of machines with Expanded memory). For nearly two years following its introduction, the Tandy 2000 was the top performer for processing large models in Lotus 1-2-3.

The Tandy 2000's 720 KB floppy drives were a distinct advantage for running Lotus, because they were large enough to store even the largest worksheets on a single diskette. This is in stark contrast to the IBM PC and XT with 360 KB floppy disks. In order to store the largest worksheets, a PC user would have to split them and save them on two disks—and then recombine them in memory later. Although the XT had a hard drive that could store large Lotus worksheets in a single file, a user could not rely on a single storage device for permanent storage of important data files; again they would be forced to segment worksheets for storage on separate disks. The Tandy 2000's large-capacity floppy disks made backup maintenance relatively effortless.

End of life
After Tandy dropped support of the Tandy 2000, a group of users formed the Tandy 2000 Orphans, with software reviews, software and hardware hacks, and a shareware/freeware repository. It was discovered by amateur programmers that many commercial MS-DOS applications needed only minor modifications to function on the Tandy 2000's unique hardware.

There was also a BBS based in Texas that had an extensive library of compatible software available for download; neither the BBS nor its web-based descendant is active today.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Tandy 2000


text:
Talk:USS America (CV-66)

fuel?
Diesel and/or Heavy oil powered ?--— ⦿⨦⨀Tumadoireacht Talk/Stalk 03:43, 4 January 2022 (UTC)

Written like a novel
The article is written like a story or novel, not like a factual encyclopedia article. It should be reviewed and redone. 77.224.166.216 (talk) 12:16, 19 March 2022 (UTC)

Missing Information
Hello. I am relatively new to this. My Grandfather served on that ship and worked on the jets on there. Why is there nothing on the F-14s on there? It should be, like the other guy said, redone and should include the type of jets it carried. I can try to provide as much information as I can, but no garuntees. 64.130.102.153 (talk) 18:13, 16 September 2022 (UTC)

title: Talk:USS America (CV-66)


text:
Wikipedia talk:MediaWiki namespace/Archive

top
I like this stuff! If I understand this right, do we get to have like substitute-text with $1 and $2 and stuff? How is it done? (Perhaps I should have asked this first before creating MediaWiki:Vio :/// ) Dysprosia 06:38, 6 Dec 2003 (UTC)

 * I don't think there is a way to specify what $1 and $2 are, so the vio page isn't going to work. Also, that might be a bit too long to be allowed. Angela. 06:57, 6 Dec 2003 (UTC)~

 * Darn. Maybe it can be broken up, something like [site]... ? Otherwise I'll get rid of it... Dysprosia 07:02, 6 Dec 2003 (UTC)

 * You could but I'm not convinced that makes things easier than they are now. I'd find it quicker to go and copy the boilerplate from somewhere than to remember and type three different SUBST messages, but if you think it would be easier then you could make them. Angela. 07:08, 6 Dec 2003 (UTC)

 * I think I'm gonna delete it until a developer makes happy-vfd-substitutey-stuff :) Dysprosia 07:14, 6 Dec 2003 (UTC)

 * I was also thinking about how it would be if we could specifyi parameters, like { {SUBST name|param1|param2} } in the article text, and use { {$1} }, { {$2} } in the message definitions. With some expansion it could become a useful templating tool for many things. But, that would probably require changes to software to keep it fast enough. OTOH, if the maximum number of parameters were to be kept down to a reasonable number for use in messages (say 5), it shouldn't be too hard to do. Zocky 19:22, 11 Dec 2003 (UTC)

-- Since this page is almost entirely about MediaWiki and not really about anything specific to Wikipedia, I think this page should be moved to meta and become part of the MediaWiki User's Guide. --mav 07:36, 6 Dec 2003 (UTC)

You're right. I've moved most of it to m:Meta-Wikimedia:MediaWiki namespace. Angela. 07:43, 6 Dec 2003 (UTC)

 * Oh, I thought you would just copy it to meta. Are you going to delete How to edit a page as well? -- Tim Starling 00:55, Dec 7, 2003 (UTC)

 * Yes. I think the aim is to move all the help pages over to Meta. If they are kept in both places, people tend to edit one and not the other and they end up out of sync. Angela. 01:07, 7 Dec 2003 (UTC)

 * I don't think that How to edit a page should be moved to meta, only copied. The copy on meta should be more general and the one on wikipedia should be more wikipedia-specific, above all in examples. Also, I don't think new users should of wikipedia should be immediately bothered with the whole notion of meta, interwiki links, etc. Zocky 19:13, 11 Dec 2003 (UTC)

 * Powerful and handy stuff, now if only I could figure a way to keep track of all of them (that user's guide will become more important, no doubt). Or maybe I'll just wait until Angela adds them all to her stash :) Dori | Talk 00:07, Dec 7, 2003 (UTC)

 * I've been keeping a list at MediaWiki custom messages but it does depend on people remembering to add any new ones they create. Angela. 01:10, 7 Dec 2003 (UTC)

Hmm, this is powerful. Where do we discuss changes? Martin 04:23, 7 Dec 2003 (UTC)

 * I would suggest Wikipedia talk:MediaWiki custom messages to discuss changes to custom messages and Wikipedia talk:MediaWiki namespace text for changes to the default messages. Angela. 04:32, 7 Dec 2003 (UTC)

msg considered harmful
Is this a good place to rant about the use of these " " things? I don't want to discuss changes to custom messages or changes to the default messages, but just the policy about their use. I thought about bringing this up back in January, but then decided it wasn't that important. But now they're getting out of control, and I've changed my mind.

Basically, I think that these " " things go completely against the wiki idea: that anyone can come along to a page, click on "edit", and change the text however they want. Nowadays, if they find a page full of text and click on "edit", they'll quite likely get an edit box that just contains something like "    ", with the text that they wanted to edit nowhere to be seen. When someone tries to edit an article, they should be able to see the text they are editing, shouldn't they? Isn't that a fundamental point about what a wiki is? The fact that what is shown in the displayed article bears so little resemblance to what is in the edit box is just going to confuse most people, and turn them away from Wikipedia. Even if " " doesn't put them off completely, unless they are computer geeks who are intrigued by goobledegook, they won't know what to do with it. There is no intuitively obvious way of getting from a "msg" in an edit box to editing the message itself. Maybe someone is going to come up with a solution to that, involving yet more intrusive links all over the pages, but we have too many of them already. Wikipedia is a mess...

The place seems to be turning more and more into a haven for computer geeks, and becoming less usable for the vast majority of people. And this is a bad thing! -- Oliver P. 08:41, 14 Mar 2004 (UTC)

 * I agree. I thought would be useful as a shortcut, but that people would avoid msg for basically the reasons you outline. I was quite surprised that so many people jumped on the bandwagon, with so little dissent. Now people want argument substitution as well. I'm afraid that this will make wikitext look like a programming language. -- Tim Starling 09:52, Mar 14, 2004 (UTC)

 * Hurray! I thought everyone would disagree. :) I have nothing against programming languages, but please, not for editing encyclopaedia articles... -- Oliver P. 11:15, 14 Mar 2004 (UTC)

Well! No-one has disagreed with my "msg considered harmful" thesis. Can I take it that no-one has any counterarguments? Can I take this as a consensus? ;) If no-one can answer my arguments, I might just start going round replacing all the "msg" tags with "subst" ones... -- Oliver P. 00:37, 16 Mar 2004 (UTC)

It's just that this has been discussed before, and probably no one really feels like re-hashing it all again. Also, you haven't given people enough time to respond. Old arguments should be somewhere on Wikipedia talk:MediaWiki namespace text Dori | Talk 00:43, Mar 16, 2004 (UTC)

The previous argument is at Wikipedia talk:MediaWiki namespace text/Archive 1. User:Tim Starling

 * Thanks. I'll go and read that now... -- Oliver P. 02:32, 16 Mar 2004 (UTC)

Okay, I've read it. The first point brought up there, about possible mass vandalism, is interesting. On the one hand, I don't see vandalism of MediaWiki pages as a special problem, because there must be people watching them, and even if not, the vandalism will show up in many articles, so it would quickly be noticed and reverted in the usual way. On the other hand, I don't like the idea that an article can now change (whether by vandalism or not) without it showing up as a change to the article itself, either on "Recent changes" or on people's watchlists. I want to know what's happening to articles without having to remember which messages they contain and watching those message pages too.

Eloquence's point about easy modification of messages in one fell swoop is valid, but I don't think it's especially important. Messages for stubs, Vfd, disambiguation, etc. are unlikely ever to change radically, and even if they do, editors can always just wait until they next edit the article, and re-"subst" the message. Piecemeal improvement over a long period of time is the norm in a wiki, and for most articles lacking up-to-date messages will be a small problem compared to their usual incompleteness, NPOV problems, and the like. They'll have to be edited many times for those things anyway, so one more thing to edit them for is, I think, trivial in comparison.

The next point, about finding stubs, seems to be only a technical matter rather than a policy one, and I have no comment on that. Have I missed any other points?

It seems that no-one brought up the main point I'm making, which is that the "msg" concept takes away the whole basic idea (and indeed the joy) of a wiki, enabling anyone to see and edit the full text of an article with just one click. It makes the editing process a lot more counterintuitive, difficult to learn, and generally off-putting, and all for what I consider to be a very small benefit. Now, any comments...? :) -- Oliver P. 03:15, 16 Mar 2004 (UTC)

 * It's possible, and probably should be recommended, to explain in an html comment how to edit the msgs contained in an article. Other people argue for msgs rather than large infoboxes on articles, as they believe that a big chunk of table html or wiki table markup is more disconcerting for a newbie to find when they click "edit this page".  I think you're dismissing the importance of central editability.  Many of these messages (article series etc) which need to be edited and maintained appear on hundreds of pages each.  No one wants to have to correct hundreds of pages each time they need to make a change.  fabiform | talk 03:41, 16 Mar 2004 (UTC)

 * Oliver, I think you have some good points in your arguments. I was (and am) in favor of using msg in limited ways. For example, I think stub:msg makes perfect sense. Same thing for msg:disambig. These are long-term, short messages where consistency is definitely desireable.

 * As for the rest, I'm not certain. We do want to keep Wikipedia simple to edit, and based on that alone, your argument has merit.

 * Your argument that using msg is completely against the "wiki idea" is much less compelling for me. The objective/goal of Wikipedia is the creation of a great, free encyclopedia. As far as I'm concerned, whether it is in keeping with the "wiki idea" is a secondary question. The first question is whether the feature provides a net positive contribution to the making of a great, free encyclopedia.

 * In many cases, consistency from article-to-article (especially in a series) is very desireable in an encyclopedia. Given the collaborative nature of Wikipedia, some aspects of that consistency will change over time. msg is an important method of maintaining such consistency.

 * Wikipedia is breaking new ground, given its size and its objectives. We may need to tweak how msg is being used, but I'd be firmly against abolishing it.

 * -Rholton 03:56, 2004 Mar 16 (UTC)

But it is actually easier to edit using messages. You edit one page, and the change happens across hundrends, or thousands of articles. Messages shouldn't be used for content, but rather for small messages and tables. Can you imagine redoing all sort of pages just to make a small change. People would be opposed to it, just because it's become "convention". Also for pages that use tables, not only would you have to paste all the table code in the articles where it's used, but you would have to customize them (i.e. bold the current link, instead of having it done automatically). Eventually, there could be links in articles to edit the messages that are contained in it, and perhaps have a link to their histories as well, but right now messages a too useful to be gotten rid of. Dori | Talk 04:01, Mar 16, 2004 (UTC)

 * I've only been around a very short time and I picked up on how msg worked very easily. I haven't seen people asking many questions about them either. I think the standard messages like VfD, stub, etc. are all more useful as msg than as subs. I do not consider those to be part of the content of an article. I don't see it as a problem if new users are not able to edit that part of an article -- it's not supposed to be edited.

 * On the other hand, it seems some messages are getting more elaborate and I don't even know anything about parameterized messages. I'd have to see examples before I ventured an opinion about them. It seems that if someone wanted to edit something in a msg, they would ask about it, either on the talk page or the Village Pump. Which is probably a good thing, no? I mean, if the message is used for purposes of standardization, then presumably (I would hope) that there had been some discussion and consensus about the content of the message before it is put into widespread use. And if someone wants to make changes to it, it should be discussed first, no? Or is that contrary to the spirit of Wiki as you see it? Bkonrad | Talk 04:09, 16 Mar 2004 (UTC)

msg has exactly the right effect for newbies; it encapsulates material that they probably cannot edit correctly, and for which there are a hundred ways to get it wrong. A "good" article nowadays needs annotations and navigational aids of various sorts, and if you subst into each article individually, all those substs are going to get randomly changed, because few people will know that there are many other articles with the same boilerplate. (We have far more articles than most people realize; even oldtimers are creating dups without realizing it.) Stan 14:00, 16 Mar 2004 (UTC)

Msgs are not actually a problem if we understand that it should be used for categorisation and navigation, not for content. We have far more un-wiki stuff to take care about, like table syntax. That one is hairy. — Sverdrup 20:32, 16 Mar 2004 (UTC)

Proposal for a technical fix
Perhaps a good technical fix to these concerns would be to add a "section edit" link associated with each msg: that takes you directly to editing the MediaWiki: page that msg comes from? For example, instead of just

''This article is a stub. You can help Wikipedia by expanding it.''

you'd see

''This article is a stub. You can help Wikipedia by expanding it.'' [edit]

Of course, when you just clicked "edit this page" for the page as a whole, you'd still see, but it'd be pretty simple to just click cancel and then the section-edit link instead. Bryan 05:58, 16 Mar 2004 (UTC)

 * Such an edit-link seems to invite to vandalism. We could do without.--Ruhrjung 09:16, 16 Mar 2004 (UTC)

 * Vandalism has consistently been cited as a particular concern for MediaWiki: namespace pages. However since they have been introduced there has been virtually zero vandalism (and yes there are non-protected pages, but not enough). As Oliver points out above, such vandalism would be noticed and corrected even faster than regular vandalism. I think something like this would be worth a go. Of course the top of the edit box would have to say "WARNING: This is a transcluded message, changing it will affect all the pages on which it appears" or something. Pete/Pcb21 (talk)

 * Better to have a list generated when you edit the page saying "Messages transcluded in this article:" with a button or something to jump to the appropriate MediaWiki: page. This came up on the Village Pump a while back, but I haven't time to find where it was archived at the minute.
 * That said, I will weigh into the conversation above later on how often msg should be used rather than subst. - IMSoP 10:55, 16 Mar 2004 (UTC)

 * That's an interesting one, I hadn't heard it before. Although it's my opinion that "transclusion" is just a silly made-up word which means the exact same thing as "inclusion", as a programmer understands the word. Any thoughts on the formatting and placement of this list? -- Tim Starling 11:45, Mar 16, 2004 (UTC)

First, the syntax of these messages will soon change. Instead of, you will write. The page itself will no longer reside in the "MediaWiki:" namespace, but in the to-be-created "Template:" namespace (some have also suggested "Block:" or "Module:").

Second, the goal of this syntax is ultimately to make Wikipedia more newbie-friendly, and to increase the joy of editing. This is especially true for parametrized messages with name/value combinations. For example, you would be able to say something like:

You would get a nice table with the parameters inserted in the right places, making it possible for any newbie to easily alter the values without dealing with the layout.

This syntax is entirely made up. The system currently in development uses numbers instead, so you have to pass parameters in the order in which they appear in the template, and you don't know what aspects of the template you are changing unless you look at it. This is bad usability, but it was easier to code.

Second, yes, we need a better way to edit these templates. Preferably, that method should only be accessible if the page itself is unprotected. We don't want to provide easy-edit links for the messages on the Main Page, because we want these unprotected.

A dropdown box on the edit page would make the most sense. It would look roughly like this:

Templates used: [ country ....... ^ ] [edit]

It would only be shown if at least one of the templates in question is unprotected, or if the user has sysop status. (This requires a DB look-up, but should be within acceptable limits.)

The proper position for this dropdown box would be at the footer of the edit page, below even the copyright notice. There should be a separate notice below the dropdown to the effect that edits to the page itself will be lost.—Eloquence 20:34, Mar 16, 2004 (UTC)

 * Hey as long as this is in development, I'd like to mention that links would be preferable to dropdowns since you can't open the dropdowns in new tabs. Dori | Talk 21:24, Mar 16, 2004 (UTC)

 * Hmm, I hadn't thought of that, Dori. Useful though it would be, it would potentially be a lot of links down the bottom, which might prove a bit ugly. Have it drop-down by default, but flattenable in preferences? You can always clone the tab first, and then use the form button, of course; or have an option to open in new window, and force your browser to always use tabs not windows somehow.

 * As for the Template: syntax, I would really like to see the paramaterisation markup got right first time. It wouldn't be that hard to do, surely? I've never used PHP before, but in Perl, you could simply do
 * (where  is whatever the user put after  )
 * And you'd have a hash containing all the appropriate named variables. For instance   could point at Template:Foo, in which $bar was replaced by   in the PHP rendering.
 * If you wanted to be clever and not die if users put an = in their arguments, you could have a more complex regex. Or just do two splits, first on /|/ then on /=/. It would be a lot easier to read the wikisource if implemented this way.
 * - IMSoP 22:37, 16 Mar 2004 (UTC)

Good God, it's all a hundred times worse than I thought. "[The] goal of this syntax is ultimately to make Wikipedia more newbie-friendly, and to increase the joy of editing." You can't seriously believe that, can you? Every increase in complexity discourages more people. I am horrified at the direction that you are pushing this project in. This has got to stop. -- Oliver P. 13:42, 22 Mar 2004 (UTC)

 * I don't entirely agree with Oliver as I do see many places where msg: is useful, but I can understand his concerns. I think if the syntax is going to get more complicated, and start to look like the  example given above, then perhaps they should appear in a separate edit window from the main text. If they are used for meta data, is there a need for them to appear to people who just want to edit the actual content of the page? Would splitting the edit window address the concerns of confusing newbies? Angela. 00:23, Mar 24, 2004 (UTC)

 * I don't know. I think if the template system is implemented and used wisely, it could actually be a lot less ugly than messes of table syntax, for a start. I mean, seems pretty "transparent" to me. Maybe I've just spent too long in geekdom - does x=y not have obvious meaning to "Joe Internet User"? - IMSoP 00:31, 24 Mar 2004 (UTC)

 * Your example tells the user that this is the information for the country info box, that Germany is a country, that its population is 82 mil., etc. It doesn't tell them how to change the formatting, how to add extra rows, where in the box the "name" parameter is displayed and what will happen if it is changed, etc. To edit Wikipedia effectively and confidently, the user must learn the template syntax completely. This is intimidating. -- Tim Starling 03:46, Mar 24, 2004 (UTC)

 * Can't something be done so that expandability becomes a little more automatic? For example, using the above, tweaked a little
 * and say, I want to add the fact that it's national food is potatoes (I don't know if it is, but let's just say ;)
 * So...
 * So instead of shielding the user absolutely from the MW message, the MW message becomes a skeleton for the formatting, which becomes extensible as desired. Dysprosia 07:30, 24 Mar 2004 (UTC)
 * So instead of shielding the user absolutely from the MW message, the MW message becomes a skeleton for the formatting, which becomes extensible as desired. Dysprosia 07:30, 24 Mar 2004 (UTC)
 * So instead of shielding the user absolutely from the MW message, the MW message becomes a skeleton for the formatting, which becomes extensible as desired. Dysprosia 07:30, 24 Mar 2004 (UTC)

 * Out of interest, what is the reasoning behind selecting the syntax rather than  ? It seems to me that the latter has several advantages, since it makes it obvious to the user that this is in fact a template and points to the exact location where that template lives. What's more, if we have a drop-down list at the bottom of the page (which does seem rather a good idea) saying "the following templates are used on this page", it would be rather good to give the user a strong clue as to what a "template" is. If the syntax simply consists of punctuation, they will have to guess based on spotting the same name in the article and the list. - IMSoP 15:31, 25 Mar 2004 (UTC)

 * requires the pressing of more keys. In the CVS version, it's obvious where goes because if Template:Thing doesn't exist, a broken link to Template:Thing will be displayed. So it'll only be obscured until the user makes a typo. Also, it's been proposed to provide links to all linked templates in the edit screen. Note, however, that  will be valid syntax. The new syntax allows the user to designate the namespace. ,  ,  , etc. are allowable. The caveat is that changing the text of an inclusion only clears the cache of the referring articles if the included page is in the Template namespace. -- Tim Starling 00:07, Mar 26, 2004 (UTC)

Empty talk page messages.
Please see Wikipedia talk:Talk pages and MediaWiki talk:Noarticletext. These are 2 different messages, one when going directly to the empty talk page, the other when they click on the red "discussion" link. -- Jeandré, 2006-04-24t12:20z

Undo-failure
The current content of MediaWiki:Undo-failure is:
 * The edit could not be undone due to conflicting intermediate edits.

I propose to change this into:
 * The edit cannot be undone due to conflicting intermediate edits.

(Underlining for highlighting the difference only.)

Rationale: In the situation in which the user gets to see this message, the edit would not yet have been undone anyway if there had been no conflict; it is only by then saving the page that the edit will be undone, if such is possible.

--Lambiam 12:48, 8 March 2008 (UTC)

Show/hide function
Hi: How could I use the show/hide function (where is that template btw?) to show or hide multiple panes in the list of letters in the "Dining Late with Claude La Badarian" article. I would like to hide by default all of the panes that show the References section in the list of letters at the bottom of the article, and by one click to show them all. This is of some importance since by default I want the list of letters to be shortened. I appreciate any help you could offer.Manhattan Samurai (talk) 21:06, 29 November 2008 (UTC)

Merge?
This page is an obvious fork of Help:MediaWiki namespace, isn't it? When they're merged into one, which namespace should it be in? (I suggest Help:, since this is just information about how the software works.)--Kotniski (talk) 09:45, 2 November 2009 (UTC)

 * Yes, merging MediaWiki namespace, Help:MediaWiki namespace and MediaWiki seems like a very good idea. If you should use the first or second name doesn't matter much. I think you should go ahead with it, since it seems very uncontroversial.
 * --David Göthberg (talk) 12:42, 2 December 2009 (UTC)
 * OK, I will in a few days, when I get some time, but if anyone else feels like working on it in the meantime, that will be great.--Kotniski (talk) 18:58, 2 December 2009 (UTC)
 * Done. (Though the resulting page still needs some tidying up.)--Kotniski (talk) 10:57, 6 December 2009 (UTC)


text:
Wikipedia talk:Template index

Horizontal list layout?
I found it difficult to parse the table-based layout of the main index in order to find a specific category, so I attempted to bring it closer to something like List of policies and guidelines. This would also bring improved accessibility and mobile readability (although these might be less of a concern for an editor audience). The changes were reverted by @Grandpallama, who suggested a discussion. So is there a preference for horizontal lists or tables? Ninepointturn (talk) 04:39, 12 January 2022 (UTC)
 * This is a heavily used template index, so I don't think it should have the layout completely changed without consensus from the community. It also serves a different purpose from the list of policies that you cite, as this is specifically an index to find the appropriate template codes; turning it into a list is a significant conceptual change for its design and purpose. For me, it was disruptive to come to the page to quickly grab an edit-warring template only to find the layout completely altered.
 * For new users who have difficulty finding a particular template, there is a search field. Given the index design and intent of this page, I'm not sure readability is a primary concern. Grandpallama (talk) 18:27, 12 January 2022 (UTC)

Edit request
redirects here. Please indicate HELP:Templates and WP:WikiProject Templates as well

Add the hatnote

-- 65.92.246.142 (talk) 22:19, 6 April 2022 (UTC)
 * Pictogram voting delete.svg Not done. Both the WikiProject and the Help page are already on the page. Viewer 719 /  Contribs! 11:53, 7 April 2022 (UTC)

Position of TOC
Can you please explain, in this, why do you think that TOC right is "more useful"?

I have changed the TOC position to the right, because I think the page looks less cluttered that way, both in desktop view and in mobile view.

But then, if many editors say that TOC left looks cluttered, you may go ahead and revert my edit. Thank you — CrafterNova [ TALK ]  [ CONT ] 09:30, 22 October 2022 (UTC)

 * @CrafterNova I did it because I could not initially locate the TOC. I thought maybe it was some bug or something. It didn't occur to me to look to the right, because I hadn't seen TOC there before. Because the trouble I had locating the TOC when I wanted to see it, I moved it to the left, thinking other editors could have a hard time as well for it being to the right. Thinker78  (talk) 15:51, 22 October 2022 (UTC)
 * I can relate. Sometimes I'm also unable to work with complex templates, but not as bad as I did when I started editing in July 2020. You can be better too. See Help:A quick guide to templates and Help:Template. Just look at source codes of simple templates at first such as template link and section link. You can also start with TOC itself. Copy and paste the source codes in your sandbox and experiment with them. Familiarizing with wikitext took me about 3 or 4 months. How much time it will take for you depends on how much free time you have.
 * And yes, there are many bugs in template transclusions and page displays, especially on mobile devices. Many complex templates, such as navboxes don't appear at all in mobile view.
 * I didn't about these bugs until pointed out the mess I did at Talk header template documentation page, and that discussion took place on my talk page at  — CrafterNova  [ TALK ]  [ CONT ] 16:26, 22 October 2022 (UTC)
 * Thanks for the idea about experimenting with template codes. I may look into it. I have long wanting to do it. But the issue about moving to the left was a pure display issue, at least initially. When I was looking perplexed for the TOC, I didn't check the code. Afterwards, I did some research and I think it is when I found the TOC right code being used and the template documentation. Then I used the TOC left version. Thinker78  (talk) 16:51, 22 October 2022 (UTC)
 * No prob. Also, see 's Toolbox which is very handy for all sorts of things on Wikipedia. You are welcome ;) — CrafterNova [ TALK ]  [ CONT ] 06:42, 24 October 2022 (UTC)

dictionary reference templates
I couldn't find links or templates for citing other dictionaries similar to the ones for Wiktionary. So the equivalent to this Wiktionary category: https://en.wiktionary.org/wiki/Category:English_reference_templates --Espoo (talk) 09:55, 8 April 2023 (UTC)

 * Espoo, here's how to find the templates you're asking about from the top of the category tree for templates (top-down): Category:Wikipedia templates → →  →  →.
 * Or, the other way around (bottom-up), from one of the templates: Wiktionary's Category:English reference templates has wikt:Template:OED reference templates near the top of the category. Oxford English Dictionary is a "big deal", therefore we can assume that English Wikipedia would have a template for it. Go to Template:OED, scroll down, find Category:Dictionary source templates at the bottom. —andrybak (talk) 23:25, 14 June 2024 (UTC)

title: Wikipedia talk:Template index


text:
Fuel pump

A fuel pump is a component used in many liquid-fuelled engines (such as petrol/gasoline or diesel engines) to transfer the fuel from the fuel tank to the device where it is mixed with the intake air (such as the carburetor or fuel injector).

Carbureted engines often use low-pressure mechanical pumps that are mounted on the engine. Fuel injected engines use either electric fuel pumps mounted inside the fuel tank (for lower pressure manifold injection systems) or high-pressure mechanical pumps mounted on the engine (for high-pressure direct injection systems).

Some engines do not use any fuel pump at all. A low-pressure fuel supply used by a carbureted engine can be achieved through a gravity feed system, i.e. by simply mounting the tank higher than the carburetor. This method is commonly used in carbureted motorcycles, where the tank is usually directly above the engine.

Low-pressure mechanical pumps
On engines that use a carburetor (e.g. in older cars, lawnmowers and power tools), a mechanical fuel pump is typically used in order to transfer fuel from the fuel tank into the carburetor. These fuel pumps operate at a relatively low fuel pressure of 10 - 15 psi.

The two most widely used types of mechanical pumps are diaphragm pumps and plunger pumps.

High-pressure mechanical pumps
Pumps for modern direct-injection engines operate at a much higher pressure, up to 30000 psi and have configurations such as common rail radial piston, common rail two piston radial, inline, port and helix, and metering unit. Injection pumps are fuel lubricated which prevents oil from contaminating the fuel.

Port and Helix pumps
Port and Helix pumps are most commonly used in marine diesel engines because of their simplicity, reliability, and its ability to be scaled up in proportion to the engine size. The pump is similar to that of a radial piston-type pump, but instead of a piston it has a machined plunger that has no seals. When the plunger is at top dead center, the injection to the cylinder is finished and it is returned on its downward stroke by a compression spring.

Due to the fixed height of a cam lobe, the amount of fuel being pumped to the injector is controlled by a rack and pinion device that rotates the plunger, thus allowing variable amounts of fuel to the area above the plunger. The fuel is then forced through a check valve and into the fuel injector nozzle.

Plunger-type pumps
Plunger-type pumps are a type of positive-displacement pump used by diesel engines. These pumps contain a chamber whose volume is increased and/or decreased by a moving plunger, along with check valves at the inlet and discharge ports. It is similar to that of a piston pump, but the high-pressure seal is stationary while the smooth cylindrical plunger slides through the seal.

Plunger-type pumps are often mounted on the side of the injection pump and driven by the camshaft. These pumps usually run at a fuel pressure of 250 - 1800 bar.

Electric pumps
In fuel-injected petrol engines, an electric fuel pump is typically located inside the fuel tank. For older port injection and throttle-body injection systems, this "in-tank" fuel pump transports the fuel from the fuel tank to the engine, as well as pressurising the fuel to typically 40 - 60 psi. While for direct-injection systems, the in-tank fuel pump transports the fuel to the engine, where a separate fuel pump pressurises the fuel (to a much higher pressure).

Since the electric pump does not require mechanical power from the engine, it is feasible to locate the pump anywhere between the engine and the fuel tank. The reasons that the fuel pump is typically located in the fuel tank are:
 * By submerging the pump in fuel at the bottom of the tank, the pump is cooled by the surrounding fuel
 * Liquid fuel by itself (i.e. without oxygen present) isn't flammable, therefore surrounding the fuel pump by fuel reduces the risk of fire

In-tank fuel pumps are often part of an assembly consisting of the fuel pump, fuel strainer and fuel level sensor (the latter used for the fuel gauge).

Turbopumps
Rocket engines use a turbopump to supply the fuel and oxidizer into the combustion chamber.

title: Fuel pump