This little machine is an XT-class computer with 16MHz NEC V30HL, 1MB of RAM, double-CGA 640×400 graphics (AT&T6300/Toshiba compatible), MS-DOS in ROM and a 20MB Conner HDD (working in 8-bit mode). Its size and weight are halfway between regular laptops and handhelds (it is ultra-portable even by today’s standards). I got one three years ago and it was dead like almost all of them nowadays. The issue was “easily” fixable by replacing all the SMD capacitors. We replaced the ones on the logic board and the computer booted. However, the screen was not able to retain the contrast value, which made it hardly usable. Also the Conner drive had the head stuck (a common issue, that I want to fix later). We disassembled the lid and replaced a capacitor on the display board. Everything worked flawlessly when disassembled. As soon as we assembled the machine together, it stopped working. We were tired and put the whole thing into storage.
Recently, after three years, we gave the machine another chance. Disassembled it, booted and everything worked ok (except the HDD of course). After assembling it back? No sign of life… The issue was caused by too long legs on the new capacitor in the display board. The legs were sharp and went through the insulation layer on the (metalized) screen cover and shorted the capacitor (I know, shame on us…). Once we fixed this, we were able to put the machine back together and enjoy it. David also replaced cracked internal plastic parts using a 3D printer.
Now we have a trouble-free machine in a perfect shape with just one flaw – a faulty hard drive (and no floppy drive). However, that is not as big issue as one might think…
I was silent for a while as some things required my attention more than old computers. We extended the list of implementations of our Sieve Benchmark and it now supports even 6502. It was developed on Atari 800XL without any modern hardware or software (it’s written in ATMAS II macro-assembler). And it was a pain.
We all remember the lovely days of being young and playing with these simple computers, where programming was often the best way to spend time. These nostalgic memories don’t say the truth how horribly inefficient the development was on these machines in comparison with what came a decade later. David told me that his productivity was about 20 times lower in comparison with developing an assembly program of similar complexity and size on PC. These were one of the biggest reasons for your entertainment:
It was easy to fill whole available memory with the source code text. There was a situation when only 100 characters could be added to the text buffer, but about 2000 were needed. That caused that multiple parts were optimized for source code length (except, of course, the sieve routine itself, which was optimized for speed).
At the end, it was necessary to split the source code into two parts anyway.
Unlike with PCs, the Atari keyboard doesn’t support roll-over on standard keys. It is necessary to release the key before pressing another one (otherwise the key-press is not properly recognized).
Having a disk drive was a big advantage over tapes. However, the implementation on Atari was very slow and everything took incredible amount of time. Boot into editor? 20 seconds. Loading the first part of the source code? 5 seconds. Loading the second part? 30 seconds. Storing it back? 60 seconds (for just 17 KB). You needed about 160 seconds before trying to run the program after every larger change (including 20 seconds for compiling). Often a minute more if the program crashed the whole computer.
Although David never started to use “modern” features like syntax highlighting and code completion and he still programs mostly in the 80×25 text-mode, he said that this was too much for him so I don’t think we will repeat this again soon.
Regarding the results: A 1.77-MHz MOS 6502 in Atari 800XL/XE (PAL) required about 66 CPU cycles to go through a single inner-loop step. If graphics output was disabled during the test, this decreased to just 49 CPU cycles. A 4.77-MHz Intel 8088 needed about 73 CPU cycles to do the same. Thus, 6502 is faster if running on the same clock.
On the other side, the original IBM PC is clocked 2.7x higher than the Atari and 4.7x higher than other important 6502 machines (Apple IIe, Commodore 64). Thus, IBM PC was at least twice as fast in this type of tasks (similar to compiling, XML parsing…). I’m not surprised, but it is nice to see the numbers.
Interestingly, the heavily optimized assembly code running on Atari provides the same performance as compiled BASIC (MS QuickBasic 4.5) running on 20MHz 386DX (interpreted version would be three times slower). This was one of the fastest BASICs out there so it gives you good perspective on how these high-level languages killed the performance back then. David spent a lot of time optimizing the code for both CPUs and used the available tricks for each architecture (like self-modifying code…). If you feel that your favorite CPU should have been faster, you can download the project folder and check the source code. If you create a faster version, please send it to me (but please read the README first, especially the part called “Allowed tricks”).
Also if somebody is able to port the code to Commodore 64, it would be nice to compare the results with Atari (only the disk access, timer and console input/output need to be rewritten). Any expert/volunteer?
Working with old Amiga computers with their original color monitors is always a painful experience. Especially here in Europe where these screens run at 50Hz. Fortunately, my Amiga 2000 is equipped with a Multivision 2000 scan-doubler card that not only doubles H-sync from 15.75kHz to 31.5kHz (to make the output compatible with VGA monitors) but it also allows a user to increase refresh rates up to 100Hz.
I wanted to show this computer on Bytefest (a vintage computer show) and I decided to show it with a CRT (LCDs always ruin the experience). That created an ideal situation to check how this “software controllable refresh rates” feature works. The manufacturer of the card (3-State) bundled a diskette with a simple program that allows you to find the optimum refresh rate using multiple sliders and the way it works is compatible even with old simple VGA screens from the early 1990s.
The picture frequency is increased when a user decreases the number of video lines. Speed of drawing of each line is still the same. The computer just generates fewer lines, which means that a single frame takes less time and the next one can start sooner.
I switched Workbench into the interlaced mode (512 lines instead of 256) and then used the bundled Sync Master tool to decrease the number of lines close to the original non-interlaced resolution. As a result, I got nice and steady 80Hz on a standard VGA screen, which allowed me to work with the computer for hours without eye strain. This is a perfect setup for office/productivity work. However, be prepared that this tool doesn’t work well with applications that open their own screens a display outside Workbench (you need to revert it to default before starting such application).
Digital (DEC) always made interesting computers and their PC laptops were no exception. DECpc 325SLC was a laptop with the first generation of color passive-matrix displays. The picture quality (aside the ability to display colors) was on par with monochrome passive-matrix screens with all the drawbacks they had. On the other side, the computer was equipped with a 25-MHz Intel 386SL and SVGA graphics for just $2.100 – the price where other laptops from most other brands have just monochrome screens and VGA graphics.
The 386SL is the first CPU specifically designed by Intel for use in laptops. It integrates almost a whole PC into two chips, with the main chip containing (among other things) a 386SX core (with 16-bit data bus) and 64kB of cache (16-bit as well). Intel built the platform to support then new power management functions like the sleep mode (“suspend to RAM”). The performance of this CPU is halfway between 386SX and 386DX.
Graphics chip was not integrated in the two Intel chips. Digital decided to use a chip from Western Digital with 512kB of video memory and the support for 256 colors with a resolution up to 800×600. The chip was attached using the ISA bus and had no acceleration. On the other side, the support for VESA VBE 1.2 and ~3MB/s throughput to video memory made it a good mainstream solution among ISA based cards of the time.
There was also a detachable trackball module available for the computer. It’s not hot-plug and you need to reboot the system, but it works surprisingly well even after decades. Note the mouse icons on the arrow keys and Z/X – these are for the mouse emulation. The laptop with no trackball or mouse attached transparently emulates PS/2 mouse on these keys and the result is way more usable than the Windows feature called “MouseKeys”.
It took me two years to find some time to disassemble the machine and then another year to start fixing it. Repairing the PSU with the blown EMI suppression capacitor was an easy task and that’s what we started with. Worse part was the instability – machine often crashed to a guru meditation error during certain tasks and sometimes a restart resulted in a “color screen” error.
David created and programmed a small device with eight differential inputs for voltage measurement (and logging) so we could check if the electrolytic capacitors did their job properly. To our surprise, they were fine. We also tried different programs to test memory and other hardware but the computer successfully passed all the tests.
Based on the Guru error codes, we found the root cause in the faulty EPROM chip (Kickstart 3.1). It started to lose data and reading of certain regions of the chip was sometimes affected. Thus, CPU executed faulty code (like a word or long word access on an odd address boundary).
The system is now running with Kickstart 1.3 and Workbench 1.3 and all original upgrades are inside except one. The Commodore A2630 accelerator card (25MHz 68030+98882, 2MB 32-bit RAM) crashes with dark blue and green screens and I’m afraid that there is a mechanical issue.
Next steps: Fix A2630 and reprogram the EPROM chip.
Don’t expect fancy setup utilities in CP/M. This is the process to create a machine compatible version of Kermit (terminal emulator software). MLOAD.COM takes the main program file in HEX and modifies it using the machine specific HEX file. The result is an executable file (COM) of the desired program.
Although there were text-based DOS programs around even in the 90s, their interface was usually far more user friendly with all the setup utilities, pull-down menus and other cool features. CP/M and early DOS programs were a perfect example of how simple and crude the software from the early- and mid- 80s was.
Kermit also reminds me a big advantage of the “PC compatibility”. In theory, the CP/M software was universal. However, different floppy formats, different pinouts on serial/parallel ports and different screen handling commands made life much tougher for both software developers and users.
I play a lot with my PowerBook 100 these days. It’s a part of a large article about early Macs for my main blog (in Czech). PB100 is a cool office machine and it’s always a pleasure to work with it. I mostly run a text editor and a terminal emulator (the 9600 baud connection to a Linux box that can be used for the Internet access). When I need to relax, I have Test Drive II: The Duel (among other games). The Mac version of this game is somehow more fun than on PC even though it displays just black and write pixels.
Anyway, my obsession is to port our Sieve Benchmark to every single old computer I play with. PB100 was not an exception. I already had a version for Mac so I only needed to modify the code to run on the plain Motorola 68000 and System 7.x.
PB100 with a 16-MHz 68HC000 CPU runs twice as fast as Amiga 600 (with no fast memory). That’s not bad. However, my another small laptop from the same era – Toshiba 2200SX – is still three times as fast as PB100 thanks to its 20-MHz Intel 386SX. I’m not surprised that higher-end models (with 68030) from the first generation of PowerBooks were more popular. Still, this PowerBook is my favorite machine among early portable Macs.
I was given a Multia a few months ago from a former Digital employee. He told me that the machine could not start (no sign of life, even fan didn’t spin on). I cleaned it, checked all cables and the machine started without any issue. However, after an hour of work, screen went black and the machine was not able to boot anymore (no smoke effects).
I thought this was maybe the well-known issue with the two chips on the bottom side of the system board dying due to overheating. Ordering these chips looked easier than doing any diagnostic so we ordered the replacement and “fixed” the board. However, it didn’t help. My Multia still blinks the error code E – “Failed while configuring memory”.
These chips are octal bus transceivers – they are between the CPU and RAM slots. There are nine of them (8x8bit for data, 1x8bit for ECC). Two of them on the bottom side. We did some checks using oscilloscope to see what was happening there. At least OEAB signal was changing rapidly. !OEBA seemed H all the time (cannot tell for sure, maybe there were just too few changes). There was some data on two out of the nine chips. The rest of transceivers had no visible data receiving from the CPU (L).
We don’t have a usable logic analyzer at the moment so it is hard to move further. I tried to find some documentation and block diagrams of the machine with no success (I have a reference board design for the CPU though). Also, all Multia pages just mention that there are issues with the two transceivers that we already replaced… but there is no further explanation how the machine behaves if these are faulty (to check that we are on the right way).
In the first part, I cleaned this little machine and convinced it to boot. Sadly, it died an hour after the first start. Anyway, you can see photos containing:
Video card self-check (color stripes)
ARC firmware for loading Windows NT (blue background)
SRM console integrated in the firmware for booting UNIX and VMS (black background) … yes, it has dual firmware
Digital Tru64 UNIX boot
CDE graphics environment
Today, I will try to replace two suspicious chips. Let’s hope that it will bring the machine back to life.
I’ve installed a new “hard disk” in my PowerBook 100 a few months ago. However, until now, there was no time to install an operating system other than the primitive System 6.0.8E that I used in the floppy-only mode. My goal was to have a Czech version that would allow me to read and write documents with our unique letters like Ř/ř. With a help of my friend, I got the floppy images of Mac OS 7.1 CZ and was able to copy them on real floppies (using my modern iBook G4 and a generic USB drive).
Working with old Macs can be painful due to use of file metadata (called resource forks) that can be lost very easily. Old Mac apps insist on this metadata and refuse to open a file if metadata is lost. Having a modern Mac is always handy to prevent these situations.
I don’t have a Mac serial cable. However, I recently bought two adapters for the conversion from Mac/SGI 8-pin mini-DIN to PC DB9. Connecting these adapters to a standard null-modem on both sides worked well and I was able to copy programs and documents from another old Mac. I’ve also managed copying files from/to a modern Windows PC. I pack the files into a ZIP file (to preserve resource forks) inside a Mac emulator and copy it using ZMODEM.
