In article <1328644112.95691.YahooMailNeo at web164502.mail.gq1.yahoo.com>,
Chris M <chrism3667 at yahoo.com> writes:
I think Richard's point was that the title belies
the fact that the NES
itself is not being programmed, but rather an emulator is being implemented
in LISP.
It's not an emulator. He wrote a 6502 compiler in LISP. He writes
his demo in LISP that when executed compiles to the native instruction
set for the NES and presumably writes that out to a file. I admit to
having skimmed the article so I didn't read every little detail of how
he gets the output of his compiler onto the NES.
I find emulation in general a fascinating topic. It
seems that not too many
people on this list are familiar w/the mechanics of creating an emulator
(as of a couple of years ago. I asked a question or 2 and got no reply.
Perhaps my queries were regarded as white noise, and were dispensed
w/accordingly. Don't know. Anyone? bzzzzzzzz).
Responses are spotty. When people go on and on for 50 or 100 messages
on items that are off-topic, people basically stop paying attention
to the entire list. Add to that people's penchant for *not* adjusting
the subject line to account for topic drift and I suspect that many
people, like me, skim the subject lines and delete en-masse when it
doesn't seem interesting. I don't have enough time to read every
message on the hope that it might contain something interesting when
it's just another meandering topic thread from the Usual Suspects.
There seems to be a
significant distinction made between emulation and virtualisation.
Most definitely.
[...] it
behooves the programmer to recreated every last detail of the targeted
system, down to gliches and whatnot.
Unfortunately for truly authentic simulations, the glitches aren't
often documented and must be discovered the hard way. I would imagine
that it's a small number of people that have the drive and patience to
faithfully reproduce all the glitches in an obscure system. For
something like the C=64, sure, because you've got a community of
enthusiasts to keep you motivated, but for something like the Nuclear
Data ND-812? I doubt it.
It seems this approach is rather fundamental to
virtually (no pun intended)
all low and much higher level exercise. If a firmware patch is needed to
implement a new feature (such as running flash on a cheap Taiwanese tablet
knockoff, where earlier it would refuse or crash the machine), how is this
not in a broad sense "emulation" of a sort?
Sorry, you lost me there. Firmware patches aren't any sort of
emulation or simulation.
A question I asked sometime ago was is emulation
basically just parsing?
No, it's not. Parsing is just turning raw text into a data structure.
It's the first part of a compiler or interpreter. You could view
emulation as having a "parse" of the binary instruction stream, but
typically decoding the binary instruction stream is simple enough that
it's not considered parsing. In a processor there would be circuitry
dedicated to this function and it's generally called "instruction
decode" and that's what people writing emulators generally call it as
well.
Anyone. Bzzzzzzzzzzz. Perhaps that's too simple a
description, but it would
it seems describe what is taking place (and in that sense all
assembling/compiling/translating is simply that, parsing)
No, no, no. Parsing is not assembling, compiling or translating.
It's important to use the terms properly or you'll just confuse
everyone who's listening.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>