2 files changed, 22 insertions(+), 31 deletions(-)

M DESIGN.md
M README.md

@@ 12,12 12,12 @@ software, their capabilities were staggeringly limited compared to anything mode
 
 But the _distance_ between _access_ and _discovery_ seems much shorter to me.
 Modern computers are marvels but they sit upon a bedrock of knowledge and
-existing software so large, it dwarfs the ability to master it and even deep
+existing software so large, it impedes the ability to master it. Even deep
 comprehension is attained by very few.
 
-I want to write an environment to simulate an old computer. An old computer that
-had some cool applications that will be fun to use. A new environment with
-built-in tools for _observation_ and _exploration_. A toolkit for interacting
+I want to write a new environment to simulate an old computer. An old computer
+that had some cool applications that will be fun to use. A new environment with
+built-in tools for _observation_ and _exploration_. A toolkit for interacting,
 for rooting around in search of buried treasure.
 
 I'm way out of my depth here, technically speaking. But maybe that's the point.


@@ 43,7 43,7 @@ To expand, here are some notes which are part project planning, part philosophic
   * Anti-goals: Support for all mappers/games, glitch accuracy, 60 FPS/no latency blips, etc.
   * Bronze: Test roms / CPU interpreter, Silver: Donkey Kong / PPU, Gold: Mega Man 2 / CPU JIT?
 2. "Readable" lisp codebase, modern software practices.
-  * Don't write Lisp like it is C. Use CI, test roms and unit tests to ensure components work.
+  * Don't write Lisp like it is C. Use CI, test roms, and unit tests to ensure components work.
   * Readability is nebulous and for the moment adheres to my personal taste.
     * However, ideally the code and docs could serve as an introduction to low-level programming
       issues for someone with light lisp exposure and serious experience with a previous language.


@@ 61,26 61,3 @@ To expand, here are some notes which are part project planning, part philosophic
   * A companion webservice might be ideal, though clearly a separate project.
   * Formats for storing and disseminating partially deconstructed / annotated binaries.
   * Ways to export visualizations or recompiled code?
-
-### Architecture
-
-#### Memory
-
-##### The Address Space
-
-#### CPU
-
-* All the CPU registers fit in 56 bits. We could get crazy and use a bit vector to represent it...
-* Probably not a great idea but cute.
-
-##### Instruction Dispatch
-
-* Basic interpreter to start with.
-* Threaded interpreter with go/tagbody? Room for deep macrology here, could be cool!
-* Predecoding? Keep a hash mapping address -> opcode(args)...
-
-#### Graphics
-
-##### Drawing Frames
-
-* Possibly use static-vectors here to hand off framebuffers to OpenGL/SDL?

@@ 2,13 2,20 @@
 
 [![Build Status](https://travis-ci.org/kingcons/clones.svg?branch=master)](https://travis-ci.org/kingcons/clones)
 
+## Goals
+
+See: [Design](https://github.com/kingcons/clones/blob/master/DESIGN.md)
+
 ## Usage
 
+Not just yet...
+
 ## Installation
 
-Use [Quicklisp](https://quicklisp.org)!
+Eventually, Clones will be installable through [Quicklisp](https://quicklisp.org).
 
-Just run `(ql:quickload :clones)` and you should be ready to go.
+For now, you may clone this repo into `~/quicklisp/local-projects`.
+Then run `(ql:quickload :clones)` and you should be ready to go!
 
 ## Tests
 


@@ 23,13 30,20 @@ since SLIME doesn't support ANSI color codes.
 (let ((prove:*enable-colors* nil)) (asdf:test-system :clones))
 ```
 
+There is also a helper for running individual test files.
+
+```lisp
+(ql:quickload :clones-test)
+(clones-test.helpers:run-file "cpu")
+```
+
 ## Author
 
 * Brit Butler (brit@kingcons.io)
 
 ## Copyright
 
-Copyright (c) 2017 Brit Butler (brit@kingcons.io)
+Copyright (c) 2018 Brit Butler (brit@kingcons.io)
 
 ## License