News for the ‘History’ Category

Eye Candy : Apple’s Tablet Computer R&D History

Fabulous collection of prototype Apple hardware designs. Be prepared for a wave of powerful nostalgia for things that never were but could have been.

Via Daring Fireball.

Posted: November 11th, 2010
Categories: Apple, History, Tablets
Tags: , ,
Comments: View Comments.

October 14th 1985…

Stroustrup had been hacking away at his replacement for the C programming language at AT&T Bell labs since 1979, where he and his colleagues in the research department were given free reign to experiment with new ways of building software.

I was 10 years old. A handful of years later I would get a Commodore Vic 20, and learn BASIC. Shortly after I would jump into machine code, and never look back.

[October 14th] 1985: The first official reference guide for the C++ programming language is published.

I learned today that not only do I share my birthday with Cliff Richard, I also share it with my second language; C++. My first language being machine code.

When I was writing games for home computers, and arcade games I simply did not get what C, or C++ was all about. The transition in the games industry from machine code to C++ was like a tidal wave of terror for me. So much so that I ran from job to job where I could still craft in what I believed at the time was the one and only language I would ever use.

C++ went on to become one of the most popular programming languages ever created. It was designed to be a “general use” language: It can be run on just about any platform, and it shows up almost everywhere, especially in videogames and embedded systems.

Although I am still most at home coding in ASM, C++ has become my native language these days. The main occupant of the bag of tools I now take to work for most jobs I may encounter.

I do still have a little black wallet, lovingly wrapped in wax paper, in my tool box, tightly packed with little op codes for those special occasions. And of course a big brightly coloured plastic bag full of Objective C.

I guess if I had thought of it and had some marketing sense, every computer and just about any gadget would have had a little “C++ inside” sticker on it.

Imagine if Microsoft had got its hands on Stroustrup!

Fantastic interview with Stroustrup, from Michael Calore for Wired. Well worth a read.

Posted: October 14th, 2010
Categories: History, Programming
Tags: ,
Comments: View Comments.

Ars Technica : Amiga gaming retrospective

Great retrospective on one of the machines that also featured in the foundations of my career in gaming. Can’t wait for the next instalment.

The Amiga’s rich, 4096-color palette demanded people who were skilled artistically to create the sprites and backgrounds. The four-channel sampled sound chip cried out for musicians to make it sing. The larger size and complexity of the games required that someone other than the programmers be asked to test the games before they were released.

Its fun to read those specs and compare them to what we have today. And then remember just how exciting those specs were to us as programmers and artists!

Clashing egos and arguments, fights over poorly-worded or non-existent contracts, and disappearing funds would stretch friendships to the breaking point. When a studio was in desperate need of cash, developers and artists would work 16-hour days and beyond. Managers would call up contract workers at 2 AM to make sure they were still working. Miha Rinne, who worked at Terramarque, told me how his supervisor demanded that he write down all the time he spent writing notes, doing backups, and even going to the washroom! He later took his experiences in the game industry and made a comic out of it, which can be found here.

Good times!

Still, to really understand the power of the Amiga’s chipset, there was only one reference guide that really mattered: Commodore’s own Amiga Hardware Reference Manual. This was the Bible for Amiga game developers.

When I was developing for the Atari XL range of computers I had to make my own Hardware Reference manual by peeking and poking my way through memory and figuring out what did what. I learned about sound, and graphics on the machine in totality from personal research! You can imagine how much time The Amiga Hardware Reference Manual saved us as developers.

It let dedicated explorers discover how the Blitter chip blasted graphics directly from memory to the screen, how the Copper let the programmer jump in and change the way the display worked even in the middle of scanning a line on the screen, how the audio chip offloaded sound processing, and how the CPU synchronized all these activities together.

Remember it all so well, even to this day. Poking around inside any of Jay Miner’s creations is always an awesome experience. I have fond memories of Display Lists (completely different from OpenGL Display Lists) on the early Atari XL Computer chip sets.

Still, for raw speed and power, you couldn’t beat 68000 Assembly language. On early Amigas, memory was at a premium: the market consisted of machines like the Amiga 500 with 512 KB (that’s kilobytes, not megabytes!) of RAM, split between “chip” (memory dedicated to the display and custom chips) and “fast” RAM. Getting everything to work smoothly, without flickering and at high frame rates, took a lot of mental juggling.

One language to rule them all! And the kind of memory space I still feel most comfortable in!

Consider the task of Cesare Di Mauro, developer of USA Racing. He wanted a target of 50 frames per second to retain a smooth experience, but this, combined with RAM constraints, meant that it was impossible to use double-buffering (a technique where a second screen with the next frame of action is stored behind the scenes in memory). Using a single screen saved execution time and memory, but made the task of scrolling the background and updating the BOBs (blitter objects, similar to sprites) much more difficult.

His solution consisted of a 352 x 272 virtual screen, with only 320 x 240 pixels viewable at any time. The area was divided into two vertical slices, combined to show a single view. The background consisted of 32 x 32 pixel tiles, arranged in a large map of 4096 x 65536 pixels (coders everywhere will recognize those numbers).

Juggling the number of tiles, the BOBs displayed on top, the music and sound effects, and collision detection with walls and other cars was a huge challenge. Cesare ended up writing a tool in assembly language that handled all of these at 50 frames per second, sorting drawable objects into a display list to maximize performance. The program would first display all BOBs in-order on the list, then update hidden areas to handle scrolling (horizontal scrolling was handled by the graphics chipset by setting a scroll register value, while vertical scrolling was similar but more complicated), then waited for the monitor’s display beam to reach the bottom position of each BOB to restore the background they had “stained.” He wrote custom routines for sound and even disk access to maximize speed and minimize RAM usage.

This sort of careful balancing was typical of game programmers who wanted to push the envelope. Many of the concepts they came up with would be recreated as part of industry standard libraries much later—display lists, for example, are a crucial element of Direct3D.

This account brings back so many memories for me also. And is one of the reasons I enjoy working on the iPhone today. Even though it has a lot of modern features, with VFP, Neon and mobile GPUs, with the limited memory footprint, and constrained resources, a lot of my kind of early industry experience comes into play again.

Posted: June 14th, 2010
Categories: History
Tags: ,
Comments: View Comments.
Get Adobe Flash playerPlugin by wordpress themes