By Greg Noggle, Telecommunications Editor and Hardware Guru, email@example.com
Motorola, the company producing the 680x0 family, offers crippled versions of their processors. They are a little bit cheaper than the originals; that's why Commodore decided to build the 68EC020 into the A1200 and the 68EC030 into the A4000/030.
The difference between the 68020 and the 68EC020 is that the latter can address just 16mb of memory. That's why the stock A1200 cannot have more that 10mb RAM. In most cases you will not notice the difference.
This is not the case for the 68EC030; many owners will notice that the 68030 has an MMU and the 68EC030 does not. There are some important programs that depend on there being an MMU in the system: for example, Enforcer (a debugging utility), GigaMem (a program to emulate virtual memory), or all current Unix versions. Amigas other than the A4000 and the A3000 need an additional processor card to run these.
The first 680x0 processors (up to 68030) could process integers only. Floating point (decimal/fractional) operations had to be emulated by the software. An FPU is a chip (or part of a chip) that can process floating point operations; in other words, a mathematical coprocessor.
There are three separate FPU types on the Amiga: The 68881, 68882 and the 68040's internal FPU. The 68882 is up to 1.5 times faster than the 68881, because it is split into two parts: a conversion unit (the FPU's are using an 80 bit format internally) and the arithmetic unit. The 68040's internal FPU adds a pipeline, but misses the trigonometric instructions of the others. These are still emulated by the software, for example, 68040.library.
Special programs (Raytracing, DTP, Mathematics, TeX) are offered in a special coprocessor version which will run up to 50 times faster than the original versions.
Many printers come with a manual that explains which Esc sequence cause which action on the printer. But weird things can happen when you try to send these sequences to your printer: either it does nothing, or it does something completely different. There is a reason: the Amiga printer drivers. These drivers are made in a way that they only understand a certain set of `ANSI Esc sequences', not the special ones defined (differently) by the various printer manufacturers.
The purpose is that every application on the Amiga just uses this one standard set of control sequences and this way doesn't need to know which printer is actually connected. The printer driver then translates these standard sequences into the special sequences a certain printer understands. A list of the available ANSI Esc sequences is found in the current Workbench manuals (or older AmigaDOS manuals). Now if you want to issue a control sequence to the printer that's not available as an ANSI command, you have two ways to achieve this:
But both methods have one big disadvantage when used in an application program: you lose the printer independency! If you stick to ANSI sequences, you can output to any printer on earth, as long as there is an Amiga printer driver for it. If you start to use special control sequences, your program will be tied to this single printer model and will not be useful for any other (or you would have to provide some dozen new printer drivers for your application).
PostScript is a programming language designed to be used to describe printing on pages. Apple helped make PostScript popular by selling printers with built in PostScript interpreters. Many programs have evolved to produce PostScript programs as their output, making PostScript the lingua franca of printing. Until recently, in order to print a PostScript file, you had to have a relatively expensive laser printer. The development that changed this was the software "PostScript Interpreter." These programs allow your computer to interpret PostScript programs, and produce the matrix of dots to send to your normal graphics printer.
One of the benefits of PostScript is that it is resolution-independent. What this means is that it can support the highest resolution of your device and that you can reasonably preview PostScript on a low resolution screen.
There are two free PostScript interpreters for the Amiga. Post and Ghostscript. Post comes as an Amiga shared library along with front ends for previewing to the screen and printing. This structure allows others to write programs that can show PostScript images on screen. In fact, AmigaTeX uses Post's library to support incorporation of PostScript into documents. Ghostscript similarly comes in two programs, but not as a shared library. Ghostscript is the rendering engine, and Ghostview is the front end. Sources: Aminet (directories `text/print' and `text/dtp'), Fish disk 669.
Computer images are arranged as a grid of pixels, each of which can be thought of as a number representing the color number of the pixel, sort of like a paint-by-numbers scheme. For example, here's a simplified example image, in four colors:
The Amiga stores this image in a `bitplane' mode. That is, it is represented by several planes of bits (binary digits, 1s or 0s). This is a four-color image, so each color number could be represented by two bits. Therefore, there are two bitplanes:
00100110 Here's bitplane 0 00101011 And here's bitplane 1 -------- Now, let's add them up, binary style: 00302132
Which is the final image. If the image was in two dimensions, it would truly be composed of bit planes. However, I'd need three dimensions to show multiple bitplanes overlayed, and therefore for simplicity we're working in one dimension (which is all we need).
Now, there's another way of storing this image. How about if we localize the bit data in little chunks?
00 00 11 00 01 10 11 01 = 00302132
This is the principle of the `chunky' pixel mode.
Both methods of image storage are perfectly logical, and no one can say that one is better than the other. However, there are certain technical aspects which cause certain advantages and disadvantages.
First, if you've seen colored text scroll on your Amiga, you know there is a bit of "flicker" that arises. Specifically, what happens is that while the text is scrolling, its color temporarily changes to something completely different. What's happening is that the computer is moving several bitplanes of data while the raster (monitor electron gun) is sweeping across the screen. What that means is that, if the raster catches the data while it's being moved, you can end up with some bitplanes being moved and some not. What if we filled bitplane 1 in the example above with 0s? Instantly all the 3s become 1s, and the 2s become 0s! This is what causes "flicker" when certain colors are scrolled. By contrast, if a chunky pixel display is caught while scrolling, all we see is a partially-scrolled image; the colors are preserved (since their units are the small ones).
That's a disadvantage to planar pixels, but what about chunky pixels? Well, recall that a computer organizes information in terms of 8 bit bytes. These groups are static; you cannot decide to all of a sudden organize data in terms of three bytes or something! Therefore, when using chunky pixels, things get complicated if we decide to use a nonconvenient number of bits per pixel. In practice, the 8-bit (256-color) mode, and 24-bit (16 million color) modes are the most common candidates for chunky pixel displays.
Finally, certain effects can be accomplished with the different systems. Bitplanar mode is particularly useful for things like shadows (where an extra bitplane is set with 1s instead of 0s), and chunky mode is great for perspective and "mapping" (since the data for each pixel is localized in a single "chunk"). The latter advantage makes chunky pixel mode really great for games, and is what made Wolfenstein 3-D possible.
We all know that Amigas use the bitplane system for storing images. However, the Macintosh and PC (VGA) both use chunky pixel modes. While we can optimize our RAM usage with "bizarre" modes like 8- and 128-color, they gain the advantages of non-flicker scrolling, and the programming simplicity of just writing a byte where you want the pixel to go.
The difference between the two modes becomes problematic in things like emulation. EMPLANT has a "chunky to planar" routine which it uses to convert a MacIntosh display into an Amiga one. "Chunky to planar" routines are also useful for getting chunky-inclined things to run on Amigas (see TMAPDemo, rotdemo). On a side note, there was some confusion as to what EMPLANT used the MMU for with regard to chunky to planar. The MMU itself is incapable of performing the algorithm for the conversion; rather, it is used to detect what portions of the display memory are updated from the Mac side, and therefore the processor is saved from having to perform the chunky to planar conversion for the entire display.
Don't be ashamed if you haven't a clue as to what this is. It's rather simple, really. Imagine you wanted to animate something by drawing out each frame. Now imagine you had only one piece of paper. Even if you drew pretty fast, it would be difficult to see what the animation looks like because you'd have to erase the frame you just drew, in order to draw the next one!
What if you had two pieces of paper? Why, then, you could see the difference between two adjacent frames. First you'd draw your first frame on the first piece of paper, then you'd draw the second frame on the other piece. Then you'd erase the picture on the first piece of paper, and draw in the third frame. Then you'd erase the picture on the second piece of paper, and draw in the fourth frame, and so forth.
This is the principle of doublebuffering. The computer shows you the picture it just drew, then turns around and draws the next one. It then swaps the picture in front of you with the one it just drew, and repeats the process. The result is a smooth animation, because you never need to see the computer draw; all you see is each finished product.
Monitors can be classified according to the horizontal scan frequency at which they operate. TVs, as well as Commodore's 1084 monitor, run at frequencies of around 15kHz. VGA/SVGA run at approx. 30 kHz. Multisync monitors can take many frequencies.
In short: You can use any monitor you want with an A1200. BUT:
For a VGA/SVGA or Multisync monitor, you'd need a little shiny box which gives you the standard 15-pin "D" connector. It costs around $15.
Also, you can get a VGA monitor, and hook up your TV to the composite or RF port on the Amiga - one monitor for games, one for serious stuff.
PAL and NTSC are two different video standards, the former being European, and the latter being American. PAL has a slightly taller screen (256 lines non-interlaced, non-overscanned) as opposed to NTSC (200 lines), so if you see the bottom portion of a program's screen getting cut off on your American machine, chances are the program was written for PAL, and is running on your shorter NTSC screen. PAL and NTSC differences are somewhat less important to European users; since their machines default to PAL, running an NTSC program is no more than a minor annoyance at having the screen only appear in the top portion of the display.
Therefore, for us NTSC folks, switching into PAL mode becomes important to avoid loss of some picture on Euro Demos, etc.
First, the most common misconception about switching between PAL and NTSC is that you need a Multiscan or special monitor for such a purpose. Not so! Just about any monitor can handle the minor signal difference between PAL and NTSC (50Hz vertical refresh versus 60Hz). The 108x, 19xx, and 20xx series, and even most TVs, can display both PAL and NTSC. Sometimes it is necessary to perform minor tweaking of vertical hold and/or v. size on your monitor to achieve full display, though this is trivial.
What IS needed to switch between PAL and NTSC in software is a "Fatter" (1MB) Agnus or better. If your system has more than 512K of CHIP RAM (use the avail command to find out) you have this chip. If you do not, you can still construct a hardware switch (see below).
The following directions assume you're an NTSC user who wants to switch into PAL mode, but the procedure for going from PAL to NTSC is much the same.
The most common use of switching into PAL is for self-booting games, demos, etc. The best way to accomplish this on pre-3.0 systems is to use Chris Hames' Degrader program (most recent version: 1.30). Once you have procured this program, the switch is as simple as selecting "50Hz", and "50Hz System", then installing the program's ROMTag (little program that runs at boot-time) by pressing the "Survive Reset(s)" button.
AmigaDOS 3.0 added a PAL/NTSC switch feature to its Boot Menu, and all you need to do in order to access this is hold down both mouse buttons as the computer boots. Select Display Options, Display Mode/PAL, and then Boot. If the program still fails to go into PAL mode (Zool is one I've found), you may wish to get Degrader anyway and try that.
Software PAL/NTSC switching is easy and painless. Some people have gone even further by installing hardware PAL/NTSC switches. This results in a system which even the most nasty hardware-banging programs can't bring to its original configuration (if it has been switched). The procedure is simple - most Amigas have jumpers already - but beyond the scope of this document.
Therefore, if your screen is too short or cut off, seek the different screen mode. You'll "see new horizons", literally!
No problem for owners of Workbench 2.1 or higher: The program CrossDOS is part of the Workbench. All you have to do is mount the device `PC0:' by putting it into the drawer `Devs:DOSDrivers' or by double-clicking on the icon in `Sys:Storage/DOSDrivers'. MS-DOS disks in drive `DF0:' can now be handled in the usual manner, replacing the word `DF0:' with `PC0:'. For example, the directory can be shown with the command "dir PC0:."