I am trying to avoid buying any old computer, but a friend of mine and I made an exception in this case and bought this together. Somebody in Prague offered a non-working HP Integral Personal Computer (1985) for $420. It was just 15 minutes of traveling from my friend’s home, so he visited the seller and told him that he would buy it if he could look into it, measure voltages and check for corrosion (either from caps or a leaked battery). The seller agreed. They briefly started the computer, but only horizontal bars were flashing on the screen. Then he disassembled the system, and everything was in pristine condition and all voltages were ok. After reassembling, he just paid and took it home.
When I visited the friend, he showed the computer. I asked him to start it so I could record a video of the error. To our surprise, the machine started directly into its HP-UX 5.0 UNIX system stored in ROM. Maybe the reseating of the internal boards helped it. Who knows. Anyway, we haven’t played with it more. I will first clean it and it is necessary to check capacitors in the power supply, repair the power button and check why the machine does the high-pitch sound when operating – it sounds like a hard drive which is not there.
I love how the machine looks like and it is even smaller than I expected. When carried, it is just as tall as my 1989 Toshiba T3200SX with a 386SX CPU, 3MB of RAM and a VGA gas-plasma display… and it is not much heavier. HP Integral Personal Computer is based on the Motorola 68000 CPU and has at least 512KB of RAM. In addition to the ROM storage containing the operating system, there is just a single internal floppy drive (720KB 3.5”). More storage devices can be connected using HP-IB though. I always wanted this machine. I even have a HP Journal magazine from 1985 with a very in-depth description of each internal component.
Last summer, I put new set of alkaline batteries in this portable beauty as I needed it for a photoshoot. A few months later, I used the machine also during a vintage computer event and (both times) I forgot to remove them. The stand-by energy consumption is apparently so low that nine months, the computer still holds the data in its RAM disk.
After years, I’ve finished a long in-depth write-up about an interesting piece of history – the SGI IrisVision 3D accelerator from 1990. It was a scaled-down version of the graphics board set from the SGI Personal IRIS and was intended for PC compatibles (16-bit AT bus) and PS/2 computers (MCA).
The whole thing started when IBM licensed the graphics hardware and the IRIS GL 3D API for their IBM RS/6000 UNIX workstations. Although the IrisVision was not very successful (like all 3D accelerators of the era), it is cool that IRIS GL programs could run under DOS.
At the end of the article, there is a video showing the card in action in a high-end IBM PS/2 Model 70 with a 25-MHz Intel 386 and 387.
I recently acquired a shiny Model 100 portable with necessary accessory. I played a bit with the machine before cleaning it and I was a bit surprised that it could retain data in the RAM disk for minutes after disconnecting the power. That gave me the impression that there was a backup battery inside, which scared me enough to open the machine immediately… and yes, although the battery still provided some voltage, it started destroying itself and the computer. I removed the residue from both the backup battery and the battery compartment for AA cells and cleaned the rest of the machine. It looks almost like new now.
I have to say that I am very impressed with the Model 100. The user experience is closer to professional computers of that time than home 8-bit machines. The programs in ROM can read/write the same files, switching between them is fast and there is even a shared clipboard. I particularly like the built-in terminal emulator with handy access to download/upload features and easy configuration. This was a true mobile companion for those working on the road and accessing the company minicomputer over modem.
My version does not have the modem, but at least the null-modem communication works flawlessly. I think I should install an old UNIX somewhere and try accessing it like in the old days. Somebody even created a Model 100 termcap definition file, so it is possible to use control functions of its terminal emulator in UNIX.
A guy contacted me that he found a complete TRS-80 Model 100 at the recycling center, ready to be destroyed. He was not a vintage computer collector but realized that it could have value for some, so he started to google somebody who can appreciate it and found my Czech blog. He wrote me a message that I could take it for free if I was interested.
… and I indeed was. This particular machine travelled to our country during the socialism era and it is quite rare here. I love portable computers of all kinds, so I am very curious to see whether this 1983 ultra-mobile machine was just a useless toy or a valuable companion on the road. The next step is to clean everything. The original suitcase started to disintegrate, and everything is covered with the black filth.
TIGA is a strange beast. Texas Instrument’s TMS34020 (introduced in 1990) was the holy grail of 2D graphics acceleration for a certain period in the world of PCs. This chip is fully programable general purpose processor, so you can offload even non-graphics tasks to it (my low-cost SPEA Graphiti HiLite 1024 has 1MB of program/data memory in addition to 1MB of framebuffer memory). If you add a floating-point coprocessor (like Intel i860 or TMS34082), you can create a 3D accelerator that processes both rasterization and geometry processing.
On the other side, fixed-function graphics cards soon became cheaper and faster, which took the mass-market appeal away from TIGA. There were also multiple reasons, why TIGA was not a user-friendly standard. Unlike CGA, EGA and VGA, TIGA has a vendor specific part of the graphics driver. That means that you cannot just put a TIGA card in your computer and hope that programs or operating systems listing TIGA among supported graphics standards will work. That’s the reason why most TIGA collectors not even try if their cards are in a working condition.
This SPEA card (like many other TIGAs) is supported in DOS and Windows 3.x only. You need to configure the card (the configuration is stored in its EEPROM), initialize it during every boot using a vendor specific driver and load a generic TIGA library. Once all the steps are done, you can run any TIGA-enabled program.
This approach means that there cannot be any generic TIGA driver for UNIX, Linux, Windows NT and other operating systems that cannot work with drivers loaded from DOS. Windows 3.x has a generic TIGA driver and one can be installed also in Windows 95, but that’s all.
SPEA didn’t bank on the generic TIGA support in programs. They provided “direct” drivers for multiple DOS CAD programs (including AutoCAD) and Windows 3.1. These drivers work only on compatible SPEA cards and bypass all TIGA libraries. SPEA made them more performance optimized for CAD work. The Windows driver also offers an easy way to change resolution and color depth. Only 256-color (8-bit) and true color (32-bit) modes are supported, so my entry-level board with just 1MB of framebuffer memory can show millions of colors in resolutions no higher than 640×400.
(The first photo shows the SPEA card compared to a standard “dumb” ISA SVGA card. This SVGA card is one of the best choices from the early 90s thanks to its fast Tseng ET4000AX chip and 1MB of 32-bit video memory.)
Although mounting remote HDDs over a serial cable to my Olivetti Quaderno was a nice solution, it was not very fast. I wanted to add persistent storage using a PCMCIA card, but Quaderno has just PCMCIA 1.0. I used to work a lot with PCMCIA, but it was always the newer standard (2.0) typical for 386/486 laptops. PCMCIA 1.0 does not support IO devices (so no ethernet cards) or CompactFlash cards (as they are IO cards in the ATA mode). PCMCIA 1.0 can work only with linear memory mapped cards. For linear flash cards, there were two incompatible standards (FTL and MS FFS). SRAM cards had just a single standard. In addition to all of this, simpler devices (industrial, embedded) required attribute memory on the card in order to work at all (fortunately, this laptop supports full Card Services and does not need it).
I took a 4MB PCMCIA SRAM expansion from my Amiga 600 and put it in Quaderno. The ROMDOS drive contains a Microsoft program called MEMCARD.exe (very similar to FDISK.exe, but for early PCMCIA cards), so I used it to format the card, rebooted the machine and got 4MB of persistent storage (the SRAM card has a battery to retain the data even after removing the card from the computer).
These early PCMCIA cards don’t work in Windows out of the box. However, there is already a DOS driver included in Windows 9x. You just need to add two lines in the config.sys and you can use the SRAM card in a “more modern vintage computer” (it still allows you to use the slot with other cards and use hot-plug features). Btw these direct mapped SRAM cards have one big advantage – they are super-fast.
I know it’s almost 30 years late, but I finally understood, how these old PCMCIA devices work…
You might think that the machine is useless without a working HDD and no floppy drive, but that is not true. Quaderno has a small bootable “ROMDOS” drive with basic system files, COMMAND.COM, a RAMDISK driver (up to 320KB of EMS memory can be used and you still have full 640KB of conventional memory) and Interlink software. This drive is interesting, because it acts like a read-write one. You can edit config.sys and autoexec.bat (the changes are there even after shutdown, if the CMOS battery is ok or AC is connected). You can even copy files there, but if it’s more than a few KB, the system will crash hard (requiring you to reinitialize the ROMDOS).
With Interlink, you can mount remote HDDs over a serial port. I used it to run VC (Volkov Commander) to edit the config.sys (no EDIT.COM in ROMDOS) and enable the RAMDISK driver. After this, I had my small but fast local storage (non-persistent) and everything bigger was started directly out of the remote HDD from another computer. This is a good way to test the computer before fixing the HDD or installing a flash/SRAM card in PCMCIA 1.0.
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?