This is the source code distribution for Atari800Win, an Atari 8-bit emulator
for Win32 systems. The executable is not included in this archive; if you are
looking for that instead, head to http://www.cris.com/~Twist/atari800win and
download the latest version.

No attempt has been made here to support anything but a Visual C++ 6.X 
environment. There is an exported makefile; but it assumes NMAKE and other
Visual C utilities. If folks want to create makefiles for other compile systems,
great - please forward them to me for inclusion into the archive.

Atari800Win is actually an MFC application. This was done to make various user
interface design and implementation faster; the one commodity I do not have to 
spare is time, and so saving it is important to me. However please note that
the requirement to support a large legacy code base written in C precluded 
Atari800Win ever being remotely object oriented. There is much ugly sharing of
variables across modules; from C to C++, etc. This is the reality of having to
port something instead of rewrite it; I make no further excuses. It works.

Most of the original source code for the Atari800 project is included verbatim.
It is located in the "Atari800Src" directory and is regularly updated by a team
of programmers who are working on it (including me). The homepage for that
effort is http://cas3.zlin.vutbr.cz/~stehlik/a800.htm.

In addition the Win_C directory has C modules that have most of the hardware
dependent requirements for Windows; graphics, sound, and the like. In most
other ports of Atari800 this would be a single file included in the main
archive; the Windows version gives a wider variety of options and so it was
prudent to break these up into applicable modules.

The final section of source is the Win_CPP directory; it contains "classes"
(which for already mentioned reasons aren't really objects) required to
handle the various user interface work.

This source code is very much a work in progress; it changes currently every 
few weeks or so, either from modifications to the underlying Atari800 layer or
changes in the Windows code itself. Also, being a largely personal project, I
have not commented very well; I will go back and clear this up as I get time,
but for now most comments are pretty sparse. If there are questions that can 
reasonably be answered (not "how does DirectX work?" for instance - there are
books for that :-) ) you can e-mail me and ask why I did this or that using
rich@kesmai.com. I get a LOT of e-mail and I have a very full time real job,
so please be patient.

A few compile-time defines and what they mean:

UNALIGNED_LONG_OK - The processor can access memory on non-word aligned 
boundaries. True for all Intel makes; NOT true for most everything else.

POKEY_UPDATE - Regularly update the pokey routines instead of using a DMA 
interrupt. Set to on because there ARE no interrupts in Win32.

USE_PERF_COUNTER - Uses QueryPerformanceCounter() instead of timeGetTime().
Generally faster, but requires a lot more code to watch for rollovers. 

USE_FLIP_BUFFER - Causes the display routine to double-buffer and pageflip.
Currently much slower than the simple blit from system to video ram that is
the default.

USE_DSOUND - enables DirectSound code. Should work but hasn't been turned on
in a while; DirectSound was a wildly inconsistent performer for the user base
and didn't always work, whereas the current Multimedia layer sound work fine.