To Do: cannot load other game and have another sequencer... feedback from and to goggle -Fix that darn integration inaccuracy -Do that joystick thing Keith send me -further speed optimaziation -look if I get the 3d stuff to work... -any other idea? -perhaps a port to windows??? (directX) 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 *********************************************************************