I recently mentioned PCMCIA linear memory cards (both SRAM and flash) that existed before PCMCIA controllers started to support IO devices and ATA. I used such an SRAM card in my Olivetti Quaderno subnotebook instead of its failed hard drive. Quaderno boots DOS from the internal ROM, loads a driver to support SRAM and allows using it as an additional drive. However, there were also laptops that supported booting from PCMCIA cards, and I am surprised that this feature was not uncommon.
Certain 386/486 laptops with Phoenix BIOS have “PCMCIA” in the boot device list (in addition to “hard drive” and “floppy drive”). These support just linear flash/SRAM cards and let you boot DOS out of the card mapped as A:. Everything works just fine and you don’t need to load any PCMCIA driver. ATA PCMCIA and CompactFlash drives are not supported here – they are ignored by the BIOS module.
The laptop with AMI BIOS could have an optional “PCMCIA Boot Function” module. Once it was enabled and a card was inserted, the system booted from PCMCIA and mapped the card again as A:. However, the support was flaky – just good enough to load a proper PCMCIA driver during OS boot.
Laptops from large brands (like Toshiba) mostly didn’t support this feature. ThinkPads were an exception (486 and maybe also early Pentium ones). According to some owners, they even supported booting from ATA/CF cards. However, ThinkPads as well as the laptops with Phoenix and AMI software did not provide a driver-less access to PCMCIA cards if a user booted from a different device. It seems that there is only one known laptop that supported this – MiTAC 4022.
This is my new project for next few months – SPEA Graphiti HiLite 1024 – a TI TMS34020-based professional CAD card (“TIGA”). The video output does not work properly as some traces between the GPU and RAMDAC are bad, but the rest of the card seems to be ok. Once I fix it, I would like to play with the chip and program some benchmarks to see the real performance. It looks like TIGA cards are valuable among collectors, but there is very little info about what can be done with them. TMS340x0 chips are fully programable 32-bit integer CPUs and this (rather low-end) card has 1MB of program/data memory (in addition to 1MB of framebuffer memory). It is like a complete computer on a card.
These chips were used in the graphics subsystem of Sun 386i UNIX workstation and some CRT terminals (like DEC VT1000). There were even Amiga Zorro cards with these chips (boosted with TI floating point co-processors), but presumably the concept was too complicated at the time when most people cared just about BitBlt and basic acceleration of line drawing.
(fortunately, my Siemens Nixdorf PCD-4Lsx PC is just big enough to accommodate one full-size ISA AT card… the card is very picky and refuses to work on Pentium systems or anything with ISA clock beyond ~8MHz)
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.
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?
David asked me if I could help him with transferring all files from the pack of floppy disks he used during the late 80s with an 8-bit Atari (800XE). We are working on the Atari version of our Sieve Benchmark (to compare the performance of old computers) and he told me that, as a kid, he created many assembly programs that can now speed up the development . The ultimate goal is to compare extremely optimized assembly versions of the benchmark for 6502, Z80 and 8088 to find out, which CPU is faster.
I didn’t have any modern disk emulator for the system so I transferred the files to the PC the old way. I used Atari 800XL and two floppy drives (1050 and XF551). At the beginning, I had just one drive, but then I realized that I was not able to create at least a small RAM disk on a 64k machine with MyDOS – that would allow me to copy files from one disk to another without using multiple drives (this is not straightforward when each of the disks has different density).
Copying files to different disks was necessary. David used the 130KB “ehnanced density” format that is not readable on floppy drives in PC. The Atari XF551 disk drive supports all the Atari formats up to the 360KB double-sided double density that is sort of compatible with PC drives. With the two drives connected to the Atari, I copied the files from the old disks to a few “new” ones and started searching what is necessary to do on the PC side.
At the end, I used two MS-DOS programs – ATUTIL for reading/writing individual files and WRITEATR for creating ATR disk images out of real floppies. All of this took me two evenings, but I’m happy that I didn’t have to use modern hardware to copy files both ways between 8-bit Atari and PC.
(btw David also decided not to use modern hardware so he is programming directly on the Atari 800XL with Atmas II macro assembler from 1985)
I was asked by my manager to download data from multiple boxes full of floppy disks he used in the early 90s. I’m used to people at work asking me for help with old UNIX systems, but reading 5.25-inch floppies is here for the first time. He used to be a musician when he lived in Israel and used his 386 PC as a sequencer with an E-mu Proteus/1 external wavetable synthesizer.
I picked my Vienna 286 computer to read the floppies. It’s quite a high spec machine with an 8MHz CPU, math coprocessor, Hercules-compatible Graphics and 1.5meg ISA RAM card… and it’s my only computer with a 5.25-inch drive. If you ask why I removed the CRT before I started copying the files, ugly mold smell goes from it every time it’s turned on and I hate it. I rather configured the machine to work in a headless mode (straight boot into Microsoft InterLink Server) and accessed the drives from a laptop over a null-modem cable.
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.
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.
