In mid-March, the Tools subgroup met FRED, our Forensic Recovery of Evidence Device. The subject lines we’ve shared since then (e.g., “tinkering with FRED today”) reflect the approach we’re taking:  careful, playful, open-minded. We marveled at all the ports, laid out and photographed the various cables and adapters included in the toolbox, and took turns at the keyboard. There was much to do before any imaging occurred, though.

We spoke at length about network security, viruses, connecting to the Internet, and safeguarding personally identifiable information, which we’re sure to obtain in future images we make. Porter noted that Digital Intelligence, the company that manufactures FRED, assumes that one will connect the machine to the Internet, while Josh played the devil’s advocate, acting Thomas Pynchon-paranoid. The immediate action we took at the conversation’s conclusion was to connect to the Internet via a USB network adapter to install Microsoft Security Essentials. Next we updated all the Windows, Adobe, and Java applications. A clean machine, we agreed, should be virus protected and fitted with all the latest software updates.

The FRED system has two drives, one of which is dual partitioned into Windows 7 Ultimate (64 bit) and Win98 DOS. This is the operating system environment we initially worked in, where we made other essential downloads including BitCurator and Oracle VM VirtualBox. Later, because BitCurator is native Linux, we chose to install SUSE Linux 12.1 on FRED’s empty DATA drive.

Returning to Windows 7, the first device we connected to the UltraBay 3D Hardware Write-Blocker was Digital Stewardship’s 2 TB external hard drive, which contained images of some media from the Bill Bly Collection. Tableau Imager didn’t recognize it, nor did it register a 2 GB thumb drive that we inserted in the USB 3.0 port, although each device was visible on the list of the computer’s drives. Reading through the text-based instructions again, we discovered that the UltraBay has a power supply independent of the FRED tower (Digital Intelligence does not include diagrams or screenshots in its instructions), which, once turned on, allowed us to image the thumb drive. No matter which target directory we selected, however, the external hard drive repeatedly failed to image, due to lack of storage space. Tableau Imager offers EnCase E01 and Raw Disk dd imaging options, both of which are set to capture all the bits, so 2 TB was a bit much to ask of the machine.

Our progress configuring FRED has been fun and sometimes frustrating, but always steady. Over the next couple of months, our goal is to attempt to image every imaginable format on FRED and our BitCurator Digitization Workstation. Which system, with which software (BitCurator, Tableau Imager, FTK Imager), works most effectively? Learning what’s possible to accomplish with our equipment will be a beneficial exercise to complete before the arrival of our National Digital Stewardship Residency fellow in September.

The post Born Digital Working Group: Configuring FRED appeared first on Maryland Institute for Technology in the Humanities.

The following post was written by PoliProc members Robin Pike and Joanne Archer.

The Born-Digital Working Group, Policies and Procedures subgroup, has spent February examining the changes we will need to make to existing policies to accommodate born digital material. The goal of the subgroup over the course of the next few months is to:

• examine current Special Collections policies such as collection development policies, donor agreements, and the UM processing manual
• review policies that consider born-digital or electronic media at other institutions, especially within the AIMS project
• create modular policies and agreements for the UMD Libraries that consider born-digital media
• identify the input we will need from the Administrative and Tools subgroups that will determine the content of some of the policies.

Special Collections does not currently have an overarching collections policy. Instead each subject area within special collections has smaller, separate policies, none of which specifically address collecting born-digital material. Our subgroup will develop a policy for born digital material that will provide Special Collections staff who are working with donors a clear understanding of our capability to provide long term stewardship of digital material. It will also give guidance on the type of information that should be gathered at the early stages of donor development.  We expect that we will draw heavily on the born-digital sections of other institutions’ existing policies.

Examining the existing donor agreements at first glance seems to be the most straightforward aspect of our work. Special Collections uses a standardized deed of gift form which is modular in format and takes into account various rights, privacy, and use restrictions. We plan to add points and revise current statements to consider born-digital media. However, some of the questions we need to reflect in the donor agreements include how born-digital material will be transferred or captured, donors’ preference in terms of files previously deleted but recovered in the transfer process to the library, the scope of what we can provide in terms of preservation of the born-digital material, and specific conditions on access to materials. Although the donor agreement seemed the easiest place to start it become clear that establishing what we can and are willing to collect (i.e. the collection policy) is the critical first step for this group. It’s also clear that we need to work closely with our tools group to understand what will be technically feasible at the University of Maryland.

While part of the scope of this group will be making changes to the Special Collections Processing Manual it is already clear that this will happen much later down the road once the tools group has made recommendations for ingesting and accessing born digital materials.

Fortunately, we are not the first to begin work on these issues and we will be relying heavily on the work of other institutions. Our first steps are to examine the following resources:

• AIMS Born-Digital Collections: An Inter-Institutional Model for Stewardship, January 2012 (http://www2.lib.virginia.edu/aims/whitepaper/AIMS_final.pdf)
• SAA Campus Case Studies
• SAA E-records listserv (for examples/templates)

The BDWG has started it’s work in earnest at this point and it’s the questions we need to answer are becoming more clear. Our FRED (Forensic Recovery of Evidence Device) has arrived so soon we will be able to start thinking more concretely about workflows and procedures.

The post Developing Policies for a Digital World appeared first on Maryland Institute for Technology in the Humanities.

Tools
Originally called “Technology/BitCurator/hardware/software/tools,” this subgroup is dedicated to pre-processing work–everything that happens before an acquisition is deposited in the digital repository. The Tools group is led by Jennie Levine Knies and includes Amanda Visconti, Eric Cartier, Matt Kirschenbaum, Porter Olsen and Rachel Donahue.

Policy/Procedures
Dedicated to developing the many guidelines necessary to implement new digital workflows in the libraries. The Policy/Procedures group is led by Joanne Archer and includes Caitlin Wells, Daniel Mack, Rachel Donahue, Robin Pike, and Trevor Muñoz.

Metadata
Dedicated to data about data. Specifically, this group will look at everything that’s needed to create a properly-described submission information package (SIP). The Metadata Group is led by Joshua Westgard and includes Eric Cartier,Jennie Levine Knies, and Rachel Donahue.

Administration
Dedicated to providing the high-level support needed by change agents everywhere. Administration was originally lumped in with Policy/Procedures, but we broke it out to keep things specific and manageable. The Administration group is led by Trevor Muñoz and includes Daniel Mack, Jennie Levine Kniees, Joanne Archer, Matthew Kirschenbaum, and Rachel Donahue.

As you read our posts in the future, bear in mind that we’re essentially starting from scratch. We’re unlikely to have anything amazingly groundbreaking to share, but we hope that being transparent about our work might help other organizations undergoing similar changes.

The post The Born Digital Working Group Divides and Conquers appeared first on Maryland Institute for Technology in the Humanities.

One goal of the Preserving Virtual Worlds 2 (PVW2) project is to provide videogame curators with information and tools to make their job easier.  One small but important step in any digital preservation workflow is auditing the files–making sure that the bitstream you have in your repository is the same as the bitstream on the original media (or, down the line, making sure that the bitstream in the repository is the same as the bitstream you originally ingested). This is sometimes referred to as an integrity check, and with files stored and accessed on ordinary media is a relatively trivial matter of calculating a checksum at ingest and  checking that the same number is still derived when the same algorithm is applied to the bitstream at regular intervals.  When data is being migrated into a new format, it is also wise to make sure nothing is lost when accessing the file in  the new format, which is why you’ll find color strips in the toolkit of digitization QCers.

When we migrate SNES games to a media neutral format, we’re taking code that was originally burned into a read-only chip (ROM) and creating a digital file. We then access that digital file using a software emulator instead of proprietary hardware designed to do nothing but read those cartridges. This raises two questions:

1. How do we know that the file we save matches the file originally burned on the ROM?
2. How do we know that the emulator is correctly interpreting the ROM?

To answer these questions, we’re using a nifty device called the Retrode2.  The Retrode allows you to play SNES cartridges with original SNES controllers through an emulator on your computer. As a side effect, it also allows you to extract ROM files and savegames (SRAM) and to write new files to the SRAM. The following workflow is based on the assumption that

1. A ROM file which will read an original savegame  from an SNES cartridge is likely an accurate representation of the game.
2. An emulator which produces a savegame which can be loaded by the game on the original cartridge likely presents an accurate representation of gameplay.

Setting up the Retrode2

The Retrode box contains the Retrode unit, a Mini-USB cable, and a simple sheet of instructions. SNES cartridges are inserted in the rear slot, facing backwards. Controllers are plugged into the side ports.

Before using the Retrode, it is necessary to flash the firmware (the firmware it ships with is known to have some errors with SNES controllers). The latest firmware, along with some basic instruction, are available here. If you’re using Windows and have difficulty with FLIP, try running it as Administrator.

Once you’ve successfully updated the firmware and reset the device, open up the Retrode in a file manager. Note the datestamp–files on the Retrode will always display this datestamp, even if you have updated them (when the device has been reset after any file changes).

Open the file RETRODE.CFG in a text editor. Your filenames may include a number after the game title. If you’d like to disable this, change the value on line 15 for

[filenameChksum] from 1 to 0. In order to write savegames to the cartridge, it is also necessary to change the value for [sramReadonly] on line 17 from 1 to 0. Only change this value if and when you are writing a savegame to the cartridge. Leaving it on provides some small security against accidentally corrupting your save file. Save. If for some reason saving the config file fails, refer to procedures for writing an SRAM (save) file  to the cartidge.

1. ; Retrode .17g – Config
2. ; Remove any line to revert setting to factory default
3. [HIDMode] 1 ; 0: Off; 1: 4Joy+Mouse; 2: 2Joy; 3: KB; 4: iCade
4. ; Hex codes for KB mode (in this order):
5. ; SNES gamepad: B Y SEL STA ^ v < > A X L R
6. ; In NES mode: A B SEL STA ^ v < > x x x x
7. ; SEGA gamepad: B A MOD STA ^ v < > C Y X Z
8. ; See usb.org/developers/devclass_docs/Hut1_11.pdf (pp.53ff)
9. [kbL] 06 1b 28 2c 52 51 50 4f 09 07 04 16
10. [kbR] 10 11 05 19 33 37 36 38 0e 0d 0a 0b
11. [nesMode] 0 ; 1: NES gamepads; 0: SNES
12. [filenameChksum] 0 ; checksum in filename? 0,1
13. [detectionDelay] 5 ; how long to wait after cart insertion/removal
14. [sramReadonly] 0 ; write protect SRAM?
15. [segaSram16bit] 0 ; use 16bit words for SRAM?
16. [sramExt] srm
17. [snesRomExt] sfc
18. [segaRomExt] bin
19. ; Override autodetect:
20. [forceSystem] auto
21. [forceSize] 0
22. [forceMapper] 0
23. ; Optional plug-ins:
24. [atariRomExt] a26
25. [tg16RomExt] huc
26. [vbRomExt] vbr
27. [n64RomExt] n64
28. [gbRomExt] gb
29. [gbaRomExt] gba

Here it is, set up and running Super Mario Kart:

Setting up an Emulator

SNES9x is an emulator available for all major platforms. To run it, simply extract the contents of the zipfile to a directory of your choice.

The SNES game pad must be setup as the input device within the emulator. To do this, select Input->Input Configuration in the top menu or press Alt+F7. Click your mouse in the “Up” textbox, and then press the corresponding buttons on the SNES controller until all buttons have (J0) or (J1) values. Ignore the  buttons after the R-button.

Select File->Load Game or type Ctrl+O and navigate to the Retrode directory. Open the *.sfc file; opening the *.srm (save) file will just cause the emulator to hang. When you play the game, it should reflect any data currently stored in the cartridge’s SRAM. The *.sfc file can be copied to SNES9x’s  Roms directory for later play without the Retrode.

Extracting and Injecting Battery Saves

To extract a save file, simply copy the *.srm file to a local directory (for instance, SNES9x’s Saves directory).

Ensure that [sramReadonly] on line 17 is set to 0 in RETRODE.CFG. If you get “Access denied.” or a similar error message when attempting to inject a save, this value is set to 1.

Some command-line work is necessary to inject a new savefile onto the SRAM. In Windows, type “cmd” in the Start Menu, right click the program that shows up, and select “Run as Administrator.” On other platforms, use the Terminal. Note the location of the NEW save file as well as the drive letter/location of the Retrode. The new save file must have the same name as the file you are replacing. Case is important. In this example we will be placing a new save file onto a Super Mario Kart cartridge. At the command line (in Windows), type:

type C:PathtoNewSaveGame.srm > D:SaveGame.srm

so, for Super Mario Kart

type  Z:DocumentsMITHPVWSNESsnes9xSavesSuperMarioKart.srm > D:SuperMarioKart.srm

 on Mac/Linux you can either use

cat /path/to/New/SaveGame.srm > /path/to/SaveGame.srm

or

dd if=/path/to/New/SaveGame.srm of=/path/to/SaveGame.srm

 When you look at the Retrode in a file manager, the srm file should now reflect today’s date. After the Retrode has been reset, even if you were successful, the datestamp will revert to the standard 1990 date. To see if the transfer was successful, clear out any files in SNES9x’s Save directory (it has a tendency to privilege local save files) and open the *.sfc file from the Retrode. The game data should now reflect the new savegame rather than whatever was originally on the cartridge. The easiest way to check this in Super Mario Kart is to look at Time Trials.

If for some reason you get a CHKSUM error and SNES9x hangs, fear not! Playing the game with an original SNES console should fix the problem. This is most likely to happen if you use the OS’s GUI copy command rather than writing over the file at the command line.

The save data originally on the cartridge.

The new save data.

 

The drawback to this workflow is that it only works with SNES cartridges that support saving. It also depends on the battery which powers those saves being live, though it is easy to replace that battery with a little technical know-how. It does, however, give us a way to audit a fair subset of SNES games and it’s a lot of fun!

The post Preserving Virtual SNES Games appeared first on Maryland Institute for Technology in the Humanities.

Travis Brown has posted additional photos (including some without Testudo) to Flickr.

The post Testudo takes over the MITH Dedication Celebration appeared first on Maryland Institute for Technology in the Humanities.

I’ve had the good fortune of being the graduate assistant for the Preserving Virtual Worlds (PVW) project for *mumble* years. The project is a partnership between MITH, The University of Illinois Urbana-Champaign (UIUC), Stanford University, and the Rochester Institute of Technology (RIT). In the first phase (2008-2010) we focused on fairly practical matters: getting videogame data into a form that could be transferred to and stored within a digital repository, packaged with enough descriptive information that a user in the far future might be able to access it meaningfully. You can read the final report here.

In the second phase (PVW2), we’re focusing on what exactly accessing a videogame “meaningfully” entails. What features need to be preserved (and how faithfully) to maintain an authentic experience of gameplay? Within the cultural heritage community, those features essential to authenticity are called significant properties. The InSPECT project says of significant properties:

Significant properties are those aspects of the digital object which must be preserved over time in order for the digital object to remain accessible and meaningful. An institution with curatorial responsibility for digital objects cannot assert or demonstrate the continued authenticity of those objects over time, or across transformation processes, unless it can identify, measure, and declare the specific properties on which that authenticity depends. Nor can it undertake the preservation actions required to maintain access to those objects, unless it can characterize their current technical representations with sufficient detail.

With some items, these properties are fairly self evident. Structure and content are essential to maintaining an authentic copy of an inter-office memo, but aesthetic details like font style and color (with rare exceptions) probably are not.  Knowing that we will never perfectly replicate my first experience playing Oregon Trail on a classroom Apple ][, looking at the significant properties raises many questions, few of them with anything approaching a definite answer, most of them with different answers depending who you ask.

• How important is the hardware? Is a game fundamentally changed if it was originally played with a paddle, but is emulated using a joystick?

• If the game was originally intended for a CRT display, is playing on an LCD or Plasma screen authentic?

• How important is sound fidelity? Early games used sound very minimally, because they were limited to the harsh sounds of an internal PC-speaker. (Try playing the “PC beep” sound in your computer’s sound options. Now imagine an entire soundtrack of PC beeps).

• How important is color fidelity? If the blood spatter in a first person shooter was originally PMS  186, do we lose something fundamental if it’s emulated as PMS 185 (Pantone Matching System)?

How do we even begin to answer these questions?!  We’re using a three step process:

Play through a case set of games and take note of features that jump out during and after play.  All project partners did a trial run at this analysis with Typing of the Dead. At MITH, we’ve been tasked to examine titles from the Harpoon, Oregon Trail, and Super Mario Bros. franchises. “Taking note” ranged from spontaneous expressions caught on video as we played, hand-written notes, and post-play captioning of video screen-capture. The notes were then compiled into a list of potential features, which we analyzed both narratively:

“TotD has intratextonic dynamics. While target phrases (the sequences typed to fire at an enemy) follow a pattern, they may change based on the difficulty setting, special items found with the game, or a random algorithm choosing from a set list of options. The first-person perspective is personal. Because the game is on rails with a linear storyline, game action is determinant and predictable, with only limited modification based on difficulty setting, special items, and in-game actions such as rescuing a non-combatant NPC.  Standard enemy NPCs move in the same patterns and will have standard phrase lengths and error forgiveness based on difficulty setting and game level. Boss characters are slightly less predictable in that they may be less tolerant of errors, errors might have consequences beyond missing a shot, and battle sequences are longer with some variety to the type and timing of attacks directed at the player. The on rails nature of the game also makes it transient; the player character will continue to move through the game level and be attacked by NPCs regardless of her input into the game.  Access is controlled and conditional, with the player required to complete levels linearly, within a certain amount of time/with a certain amount of life points before accessing new content, both playable and not.” (Following the pattern set out by Lars Konzack in his 2002 CDGC conference paper).

And ontologically:

The ontology used above combined Alexander Galloway’s work in “Game Action, Four Moments” (a chapter in a book he edited titled Gaming: Essays on Algorithmic Culture) and an in-house list of mechanics developed based on our own experiences playing games. Later attempts also incorporated the work done by the Game Ontology Project.

Knowing our bias as both players and researchers, the second step has been to interview the actual developers of the games as possible.  The developers, however, have their own biases: Both Larry Bond, original creator of Harpoon and Don Rawsitch of Oregon Trail firmly believe that the algorithms and data lying underneath their games are the only features with any significance. While it’s true that in the future a game could be recreated by overlaying a new interface over the back-end data and algorithms, it’s doubtful that many of the original game players would call such a recreation “authentic.”

This is where the third phase of our research will take over.  We will be running a series of double-blind experiments in which subjects will play both an original and emulated version of games in our case set, using the original controller. Subjects will be encouraged to verbalize any differences they note and will be given an exit interview to be developed from our experiences and interviews in the initial stages of the project.

Taken together, we hope the data we gather will help us to generate a best practices guide—or at least starting point—for cultural heritage professionals who may be faced with preserving highly interactive digital objects unlike any other digital or physical artifact in their collections.

The post Videogames as Objects of Cultural Preservation appeared first on Maryland Institute for Technology in the Humanities.