PDA

View Full Version : To emulate or not to emulate; that is the question.



bettablue
September 27th, 2012, 06:07 AM
To emulate or not to emulate; That is the question. This will be the title of an upcoming post on my Blog on my web page, All Things DOS. I have been asked to write an article outlining why or why not one would choose to use an emulation program rather than use the real deal? Why, or for that matter, why not would one choose to use an emulation program rather thanuse the real deal?

I understand that most users who choose emulators do so out of the desire to run a particular program, or game that current operating systems just can't play any longer. Compatibility issues like this are all over the place. Silent Steel and Ripper are a couple that come to mind for me. In order to play these, I either have to have a computer running an older OS; which I do, or they will have run them under an emulator. These users really have no choice but to emulate a previous version of operating system loke DOS, or Windows 95. DOS Box is great for these two games.

However, what about those like you and me, and most of us here in the forums? Do you run an emulator for a particular computer you own?

I mean, I myself, have seen some pretty good reasone for emulating a particular program before running it on the vintage computer. That makes perfectly good sense. However, I have also seen instances where a particular user will run the emulator almost exclusively, even though the computer they're emulating is in perfect working order sitting right next to them.

Then there are those times, when running an emulator just makes no sense whatsoever, and the emulator would mislead a user intobelieving that a program they are running will work with the real computer. Then when the use attempts ro run the program on the real computer, the program fails because of memory, hardware configurations, or sometimes, coding differences based on their own criteria. For instance. A user is running a program under a Tandy Color Computer emulator. Then because he likes the program so much, and he likes the way the game plays in the emulator, he goes out and purchases a NIB Tandy Color Computer, only to find afterwards that he purchased a Coco 1, and the program requires a later model of the Color Computer; the Coco 3. Well, of course that is the users fault for not looking at the system requirements of the program he wants to run. I personally own a Tandy Coco 1 with Extended Color Basic, and only 8464 Bytes of memory available for use. Almost all of the programs designed to run under emulation require much more; somewhere in the order of 128K. So my Coco 1 will never be able to run those programs. I accept that limitation, because the programs I'll end up writing for it, simply will not require more than that. My first Coco 1 only had 4K of memory after Extended Color Basic was loaded. Of course, that caused some problems, but I learned to live with it. An emulator usually won't know what model of computer you're running, or how much memory you have. It's jub is to mimic the best of the machines the program was designed to mimic.

OK; let me get back on track.

Here is a basic questionaire. Answer to the best of your ability. And please indicate if you will allow me to use your real name or handle in my article. When the blog is posted, I will inform you all here. And of course, you can read the entire article at www.allthingsdos.com (http://www.allthingsdos.com).

1. Your name/Handle
2. Can I use your name/Handle in my article?
3. Do you use an emulator? If so, What computer are you emulating? What emulation program are you using?
4. Do you also own the computer your emulation program is designed to mimic? If not, do you plan to purchase that particular computer?
5. Do you find that you would rather use the emulation program, or do you prefer to use the program on the real computer? Why?
6. What are the primary reasons you run an emulator?
7. What are some reasons you would NOT use an emulator?
8. Would you recommend an emulator to someone who has the computer the emulator is designed to mimic? Why, or why not?

Please take your time in answering these questions. I want to thank each an every one of you who take the time to complete my small questionaire. And to those many people who have helped me in the past. I offer a special thank you. It is because of VCF that I not only have the best possible IBM PC system, but that my collection has grown from only one computer to 9. And now that we have enough computers, All Things DOS will be taking these computers into the classroom. More on that later. I will have something written on my web page a www.allthingsdos.com (http://www.allthingsdos.com) for your review shortly.

Thanks again all.

patscc
September 27th, 2012, 07:36 AM
Are you including virtual machines, like vmware, in your definition of emulation ?
patscc

bettablue
September 27th, 2012, 08:38 AM
I guess you could consider that too. After all you are adding another progtam to your computer to allow the use of other programs, so the definition seems to fit.


Are you including virtual machines, like vmware, in your definition of emulation ?
patscc

Chuck(G)
September 27th, 2012, 09:30 AM
I'm not at all clear on this. Is running DOS programs on OS/2 or Windows NT considered as "emulation"? How about Windows 9x?

bettablue
September 27th, 2012, 09:56 AM
Trying to keep this as simple as possible. Usually any of the emulators are labeled as such. So, Chuck, since you have an IBM PC. Do you have something on your primary computer that would allow you to run and test a game you plan to install on your 5160? That intermediate program would be an emulator. The reason I would also consider something like VM, is that with a virtual machine, you're basically emulating an earlier, or different operating system. I can run Apple OS-10 on my Windows 7 machine by using VM, so in effect, I'm emulating a Mac. I'm also using VM to load Windows XP Mode, with is really emulating Windows XP.

By itself, a machine running Windows 95 is NOT emulating anything. Nor is running DOS with Win95, unless you have something that will allow you to run a non native version that doesn't load with the Windows 95 shell.

Hope this helps. ;-)


I'm not at all clear on this. Is running DOS programs on OS/2 or Windows NT considered as "emulation"? How about Windows 9x?

Chuck(G)
September 27th, 2012, 10:08 AM
Running Windows XP in a VM is not "emulating" XP--that's real XP there, not someone's emulation of it. What's being emulated is the machine itself.

Similarly, I can boot any version I care to of DOS on Linux DOSemu--but it's real DOS, not an emulation. What's being emulated is the x86 CPU and its BIOS environment. Although I haven't tried it, I seen no reason that Concurrent CP/M couldn't be run just as easily under DOSemu.

XP, on the other hand, does emulate the DOS API and a few hardware functions, such as video memory mapping, so it's not real DOS per se.

Do you get my drift?

bettablue
September 27th, 2012, 10:25 AM
I completely understand your point. All I'm asking is a very simple question. I didn't think it was going to open a whole can of worms. The point isn't to say what is emulation, but do you use an emulator. In the simplest form, if I'm running my Windows 7 computer, and want to run software written for my Tandy Coco, the I have to run an emulator. A true emulator will adjust for all of the Coco's resources so the game of software will run properly.

Now as far as emulation in the broader sense is concerned, I could argue that all of the things I mentioned to your first reply are all emulating something else. And yes, they do all fit. Like I said though... I'm not looking for what one person would call an emulator, and another wouldn't. You would ultimately know if you downloaded an emulator so you can play some game or run some program for let's say, and Atari computer from way back when. You really would need an emulator to do it. I really don't want to go that far though. All I want to know is if someone is using an emulator and what for; as in what computer are you emulating, a Tandy Coco, a Commodore 64...

The rest should be pretty self explanetory. "Should" being the operative word here... Lol.




Running Windows XP in a VM is not "emulating" XP--that's real XP there, not someone's emulation of it. What's being emulated is the machine itself.

Similarly, I can boot any version I care to of DOS on Linux DOSemu--but it's real DOS, not an emulation. What's being emulated is the x86 CPU and its BIOS environment. Although I haven't tried it, I seen no reason that Concurrent CP/M couldn't be run just as easily under DOSemu.

XP, on the other hand, does emulate the DOS API and a few hardware functions, such as video memory mapping, so it's not real DOS per se.

Do you get my drift?

krebizfan
September 27th, 2012, 10:37 AM
This will be a little bit disjointed. I am supposed to be observing a web presentation but the big name vendor seems to have forgotten to include clocks in their offices.

I have two cases where I prefer to use an emulator over older real hardware

First, initial drafts of software. If I was to do something crazy like write a new OS for PDP-11, I would prefer to have the emulator crash when I incorrectly access the emulated floppy drives instead of hearing physical floppy drives scream in protest.

Second, I do a surprising amount of data conversions for old software but modern versions of the applications don't handle files created by software more than 10 years old. But the older versions either won't work on a modern OS or won't coexist with newer versions. Place an older version in a VM with an appropiate OS and use that to move to an intermediate format that new software can handle. The VM will much faster at the conversion and moving the results from the VM to the system with modern will be much simpler than using an era appropiate set of hardware.

patscc
September 27th, 2012, 10:55 AM
krebizfan said

but modern versions of the applications don't handle files created by software more than 10 years old
That's kind of a blanket statement, don't you think ? MS Word 2010 opens up Word 97 files just fine, Visual Studio 2010 opens up old projects, Adobe Acrobat still opens up early pdf's, just to name a few.
patscc

Trixter
September 27th, 2012, 02:08 PM
Your survey questions lend themselves to me re-stating my basic point multiple times redundantly, so I'll just answer in essay form. You can use any of this information as you see fit, and you can use my real name (Jim Leonard). For the purpose of my reply, I define "emulation" as "interacting with software running in a virtual environment that mimics the physical environment the software was originally designed to run under". I also define a "work" as the software you are running in said environment, and is not limited to games (although most emulators are indeed used overwhelmingly for gaming).

Apologies for length; I probably should have turned this into a blog post first and then linked you to it. For the TL;DR crowd: You need both vintage hardware and emulation to properly research something. (I will likely turn this into a hyperlinked blog post in the near future.)

I've contributed to a few emulators in varying capacities over the last decade, and in that time, some of my emulation colleagues have expressed surprise when I mention that I have a large collection of functional vintage machinery (both personal computing as well as console gaming) hiding in my crawlspace, and that I rotate pieces in and out on a regular basis for both enjoyment and research. This is not a statement against emulation; some emulators are packed with features that make interacting with the original works very easy and flexible (such as DOSBox, MESS, and MAME) while others are dedicated to accuracy to extreme levels (such as bsnes). The state of most emulation scenes today is thriving and quite practical.

So if that's the case, why maintain so many physical machines? It's because emulation can only go so far. No matter how good the emulation is, you can't change the fact that you are running a work on a physically different computer than what it was designed for. For most works, this is perfectly acceptable, but there will always be something missing no matter how good the emulator is. In my vintage computing research, I use a mixture of both emulation and real machines so that I can reap the benefits of both. To illustrate this, I'm going to explain the advantages of both emulators and vintage hardware.

Vintage Hardware Advantages

People who never had access to vintage hardware, and always have success running software inside their emulators, sometimes can't understand what is missing when you emulate, even using one as hyper-accurate as bsnes. Most emualtors handle the obvious (CPU and Video display subsystem) well, because those are required for basic operation; they also handle CPU "speed" and system timing well, as mishandling them would prevent performance-sensitive software from running properly. So what's missing? Here's a short list:

- Video display properties: Color temperature, screen curvature, scanlines, response time, phosphor layout, phosphor speed. All of these are important, some more than others. Vintage game graphics were composed with all of these properties in mind, from color choices down to individual pixel placement by the artist. If you are viewing a classic game's graphics on a progressive display, the end result can be either too bright or too dim, over-saturated or under-saturated -- no matter the outcome, it's definitely not what the artist intended. Thankfully, this is changing thanks to ever-increasing GPU power (see http://filthypants.blogspot.com/2011/05/more-emulator-pixel-shaders-crt-updated.html) But as awesome as modern shaders are, they can't overdrive hardware. Anyone doing serious research on vector arcade games absolutely must see at least one in person to get a feel for just how bright and intense the vectors can be. (I personally recommend the mint-condition Asteroids currently operating at the Galloping Ghost arcade -- very bright, currently no burn-in.)

- Interface properties: Input device layout, button placement, tension/stiffness, etc. This is just as important for computer emulation than game console emulation, because computers have input devices specialized for general-purpose computing (keyboards, mice) and not gaming. For example, some games on the PC used F9 and F10 for lateral movement in games, which initially doesn't make any sense until you look at a vintage 83-key PC keyboard and see that F9/F10 were located at the very lower-left of the keyboard -- optimal placement for gaming with the left hand. And young Mac users may wonder why classic mac games only use a single button until they physically see why. This is most easily fixed by connecting vintage input devices directly to the machine performing the emulation, although such connections can range from a commercial adapter to a homebrew wire-wrapped monstrosity. But it's worth the effort, so that you can see why Intellivision or Colecovision games require you to quickly navigate menus using the 1, 3, 7, and 9 keys (look at the controllers, you'll see what I mean).

- I/O properties: Because most emulation research is in the field of gaming, little attention is paid to emulating I/O as it was on the original hardware, such as the speed of the storage subsystem, any noise it made, and so on. (In fact, most emulators attempt to speed up I/O as much as possible so that programs load much faster than they did on the original hardware.) Some emulators do this, such as WinUAE, but the overwhelming majority do not, and I think that's a shame. For gaming, I/O isn't usually a concern, but for any historical research, it can provide a visceral response that would otherwise be missing.

This last one is hard to understand, so I'll provide a real-world example: When playing the game Wizardry on a real Apple II or IBM PC, it loads from a single floppy disk frequently while the game progresses, to load new graphics, maze data, etc. due to the computer's memory being smaller than what a floppy disk holds. Wizardry is a role-playing game, which lends itself to repetitive tasks: Enter dungeon, explore new area, fight party of monsters, etc. As you play Wizardry on these systems, you begin to recognize, either consciously or subconsciously the floppy disk access patterns -- the "whirr, thunk, buzz" noises coming from the drive -- for these repetitive tasks as the game runs. Open a chest, "thunk"; go down a level, "thunk-THUNK whirr thunk", you get the idea. Now, imagine that your party is wounded and desperately heading to get to the surface to heal, while navigating an unfamiliar dungeon trying to avoid conflicts. You (K)ick down a door, and instead of the familiar "whirr thunk" of finding an empty room, or "whirr buzz thunk" of finding a chest, you hear "whirr buzz thunk-thunk BUZZ THUNK THUNK-THUNK-THUNK-THUNK" and realize, with growing horror, that the game is loading a lot more data than usual because it is trying to put a bone-crushing, game-ending party of monsters behind that door. But my example doesn't end there! Not only is the I/O subsystem contributing to a real feeling of anxiety and dread, but it is also offering you a choice: If you act quickly enough, you can dive for the floppy disk and pull it out of the drive, preventing the game from loading the data it needs to seal your party's fate. This works because Wizardry only saves your progress at two places: When you die (which in this example is in about two seconds from now), or out of the dungeon, back in town. Ripping the disk out means you unfortunately lose your progress since the last time you saved, but more importantly it cheats death -- and in Wizardry, death is (mostly) permanent, even across saved games.

Emulation Advantages

For vintage gaming research, emulation provides many benefits that the original hardware would struggle with, or in some cases, are impossible. My favorite emulation advantages are, in order of importance (to me):

- Instant searching. You can load and try at least one game a minute, faster if you're organized and a quick typist. This is great if you're trying to blow through 50+ games looking for something (a game character, a programmer or graphics artist in the credits, a specific gameplay mechanic, etc.) This is great for answering quick historical questions.

- Infinite hardware access. For PC emulation, any combination of video and sound standards can be quickly loaded and tested. My most common use of this hearing all of the different ways a composer tried to optimize a game score for a specific hardware device. For example, load a game that uses 16-note polyphony with a MIDI device, and then load it again with the 3-voice Tandy/PCjr audio chip and hear how the musical elements were scaled down to a drastically limited output device. This practice can also lead to some interesting discoveries, such as how Rob Hubbard bit-banged a single SN76496 channel to make it perform like a crude DAC on Tandy machines, leading to some music soundtracks you can only hear properly on that platform.

- Easy video and audio capture. While audio/video capture is not a substitute for the real thing, it is excellent for quickly illustrating gameplay mechanics or concepts. Capturing video or audio from vintage hardware ranges from easy and high-quality to "impossible" (requiring hardware modification to tap the necessary signals for capture).

- Expanded capabilities. Emulation can enhance your experience of a work, which can greatly increase your enjoyment or appreciation of it. My favorite example of this is playing early multiplayer serial/modem/IPX games, or even 2-player game console games, across the internet with another player. In the 1980s, if you wanted to play a console or computer game with another person, you had to be physically present. In the case of computer hardware, you had to connect computers via a serial cable, a modem connection over phone lines, or some other wacky physical connection such as a MIDI cable. The difficulty of establishing connectivity limited the experience. Nowadays, that situation has completely flipped -- connectivity is standardized and widespread across international boundaries. Emulation bridges what the vintage hardware expects with what the real world can provide, and makes it possible for two people to play the same vintage console or computer game as if they were sitting side-by-side.

- Inspection. I absolutely love this. Many top-flight emulators have an embedded debugger that allow you to pause the emulated system, inspect memory and registers, set execution breakpoints/conditions, and more. This is an absolute boon to researchers (and preservationists, who wish to unprotect copy-protected games so that they can survive past the failure of their media). This has answered a great deal of historical questions for me, from why one particular PC MOD player is the fastest in the world, to how some vintage games manipulate a 3-D virtual space and calculate rotation and perspective transformations.

So there you have it: You need both vintage hardware and emulation software to get a better picture of what you're researching.

(Note that I didn't say "to get the full picture", because it's impossible to get the "full" picture of a particular work. The "full" picture would conceivably include facets of the work that may be impossible to obtain, such as experience with the social and political direction of the time period in which the work was created, the background of the people who created the work, the business and financial pressures that led to the funding of the work and controlled its motivation and direction, etc.)

bettablue
September 27th, 2012, 02:44 PM
Trixter, I haven't seen you here in a while. Good to see you answering my little questioniair too. And thanks for the definition at the beginning of your reply. I thank that was exacyly what I needed in conjunction with Chucks in order to clarify my objective.

Thanks much to both of you.

Chuck(G)
September 27th, 2012, 04:52 PM
Pretty much what Jim said. I emulate when I'm running tools that don't require direct hardware access; it's just more convenient. I don't emulate when I need direct hardware access--most emulators do a very bad job of emulating actual hardware devices.

I don't play games, so that's not a consideration for me.

reenigne
September 28th, 2012, 02:33 AM
1. Your name/Handle

Andrew Jenner/reenigne


2. Can I use your name/Handle in my article?

Sure.


3. Do you use an emulator? If so, What computer are you emulating? What emulation program are you using?

I do. Mostly PCs, in DOSBox and sometimes MESS. I've also played around with other PC emulators and with emulators for many other systems to various degrees.


4. Do you also own the computer your emulation program is designed to mimic?

I do - I bought an XT last year.


5. Do you find that you would rather use the emulation program, or do you prefer to use the program on the real computer? Why?
6. What are the primary reasons you run an emulator?
7. What are some reasons you would NOT use an emulator?
8. Would you recommend an emulator to someone who has the computer the emulator is designed to mimic? Why, or why not?

I'm going to follow Trixter's example here and reply to all these at once with an essay.

I came about this a different way to probably most on this forum. I started tinkering with emulators for the purpose of software preservation - there are many pieces of software out there written for old computers which won't run on modern PCs without an emulator, and many of those don't work perfectly on emulators either because emulators tend not to be perfectly accurate. The old machines won't last forever and I didn't want the software to be lost when the last machine capable of running it breaks down beyond repair. I also figured that if I could improve the state of emulators enough, people could finally get rid of the space-hungry, power-hungry, inconvenient old machines that they were keeping around to run some of these old programs. In fact, I heard of several people (probably between 6 and 12) getting rid of old machines because they were able to replace Digger with Digger Remastered - so many machines being kept around just to play a single game!

For a long time now I've been intending to write my own emulator, which emulates the original PC and XT machines much more accurately than anything else out there. I've been thinking about it, on and off, for at least a decade and it's still not done - but I have had a lot of fun on the way! At some point I realized that the information needed to write the emulator I wanted to write (in particular, detailed instruction timing information) just wasn't out there on the web, and would have to be reverse-engineered from the physical machines themselves - which is why I bought that XT last year.

But in the process of getting the machine working and extracting the information I needed from it, I discovered the joys of simply playing with the original physical hardware itself - I came to appreciate the construction techniques used back then, and circuits simple enough to be understood and repaired by mere mortals. I realized that there are aspects to owning and using these machines which can never be duplicated in an emulator. Trixter goes into more detail about this but I think the main ones for me are the tactile ones (switches, keyboards and floppy disks) and also the experience of taking the machines apart and repairing them. So I no longer believe in my original goal of ridding the world of vintage computers through more accurate emulation. In fact, I have a long and growing wishlist of machines I'd eventually like to obtain once I have money to do so and space to put them!

That doesn't mean I've given up writing that emulator, though - on the contrary, having an explicit goal like that gives me a good excuse to play with the physical hardware! And because of the advantages of emulation, it'll make things possible that have never been possible before. With a cycle-exact emulator, I'll be able to write an assembler that counts cycles as it's assembling and inserts timing delays statically or rearranges instructions for maximum performance. Or a debugger that can infallibly tell you exactly what happened in the lead up to some error because it understands the entire state of the machine. It is my hope that such tools will lead to a sort of renaissance of programming for these old machines and some great new software being written for them, such as has been done with the Commodore 64 (I'm seriously impressed at some of the art, music, demos and games that have been made for that machine, and I'm sure it's not a coincidence that the machine is much better understood and documented and emulators are much more advanced and accurate). Of course, it'll be no fun if there aren't still suitable machines around then to run those programs on to prove that they really do work that well on real hardware!

eeguru
September 28th, 2012, 02:44 AM
Isn't 'emulation' fundamentally tied to imperfection? If you had two things - either two computers or even two people - and one was emulated and the other original, if you couldn't tell which one was which from interacting with it, is either really an emulation or just a perfect recreation of the original?

If you perfectly recreated an old CPU at an RTL level, is that an emulator?

Was the kid in Kubrick's AI a real boy?

reenigne
September 28th, 2012, 03:07 AM
Isn't 'emulation' fundamentally tied to imperfection? If you had two things - either two computers or even two people - and one was emulated and the other original, if you couldn't tell which one was which from interacting with it, is either really an emulation or just a perfect recreation of the original?

I think it's an "interface" vs "implementation" thing. You could have a perfect emulator if you can make all the interfaces between the human and computer indistinguishable from the original machine but implemented it in a different way (software running on a modern PC, a FPGA instead of Intel chips and 74xx discrete logic etc.). I suppose the difficulty comes in defining what constitutes the interface. Does taking the cover off the machine and looking at the chips inside constitute an interface? What about probing their legs with a multimeter or oscilloscope? Having one go faulty and replacing it with a soldering iron?

So (depending on exactly how you define it) a "perfect" emulator may not be possible. But it should be possible to make an emulator so good that no piece of software can determine if it's running on an emulator or on a real machine. And it's certainly possible to improve on today's emulators (such as simulating many of the effects that Trixter mentioned).


If you perfectly recreated an old CPU at an RTL level, is that an emulator?

I would say yes.


Was the kid in Kubrick's AI a real boy?

Fortunately none of things that emulator authors have to worry about are as slippery to define as consciousness!

tezza
September 28th, 2012, 03:58 AM
Yes, there is room for both emulators and the physical units when it comes to enjoying vintage computing. I have emulators in place on my XP box for all my physical models (http://www.classic-computers.org.nz/blog/2010-04-5-emulators.htm).

Tez

eeguru
September 28th, 2012, 04:16 AM
If you perfectly recreated an old CPU at an RTL level, is that an emulator?

I would say yes.


Then is a Harris 80C286-20 a real 286? There have been many instances of CPU creators sub-contracting late run production. I doubt in most if not all cases the sub-contractor took the original metal mask and sent it to the fab as-is. Most took an original RTL design and re-synthesized it with minor changes targeting their fab process. If you did that today targeting an ASIC house or with an FPGA, I submit it would still be a 'real 286' but not necessarily a genuine Intel 80286-6 or Harris 80C286-20. But it would fall in the same general category second run parts produced by Harris, AMD, NEC, OKI, etc through-out the years.

When arguments are taken to the extreme, the division usually becomes clearer - or in some cases not.

Chuck(G)
September 28th, 2012, 08:49 AM
Please, let's not get into the "emulator" versus "simulator" discussion. That's been beaten to death (with no positive outcome) on seveal fora.

There was a time in computing when an emulator connoted a mostly hardware-level device, such as the 1401 emulation mode on a S/360 mainframe. Simulators tended to be software-only. But even that distinction wasn't strictly observed.

bettablue
September 28th, 2012, 09:06 AM
This entire thread has been a learning experience. Thanks Chuck, Teza reenigne, and others. I fully agree with Chuck here in his last statement too. Let's just try to keep it simple. I certainly didn't want to turn this into a What if, what if, what if thing. Yes, there could be litterally hundreds of different configurations all claiming to be an emulator, and an equal number calling themselves simulators. Trying to decise which is which isn't really going to answer the questions I posed. Still though, I want to let this run for a few more days so I can collect as much data as possible before compose my Blog entry.

Do any of you mind if I use arguments and/or comments from this thread in my writeup? Then before posting, I would like to send it to a few of you via PM for your approval. (Chuck will be one) Only after we have a consensus will I post the completed article.

What say you?



Please, let's not get into the "emulator" versus "simulator" discussion. That's been beaten to death (with no positive outcome) on seveal fora.

There was a time in computing when an emulator connoted a mostly hardware-level device, such as the 1401 emulation mode on a S/360 mainframe. Simulators tended to be software-only. But even that distinction wasn't strictly observed.

reenigne
September 28th, 2012, 12:16 PM
Do any of you mind if I use arguments and/or comments from this thread in my writeup?

That's quite alright by me! I look forward to reading the finished piece.