Alphabet Soup

November 11, 1996

Phase 5 finally lifted the lid to let us peek inside its "super-Amiga" project. They've outlined the specs of this remarkable, and decidedly Amiga-like system (which they claim will run existing Amiga applications). It is definitely NOT built from the "organ bank" like the BeBox or the theoretical PIOS systems - it's truly custom. And it's very cool, at least on paper.

And the name Phase 5 has given it? Are you ready for this?

A\box.

Yes, that is a backslash. Yes, it definitely seems designed to pick on Be. And yes, it comes alphabetically before Amiga, much like Amiga comes before Apple in the dictionary.

They're shying away from those commercial mass-produced SVGA-style graphics controllers that Dave Haynie insists are the only way to go - instead opting for a somewhat more proprietary approach that, regardless of its technical merits, will instantly appeal to diehard Amiga custom-chipset fans.

"The heart of the A\BOX is the system controller, CAIPIRINHA, which will realise the functional integration on which the A\BOX concept is based. CAIPIRINHA opens up new dimensions of power and technology. CAIPIRINHA will be implemented as a VLSI Custom Chip design in 0.35 um CMOS ASIC technology using a modern, probably 575-pole BGA housing. With a bus width of 128 bits to the memory bus, extensive dual-port buffers and FIFO's in the data lines, and clock rates of initially 100 MHz externally and 200 MHz internally, CAIPIRINHA can provide an intense data throughput and powerful additional functions which do not rely on the processor, such as support for 3D and multimedia applications."

Also keep in mind most motherboards today clock somewhere between 33MHz (most 486es, certain Quadras, older Pentiums) and 50MHz (Pentium Pros, Power Mac designs) - and the clock is internally multiplied (actually divided) in the processor to reach those speeds of 200 and up. A motherboard controller running at 100MHz doesn't necessarily mean a 100MHz motherboard with a clock-multiplied processor, but it doesn't rule it out. Exponential has already demonstrated a 566-MHz (!!!) PowerPC-compatible processor running on a specially air-conditioned daughtercard inside a Power Mac 9500 - speeds so fast certain things in the Mac ROMs start to break, the occasional "oh there's NO WAY a loop this long will take less than a second to run, you'd need a 500MHz chip to break this!" that finally met a chip too fast. (For what it's worth, such a chip could run the emulated 68000-code Mac Finder faster than any Quadra or Shapeshifter/68060 ever, and could easily run 68040 software faster than current Power Macs run PowerPC code.) But I'm ahead of myself again.

This custom ABox controller - the Caipirinha - has a 128-bit memory controller, bantying about an acronym called "UMA" - Unified Memory Architecture. This, to be simple, is unlimited Chip RAM. It'll use Power Mac 9500-style 168-pin DIMMs (which are still more expensive than SIMMs of the same size) - and will probably take them in pairs for 128-bit memory channels, again like Apple's top-flight 9500. It's also got a 64-bit processor bus (their words) - and the aforementioned 100MHz clock, not to mention multiprocessing support (the initial ABox will probably max out at two processors).

But there's more to Caipirinha than memory. It's not just a souped-up MMU, or a souped-up Gary. It's actually more like Gary, Agnus, Denise, Paula, a 68851, a Mitsumi keyboard controller two 8520's, and a couple sets of AD/DA converters all condensed onto one huge ASIC. It probably has more in common with Tandy's GIME chip - the combined graphics/interrupt/memory controller in the Color Computer 3 - than with any single Amiga custom chip. But hey - the specs are cool no matter what.

Let's start with dual 24-bit DMA video units with built-in digital-analog converters - for two independant video displays. Add four (!) 16-bit audio ports (surround sound would only require three, wonder what the fourth will be!) running at AAA-like 44.1KHz (CD-quality), with sample output and FM and AM synthesis (not the PC-style wave-table elevator music chiptune crap). How many channels? "any number of virtual tracks." That scares me. This machine is built for heavy-duty MODs.

But let's not stop there. A VESA-compliant LCD controller. PCI bus (for what Phase 5 calls "medium-performance I/O applications"). Some custom DMA local bus thing. It's got FireWire! And it has what it describes as a "desktop bus interface." I assume it means either access.bus (the DEC standard for hooking up monitors and keyboards and printers in a 127-unit SCSI-like chain - truly plug and play and a nifty emerging standard) or Apple Desktop Bus (those little four-pin Apple keyboard/mouse connectors that are always falling off).

(My Apple mouse came disconnected accidentally just minutes after writing that.)

"CAIPIRINHA is basically designed as a highly complex system and memory controller in the form of a SOMA Engine (Sole Memory Access). At the same time CAIPIRINHA manages all access to the A\BOX memory which takes the form of a highly powerful Unified Memory Architecture (UMA). All external memory access, including that of the processor, only occurs virtually and is administered and implemented by CAIPIRINHA. Unified Memory Architecture means that the entire system memory is made available as a unified memory which stores all types of data, such as programs and their data, display data, 3D-textures or Z-buffer data, audio data, incoming flows of video data etc. etc. and which can be addressed by all functional units in the system. For the user UMA means that the entire memory in the system is available for all applications at all times. When the memory is expanded with inexpesnive SDRAM modules, the additional memory capacity is then always available for all applications and functions in the system. In terms of its principle UMA corresponds to the Amiga Chip RAM which can be addressed both by the processor and by the custom chips and video and audio DMA units of the Amiga. Unlike the Chip RAM, however, and unlike the low-cost attempts made to implement UMA memories in the PC field, the memory subsystem of the A\BOX in the form of a unified memory architecture will be implemented with 128 bits databus width and by use of synchronous DRAM's which have a speed of 100 MHz, which allows a band width of 1.6 G-bytes/second. A special method of controlling the SDRAM modules also considerably reduces latency times when accessing the memory.

Due to the integration of the video DMA into CAIPIRINHA the UMA memory can simultaneously be used as a display memory. CAIPIRINHA provides two video DMA engines: one 220 MHz high-performance video output for resolutions of up to 1600 x 1280 pixels with 24 bits and a refresh frequency of 75 Hz and a Genlock-capable 135 MHz video output for a second monitor or image output in video resolutions such as PAL/NTSC or S-VHS. The video output of the 135-MHz output can be superimposed as a window on the 220 MHz display while both video DMA's are in parallel operation."

"Unlike conventional raster scan displays, CAIPIRINHA's video DMA engines function on the basis of a random memory access (Random Access Display), which makes it possible to display any data in visual form at any random screen positions. With this method windows, as hardware windows for example, can be superimposed and moved around anywhere with their full content, without any delay or jerkiness, even with moving animation or video sequences. Special pipelines and FIFO buffers within CAIPIRINHA's video DMA ensure a stable data throughput. The complex display possibilities are controlled by an integrated display-list RISC processor (DLRP). As the video DMA engines always have an output in 24-bit display mode, it is, of course, possible to mix any depth of shade at will. In this way, for example, on a memory-saving background with a colour depth of 8 bits it is possible to display 16-bit and 24-bit windows in any position. Of course CAIPIRINHA makes it possible to open and display virtual screens of any size and to make use of the capacity of the entire RAM. For example an image-processing application can open a virtual screen of 4000 x 4000 pixels in 24 bits in a system expanded to 72 M-bytes and scroll it in a display that can be represented on the monitor in 1280 x 1024 pixels without any delay or jerkiness. Another interesting feature of CAIPIRINHA's video DMA engines is the fact that windows need no longer be merely rectangular, but can assume practically any outlines. Last, but not least, video data in the RAM which are intended for output can be stored in various formats such as RGB, YUV or CMYK and displayed simultaneously."

Think about this for a moment. Hardware windows. You thought screen-dragging was cool. You're in for the ride of your life. Hardware overlay. A RISC display-list processor - essentially a Copper from hell. Remember long ago when I said AAA would let the copper feed the blitter? As Sega says, welcome to the next level - a flexible RISC copper. You don't wanna eat up all your (Chip) RAM with a 24-bit background, fine, use an 8-bit one instead - and feel free to open up Photoshop in a 24-bit window over the top of it - in hardware. Superbitmap screens? Autoscrolling? Why sure - a 4000-pixel square (film resolution) 24-bit image superbit autoscrolling. And put that in a window too if you feel like it. For that matter, aren't you tired of rectangular windows? How about triangles and circles? (What would the scroll bars look like on such a window?) Wipe that drool off your face - you look silly.

"The A\BOX system will be implemented as a progressive and innovative concept of a personal workstation which offers extremely good value for money. As we have mentioned, the system builds up on the innovative CAIPIRINHA chip which serves as the functional heart of the system. The type of processor we intend to use will be the Initial PowerPC processors of types 603e and 604e. Theoretically these can be operated with clock frequencies of up to 500 MHz. At present, with the first A\BOX design, a maximum of two processors can be connected on the CAIPIRINHA processor bus; a corresponding expansion option for the second processor will be available in the A\BOX design.

The memory can be expanded by using inexpensive standard SDRAM modules with a width of 64 bits (168-pin JEDEC DIMMS). In future these SDRAMs will increasingly be replacing slower, traditional DRAMs. Eight slots will be available so that the memory can be expanded to a maximum capacity of 1 gigabyte. The slots can be expanded in pairs (due to the 128-bit mode).

As a standard feature the system provides two video outputs, one of which has a maximum pixel rate of 220 MHz and the second of which can be operated at 135 MHz. In addition to this, the second video output can be synchronised externally and is thus suitable for compatible analogue video applications."

And yes, this thing will run the PowerPC. Personal workstation indeed... this thing could leave Silicon Graphics whimpering in the corner curled up into a fetal position.

Oh, you ask the classic question, a question that's no stranger to the Amiga: What good is cool hardware without software?

"A large number of options will be available for the operating system software of the A\BOX. In general the A\BOX project aims to implement an Amiga-OS-compatible operating system of a state-of-the-art technical standard and to provide it as a basic operating system for the A\BOX. Modern functions such as support for multi-processing are to be transparently integrated. The basis for this development has already been created in the form of the Amiga-OS 3.1 compatible operating core which is currently being tested in the software labs of phase 5 digital products. In the near future we will also be pressing ahead with more development work in co-operation with important software partners, for example on an updated GUI or other high-level components. An important aspect of this development work will be our efforts to make the operating system provide complete support for the superb possibilities offered by the hardware.

In addition to this we also plan to implement a NetBSD and a Linux version for the A\BOX in co-operation with other partners. The current concepts provide for a very close integration of these OS adaptations into the basic operating system of the A\BOX so that parallel operation of the two operating systems and of software applications based on these operating systems will proceed with extreme transparency and excellent coordination. A\BOX will also be open for other operating systems, especially including the ones that are already suitable for the PowerPC. In the future we might use attractive standard operating systems by way of licence agreements and emulation."

Compared to the exquisite hardware specs above, it doesn't look like Phase 5 has much of an OS strategy. And we WILL likely see some comments from Dave Haynie soon, again asking where Phase 5 is getting its "Amiga-compatible" operating system, except as a really nasty patch to existing Kickstarts. And the next question is the degree of Amiga compatibility. MacroSystems found out the hard way only a small percentage of Amiga software is truly OS-compliant - even ACE Basic bangs the hardware for sound and joystick support - and without Amiga chips, or at least an abstraction layer of some kind, Amiga software will start dying painful deaths on the ABox. Does Phase 5 have plans to implement some kind of Agnus-emulator or similar Amiga chip emulation layer? If not, to what degree will Amiga software find Amiga chipset registers in the Caipirinha register space? (i. e. can Amiga software bang the ABox hardware as if it were an Amiga and expect Capirinha to do something meaningful.) Otherwise it's a Power Draco - you hope and pray your software never notices there's no Amiga in there.

But hey. The whole idea behind a box like this is to be what the A1000 was in 1985 - who needs Lotus, we have Juggler! Who needs industry-standard applications (at least for now) - or even existing Amiga applications - we're in on the ground floor of truly unique technology. We'll wait for the cool applications - because they WILL come. Hardware like this is the sort of technology that inspires new applications that simply couldn't exist before - much like the Amiga inspired desktop video production.

Now we wait and see if Phase 5 delivers hardware as promised.

Okay. Next cool item? You want more juicy earth-shaking rumors? Okay, here's one:

Amiga Netscape.

This is totally unconfirmed, but it did come to me (in a roundabout way) from C|Net - the story goes that Netscape is considering putting a beta version of Netscape for the Amiga into rotation by the end of the year. Such a program would, the story goes, only run on newer Amigas - but then, if you're running a 1MB A500 with Kickstart 1.2 and complaining because you can't run Netscape, you don't deserve Netscape anyway.

So here's the thing. First off, I don't put much credence to the story - remember we've gone through this before with the rumors of Amiga Internet Explorer. Second, Netscape is suffering from the Steve Jobs Syndrome - a company so arrogant it doesn't realize it's losing. Here, lemme show you an example.

Netscape 3 for Windows has a teensy little glitch. Someone discovered a way to make a Web page - or EMail message - that locks up your entire system solid. What it does? <img src="file:///com1:"><img src="file:///com2:"><img src="file:///com3:"><img src="file:///com4:"> - think about that for a moment. It tries to get an image from all four of your PC's COM ports at once - and fails miserably and hangs up. Mac version doesn't have this problem (nor could it), Internet Explorer doesn't have this problem. It wouldn't be hard to fix it - just disallow DOS device names - but so far Netscape is in no hurry.

Netscape is slipping. But they're slipping in an almost NeXT-ish way - the guy in tenth place in the race who thinks the crowd is cheering him. Why drop prices or fix bugs? We're winning.

But I'm not about to discourage Netscape from making an Amiga browser. The only concern I have is that we'd never get any tech support or bug fixes - which is in a way worse than no software at all, because at least there are fewer complaints.

Anyway, Netscape has acknowledged the demand for Amiga Navigator - on their site they list a few OSes that people have been clamoring for, and noncommittally saying "We may provide support for these in the future." The Amiga is the top of the list - perhaps alphabetically, perhaps in order of likelihood. They only recently put Navigator 2.02 on OS/2.

Eric Schwartz, legendary Amiga animator, is starting an Amiga awareness campaign, to remind everyone we're not part of the TI-99/4A crowd or the TRS-80 crowd, but rather, like G'Kar standing on the table shouting, "We're still here! We exist!" we haven't gone away - we're here not because we have to be, but because we want to be - and we've stuck by the Amiga as long as the Amiga has stuck by us.

To this end, Eric has drawn a cool picture called "The Survivor" - of an Amiga standing in a blast crater, with bandages, bruises, scrapes, wounds, scars, and crutches, glaring defiantly up at the camera as if to say "Okay, that hurt, but I'm not dead yet..." He's encouraging people to put the picture on shirts, posters, or whatever, to drum up Amiga awareness. As he says, "I have no idea what to expect from a campaign of this sort, but I think I'll be happy if I see a few appearances of the picture in places I didn't expect to see them." I agree - it would be cool to see "Survivor" on someone's chest just wandering around the mall, or worn by someone on TV, or worn by a rock musician at a concert, or on a poster in someone's room on a TV show (would look great in Sheridan's office, no?), or whatever.

It's a great idea. I think it probably has more potential than other weird Amiga "grass roots" ideas I've seen - because Eric Schwartz is someone we all know and trust. Unlike Dave Haynie or Jason Compton, there is no way we can point to anything Eric does and assume there's some kind of financial or political motive. Eric does what he does because he likes the system, and always has. Many of us bought our first Amigas in part after seeing "Flip the Frog" and the "Anti-Lemmin' Demo." Eric is truly an Amiga giant (and if you've ever encountered him in person you'll agree) - I wish him the best of luck with this. Perhaps he'd make a great first candidate for the Amiga President role I mentioned some time ago - his public-speaking skills weren't in top form at AMICON, but then, that wasn't exactly the best venue, and we wouldn't be electing the guy based on how good an impression of Kiki "Endless Product Pitch" Stockhammer he can do - but rather on the basis of what a potential Amiga President actually believes about the Amiga.

And here's the wildest piece of news fresh from the furnace. In the "Holy shit, they're actually gonna DO it" department comes this from MacWeek Online (used without permission, sorry):

"Apple and Be Inc. were at the bargaining table this week, hashing out a deal that would bring the small Menlo Park, Calif.-based company's OS into Apple's fold.

Sources said that while terms of a company or software acquisition are not firm, Apple already knows how it wants to deploy BeOS.

MacWEEK has learned that the main thrust of Apple's plans is a merger of the microkernel from Mac OS 8, formerly code-named Mac OS 8, with the BeOS application model. The company reportedly has set late summer 1997 as the earliest timeframe for an initial delivery of the hybrid OS. Apple expects to port key System 7.5 services to this new platform gradually, sources said."

That was beautiful...

This is the biggest rumor of the year where the Mac is concerned. Copland, aka System 8, would have been one hell of an operating system, but at its current rate of progress, would not have been deliverable until 1998. It went from "early 1995" to "late 1996" to "early 1998" to "oh, hell, let's just ship it in pieces." When Be first demonstrated BeOS DR8 running on a Power Mac, which was done almost literally over a weekend, it dawned on many observers that it would actually be quicker to just put the BeOS on a Mac and run System 7 in emulation if at all. There had already been weird rumors that Apple had actually created Be, Inc. as a roundabout way to eliminate legacy code...

But by all accounts, this looks official.

The details are these: Apple is taking the pieces of BeOS, namely the application model and kits, and using that as its foundation for future OS development. They can have a sort of Apple BeOS ready probably early next year, and people can start writing new apps for the new OS, while they work on a way to run existing System 7 stuff later.

Or so the MacWeek article said.

Here's what Gil Amelio had to say.

"Inevitably, we will do some things together simply because we are plowing the same turf. I think there are things we can learn from [the BeOS], and so in that spirit we would be delighted to work with them in any way we can."

He tried to kinda put the brakes on the notion of BeOS-replaces-Copland, saying instead that BeOS pieces and parts could be made available as Copland modules. Both Mac purists and BeOS fans may be kinda upset at the notion of BeOS becoming spare parts for System 8, but no matter what they do at this rate will make a cooler MacOS.

In any case, System 8 (both the Be and Copland versions) would finally offer memory management to Mac applications - a Mac app would be given what it thinks is total control of system memory, as if it were the only application running. The System software maps itself in on the bottom - it has to be in the MMU table at all times - and gives the app an unsegmented "virtual" space above that with an unlimited amount of room to play. Memory never becomes fragmented. The program doesn't know or care whether it's in virtual memory or not - and you never run out of memory, at least until your hard drive fills. The MMU could specify that the Mac System software is read-only or execute-only - so that out-of-control Mac apps couldn't explode all over the System and corrupt it. Nice little protection box.

The existing Copland framework (the beta that should have shipped to developers last month) has a weird sort of "new" Thread Manager - new Copland-generation apps could write to the new thread manager API and get preemptively scheduled threads. Existing Mac apps using the existing Thread Manager extension will be cooperatively scheduled, as will existing Mac apps trying to run simultaneously. (Cooperative multithreading - what a horrifying thought.)

Now let's look at Be. Your Macintosh stuff could end up running in a nice little emulation package - Mac Toolbox stuff and the like - feeling sorta separated from the rest of the system. Not to mention the BeOS is still in pre-beta (DR comes before Beta), there's the teensy problem that the BeOS doesn't offer some of the more er, aesthetic things the Mac has - things like International support (that's Localization for you Amiga people), things like power management (necessary for laptops - the OS kernal can switch things on and off to conserve power). BeOS is still very much a hacker OS, its UI is still a bit unrefined in places (floppy disks and CD-ROMs don't always automount, there is no OS-level "completion gauge" gadget, several other things missing), certain things are still rather unintuitive (the Database is cool but mention of the word "database" can send people scurrying), and there's this damn flip-flopping between dual-forked (Mac-like) and single-forked (normal) file systems in every other release. The OS itself doesn't yet have a real "appearance manager" system yet - the MacOS can look like a Be but not the other way around. And the menu bar is actually "in" the window like Windows or Solaris instead of at the top like the Mac or Amiga.

But much of this is stuff that can be fixed. I'm hoping future BeOS versions will "optionify" many of these things - menubar at top of screen, top of window, down the right side, or pops up at cursor, all selectable via control panel, for instance. Problem is, it'll take as long to bring BeOS to Copland's level of planned functionality as it would to bring Copland to BeOS's level of planned functionality.

Copland has the 'front end' stuff under control but the kernal needs work. Be has the kernal downpat (multiprocessing, memory management, threading) but has big gaps on the way up to the user. It all amounts to which Apple needs more - or which Apple thinks it needs more.

We'll wait and see.

MacTech Magazine is putting BeOS for Power Mac ("OS Doubler") DR8.2 on its January cover CD-ROM - I expect that will probably be the biggest-selling single issue of any Macintosh magazine ever. They'd better have ordered heavily - they WILL run out. (This happens in the UK all the time, the issues of Amiga mags with the coolest coverdisks - they put LightWave on a coverdisk once! - sell out first.) The idea behind this coverdisk is to give Mac developers a taste of the future, so to speak - if you are lucky enough to lay hands on this disc, remember it requires a 603 or 604 Power Mac, and is still beta.

I noticed something odd in my "Personalities" section: "At least one of the Banditos is rumored to have been Perry Kivolowicz of ASDG fame..." um, how many Perry Kivolowiczes would there be, and how many were Banditos? Oddly enough, the blurb doesn't sound quite right without the "at least one" - so I'm leaving it that way. (Maybe, like President Grover Cleveland, he did two nonconsecutive stints as the Bandito...)

We put Speed Doubler on one of the Power Macs here at the office, and hot damn, it really works! I still think this is perhaps the most unusual thing about the Power Mac design: the concept of the software accelerator. Get a faster 68040 processor without ever opening the case - just run an Installer. You'd be amazed how much of the Finder is still 68000 code... still I keep fuming at Phase 5 for that bizarre "cooperative RISC" approach to PowerPC, the fact that their method (currently) requires a real 68030 or 68040 processor in order to work. FatBinary-style Amiga combined-hunk executables? Not today, friends.

I must confess - I have been in league with the Shadows. I downloaded Microsoft Internet Explorer 3.0 Beta for the Mac the other day - and liked it.

IE3B1 is an unusual Microsoft product - it's an early Beta that's actually somewhat usable. Its toolbar isn't quite as snazzy as its Windows cousin, and it's missing a number of features - it's more like 2.2 than 3.0 - but it's actually not a bad little browser. It's quite well-behaved - is faster at certain things than Netscape - and has a much smaller memory footprint than Netscape 3. Plus it's got some handy features I like - the font size buttons, for example.

Oh, it's by no means perfect - fortunately. While it can play QuickTime and other media files internally, it doesn't quite understand when a page wants Netscape's plug-ins for the same file types - and doesn't play them. It has NO support for JavaScript at all. It uses "MactiveX" - which I'll get to in a moment. And - weirdest of all - it periodically freezes in place for 15 or 20 seconds at a time, exactly the way Netscape 1.1N used to do. It's also typical Microsoft in that it sometimes doesn't respond to user input - but then responds to it when you don't want it to, so you end up three pages back from where you wanted to be because it kept taking "back" clicks.

MactiveX is the result of Microsoft trying to bring ActiveX to the Mac. It's cool - you can run these nifty little controls in the browser window just like on the PC - but there's a million things wrong with it, most notably the fact that ActiveX controls have to be written AND COMPILED specially for the Mac in order to work. All those existing ActiveX components you see on Gamelan won't work. I TOLD you Microsoft was not going to make it truly cross-platform! Of course, Mac ActiveX also is a plug-in (at this time), meaning you might have a hell of a time just getting it operational. That's two distinct flavors of ActiveX - and they aren't cross-compatible at all. Hey Microsoft, "cross-platform" doesn't mean just Windows 95 and Windows NT.

But IE3B1 supports Java - sort of. Specifically it supports a sort of Java plug-in architecture, called JManager, into which you can insert the Java run-time engine of your choice, such as Apple's MacOS Java Runtime beta. IE3 will probably ship with Metroworks' Java bytecode accelerator - for acceptable Java speeds at long last, very useful since MactiveX is so nearly useless in the grand scheme.

IE3B1 is the most Mac-friendly Microsoft application I've seen. It doesn't gratuitously rape and kill the system. It changes the button style the same way many other Microsoft Mac apps do - much like Greg's Buttons - but it doesn't seem to be sidestepping the system in any large measure. The Power Mac version only eats about 5MB of RAM - remarkable for anything Microsoft these days. And it's faster at certain things than Netscape - so much that I keep saying "Oh this will take awhile" and then it's done instantly. (But other things are painfully slow... like the delay between clicking "stop" and actually seeing the thing stop.) It's better-looking than IE2.1 - the toolbar is a lot more stylish and less Windowsey - and does a bang-up job on actually rendering Web pages. It does some funny things when rendering forms - like drawing textareas without scrollbars - but otherwise is frighteningly competent as browsers go. It scares me.

So now the ball's in Netscape's court. They're promising a beta of Navigator 4 before the end of the year - I'm waiting. I don't like Microsoft - they're the bad guys - but they've got the upper hand now and they make a damn good browser. Now we wait.

Next up in this decidedly unfocused and scatterbrained issue is another emulator I managed to get hold of recently: a Dragon 32 emulator. You Merkins who have never heard of the Dragon, it was a mid-80's 8-bit computer with a 6809 processor, a 6847 graphics chip, and a 6883 sequential address multiplexer (a primitive PMMU) - sound familiar? Yep - a Color Computer clone, complete with a command-for-command compatible Microsoft BASIC ROM that was just different enough that Tandy couldn't sue.

I haven't played much with this emulator, mostly because I don't own a real Dragon ROM - oh I did succumb to the temptation to download one off the Net, but my conscience got to me, so now it's collecting dust on the hard drive. But I did get to see the long-awaited nostalgic neon green screen, ugly all-uppercase text, and multicolored caffeine-injected flashing cursor on an Amiga. And it did get me thinking.

I've kicked around the idea for some time of writing my own Color Computer emulator - I've got enough 6809 datasheets and know _just_ enough of the CoCo's memory map and architecture that I could at least begin such a project. I even figured out the Lazy Bunghole's Method of doing such - you implement a couple of 6809 instructions and some hardware registers in the $FF00 space, then throw a copy of the Extended Color BASIC ROM at it and let it run until it hits something you haven't implemented yet. Add that feature and run it again. Eventually, when it runs BASIC without crashing, you move on to running other software until it crashes too... and after awhile the whole system works. Then you start optimizing it. :-) Of course, it'd be easier for me to "bit-emulate" the 6809, instead of saying "IF instruction = "JSR" THEN gosub jsr_subroutine" for all 200-odd instructions - by bit-emulating, you'd say "if bit such-and-such is set this is an add, if this bit is set it's A, if that bit is set it's adding to memory..." and essentially emulate the _internals_ of the chip, possibly even going so far as adding pipelines and out-of-order execution. I'd definitely have to keep a "cycle counter", and internally keep track of how many cycles each instruction _should_ take on a real 6809 - so I could emulate a floppy drive by saying "OK it's been 45207 cycles, it's gonna try to read the drive now, I'd better have the right piece of data here waiting for it." (Also would be helpful for emulating raster-interrupt tricks - the CoCo equivalent of the Copperlist, the way CoCoMax III displayed all 64 colors at once.)

But that's awhile off.

Finally, the last and perhaps most important thing in this edition:

I need a job.

Columbus PBX is dying. While Compassworks - Web Builders for Business - is a separate company, it will be some time before the checks start rolling in. And I have rent coming due within the next 72 hours. So I have permission from everyone else in Compassworks to look for work where I can get it.

I hate resumes. If you're actually reading the Amiga Page and Rumor Mill, free-form rant that it is, it's doubtful you're the sort who requires a perfect resume - for a Web designer, a web page _is_ a resume anyway. So I'll just sorta bang out a list of what I can do and why you should hire me.

I know Macs, Windows 3.1 and 95, Unix, Amigas, and a little VMS. I know BASIC and Perl, and have some working knowledge of C/C++, REXX, and 6809 and 68000 assembly. I can use Photoshop and AutoCAD. I'm learning Imagine - but would learn quicker on something more modern. I know POV. I know a lot about the Amiga's inner workings - not as much as Dave Haynie but more than most - and Amiga users are a technical lot.

I can also write - as you've noticed. I can also run a cash register in my sleep - but I'm not sure that's the job I want. I draw - and have a weird escapist imagination well suited to game development and anything science-fiction related.

I attended Seymour High School, graduating in 1993. I then attended Indiana University-Purdue University, Columbus - and am still there, going for a Computer Technology degree at a somewhat casual pace. I've worked at Columbus PBX since June of 1995, building World Wide Web sites back before the Web was cool - prior to that I helped build IUPUC's local campus page. In 1994 I worked at Meadows Metal Products, doing their CAD work - I was the entire CAD department for seven months, dealing with a large volume of new parts. Prior to that, I worked at Waterjet, doing two-dimensional nesting and some 2-D outline graphics work with AutoCAD, CorelDraw, and some in-house nesting software. Contact information for these companies and more, plus references, are available - all you have to do is ask.

I live in Columbus, Indiana, but if the price is right, I can relocate. Just make sure I hear from you QUICKLY - I need to know very soon before I get too settled in or before I make a decision about classes next semester. I'd prefer somewhere within maybe 350 miles of my current location.

Now, while you're digesting all that, I'll go work on a "real" resume.