Amiga short takes: OS 3.1.4, disk error

▼ The last few weeks I've been spending some time with my Amiga 1200 and Amiga 3000, and I want to write about some of that. However, I don't want to spend too much of my own time and that of the readers of this blog on that. So my plan is to do a collection of short takes periodically. This will be the first one. Topics:

• AmigaOS 3.1.4
• Roadshow TCP/IP stack
• Cybergraphx 960x540 resolution
• Disk error
• SD-to-CF adapter

AmigaOS 3.1.4

I don't think we're in any danger of the Amiga joining modern operating systems in having an update every time you've been away from your computer for fifteen minutes. But: turns out that two years ago, there was actually a new AmigaOS 3.1.4. Yes, more than two decades after the last Amiga rolled off the assembly line.

My Amiga 1200 came with 3.0 and I never upgraded to 3.1, as it didn't seem to offer any useful (to me) new features. And then Commodore went out of business. However, there were 3.5, 3.9 and 4.0 upgrades, with tons of new stuff. As the version number suggests, 3.1.4 builds on 3.1. It doesn't offer new flashy features, but just improves a bunch of stuff. For instance, you can now use drives larger than 4 GB. It also brings newer, more colorful icons to the OS, supporting both NewIcons and AmigaOS 3.5 type icons natively.

I opted to get AmigaOS 3.1.4 as a download, and not get new ROM chips. Instead, I just use BlizKick to load the 3.1.4 Kickstart into RAM, overwriting the copy in RAM my A1260 accelerator makes anyway.

I installed the new OS on my Amiga 1200 from floppy disks on a new CF card, which went quite well except I had to install a 68060.library to support my 68060 CPU manually, and without the 3.1.4 Kickstart, booting into the new OS leads to an immediate crash as during startup, ROM patches are loaded but these are of course not compatible with my 3.0 ROMs, hence the crash.

This did make me realize that if you want to run an Amiga in this day and age, you really have to be comfortable configuring stuff manually and not solely depend on installers.

Roadshow TCP/IP stack

I'm rebuilding a new AmigaOS installation from scratch, but I can also boot from a copy of my old install, I wasn't going to throw away 25 years of history. So this was a good opportunity to update my networking. I've used Miami from 1995 or so. Miami is a TCP/IP stack that is entirely configured using a graphical interface, and worked especially well with dial-up modems. However, the GUI creates a lot of overhead.

Turns out there is a much newer TCP/IP stack that a lot of people like: Roadshow. So I installed the demo version, which turned out to be about 50% faster than Miami. So I immediately got the commercial version, my smbfs file transfers can use all the help they can get.

Roadshow does come with an installer, but I needed to make a config file for my I-Card driver manually. (The I-Card is rather obscure because it was available in the 1990s long before consumers had the need for Ethernet.) After it's installed, Roadshow just loads automatically and is completely invisible, like we're used to with modern computers. So highly recommended if you have an Ethernet adapter for your Amiga.

I also installed Roadshow on my Amiga 3000, which only has 4 MB fast RAM left (of 8) after loading Cybergraphx drivers and BBS software, as well as two kickstarts. Replacing Miami with Roadshow improved that by almost a megabyte.

Cybergraphx 960x540 resolution

All this network speed testing meant I spend a bunch of time looking at the output of the Cybergraphx 64/3D graphics card in the A3000. I used a 800x600 resolution, which works very well with the VGA input of my Dell U2312HM monitor. (Much better than the Amiga 3000's native VGA output.) However, after getting 960x540 to work on my Amiga 1200, I wanted to see if I could do the same with the Amiga 3000. Turns out that the Cybergraphx software has supported setting up your own resolutions all along, so I did some experimenting.

When I set up 960x540, the monitor recognized that as 1920x540. So that was good. However, it didn't show all 540 lines, and there as a significant amount of unused space on the left and the right. I fixed this by upping the pixel clock a lot and adjusting the last vertical setting, and then adjusting the pixel clock and phase on the monitor a bit. I can't check the exact settings right now because of the last topic of this post.

Disk error

And then yesterday morning I turned on my Amiga 3000 and it couldn't boot because the harddrive was validating. In and of itself that isn't a huge deal, usually the validation process runs for a while and then everything is back to normal. I actually have a small wait for validation tool in my user-startup so the BBS won't start until the HDD has been validated. So I guess (don't remember) that back in the day, this happened with some regularity.

The trouble is, I have a pretty tricky boot setup on the A3000, and that setup doesn't work if the drive is read-only, as it is during validation. The older Amiga 3000s load their Kickstart from disk in a somewhat peculiar way. When I installed AmigaOS 3.0, I kept that 2.0 Kickstart process, and then loaded a second 3.0 Kickstart and then pointed all the assigns to the 3.0 system in a subdirectory on the 2.0 drive.

Turns out, the execute command needs a temporary file, which normally goes in T:, but if the boot process isn't far enough along to have the T: assign, it uses :T (i.e., a T directory on the boot drive) instead. Which it couldn't, because the disk was validating. And then failed to validate because of a read error. Eventually I was able to boot by creating T: in RAM manually and then executing s:startup-sequence.

Before I figured that out, I actually used a terminal program to exchange files with my other Amiga over a nullmodem cable. This is actually a pretty good option of last resort, because using a terminal program to talk to the serial port is infinitely simpler than setting up networking, which not only requires a networking stack but also a bunch of settings and the right driver.

Right now, DiskSalv is trying to copy data off of the drive to my NAS, but that seems to be taking forever. Fortunately, I made a copy last week, so even if this fails I probably won't lose any data. Maybe I can repair the drive, but I think at the very least I need to do a full format so the drive can remap any bad sectors.

The trouble is that with a non-working floppy drive, if I wipe the SCSI HDD, the computer can then no longer boot. I guess it can be done by having networking running, do the format and copy the necessary stuff back to the HDD from over the network. However, if I make a mistake and the machine won't boot, there's nothing I can do. So I think I'm going to get a Gotek drive to solve that, and as I'm going to open up the 3000 anyway, replace its fan with a quieter one.

SD-to-CF adapter

As an additional option to exchange files with my modern systems, I ordered an SD-to-CF adapter from Amazon. I was lucky, because I ordered a type I card, which is about 3 mm thick. Most are type II cards, which are over 5 mm thick and don't fit in a CF-to-PCMCIA adapter that goes into the Amiga 1200.

The good news is that the adapter works as advertised: you put an SD card in the CF adapter, which then goes into the PCMCIA adapter, which then goes into the A1200. With CFD133 and fat95 installed, the card is immediately recognized, as long as it's formatted as FAT, not exFAT. Just plugging 64 GB of removable storage into the side of an Amiga 1200 is pretty wild.

However, I wouldn't say that this adapter is a success. First of all, the SD card goes into the side of the adapter. This means you need to remove the SD-to-CF adapter from the CF-to-PCMCIA adapter to insert or remove the SD card. The CF and PCMCIA interfaces work with lots of thin pins, so you really don't want to be plugging/unplugging those all the time. And you wouldn't want to use an SD card as (semi-) permanent storage as the transfer speeds aren't great: about 850 kB/sec. A CF card is almost twice as fast at 1.5 MB/sec.

Permalink - posted 2020-10-04

The evolution of computer display technology

▼ In a previous post, I mentioned that it's hard to connect a Commodore 64 to currently available monitors and TVs. I've also had considerable difficulty hooking up my Amiga 1200 to an LCD monitor and getting a clear picture. Probably more about that in a later post.

So I thought it would be interesting to look at how widely available computers since the late 1970s have sent text and graphics to an external display, and the evolution of those systems.

1980s home computers

Home computers from the 1980s were intended to be used with a TV as their display. This works very well for screen resolutions up to around 320x200 that those computers had to use because of memory and speed limitations. Nearly all of those computers had a text mode, and then often various graphics modes and additional capabilities such as sprites that are useful for games. They could display 8 to 16 different colors. Text was limited to about 40x25 characters.

Typically, home computers had a built-in RF modulator, which created an actual broadcast TV signal. That works with all analog TVs. And VCRs did the same thing. It quickly became clear that skipping the RF modulation/demodulation steps provided a better picture, so new TVs came with composite video or SCART connectors to hook up VCRs (and home computers).

A composite video signal is a combination of a black-and-white signal and an additional signal that encodes color information. These are also the signals a VCR records on tape. The computer's video chips directly created these signals inside their video chip, so those are the best quality video output available. A few computers such as the Commodore 64 provided access to separate luma (black-and-white) and chroma (color) signals, which prevents the two from interfering with each other. That system was later called S-video.

Early IBM-compatible PCs

The original IBM PC from 1981 had two display options: a monochrome text-only MDA video card or a color CGA video card that also supported graphics. At 640x200 in graphics mode and 80x25 in text mode, the CGA card supported a higher resolution than home computers did, and the signal wasn't an NTSC signal, but TTL RGBI. That means: four wires for red, green, blue and intensity. Each wire caries a binary on/off signal, allowing for 16 color combinations. However, the timing signals were the same as NTSC, so it was possible to connect a TV to a CGA video card with the right adapter.

A limitation of the CGA card is that characters are 8x8 pixels, which doesn't look very smooth. The MDA graphics card addresses this issue by using 9x14 pixel characters. This means the resolution of the display must now be 720x350. A monitor with NTSC timing can in principle a 720x350 resolution, but the image will flicker horribly because it can only draw a complete image 30 times per second. (An image of no more than about 200 lines can be redrawn 60 times per second and doesn't flicker.) So instead, MDA displays use a faster pixel clock, which in turn allows for a faster horizontal refresh rate, resulting in a vertical refresh rate (how often the complete image is drawn) of 50 Hz. MDA only supports text in one color plus extra brightness. It uses two TTL signals for that.

Not long after, there was a Hercules Graphics Card that supports the same text mode as MDA, but also a 720x348 monochrome graphics mode.

In 1984, the EGA graphics card came out, which could run in a modes compatible with both CGA and MDA monitors and supports 64 colors by having two TTL signals each for red, green and blue.

Mac

The original Macintosh/128K from 1984 had a built-in display with a resolution of 512x342 and a refresh rate of 60 Hz, which, like MDA, uses faster timing than a TV signal. Interestingly, there was no text mode, only back and white, and no additional capabilities such as automatically overlaying the mouse pointer over the image. Later Macs increased the resolution and number of colors similar to VGA and its successors.

Amiga

In 1985, Commodore introduced the Amiga. The first generations of Amigas had very flexible graphics modes up to around 320x200 with 2, 4, 8, 16 or 32 colors out of a palette of 4096, or around 640x200 with up to 16 out of 4096 colors (4 bits per color). The timing is compatible with the NTSC or PAL TV standards. So much so even, that with the aid of a genlock device, the Amiga's video chip can sync up with the an external video signal so the Amiga's display can be overlaid over parts of it.

However, the original Amiga was intended to be used with a monitor, not a TV. So its video output is in the form of three analog signals for red, green and blue—12 TTL signals to allow for 4096 color combinations would have been impractical. As a CRT's electron beams are driven by three analog signals for the three primary colors, an analog RGB signal from the computer is a very natural fit.

The Amiga 1200's video outputs: analog RGB, composite video, RF

A big limitation of NTSC/PAL compatibility was that resolutions of more than 200 lines (256 for PAL) required interlaced video with its inherent flickering. So later Amigas got a faster pixel clock that let them draw resolutions such as 640x480 at 60 Hz without flicker. The number of colors was also increased to max 256 out of 16.8 million (8 bits per color).

VGA

In 1987, the new IBM PS/2 PCs came with the Video Graphics Array. VGA has (yes, present tense, VGA is still supported as a lowest common denominator standard in most video cards!) a 80x25 text mode and 640x480 graphics with 16 out of 262144 colors (6 bits per color) or 320x200 with 256 colors. It uses the (in)famous 15-pin VGA connector with analog signals for red, green and blue. After VGA came SVGA, XGA and many others, which increased the number of colors to 256 at higher resolutions, and resolutions kept increasing up to an eventual 1920x1200.

Unification

The early color computers used a small number of fixed colors and the later ones worked with an indexed color system, where you still only had a relatively small number of different colors on the screen at the same time, but you could redefine those colors by specifying the three primary colors with a precision of 2, 4, 6 or 8 bits.

After that came high color and true color starting at around 1995. With high color, each pixel is 15 or 16 bits, with 5 bits for red and blue, and 5 or 6 bits for green. True color increases this to (at least) 24 bits per color, so 8 bis per color. So with a true color system, there are no limitations on how many colors can be on the screen at the same time.

Around the same time, MSDOS gave way to Windows so it was no longer common for computers to use text mode, but rather, mix text and graphics in a (high color or true color) graphics mode.

The VGA connector was never replaced by anything new until analog display connections were replaced by digital ones: first DVI, then HDMI and DisplayPort. Within a few years after VGA came out, Macs became compatible with VGA monitors, and the later Amigas could also use a VGA monitor when running in the correct screenmode.

So as of the second half of the 1990s, all common computer types moved away from TV-based display options towards a common display technology. Then, with the advent of HDTV, TV also made the jump to higher resolutions and digital connections... and now it is again possible to use a TV as a computer display.

Funny how things work out sometimes.

Permalink - posted 2020-09-13