Remembering the Camputers Lynx

Thirty years ago I reviewed the eight-bit Camputers Lynx for Your Computer magazine. Tony Smith picked up my review for a look back at the Lynx he wrote for The Register.

The Lynx was interesting. It had a solid case with a keyboard — a design like the Commodore 64 and Vic-20. In those days most British microcomputers had advanced technology inside, they were rubbish on the outside. This was different.

The Lynx had a better specification than its rivals. Camputers offered a higher resolution than competitors and packed the latest ideas in the box. As my review points out, it was well-suited for machine-code programming. Computer buyers thought this was important in the early 1980s.

As the Register says, the Lynx wasn’t a success. It arrived too late appearing at the end of the British microcomputer boom. And it was expensive compared with popular models. Camputers failed to attract interest from games developers. That proved fatal.

Guilty secret

Camputers included a printer port on the back of the Lynx. I mentioned this in another story I wrote about the machine but failed to mention the printer port didn’t work.

Much to my embarrassment my boss at the time, Jack Schofield, pointed this out to me. My excuse — not a good one — is that Camputers had earlier showed me a demonstration where the machine printed text. The demo must have been a non-production computer. I learnt an important lesson: don’t trust product demonstrations, trust only what you test yourself.

3 thoughts on “Remembering the Camputers Lynx

  1. Interesting machine, but it’s quite funny what was regarded as important — and too unimportant to mention — at the time. For example peek and poke being important, and procedures. And yet single-character variable names was an unimportant detail!

    All that would become absolutely moot in November of the same year when Turbo Pascal came out for CP/M at $49.99. You’d immediately be a fool to use anything else. (I was using it on both CP/M and DOS machines from the start of 1984)

    I also find the complaints about specifying sound by wavelength a little strange. It’s the natural way to make the function work internally, with a simple scaling from the wavelength to the number of times to go around a delay timing loop. A BASIC program to convert from note names or frequency to wavelength is less than 10 lines long (or would be if you could put more than one statement on a line!) but there’s no need to burden the runtime with that calculation (a floating point divide) for every note played, and no need to burden the ROM with a table that only some programs need.

    I’d like to see someone write an article comparing the capabilities of machines of this era to the wildly popular Arduino of today. The Arduinos are a little faster and have more analog and digital I/O capability but have vastly less RAM (more on a level with a ZX80). And have a very user-friendly IDE that lets you program them in C++ on a real computer (though they go to some lengths to *not* scare you by telling you it’s full C++).

    Like

    • When the Lynx arrived I had spent the past two years checking Z80 and 6502 machine code programs for magazines. I would wake in the night dreaming of sprite routines and the like. The code features in the Lynx seemed great, but as you
      say within a year it was all over for machine code programming.

      And by then I had the orignal 128K Mac. Turbo Pascal was (almost) my last brush with that kind of coding – although I spent some time with something called Z Basic and writing macros.

      Like

    • The main problem with specifying wavelength for music was the they weren’t accurate. And the inaccuracy wasn’t linear. I vaguely remember someone working out a conversion table mapping actual notes to the ‘wavelength’ input, but it was a waste of time because the inaccuracy varied from machine to machine. Every piece of music ended up sounding avant garde. Not necessarily a bad thing :-)

      Like

Comments are closed.