other irredeemably nerdy habit is roadgeeking, exploring and mapping highways both old and new, and it turns out that 8-bit roadgeeking on ordinary home computers was absolutely possible. For computers of this class, devising an optimal highway route becomes an exercise not only in how to encode sufficient map data to a floppy disk, but also performing efficient graph traversal with limited hardware. Today we'll explore Roadsearch-Plus, one of the (if not the) earliest such software — primarily on the Commodore 64, but originating on the Apple II — and at the end "drive" all the way from southern California to British Columbia along US Highway 395, my first long haul expedition, but as it was in 1985. Buckle up while we crack the program's runtime library, extract its database, and (working code included) dive deeply into the quickest ways to go from A to B using a contemporary home computer. Although this article assumes a little bit of familiarity with the United States highway system, I'll provide a 30-second version. The top-tier national highway network is the 1956 Eisenhower Interstate System (abbreviated I-, such as I-95), named for president Dwight D. Eisenhower who promulgated it, signed with red, white and blue shields. Nearly all of its alignments, which is to say the physical roads composing it, are grade-separated full freeway. It has come to eclipse the 1926 United States Numbered Highway System (abbreviated US, such as US 395), a nationally-numbered grid system of highways maintained by the states, albeit frequently with federal funding. Signed using a horned white shield, these roads vary from two-lane highway all the way to full freeway and may be multiplexed (i.e., multiply signed) with other US highways or Interstates in many areas. While they are no longer the highest class of U.S. national road, they nevertheless remain very important for regional links especially in those areas that Interstates don't service. States and counties maintain their own locally allocated highway systems in parallel. Here is a glossary of these and other roadgeek terms. Geographic information systems (GIS) started appearing in the 1960s, after Waldo Tobler's 1959 "Automation and Cartography" paper about his experience with the military Semi-Autographic Ground Environment system. SAGE OA-1008 displays relied on map transparencies developed manually but printed with computers like the IBM 704. Initially such systems contained only geographic features like terrain and coastlines and specific points of interest, but support for highways as a layer or integral component was rapidly implemented for land use applications, and such support became part of most, if not all, mainframe and minicomputer GIS systems by the late 1970s. However, these systems generally only handled highways as one of many resource or entity types; rarely were there specific means of using them for navigational purposes. Honda Electro-Gyrocator. Because Global Positioning System (GPS) satellite data was not then available for civilian applications and other radio navigational systems like LoRAN were hard to reliably receive in canyons or tunnels, it relied on its own internal gas gyroscope to detect rotation and movement aided by a servo in the car's transmission. The Electro-Gyrocator used a Texas Instruments TMS9980 (a derivative of the 16-bit TMS9900 in the TI-99/4A but with an 8-bit data bus) as its CPU and a sidecar TMS9901 for I/O. It had 10K of ROM, 1K of SRAM and 16K of DRAM, hopeless for storing map data of any consequence, so the actual maps were transparencies too; the 9980 integrated sensor data provided by the 9901 from the gyroscope and servo to plot the car's course on a small 6" CRT behind the map overlay. The user was expected to set the starting location on the map before driving and there was likewise no provision for routing. It was only made available that year for ¥300,000 (about US$2900 in 2025 dollars at current exchange rates) on the JDM Honda Accord and Honda Vigor, and discontinued by 1982. There were also a few early roadgeek-oriented computer and console games, which I distinguish from more typical circuit or cross-country racers by an attempt to base them on real (not fictional) roads with actual geography. One I remember vividly was Imagic's Truckin', a Mattel Intellivision-exclusive game from 1983 which we played on our Tandyvision One. Juggernaut for the ZX Spectrum by at least two years, and Juggernaut uses a completely fictitious game world instead. you're expected to do that! an easter egg. Besides very terse prompts and a heavily compressed internal routing table, the game makes all highway numbers unique and has no multiplexes or three-digit auxiliary Interstates, and while you can drive into Canada you can't drive into Mexico (admittedly it was pre-NAFTA). Additionally, for gameplay reasons every highway junction is a named "city," introducing irregularities like Interstate 70 ending in Provo, UT when it really ends about 130 miles south, or Interstate 15 ending in El Cajon, CA, and many cities and various two-digit primary Interstates are simply not included (e.g., I-12, I-19, I-30, I-85, I-93, etc.). As a result of these constraints, among other inaccuracies Interstate 90 terminates in Madison, WI at I-94 (not Boston), I-94 terminates in Milwaukee at I-55 (not Port Huron, MI), and I-40 is extended west from its true terminus in Barstow, CA along real-world California State Highway 58 to intersect I-5 "in Bakersfield" (real Interstate 5 is around twenty miles away). Still, it contains an extensive network of real highways with their lengths and control cities, managing it all on an early console platform with limited memory, while simultaneously supporting full 1983-level gameplay. The 8-bit home computer was ascendant during the same time and at least one company perceived a market for computer-computed routes with vacations and business trips. I can't find any references to an earlier software package of this kind for this class of computer, at least in the United States, so we'll call it the first. The Software Writer's Marketplace from 1984. If this is the same person, he later appears in a 2001 document as the Ground and Mission Systems Manager at the NASA Goddard Space Flight Center in Greenbelt, Maryland, about a half hour's drive away. Columbia Software does not appear in any magazines prior to 1982 nor does it appear after 1985, though no business record under that name is known to either the state of Maryland or the state of Delaware. T%(), N%() and B%() which sound like Applesoft BASIC integer arrays. (The file MPH just contains the MPG and MPH targets in text.) In fact, there are actually two compiled programs present, ROADSEARCH (the main executable) and DBA (the distance editor), and using these "variable" files allows both programs to keep the memory image of the arrays, no doubt the representation of its map database, consistent between them. You can start either compiled program by BRUNning them, as HELLO does. Exactly which compiler we can also make a fairly educated guess about: there were only a few practical choices in 1981-82 when it was probably written, and most of them we can immediately eliminate due to what they (don't) support or what they (don't) generate. For example, being almost certainly Applesoft BASIC would obviously eliminate any Integer BASIC compiler. It also can't be On-Line Systems' Expediter II because that generates "Applesoft BASIC" programs with a single CALL statement instead of binaries that are BRUN, and it probably isn't Southwestern Data Systems' Speed Star because of the apparent length of the program and that particular compiler's limited capacity. That leaves the two major compilers of this era, Microsoft's TASC ("The Applesoft Compiler"), which was famously compiled with itself, and Hayden Book Company's Applesoft Compiler. TASC uses a separate runtime that must be BLOADed before BRUNning the main executable, which HELLO doesn't do. Hayden's compiler is thus the most likely tool, and this theory is buoyed by the fact that this compiler does support variable sharing between modules. If we run strings on the DOS 3.3 .dsk image, we see things like Accounting for the fact that the disk interleave will not necessarily put lines in sequential order, you can pick out the strings of the program as well as a number of DOS 3.3 file manager commands, sometimes in pieces, such as B%(),A30733,L5448 which is probably part of a BSAVE command, or BLOAD B%(),A30733. The disk also has examples of both kinds of DOS 3.3 text files, both sequentially accessed (such as OPEN T%(), READ T%() and CLOSE T%()) but also the less commonly encountered random access (with explicitly specified record numbers and lengths such as OPEN ROADS,L12 and OPEN ROADMAP CITIES,L19, then READ ROADS,R and READ ROADMAP CITIES,R which would be followed by the record number). For these random access files, given a record length and record number, the DOS track-and-sector list is walked to where that record would be and only the necessary sector(s) are read to construct and return the record. We can see the contents with a quick Perl one-liner to strip off the high bit and feeding that to strings: Again note that the order is affected by the disk interleave, but the file is stored alphabetically (we'll extract this file properly in a moment). Another interesting string I found this way was "TIABSRAB WS AIBMULOC" which is COLUMBIA SW BARSBAIT backwards. Perhaps someone can explain this reference. In a hex editor the city database looks like this, where you can see the regularly repeating 19-byte record format for the names. Remember that the characters are stored with the high bit set. This is not a very efficient means of storage especially considering DOS 3.3 only had 124K free per disk side (after DOS itself and filesystem overhead), but it would be a lot easier for an Applesoft BASIC program to handle since the record lookup work could be shunted off to DOS 3.3 and performed quickly. Also, while you can list the cities and junctions from the menu, they are not indexed by state, only by first letter: ROADMAP CITIES to the emulator's virtual printer. We know its record length because it was stored as a string in the compiled BASIC text we scanned previously. That, in turn, gives us a text file we can read on the Mac side. It is, as expected, 406 lines long. The same process gets us the ROADS list, which is 171 lines long. Keep in mind that's just a list of the names of the roads; it does not contain information on the actual highway segments between points. T%()), where for each letter index 1-26, the value is the first record number for all cities starting with that letter. As we saw previously, the cities are already sorted on disk to facilitate. There are no cities starting with Z, so that letter just goes to the end of the file (non-existent record 407) and terminates. B%() and N%(), but we'll solve that problem a little later on. and updated routing information. However, this release appears to be specific to the Commodore port — if there were a 1985 map update for the Apple II, it has yet to surface — and I can find no subsequent release of Roadsearch after 1985 on any platform. Both C64 versions came in the same Roadsearch and Roadsearch-Plus variants for the same prices, so the iteration we'll explore here is Roadsearch-Plus with the presumed final 1985 database. For purposes of emulation we'll use VICE's SuperCPU spin with the 65816 enabled as some number crunching is involved, but I also tested it on my real Commodore SX-64 and 128DCR for veracity. (Running xscpu64 in warp mode will absolutely tear through any routing task, but I strongly recommend setting location 650 to 64 in the VICE monitor to disable key repeat.) It's worth noting that the various circulating 1541 disk images of the 1984 and 1985 editions were modified to add entries by their previous owners, though we'll point out how these can be detected and reversed. For much of this article I'll be running a 1985 disk that I manually cleared in a hex editor to what I believe was its original contents. ROADSEARCH+), the editor (IDBA) and two RELative files for the CITIES and ROADS. RELative files are functionally equivalent to DOS 3.3 random access files, being a record-based file format with a fixed size and an index (made up of "side sectors"). They are an uncommon sight on commercial software due to their idiosyncracies and a few outright bugs, and they don't work well for binary data or support variable record sizes which is why Berkeley Softworks came up with VLIR for GEOS instead. On the other hand, they do just fine for text strings and the lookup can be very fast. The cities file looks like this when dumping the raw sectors from the .d64 disk image: The directory entry indicates a file with 31-byte records, the first side sector at track 19 sector 10 and the first data sector (shown in part below) at track 19 sector 0. Other than the obvious typo in Abilene, TX, it is the same basic format as the Apple version and also sorted, ending each string with a carriage return. As a method of what I assume prevents trivially dumping its contents, a naive read of each record won't yield anything useful because every record starts with an $ff and a whole bunch of nulls, which Commodore DOS interprets as the end. The actual string doesn't start until offset 12. The same basic idea holds for the roads file: The same offset trick is used, but here the records are 24-byte since route names are shorter. Again, this isn't a particularly efficient storage mechanism, but we have over 165K available on a formatted disk, and RELative file access to any arbitrary record is quite quick. Despite the presence of side sectors, the actual records of a RELative file are still sequentially stored on disk with the usual forward track and sector pointers. As such, we don't need to grab the side sectors to simply extract its contents. For some period of time the c1541 tool from the VICE suite would not copy REL files and this was only recently fixed, so here is a Perl script I threw together to iterate over a D64 disk image and transfer a file to standard output, either by name or if you specify a starting track and sector. Because this yanks the files "raw," we will then need to strip them down. Feed the extracted REL records to this and you'll get a text file: You'll notice that both the cities and roads lists are, or at least start out, sorted. All C64 Roadsearch images I've seen circulating so far have been altered by their previous owners to add their own local roads and cities, and their changes can be easily distinguished at the point where the lists abruptly go out of alphabetical order. There is also a pair of SEQuential files, one named MPH and serving the same function to store the preferred speed and fuel economy, and a second one simply named M. This file contains four ASCII numbers, one obviously recognizeable as our serial number, though this is only one of the two places the program checks. The others are the number of cities (406, or 487 in the 1985 version), number of roads (215 in 1985), and a third we don't yet know the purpose of. You can confirm the first two by checking it against the number of lines in the files you extracted. What we don't see are files for the arrays we spotted on the Apple disk. The only file left big enough to account for those is MATS. To figure out how that works, we should start digging into the program. RTL-64, a runtime library and the telltale sign of a program compiled with DTL BASIC. DTL BASIC, formally DTL-BASIC 64 Jetpack, became extremely popular with developers not just due to its good performance and compatibility but also requiring no royalties to sell programs compiled with it as long as credit was given. An optional "protector" version can obfuscate the program and/or require a hardware dongle, though this version is rarer due to its expense (and fortunately was not used here). The runtime library slots into the RAM under the BASIC ROM, so there is no obvious loss of free memory. DTL stood for "Drive Technology Ltd." and was written by David Hughes in the UK, first for the PET; the compiler is notable for being compiled with itself, like Microsoft TASC, and using the same "RTL" runtime library and protection system (and, obnoxiously, a dongle) as the object code it generates. The 64 tape version is substantially less capable than the disk one. DTL BASIC compiles to its own bespoke P-code which is executed by the RTL. It achieves its speed through a greater degree of precalculation and preparsing (e.g., pre-resolving values and line numbers, removal of comments, etc.), a custom garbage collection routine, and also, where possible, the use of true signed 16-bit integer math. This is a substantial speed-up over most Microsoft-derived BASICs, in which Microsoft Binary Format floating point is the native system for all calculations to the point where integer variables must first be converted to floating point, the computation performed, and then converted back. Ordinarily this would only make them useful for smaller arrays in memory because the double conversion will make them slower than regular floating point variables. However, DTL BASIC does perform true integer math without conversion, first for all variables explicitly declared as integer, and even autoconverting other variables at compile time with a directive (pragma). Although some private work on a decompiler reportedly exists, to the best of my knowledge that decompiler remains unfinished and unavailable. Interestingly, what I presume is the earlier 1984 disk image has some ghost directory entries, two each for the source BASIC programs and their "symbol tables" used by ERROR LOCATE for runtime errors: Sadly these source files were overwritten and cannot be resurrected, and even the ghost entries were purged on the second 1984 image. However, two aspects of the compiler make it possible to recover at least a portion of the original program text by hand. The first is that not all statements of the original program are fully converted to P-code: in particular, READ/DATA, OPEN, INPUT/INPUT#, DIM, PRINT/PRINT# and possibly others will be preserved nearly in their original BASIC form, including literal strings and most usefully variable names. For example, if we pull the compiled ROADSEARCH+ off the disk image and run it through strings, we see text not unlike a BASIC program: DTL-compiled programs always start with an SYS 2073 to jump into a small machine-code subroutine linked into the object. This section of code loads the RTL (the filename follows) and has other minor housekeeping functions, including one we'll explain shortly when we break into the program while it's running. It resides here so that it can bank BASIC ROM in or out as necessary without crashing the computer. Following that is an incomplete machine language subroutine in a consolidated DATA statement. Disassembly of the fragment shows it's clearly intended to run from $c000, but at least part of it is missing. Of the portion we can see here, however, there are calls for what appears to be a Kernal load, so if we drop a breakpoint on $ffba in VICE (e.g., the Kernal SETLFS routine) we can run the 6502's call stack back to see the full routine and the filename (at $c0e1) it's trying to access: MATS. It loads it straight into memory in the middle of the available BASIC range. After that, now we see the arrays we saw in the Apple II version, but more importantly they're clearly part of DIM statements, so we can also see their dimensions. We already knew T%() was likely to be only 26 (27 counting the zero index) integers long from dumping the Apple version's contents, but the N%() array has up to 757 entries of five fields each, and B%() is even bigger, with 1081 records of four fields each. This is obviously where our map data is stored, and MATS is the file it seems to be loading to populate them. This brings us to the second aspect of DTL Jetpack that helps to partially decipher the program: to facilitate some reuse of the BASIC ROM, the generated code will still create and maintain BASIC-compatible variables which we can locate in RAM. So that we know what we're dealing with, we need to figure out some way to stop the program while it's running to examine its state. Naturally the compiler offers a means to defeat this. ; warm start (2061) .C:080d 20 52 08 JSR $0852 .C:0810 4C 2B A9 JMP $A92B ; not called? .C:0813 20 52 08 JSR $0852 .C:0816 4C 11 A9 JMP $A911 ; cold start (2073) ; load the RTL if flag not set, then start P-code execution .C:0819 20 52 08 JSR $0852 .C:081c AD FF 02 LDA $02FF .C:081f C9 64 CMP #$64 .C:0821 F0 17 BEQ $083A .C:0823 A9 3F LDA #$3F .C:0825 85 BB STA $BB .C:0827 A9 08 LDA #$08 .C:0829 85 BC STA $BC .C:082b A9 06 LDA #$06 .C:082d 85 B7 STA $B7 .C:082f A9 00 LDA #$00 .C:0831 85 B9 STA $B9 .C:0833 A2 00 LDX #$00 .C:0835 A0 A0 LDY #$A0 .C:0837 20 D5 FF JSR $FFD5 .C:083a 68 PLA .C:083b 68 PLA .C:083c 4C 48 A0 JMP $A048 .C:083f .asc "RTL-64" ; seems to get called on a crash or error .C:0845 20 52 08 JSR $0852 .C:0848 20 2F A0 JSR $A02F ; jumps to $a948 .C:084b 20 5F 08 JSR $085F .C:084e 60 RTS ; dummy STOP routine .C:084f A2 01 LDX #$01 .C:0851 60 RTS ; bank out BASIC ROM .C:0852 A9 03 LDA #$03 .C:0854 05 00 ORA $00 .C:0856 85 00 STA $00 .C:0858 A9 FE LDA #$FE .C:085a 25 01 AND $01 .C:085c 85 01 STA $01 .C:085e 60 RTS ; bank in BASIC ROM .C:085f 48 PHA .C:0860 A9 03 LDA #$03 .C:0862 05 00 ORA $00 .C:0864 85 00 STA $00 .C:0866 A5 01 LDA $01 .C:0868 09 01 ORA #$01 .C:086a 85 01 STA $01 .C:086c 68 PLA .C:086d 60 RTS ; execute next statement (using BASIC ROM) .C:086e 20 5F 08 JSR $085F .C:0871 20 ED A7 JSR $A7ED .C:0874 20 52 08 JSR $0852 .C:0877 60 RTS DS and ES compiler directives which disable and enable RUN/STOP respectively. If we scan the RTL for code that modifies $0328 and $0329 where the STOP routine is vectored, we find this segment: $f6ed is the normal value for the STOP vector, so we can assume that the routine at $b7c9 (which calls the routine at $b7da to set it) enables RUN/STOP, and thus the routine at $b7e5 disables it. Both routines twiddle a byte at $a822, part of this section: By default the byte at $a822 is $ea, a 6502 NOP. This falls through to checking $91 for the state of the STOP key at the last time the keyboard matrix was scanned and branching accordingly. When the STOP routine is revectored, at the same time the byte at $a822 is changed to $60 RTS so that the STOP key check is never performed. (The RTL further achieves additional speed here by only doing this check on NEXT and IF statements even if the check is enabled.) The simplest way to deal with this is to alter RTL-64 with a hex editor and turn everything from $b7e5 to $b7ec inclusive into NOPs. This turns the DS directive into a no-op as well, and now we can break out of the program by mashing RUN/STOP, though we'll do this after MATS is loaded. Parenthetically, instead of using CONT, the compiled program can be continued with SYS 2061 instead of SYS 2073. T%(), since we've assumed it has the same purpose in the Commodore port, and it does (once again there are no cities starting with Z, so the final letter points to non-existent record 488 beyond Yuma, AZ as record 487). We then use the BASIC routine at $b08b (SYS 45195) to look up the address of the first variable in the array — note no comma between the SYS and the variable reference — which is deposited as a 16-bit address in location $47 (71). In this case the pointer is to $6b8a (27530), the actual zeroth data element, so if we rewind a few bytes we'll also get the array descriptor as well as its entire contents: C:6b83 d4 80 3d 00 01 00 1b 00 01 00 01 00 0f 00 2d 00 >C:6b93 52 00 60 00 69 00 7c 00 8b 00 97 00 ed 00 f6 00 >C:6ba3 fe 01 16 01 36 01 43 01 4e 01 62 01 63 01 70 01 >C:6bb3 a3 01 b6 01 c8 01 cf 01 e4 01 e4 01 e8 big-endian: the dimensions themselves (a single big-endian short specified as 27, i.e. 26 plus the zeroth element), and then each value. In multidimensional arrays, each dimension is run out fully before moving to the next. We can easily pick out the values we saw for T%() in the above dump, but more importantly we now have a long unambiguous 61-byte key we can search for. The entire sequence shows up in MATS, demonstrating that the file is in fact nothing more than an in-place memory dump of the program arrays' contents. Rather than manually dump the other two arrays from BASIC, we can simply walk MATS and pull the array values directly. This Perl script walks a memory dump of arrays (currently only two-dimensional integer arrays are implemented because that's all we need for this project). It skips the starting address and then writes out tab-separated values into files named by the arrays it finds. Unlike their storage in memory, where values go (0,0), (1,0), (2,0) ... (0,1), (1,1) and so on, this pivots the arrays horizontally so you get (0,0), (0,1), (0,2), etc., grouped into lines as "rows." B%() is the easiest to grok. Ignoring index 0, here is an extract from the file: B%() is referenced directly in one PRINT statement when displaying outgoing roads from a particular city: Let's take city record number 1, which is the misspelled (but only in the 1985 version) ABILINE TX (that is, Abilene, Texas). The develop-a-route feature will list all connected cities. For Abilene, there are five in the database. PRINTed. PRINTs above that B%(I,3) represents the mile length of the current connecting segment indexed by I (here 39), which would make B%() the array containing the connecting roads between cities and junctions. We also know it gets R$ and C$ from the RELative files ROADS and CITIES on each row. Helpfully, it tells us that FORT WORTH TX is city number 115 (it is), which we can see is B%(I,1). B%(I,2) is 1, which must be us, leaving B%(I,0) as the route number which must be the record number for Interstate 20 in ROADS. If we grab line 39 from out-B% (the value of index I), we do indeed see these same values. However, we can now do the search ourselves by just hunting for any record containing city 1 in columns 1 or 2 of our dumped array file (^I is a TAB character): Or, to show the correspondence more plainly: B%(). N%(), on the other hand, is a little harder to crack. Other than its apparent DIM statement at the beginning (as shown above), it is never displayed directly to the user and never appears again in plaintext in the compiled object. Here are the first few entries of the array: The first record (index 0) is the second place where the serial number is stored, though only the map editor references it. Not counting index 0 the file has exactly one record for every city or junction, so it must correspond to them somehow. Otherwise, column 3 (except for index 0) is always an unusual value 32,766, near the positive maximum for a 16-bit integer variable, and columns 4 and 5 are always zero (note from the future: this is not always true for routes which are added in the editor). Additionally, columns 1 and 2 have an odd statistical distribution where the first is always between 4499 and 8915 and the second between 11839 and 21522. There are no negative values anywhere in the file, and the first three columns are never zero (other than index 0). Whatever they are, they are certainly not random. The meaning of the values in this array managed to successfully evade my understanding for awhile, so in the meantime I turned to figuring out how Roadsearch does its routing. The theorists reading this have already internalized this part as an exercise in graph traversal, specifically finding the shortest path. Abstractly the cities and junctions can be considered as the nodes or vertices of a graph. These nodes are enumerated by name in CITIES with additional, currently opaque, metadata in N%(). The nodes are then connected with edges, which are weighted by their mile length. These edges are the highway alignments listed with termini and length in B%() and their names in ROADS. The program appears to universally treat all edges as bi-directional, going both to and from a destination, which also makes the graph generally undirected. Because of the way the database (and indeed the nature of the American highway network) is constructed, all nodes are eventually reachable from any other node. For a first analysis I presented Roadsearch with a drive I know well, having done it as part of longer trips many times in both directions: Bishop, California (city number 31) to Pendleton, Oregon (city number 338). This run can be traveled on a single highway number, namely US Highway 395, and it is also the shortest route. I have not indicated any roads that should be removed, so it will use everything in its database. five seconds. No, warp mode was not on. Take note of the progress display showing miles traveled. This is the first milepoint that appears. If we compare the edges (highway alignments) directly leaving from Bishop and Pendleton, an edge with a weight (length) of 198 miles only shows up leaving Pendleton, suggesting the program works the routing backwards: Edsger Dijkstra's algorithm, conceived in 1956 and published in 1959, an independent reimplementation of Vojtěch Jarník's 1930 minimum spanning tree algorithm that was also separately rediscovered and published by Robert C. Prim in 1957. In broad strokes, the algorithm works by building a tree out of the available nodes, putting them all into a queue. It keeps an array of costs for each node, initially set to an "infinite" value for all nodes except for the first node to be examined, traditionally the start point. It then repeatedly iterates over the queue: of all current nodes in the queue the lowest cost node is pulled out (so, first out, this will be the start point) and its edges are examined, selecting and marking any edges where the sum of the current node's cost and the cost of the edge (the mile length) are less than the current cost of the node it connects to (which, first out, will be "infinite"). The nodes connected by these marked edges take the current node as their parent, constructing the tree, and store the new lower cost value. Once the queue is empty, the algorithm halts and the tree is walked backwards from the target back to the start point, accumulating the optimal route using the parent pointers. This Perl script accepts two city numbers and will generate the optimal route between them using the Roadsearch database with Dijkstra's algorithm. It expects cities, roads (both converted to text, not the raw RELative files) and out-B% to be in the same directory. We build arrays of @cities and @roads, and turn B%() into @edges and @a (for arcs) for expedience. We then walk down the nodes and build the tree in @s, noting which arc/edge was used in @prou so that we can look it up later, and then at the end walk the parent pointers back and do all the dereferencing to generate a human-readable route. As a check we also dump @s, which indexes @edges. Here's what it computes for Bishop to Pendleton, forward and reverse: This is the same answer, and Dijkstra's algorithm further gives us a clue about one of the columns in N%() — the one which is invariably 32766. We already know from the plaintext portion of the compiled program that there are no other arrays, so the routing must be built in-place in the arrays that are present. We need an starting "infinite" value for each node within the range of a 16-bit signed integer, and no optimal path in continental North America would ever exceed that mileage, so this is the "infinite" value used to build the route into N%(). (It gets reset by reloading MATS if you select the option to start over after route generation.) That said, it's almost certain that the program is not using an implementation of Dijkstra's algorithm. The queue starts out with all (in this case 487) nodes in it, making finding the lowest cost node in the queue on each iteration quite expensive on a little ~1.02MHz 6502. The usual solution in later implementations is a min-priority queue to speed up the search, but we already know there are no other arrays in memory to construct a faster heap or tree, so any efficiency gained would likely be unimpressive. Furthermore, it's not clear the author would have known about this approach (the earliest work on it dates to the late 1970s, such as Johnson [1977]), and even if he did, it still doesn't explain the meaning of the first two columns in N%() which aren't even used by this algorithm. After all, they're not there for nothing. E(x) specific to the problem being examined to walk from a source to a target node, terminating when the target was reached. In the process it created a set of partial trees from the source to the target from which the lowest cumulative value of E(x) would ultimately be selected, starting with individual nodes where E(x) to some next immediate destination was locally smaller. Additionally, since it was now no longer required to construct a complete tree touching every possible node, the initial set of nodes considered could simply be the starting point. How the evaluation function was to be implemented was not specified, but a simple straight-line distance to the goal node would have been one logical means. Raphael instead suggested that the function to be minimized be the sum of the distance to the goal node and the evaluation function, which was reworked as a heuristic. The heuristic thus provided a hint to the algorithm, ideally attracting it to the solution sooner by considering a smaller set of nodes. If the heuristic function was properly admissible — what Hart defined as never overstating the actual cost to get to the target — then this new algorithm could be proven to always find the lowest-cost path and greatly reduce comparisons if the solution converged quickly. Considering Graph Traverser as algorithm "A," this more informed goal-directed algorithm was dubbed "A*" (say it A-star). If Roadsearch really is using A-star, at this point we don't know what the heuristic function is. (Note from the future: stay tuned.) Fortunately, a heuristic function that returns zero for all values is absolutely admissible because it will never overstate the actual cost. Although as a degenerate case doing so effectively becomes Dijkstra's algorithm, we'll still observe the runtime benefit of not having an initial queue potentially containing all possible nodes and being able to terminate early if the target is reached (which is always possible with Roadsearch's database). To make the number of nodes more manageable for study, since we will also want to observe how the program behaves for comparison, we'll now consider a smaller routing problem that will be easier to reason about. #!/usr/bin/perl die("usage: $0 point_no_1 point_no_2\n") if (scalar(@ARGV) != 2); $p1 = $ARGV[0]; $p2 = $ARGV[1]; die("wherever you go there you are\n") if ($p1 == $p2); open(K, "cities") || open(K, "cities.txt") || die("cities: $!\n"); @cities = ( undef ); while(<K>) { $ln++; if ($ln==$p1) { $v1=$p1; print; } if ($ln==$p2) { $v2=$p2; print; } chomp; push(@cities, $_); # default gscore and fscore $gscore[$ln] = 99999; $fscore[$ln] = 99999; } die("both cities must be valid\n") if (!$v1 || !$v2); close(K); open(R, "roads") || open(R, "roads.txt") || die("roads: $!\n"); open(B, "out-B%") || die("out-B%: $!\n"); @roads = ( undef ); while(<R>) { chomp; push(@roads, $_); } close(R); $ee = 0; while(<B>) { chomp; ($rn, $c1, $c2, $d) = split(/\t/, $_); $rn += 0; $c1 += 0; $c2 += 0; $d += 0; next if (!$d || !$c1 || !$c2 || !$rn); push(@edges, [ $rn, $c1, $c2, $d ]); push(@{ $a[$c1] }, [ $rn, $c2, $d, $ee ]); push(@{ $a[$c2] }, [ $rn, $c1, $d, $ee++ ]); } close(B); @camefrom = (); @openset = ( $v1 ); $gscore[$v1] = 0; $fscore[$v1] = 0; # heuristic of distance is 0 for the start while(scalar(@openset)) { @openset = sort { $fscore[$a] <=> $fscore[$b] } @openset; print join(", ", @openset), "\n"; $current = shift(@openset); last if ($current == $v2); foreach $n (@{ $a[$current] }) { $ni = $n->[1]; $tgscore = $gscore[$current] + $n->[2]; if ($tgscore < $gscore[$ni]) { $camefrom[$ni] = $current; $routefrom[$ni] = $n->[3]; $gscore[$ni] = $tgscore; $fscore[$ni] = $tgscore + 0; # "heuristic" unless (scalar(grep { $_ == $ni } @openset)) { push(@openset, $ni); } } } } @s = ( ); while(defined($camefrom[$current])) { $route = $routefrom[$current]; $current = $camefrom[$current]; unshift(@s, $route); } print join(' - ', @s), "\n"; $miles = 0; foreach(@s) { print $roads[$edges[$_]->[0]], "($edges[$_]->[0]) - ", $cities[$edges[$_]->[2]], "($edges[$_]->[2]) - ", $cities[$edges[$_]->[1]], "($edges[$_]->[1]) ", $edges[$_]->[3], " miles\n"; $miles += $edges[$_]->[3]; } print "total $miles miles\n"; f(x) (realized here as @fscore) and g(x) (@gscore). The G-score for a given node is the currently known cost of the cheapest path from the start to that node, which we build from the mile length of each edge. The node's F-score is its G-score plus the value of the heuristic function for that node, representing our best guess as to how cheap the overall path could be if the path from start to finish goes through it. In this case, the F-score and G-score will be identical because the heuristic function in this implementation always equals zero. Also, because we're interested in knowing how many fewer nodes we've considered, we dump the open set on every iteration. % route-dij 375 311 NEEDLES CA SAN BERNARDINO CA 237 - 236 - 63 - 719 I 15 - SAN BERNARDINO CA - US395/I15 CA 27 miles I 15 - US395/I15 CA - BARSTOW CA 44 miles I 40 - BARSTOW CA - I40/US95 CA 134 miles I 40 - I40/US95 CA - NEEDLES CA 12 miles total 217 miles % route-astar 375 311 NEEDLES CA SAN BERNARDINO CA 375 443, 335, 274, 376 335, 274, 442, 18, 376 274, 442, 18, 376, 34 442, 18, 376, 171, 380, 34 18, 376, 171, 380, 15, 34, 31 376, 171, 380, 15, 34, 169, 262, 31 424, 171, 380, 15, 34, 169, 262, 31, 487 171, 380, 15, 34, 169, 262, 31, 487 380, 15, 34, 169, 275, 262, 31, 487 15, 34, 169, 275, 262, 31, 379, 487 34, 45, 169, 275, 262, 31, 379, 487 45, 169, 275, 262, 31, 379, 311, 487, 342 169, 275, 262, 31, 379, 311, 119, 487, 342 275, 311, 262, 31, 379, 119, 487, 342 311, 262, 31, 379, 336, 119, 487, 170, 342 237 - 236 - 63 - 719 I 15 (31) - SAN BERNARDINO CA (375) - US395/I15 CA (443) 27 miles I 15 (31) - US395/I15 CA (443) - BARSTOW CA (18) 44 miles I 40 (60) - BARSTOW CA (18) - I40/US95 CA (169) 134 miles I 40 (60) - I40/US95 CA (169) - NEEDLES CA (311) 12 miles total 217 miles % route-astar 311 375 NEEDLES CA SAN BERNARDINO CA 311 169, 251, 34 251, 34, 262, 18 168, 34, 262, 18 34, 262, 18, 475, 110 262, 18, 475, 110, 335, 342 454, 18, 475, 110, 335, 342, 427 18, 475, 110, 335, 342, 53, 427, 446 442, 443, 475, 110, 335, 342, 53, 427, 446 443, 475, 110, 335, 342, 15, 53, 427, 31, 446 475, 110, 375, 335, 342, 15, 53, 427, 31, 446 110, 375, 335, 342, 15, 53, 427, 31, 446 375, 335, 342, 15, 53, 427, 31, 446, 124, 247 719 - 63 - 236 - 237 I 40 (60) - I40/US95 CA (169) - NEEDLES CA (311) 12 miles I 40 (60) - BARSTOW CA (18) - I40/US95 CA (169) 134 miles I 15 (31) - US395/I15 CA (443) - BARSTOW CA (18) 44 miles I 15 (31) - SAN BERNARDINO CA (375) - US395/I15 CA (443) 27 miles total 217 miles N%(), we'll instruct VICE to trap each integer array write to the range covered by MATS. (Trapping reads would also be handy but we'd go mad with the amount of data this generates.) We can get the value being written from $64/$65 (using the BASIC #1 floating point accumulator as temporary space) based on this code in the RTL: On each store we'll duly log the value in $64/$65 (remember it's big-endian) and the address it's being stored to. I wrote a one-off script to turn this string of writes into array offsets so we can understand how they relate to N%(), and then look them up in the tables so that we know which node and edge is under consideration. Remember, Roadsearch works this problem backwards starting with Needles. From the above you can see where the program marks the order of each node and the accumulated mileage. Our running totals, most likely the F-score and G-score, for a given node x are in N%(x,1) and N%(x,2), the length of the candidate edge is in N%(x,1), the optimal edge for the node is in N%(x,4), and the iteration it was marked in is recorded in N%(x,3). (We count an iteration as any loop in which a candidate node is marked, which in this simple example will occur on every run through the open set.) N%(x,0) also looks like a distance, but it doesn't correlate to a highway distance. To construct the itinerary at the end, it starts with San Bernardino and then repeatedly walks the selected edge to the next node until it reaches Needles. It's painfully obvious that compared to our models Roadsearch is considering a much smaller number of nodes (18, 34, 169, 251, 262, 311, 375, 442 and 443), counting the five in the optimal solution, and it duly converges on the optimal routing in just four iterations compared to twelve in our best case. I did look at its read pattern and found that N%(x,0) and N%(x,1) lit up a lot. These values are clearly important to computing whatever heuristic it's using, so I pulled out a few from across North America. I stared at it for awhile until it dawned on me what the numbers are. Do you see what I saw? Here, let me plot these locations on a Mercator projection for you (using the United States' territorial boundaries): coordinates. The first column increases going north, and the second column increases going west. Indeed, in the very paper written by Hart et al., they suggest that the straight-line distance from the current node to the goal would make a dandy heuristic and now we can compute it! The thing we have to watch for here is that the scales of the mileage and the coordinates are not identical, and if we use a simple distance calculation we'll end up clobbering the cumulative mileage with it — which would not only make it non-admissible as a heuristic, but also give us the wrong answer. To avoid that, we'll compute a fudge factor to yield miles from "map units" and keep the heuristic function at the same scale. Let's take San Diego, California to Bangor, Maine as a reference standard, for which computing the geodesic distance using WGS 84 yields 2,696.83 miles from city centre to city centre as the crow flies. If we compute the straight-line distance between them using the coordinates above, we get 8703.63 "map units," which is a ratio of 3.23:1. To wit: We now have implemented an h(x) that for a given node x returns its straight-line distance from the target node. Let's try it out. Remembering that Roadsearch works it backwards, we converge on the same solution examining the same nodes in the same number of iterations (four). Further proof is if we dump the program's array writes for the opposite direction: This routing proceeds in six iterations, just as we do, and once again the nodes we end up considering in our new A-star model are also the same. It also explains N%(x,0) — this is the straight-line distance and thus our heuristic, calculated (it's backwards) as the distance to the "start." For example, Palm Springs is indeed roughly 135 miles from Needles as the crow flies, again depending on your exact termini, whereas the western US 95/Interstate 40 junction is only about 11 miles. It should also be obvious that this "fudge" divisor has a direct effect on the efficiency of the routine. While we're purportedly using it as a means to scale down the heuristic, doing so is actually just a backhanded way of deciding how strongly we want the heuristic weighted. However, we can't really appreciate its magnitude in a problem space this small, so now we'll throw it a big one: drive from San Diego (376) to Bangor (17). (I did myself drive from Bangor to San Diego in 2006, but via Georgia to visit relatives.) This route requires a lot more computation and will also generate multiple useless cycles in which no node is sufficiently profitable, so I added code to our heuristic A-star router to explicitly count iterations only when a candidate node is marked: With our computed initial fudge factor of 3.23, we get this (again, worked backwards): And now for the real thing. quick. Both our simulation and the real program agree on the optimal route, as demonstrated by the cumulative mileage. N%(x,3). Interestingly, we do not: our simulation converged on the optimal route in 328 iterations, but the Commodore got it in 307. However, if we tune our simulation's fudge factor to 3.03, we also get it in 307. Is there an optimal fudge divisor? We know the optimal route, so we'll run a whole bunch of simulations over the entire interval, rejecting ones that get the wrong answer and noting the iterations that were required for the right ones. In fact, we can do this generally for any routing by using the longhand Dijkstra method to get the correct answer and then run a whole bunch of tweaked A-stars compared with its routing after that. In our simulation, stepping the fudge divisor over the interval from 0 inclusive to 4 by 0.001 increments, I ran six long haul drives in total, San Diego (376) to Bangor (17) and back, Bellingham, WA (24) to Miami, FL (291) and back, and then San Francisco, CA (377) to Washington, DC (465) and back. I then plotted them all out as curves. h(x)=0 heuristic from above, which is always accurate and the least goal directed (and consequently requires the most iterations). First off, there is no single fudge divisor that always yields the most optimal route for all of our test cases. Notice how much of the graph yields absolutely wrong answers (so nothing is plotted), and even in the interval between around 2.2 and 2.8 or so not all of the curves are valid. They all become valid around 3, which I enlarged in the inset on the left, and each one's iteration count slowly rises after that with the zero heuristic as more or less the upper asymptote. Except for the purple curve, however, 3 is not generally their lower bound. Second, there is no single fudge divisor that always corresponds to the program's iteration count, which is 311 (17 to 376), 307 (376 to 17), 183 (291 to 24), 264 (24 to 291), 261 (377 to 465) and 220 (465 to 377). With the value of 3.03 from above, however, our simulation generally does better than the real thing, which is both gratifying for the purposes of pathfinding and frustrating for the purposes of modeling. B%(x,3)). That assures it will always have an insuperably high cost, yet be unlikely to overflow if it's involved in any calculations, and thus it will never be pulled from the open set for evaluation. The in-memory database is always reloaded from disk after the route is disposed of. As our final stop in this article nearly as long as some of the drives we've analysed, we'll do my first 2005 long haul expedition along US Highway 395. This is a useful way to show how to add your own roads and what the program does with that, since not all of its segments are in the database. M, which will then cause the program to ignore any extraneous ones. Style points are added if you clear the records in the RELative files and turn them into nulls, though this isn't required. For the 1985 release, set M to 20 34 38 37 20 0D 20 37 37 35 20 0D 20 32 31 35 20 0D 20 39 39 39 39 20 0D, which is (in PETSCII) 487 cities, 775 road segments, 215 road names and serial number 9999 or as you like. (Note this will not change the serial number in the editor, but with this patch you're only using the main program in any case.) However, if you try to use a disk modified this way to add routes or cities, it will correctly recognize the new ones as new but erroneously find their old links in the arrays. That will not only get you unexpected residual road links to any new cities, but the links' presence can also confuse the program to such an extent it will end up in an infinite loop. In this case you'll need to delete these hanging links by patching MATS to null out the entries in B%() and N%() referring to city numbers greater than 487 and road numbers greater than 215 (remember that there are three arrays in that file and that multi-dimensional arrays run out each dimension before going to the next, meaning you can't just truncate it and stuff nulls on the end). This is simple to understand in concept but a little tedious to do, so I have left this as an exercise for the reader. Should I come up with a clean MATS myself, I will put it up somewhere if there is interest; for now we'll do our work on a well-loved copy which means that the city numbers you see here may not necessarily be the ones you get if you're following along at home. From there it proceeded north to the Columbia River gorge and intersected US 730 further west, then went east with it as before to US 12. This intermediate state is shown on this 1976 Donnelley atlas page, with the relevant portion highlighted. It was not until around 1986-7 when Interstate 82 was completed that US 395 was moved to I-82 instead as its present-day routing, leaving only a tiny residual overlap with US 730 east of Umatilla, Oregon. The problem is that none of these locations have waypoints we can easily connect to. M or MATS to disk until this point so that if the process gets aborted in the middle, the database remains internally consistent except for some harmless unreferenced RELative file records that can be overwritten later. N%() as its heuristic, but we were never asked for anything like latitude or longitude. How, then, can it get this information for the new cities we just created? At this point I dumped the RELative files and the new MATS to find out, and it so happens that the new city gets the same coordinates as the one it was connected to: both Wallula Junction and Walla Walla get coordinates 8062 and 20802, which are Walla Walla's coordinates. As we are connecting a couple new cities together along US 12, they also get the same coordinates, up to Yakima which retains its own. If we extended from both sides into the middle it would probably have made the database slightly more accurate at the cost of some inconvenient dancing around. This would be a good idea if you needed to reconstruct or chop up a particularly long segment, for example. I had also made an earlier call-forward that cities added from the editor sometimes don't have columns 4 or 5 set to zero. I can see this for the entries the previous owner entered, but all of mine ended up zero, so I'm not sure under what conditions that occurred. It doesn't seem to matter to the program in any case. .d64 disk images for this program all show new routes had been added suggests they got non-trivial usage by their owners, which really speaks to the strengths of the program and what it could accomplish. While it's hardly a sexy interface, it's functional and straightforward, and clearly a significant amount of time was spent getting the map data in and tuning up the routing algorithm so that it could perform decently on an entry-level home computer. Unfortunately, I suspect it didn't sell a lot of copies, because there are few advertisements for Columbia Software in any magazine of the time and no evidence that the Commodore version sold any better than the Apple II release did. That's a shame because I think its technical achievements merited a better market reception then, and it certainly deserves historical recognition today. We take things like Google Maps almost for granted, but a program that could drive a highway map on your 1985 Apple or Commodore would truly have been fascinating. As for me, I look forward to another long haul road trip in the future, maybe US 95 or US 101, or possibly reacquainting myself with US 6 which I drove in 2006 from Bishop to Cape Cod, Massachusetts. Regardless of where we end up going, though, this time we won't be taking the SX-64 with us — my wife has insisted on getting her seat back.

I like the Power ISA very much, but there's nothing architecturally obvious to say that the next natural step from the Motorola 68000 family must be to PowerPC. For example, the Palm OS moved from the DragonBall to ARM, and it's not necessarily a well-known fact that the successor to Commodore's 68K Amigas was intended to be based on PA-RISC, Hewlett-Packard's "Precision Architecture" processor family. (That was the Hombre chipset, and prototype chips existed prior to Commodore's demise in 1994, though controversy swirled regarding backwards compatibility.) Sure, Apple and Motorola were two-thirds of the AIM alliance, and there were several PowerPC PowerBooks available when the fall of 1997 rolled around. But what if the next PowerBooks had been based on PA-RISC instead? Well, no need to strain yourself imagining it. Here's nearly as close as you're gonna get. that game we must all try running), analyze its performance and technical underpinnings, and uncover an unusual artifact of its history hidden in the executable. (A shout-out to Paul Weissman, the author and maintainer of the incomparable PA-RISC resource OpenPA.net, who provided helpful insights for this article.) near my childhood hometown, RDI Computer Systems was founded in 1989 as Research, Development and Innovations Incorporated in La Costa, California, a neighbourhood of Carlsbad annexed in 1972 in northern San Diego county. (It is completely unrelated to earlier Carlsbad company RDI Video Systems, short for "Rick Dyer Industries" and the developers of laserdisc games like Dragon's Lair and Space Ace, who folded in 1985 after their expensive Halcyon home console imploded mid-development from the 1983 video game crash.) RDI, like several of its contemporaries, was established to capitalize on Sun Microsystems' attempt to commoditize SPARC and open up the market to other OEMs. While most such vendors like Solbourne Computer heavily invested in the desktop workstation segment, RDI instead went even smaller, producing what would become the first SPARC laptops in the United States. Basically SPARCstation IPC and IPX systems crammed into boxy off-white portable cases, the BriteLite series weighed a bit over 13 pounds and started at $10,000 [$24,600]. They were lauded for their performance and compatibility but not their battery life, and RDI became an early adopter of Sun's lower-power microSPARC for the sleeker, sexier PowerLites, using a more dramatic jet-black case. An 85MHz microSPARC II PowerLite 85 was the machine that computational physicist Tsutomu Shimomura, then at the San Diego Supercomputer Center, used to track down hacker Kevin Mitnick in 1995. RDI's initial success enabled its expansion into a bigger 40,000-square foot industrial park facility at 2300 Faraday Avenue, which apparently still exists today. Unfortunately for the company, however, microSPARC hit a performance wall above 125MHz and Sun abandoned further development in 1994, which RDI management took as an indication they needed to diversify. By then the RISC market had started to flourish with many architectures competing for dominance, and RDI decided to throw in with Hewlett-Packard's PA-RISC which had extant portable systems already from Hitachi and SAIC. Neither of those systems had ever existed in large numbers (and the SAIC Galaxys only in military applications at that), giving RDI a new market opportunity with a respected architecture that was already mobile-capable. Producing a final PowerLite in 1996 with the 170MHz Fujitsu TurboSPARC, RDI expanded the PowerLite case substantially for their next systems, replacing the trackball with a touchpad and adding an icon-based LCD status display but keeping its multiple hard disk bays and port options. In the same way the original BriteLites were SPARCstations in every other respect, the new RDI PA-RISC laptop was an otherwise standard HP Visualize B132L or B160L workstation, just inside a laptop case. in our demonstration of Hyper-G, which I've christened ruby after HP chief architect Ruby B. Lee, a key designer of the PA-RISC architecture and its first single-chip implementation. This time around, however, we'll take a closer look at ruby's hardware as a comparison point since it will inform some of the choices we'll make running the Macintosh Application Environment. So that I can save some typing, I'm going to liberally abbreviate "PrecisionBook" to "PABook" for the remainder of this article (avoiding "PBook" so we don't confuse it with PowerBooks). RDI's estimate. I haven't bothered trying to recell this one, and although the status LCD claims it's fully charged, it currently lasts maybe a minute or so which is enough to ride out a AC voltage drop and not much else. Under that is a small 15-pin connector for the optional external 3.5" floppy drive which I don't have either, and behind the other door is the external micro 50-pin SCSI-2 port. A diagram sheet shows that an IR transceiver was planned to be next to the SCSI port, but I don't see one on mine. I took some grabs of the boot process before starting the operating system using a different video mode that my Inogeni VGA capture box would tolerate (my Hall scan converter didn't like it either), though this turned the LCD off, so we won't be bringing up the operating system in this configuration. There is no separate service processor; this all runs on the main CPU. SAIC Galaxy family, and the last and fastest-clocked of the 32-bit PA-RISC 1.1 chips (though the earlier PA-7150 and PA-7200 with their comparatively massive caches can easily beat the 132MHz part). Being effectively a hopped-up PA-7100LC, it inherits most of the characteristics of the earlier chip including a two-way superscalar design, bi-endian support, two asymmetric ALUs, a slightly gimped FPU (the "coprocessor" in the POST summary) with greater double precision latency, and MAX-1 multimedia SIMD instructions. It also incorporates the GSC bus controller on-board. Where the PA-7300LC exceeds its ancestor is in its faster clock speeds — from 132 to 180MHz versus 60 to 100MHz — on a slightly longer six-stage pipeline instead of five, and much larger 64K/64K L1 caches (versus just 1K of I-cache) that were on-die for the first time. In keeping with its "consumer" roots the PA-7300LC additionally includes an L2 cache controller like the PA-7100LC, but here as shown on-screen the PABook's L2 is a full megabyte, and up to 8MB was supported. This is particularly notable given L2 cache was rarely a feature with PA-RISC — large L1s were more typical — and it would not be seen again on a PA-RISC CPU until the PA-8800 seven years later. Other improvements include a 96-entry unified translation lookaside buffer (versus 64) and a four-entry instruction lookaside buffer (versus one) specifically for instruction addresses, which also supported prefetching. The die was fabbed by HP on a 0.5μm process with 9.2 million transistors, 8 million of which were for the L1 cache which consumed most of its 260 square millimetres. A velociraptor can famously be seen in die photos. And here the PowerBook 3400c has a run for its money. This is the point at which I get conflicted because I'm a big fan of the Power ISA, yet I have a real soft spot for PA-RISC because it was my first job out of college, so this is like trying to pick which of my "children" I like best. Although the 3400c with a 240MHz PowerPC 603e was briefly the "world's fastest laptop," at least according to Apple, on benchmarks this 160MHz PA-7300LC wins handily. The last generation 300MHz 603e got SPEC95 numbers of 7.4/6.1, while the 180MHz PA-7300LC recorded scores of 9.22/9.43, with 9.06/9.35 officially recorded for the 180MHz PABook. If we linearly adjust both figures for clock speed we get 5.92/4.88 versus 8.20/8.38, and even using the lower figures in the PABook's technical manual (7.78/7.39 at 160MHz and 6.49/6.54 at 132MHz) the PABook still triumphs. While this isn't a completely fair fight due to the 603's notoriously underpowered FPU, clock for clock the PA-7300LC could challenge both the Pentium Pro and the piledriver PowerPC 604e; the Alpha 21164 could only beat it by revving to 300MHz. And I say all this as a pro-PowerPC bigot! Processing power isn't everything, of course: the 160MHz PA-7300LC does this with a TDP of 15W, while the 300MHz 603e displaces just four to six watts, and the 240MHz part (fabbed on the same 290nm process) is on the lower end of that range. In real world terms that translated to battery life that was at least twice as long on the 3400c. The PABook normally boots from the drive bay closest to the rear (SCSI ID 0; the others are 1 and 2) and the 4GB drive as shipped is in that position, but it can also boot from an external device (SCSI ID 3 or higher) if necessary. The console path is virtually always GRAPHICS(0) for the on-board Visualize-EG and the keyboard path is likewise PS/2, but this can apply to both an external keyboard or the built-in keyboard, which is internally connected the same way. COnfiguration, with the RDI commands for RDI-specific features like mirroring the LCD, but here we'll be asking for INformation on what's installed. INTERNAL_EG_X800, is directly connected to the GSC, but most of the rear ports are connected to a "Bus Adapter." This is the HP LASI ("LAN SCSI") combo chip updated for the PA-7300LC, implementing an Intel i82C596CA 10Mbit NIC, NCR 53C710 SCSI-2 controller, a 16550 UART for RS-232, a WD16C522-compatible parallel port, PS/2 controllers, floppy drive controller and HP Harmony audio. Not enumerated here, a secondary low-speed bus from the LASI called the PHD bus connects to its 1MB flash boot memory, NVRAM and power supply controller. The LASI only supports one serial port, so a second UART is attached to a "Bus Bridge" to provide the second one. This "Bus Bridge" is Dino, a GSC-to-PCI bridge. mikec, I'd like to ask about your experiences with the hardware: please say hi in the comments or drop me a line at ckaiser at floodgap dawt com. directly on AIX — which also used the same PowerOpen ABI — through a thinner runtime layer called Macintosh Application Services (MAS) exclusively for IBM's operating system. only one Apple computer ever ran AIX. In May 1996 Apple updated MAE to version 3.0 with System 7.5.3. This release added compatibility with HP-UX 10.x and made the CPU emulation even faster, primarily through improved handling of condition codes and floating point instructions. It also touted better application compatibility and faster screen updates for users running MAE over a remote X11 session. MAE 3.0 received four point updates up to 3.0.4, badged as "Version 3.0 (Update 4)," which is the final release and the version we'll use. xwd. The installation process is with a shell script and binary installer, both running from within a CDE shell window. Apple offered a trial version so that people could test their software and unlocking the trial limitations requires a license key which you may or may not be able to find on any Archive on the Internet. I won't show the installation process here since it's not particularly interesting or customizeable, but ideally it should be installed to /opt/apple, and even though this version of MAE includes it we're not going to install AppleTalk: ./mae in /opt/apple/bin. The very first run requires us to accept the EULA; there is a specific binary for this and we'll look at it when we take the code apart a bit. /opt? Hang on and we'll get to the on-disk representation. /opt. Again, explanations presently. ruby:/home/spectre/% ls System Folder bin src uploads ruby:/home/spectre/% ls -l System\ Folder/ total 1650 drwxr-xr-x 2 spectre users 1024 Jul 23 21:23 Apple Menu Items -rw-r--r-- 1 spectre users 2846 Jul 23 21:23 Clipboard drwxr-xr-x 2 spectre users 1024 Jul 23 21:23 Control Panels drwxr-xr-x 2 spectre users 1024 Jul 23 21:23 Control Strip Modules drwxr-xr-x 3 spectre users 1024 Jul 23 21:23 Extensions -rw-r--r-- 1 spectre users 35921 Jul 23 21:23 Finder drwxr-xr-x 2 spectre users 1024 Jul 23 21:23 Fonts -rw-r--r-- 1 spectre users 152162 Jul 23 21:23 MAE Enabler -rw-rw-r-- 1 spectre users 18952 Jul 23 21:24 MacTCP DNR drwxr-xr-x 3 spectre users 1024 Jul 23 23:04 Preferences -rw-r--r-- 1 spectre users 72200 Jul 23 21:23 Scrapbook File drwxrwxr-x 2 spectre users 96 Jul 23 21:24 Shutdown Items drwxrwxr-x 2 spectre users 96 Jul 23 21:24 Startup Items -rw-r--r-- 1 spectre users 553762 Jul 23 23:59 System CODE resources) on a native HP-UX Veritas filesystem? The answer is that these files are all AppleSingle, which is to say with their resource and data forks combined, and MAE reads and writes AppleSingle on the fly. There is another interesting folder that gets created. This directory is effectively where the virtual Mac lives. It contains the contents of the virtual Mac's "PRAM" (sm.vpram) plus various databases for files and aliases. The numbered directories require specific explanation. Since each Macintosh volume is its own root, which is certainly not the case in Unix, this directory collects the virtual Mac's volumes here. These aren't symbolic links elsewhere in the filesystem; these are MIVs, or MAE Independent Volumes. They correlate with all the mount points in /etc/fstab by default but any directory can be designated as an MIV, "mounted," and then treated as a volume. We only saw two of them on the desktop because only two of them are "mounted" in /opt/apple/lib/Default_MIV_file, and only those two "volumes" have desktop databases. The home directory is obvious, but /opt was also given a mount because we're running MAE from it and there are various resources in /opt/apple/lib it will try to access. (Some of these are global resources and are treated as part of the System Folder, such as fonts, additional standard applications for the Apple menu, keymaps, locales and, of course, the license key.) These MIVs can be renamed and otherwise treated as if they were any other mounted Macintosh fixed volume. Two other hidden files are also present in this directory, .fs_cache and .fs_info, which maintain the virtual Mac's file and volume information respectively. .fs_cache in particular is very important as it is roughly the global equivalent of an HFS catalog file (and, like a real HFS catalog file, is stored on disk as a B-tree), storing similar metadata like type and creator, timestamps and so forth. This file is so important to MAE that Apple distributed a separate tool called fstool to validate and repair it, sort of like MAE's own Disk First Aid from the shell prompt. You'll have also noticed above that the desktop database in spectre and opt is made up of four files. Desktop DB and Desktop DF are present as usual for the bundle database and Finder information respectively, but there are also two more files %Desktop DB and %Desktop DF, named exactly the same except for a percent sign sigil. This is the other way that resource forks can be represented in MAE, as AppleDouble. Here, the data fork and resource fork are split, with the percent sign indicating the resource fork. Let's explore the MAE System 7.5.3 some more before we attempt to install anything. /opt as they appear in the Finder. /opt is read-only to my uid, so I can't write directly to it. If I had permissions, I could change them from the Permissions dialogue, which is MAE's equivalent of chown, chmod and chgrp all in one. You can also view the (composite) System Folder here and see that it looks pretty much like any other System Folder on any other Mac with the exception of the MAE Enabler. SoftwareFPU. Since not all 68K Macs have floating point units, applications are supposed to use Apple's SANE IEEE-754 library which computes the result in software if no FPU is available. Not all software does this, of course (the Magic Cap 1.0 simulator comes to mind), and this is particularly relevant with Power Macs because the 68K emulator only provides a virtual 68LC040. SoftwareFPU, then, is very simple conceptually: it traps F-line instructions intended for the non-existent coprocessor and turns them into SANE calls. This is slow but it means certain software is able to run that otherwise could not. The MAE SoftwareFPU, which Apple licensed from John Neil & Associates and modified for MAE 3.0, goes a bit further. This version implements a fast path where 68K floating point instructions are directly forwarded to MAE, effectively making F-line traps into hypercalls. Apple estimated this was about 50 percent faster than using regular SoftwareFPU. That said, you'll notice that SoftwareFPU is disabled, which is the default. We'll come back to this when we benchmark the emulator. In MAE 3.0, SANE was changed to directly use host FPU instructions (either SPARC or PA-RISC) for the most commonly performed floating point operations. This works for single and double precision and ran substantially faster than MAE 2.0, but it doesn't work for the 68K's 80-bit extended-precision type, where double precision operations are performed instead and converted (but with a corresponding loss of precision). The previous behaviour, where SANE is simply run under emulation, can be restored with the -sane command line option. A better solution on Power Macs is Tom Pittman's PowerFPU, which (where possible) uses PowerPC floating point instructions directly rather than SANE. All Power Macs have an FPU, so this works on all Power Macs, and is over ten times faster than SoftwareFPU. xclock or xcal. Frodo Commodore 64 emulator, which I installed in /opt. The terminal window opens, which is important to capture any standard error or output, but otherwise it runs normally outside of MAE. That makes you can use the MAE Finder as ... your desktop. You could make MAE take up the entire screen by passing /opt/apple/bin/mae the appropriate -geometry option and setting the X resource Vuewm*mae*clientDecoration to none, effectively making it rootless, and Apple fully supported and documented doing so. Now you've got a virtual Mac that will launch your native X11 applications as well. Who needs CDE when you've got this? We'll look at another standard control panel that MAE uses for a different purpose in a little while. Meantime, having made a basic survey of the emulator, it's now time to actually run software on it. A benchmark would be a good first test but to do that we need to actually put software on it. thule, my little 128MB Macintosh IIci running NetBSD and Netatalk for AppleShare. I have lots of basic software on here including useful INITs and CDEVs and essential tools like StuffIt Expander. It still runs NetBSD 1.5.2 because I had trouble getting regular AppleTalk DDP working with 1.6 and up, so it's a fun time capsule too. But we don't have AppleTalk in MAE, so how are we going to get files from it? Easy: we're going to download the files from thule with FTP and put them into my home directory while MAE is running. The Finder will see the new files and incorporate them. What about the resource forks? The fact that the files are being served by Netatalk from a non-HFS volume (i.e., BSD FFS) actually makes that easier. Netatalk natively stores anything with a resource fork as AppleDouble, depositing the resource fork itself as a separate file into a hidden directory .AppleDouble. We pull down both the data fork and the resource fork, rename the resource fork with a %, and move them both at the same time into my home directory. On the next Finder update, it sees the "whole" file and it becomes accessible. Mac and moved StuffIt Expander there. We can now work with StuffIt archives and only have to download one file, which saves having to get the resource fork separately. An alternative approach, especially if you are transferring a file directly from an HFS or HFS+ volume, is to turn it into AppleSingle first and copy that over; MAE will use the file as-is. Apple provided a tool for this in later versions of Mac OS X/macOS, though 10.4 and prior, arguably where it would have been most useful because those versions still support the Classic Environment, don't seem to have it. The best alternative there is /Developer/Tools/SplitForks, which doesn't do AppleSingle but does create separate AppleDouble data and resource fork files, so at least you can copy those. We'll get to a somewhat more automatic way of specifically handling Netatalk's AppleDouble directories a bit later. over 23 years ago and here we are. I wrote SieveAhl in Modula-2 using the unfortunately named MacMETH compiler just to be weird, rolling all the Toolbox calls by hand. It implements the Sieve of Eratosthenes and a modified version of the FPU-dependent Ahl's Simple Benchmark and issues a score relative to my Macintosh Plus which I have as a reference standard. The main advantage SieveAhl has over other benchmarks is that I wrote it intentionally to run on just about any Mac, even down to System 1.1 (tested in vMac). Here, I'm simply grabbing the StuffIt archive using Internet Explorer 5 for UNIX on the CDE side and saving it into the Mac folder. .sit files isn't too swift on other 68K systems either. We now have a Mac directory that looks like this from the Unix side: Our newly created files in the SieveAhl Folder are now AppleSingle, for example the readme file: We'll get to the rules about when MAE creates AppleSingle and AppleDouble files in a moment. Let's see the numbers we get. Byte in September 1981. It iterates over the interval 0-8190, in which 1,899 primes are expected. Creative Computing, intended originally to evaluate performance and precision differences between various microcomputer BASIC implementations. We don't care about the accuracy or randomness values his benchmark would compute (well, we don't care much), so we just compute those and throw them away. This gets 4,863% the speed of a Mac Plus, which we would expect to be roughly the same because we have no floating point hardware. Repeated runs of both tests were nearly identical. regular SoftwareFPU, not against using it at all. Additionally, MacMETH generates well-behaved code that calls SANE as it should and doesn't emit floating point instructions. How does this compare to a real 68LC040? Conveniently, we have one handy to try it out on! rintintin, my PowerBook 540c with a 33MHz 68LC040 and 12MB of RAM running Mac OS 7.6.1, and the most powerful Blackbird PowerBook sold in the United States (the later Japanese 550c is the same speed, but with a full 68040 and FPU). It was the first PowerBook with any '040 processor, stereo speakers, on-board Ethernet (via AAUI), a trackpad instead of a trackball, twin battery bays and a full-size keyboard. The PowerBook 520/520c and 540/540c came out just a couple months after the first Power Macs and Apple placed the processor onto a daughtercard as a promise that it could be eventually upgraded. As such, the "Ready for PowerPC upgrade" sticker came on these models from the factory, though this particular one is a slightly larger reproduction I printed up a few copies of so I could surreptitiously slap them on the Intel Macs at the Apple Store. Apple nevertheless greatly underestimated demand for the line, mistakenly believing people would rather wait for what eventually was the PowerBook 5300, and the Blackbirds were chronically short-stocked for months. I upgraded this particular unit with an additional 8MB of RAM (on top of the base 4MB) and a SCSI2SD, making it an almost silent unit in operation. The only flaw it has is an iffy cable connection between the display and the top case, which is unfortunately a common problem with these models. Mission: Impossible movie with Tom Cruise and Jon Voight. A regular Blackbird in the standard two-tone grey, most likely a 540c, was what Luther used to block the NOC list transmission on the TGV in the third act. any Blackbird laptop anymore by the time the movie came out, neither computer's model badge is ever visible, though you can at least see a rainbow apple on Luther's. MacLynx, the venerable text browser natively ported to the MacOS. Here we'll run beta 6. lynx.cfg to point to our local Crypto Ancienne TLS 1.3 proxy server. However, we don't have a proper text editor installed other than SimpleText. We could certainly grab BBEdit Lite from the server as well, but MAE gives us an alternative. The manual indicates that "[b]y default, MAE stores files (except text files) in AppleSingle format." Text files, however, are stored as AppleDouble. If we look at our directory listing after unStuffing MacLynx, we can see this rule has been followed: You'll notice that all the text files — the readmes, index.html, lynx.cfg and lynxrc — got separate resource forks as AppleDouble, but the main executable did not. Now, the smart ones among you will say, "But wait! The SieveAhl readme file is text, and it was AppleSingle!" That's right — except that file's text is all stored in styled text resources and there's nothing in the data fork at all. MAE seems to content-sniff files to figure out what to do with them, so BinHex files (which are valid text) will be treated as a text file and made AppleDouble, but a read-only SimpleText file with nothing in the data fork will be treated as a binary and made AppleSingle. The AppleDouble control panel allows you to always force storing files as AppleDouble with specific applications and the separately distributed asdtool will convert a Mac file between AppleSingle and AppleDouble from the shell prompt. vi or, for the mentally deranged, emacs — and the resource fork will remain undisturbed. With MacLynx thus configured for the proxy server, we can view modern HTTPS sites inside MAE no problem. move it. That almost sounds like that the MAE desktop doesn't belong to any MIV even though it is, in fact, part of the MIV for your home directory and that's where we had StuffIt Expander: Conveniently, if you open an alias to something on an MIV that's defined but not yet mounted, MAE will automount it on the desktop for you. Our next set of programs will be TattleTech 2.8 and Gestalt.Appl so we can see what's going on under the hood. There are some surprises here. _L at the end of the Device sResource Name is significant because /opt/apple/bin/macd defines six such resources: Display_Video_Apple_MAE_S, Display_Video_Apple_MAE_M, Display_Video_Apple_MAE_L, Display_Video_Apple_MAE_F, Display_Video_Apple_MAE_C1 and Display_Video_Apple_MAE_C2. These apparently correlate to specific resolutions, namely (in the order they appear) "512 x 342 (9" Macintosh)", "640 x 480 (14" Macintosh)", "832 x 624 (17" Macintosh)", "864 x 864 Resolution", "640 x 800 Resolution" and "640 x 640 Resolution". Since we're at 832x624, we get the _L (presumably small, medium, large, full and two custom?) "card." The emulated DeclROM used by these virtual cards is part of the big blob stored in /opt/apple/lib/engine, along with the Toolbox ROM and other goodies. We'll come back to this when we explore its Gestalt selectors. are defined, but neither appears to be supported. MAE naturally supports printing, but only to a "UNIX PostScript printer" (i.e., lpr) or via AppleTalk, and it does not support using the modem port for a modem or even as a serial port. deprecated it for 68K in 1996. allow the Apple Network Server to numbercrunch for connected clients. It should be possible to do something similar with MAE and have the local host do the work, but there are no local AppleTalk interfaces or headers to compile against. QuickDraw is naturally present (no GX or 3D, of course). In MAE 3.0 QuickDraw is especially important and we'll get to that when we try playing a couple rather famous games. QuickTime is also present, version 2.5, though not everything is enabled (no software MIDI synthesizer, for example). -noextensions. cith selector ("Sith"? Darth Mac?), which is unique to MAE and is conveniently set to $00000304 (i.e., major version 3, minor version 4). While I don't have MAE 1.0 here to test with, René Ros indicates in his Gestalt reports that it has a cith value of 0, though it does exist there too. I don't know what version MAE 2.0 reports but I'm sure someone is firing it up right now to find out and will post in the comments. To more easily decipher the others we'll turn to Gestalt.Appl and I'll point out the highlights. micn is not interesting for the icon (just generic Mac) but rather the string shown, which is a STR# resource indexed by the value of mach (-16395). The string is "Macintosh ApplicationEnvironment" [sic]. mmu " (note space), but this isn't a surprise for an emulator. Consequently, there is also no virtual memory support within MAE (the host is supposed to handle that). romv) is more interesting. Although a great many Old World Mac ROMs are tagged as version 1917, the particular ROM that MAE is using is from the Quadra 660AV and 840AV because we can find its checksum (5b f1 0f d1) and version (07 7d) at offset $001c0000 in /opt/apple/lib/engine. No other valid checksum and version appears anywhere else in this file, and no true Scotsman Macintosh LC would have used a ROM that recent. Thus, if you get a Gestalt ID of 19 but a ROM version of 1917, that's a pretty good indication you're running under MAE. René's list also shows a ROM version of 1917 for MAE 1.0, so MAE 2.0 almost certainly does as well. sltc insists there aren't any NuBus slots. snhw for the sound hardware, which reports a driver cith. This likewise appears nowhere else and is specific to the MAE emulated audio hardware. Oddly, although MAE 1.0 lacked sound, René's list indicates an snhw of awac which would suggest an AWACS. Let's get back to running some more apps. I'm going to bump up the emulated RAM now because a couple near the end will likely benefit. still sold! — was a bit of a mixed bag on MAE. 2.1.2 was the 68K version I had on thule, so I tried that first. It starts and runs fine, but when I actually tried to download anything with this version of Fetch it locked up the entire emulated Mac as soon the file was transferred. That said, I'm not sure if this is a fault of MAE or Fetch because at the exact same point of the exact same file with the exact same version of Fetch on the 540c, it abruptly dropped the connection and threw an error message — though I note transfer speeds were faster on MAE, probably because of the better hardware, right up until it hit the wall. Fortunately the later Fetch 3.0.1 behaves correctly and Apple even offered that specific version for download from the MAE website. There are specific advantages to using Fetch in MAE because of its transparent support for AppleSingle transfers. Still, grabbing files with MacLynx works fine too (hurray for eating your own dogfood), so I'll mostly use that. ssheven, which works great on my real Macs, crashes on MAE and I'm not sure why. ssheven, though I'd have to get a better debugger up on it to figure it out. ssh, and that would even be more useful. Instead, we should try something really important next. Apple IIgs versions are derived from the Mac version. This port was released in 1994 and the "Accelerated for Power Macintosh" and "System 7 Savvy" stickers give the rough timeframe. It requires a 25MHz 68030 or better and is a fat binary. Given that the PABook doesn't have a floppy drive, I copied over this version by simply Stuffing the installed folder on my Power Macintosh 7300 and downloading it over shell FTP (NCSA Telnet on the Mac contains a very basic FTP server which is handy for this). Wolfenzoom (Gopher link) that will scale-blit the 320x200 to 640x400, and I used to use it on my unaccelerated desktop Macintosh IIci when I first bought this game. However, since I'm all about pushing my luck, let's try the highest resolution. unchecked, the game will try to draw directly to video memory. This doesn't always work, and as you can see in this screenshot, not all of the screen was updating properly in this mode. This observation will become relevant when we try running our next game. You do see where this is going, don't you? does use QuickDraw, and appears correctly, but ... thule, but copying Word 5.1 over was a much bigger situation than simply grabbing a single file and its resource fork; we had a number of double-forked files we needed to move en masse. This Perl script, which works on both Perl 5 and 4.036, will iterate over a copy and move Netatalk's AppleDouble resource files into the proper location for MAE, resolving ambiguities in filenames if needed. Call it with find [directory] -name '.AppleDouble' -print | perl ad2mae to run. Only run this on a copy! When everything was in the right place, I moved the directory into my Mac folder and it was ready to go. ad2mae from the MAE Finder, the Finder determined it was a text file and opened it up in vi in a CDE window ready for editing. Not bad! As MAE 3.0 specifically advertised that it was faster than previous versions over remote X, let's test how well that works from my POWER9 Raptor Talos II in Fedora 42. Being the Wayland refusenik I am, I still run KDE Plasma in X11, so with xhost set appropriately and AllowByteSwappedClients enabled (because the POWER9 is running Power ISA little-endian and the PABook is running big) we should be able to connect: actual Command and Option keys, though (I use a white A1048 USB Apple Keyboard with the Quad G5 and the Talos II). makes it tick. DLOG modal when MAE is formatting the TIV. DLOGs for the MAE Toolbar help we saw earlier. DLOG is one of the modals for the floppy/CD mounter. DITL looks like it's part of a credits easter egg, though I haven't figured out yet how to trigger it. I'm assuming the dog is named Rosco ("In Memory of Rosco - 10/5/96"). Also note the dog's Dr Seuss hat, a callback to MAE's "Cat-in-the-Hat" codename. Here's the MAE 3.0 development team: Peter Blas, Michael Brenner, Matthew Caprile, Mary Chan, Bill Convis, Jerry Cottingham, Ivan Drucker, Gerri Eaton, Tim Gilman, Gary Giusti, Mark Gorlinsky, John Grabowski, Cindi Hollister, Richard W. Johnson, John Kullmann, Tom Molnar, John Morley, Stephen Nelson, Michael Press, Jeff Roberts, Shinji Sato, Marc Sinykin, Earl Wallace, Gayle Wiesner. This list of credits will show up again later. PICTs. I'm not sure what they refer to. Notice that the Toolbar Menu when you use the third mouse button is actually just a bunch of PICT resources. There are some other interesting things of note when we start going through the binaries. I separately extracted the files from the installer packages (they're just cpio archives) to preserve their time stamps for analysis. Let's look at everything that's there and then dig into the most notable individual files. All of the core binaries have a modification date of January 23, 1997, presumably the RTM date. Of the library files, data and engine are probably the most notable. We will look at those seprately. KeymapDepotDB is where the default keymaps MAE uses are kept, and MajorUpdate is instructions to the installer script for how to perform an upgrade to a new major release. Since there's no MAE 4.0, this presumably will never be used again. The manual does not document what btree does, and it has only a single readable string in it: Copyright 1991 Apple Computer, Inc. All Rights Reserved. Ricardo Batista The rest are character set mappings and the EULAs in graphic form for both the MAE demo and the full version (with X bitmap buttons for accept/don't accept in all languages except English): After installation Default_MIV_file also lives in /opt/apple/lib, and optionally AliasList for default aliases to appear when starting MAE. To reduce the size of individual users' System Folders, a substantial portion of the composite MAE System Folder is pulled from the shared directory, and other pieces from /opt/apple/lib/data. /opt/apple/lib/data contains the rest of the System Folder, with common pieces like the System 7.5 jigsaw puzzle (licensed by Apple from Captain's Software), note pad (Light Software), scrapbook, menu bar clock (from Steve Christensen's SuperClock!), desktop patterns, compressed System resources and standard INITs and CDEVs. /opt/apple/sys, however, which we won't do much more with here, is the master template for creating each user's own System Folder. We don't need to look at it again because we already saw my own copy of it. /opt/apple/lib/engine is a mashup of many miscellaneous tools. There are various conglomated binaries in it ratted out by the presence of .text, .data and .bss, plus the fake DeclROM for the virtual video card and the Quadra 660AV/840AV Toolbox ROM it uses. There are also many other interesting strings, and being a 10MB file, there are a lot of them: /dev/null 2>&1 Move failed: (%d) [...] cGetDevPixmap, could not emulate Macintosh color table (%d), exiting. cGetDevPixmap, unknown depth %d in encountered. doVideo, error installing video driver, exiting. doVideo, error initializing NewGDevice, exiting. doVideo, could not emulate any Macintosh video devices. Insufficient shared memory or swap space. Using malloc instead. Performance could be increased by adding more swap space and/or configuring more shared memory into the kernel. ERROR: MAE could not allocate the video screen (%dx%d, %dk). Please increase swap space or kill other processes before restarting MAE. Could not malloc new screen buffer, restoring previous size. Not enough shared memory, using malloc instead. Performance would be increased by configuring more shared memory into the kernel. [...] BUGS on MacPlus/SE, NuMc on later [...] Got the OKAY to clear %s (0x%02x bytes at pram 0x%02x) - [...] QDtoGC: (penMode & kHilitePenModeMask); *punting* QDtoGC: penmode=invert (but not well matched); *punting* [...] Aae: AAAAARGH! Fatal X Error [...] Copyright (c) 1987 Apple Computer, Inc., 1985 Adobe Systems Incorporated, 1983-87 AT&T-IS, 1985-87 Motorola Inc., 1980-87 Sun Microsystems Inc., 1980-87 The Regents of the University of California, 1985-87 Unisoft Corporation, All Rights Reserved. [...] 36 41 2 1 c #FFFFFFFFFFFF . c #000000000000 ... .... ..... ..... ..... ..... .... .. ...... ...... .......... .......... ....................... ......................... ....................... ....................... ....................... ...................... ...................... ...................... ...................... ....................... ...................... ....................... ......................... ....................... ....................... ..................... .................... ................... ........ ........ .... .... 36 41 9 1 c #FFFFFFFFFFFF c #0000BBBB0000 c #FFFFFFFF0000 c #FFFF66663333 c #FFFF64640202 c #DDDD00000000 c #999900006666 c #999900009999 c #00000000DDDD ... .... ..... ..... ..... ..... .... .. ...... ...... .......... .......... ....................... ........................ XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX oOOOOOOOOOOOOOOOOooooo oOOOOOOOOOOOOOOOOOOOOo oOOOOOOOOOOOOOOOOOOOOo oOOOOOOOOOOOOOOOOOOOOOo +++++++++++++++++++++++ ++++++++++++++++++++++ +++++++++++++++++++++++ ++@+@+@+@+@+@+@+@+@+@+@+ @@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@# $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$ $$$$$$$$ $$$$$$$ $$$$ $$$$ # CREATOR: MAE 3.0 %d %d %3d %3d %3d GIF87a $Id: ximage_high.c,v 3.6 1996/09/11 08:19:50 johng Exp $ $Id: ximage_icon.c,v 3.0 1995/03/23 20:51:23 cvs Exp $ X36 41 2 1 c #FFFFFFFFFFFF . c #000000000000 ... .... ..... ..... ..... ..... .... .. ...... ...... .......... .......... ....................... ......................... ....................... ....................... ....................... ...................... ...................... ...................... ...................... ....................... ...................... ....................... ......................... ....................... ....................... ..................... .................... ................... ........ ........ .... .... 36 41 9 1 c #FFFFFFFFFFFF c #0000BBBB0000 c #FFFFFFFF0000 c #FFFF66663333 c #FFFF64640202 c #DDDD00000000 c #999900006666 c #999900009999 c #00000000DDDD ... .... ..... ..... ..... ..... .... .. ...... ...... .......... .......... ....................... ........................ XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX oOOOOOOOOOOOOOOOOooooo oOOOOOOOOOOOOOOOOOOOOo oOOOOOOOOOOOOOOOOOOOOo oOOOOOOOOOOOOOOOOOOOOOo +++++++++++++++++++++++ ++++++++++++++++++++++ +++++++++++++++++++++++ ++@+@+@+@+@+@+@+@+@+@+@+ @@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@# $$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$ $$$$$$$$ $$$$$$$ $$$$ $$$$ PaintIconIntoImage, unknown message type %d. %d %d %d Unable to get Icon window id from MACD, exiting. The SuperROM SuperTeam: Central: Ricardo Batista, Rich Biasi, Philip Nguyen, Roger Mann Kurt Clark, Chas Spillar, Paul Wolf, Clinton Bauder Giovanni Agnoli and Debbie Lockett RISC: Scott Boyd, Tim Nichols and Steve Smith MSAD: Jeff Miller and Fred Monroe Cyclone: Tony Leung, Greg Schroeder, Mark Law, Fernando Urbina Dan Hitchens, Jeff Boone, Craig Prouse, Eric Behnke Mike Bell, Mike Puckett, William Sheet, Robert Polic and Kevin Williams Thankzzz to all who contributed to past ROMs...and System 7.x legal, which is the program that requires you to accept the EULA on first run. legal in particular looks like it's just an embedded Tcl/Tk script. It's also notable that appleping, appletalk, atlookup, asdtool and legal still have symbol tables. The AppleTalk tools in particular list functions related to DDP, LAP, NBP and RTMP, but you'd expect that (legal has symbols for Tcl/Tk instead). Interestingly, a few of the strings in appletalk suggest that LocalTalk might have been, or at least was considered for being, supported at one time. Although mae is the binary that you run directly, macd is what handles a lot of the background stuff and mae communicates with it over IPC. The administrator's manual is (probably intentionally) vague about its exact functions, saying only that it "is a daemon that runs whenever apple/bin/mae runs and helps MAE interact with the UNIX environment. It also cleans up after mae if the mae process is killed." We can get a little better idea of what it does from its own set of strings at least: And now mae itself. Some of these strings and components are duplicative of what we saw in /opt/apple/lib/engine. I'm not sure why they're being used twice. Then we start getting into an unusual section. ] [-o >outfile>] [-step] [-remote_debug] decimalinetport hexinetaddr <A/UX COFF file> [<arg1>] ... [<argn>] emulator: cannot uname(2) local system errno = %d TBATDEBUG SOFTMAC_RESTARTING_NOW TBWARN Midnight Emulator version %s Remote Debug version built %s at %s, loading %s [...] Midnight Debugger Unless otherwise specified, the following rules apply: - Commands are single-letter and case matters a whole lot! - Whitespace between the command and arguments are allowed. - Values are hex by default. - Addresses are automatically forced to be on even address boundaries. - '<68kaddr>' is an address which will be offsetted automatically by the emulator so it lies within the 68k image. For example, on this HP system a <68kaddr> of 0x4600 is a real address of 0x%x. - '<emuaddr>' is an address which is not mucked with in any manner. It can be any address within the emulator address space. [...] HUGGERZ What About Bob? ___ ____ ___ ____( \ .-' `-. / )____ (____ \_____ / (O O) \ _____/ ____) (____ `-----( ) )-----' ____) (____ _____________\ .____. /_____________ ____) (______/ `-.____.-' \______) *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug**Hug**Hug* *Hug* *Hug* *Hug* *Hug**Hug**Hug* *Hug* *Hug* *Hug* *Hug**Hug* *Hug* *T3W* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* *Hug* Here goes a big hug from the MAE Team!!!!! [...] mae binary has a second executable binary in it, called the Midnight Emulator. And we can run it! ] [-o >outfile>] [-step] [-remote_debug] decimalinetport hexinetaddr <A/UX COFF file> [<arg1>] ... [<argn>] ruby:/opt/apple/bin/% ./midnight -h Midnight Emulator version 12:02:00 Remote Debug version built Mar 25 1997 at 10:26:25, loading -h must set LM_LICENSE_FILE env var for midnight ruby:/opt/apple/bin/% setenv LM_LICENSE_FILE /opt/apple/XXXXXXX ruby:/opt/apple/bin/% ./midnight -h Midnight Emulator version 12:02:00 Remote Debug version built Mar 25 1997 at 10:26:25, loading -h Unable to open file -h spindler, my clock-chipped Quadra 800. We'll fire it up in A/UX 3.1. spindler:/bin/% uname -a A/UX spindler 3.1 SVR2 mc68040 spindler:/bin/% file sync sync: COFF object paged executable spindler:/bin/% ls -l sync -rwxr-xr-x 1 bin bin 764 Feb 4 1994 sync spindler:/bin/% dis sync **** DISASSEMBLER **** disassembly for sync section .text $ a8: 23c0 0040 0150 mov.l %d0,0x400150.l $ ae: 518f subq.l &8,%sp $ b0: 2eaf 0008 mov.l 0x8(%sp),(%sp) $ b4: 41ef 000c lea 0xc(%sp),%a0 [...] $ 144: 480e ffff fffc link.l %fp,&-4 $ 14a: 4e71 nop $ 14c: 4e5e unlk %fp $ 14e: 4e75 rts /bin/sync looks like a very small, yet valid A/UX binary we can pull over and see if Midnight will run it. First, a quick negative control by running it on itself: The complaint that it's neither COFF nor engine suggests that its normal state is to be running /opt/apple/lib/engine, though this isn't too interesting, since we would assume MAE does that ordinarily. Regardless, it doesn't like our real A/UX COFF binary, even though it does try to load it. It is particularly strange that mae has a modification date of January 23, 1997, but the Midnight Emulator claims to have been built on March 25, over two months later. More explorations to come, especially into whether this could help to debug MAE itself. At the end of this extensive strange trip, I found I rather liked the way MAE worked, and the integration features with HP-UX in particular really tempt me to try running it as my primary environment on top of CDE or VUE. Its performance was surprisingly good and I think if I had the choice back in the day between buying new a 3400c or this thing, even as noisy, heavy and costly as it is, I might strongly have considered buying the latter. Also, I bet MAE would run like a bat out of hell on my maximally configured C8000 and some additional explorations of the Macintosh Application Environment, possibly also on one of my SAIC Galaxys with a floppy drive and an earlier version of HP-UX, might be the subject of a future article. The MAE team clearly didn't think 3.0 was the end of MAE; in the MAE 3.0 white paper's "Future Directions" they indicate that support for additional hardware platforms and "additional UNIX systems" are "being considered." They acknowledge the fact it doesn't run Power Mac software, even saying that "Apple is also investigating the viability of supporting PowerPC Macintosh applications on MAE." However, the document also adds that "Apple wants to ensure that the performance of RISC-on-RISC emulation will meet customer requirements before committing to this development effort." It's not clear if any work on this was ever done. In the wake of Apple's purchase of NeXT in 1997 there was a mention in Informationweek that MAE would be ported to NeXTSTEP as a solution for legacy applications, but this would have been a limiting choice because of the existing PowerPC software that people wanted to run and I don't think it was ever a truly serious proposal. Although I couldn't find anything obvious in the trade rags about exactly when MAE was cancelled, I suspect Gil Amelio did it at Steve Jobs' suggestion after the buyout, like what happened with the Apple Network Server and OpenDoc. After all, MAE had just become superfluous after Apple adopted Rhapsody as the future Mac OS: now that Apple had its own Unix, there was no reason to support anyone else's. Nevertheless, although the Classic Environment in PowerPC versions of Rhapsody and Mac OS X (nicknamed the "Blue Box") is not a direct descendant of MAE, it's very possible that MAE informed its design. In practice, Classic is actually closer to MAS in concept in that it runs native PowerPC code directly in the so-called "problem state" on a paravirtualized Mac OS 8 or 9, using the standard ROM 68K emulator for 68K applications. Classic is less flexible than MAE in that only one instance can be running on any one Power Mac and only one user can be running it, but it was never going to be the future anyway.

totally unreasonable price for a completely untested item, as-was, no returns, with no power supply, no wiring harness and no auxiliary daughterboards. At the end of this article, we'll have it fully playable and wired up to a standard ATX power supply, a composite monitor and off-the-shelf Atari joysticks, and because this board was used for other related games from that era, the process should work with only minor changes on other contemporary Gremlin arcade classics like Blockade, Hustle and Comotion [sic]. It's time for a Refurb Weekend. a July 1982 San Diego Reader article, the locally famous alternative paper I always snitched a copy of when I was downtown, and of which I found a marginally better copy to make these scans. There's also an exceptional multipart history of Gremlin you can read but for now we'll just hit the highlights as they pertain to today's project. ported to V1 Unix and has a simpler three-digit variant Bagels which was even ported to the KIM-1. Unfortunately his friends didn't have minicomputers of their own, so Hauck painstakingly put together a complete re-creation from discrete logic so they could play too, later licensed to Milton Bradley as their COMP IV handheld. Hauck had also been experimenting with processor-controlled video games, developing a simple homebrew unit based around the then-new Intel 8080 CPU that could connect to his television set and play blackjack. Fogleman met Hauck by chance at a component vendor's office and hired him on to enhance the wall game line, but Hauck persisted in his experiments, and additionally presented Fogleman with a new and different machine: a two-player game played with buttons on a video TV display, where each player left a boxy solid trail in an attempt to crowd out the other. To run the fast action on its relatively slow ~2MHz CPU and small amount of RAM, a character generator circuit made from logic chips painted a 256x224 display from 32 8x8 tiles in ROM specified by a 32x28 screen matrix, allowing for more sophisticated shapes and relieving the processor of having to draw the screen itself. (Does this sound like an early 8-bit computer? Hold that thought.) patent application was too late and too slow to stop the ripoffs. (For the record, Atari programmer Dennis Koble was adamant he didn't steal the idea from Gremlin, saying he had seen similar "snake" games on CompuServe and ARPANET, but Nolan Bushnell nevertheless later offered Gremlin $100,000 in "consolation" which the company refused.) Meanwhile, Blockade orders evaporated and Gremlin's attempts to ramp up production couldn't save it, leaving the company with thousands of unused circuit boards, game cabinets and video monitors. While lawsuits against the copycats slowly lumbered forward, Hauck decided to reprogram the existing Blockade hardware to play new games, starting with converting the Comotion board into Hustle in 1977 where players could also nab targets for additional points. The company ensured they had a thousand units ready to ship before even announcing it and sales were enough to recoup at least some of the lost investment. Hauck subsequently created a reworked version of the board with the same CPU for the more advanced game Depthcharge, initially testing poorly with players until the controls were simplified. This game was licensed to Taito as Sub Hunter and the board reworked again for the target shooter Safari, also in 1977, and also licensed by Taito. For 1978, Gremlin made one last release using the Hustle-Comotion board. This game was Blasto. present world record is 8,730), but in two player mode the players can also shoot each other for an even bigger point award. This means two-player games rapidly turn into active hunts, with a smaller bonus awarded to a player as well if the other gets nailed by a mine. shown above with a screenshot of the interactive on-board assembler. Noval also produced an education-targeted system called the Telemath, based on the 760 hardware, which was briefly deployed in a few San Diego Unified elementary schools. Alas, they were long gone before we arrived. Industry observers were impressed by the specs and baffled by the desk. Although the base price of $2995 [about $16,300] was quite reasonable considering its capabilities, you couldn't buy it without its hulking enclosure, which made it a home computer only to the sort of people who would buy a home PDP-8. (Raises hand.) Later upgrades with a Z80 and a full 32K didn't make it any more attractive to buyers and Noval barely sold about a dozen. Some of the rest remained at Gremlin as development systems (since they practically were already), and an intact upgraded unit with aftermarket floppy drives lives at the Computer History Museum. The failure of Noval didn't kill Gremlin outright, but Fogleman was concerned the company lacked sufficient capital to compete more strongly in the rapidly expanding video game market, and Noval didn't provide it. With wall game sales fading fast and cash flow crunched, the company was slowly approaching bankruptcy by the time Blasto hit arcades. At the same time, Sega Enterprises, Inc., then owned by conglomerate Gulf + Western (who also then owned Paramount Pictures), was looking for a quick way to revive its failing North American division which was only surviving on the strength of its aggressively promoted mall arcades. Sega needed development resources to bring out new games States-side, and Gremlin needed money. In September 1978 Fogleman agreed to make Gremlin a Sega subsidiary in return for an undisclosed number of shares, and became a vice chairman. Sega was willing to do just about anything to achieve supremacy on this side of the Pacific. In addition to infusing cash into Gremlin to make new games (as Gremlin/Sega) and distribute others from their Japanese peers and partners (as Sega/Gremlin), Sega also perceived a market opportunity in licensing arcade ports to the growing home computer segment. Texas Instruments' 99/4 had just hit the market in 1979 to howls there was hardly any software, and their close partner Milton Bradley was looking for marketable concepts for cartridge games. Blasto had simple fast action and a good name in the arcades, required only character graphics (well within the 9918 video chip's capabilities) and worked for both one or two players, and Sega had no problem blessing a home port of an older property for cheap. Milton Bradley picked up the license to Hustle as well. Bob Harris for completion, and TI house programmer Kevin Kenney wrote some additional features. 1 to 40 (obviously some thought was given to using the same PCB as much as possible). The power header is also a 10-pin block and the audio and video headers are 4-pin. Oddly, the manual doesn't say anywhere what the measurements are, so I checked them with calipers and got a pitch of around 0.15", which sounds very much like a common 0.156" header. I ordered a small pack of those as an experiment. 0002 because of the control changes: if you have an 814-0001, then you have a prototype. The MAME driver makes reference to an Amutech Mine Sweeper which is a direct and compatible ripoff of this board — despite the game type, it's not based on Depthcharge.) listed with the part numbers for the cocktail, but the ROM contents expected in the hashes actually correspond to the upright. Bipolar ROMs and PROMs are, as the name suggests, built with NPN bipolar junction transistors instead of today's far more common MOSFETs ("MOS transistors"). This makes them lower density but also faster: these particular bipolar PROMs have access times of 55-60ns as opposed to EPROMs or flash ROMs of similar capacity which may be multiple times slower depending on the chip and process. For many applications this doesn't matter much, but in some tightly-timed systems the speed difference can make it difficult to replace bipolar PROMs with more convenient EPROMs, and most modern-day chip programmers can't generate the higher voltage needed to program them (you're basically blowing a whole bunch of microscopic Nichrome metal fuses). Although modern CMOS PROMs are available at comparable speeds, bipolars were once very common, including in military environments where they could be manufactured to tolerate unusually harsh operating conditions. The incomparable Ken Shirriff has a die photo and article on the MMI 5300, an open-collector chip which is one of the military-spec parts from this line. Model 745 KSR and bubble memory Model 763 ASR, use AMD 8080s! The Intel 8080A is a refined version of the original Intel 8080 that works properly with more standard TTL devices (the original could only handle low-power TTL); the "NL" tag is TI's designation for a plastic regular-duty DIP. Its clock source is a 20.79MHz crystal at Y1 which is divided down by ten to yield the nominal clock rate of 2.079MHz, slightly above its maximum rating of 2MHz but stable enough at that speed. The later Intel 8080A-1 could be clocked up to 3.125MHz and of course the successor Intel 8085 and Zilog Z80 processors could run faster still. An interesting absence on this board is an Intel 8224 or equivalent to generate the 8080A's two-phase clock: that's done directly off the crystal oscillator with discrete logic, an elegant (and likely cheaper) design by Hauck. The video output also uses the same crystal. Next to the CPU are pads for the RAM chips. You saw six of them in the last picture under the second character ROM (316-0100M), all 2102 (1Kbit) static RAM. These were the chips I was most expecting to fail, having seen bad SRAM in other systems like my KIM-1. The ones here are 450ns Fairchild 21021 SRAMs in the 21021PC plastic case and "commercial" temperature range, and six of them adds up to 768 bytes of memory. NOS examples and equivalents are fortunately not difficult to find. Closer to the CPU in this picture, however, are two more RAM chip pads that are empty except for tiny factory-installed jumpers. On the Hustle and Blasto boards (both), they remain otherwise unpopulated, and there is an additional jumper between E4 and E5 also visible in the last picture. The Comotion board, however, has an additional 256 bytes of RAM here (as two more 1024x1 SRAMs). On that board these pads have RAM, there are no jumpers on the pads, and the jumper is now between E3 (ground) and E5. This jumper is also on Blockade, even though it has only five 2102s and three dummy jumpers on the other pads. That said, the games don't seem to care how much RAM is present as long as the minimum is: the current MAME driver gives all of them the full 1K. this 8080 system which uses a regulator). Tracing the schematic out further, the -12V line is also used with the +5V and +12V lines to run the video circuit. These are all part of the 10-pin power header. almost this exact sequence of voltages? An AT power supply connector! If we're clever about how we put the two halves on, we can get nearly the right lines in the right places. The six-pin AT P9 connector reversed is +5V, +5V, +5V, -5V, ground, ground, so we can cut the -5V to be the key. The six-pin AT P8 connector not reversed is power-good, +5V (or NC), +12V, -12V, ground, ground, so we cut the +5V to be the key, and cut the power-good line and one of the dangling grounds and wire ground to the power-good pin. Fortunately I had a couple spare AT-to-ATX converter cables from when we redid the AT power supply on the Alpha Micro Eagle 300. connectors since we're going to modify them anyway. A quick couple drops of light-cured cyanoacrylate into the key hole ... Something's alive! An LED glows! Time now for the video connector to see if we can get a picture! a nice 6502 reset circuit). The board does have its own reset circuit, of a sort. You'll notice here that the coin start is wired to the same line, and the manual even makes reference to this ("The circuitry in this game has been arranged so that the insertion of a quarter through the coin mechanism will reset the restart [sic] in the system. This clears up temporary problems caused by power line disturbances, static, etc."). We'll of course be dealing with the coin mechanism a little later, but that doesn't solve the problem of bringing the machine into the attract mode when powered on. I also have doubts that people would have blithely put coins into a machine that was obviously on the fritz. pair is up and down, or left and right, but not which one is exactly which because that depends on the joystick construction. We'll come back to this. Enterprises) to emphasize the brand name more strongly. The company entered a rapid decline with the video game crash of 1983 and the manufacturing assets were sold to Bally Midway with certain publishing rights, but the original Gremlin IP and game development teams stayed with Sega Electronics and remained part of Gulf+Western until they were disbanded. The brand is still retained as part of CBS Media Ventures today though modern Paramount Global doesn't currently use the label for its original purpose. In 1987 the old wall game line was briefly reincarnated under license, also called Gremlin Industries and with some former Gremlin employees, but only released a small number of new machines before folding. Meanwhile, Sega Enterprises separated from Gulf+Western in a 1984 management buyout by original founder David Rosen, Japanese executive Hayao Nakayama and their backers. This Sega is what people consider Sega today, now part of Sega Sammy Holdings, and the rights to the original Gremlin games — including Blasto — are under it. Lane Hauck's last recorded game at Gremlin/Sega was the classic Carnival in 1980 (I played this first on the Intellivision). After leaving the company, he held positions at various companies including San Diego-based projector manufacturer Proxima (notoriously later merging with InFocus), Cypress Semiconductor and its AgigA Tech subsidiary (both now part of Infineon), and Maxim Integrated Products (now part of Analog Devices), and works as a consultant today. I'm not done with Blasto. While I still enjoy playing the TI-99/4A port, there are ... improvements to be made, particularly the fact it's single fire, and it was never ported to anything else. I have ideas, I've been working on it off and on for a year or so and all the main gameplay code is written, so I just have to finish the graphics and music. You'll get to play it. And the arcade board? Well, we have a working game and a working harness that I can build off. I need a better sound amplifier, the "boom" circuit deserves a proper subwoofer, and I should fake up a little circuit using the power-good line from the ATX power supply to substitute for the power interrupt board. Most of all, though, we really need to get it a proper display and cabinet. That's naturally going to need a budget rather larger than my typical projects and I'm already saving up for it. Suggestions for a nice upright cab with display, buttons and joysticks that I can rewire — and afford! — are solicited. On both those counts, to be continued.

Bona fides: Commodore 128DCR on my desk with a second 1571, Ultimate II+-L and a ZoomFloppy, three SX-64s I use for various projects, heaps of spare 128DCRs, breadbox 64s, 16s, Plus/4s and VIC-20s on standby, multiple Commodore collectables (blue-label PET 2001, C64GS, 116, TV Games, 1551, 1570), a couple A500s, an A3000 and a AmigaOS 3.9 QuikPak A4000T with '060 CPU, Picasso IV RTG card and Ethernet. I wrote for COMPUTE!'s Gazette (during the General Media years) and Loadstar. Here's me with Jack Tramiel and his son Leonard from a Computer History Museum event in 2007. It's on my wall. Retro Recipes video (not affiliated) stating that, in answer to a request for a very broad license to distribute under the Commodore name, Commodore Corporation BV instead simply proposed he buy them out, which would obviously transfer the trademark to him outright. Amiga News has a very nice summary. There was a time when Commodore intellectual property and the Commodore brand had substantial value, and that time probably ended around the mid-2000s. Prior to that point after Commodore went bankrupt in 1994, a lot of residual affection for the Amiga and the 64/128 still circulated, the AmigaOS still had viability for some applications and there might have been something to learn from the hardware, particularly the odder corners like the PA-RISC Hombre. That's why there was so much turmoil over the corpse, from Escom's abortive buyout to the split of the assets. Today the Commodore name (after many shifts and purchases and reorgs) is presently held by Commodore Corporation BV, a Netherlands company, who licenses it out. Pretty much the rest of it is split into the hardware patents (now with Acer after their buyout of Gateway 2000) and the remaining IP (Amiga Corporation, effectively Cloanto). The Commodore brand after the company's demise has had an exceptionally poor track record in the market. Many of us remember the 1999 Commodore 64 Web.it, licensed by Escom, which was a disastrously bad set-top 486 PC sold as an "Internet computer" whose only link to CBM was the Commodore name and a built-in 64 emulator. Reviewers savaged it and they've become collectors' items purely for the lulz. In 2007, Tulip licensee Commodore Gaming tried again with PC gaming rigs sold as the Commodore XX, GS, GX and G (are these computers or MPAA ratings?) and special wraps called C=kins (say it "skins"). I went to the launch party in L.A. — 8-Bit Weapon was there, hi Seth and Michelle! — and I even have one of their T-shirts around someplace. The company subsequently ran out of money and their most consequential legacy was the huge and heavily branded case. More recently, in 2010, another American company called itself Commodore USA LLC and tried developing new keyboard computers, most notably the (first) Commodore 64x. These were otherwise underpowered PCs using mini-ATX motherboards in breadboard-like cases where cooling was an obvious issue. They also tried selling "VICs" (which didn't look like VIC-20s) and "Amigas" (which were Intel i7 systems), and introduced their own Linux-based Commodore OS. Opinions were harsh and the company went under after its CEO died in 2012. Dishonourable mentions include Tulip-Yeahronimo's 2004 MP3 player line, sold as the (inexplicably) e-VIC, m-PET and f-PET, and the PET smartphone, a 2015 otherwise unremarkable Android device with its own collection of on-board emulators. No points for guessing how much of an impact those made. And none of this is really specific to Commodore, either: look at the shambling corpse of Atari SA, made to dance on decaying strings by the former Infogrames' principals. I mean, cryptocurrency and hotels straight out of Blade Runner — really? The exception to the rule was the 2004 C64DTV, a Tulip-licensed all-in-one direct-to-TV console containing a miniaturized and enhanced Commodore 64 designed by Jeri Ellsworth in a Competition Pro-style joystick. It played many built-in games from flash storage but more importantly could be easily modded into a distinct Commodore computer of its own, complete with keyboard and IEC serial ports, and VICE even emulates it. It sold well enough to go through two additional hardware revisions and the system turned up in other contemporary DTVs (like the DTV3 in the Hummer DTV game). There are also the 2019 "TheC64" machines, in both mini and full-size varieties (not affiliated), which are pretty much modern direct-to-TV systems in breadbin cases that run built-in games under emulation. The inclusion of USB "Comp Pro" styled joysticks is an obvious secondary homage to the C64DTV. Notably, Retro Games Ltd licensed the Commodore 64 ROMs from Cloanto but didn't license the Commodore trademark, so the name Commodore never appears anywhere on the box or the machine (though you decide if the trade dress is infringing). The remnant of the 64x was its case moulds, which were bought by My Retro Computer Ltd in the UK after Commodore USA LLC went under and that's where this story picks up, selling an officially licened new version of the 64x (also not affiliated) after Commodore Corporation BV granted permission in 2022. This new 64x comes in three pre-built configurations or as a bare case. By buying out the Commodore name they would get to sell these without the (frankly exorbitant) fees CC BV was charging and extend the brand to other existing Commodore re-creations like the Mega 65, but the video also has more nebulous aims, such as other retro Commodore products (Jeri Ellsworth herself appears in this video) or something I didn't quite follow about a Commodore charity arcade for children's hospitals, or other very enthusiastically expressed yet moderately unclear goals. I've been careful not to say there's no point in buying the Commodore trademark — I said there's not much. There is clearly a market for reimplementing classic Commodore hardware; Ellsworth herself proved it with the C64DTV, and current devices like the (also not affiliated with any) Mega 65, Ultimate64 and Kawari VIC-II still sell. But outside of the retro niche, Commodore as a brand name is pretty damn dead. Retro items sell only small numbers in boutique markets. Commodore PCs and Commodore smartphones don't sell because the Commodore name adds nothing now to a PC or handset, and the way we work with modern machines — for better or worse — is worlds different than how we worked with a 1982 home computer. No one expects to interact with, say, a Web page or a smartphone app in the same way we used a BASIC program or a 5.25" floppy. Maybe we should, but we don't. Furthermore, there's also the very pertinent question of how to steward such a community resource. The effort is clearly earnest, genuine and heartfelt, but that's not enough without governance. Letting these obviously hobbyist projects become full-fledged members of the extended Commodore family seems reasonable and even appropriate, but then there's the issue of preventing the Shenzhen back alley cloners from ripping them (and you) off. Plus, even these small products do make some money. What's FRAND in a situation like this? How would you enforce it? Should you enforce it? Does everyone who chips in get some fraction of a vote or some piece of the action? If the idea is only to allow the Commodore name to be applied to projects of sufficient quality and/or community benefit, who decides? Better to let it rest in peace and stop encouraging these bloodsuckers to drain what life and goodwill remain in the Commodore name. The crap products that came before only benefited the licensor and just make the brand more tawdry. CC BV only gets to do what it does because it's allowed to. TheC64 systems sold without the Commodore trademark because it was obvious what they were and what they do; Mega 65s and Ultimate64s are in the same boat. Commodore enthusiasts like me know what these systems are. We'll buy them on their merits, or not, whether the Commodore name is on the label, or not (and they will likely be cheaper if they don't). CC BV reportedly has been trying to sell off the trademark for awhile, which seems to hint that they too recognize the futility. Don't fall into their trap.