DOS Vectrex Emulator (DVE V1.20d) - SOURCE CODE (what chris has done to it)
----------------------------------------------

Needed now: SVGALIB 6.0 from scitech


http://www.scitechsoft.com
ftp://ftp.scitechsoft.com/devel/svbase60.exe
ftp://ftp.scitechsoft.com/devel/svsrc60.exe
ftp://ftp.scitechsoft.com/devel/svdem60.exe


in case you want to use pmodew with it:

http://www.dorsai.org/~daredevi/pmw/pmw124.zip
http://www.dorsai.org/~daredevi/pmw/
http://www.di.net/pmw



Ugh, ah...
This has gone thru my hands and it has taken definitly a step towards
the worse. (Chris)

Sorry guys, source is not all that well readable anymore.

In order to squeeze some speed out of the code without actually having
to rewrite to much, I heavily used 'inline' functions.

And I heartly broke up functions to save some 'if...then...else' clauses which
would have popped up every other micro second.

What I mean with 'inline':

'C' doesn't usually support inline functions, so I had to come up with
something similar. Lucky me there is such a thing as a preprocessor...
So I #included all 'functions' at the point where they were required.
One could even take back the inlining by just replacing the #include
with the actual function call... This method gives a slight speed increase
and uses some more memory...
Actually Watcom compiler seems to be memory conscious to some extend...
'cause I was not able to 'inline' the analogTick... The compiler would
flatly refuse to compile... but then again who wants an *.exe 10 times
as large as neccessary for perhaps 1% speed increase...
All 'inline' #includes have the extension *.cc.

The other outragous thing I did was to use different functions for different
'user states' actually there are now somewhat in between 4 and 8
emulators packed in that *.exe file, one for Linear, one for banked
framebuffers... One with lightpen support, one without and so on...
I assign the functions to their 'historic' names at runtime... so at least
portions of the code would look the same.

The worst possible section you might look at is the sequencer.
The heart and the labyrinth.
You are going to have a hard time if you wanna know how that thing works.
Better look at Keiths original and then take some aspirins and
look what I have done to it...

Very much 'inlining'...


The original Idea how to speed up the sequencer came from Keith...
And I must admit that I'm rather proud of myself that I got it to work so
well.
Keith original scheme was simple:

    -one PIA tick (and if neccessary one analog tick)
    -one CPU tick
    -goto top

This was sort of time consuming, cause' pia doesn't allways do all that much.

His idea was this:
[...]

> ...any clue how further optimiziation of your emulator may be
> accomplished? What section is the most power hungry?

I did have some specific ideas. One of the
reasons its so slow is that every emulator loop checks the counter &
serial port status as they operate some of the vector hardware
independantly of the CPU. What I considered doing was:

IF (timer1_count > limit) AND (timer2_count > limit) AND (serial port inactive)
{
 Use CPU model with no peripheral checking and no loop so:
 cycle_count+=instuction cycle count
 timer1_count+=instruction cycle count
 timer2_count+=instruction cycle count
 }
 else
 {
  Use current single cycle CPU model checking peripherals every cycle
 }

 limit is set to max instruction cycle count + 1

So when the screen is inactive then we use a dumb CPU model that counts
cycles but doesn't execute the FETCH, WAIT, WAIT.... WAIT, EXECUTE model
round the loop, this should make things execute about 5x faster when the
hardware is not in use.
[...]

Actually 5x was far to much, about 10% at most... but a nice speed increase...
Actually the new model still looks like

[...] FETCH, WAIT, WAIT.... WAIT, EXECUTE [...]

But it really only does FETCH AND DECODE in one step... but this way it
looks similar to the old stuff.
You will see a nearly exact copy of the above IF clause in seq.cc, it
works great!

I do another test... if only shift activity is expected I use another
CPU model that will only 'activate' the pia shift stuff.
I tried a model with only T1 and only T2 and T1shift and T2shift...
But it was not worth the effort, so I droped that idea again...

Actually I replaced the old single CPU model with another
multi cpu model... since interrupts are only processed on
a cpu fetch cycle one could squeeze a little bit out of that fact...
I only had to make sure that Interrupts are not processed in any other Model
(T1 that is... uh, why...???)

Another dirty one is in io.c!

I added support for Hardware linear Framebuffer...
A big speed difference, especially when using 'enhanced_display'...
In the above case it gives a speed increase of sometime 30%-40%!!!
(Though I must admitt I could have optimized the banked framebuffer stuff
quit a bit more... but then again... my card has hardware linear framebuffer:-))

Lightpen (see the other doc...) I have not been able to set the bank within
the mouse interrupt handler, dunno why, so I use some kind of polling
technique, makes banked even slower :-( (I didn't try all that hard to get it
to work properly... it's banked you see...)

Some other odds and ends...
-changed the hashing function (Keiths was probably one of the worst he could
 come up with, first the size of the array of 1024 (a power of 2!) and second
 the function itself, sure it only uses ors plusses and ands, but it
 provides a range from 500 - 550 in 90% of all input (SHUDDER!))
 (Hey Keith don't take my babbling here to serious, it's in the nature of
  fixing that the old stuff is not seen in quite so bright a light!)
-Latch register in PIA timer 1 should only be put into counter when in
 free run mode (I think...)
-small stuff

-note: I did not translate a single line of 'c' to 'asm'!
-speed consideration: if linear framebuffer --- more than doubled!!!


If you got any questions regarding v1.20 ... just ask...

chrissalo@aol.com






DOS Vectrex Emulator (DVE V1.00) - SOURCE CODE
----------------------------------------------

Hi Folks,

A number of people have contacted me regarding ports of DVE to various
platforms. I debated putting DVE out as shareware for a while but the
idea of having to provide support kind of put me off. I said to most
people I'd consider releasing the source when V1.0 was finished. Well
here it is in its entirity.

If you wish to port DVE to another architecture then by all means have
a go. I don't mind answering serious questions about porting. Please
think your questions through before emailing. Bear in mind I never
designed DVE to be ported, a bad call on my part. I don't intend to
act as a coordinator for DVE further development, anarchy suits me
just fine. It would be nice to know if you are doing a port though.
I'll pass the information on to the UK/US home page authors for
inclusion.

I'm not particularly proud of the code, various bits have been hacked
off of other pet projects and kludged together. Some of the comments
may be misleading or wrong. The structure started out very nicely but
got compromised along the way. Most of it is pretty well commented.
If I had to do it all over again i'd probably do many things
differently but what the hell it works and is very stable even under
windows 95.

Please don't tell me about the bug in the keyboard buffer, I know
it acts like a stack rather than a fifo. I just can't be bothered
to fix it. You'll only ever see it if you type ahead when opening
the monitor window.

When I started the code I had some strange style ideas that seemed
elegant at the time. The worst is the letters in front of function
names & variables. Seemed like a good idea at the time but now I
find it intensly irritating. fDebug this iLoop that, yuck.

The makefile is in a pretty bad state, the header dependancies dont
work, it needs re-writing.

DVE is built with the PMODEW dos extended rather than DOS4GW, its
smaller and slightly faster. If you want to compile with DOS4GW
you'll need to change the linker section of the makefile.

I have my source tree organised in the following manner:

   vectrex
      object
      source

The make file relies on an environment variable called WBUILD, it
can either be DBG or REL for debug or release. I have included two
batch files that I use for setting WBUILD.

I've included the debugging version of DVE in with the source
release, press ALT-M to invoke the debugger. Type help for a list
of insructions.



Happy porting...............

Regards

Keith Wilkins



*********************************************************************

DVE source code is Copyright(c) 1994, 1995, 1996 by Keith Wilkins

This licence grants you the following:

Permission to use, copy, and distribute DVE in its entirety, for
non-commercial purposes, is hereby granted without fee, provided that
this license information and copyright notice appear in all copies.

If you redistribute DVE, the entire contents of this distribution
must be distributed.  The software may be modified for your own
purposes, but modified versions may NOT be distributed without prior
consent from Keith Wilkins.

This software is provided 'as-is', without any expressed or implied
warranty.  In no event will the author be held liable for any damages
arising from the use of this software.

If you would like to do something with DVE that this copyright
prohibits (such as distributing it with a commercial product, using
portions of the source in some other program, etc.), please contact
the author.

The author can be contacted via email at: kwilkins@nectech.co.uk

*********************************************************************



