Affordable computing by rotating bits at 3700 rpm.
In July 1956, when IBM was still considering its answer (which was to become the IBM 1401) to the French challenge that was the Bull Gamma 3 (1952), then posing a serious threat to IBM’s monopolic line-up of punched card appliances, Librazette, Librascope’s employees’ and PR gazette, proudly announced that the company’s new LGP-30 computer had been promoted to production.
The computer had been developed by Stan Frankel as the MINAC at CalTech in 1954 and Librascope had bought Frankel’s design (apparently in the same year), releasing it as the LGP-30 in 1956. (…)
The computer generally known as the Royal McBee LGP-30 was a desk-sized appliance and weighed in at about 800 pounds (360 kg). It came with a Flexowriter-style console typewriter and consisted internally of just 113 vaccum tubes, 1,450 solid state diodes, and a magnetic drum for memory (4K of 31-bits words) and 3 registers. It plugged into an ordinary wall socket, from which the combined circuitry drew up to 1500 Watts. All this could be yours for just US$ 47,000 ($433,000 in 2018), which was actually the first viable option for small-to-medium scale computing.
“Today, you are an Astronaut. You are floating in inner space 100 miles above the surface of Earth. You peer through your window and this is what you see. You are people watching. These are fleeting moments. ¶ These videos come from YouTube. They were uploaded in the last week and have titles like DSC 1234 and IMG 4321. They have almost zero previous views. They are unnamed, unedited, and unseen (by anyone but you).”
This is a great little project! — Don’t fail to experience this inner journey through these ghostly voids of abandoned footage! Ephemeral at its best! Chapeau!
A recent discussion on the Retro Computing Forum turned my interest towards the DEC PDP-7 in general and it’s peculiar lack of a dedicated instruction for two’s complement subtraction (or, that is, subtraction at all) in the absence of a two’s complement negate instruction …
mass:werk proudly presents: Running BASIC on a virtual PET 2001 from URL-data.
So you want to show your friends a little BASIC program or want to solve some problem with (retro) style? Despair no more, since help is near…
More specifically, just a click away, at www.masswerk.at/pet, where you find my enhanced version of Thomas Skibo’s in-browser PET 2001 emulation. What’s new is an additional mode, where the emulator loads (and runs) a program from data encoded in URL-parameters — as provided either in the query-string or in the URL-fragment (hash). And you may use this for immediate execution in direct mode, as well!
On the origin of digital video games and the complexity of classification.
When it comes to the first known digital video game (i.e. an interactive game implemented on a digital computer communicating its state by some kind of graphical display), it’s always also about a question of definition. Personally, I’d opt for a requirement of a digital computer running a simulation in real-time and providing means of interactive manipulation of said simulation by some kind of user input (without any interruption to the flow of the program). By this, we define a distinctive problem class for this, namely interactive, visual real-time computing. So a turn based game, like OXO, wouldn’t be a member of this class, while, say, Spacewar! would happily fit the definition.
So I’d like to divert your esteemed attention to a certain, lesser known edge case, “Pool”, implemented by William George Brown and Ted Lewis in 1954 on the one-of-a-kind MIDSAC computer.
Investigations into a lesser known bug in Commodore BASIC abbreviations.
There is a well known, special feature of the BASIC implementation of Commodore 8-bit machines, namely abbreviated BASIC commands. While this is probably more a bug than a feature, this bug has a curious bug of its own. Reason enough to start an investigation.
Why are there these abbreviations, how do they work, and, what could possibly go wrong?
A closer look at the glyphs drawn by the DEC terminals VT100 and VT220.
Recently, I engaged in a bit of analog media emulation, namely for the purpose of the reenactment of raster CRT graphics as seen on “glass terminals” like the iconic VT-series by the Digital Equipment Corporation (DEC). An endeavor, which raises a few questions, like, is there anything special to the media, what did the fonts really look like, and can we reconstruct them from specifications?
Since ROMs are available (and modern TrueType fonts, as well), we may start there, since they are the closest, we may get, to the real thing, aren’t they? What could possibly go wrong?
Images from the outer limits of numeric precision.
Take any numeric renderer which allows you to zoom in repeatedly. For instance a Mandelbrot set renderer, because, Mandelbrot sets are always fun. For instance this one (by your’s truely). As you keep zooming in and zooming in, after a while, eventually, the rendered image will suddenly show pixelation. And as you are zooming in again, the pixels will increas in size. However, this is not a fault of the visualization layer, it’s just that you hit the mathemitcal barrier of numeric precision. The grain in binary computers…