tuxnes-dc v0.1
--------------

tuxnes-dc is a port of TuxNES (tuxnes.sourceforge.net) to the Sega Dreamcast.
This version is based off v0.75 CVS as of 2001-07-18, although I don't believe
anything has changed since then.

The significant changes for the Dreamcast port are:
- Obviously, works on Dreamcast hardware.
- Cheesy game select screen.
- Renderer will only draw full scanlines.  The original could
  draw partial scanlines (even one pixel) if video registers
  were updated mid-line.  This renderer delays register updates 
  until the next line, preventing the render loop from being called
  several times in the same scanline and simplifying the loop code.
  We trade the ability to track the color emphasis bits precisely
  for a big speedup.  (TuxNES does not support color emphasis anyway.)
- Renderer draws eight pixels (one tile) per loop iteration,
  rather than one pixel.  This provides a significant speedup,
  and again simplifies the loop code greatly.
- MMC2/4 latching disabled due to speed issues; this affects
  e.g. Punch-Out.
- 6502 emulation core is C-based and interpreted, not dynamically
  recompiled.

Changes not really visible to the end-user:
- Sound code abstracted to allow multiple sound engines, just like
  the rendering code allows multiple rendering engines.  "mute" and
  "none" sound options are cleaner than in the original.

Current status:
- Almost all games work at 30FPS.  In fact, the renderer is 
  artificially locked to 30FPS (frameskip = 1).  The sound code 
  currently imposes this constraint.
- Without sound, I benchmarked between 50-60 FPS on most games.
  This is a far cry from the 12 FPS I was getting when I first ported
  the thing ;)  You can disable sound, vsync and frameskip to
  achieve these speeds, but you have to dig in the code to do it for now.
- Sound works well, but is subject to some artifacts.  If game speed
  drops below 30FPS, sound will break up.
- Save games are implemented, but you need dcload and a PC to take
  advantage.  I.e., vmu saving is not supported.  Or, at least, I
  haven't tried it.  Provided KOS gets a stable vmufs, you can try
  setting your save directory to "/vmu/".

Despite the "buts", it's pretty fun to play.

Installation from binary distribution:
1 Untar the source file (creates directory tuxnes-dc-0.1-bin/).
2 Create a directory ng/ under tuxnes-dc-0.1-bin/cd/ and dump your ROMs in it.
3 Burn tuxnes-dc-0.1-bin/cd/ to CD the standard way (cdrecord, mkisofs).  
  I recommend specifying the -r option (Rock Ridge extensions) to mkisofs 
  to preserve ROM filename case.

I assume you have experience burning Dreamcast CD-Rs.  The binary distribution
is released 1) as a test, to verify that I CAN create a binary distribution;
and 2) to provide a benchmark that shows the best speed I've attained, since
different gcc versions and small irrelevant code tweaks can cause wide
variations in performance.  (I have a funny story about this.)
Mainly, I wanted to make the source available to the community.
So, unless I screwed up somewhere, I won't assist with burning problems.
Ask your doctor about those.

Installation from source (tested with KOS 1.1.4 and gcc-20010312):
1 Untar the source file.
2 Set up your usual KOS environment.  I've provided the file that 
  I source, environ-dc.sh.
3 Tweak Makefiles if desired *
4 "make" (or "make bin" for scrambled 1ST_READ.BIN)

* Typical tweakable variables in the Makefiles:
  ROMDIR   - your rom directory 
  SAVDIR   - your save directory ("/pc" filesystem requires dcload)
  SCRAMBLE - path to scramble, if you want to create 1ST_READ.BIN
  BIN2C    - (in dc-aica/) path to bin2c, should be included with KOS

You can upload the resulting .elf file, tuxnes-dc, with dcload or
burn 1ST_READ.BIN to CD.

Operation:
- At the game select screen, A selects game, B+START quits.
- During emulation:
  DC         Nintendo
  A       -> A
  X       -> B
  Y       -> SELECT
  START   -> START
  B+START -> return to game select
- Save ram is automatically written out to filename.sav when you 
  return to the game select menu with B+START.

Jim Ursetto
jim@3e8.org (http://3e8.org)