Oh, Those Wacky Computer People

February 16, 1997

I swear, I'm going to have gray hair by the time I turn 23. Stop me if you've heard this one before:

"As per the request of the German liquidator Of Amiga Technologies GMBH, QuikPak Corporation of Norristown Pennsylvania, has submitted a final comprehensive bid for the assets and intellectual properties of Amiga.

According to David Robinson, US legal counsel for Mr. Hembach, all offers must be in by January 31, 1997, midnight. During February the offers will be reviewed and a winning bid will be selected by the 28th of February, 1997.

QuikPak remains committed to the future of the Amiga Platform. We believe we have submitted a "winning" offer. As soon as the outcome of the bidding process is evident we will make the appropriate announcements to the public.

QuikPak would like to take this opportunity to thank all the Distributors, Retailers, Developers and especially the customers and end users who have shown their support for us in these troubled past months. We have continued to manufacture and develop Amiga Products because of our respect for the original creators of the Amiga. We share their vision of affordable multi-tasking, multimedia computing for the family. Although it may have seemed that our focus was aimed at the video professional, we remain committed to reintroducing the entry level Amiga back to the marketplace with 1997 features."

But in any case, QuikPak doesn't have a PC clone business to weigh them down. They're a manufacturing company. Petro Tee (one day I'll learn to spell his name) selected them in 1995 to make 4000 towers, partly because they were in the United States which is where the 4000's major markets were supposed to be: video production. QuikPak specializes in IC fabrication and motherboards and the like; their major focus is short-run, esoteric systems, and let's face it, you don't get much more esoteric than the Amiga 4000. Petro chose them because they could get 4000's out the door quickly and without going TOO astronomical on the cost - $2700 wasn't cheap, but let's see YOU build a Commodore-like manufacturing center and whip out Amigas on short notice and get the prices under the $3500 mark. QuikPak is still not the cheapest place to have computers made, not to mention certain stages of the 4000T's are assembled by hand, but at least they're quality - not like those "empty case" Amigas Commodore occasionally shipped. (The Bandito once tried to tell us this was a problem specific to C= Asia/Pacific, but Digital Arts in Bloomington has more than once received Amigas from Commodore minus important parts like the motherboard.)

Anyway, QuikPak is based in Norristown, right up the road from West Chester, probably not far from where Commodore Engineering breathed its last. Several of them are ex-Commodore people - from the chip labs, mostly, the "industrial" Commodore guys who lived on the production line. Somewhere along the line, they decided they liked the Amiga. When SMG took to the parachutes with that surreal "Get out while you still can" message, Petro told QuikPak they were to take up the reins and fill in where SMG had been failing for months anyway: North American distribution, marketing, and warranty service.

Anyway, the first thing QuikPak did was to start selling straight to the dealer channels - CEI, Software Hut, and MicroPace - at prices below anything SMG ever hit. Then they started bringing the prices gradually down as production ramped up - again, something unheard-of in the SMG regime, if the cost of manufacturing went down, SMG would pocket the difference.

And then QuikPak did something truly remarkable: they started designing new systems. On their own. With no help from Amiga Technologies or VIScorp. Real systems, too, not that black plastic penis thing Amiga Technologies tried to impress us with - the case itself wasn't my big complaint, actually, it was the 40MHz 68EC030 innards, nonstandard expansion, and un-Amiga-like hardware that bugged me. No set-top boxes, either. These were REAL systems, COOL systems, high-end stuff.

First up was shipping A4000T's with 68060's. Amiga Technologies never got around to that part - thinking the five-year-old 25MHz 68040 technology was enough to placate its American customers. Yeah, you can always go buy an accelerator - but then you're stuck with an A3640 card and a spare processor you'll never use (those cards apparently can be made to work in an A3000, btw) and you PAID for that 68040 card you won't use. Why not ship the damn thing with the 060 already in there? QuikPak agreed with that sentiment. The next question was, which 68060 card to use? RCS' Fusion Forty? The Phase 5 Cyberstorm? Some other off-brand? No - QuikPak made their own, the 4060T, and included that instead of the 3640. (To use the Commodore board naming conventions, the card should have been called the 4660, after the 2620/2630 and 3640; 4xxx for the 4000, x6xx for accelerator, and xx60 for the chip. But that's boring trivia.)

Then came the prototypes. Everyone saw the pics in Amazing, of Jason Compton showing off that weird-looking black-case luggable. That was QuikPak's design, an A4000T-spec motherboard in a 1985-Compaq-style black case with detachable keyboard and movable active-matrix LCD color screen. The unit looked very much like a black version of the Silent Paw 4000 case. This particular prototype had expansion slots, and could host a Video Toaster - just in case you've ever needed to do Toaster work in the field.

The next, even odder prototype, was an A4000T with an LCD panel that hinged out from the side. That one scares me.

And then came the Pentium Amiga. Using HiQ's "Siamese" system - not, repeat NOT a bridgeboard - this unit had an Amiga and a Wintel system sharing the same case, networked together internally and sharing the same devices. The resulting system had Zorro and PCI slots, and could run Amiga and Windows 95 side-by-side sharing drives and data, like a modern bridgeboard from hell. (For those just joining the party, the Bridgeboard was a special two-headed expansion card for big-box Amigas; one end plugged into a Zorro slot, the other end into one of the ISA slots found in the 2000 and up, the board contained an Intel processor, either an 8088, 80286, 80386, or in the case of one third-party board, an AMD 486SLC. You could plug PC expansion cards into the ISA slots, run PC software alongside Amiga software across the bridge, exchange data between platforms, and even use PC expansion cards from the Amiga side - Caligari 24 worked this way, using a bridgeboard and a Targa video card to generate 24-bit displays before Amiga 24-bit cards became available. The Bridgeboard system is now quite limiting, it doesn't support anything newer than a 486SLC at 25MHz, it still works on 16-bit ISA, and often requires two monitors and mice. The Siamese system allows you to use the Amiga monitor, mouse, and keyboard to control the PC side.)

Nowhere in QuikPak's prototype gallery is there a set-top box.

Admittedly, QuikPak isn't making a big effort to build a low-end Amiga, but then, as Haynie the Hardware Master will tell you, the one-piece plastic A1200 case costs MORE to make these days than storebought PC clone cases. Maybe QuikPak hopes to put the prices of the A4000T down through the floor before long, and sell THAT as its low-end system. Maybe they're hoping to get Solectron in France to make another A1200 production run. Maybe they've got something up their sleeve they aren't telling us yet. Maybe they don't think there's a market for low-end Amigas anymore. But they're taking "real" Amigas seriously, which VIScorp never did - and for that matter, neither did the rest of the industry.

I'd much rather have to convince a company who only makes high-end Amigas that there's a market for low-end, than the other way around. QuikPak doesn't see anything funny about an Amiga in a tower case standing next to a PC. VIScorp seemed to find the notion of set-top box technology in a "real" computer case amusing. A company that already takes the Amiga seriously as a computer is more likely to give us the respect and support we need than a company who just wants to make an AGA channel-changer. Yes, an Amiga TV-top unit would be neat, but it already exists - it's called CD32.

Anyway. So QuikPak is the first company in years who wants to buy the Amiga for the sake of the Amiga, not for PC clone technology, not for the brand name, not for goofy "set-top" crap. Even if they AREN'T the best company for the job - they care enough about the Amiga that they can be convinced what IS the right way to do things, and maybe, just maybe, they would be willing to outsource cost-critical components to the Philippines, if that's what it takes. They're American so they understand the market, but they don't have the same head-up-the-ass perspective VIScorp had. They certainly have the technical know-how to push the Amiga a little farther down the road - at the very least, giving us new and technologically capable 680x0-based systems to keep us smiling until Phase 5 and the others finally deliver the nifty toys.

Oh, and speaking of RISC Amigas...

PIOS and ProDAD (what's with all the P's?) have struck a deal. PIOS, as you know, is Stefan Domeyer's new company, they currently have such names on board as Peter Kittel, Andy Finkel, and Dave Haynie; their goal in life is to build a Power-PC-based Amigasystemthingielike. (That's a very German-looking word - but is the best way to describe what they're making, they can't come out and call it an Amiga, but they won't dare admit it ISN'T an Amiga.) So right now they're making a thing called PIOS One - a PPC-based consumer system with mostly off-the-shelf parts.

Anyway, PIOS finally pulled an Apple and realized they can't make the OS in-house. They do have Andy Finkel onboard, so I'm not entirely sure what the story is - maybe they all decided he just didn't have the resources available in a 15-person company to build an OS worthy of the name. Whatever the backplot, the known fact is that PIOS and ProDAD are gonna put P-OS on the PIOS One.

Wahoo! Last time, you'll recall, I extolled the virtues of P-OS as a potential AmigaOS 4.0 - it runs happily on 680x0 and PowerPC, and is "source code" compatible with existing Amiga applications. What I failed to note was one other awesome feature of P-OS: it can run alongside another operating system! The question of compatibility is thus answered: use P-OS alongside AmigaOS on your 68030/040/060 systems, recompile things for P-OS as you go, and finally start migrating everything to PowerPC P-OS. Having P-OS ship on high-profile machines (in the Amiga market anyway) should help boost its acceptance, much as Power Computing's bundling of BeOS for Power Mac should help that system's market share.

Oh, speaking of the Mac...

First up, the BeBox is now a museum piece. Be, Inc., in a move eerily reminiscent of NeXT, has suspended their hardware development and discontinued their proprietary BeBox, focusing entirely on BeOS for Power Macintosh. No word on how long they will continue to support the BeBoxes that have already been sold. They do, however, already have BeOS working on multiprocessor Mac hardware, including DayStar's quad 200MHz 604e monster. How much impact the BeOS will have on the marketplace now that Apple's gone elsewhere for its OS, that's still up in the air - but there's no doubt the BeOS will find its niche, much as NeXTSTEP did years ago.

And now to Apple itself. You'll notice for a laugh, on my "links" page, www.next.com is listed as "Apple Computer - operating systems division." That's only 90% accurate - NeXT's WebObjects is still being sold, supported, and developed. It's quite a cool package itself, an object-oriented Web database solution based on NeXT Objective-C, and an awesome in-road for Apple to start selling business solutions. I have this feeling once we get an NT system running here at Compassworks, WebObjects' free version is gonna have a home on it. And when they port WebObjects to the Mac, which is probably inevitable now, expect to see it ship in a bundle with WebStar or other Web server software. It would make an awesome self-contained Mac Web server package - handy for building online catalogs, something a lot of Mac dealers need desperately. (Shopped on the Web for any Mac hardware lately?)

But anyway. After Apple's "surprise" profit in Q396, that $29 million they found at the last minute, this past quarter they more than made up for their profit by losing $120-odd million. This does NOT reflect the $400 million purchase of NeXT, which will be written off partly as R&D costs and partly absorbed over the next few years. Apple's hardware sales have dropped a few percent, their market share is still sliding down (although not as rapidly as this time last year), and in general this last year just didn't end on the happy smiley-face note they wanted.

Well, in the "here we go again" department, Apple has just announced another restructuring, yes it's not been that long since the last one. Gil Amelio, "Captain Comeback," is trying one more time to earn his keep; the last restructuring split Apple into a number of mostly-independant divisions, which he says he likes, but he's also now said Apple will not return to that kind of structure until it turns profitable again. He's also decreed that there will be no more executive bonuses until "this baby shows a profit."

The various NeXT divisions are being brought in closer to the fold; for example, there is one sales division now, responsible for Apple, Claris, and NeXT product sales.

No one is yet talking about discontinuing product lines, although that's certainly a possibility. Apple has already decided to drop the Performa nameplate, although they aren't discontinuing the consumer mid-range Macintosh line, they just aren't going to call them Performas anymore. There will only be two Mac nameplates from now on, the Power Macintosh and Powerbook; for those who remember the brain-draining days of seeing the Mac II, LC, Performa, Centris, Quadra, Powerbook, and Power Mac all on store shelves at once, this is a relief.

But renaming models is one thing. Persistent rumors of the imminent demise of the Newton are something else. Newton handhelds and the Pippin set-top-box architecture are the two leading candidates for the ax, according to the spy network. Pippin, in any case, is a finished architecture, and Bandai is more than welcome to continue making systems based on it; Newton, on the other hand, is one of the niftiest new technologies of the decade, and I'd hate to see it go. It's got a much easier to use OS than any other handheld, and with the new models based on 190Mhz StrongARM processors, it's probably the fastest handheld computer in the world. It's a new, beautiful way to look at an OS - document-centric instead of file-centric or application-centric - and is touted by many forward-thinkers as a model of what the future of computing could look like. Imagine a Newton-like system for $20; that's a truly beautiful future.

I'd be much happier if they just dumped Pippin instead.

Anyway, Avadis and his pals over in OS development finally picked a kernel. NeXTSTEP isn't an OS by itself, it sits on top of a microkernal. It was originally built for Mach, although it has since been ported to the Solaris kernal and to a Windows NT kernal; there was a rumor that Apple might actually use NuKernal, the microkernal the late great Copland would have used. But the official word now is that they're going to use Mach.

The cool thing about this? Just how long has Apple been considering NeXTSTEP? Apple had never been particularly helpful to people trying to port third-party OSes to the Mac, which was part of the reason why Linux/68K never made it to the Mac (despite being ported to the Amiga, Atari ST, and various other 68K hardware). Then, wacky enough, out of nowhere came this third-party Linux port for Power Macs, with Apple's official blessing and in fact an official Web server hosted at apple.com! Power Mac Linux, as it turns out, is two things: Linux ported to the Mach microkernal, and Mach ported to Power Mac.

Thus a large part of porting NeXT to the Mac was done last year - with Apple's encouragement and assistance.

It's worth noting that Avadis Tevanian was part of the Carnegie-Mellon team that designed Mach in the first place.

It's now just a matter of time before people start making awful jokes from "Mac" and "Mach." You have been warned.

The final wacky piece of Apple news? They're bringing back Steve - the OTHER Steve, Steve Wozniak (designer of the Apple I and II) will join Apple as a consultant, alongside Steve Jobs. The more things change, the more they look like they did 20 years ago.

And speaking of which, your mission, and you will accept it, is to go see Star Wars: Special Edition. Yes, they broke a few scenes trying to "fix" things that were never broken, yes, the dewback thing is pointless and self-indulgent, but the whole effect is to take the 1977 stuff out of the movie (with the exception of the sideburns) and make you forget you're watching a late-70's low-budget sci-fi flick with cardboard sets and plastic models. Those of us who'd never seen it on the big screen were left utterly brain-dead once the Star Destroyer appeared the first time - the trailers were right, if you've only seen it on TV, you haven't seen it at all. And you'd be amazed just how much original 1977 special effect footage remains intact or only slightly altered - and how well some of those models-and-optical-matte shots hold up alongside modern CGI. Mos Aisley you will love. Jabba you might or might not like. The dogfight at the end is exactly how you saw it the first time - NOT how it actually was: high speed action, not sluggish models and cheap fireworks. Lucas got what he wanted: the special effects get the hell out of the way and let him entertain you.

And since I couldn't think of another category for it, there's Lava. You know about Java, Sun's C-like "semi-interpreted" platform-independent programming language, famous for slow animations and weird out-of-memory errors in Web browsers. Lava, aside from the word itself, has nothing to do with Java. Lava is phase one of Carl Sassenrath's "future of computing" project: a programming language that doesn't chain you down to some other programmer's notion of what you should be able to do. C/C++, as you probably know, as well as Java, are little more than "answers to a question" - despite all the wonderful data types, object-orientation, and structure, these languages still require you to use pointers at some point - essentially deferencing memory at a level only slightly above machine language. They're industrial languages, not in the slightest are they designed for people like you and me to just whip up a shell program to copy 150 files in numbered order, four at a time (which I needed to do the other day!). Lava is supposed to get around such problems.

I have no idea what the innards of Lava are supposed to look like. I know I've been doing some thinking myself along these lines lately, about Perl in particular as a "natural language" in which you can express yourself with only a minimal knowledge of the language, and get better as you learn more tricks. Most Perl programmers these days are at the equivalent of "Want Mommy" - the best gurus are at Shakespeare. My own Perl skills are somewhere near "I wanna blanket." Any of these can communicate - my Perl stuff, despite its nasty structure and set-myself-up-for-disaster coding practices, actually works and gets the job done remarkably well. I could wish for the skills of the Perl gods - what I do in twelve lines, a Perl Jedi could probably pull off in one line with a craftily placed question mark. It says much about the difference between Perl and C, that C has an "obfuscated code contest" while Perl has both the obfuscated code contest and a "poetry contest." It's possible to write working Perl programs that look like English - aside from the dollar signs. C can do that only with lots of #define statements. In any case, SuperCard has it all beat - "get the sum of 2 and 3 and put it into A" is a valid statement. But I'm going in wacky directions here.

My opinion of Lava itself will have to be reserved for when he has a language spec that he can publish, so I can decide for myself whether it's really the quantum leap he's promising. What I do have to note, however, is that Carl is not getting paid to do this project. (VIScorp still owes him money anyway.) He's soliciting donations - at several "contributor" levels, ranging from $50 to $1000 and up, with various levels of nifty benefits: autographed LAVA release disks, mailing lists, web site banners, and the like. One does not build a new programming language of this level without some kind of funding... actually, he's more concerned with the next phase, the Magma operating system, which WILL take some money to build.

Carl intends to make Lava run initially on Amigas and PCs, with minimal specs; Kickstart 2 and a meg of RAM, I think, is his planned baseline, although he intends to make a 1.3-compatible version eventually (you remember 1.3, don't you?) - for those with CDTVs that cannot be easily upgraded. He says it's fairly easy at this stage to make Lava run on PC's with 5-10% additional effort; how long it stays that way remains to be seen, once he starts adding networking and multimedia to it, supporting Windows is gonna get more and more complex. He does, however, want it to run on PC's - so it has a chance of market acceptance. His intention with the language itself is to make it simple to do simple things - his catchphrase of late - he says it should be easy to write shell scripts, CLI commands, and even editors and directory utilities with it. (Write your own DOpus!) How he handles windowing abstraction is still a mystery - by this I mean windows and gadgetry, in a cross-platform manner, so the same Lava program can open more-or-less-similar interfaces on both the Amiga and PC - Java currently sucks at this, and most other cross-platform interface builders tend not to be compliant to the style guides of any of the platforms they target to - assuming they use the OS at all, instead of building their own gadgetry (SuperCard, anyone?). If he can pull that off reasonably well, it would be VERY cool - language portability!

Anyway, while I'm talking about Carl, I thought I'd mention that I finally figured out where he - and Metacomco - fit into the Amiga operating system history. exec.library, the tiny 15K system library that handles library loading, task scheduling, and multitasking, was designed and written by Carl. Intuition, the substantially larger library that handles windows, buttons, menus, and the rest of the system gadgetry, was coded almost entirely by RJ Mical. So where, you may ask, does Metacomco fit into all this?

The DOS. The shell commands. Amiga, Inc. was cowriting the DOS with a California company, and when things fell apart there, they needed a DOS in a hurry, so they called England's Metacomco. They'd written TriPOS, a mainframe command line OS, in BCPL (a buggy thing somewhat similar to C), and were able to get it ported very quickly. Of the rest of the Amiga's early system software, MEMacs was ported from UNIX (by Andy Finkel), ABasiC from Metacomco disappeared for legal reasons and was replaced by Microsoft BASIC, and a very few commands and programs - CMD, for example - were written by Commodore. (CMD, needless to say, is a particularly atrocious example of an Amiga system command that follows no style guidelines.) The few DOS commands that wound up in the Kickstart ROMs were in BCPL; several system libraries were also coded in BCPL, and thus early Kickstarts actually had a "BCPL load table" in them, a by-product of the crappy compiler they used.

Most of this was fixed in 2.0, the load table was removed, the few BCPL system libraries were recoded in C, Intuition was enhanced with new "3-D look" window gadgetry, Gadtools was added - allowing buttons, menus, and other system gadgets to be coded in an object-oriented manner (BOOPSI) - and parts of Intuition and all of Workbench were retooled for it. Most DOS commands were recoded in C, so they were smaller, faster, and more stable - and the most-used commands (DIR, CD, copy) were put in ROM. The underlying disk OS was also enhanced, with the addition of FastFileSystem (which made its first appearance in 1.3 as a hard-drive-only file system). But all this happened after the original OS team left.

That, as it happens, was the last major OS retooling. 2.04 and 2.05 were bugfixes. The missing 2.01, 2.02, and 2.03 were actually what we used to call "Kickstart 1.4" - and had window gadgetry "within" the title bar, eerily reminiscent of NeXT - you have to see it to understand. (Developer versions of 1.4 exist in the boot ROMs of some A3000s - just enough of a ROM to boot from a 2.0 romfile on the hard drive. There's an arcane ritual you go through in the boot phase of those machines, but if you catch it just right, it fails to load 2.0, and brings up an error message in the 1.4 style! A few people have actually figured out how to use this "limited OS" to run applications - it's missing a lot of libraries, but is actually useful for squeezing an extra 512K RAM out of your machine! Yet another wacky Amiga trick.) 3.0 added very little - the "new look" black-on-white menus, the nicer Workbench scrollbars, pen-mapping, International and DirCache file system modes, a few "external" BOOPSI gadgets like the colorwheel, and of course, datatypes - which are actually treated as "gadgets" by BOOPSI. For all intents and purposes, exec.library has remained largely unchanged since 1985.

It's worth noting at this point that MUI, for all its perfections and flaws, is nothing more than a highly elaborate custom external BOOPSI object class - it's as much a part of the OS as Gadtools itself. It does NOT change Gadtools in any way, merely adds its own set of objects and functions in a separate muimaster.library - it would be quite feasible to incorporate MUI's core libraries into a future Kickstart ROM, if someone was willing to do it. I doubt anyone will, though - MUI is far too controversial.

Things coded in BCPL still crawl in the Kickstart 3.1 ROMs to this day. CMD still hasn't been replaced by something more modern. Ed (one of three text editors that comes with the system software) still sucks. Certain system software STILL fails to meet Commodore style guidelines - most of what lives in Tools, for instance. But much of Intuition, and most of Exec, are still 1985 vintage and still work remarkably well in the 1990's. A testament to the genius of Carl and RJ, as well as a testament to the philosophy of "do it simple but do it right" - exec.library is still only 15K, and the ENTIRE 3.1 ROM pair, enough to boot to a working Shell from a nearly-empty floppy disk (bootable, with only an S directory containing a simple startup-sequence), is still 512K, the size of the level 2 cache in some computers.

Now you begin to see Carl Sassenrath's complaints about modern OSes. Windows 95 requires eight megabytes of RAM just to run at all, sixteen to run usably, and 32 to run well. The OS itself balloons to around several megs, and keeps its swap file well-aerated from constant swapping even with 64MB of physical RAM. Windows 95's multitasking code is not situated in any kind of microkernal; it's still MS-DOS at the core, showing its ugly face during boot (the Windows 95 splash screen conceals a DOS boot sequence in the background) - although once the boot is completed, the system primarily uses the newer Win95 modules, but there is still no centralized OS "core." Windows NT is better, but its core is a couple of megabytes. The Macintosh has no kernal, it's just 13 years worth of scattered code fragments and Toolkit calls, balooned out across four megabytes of ROM (only part of which is 68000 emulation) and several megs of hard drive space - System 7.5, with a reasonable assortment of extensions and control panels and fonts, eats a five megabyte piece out of your available RAM, before you ever bother to load an application. Even the BeOS, touted as efficient and small, wants 3 megs of RAM. At least NeXT's Mach foundation is small. Mach, QNX/Photon, and a very select few other "micro" OSes, are actually small enough for the kernal to fit into the on-chip level one caches of many processors - QNX can live in the 8K L1 cache of a 486! But such microkernals usually end up supporting bloated OS "macrokernals" - UNIX, for example, is huge. Why, when exec.library does it in 15K, with the sum total of GUI and file system fitting neatly inside 512K along with several DOS commands, must we tolerate multi-megabyte OSes that do more or less the same thing at a tenth the speed?

But then, I was born and raised on 8-bit machines, where even exec.library, at a whopping 15K, is a monster. OS-9 can, with the proper shoehorn, be made to run on a 64K computer with some 13K to spare - enough for an application like BASIC09 or MicroIllustrator. It multitasks preemptively, is multiuser, is modular, and has paged memory-management. Of OS-9 Level 2 on a two-megabyte Color Computer 3, it is said you can load EVERY application you own and leave it running; this is not just because OS-9 has few applications, this is because OS-9 applications are small and well-written. Well, except Tandy's Multi-Vue that is. :-) Anyway, you see my point about OS sizes and code bloat. At least the Mac's balooned OS is due to "additional packages" like QuickTime and fonts and the like; Windows is that big simply because it can get away with it. An Amiga that had to preload all its fonts during boot, not to mention quicktime.library, adobetypemanager.library, 68000.library, and the like, as well as all the system beep sound files, backgrounds, icons, and big pieces of each of the Prefs programs, would quickly balloon to Mac-like sizes easily. Datatypes and icons are bad enough - they dynamically balloon and then shrink back when you're done with them.

Anyway, I'm still amazed at how the faster computers get, the longer they take to boot. It's counterintuitive but it's true.

Which reminds me - I need to clean up my Amiga's startup process, it's taking more than 30 seconds to boot from cold. I want that down to 20 seconds or less. :-)

I'm in a MUI mood this month. This happens to me from time to time, I'll just all of a sudden prefer MUI apps to their GadTools equivalents, get some entertainment out of customizing everything for a few weeks, and then return to sanity when I get tired of sluggishness and wasted Chip RAM. :-) It is kinda nifty, though - you can do amazing things with MUI, I have a few apps set to look like native Gadtools, a few set to look like the Macintosh (light grays, XEN buttons, Chicago font, black on white where possible), and a few just downright custom, with marble buttons and scrollbars with + and - instead of arrows. I actually went in and made a few of my own MUI images - any paint program will do, save your brushes in mui:images in a subdirectory of your choosing as object.mf0 and object.mf1 where object is the name you want the image to have (cycle, arrowup, whatever) - they show up as part of the "image tree" when you use MUI to pick different gadgets for whatever. I still have no idea how to build vector images, though, or else I'd have designed my own scrollbars by now. :-)

In any case, it's been said that MUI violates a lot of usability rules. It does. MUI apps are not for beginners - certain things aren't always intuitive, and the preferences program carries a steep learning curve - but for those who already know the system, it's fun fun fun till your MUI takes your chip RAM away. (I can't believe I said that.) I look at MUI as a sort of prototype for what a future OS could be like - actually, in many ways, MUI is like an OS in itself, with its own UI and method of operation. Here's my wish list for MUI 4.0, see for yourself.

• A better preferences program. The current one is too programmey. I think it should have two windows, an "editor" window and a "mockup" window - so there's no slow "test" button to go through; the mockup window has all the MUI gadgets rendered in the style you select, so when you make a change, it updates immediately and lets you see how those scrollbars look on that background.
• A better way of picking images in the preferences program. The current dinky collapsible-tree window that pops up is a timewasting pain in the arse; it would make more sense laid out horizontally, with "tabs" along the top and a horizontal scrollbar along the bottom, each tab is a different subdirectory (kmel, XEN, wd, goonie) with a tab row below that for more subdirectories (11, 13, plain, gradient, scrollbar) - and make it remember three locations for you: where the current selected image is, where the last image you selected is, where the last image OF THAT TYPE you selected is. This is easier to show than describe.
• The option to use the above tab-window system in place of listtree - for newsreaders, for instance.
• More control over the tabs: appearance (maybe using the same outlines as button frames?), arrangement (two columns if more than HOW many tabs), etc.
• Horizontal scroll bars if there are too many tabs for one window. See above.
• Multiple-frame animated images: cyclegadget.mf0, cyclegadget.mf1, cyclegadget.mf2, and on and on.
• Smooth-rotating arrows for listtrees - and an accompanying multiframe "listarrow" image, listarrow.mf0, listarrow.mf1, listarrow.mf2 and so on, so the little triangle rotates through several frames of animation, sorta like the Mac but preemptively.
• Even more customizability: distances between buttons, more font choices, more color options. (button fonts in one color, listview fonts in another)
• Fonts outlined in a second color, like the "OutlineFont" utility on Aminet.
• The ability to put multiple windows from a single application on separate screens. MUI does not currently allow this within one application.
• Drag-and-drop reorganization of a running application. IBrowse and others already allow a limited form of this, but I wouldn't mind being able to drag-rearrange almost ANY application, moving groups and buttons around and the like. I think MUI is "decoupled" enough to allow this - merely by updating muimaster.library!
• Antialiased fonts. This would be easier to support in MUI than in Intuition at large.
• The option to put scrollbars down the left and across the top of a window, if you so desire.
• An easier way to move an application from screen to screen. MUI already supports dynamically moving an application from one screen to another, but you have to make a trip to Settings to do it. How about a fifth "special button" in the title bar, with a drop-down menu of all available defined MUI screens? I would absolutely LOVE this.
• Customize the pop-up menu. It currently looks like "standard Gadtools" - whether you're running MagicMenu or not.
• The usual: more images and frame styles. How 'bout a black oval-shaped, Mac-like button style? A rounded Copland-like button style? A NeXT-like (or Windows 95-like, but you know where they stole it from) rectangular "two-tone" button border? More gadgetry, of course, maybe a better vector cyclegadget (the existing ones all suck). Extra scrollbars - or maybe a standalone application that creates them!
• Better presets mechanism; currently there is no "Save as" option in Settings, to make your own presets involves a shell, the COPY command, and some arcane rituals.
• Presets under a "Presets" submenu in the special drop-down menu, you know, the one with Snapshot, Iconify, About, and Settings? Two-click switching between preset styles - go from XEN to Macintosh to Squid Custom almost instantly.
• The ability to tear off buttons or menus into a floating toolbar. Can't you just imagine ripping IBrowse's "fastlinks" bar off into a floating ToolManager-like window?
• Better color control.
• Some way to quickly see backgrounds as you select them.
• The ability to choose a file requestor - ASL, Reqtools, or "custom".
• A way to specify that the Colorwheel always opens on the highest-depth screen available.
• A fourth "scrollbar arrow location" option: two arrows at both ends. The current choices are: one at each end (Mac-style), both at top, and both at bottom (Amiga standard, NeXT). The Mac and Be can put both arrows at both ends (double-headed arrows) - why not us?
• A fairly simple built-in bitmap editor. Would be useful as an image editor, background editor, and icon editor. Hell, someone well-versed in MUI could write such a toy as a standalone - and MUI 4.0 could just provide a hook to the "external image editor" of your choice.
• A better textfield.gadget. I can't complain enough about the Amiga's current lack of good text entry systems - there's the "square cursor" standard that doesn't really properly support cut and paste, and there's textfield.gadget, which is sloooooooooow, especially with big files, and eats RAM and can crash. Amiga word processors do a much better job - fitting the "style guide" that I'm used to, where you drag-select text, it highlights, you hit backspace, and it deletes; words auto-wrap as needed, shift key can be used to modify the "selected" area, double-clicking selects a word, triple-clicking selects a line, and so forth. No Amiga text editor currently works like this, textfield.gadget comes close but is poorly implemented, and unfortunately I haven't yet figured out how to call excellence! as my text editor in YAM.
• The prefs editor of textfield.gadget incorporated into the main Settings program. See above.
• The ability to decide what happens to a button or gadget when it's "selected" via the keyboard - it's currently just outlined in a color. I'd like to be able to "dotted outline" the button text (yes, I know which OS that's from, it's one of the few things I like about Windows) or draw an extra border around the button (Mac-style) if there's room. (Imagine MUI looking like ARQ!) This will help usability and improve the appearance greatly - the default button stands out much more.
• The ability to replace the entire window. CUI and Windoid show how this is possible - right down to custom close and size gadgets. The "extra" bar in the right or bottom of a window can be eliminated entirely, the close, resize, zoom, and front-to-back buttons can be replaced, the title bar can be antialiased (see above), and you can in general have REAL nifty fun, without the nasty system hacks like URouhack (which on my system makes ReqTools buttons appear empty!).
• The usual speed improvements and bugfixes: make scrollbars not leave big pieces lying around, for instance.

Speaking of SASG and things Magic, perhaps you're aware of the running feud between Martin Huttenloher (creator of Magic Workbench) and Roger McVey (creator of NewIcons). These two products, for the uninitiated, are replacement icon packages for the Amiga - replacements for the puke-ugly four-color Commodore icons. MagicWB is an icon style, using 8 colors (the usual black, white, gray, and blue, plus slightly lighter gray, slightly darker gray, and two shades of orange) - you just set your Workbench to use that "standard" palette, and replace all your icons. NewIcons goes a step further, actually adding to the OS itself a new icon display mechanism; it stores a 256-color compressed icon image within the .info file tooltypes, and the "patch" allows the OS to pen-map those 256-color icons to the current Workbench palette. NewIcons comes with a set of "isometric"-style replacement icons for your existing system. MagicWB is shareware; NewIcons is freeware.

Anyway, as far as I've been able to determine, both these guys are being assholes about this. Here's a carefully selected excerpt from McVey's .readme file for NewIcons:

Well it's been awhile since my last foray into the great GUI debate. I have been auspiciously absent for a year or two due to what I consider an alarming trend towards a gratuitiously ugly standard, namely MagicWB....

MagicWB appears to be an oxymoron from the ground up. The term "magic" would seem to imply a technological achievement which surpasses human comprehension. Although from a visual standpoint it may be difficult to comprehend why anyone would settle for this pedestrian, monochromatic interface, it is all quite easily explained: Amiga users are in such despair over the lack of ANY standardization that they will eagerly embrace whatever looks better than Commodore's laughable attempt at what is known in the industry as a Graphical User Interface (GUI). It would seem, however, that style, taste, and/or design are not any of the chief concerns of those who would endeavor to better the situation. Over the years, there have been those who have tried to foist upon many an unsuspecting user their interpretation of what an attractive, workable environment should look like. Many of them have gone unpunished, including that individual who designed a Workbench around a color scheme which included such delightful hues as fluorescent green and beige. Makes me wonder if Dr. Kevorkian offers gift certificates... Other incarnations have ranged from blatently insipid to overtly disgusting, the latter dominated by what is known as MagicWB. In deference to SEA (the Society for the Elimination of Acronyms), we will refer to MagicWB and other such counterparts as UGLI's (Unprofessional Graphic Layout Interface).

[...]

Until recently, I was content to remain uninvolved in this seemingly endless, lemming-like parade over the MagicWB cliff because I had my own Workbench design and seldom, if ever, made contact with any other Amiga user. I had, to my surprise, actually forgotten exactly how rancid the original Commodore Amiga icons were. When MagicWB arrived on the scene, it took me slightly less than 6 seconds to come to the realization that this was really just a cruel joke heaped upon the Amiga community by some fiendish, diseased pervert in an attempt to prove once and for all that those who owned Amigas lacked the higher brain functions of color recognition, compound speech, and the ability to switch off "Dukes of Hazzard" re-runs."

So let's see Martin H's response to the above.

"NewIcons' icons were made by Roger McVey whose only purpose was to attack me and my product MagicWB in the utmost disgusting, cheap and proletarian way possible. Read the introduction text to NewIcons and you will obviously understand that this piece of work can not be taken seriously; neither intellectually nor artistically. NewIcons was meant to be an uninspired and cheap aggressive act to weaken the wide acceptance of MagicWB by its users. The creator of these "icons" proclaimed himself as the reference artist when it comes to icon creation and officially called me a "fiendish, diseased pervert" in his documentation amongst many other insults and profile-neurotic mental diarrhea with which his introductory text is filled. To this day I do not understand why this person needs to attack me in that vulgar way; I have never written to, talked with or even met this person in my whole life, I do not know him at all. I can only guess that this man is suffering from a severe inferiority complex. So does his work 'NewIcons':

• it is based on hatred and therefore totally uninspired
• it is artistically not appealing since the style of these icons is crude and far from being photorealistic (Mr. McVey is not even capable of anti-aliasing his icons which indicates how untalented he is)
• its palette's color selection is so incompetent that it resulted in an unrealistic "ketchup & mustard" play-toy-look (which of course is a matter of taste)
• it is restricting the user to a rigid and inapt icon size, thus eliminating the possibility to quickly recognize different icon types by their forms. Furthermore NewIcons' icon size is contradicting all rules of professional layouting.
• it has not succeeded in creating a wide user-base and failed to be a standard and is neither accepted by shareware & freeware authors nor commercial applications. MagicWB in the opposite is responsible for the biggest avalanche of MWB-style icon sets in the history of the Amiga. Over 6000 icons and an unparalleled acceptance as the Amiga workbench standard amongst users, programmers and magazines is proof enough for the vast superiority of MagicWB. It is so established that its name and style are even known on other computer platforms!
• NewIcons is totally incompatible with the AmigaOS and a bad "hack". The side-effects are numerous and comprimising your system.
• it is very, very slow. Even on systems powered with an 040 processor the unefficient way how NewIcons hacks the system results in an immense delay of icon build-up on your workbench.
• it is so cheap that it even costs nothing! What can you expect of a product of which the mere reason for existence is hate & envy towards MagicWB, thus trying to hurt its development by offensively releasing NewIcons for free. Quality has its price -- MagicWB is quality!

I do not object competition, if it's fair and my competitor is gifted both with talent and common sense. But NewIcons is nothing of that -- it's a joke. Do not be taken in by it, it's a waste of time and effort."

Second, yes, NewIcons is a hack. I can't use it on my system because it apparently conflicts with SOMETHING, and causes a guru (or "alert" as Commodore insisted on calling it after 1.3) within minutes of it being activated.

Third, Martin H is utterly WRONG when he says NewIcons is "limiting" - he seems incapable of separating the NewIcons format (compressed 8-bit data in tooltypes) from the NewIcons style (isometric primary-colored cartoony-looking things). NewIcons can be any size and use any palette; yes, they do slow the machine down when loading a drawer full of them, but the same is true for ANY high-depth icon set, and is a limitation of Workbench itself that's only amplified, not created, by the NewIcons patch.

Fourth, both these guys are now guilty of using some of the baddest-assed insults I've yet seen in the Amiga community. "some fiendish, diseased pervert in an attempt to prove once and for all that those who owned Amigas lacked the higher brain functions of color recognition, compound speech, and the ability to switch off "Dukes of Hazzard" re-runs" from Roger, and "amongst many other insults and profile-neurotic mental diarrhea with which his introductory text is filled" is Martin's description of the above. Now we're faced with the Eddie Vedder syndrome - how do you respect an artist even though they're an asshole?

Fifth, both icon sets have their problems. MagicWB icons have a "rounded" look that I don't always like, there are newer "pattern icon" sets that I vastly prefer because the icon "surface" looks cleaner. MagicWB drawers have always bugged me - the front of the drawer SHRINKS when you open it! (You've seen this.) This makes designing "imagedrawers" needlessly hard - you lose a pixel between frames. MagicWB is designed to take into account the Workbench "icon box", but unfortunately the second icon image looks goofy without that frame - important when building ToolManager docks. NewIcons, on the other hand, yes, I'll agree with Mr. H, the default NewIcons set is butt-ugly, flashy colors, cartoony, annoying "flat isometrics", it's all the same shape, you can't tell what anything is by looking at it, etc. Drawers don't look like drawers, for example. Frankly, NewIcons look like they would be at home in Microsoft Windows.

But that's only the default set. NewIcons (the patch) still has one major thing going for it: the color-mapping scheme. It's great for pictures directories - make decent-sized icons (say, 64x48) that are thumbnails of the picture, in 256 colors, with a separate palette for each icon, so you with high-color Workbenches are smiling. This is the main reason I tried running NewIcons in the first place. Standard Workbench icons cannot remap themselves to different palette depths; there are MagicWB hacks that "eat" four colors to try to ensure MagicWB icons look good in 16 colors and up, NewIcons needs no such hacks.

Sixth, Martin didn't read all of Roger's statement that he excerpted. Roger had NewIcons before MagicWB was released. Roger may have decided to attack Martin after he noticed MagicWB's popularity, but that was not the factor in deciding to create NewIcons in the first place.

Seventh, there is a major reason that OSes like Mac System and IBM OS/2 are largely monochrome: user interface design and testing has found that "multicolored" OSes like Windows 3.1 are not the best way to do things. Color in user interfaces should be used very sparingly; bright flashy everything-has-a-color approaches get annoying and don't do color-blind or monochrome-screen users any good. Commodore, oddly enough, understood this part: everything in 2.0 was gray except the active window. MagicWB understands this part somewhat: the monochrome is there for reasons of human interface design. Although you may not CONSCIOUSLY think it looks better, it really does, much like my preoccupation with trying to write novels in white-text-on-black; I like it, but it hurts my eyes. NewIcons' default style is all flash and no design; no thought was given to why icons exist in the first place, to easily tell things apart without having to read the name. Human eyes are able to identify a clear image much faster than they're able to identify a word; all that's left is associating the image with its meaning, which is why a) icons still have titles, b) icon placement is as important as the image (I memorize locations as well as the icon images themselves!), c) toolbars are useless unless you already know what the buttons do. NewIcons ignores all this, and is largely "icons for the sake of icons." But see below.

Eighth, Martin is grasping at straws: "it has failed to become a standard" is no accusation, the Amiga itself has failed to become a standard, so has NeXTSTEP, so has Betamax, so has Esperanto, so has Dvorak, so has DAT minitape, so have electric cars. Remember this.

Ninth, Martin used the sentence "it is a matter of taste" - and then purposely forgets that sentence through the rest of his diatribe. Yes, NewIcons IS a matter of taste, and for either Martin or Roger to say "THIS is what you should use" is exactly the same kind of oppressive arrogance Microsoft has in saying "THIS is what you should use." Windows fans say "I don't see what the Mac has that Windows doesn't." I say "I don't see what Coke has that Pepsi doesn't. Does that mean no one should drink Coke?" No, NewIcons pays no attention to user interface design - but if users want ugly Workbenches, it's their right. (There are still people in this world using 4-color Commodore icons on 24-bit Workbenches!) And remember that while Martin thinks NewIcons is ugly, Roger thinks MagicWB is equally ugly.

My own idea is to get NewIcons working properly on my machine (i. e. not crashing) and remake a lot of MagicWB-style icons in NewIcons format - making use of the extended color depth. Then, of course, I'd tweak the MagicWB drawers so they don't "shrink". (Martin H may be a dickhead, but artistically he's no slouch; I can't believe he let that one get out the door, though.)

But then, my own druthers would be to replace them BOTH with another system patch - one that adds a separate graphics-chunk to the .info file format, compressed, 24-bit color data, and then allows (NewIcons style) Workbench to pen-map that image as needed. Such a hack as standard in the next OS would eliminate any issues of "standardization". The main reason NewIcons has so far failed to become a standard is the same reason the Amiga itself has failed to become a standard - the chicken and egg syndrome, why should an application use a nonstandard icon format if not all the users will be able to see it? This is something of a lame excuse, admittedly, as a NewIcon and regular Icon image can exist in the same .info file - but there's little point to bothering to create the NewIcons image if you have a "real" icon anyway, again if few people will see it.

I for one, though, don't wanna live in eight colors forever.

Which brings me to another point: the main reason NewIcons are not antialiased is because no icon editors currently know how to antialias lines. For that matter, I can't find ANY decent Amiga 2-D package that's well suited for that. DPaint antialiases reasonably well, but the version I have (4.5 AGA, from the legendary Commodore "power-up" program, y'know, where you got your 1200 in January 1993 and your software arrived in February 1994?) doesn't work in 24-bit and "prefers" full-screen sizes like 320x200 and 672x458; not totally useless but not ideal either for icon editing. Iconian does nice things but doesn't antialias and doesn't do several other things. Even Photogenics doesn't do antialiased lines! XiPaint, weird enough, has a severe glitch in its line antialiasing routines - only HALF the line is antialiased.

Mac paint programs these days have a similar approach: windows of arbitrary size, you work in a 24-bit buffer, everything can be antialiased, selection and mask operations work similarly, etc. Amiga paint programs don't quite get this right; DPaint works on a custom screen in limited depths, and has a cool but nonstandard selection/brush mechanism, while Photogenics and XiPaint are essentially workalikes; Photogenics doesn't even have a standard UNDO function. What the Amiga needs is a decent style guide complaint 2-D bitmap paint package, one that works on 24-bit or other depth IFF images, one that works in windows on Workbench or custom screens, one that works at arbitrary size, one that antialiases lines and circles and fonts, and one that's expandable. I'm already researching writing such a program in ACE. It would be little more than a toy, yes, but that's all I need - I'd write it with an external plugin API so you can add nifty things. All I'd need initially is just a line algorithm, flood fill, select/move, copy/paste, and load and save. Everything else I can do externally via the PBM utilities or ADPro. But first I gotta get cracking on ACE... which means learning the Amiga libraries... which means remembering how to program... such a "small" bitmap paint program, though, if done right, would be perfect for inclusion with an OS, much like Windows Paint. I wonder... hey QuikPak...?

Something else I'm wondering. My 1200 has two processors: the 68EC020 on the motherboard, and the 50MHz 68030 on the accelerator (actually three, counting the 68882 math unit). The EC020 is currently unused. I wonder if it's possible to reactivate that chip under program control and have it execute code while the 030 is running: cooperative multiprocessing, if you will, much like Phase 5's Power-Up boards, where you use a library to say "have the other processor run this" and wait for it to dispatch results. The 020 would be limited to Chip RAM only, since all my Fast RAM is in 32-bit space the 020 can't touch; at 14MHz it would be nearly useless for high-speed calculations, and running exclusively in Chip might slow it down even more. But it might be useful for, let's say, chunky-to-planar conversion? The 020 could be redrawing the screen while the 030 is doing other things, and would function essentially as an extra custom chip, eating Chip cycles and doing bit manipulations while the main processor continues to work. If, that is, there's a way to reenable the 020 when the accelerator slot is in use. If it worked, though, the first application I could think of is a Shapeshifter screen driver; it would eat up Chip RAM in a hurry, but you'd have two copies of the screen, one in chunky and one in planar, in Chip, the 030 would simply flag which sections of the chunky have changed, and let the 020 redraw the changes. Same thing with Eurodemos: a processor already burdened with 3-D vector transforms doesn't want to be bothered with C2P conversions, and knowing how close those demos come to the metal anyway, who'll notice such a vicious hack?

Yes, it's no rumor: Sarah McLachlan is married. She married her drummer, Ashwin Sood, on February 7, while on vacation in Jamaica. No word on whether any names will change. What does this have to do with the Rumor Mill? Not a damn thing, except perhaps a) it's my damn page and I can say what I like, and b) Sarah has a Macintosh.

One last idea before this Rumor Mill gets any bigger: Sun's Java processors, you're aware of these, right? Essentially the Java Virtual Machine "unvirtualized" as real silicon - and they run Java applets about 10 times faster than a Pentium 166 running a Java VM, even for the low-end $40 chip. Well, here's my idea. Take one of those Java chips, a 1MB DRAM, a small ROM, and stick it all on a PCMCIA card, include some Amiga drivers and patches for various Amiga Web browsers, get it out the door for $100, and... well? think about it. A $100 Java coprocessor for the A1200. $500 for the 1200, $100 for the Java card, another $100 for a modem and software, plug it into a TV, and... you have a $700 Internet terminal that will BEAT a Pentium in speed.

Well, anyway. This is already the biggest Rumor Mill in awhile, I should stop now before it gets so big it crashes browsers.