For work this week I have focused on adding content to the catalog and moving the local instance live. On the latter, it’s almost ready! There are a couple of hitches presently but everything has migrated correctly. For the former, I have been finishing up details on the Apple IIe, and adding an Osborne 1 to the site.
For the Apple IIe, I’ve scanned some documents Matt has kept through the years: packing lists, warranties, business reply forms, manual errata, etc. These add a good deal of use context to the machine. For instance, the Apple IIe came with a wrench and nut plate for adding and swapping expansion cards. The computer was really meant to be modified and expanded upon by the user. It is really a very open device. Not only does one not need screws to access the motherboard and cards, one doesn’t even need to turn the machine on its side or upside down. It opens in its regular orientation, sitting on the desk. Besides this, a printer registration card from Star Micronics provides a list of popular computing magazines from which the purchaser can indicate which he or she reads. These range from Apple Orchard and 80 Microcomputing to Dr. Dobb’s Journal.
The Osborne 1 is clearly a less openable device, but it’s providing a good test of the how flexible the modeling we have used so far really is. Like the Apple IIe, it is a fully-functioning system, but unlike that machine, there is no physical computer case to base components around. The Osborne’s form factor prevents this sort of distinction since it’s a single containing unit. Still, the system has a motherboard (which hosts all the connections and software), and it does have component pieces, such as a 300 baud modem, the 5″ CRT display (dwarfed between two Fujitsu floppy disk drives), the microprocessor, etc.
A video game preservation paper has been making the rounds of late. Dave tweeted about its discussion on Slashdot, then it showed up at Ars. It’s a good paper, and I was particularly interested in one of its citations, a 2005 paper from the National Library of the Netherlands that proposes modular emulation as a new tact on the emulation front. The authors, Jeffrey van der Hoeven and Hilde van Wijngaarden, describe some common emulation woes such as stack emulation (the rabbit hole of emulators emulating emulators and so on to persist the particular emulator of interest through future platforms), emulator migration (rewriting the emulator over and over to persist the emualtor through future platforms), and the present limitations of Lorie’s UVC for behaviorally complex data with intense I/O requirements (like software).
Modular emulation proposes breaking down emulation to component parts in the interest of reusing those component parts in different and new configurations:
Emulation of a hardware environment by emulating the components of the hardware architecture as individual emulators and interconnecting them in order to create a full emulation process. In this, each distinct module is a small emulator that reproduces the functional behaviour of its related hardware component, forming part of the total emulation process.
This makes a lot of sense to me, and it maps perfectly to the modeling we are investigating here. For example, instead of concerning ourselves with writing an emulator for the Apple IIe (which as an actual and specific machine is always going to vary in expansion cards and internal peripherals, etc.), we instead focus on a solid emulator for the MOS 6502 8-bit microprocessor that handles the system’s computations. That processor appears in many, many machines, so having that emulation software is much more useful than the Apple IIe as an unbreakable whole. It needs to be combined with other emulator-components, of course.
The benefit of modeling and describing systems by components is that if done consistently by a large number of persons, one begins to generate a collective database of parts and pieces. This can facilitate recognition of similarities across platforms (could be useful for platform studies endeavors), easier groupings of system properties, etc., and ideally, more expedient and cheaper emulation. It also strikes me that persisting these independent emulations pieces would be infinitely easier than managing a more monolithic systemwide emulation piece. And finally, this incremental approach to emulation is simply closer to the true internals of the machines, and that better accuracy of description is educational.
Walker Sampson 