But, of course, if you've read this blog for any period of time you know I don't go in for that sort of new-fangled nonsense around here. I like my retrocomputing frivolities period-correct. What the KIM-1 really needs as a mass storage medium ... is bubble memory.
Well, Marcio has uploaded the source code for Plua 2.0 itself, which I have patched up to build on my Power Mac G5. This is really great to see because now the runtime can be updated with more features and for more devices, particularly the wide-screen AlphaSmart dana.
When people think microprocessors that MOS Technology made, they think of the 6502 and its many derivatives, as one should (which are of course frequent topics on this blog too) — but there might have been another one.
In the nethermists of time when polyester ruled the earth, G-d (or at least Al Alcorn) created the Pong machines. These started out as discrete logic that was hard-wired to play the game, both in the original 1972 Pong cabinet and then miniaturized for the Atari 3659 Pong-in-a-chip that was in the first home Pong console (sold through Sears) in 1975. By greatly reducing the component count Atari's new chip made the console cheaper to produce and assemble, significantly aiding mass production. Here at Floodgap orbiting headquarters we have an original Atari Ultra Pong Doubles with the later C010765, referred to as the "ultimate" Pong with 32 game variations for up to four players, and the last and mightiest of the Atari first-party consoles circa 1977. Still, like the original 1972 Pong, it was nevertheless controlled by hardwired logic; ultimately it just played Pong, and that was it. But that's not what this entry is about.
The Pong console wasn't the first home console; that was of course the 1972 Magnavox Odyssey, developed by Ralph Baer as a side project for defense contractor Sanders Associates, and licensed to Magnavox for sale. (For that matter, it wasn't even the first home Pong console: that was arguably the Universal Research Labs Video Action II, which ran ads for Christmas 1974 in an attempt to sell unused inventory made for ailing Pong licensee Allied Leisure and beat most of the others to market in 1975 by a couple of months.) However, it was the first Pong-in-a-chip, something the other fledgling semiconductor companies had yet to duplicate. Texas Instruments was supposed to be developing a single chip implementation for Magnavox's sequel two-game Odyssey 100, but it wasn't ready until later that year for the Odyssey 200, and the 100 ended up with four chips instead despite its simplified games. But that's also not what this entry is about.
The other thing Magnavox had besides their early market advantage was Ralph Baer's patents, and a plausible legal case. Atari themselves capitulated in 1974, determining they lacked the resources to invalidate his patents, and paying a settlement and licensing them instead. Other vendors followed suit. One of these companies was General Instrument, who devised their own black-and-white Pong-in-a-chip called the AY-3-8500, also in 1975. Ralph Baer was aware of its development from the licensing process and had a previous informal relationship with toy company Coleco's president Arnold Greenberg. This exchange was all business: Baer's patents represented a significant source of income to himself and the company he worked for, and if GI could move a lot of chips there'd be a big piece of the action in it. Coleco became GI's first customer and built the AY-3-8500 into the 1976 Coleco Telstar, which went on to sell roughly a million units. The AY-3-8500 was thus firmly established in the market and even Magnavox used it for subsequent Odyssey consoles to the great chagrin of Texas Instruments, including the 1977 Odyssey 3000 which we also have at Floodgap Orbiting HQ. But that's not what this entry is about either.
The AY-3-8500 naturally had its competitors, and Magnavox-Sanders-et amis got a piece of them too, though the design was so cheap and easy to work with that General Instruments crowded most of them out of the market. Besides TI, National Semiconductor introduced the colour MM-57100N, but despite its capabilities was too expensive to dislodge the market leader (and even its graphics advantage was eroded by the AY-3-8515, which was a bolt-on colour encoder for the 8500 and incorporated into later chips). However, there was one company at that time that was very good at making cheap chips cheaply, and it needed money fast. That company was MOS Technology, and finally that's what this entry is about.
And what are those supported platforms? Why, here's some of them as they were being cruelly whipped to perform like beaten dogs for your entertainment:
Let this paragraph represent a right to use, distribute, modify, enhance, and otherwise make available in a nonexclusive manner CP/M and its derivatives. This right comes from the company, DRDOS, Inc.'s purchase of Digital Research, the company and all assets, dating back to the mid-1990's. DRDOS, Inc. and I, Bryan Sparks, President of DRDOS, Inc. as its representative, is the owner of CP/M and the successor in interest of Digital Research assets.This was to clear up an apparent earlier misunderstanding that Sparks' earlier open release of CP/M in 2001 was restricted to distribution via a particular site. Sparks clarified this was not his intent.
Overall, would I prefer a more conventional open-source license? Sure. But he didn't have to do this then, he didn't have to do this now, and he did. So, thanks, Bryan.
However, because QEMU is a much lower-level emulator, that means that things like mice are also emulated, and that tends to chug a bit even with QEMU's JIT (currently KVM-PR, the virtualization system for Power ISA, does not work properly with Mac OS 9 in QEMU for reasons that have not yet been determined). If you use the default mouse support, the mouse is entirely maintained by the operating system and the polling frequency is just slow enough to be frustrating, and you have to grab and ungrab it all the time. The normal solution is to use an absolute pointing device like the QEMU tablet and solve all these problems at once, but the classic Mac OS doesn't support it and the existing Wacom driver doesn't work. (SheepSforza, on the other hand, hooks the system mouse and system mouse pointer into the guest OS, so it's much more responsive and transparent if I do say so myself.)
To support this and other QEMU virtual devices requires updating the guest Mac. And, happily, there are now two approaches at least for doing so for the QEMU tablet, which make an interesting comparison on how we could get other devices supported on the classic Mac OS.