Table of Contents
1. Introduction
1.1 Disclaimer
This program is supplied as is. The author disclaims all warranties,
expressed or implied, including, without limitation, the warranties of
merchantability and of fitness for any purpose. The author assumes no liability
for damages, direct or consequential, which may result from the use of
this program.
... well, maybe that disclaimer doesn't fully apply to this particular
program, but I'm sure you know what I'm trying to say. eh?
1.2 Terms of use
SNEqr is an emulator for the Super Nintendo Entertainment System (SNES), known in some countries as the Super Famicom. So, just what is an emulator, you ask? A computer emulator is a program which can mimic the behavior of another computer system. In the case of SNEqr, it creates a SNES "Virtual Machine" so that you can take a ROM image (taken from a SNES cartridge you own, or an identical copy of a cartridge you own) and run it on your computer.
SNEqr does not emulate the circuitry inside the SNES. Instead,
it approximates the behavior of the system. All information about
this behavior, to the best of my knowledge, was gathered from legal sources.
Although Nintendo does not disclose all information about the SNES, "pioneers"
in SNES programming have discovered bits and pieces about how the SNES
works (through the use of "trial and error") and the information these
people discovered was used to
write the emulator.
1.4 Key features
Some items in this list will be emulated eventually, but not all of them. Main things that are not emulated:
Minimum system: SNEqr can run on a system like this, but it won't be
pretty.
Intel 386
10 MB virtual memory
VGA card and monitor
1 MB Hard disk space
The recommended minimum system adds this gear:
Pentium-class 100 MHz Processor
12 MB RAM
Mouse
But for MAXIMUM ENJOYMENT, you need:
Pentium-class or higher processor at 200 MHz
16 MB 100 MHz SDRAM
SVGA card with fast video memory
(i.e. the SNEqr -B results for 256x256 should be at least
300 FPS)
2.1 Quick start
To load a game from the GUI:
If you get the error "Stub exec failed", then you need to find the file "DOS4GW.EXE", which, for size reasons, is not included with the official SNEqr distribution. If you have a game such as DOOM, you can just copy the DOS4GW.EXE file from there to the SNEqr directory. If not, you should do an internet search to find it. This note does not apply if you are using a version of SNEqr that contains PMODE/W.
2.2 Keys for using this emulator (and using
Gamepads)
Customizing Game Controls:
SNEqr allows you to completely customize your game controls through
the use of the Joypad Settings window. There are six preset setups
for your SNES joypad. The ideal setup for a two player game is to
set one joypad to the
"Player 1" settings, and set the other to "4+ button gamepad".
If you don't have a gamepad, the best two-player game settings are "Extra
1" for player 1 and "Extra 2" for player 2.
If you don't have a gamepad, you should never have a one of the joypads
set to the gamepad entry. Also, you should make sure none of the
"Extra" controls have joypad buttons assigned. Otherwise, emulation
could become very sluggish.
Even if a gamepad is attached, you should not choose it as an input
device unless you plan to use it. The reason for this is the fact
that Gamepads slow down emulation slightly.
Note: Because of a flaw in most cheap (or even expensive) keyboards, playing two players (or even one player) is difficult because the keyboard won't handle having many keys down at once. For example, on some keyboards, you can't press two certain directions (up & left, say) and certain other keys at the same time. This is very annoying, but it is the fault of the keyboard manufacturers.
When you are using a gamepad, you should calibrate it before you try to start using it by clicking "Calibrate Joystick" in the Joypad Settings window. If the joypad acts erratically during play, it needs to be recalibrated. Note that SNEqr only supports standard 4-button gamepads and joysticks, and will not work with other controllers in their "native" configuration (the Gamepad Pro, for example, needs to have a switch on the back set to "i", the 1-player mode.)
To individually assign a SNES joypad key, click the button box you want to set up and then press the new key.
Navigating through the Graphical User Interface:
The GUI controls can be selected with the keyboard as well as the mouse.
In most windows you can change controls by pressing up and down; in all
windows, you can use tab to change controls. You can use left and
right to change the
value of slider controls and space/Enter to 'click' something.
Press F6 to change the active window.
In-game keys:
While playing, there are several "shortcut" keys you can use. Here is a complete list.
F1 to F3, or '1' to '4': Toggle BGs
F4: Toggle FPS display
F5: Save instant save file to the current slot.
Note! Instant save files are quite large.
F7: Load instant save file from the current slot.
F6: "Panic Key": Restore all BGs and Sprites
F8 or '5': Toggle sprites
F9: Enter/exit debugger
Alt+number key: Select current instant save slot. (Default: 0)
+/- : increase/decrease frame skip/auto regulation speed.
2.3 Command-Line arguments:
This emulator is designed to be the one with the best looking, most versatile and useful interface out there. Most all options can be set through the GUI. However, it does have some command-line arguments:
Some settings, such as the GUI resolution are "Global". This means that the setting is the same no matter what ROM is loaded. Other settings can be individually changed for each game. When you load a game that you've never loaded before, default settings are assigned to that game. If you are a techie type (like me!) and want to change the defaults, simply edit the SNEQR.CFG file; go to the [Defaults] section, and change the values of the fields that follow to your liking.
2.5 Options
2.5.1 In the "Startup Options" dialog:
The top set of options ("Auto", "HiROM", "LoROM") controls the memory mapping. After changing this option, you may have to reload the ROM from disk.
The next row controls the country emulation. "Auto" will usually work fine. If NTSC is selected, the emulator will consider 60 frames per second to be the optimal speed. If PAL is selected, 50 FPS will be the optimal speed and more CPU cycles will be given per frame.
Interleaved format is unselectable until I get information on this format. Once selected, you will need to reload the ROM from disk.
The radio buttons Emulate sound processor and Skip SPC go together, and select whether you want to emulate the SNES's sound unit. It is unselectable because no SPC emulation is implemented. Further, although the sound rate and "Stereo" selections can be changed, they have no effect. The SPC skip method, however, is an important option. If a ROM stops working (freezes) or won't start, this is an option you may want to change. Method 0 works in most cases; Method 1 is slow and may cause ROMs to freeze for periods of time.
2.5.2 In the "In-Game Options" dialog:
If you choose "Auto-regulate", SNEqr will maintain a constant execution
speed by altering the frame skip rate dynamically. When the slider
underneath is set to 100% (normal), games will run at the same speed as
they would on a real SNES (albeit possibly less smoothly.) However,
if your computer is too slow, it may not be possible to maintain the speed
you
choose regardless of the slider's setting. On the other hand,
if your computer is too fast for the setting you've chosen, SNEqr will
create delays to slow down emulation.
If you choose "Skip Frames", SNEqr will not regulate the speed. Instead, it will skip drawing a certain number of frames for every frame rendered. For example, if the frame skip rate is set to 2, SNEqr will not draw two frames for every frame that is drawn. A higher value results in a higher speed, but motion will become more "jerky".
Amount of CPU cycles to execute: This should normally be set to 100%. A small decrease in this value is safe for MOST games, and can result in a slight speedup of emulation. A value over 100% is usually safe also, but there is very little reason to use a value higher than 100%.
Resolution: The fastest resolution to use is 256x256, but some monitors don't support it. 320x200 is also fast, but this resolution distorts the SNES image. 320x240 is the best resolution to use if 256x256 doesn't work.
BGs and Sprites: These are the "layers" of SNES graphics; most of the time, all five options should be enabled. Turning BGs off is sometimes necessary to see layers hidden because of imperfect graphics emulation.
2.5.3 In the "Load/Save" dialog:
Load/Save slots: When playing, you can save the exact state of a game and then continue where you left off at a later time. Simply click "Save" on one of the slots, and when you want to start where you left off, click "Load" for the same slot. You can also save during the game by pressing F5, and load using F7.
Auto-backtrack: This option is designed as a comforter for compulsive instant-save users. When enabled, SNEqr automatically takes "snapshots" of the SNES state and stores them in memory. If you make a serious mistake while playing, you simply hit F10 and it will take you back in time to the last time SNEqr saved your game. You can select the interval at which SNEqr saves the game, and also the maximum number of saved games to store. When more than one game is chosen, you can hit F10 multiple times to keep going further back in time.
When you hit F10, the last "checkpoint" is loaded, but that checkpoint is still stored in memory. If you hit F10 twice in a row (that is, hit F10 less than one second after you hit it the first time), the last checkpoint is deleted from memory and the previous file is loaded. If you want to go back to the same point, you must wait more than one second before pressing F10 again.
Remember: With auto-backtrack, you may only go back! If you hit F10 too many times, there is no way to go forward again.
Directories: You can type in a directory to load/save your SRAM files and instant save (*.QS?) files. The SRAM files are normal Save RAM files, which games such as Zelda have right on the cartridge when you save your game. With SRAM files, you can share saved games between emulators. If you leave these lines empty, the SRAM and QS? files will be put in the same directory as the SNEqr .EXE file.
Disable F5/F7: Another convenience for compulsive instant savers: this prevents you from using the Instant Save/Load hotkeys! It's an easy way to break a nasty habit.
Save/Reload SRAM: When SNEqr exits, or you load a new game, the SRAM is loaded or saved automatically. This is a way to do it manually, whenever you want.
2.5.4 In the "GUI Settings" dialog:
Color sets and the six buttons underneath: These provide a way to totally customize the color scheme of SNEqr. Just for fun, six predefined color schemes are included. The color scheme is saved automatically on exit.
The other options are self-explanatory; feel free to experiment....
2.6 Cheating
2.6.1 With Game Genie codes
SNEqr supports Game Genie codes (Note: the feature has not been fully tested.) Simply type the code into the "New Code" box, a description into the box below, and click "Add". Double-click on the code when it is in the code list to toggle it (There will be a '*' next to codes that are in effect.)
2.6.2 Creating your own cheat codes: four long steps
This feature is not intended for novice users, but those who want to take the plunge may try. SNES games store certain variables at certain locations in memory, and this feature is designed to help you search for those locations so that you can modify them. It is easiest to find the location of game variables that are displayed numerically on the screen. For example, things like number of lives, number of gold pieces, etc. can be found using SNEqr's cheat searcher.
1. Once you've started a game, decide on the variable you want to find, look at the current value of that variable, and go into the GUI and type it into the "Look for" field. For example, if you are playing Mario World and you want to find where the number of lives are stored, see how many lives you have right now and type it into the "Look For" field. At this time, it is often a good idea to have "Find Near" enabled. "Find Near" will look for numbers near the one you select. For example, if you have three lives, it will also look for the numbers 2 and 4. The reason you might want to do this is because some games store the number as one more or one less than what is actually displayed on the screen. The next thing you need to decide is whether to click "Find Byte" or "Find Word". Click Find Byte if you are looking for small numbers (below 255) and Find Word for larger numbers* (such as the number of rupees in Zelda, which can go up to 999.) Finally, click on "Reset & Find All". This will search the SNES's memory for the number you want.
Note: You can only search for integers.
* To those familiar with the SNES9X cheat searchers: SNES9X is only capable of finding bytes.
2. Usually, especially when searching for bytes, you will find hundreds or even thousands of matches. If, however, less than four numbers are found, skip to step 3. Otherwise, you need to narrow the search further. To do this, go back into the game and CHANGE the variable you're looking for. For example, when looking for number of lives, you can either die or get an extra life. Then return to the GUI, type the new number in the "Look For" field, and click "Search Again". Note: If you make a mistake and type in the wrong number, you will have to start all over from the beginning. Continue changing the variable and searching for it until the number of matches is narrowed down to three or less.
If you do a search and get zero matches, there are two possibilities: either you made a mistake somewhere typing in the number, or the SNES game is storing the number in an unusual way which can't be easily searched for using the cheat searcher. In the latter case, you are probably out of luck.
3. When you have two or three possibilities left, you should try changing the variable and searching one more time to see if you can narrow down the search further. If you still can't narrow it down to one possibility, the game is probably storing duplicates of the variable in different places. Only one of the locations listed is valid, but it is okay to make codes out of the other locations too.
4. Once you've found the location of the variable, type in a value you want to keep it at in the "Set to" box. For example, if you have found the "number of lives" variable, whatever number you type in this box will be assigned to that variable. For each code you want to make, click on its button (one of the six buttons at the bottom of the window). The finished code will be copied to the "New Code" box. Next, type in a description. Finally, click "Add" and enable the code. Now you're done! Return to the game to see if it worked.
2.6.3 Using cheat codes from SNES9X
Cheat codes found using SNES9X's searcher can also be used with SNEqr. Put the memory location in the New Code box, put an equals, and then the value (converted to hex) you want to keep the memory set to. For example, if you'd found "$7E1234" in SNES9X, and wanted to keep it constant at 11, you would type the code in as 7E1234=0B. Note that the value on the right must be two hex digits.
2.6.4 Using GoldFinger codes
To convert from a Goldfinger to SNEqr cheat code, simply append an equals sign, and move the leftmost two digits to the right side of the code. For example, the code "697E1234" would be changed to "7E1234=69".
2.7 Using the debugger
Like zSNES, SNEqr has an integrated debugger, which is not intended for use by anybody but some really brainy programmers. You can enter it by holding shift as you click on "Return to Game". The default debugger screen shows several counters and the register state before each instruction is executed. You can trace by pressing Enter, and red color coding indicates which registers were changed by the instruction. The interface is based on a command-line: you enter one- or two-letter commands followed by their parameters. For example, you can do a 65816 memory dump starting at the ROM address space by typing M$8000. ($ for hex, default is always decimal.) Type ? on a blank line for a brief command list. Not all the commands are listed or fully explained for space reasons, and I won't go over them all here either. Here are some useful commands:
3.1 Known bugs and limitations
(other than the biggies, which are covered in section 1.5, "Big Limitations".) The emulator has some bugs that prevent it from running all games. Eventually, hopefully, I'll weed them out. But for now, many games don't work.
Specific problems:
Wraparound problems: When a reference is made that crosses a bank boundary,
often the wraparound does NOT occur. Some wraparounds are implemented
(e.g. stack decrement), but most are not (e.g. pushing a word onto the
stack with one byte at 0 and the other at 0xFFFF, will screw up, and so
will doing a relative long BRL across a bank boundary).
Memory-mapped I/O problems: All memory accesses are supposed to be
trapped for full emulation, but for simplicity and speed, many accesses
are NOT trapped. Here's a list of known non-traps: PC - opcode+data
fetches are not intercepted
S - Stack operations (PUSH and PULL) are not intercepted (although
stack relative operations are.)
Indirection - The final address resulting from an indirection is intercepted,
but the pointer variable itself is not. e.g.: LDA ($2140) This cannot
trigger the APU skip mechanism. But, if this is used: LDA (<$0)
and $0 contains: $40 $21 then the APU skip will occur.
Indirect jump: Indirect jumps are not intercepted.
FastROM handling is a bit iffy
SRAM: The header information is NOT checked for SRAM size, and reads/writes
are NOT intercepted - a game can always read and write to the full 512
kbits of SRAM address space.
Invalid addresses: I can't IMAGINE what will happen if you try to access
an invalid address (GPF probably...)
Debugger problems: You should only attempt to view one memory area
at a time. For example, you shouldn't try to look at the place where
the register address space meets up with the scratchpad memory space (e.g.
M$1FF0)
If you're an emu author and know where one of these limitations could cause problems in an actual game, please notify me of the how's and where's of it.
3.2 Ways to make a ROM work
1. ROM Type
There are two basic types of ROMs: HiROM and LoROM. HiROM is
a strange format which is not fully implemented, while LoROM works perfectly
as far as I know.
It is difficult for an emulator to figure out whether a ROM is the Hi or Lo type, because in the actual cart it is a hardware signal that is not contained in the ROM file (once in a while it's contained in the header, which is ignored since there are different types of headers...)
Sometimes SNEqr makes a mistake in figuring it out. If, when you go to load the ROM in the GUI, the title of the game is not shown, try clicking on "Force HiROM" or "Force LoROM". Here's a tip: a large ROM file (3 MB or more) is usually HiROM, while a small ROM (2 MB or smaller) is usually LoROM.
2. Country Code
Some ROMs, which have defective ROM headers, are not detected properly
as NTSC or PAL games. Under Startup Options, choose "Force PAL" or
"Force NTSC" to correct the problem.
3. SPC Skip
When sound emulation is disabled, some ROMs freeze or crash.
You may be able to stop this problem by changing the SPC Skip method, in
Startup Options.
4. CPU cycles
Normally, the 65c816 CPU cycles option should be set to 100%, but a
ROM may work better with a higher value. (Note! zSNES's 100% value seems
to be equivalent to about 90% in SNEqr.)
5. BGs off
Unfortunately the layering of the SNES screen isn't always right.
You may have to toggle the BGs (F1 to F4) to see the one you want to look
at.
6. Add a SMC header
SMC, the extension on most ROM images, stands for "Super MagiComm",
and is a standard console copier format. This format includes a 512-byte
header at the very beginning of the file. SNEqr ignores this header,
since it is a different format for other types of copiers. However,
it is ASSUMED to be present. If there is no header, the file will
be loaded incorrectly. If a file has a header, it will have a remainder
of 512 when divided by 1024. Conversely, a file without a header is usually
evenly divisible by 1024 (1 KB). If you find this to be the case,
you need a third-party program (such
as a hex editor) to add a header before SNEqr will recognize the image.
If the remainder is neither 0 nor 512, the ROM is probably corrupt or incomplete, and you have little hope of getting it to work no matter what.
3.3 Ways to speed up or increase smoothness of emulation
1. Skip frames
If you are having problems attaining 100% SNES speed, raise the frame
skip. The level of "jumpiness" will increase exponentially, but it
will run faster.
If you are running a ROM on a VERY fast computer (e.g. Pentium II), you will get best (smoothest) results if you enable the option "Wait for retrace", enable "Skip Frames" and set the number of skipped frames to zero.
2. CPU cycles
Often, ROMs will run faster if you set the "Amount of CPU cycles to
execute: 65c816" value lower than 100%. There are two problems with
this, however:
1. Many games will become unstable, and crash at certain points.
2. Most action games will actually slow down more easily--that is,
the game
speed will halve when only a few enemies get on
the screen.
3. Graphics Speedup
May increase graphics speed, but also may screw up your screen.
(This option is not implemented yet though.)
4. Color add-subtract
For maximum speed, this should be off (It's not implemented anyway)
5. BGs off
Scrolling parallax backgrounds and such slow down the emulator.
If you turn off game backgrounds, the game will run faster. Press
F6 during the game to turn all BGs back on.
6. Resolution
Make sure the resolution is set to 256x256 or 320x200 for maximum speed.
Note that using 320x200 will make the game screen look a bit weird.
3.4 When SNEqr won't start properly
4.1 Why emulators are SO SLOW!
People are always complaining about the high system requirements of emulators, so I may as well explain it to the world right here. First of all, why does it take so much CPU time (about 50 MHz on a 6x86) to emulate a mere 2.6 Mhz processor?
Well, bend your mind for a moment and think of a video game as being
an emulator. That's right. Think about it: whenever you are
playing an action game (say, DOOM) on your computer, it is trying to emulate
portions of the
real world. The screen on which you see the 3-D image, for example,
is emulating your eyeballs. Further, your life meter is 'emulating' gunshot
wounds. And your sound card emulates the scream you would make when
you get shot. Notice, however, that in order to do all this stuff
in real time, DOOM hardly simulates even the smallest fraction of the physics
model of the real world. This is because, whereas real physics happen
automatically and instantaneously, everything that happens in a computer
has to be processed and calculated before it happens.
And so it is with emulation of a console system. Unlike a game, however, an emulator cannot just emulate a small fraction of the system and expect a game to work well. Every little instruction from the system being emulated must be indexed, then loaded, read-trapped, processed, calculated, write-trapped, have the flags checked, and finally have its cycles and bytes counted. Depending on how well the emulator is optimized, I believe it can take 10-25 6x86 cycles for each SNES cycle to be emulated. (I don't know about the number of cycles used on a Pentium, since I have a Cyrix 6x86.)
Of course, there's much more to the SNES than its CPU. Its graphics
system was not only very powerful for its time, it's also very, VERY different
from the PC's graphics. Whenever a SNES frame needs to be rendered,
a complicated
process must be used to translate the SNES graphics representation
to a PC screen. All modern emulators speed up this process, however,
by optimizing heavily, and caching translated tiles and tile maps.
Finally, the SNES has a second CPU, which is very different from the main processor, to do its sound. Plus, the DSP is relatively powerful. That's why enabling sound in a SNES emulator can make such a drastic performance hit.
Some games even have extra on-cart chips such as the Super FX.
Some emulators are coming out with Super FX support; unfortunately, it
slows down the emulators further because I think the Super FX is a 10-20
MHz RISC chip (this
would make it a third CPU).
4.2 About dynamic recompilation
I would now like to say a few words about code recompilation. J. Turner, the EPR guy, was once wondering, "Why can't you just take the ROM image and just TRANSLATE it into a native PC game?" Well, it's rather hard to explain. If you really want to know why, become a programmer and study the SNES and the PC for a few years... eventually, the reasoning will hit you like a ton of bricks.
However, there is another technique I've come up with (and a lot of others, such as the author of Project Unreality), which I call PARTIAL DYNAMIC RECOMPILATION, that can be used to speed the CPU emulation. If anyone wants an explanation of this, I can write one up. Its advantage is obvious: speed. It will emulate stuff blazing fast; I estimate each 65816 cycle will average only five (maybe less!) Pentium cycles. But there is one primary problem with it, which has prevented any emu author from doing it before: Time and Work (these two terms are pretty much the same to us programmers.) It is a massive project that requires an intricate knowledge of both the 65816 and the x86. Naturally, it is not portable to any other architecture. Finally, it does not work in all cases (e.g. when the game uses SELF-MODIFYING CODE.) It's a little bit like compiling bitmaps, but a lot more involved...
People working on the next-generation emulators, such as PSEmu and Project Unreality, are currently planning to use this technique in future versions of their emulators; however, as zsKnight (of zSNES fame) mentions in his FAQ, it's not really worth using dynamic recompilation for a 3 MHz processor; besides, on the SNES, it's the SCREEN rendering rather than the CPU that uses the most CPU time.
By the way, some of you may have seen an old emulator based on NESA called "NES-Lord". This took a .NES ROM file and spit out a .EXE file that would run the game. Hehe. No, that did NOT translate NES games to PC games. It operated similarly to one of those "self-extracting" .zip files. It was just a normal emulator, with a ROM file tacked on the end of it. Neat, eh?
5.1 Version History
Numbering system: Most apps number their programs starting at 1.0. In the emulator world, however, it is customary to approach the magic '1.0' as being 'totally complete, full emulation'. Of course, no emulator ever manages it... although, somewhat by accident, some emulators do exceed 1 and others never get close, even though their emulation may be pretty darn good.
0.340
If you are interested in writing a SNES emulator--and I know there's
always somebody out there who wants to--check out my SNES Knowledge Base,
which should be linked to from my Emulator's home page. As well as
having the info available at other tech sites, it has a lot of Q&A
logs and is guaranteed to be the most complete doc out there. You
can also probably find on my site a graphics doc that I wrote--as far as
I know, the most complete one in existence besides Nintendo's own secret
"programmer's manual". Writing a SNES emulator is made difficult
by Nintendo's refusal to give info; they won't even release info about
their long dead system, the NES! So I wrote this document which contains
most of the stuff other emu authors have told me, and what I've managed
to figure out.... the address ought to be:
http://www.sixtyfour.com/qwertie/snesbase
BTW: If you want to use my "quick save state" instant save format,
contact me. The file format is fairly simple and non-emulator-specific,
except for one part of it.... Anyway, I've always wanted a common save
state format for SNES emulators, and maybe YOU could help that dream come
true.
5.3 Author Credits
What
By Whom
-------------------------------- -------
Low-level Graphics interface Qwertie
SNES Graphics Rendering routines Qwertie
Debugger (Shift+Return to Game) Qwertie
65c816 Emulation Core
Qwertie
Graphical User Interface
Qwertie
File Manager
Qwertie
Timer(PIT), Keyboard, Mouse
...Take a wild guess, would you?
5.4 Contacting the author
The WWW home page for SNEqr is hopefully:
http://www.sixtyfour.com/qwertie/sneqr
5.5 Special Thanks To
Many thanks go to the following people for their assistance:
# of Thank-yous Whozit
--------------- ------
*************** All those on the SNES9X team who decided to take
the plunge...
and release the SNES9X source code!
************ zsKnight - Great guy, thanks for
all the tech info!! But can
you please give me some more???
*********** Jason G. - Got lots of help
from this guy early on, THANKS A
LOT D00D! e-mail me some time eh? Are you still doing an emu?
********** Y0shi - I don't think
we've met, but your docs were useful...
if not entirely accurate!! Hint hint!!!
********* scart - This guy
figured he was gonna be my partner on this emu,
make a nifty dynamic 65816 recompilation algorithm, ETC... but
NOOoOoOo... then he decided he would rather get a stupid
university degree instead of write a SNES emu. Can you believe
that?!?!?!?
******** _Demo_ - little
bits of info from him
****** Jonathan
Turner - runs the excellent tech site, EPR. (Iz that
speled right?)
****
MrGrim - now I know where the nickname comes from ;^)
****
Duncanthrax - IF that's your REAL NAME!
****
Simkin - Dunno who you are, but nice memory map doc. Too bad
it left out some IMPORTANT DETAILS!
5.6 GREETZ!
Nuxx (how's the army life going?), Amberion (Got his #emuroms ops taken away, just like poor me), RelliK (Who are you bossing around these days?), Herbman (Looks like you're catching the op disease... I- can- ban -you -so -don't -say -anything -I -don't -like"), Marat F***ullin to pir8 iNES.7r, or not to pir8...that is the question), the #coders, [NOAM], XxDethxX (I forgot who you are, but... cool name!), LordEsnes and Nerlaska (What? MORE COMPETITION?) Trepalium (Cantcha put more comments in your code?), MindRape (you're the only one I REFUSE to give my source code to), all those other people that I didn't have time to meet because I was writing this, and scart (again!). Oh yeah, and CEB (was my resume good enough?)
plus, Richard Mui, Dan whats-his-name, Clay Hellman, and Caleb Sunstrum.
EGAD! I just listed everyone I know, like in the whole world!
Oh yeah... HI MOM!
| This version dedicated to Linda Romero (Piepgrass) | |
| Wife • Mother • Sister • Daughter | 1968 • 1998 |