Note emulation is not complete.
And I probably won't do any more stuff to it.

There are a couple of defines, which produce different emulator versions.

One crucial part is 'anatick.cc', this is where the analog hardware of
vectrex is emulated. Right now, if you switch on anti aliased lines,
there is a constant EMU_FULL_ANALOG declared. This enables some 'more'
analog features, like DRIFTs, integrator offsets (slow going) and DAC offsets.
The drifts include X, Y and Z drifts. The feature is still in test stadium,
so no 100% results can be expected, though some vectrex 'features' can be
examined with it. Note: DAC offsets can be changed online, while GUI is
enabled (and aa) with the keypad +,- keys. Integrator offsets can be changed
online, while in GUI with SHIFT cursor keys. The drifts (X, Y) can be changed
online using CTRL cursor keys. Reset these things to zero with SHIFT END.

If a global constant is set (in the makefile preferable) PATCH_OFFSET,
than the things that desturbs games like cleansweep is patched, that it
works fine. Note: this is no exact emulation, it is a 6522 patch, that
get's correct results, for what this does look in emu6522.c.

Another global constant can be set (though preferable not at the same time
as the above mentioned) ANALOG_CYCLE_PATCH.
I suspect that some control lines are not updated at the same cycle as
VIA. Original emulation had it, that for example BLANK is exactly the
VIA output (control line t6522CB2). I suspect, that the analog hardware
recieves the BLANK impulse some cycles later. I further suspect that
these lines have different 'delays'. With the above option some form
of delay can be enabled for a certain number of analog lines.
For information look in emu6522.h, emu6522.c, pia.cc.
In order for this to work somewhat correctly the option
FORCE_SINGLE_PROCESSOR must be enabled in the ini file.
Note the maximum queue for updates is defined as 5 now, so don't delay for
to long, otherwise the system WILL crash.
The delay values can be changed online, while in GUI with
following keys:
'c'+ -DAC
'z'+ -ZERO
'h'+ -SAMPLE-HOLD
'r'+ -RAMP
'b'+ -BLANK

'C'- -DAC
'Z'- -ZERO
'H'- -SAMPLE-HOLD
'R'- -RAMP
'B'- -BLANK

Some aspects not otherwise correctly emulated can be observed while fiddling
with the above settings. But I think the above things are not all that need
be emulated. For example writting to VIA also has some delay of sometimes
1, 1.5, 2 cycles. In some really time critical situations this IS important,
but as yet not emulated. (I encountered situations like this, while
optimizing Vectrex Frogger)

One other thing not emulated is the correct zeroing. Zeroing is
done at once, the real vectrex takes it's time zeroing (in a e-function
style).

And another... Though it is right that 6809 only reacts to interrupts when it
is in a fetch cycle, the vectrex hardware certainly reacts when the interrupt
occurs, EXACTLY, even half a cycle is possible, since VIA has an
offset, delay of sometimes half a cylce. Some analog lines (mentioned above)
are updated by a VIA interrupt (PB7=RAMP), if that happens, we have again
some inaccuracy!


Imager games.
Though they look like they work correctly (some), this is not
yet fully emulated either. While probably no cycle exact emulation is needed,
as with the analog hardware, there are still some traps.
(btw, the PSG output/input could be done with the cycle delay stuff mentioned
above also)
When I optimzed Keith's original source, we thought that interrupts could only
be made by VIA, through timers or shifts. This is not TRUE.
Lightpen, and 3D imager can both produce interrupts. Both joypads can
produce interrupts as a matter of fact, but only the one from the second
is really interesting.
While not in FORCE_SINGLE_PROCESSOR mode, some interrupts can thus be missed.
(only with the imager, lightpen is 'patched ok').
For narrow escape everything seems to be fine as it is, but especially
3d MineStorm has problems displaying correctly without FORCE_SINGLE_PROCESSOR.
Note further, I have not exactly translated the pulse width into
cycles needed, I just guessed. So if you intend to write your own 3D game,
you better have a vectrex and a 3d imager handy, since other values than the
ones used by the 3 available games are only guess work.
(see sound.c for the guessed values)

(bGblForceSingleProcessor can be toggled in GUI with CTRL F)

Overall I must admitt, that the source looks really awfull. I have not
commented much, and the different inlinings at places really suck.
It is everything but intuitive and readable.

Most includes found in the code can be replaced by function calls, I thought
at a time that there would be a significant speed improvement (which it was),
but nowadays with fast computers it is not all that neccessary anymore, but
still confusingly inserted in the code.

DVE emulates MANY aspects now of a real vectrex, but not everything. I planned
that sooner or later DVE could be used as a development system, but now I
realize, that without rewriting it from the bottom and slowing it down
significantly (since I wouldn't be doing it in assembler), no such thing
would be possible. I won't rewrite the emulator from scratch, it is just
too boring to do stuff again. Thus emulation is incomplete and will remain
incomplete until another picks it up (though I doubt it).

This release is probably my last, sadly incomplete, and slower as intended.
Actually right now I really can not be bothered to go on optimizing stuff.

The executable is compiled with optimization enabled, with PATCH_OFFSET
enabled and ANALOG_CYCLE_PATCH disabled.

Note:
The GUI thing is also far from complete, you'll notice soon enough.
Originally I planned to add a couple of more settings and
capabilities, but somehow I got too bored.
But: You can at least new games to the GUI thing if you want without
recompilation, just look at vgames.hlf, this file describes
the help file, that show when the GAME button is pressed, if you
do the same for your 'new' games, as is done for the others,
you shouldn't have difficulties to add your own to the menu.

Same applies to the whole help file system!

NOTE:!!!
The program has somehow difficulties with different compiler
optimization switches.
If I use the full optimizing switches, than random chrashed occur!!!
Therefor only partly optimzed versions are distributed!


Note: there are difficulties with ATI MACH 64 VESA cards.
These are the only cards which have problems with my VESA routines.
I don't as yet know why that is. The problem can be partly solved by
aquiring the newest VESA driver at ATI and fiddling with the settings.

:a run the M64VBE.COM with "vga" option to disable accelerated VGA CRT
settings

b: only in display_mode 0 (640x480 that is)