One more defect added !

A new feature has just been added to ParaJVE : the emulation of the famous Vectrex buzz noise.

The happy few having the chance to own a real system will know what I'm talking about. This buzz noise is a very typical sound pattern produced by the machine when it is operating. It is caused by a design flaw (the sound line lies too close from the board, and gets plagued by interferences due to its nearby activity).

Well, the very first implementation is now completed, and it is quite straightforward at the moment (a mere noise sample looping). The buzz sound can be turned on/off (independently of the vectrex "normal" sound), and its volume can also be adjusted independently.

Below is a small video whose goal is to let you enjoy the audio result - the framerate is capped 10 FPS, so don't really expect a smooth video ;-)



As you can hear, the result is quite acceptable already. However, a more interesting implementation would be to dynamically modulate the PCM wave, depending on the current program activity. This would require quite a lot of investigations on a real vectrex, in order to define which hardware parameters are significant, and how they can be integrated into the final noise generation algorithm.

I'm not sure I can bide enough time to tackle this task ; still, this is very tantalizing...

2010 is nearly over

Yup, 2011 is rearing its ugly head...

Therefore, I hereby promise that the 0.7.0 version will be released by the end of 2010 -- no matter how and when I will manage to do this! :o)

It got stuck for too long on my hard disk now, it's time to share. Of course, the user-guide, various documentations as well as some minor other stuff won't be completed as I wanted them to be ; but in the end, I guess you won't care too much about that -- Heck, I don't even know if you will notice it at all, indeed. ;)

I'm currently reworking the download page, since so many people seem to encounter problems while unpacking the old ZIP archives with the newer windows OS - be it Vista or Win7, then it's ready.
By the way, here's a quick tip if you have this issue : instead of using the windows "integrated" unpacking facilities, just use a third party unpacker (like winzip, winrar or 7Zip) to unpack the ParaJVE builds ; it often solves the problem...

So stay tuned for a really really near release!

In the meantime, to let you wait it out, here is a snapshot of ParaJVE running George Pelonis' War Of The Robots game (with a 100% original overlay I have designed for this game) :

0.7.0 still not released? WTF !!!

All right, it's been 8 months since the last post has been published, and still no release showing up... So what's up, you might wonder?

Right, I haven't worked that much on the emulator these last months. Some kind of coding break. I even forgot about it at some point, to be honest ;-)
Only lately did I come back again to ParaJVE development, so the release is now back on tracks.

Bank-switching, the last feature I wanted to add to this release is now nearly completed.

The ParaJVE memory model has been modified to fully support cartridges with a ROM bigger than 32Kb. It basically means that the emulator can now load and execute dual-banked cartridge (64K rom images), but also emulates multi-banked cartridges (Richard Hutchinson's VecFlash and VecMulti cartridges, for a start).

As a proof of concept, here is a picture of ParaJVE running the awesome Lineart demo (a demo made of 4 different banks, stored on a VecFlash cartridge) :


As for the games packaging, Protector + YASI (by Alex Herbert), as well as some other homebrews, have been added to the list of embedded games. For YASI to be properly displayed, a special "interlaced" mode has been added to the emulator's rendering engine. This mode suits well to these "raster" games, that often display half of the lines per frame (odd lines, then even ones).

I also created an original overlay for YASI (heavily based on the original Space Invaders overlay). Here is the result :


Ok, so what now? Well, I'm currently in the process of updating the configuration file loader, to make it support multi-banked games definitions, as well as zipped ROM files. Testing & fixing regressions here and there also keep me somewhat busy...

And as usual, no release date planned yet ;) 

Beta 4 : some more coating...

After a break of one month without any coding, the 4th beta build has just been uploaded to the Beta Download site. The registered testers can get it right now, using their private key file.

This beta comes with a new graphic feature that should push the immersion a step further : the Vectrex chassis can now be drawn around the emulated screen.

This great idea came from Heiko L., a friendly beta-tester, who already helped a lot when it came to fix the problem with 64 bits native library deployment under Linux. Not only did he had the idea, he also kindly provided me with all the graphics needed to implement it (hand-made, using the Gimp) !

Thanks a lot for your hard work on this, Heiko! :)

If you don't like this new feature, it can of course be turned off in the options: there's a dedicated settings panel that lets you zoom in/out, and specify which parts you want to see drawn (chassis, screen refraction, cartridge, joystick cables, ...).

Chassis Zoom Level

Screen Zoom Level

As you can see, the result is quite eye-pleasing ; it's even better when you see it live. Well, I hope you'll enjoy it as much as I do.

There's still no official release data planned though, as I still need to integrate the darkening shader described in the previous post.
Let's hope it won't take too long! 

WIP : version 0.7.0 beta testing advancement

First, please note that the application for beta testing is closed from now on, as there is a complete enough panel of users testing the beta at this time. Thanks a lot for the quality of the feedback received so far, it has been of invaluable help for getting things right on most systems.

Since the start of the beta cycle, many things have changed in the graphics settings, and several old bugs have been identified and fixed.

• Fixed a couple of problems that made the emulation performing too fast compared to the original games (further information on this can be found in issues #25 and #26). These bugs have been there since day one, and plagued many games that could not be played correctly so far.
  
  Today it's all history... but the counterpart is that the timing emulation is now so accurate that it will also emulate the original games slowdowns and low FPS.



• Another old problem that has been addressed is the mismatch in the native libraries 'bitness' : so far, only the 32 bits version of all the required native libraries were included in the packaging. But, as more and more systems tend to use a 64-bits Java Virtual Machine (JVM) rather than a 32-bits one, this has started to grow problematic (because a 32 bits library cannot be loaded by a 64 bits JVM, and vice versa).
  
  The emulator now comes bundled with both the 32 and 64 bits libraries; it automatically deploys the right ones during its first execution on the target system (be it Windows, Linux or Mac OS X). This, plus the native executable launcher introduced for the Windows platforms and several other system dependant adjustments, make ParaJVE feel more integrated into the OS (and less of a hassle to install on 64 bits machines).
  



• Added some protection code to handle any crashes that would occur in the game engine. This was not that useful so far, because the OpenGL code used in the previous versions was rather simple (it used only very common OpenGL features) and did not require your 3D card OpenGL drivers to be up to date. But with the addition of the new 3D shaders in the rendering engine, some crash are a bit more likely to occur in your card's native driver if it's too old.
  
  If this was to happen (which is very very infrequent, don't worry too much!), ParaJVE will detect the crash on the next launch, and will run in "safe" mode (with all shaders turned off), hence allowing to play on older or outdated systems without errors.
  



• As said earlier, the graphics settings have gone through a redesign, merging scattered options in several centric dialogs.In addition to the already existing glow shader parameters, more options have also been added (points and lines thickness, luminosity and gamma correction, ...) to better let the user configure the rendering to its own preferences.

I have done quite a lot of changes over the different betas already, and although the current version is now very stable, I don't want to release it until I have fixed a very last problem that has been reported by several testers : the overlays rendering over dark areas being too bright.

In fact, the new overlays are way nicer than the previous versions, but it appears that their transparent areas are too bright (or opaque) when placed against a black background. Put simply, my problem is that I have to render transparent colors that are barely visible over a black area, but that, in the same time, should color the white vectors as much as possible.

As I could not find any acceptable way to implement this behaviour with standard OpenGL commands, I've started to write yet another shader to handle this rendering feature. The current prototype works well when run within the RenderMonkey shaders development environment and is fully parametrable (darkening factors and thresholds), but I have trouble adding it into the emulator, where it won't work as expected for some unknown reason.

without overlay shader (in RenderMonkey)

with overlay shader (in RenderMonkey)

As soon as this overlay rendering problem is corrected, the release will follow in the next few days ; but for the moment I really can't tell whether the official release will be ready for the end of the year (as initially planed), or not...

Keep fingers crossed! :-)
 

Beta-testing has started...

A quick post to let you know that the beta version has been uploaded, and is now available for users that applied for beta-testing (download site).

If you want to help with the testing, it's never too late : send me an email with your name & surname at vectrex@orange.fr, and I'll provide you with a beta key ASAP. 

Beta-testers needed...

As said earlier, the next release is nearly there ; but for once I would need some beta-testers in order to help me to tweak the new display settings.

The new version comes with a so called "glow shader", whose purpose is to display a glow halo around the vectors. This shader is optional (because not all 3D cards support OpenGL 2.0 or more), and it is highly user-customisable.

When modifying these user settings, the display performances could be impacted (depending on the window size and the 3D card used, for instance). Also, the visual rendering will vary from one system to another, depending on the monitor attributes (LCD or CRT, brightness, contrast, etc...).

I'd like to bundle several predefined settings (what I call "profiles"), for the users to chose, depending on their preferences.

That's why I'd need some of you to run the emulator on your computer(s) and monitor(s), tell me what profile is good/bad in their opinion (both visually and performance wise). If you feel like it, you could also create your very own profiles (the emulator comes with an embedded editor) and send them back.

With these pieces of information gathered, I can hopefully have a good idea of what is the most user-adapted default settings, and what profiles I should include in the final bundle.

Here are a few pictures of the shader parameters editor:
The beta will be Windows only, and should be available in a couple of days. If you're willing to help, please drop me a line.

Thanks!

All coding done!

This is it, the programming part for the next version is now completed...

I still have to build and test the emulator both on Linux and Mac OS X. The documentations also need to be updated. And more importantly, the new display settings still need to be tweaked a bit (more on that in the next post).

Following is a comparison of some screens taken on the old and the new versions. Hopefully, you'll find that the full overlays redesign, along with the addition of the glow shader, will make the new display look better! :-)

version 0.6.0

version 0.7.0

All this to say that the release date is quickly closing in! 

Funny Bug

Just a quick post to show some odd ParaJVE rendering I've got last evening, due to combined bugs...

I was coding a kind of generator for the emulator, so that its GLSL shaders get automatically generated/compiled whenever some significant parameter is dynamically changed (such as the window size, or the filter kernel size and/or values).

The generated shaders obviously had a bug in the coordinates computation (that made the texture lookup fetch texels too far along the X axis).
This bug alone had nothing uncommon... until for some reason I forgot to clear the content of the back-buffer before each rendering loop. This then gave this strange feedback effect that I'd like to share :



It's even more amusing when you see it moving in real-time. But I guess you'll never see it alive, since I'm about to eradicate those nasty bugs... ;o) 

WIP : Game Saves

Also included in the next release will be save game support. With this feature, you will be able to save your current gaming session in a file, and load it back in the emulator whenever you want.

Following are the notes dealing with this enhancement (issue #21 on ParaJVE's tracker).


Emulator State Persistence

ParaJVE can now save and reload its full state (including the vectors work buffer) in small binary files (usually less than 4KB). There are two kind of save/load features : Quick Saves When the user presses F5, the emulator will save its current state in a Quick-Save slot ; this slot will be loaded back when F9 is pressed. Each game has a specific Quick-Save slot (basically derived from its binary CRC), so quick-saving one game will not overwrite the Quick-Save slot of another game. When Quick-Saving/Quick-Loading, the user is not asked for a file name, as all Quick-Save files are located in the <data/saves/quick> folder. Standard Saves When the "Save..." item is clicked in the "File" menu, ParaJVE asks the user a file name where to store its state. This file can be loaded back later, when selecting the "Load..." menu item. Please note that you can only load a save file containing data for the game currently emulated (for instance, you can't load a MINESTORM save if you are running the BERZERK game). The save/load file selector dialog embeds a preview frame that lets you see the content of the selected save file (cf. picture attachment). It also provides 3 different file filters : "All Files" : list all the files in the current folder, "ParaJVE save files" : list only the files containing valid ParaJVE save files "ParaJVE compatible save files" : list only the files containing valid ParaJVE save files that match the game currently emulated.

WIP : Overlays & Rendering

With the arrival of the summer, I felt like it was time to provide you with some Work-In-Progress information, so here it is... First, let's start with a couple of snapshots, taken from the current development version :
Well, as you have probably already noticed from the pictures above, I've been quite busy lately with improvements regarding the Overlays and the vectors rendering. This comprehends these three different tasks :

• Rewriting the OpenGL code responsible for rendering the overlays :
  
  In the previous versions, the transparent areas in the overlays were obviously too dark (the colors were barely visible, and the vectors drawn in such areas did not have their colors altered enough).
  
  The new overlays handler now displays textures in a much more colorful way (especially for the vectors showing through the transparent areas), and it also provides different rendering modes, so that every user can select (through a menu) the one that best fits his monitor brightness.
  
  This task is 100% completed.


• Improving the overlays texture quality :
  
  So far, the textures used for the overlays were poor quality pictures found here and there on the Internet, and that I had to alter a bit to conform with the ParaJVE rendering engine. If this was enough for a first shot, it's now clearly not good enough when the emulator is run within a large window (let alone fullscreen).
  
  Therefore, I've decided to create all the overlay textures from scratch. This is a long-drawn-out job that I've been postponing for too long, but the result is really well worth the pain. So far, I've done 12 overlays (Armor Attack, Berzerk, Blitz, CosmicChasm, HyperChase, MineStorm, Fortress of Narzod, RipOff, Scramble, SolarQuest, SpaceWars, and StarHawk) and there is about 12 more to go before the task is over.
  
  The only drawback is that the new overlays size will drastically increase (about 10 to 15 times larger than the old ones), but I will pack them all in a single texture file that should not be bigger than 2,5 MB.
  
  Task completion level : 50%


• Implementing phosphor glow using a shader :
  
  In the versions released previously, the physical properties of the vectrex display system are emulated using a "persistence" option that mimics the phosphor afterglow. The result is fair enough, but it misses another specificity of the original display: the phosphor glow around the vectors being drawn.
  
  As I have finally found some time to learn GLSL (the OpenGL Shading Language), I've started to work on shaders that would help to render the phosphor glow. The current implementation is still in its infancy (as this is a trial & error process, with a lot of parameters to tweak) and the code is far from optimal... But still, the result looks promising, and runs in real-time.
  
  There's still a lot of work to do for this task, because I need to find the best settings, then a way to dynamically and conditionally change the parameters depending on the users preferences and the OpenGL drivers capabilities (availability of p-buffers, etc...)
  
  One thing is certain : this "glow" feature will only be available for users that have a 3D card whose driver is compatible with OpenGL 2.0 (or more), because GLSL is not available for older versions of OpenGL.

Light at the end of the tunnel...

Some new devices emulation made their way into the current version :

The Lightpen (applicable in both gameports), as well as the VecVoice (only available for the second gameport).

VecVoice

The VecVoice emulation code has been ready for more than a year ; I simply did not want to include it before because I did not like its sound output.

The problem does not lie within the code, but it's rather attributable to the samples used to render the sound. So Richard Hutchinson (creator of the VecVoice hardware) kindly lent me his device in order to let me capture some cleaner samples. This is unfortunately a task I put on hold, and that I don't have the time to carry on anymore...

So, I finally decided to include the sampling as is - after all it's better than nothing at all :) - and to return back his VecVoice to Richard (many thanks and sorry for this lengthy borrowing!).

Lightpen

The lightpen emulation is finally completed, as it now works in an acceptable way for the four games I have tested so far:

Art Master (gameport #2) Animaction (gameport #2) Melody Master (gameport #2) Engine Analyzer (gameport #1)

Animaction

The Engine Analyzer ROM is not really a game per se (and not entertaining in anyway), but is nonetheless interesting as it is the only binary I know of that makes use of a lightpen plugged in the first game port.

Technical digression...

When plugged in the second gameport, the lightpen's pin 4 is connected to the 6522's CA1 input pin, so the application just polls the state of the 6522's CA1 interrupt flag to know if the pen detects the line that is just being drawn. Also, the application will sometime setup the 6522 interrupt enable register so that it propagates a real IRQ to the CPU when CA1 is set. When connected in the first gameport, the lightpen may be used through the CPU's FIRQ (rather than IRQ), as the pin 4 of the first gameport is connected to the CPU's FIRQ line. This is how the Engine Analyzer program reads the lightpen inputs.

Within ParaJVE, when the lightpen is enabled (this is done automatically for the 4 games that require it to be plugged), the Mouse Pointer is replaced with a Cross that figures the position of the lightpen on the screen.

By default, the lightpen is considered inactive (it cannot detect light hit) as long as no mouse button is pressed. It becomes active when either (or both) the Left or Right mouse button(s) is(are) pressed.

If the Right mouse button is pressed, the lightpen operates in accurate mode (that means that its precision is greater than normal, but also that it is likely to loose track of the light more easily if you move the mouse too fast).

What next ?

With these devices done, the next release is finally approaching. The code is now frozen, all I have to do is updating the documentations and third party libraries, then building the different packages.

All in all, I wouldn't be surprised to see the 0.6.0 release pop up sometime this month ... So it might be an appropriate time to give a try to the "Check for new versions" feature of the Help menu...

Hey, is it 2008 already ???

Ok, it's been almost one year since the last release. Although it's been a busy year for me (all for the good), it was rather quiet on ParaJVE's side.

Whatever ... So what has been done ?

• I've added several parameters to the command line, so that ParaJVE can be more easily tweaked when invoked through a thrid-party front end, for instance. There are new parameters to specify a path to an external binary to be executed, to force the fullscreen, and to hide the menubar, etc...


• There has been a couple of fixes in the CPU core : the V flag was not set correctly by the DEC and INC instructions ; also the CLR instruction did not execute a read cycle before performing the write access (thanks to Martijn for this tip!)


• Fixed a major frame timing problem when the T2 timer was used by the program for something else than the standard use (frame timing). For instance, in MoonLander, the intro code sets it to $A0 (the 4-3-2-1 countdown in this intro now plays at the expected speed).
  


• I changed the way Ticks Driven frames are displayed ("ticks driven" is a special mode, set off by the emulator when the program does not make use of the T2 timer for frames synchronization) : In this mode, ParaJVE now repaints the current AND the last frame at full bright (to avoid flicker - visible in the "Spike" game, for instance).


• Added support for cartridge's onboard RAM (RAM embedded within the Cartridges). To my knowledge, the only game embedding some RAM that is directly accessible is ANIMACTION: its cartridge contains 8K ROM ($0000-$1FFF) followed by 2K RAM ($2000-$27FF).
  
  This extra RAM feature can be triggered simply by adding a <memory> tag in the target game's section of the configuration file :
  <ram address="$xxxx" size="$xxxx">


• The memory manager now also theoretically supports banked memory (ie. image files that are larger than 32K) ; but since I cannot seem to work out when to switch the banks exactly, I have had to disable this feature for the time being.
  So at the moment, banked ROMS are loaded correctly, but will always stay locked on the first bank since the bank switching will never occur.


• Lightpen emulation : I've started to emulate this device, used by the Animaction, Art-Master and Melody-Master games. The result is somewhat mitigated, but all in all the device can be used within ParaJVE already. More on that later, in a following post...
  

Now, what about a surprise ?

Most of my coding effort this year went into creating a proper debugging framework for ParaJVE. It really starts to take shape and it has now become a side project, called ParaJVD (short for Parabellum's Java Vectrex Debugger).

I've created another development blog for this project, so if you're interested (or just curious), you can follow the link and have a look :
ParaJVD development blog

So, any forthcoming release planned yet ?

Unfortunately, no.

It's far too early to release ParaJVD yet (although I will send preview builds for vectrex developers who would like to test it - feel free to contact me by usual means).

As for ParaJVE, I won't release anything until I have the lightpen emulation fully working. At the actual pace, I have no idea when it could be. But I'll keep you informed whenever possible, watch this space!

See you next week...

Just a quick post to let you know that the coding for the next version (0.5.0) is now completed ; all that's left to do is update the docs and build the windows/linux/MacOSX packages.

As I'm off for a few days I cannot do that right now, however the release will be uploaded and made public somewhere near the end of next week... Stay tuned!

Joysticks & Gamepads calibration

The panel dealing with the controller tests and calibration settings is now nearly completed, so here is a brief description... This dialog is made of 3 main parts :

• The Tests component (the joystick picture at the top).
  
  It lets you check your settings in real-time. Pressing a button on your physical controller will highlight the associated button in the picture. Also, the joystick axis marker will follow the movements of your stick.


• The Analog Response Tab
  
  Here you can tweak the response of your joystick's analog position, by editing the mapped axes curve.
  
  It is embodied using a Catmull-Rom curve (a kind of cubic spline) whose control points can be dragged around with the mouse.
  The X coordinate is the raw value (as polled from the physical device), whereas the Y coordinate represents the mapped value (the final value used by the emulator).
  
  Also, two grids display both values, in real time.


• The Sensitivity Tab
  
  This part is not implemented yet (this will be a rather trivial & fast job). It will eventually let you adjust the sensitivity of the mapped axes (through 2 sliders), ONLY if they work in relative mode.
  
  Relative mode components, unlike absolute analog components, provide an input that represents a distance from its previous position (If the device never moves, it will always return 0). For instance, a mouse or a trackball are relative devices, while gamepads have absolute axes.
  

Well, excepting for the sensitivity bit, everything else is fully functional : calibration settings loading/saving, connected devices selection, as well as controllers menus and configuration dialogs...

It all means the release date gets even closer now! :D 

W.I.P.

All right, it's been nearly two months without any update to this development log, so it's time to keep you informed...

I've worked on three major axes in the last few months : the startup code, the Mac-OS X packaging, and the integration of the controllers physically connected to the computer.

Startup Code

I've had several reports of people experiencing an emulator freezing upon startup. Although I failed to reproduce this behaviour on any of the computers I could perform tests on, this bug is likely to be related to race conditions between the threads during initialisation ; hence I've rewritten the launching code.

It is now much more synchronized (which means a tad slower), thus robust. Also, you'll be greeted with a (*ahem*) nice loading screen while te overlay texture is being read and initialised.

As I cannot check whether it fixes the hangs or not, I can only hope that it will do the trick!

Mac-OS X Packaging

Thanks to RayXambeR's feedback and support, I've finally managed to come up with a proper Mac-OS X packaging.

The previous releases for Mac were merely made of a ZIP archive (much like the other platforms distributions), that wasn't very Mac-friendly, and that usually needed the user to be confident with the terminal console to be launched successfully.

From now on, the Mac version will be distributed as a TGZ archive holding a true Mac-OS X application ; thus it can be run by simply clicking its icon!

Controllers Mapping

Due to popular request ("popular" meaning at least 3 different person ;o) I'm adding support for the physical controllers within ParaJVE.

Any controller supported/recognized by the computer should appear in the list of devices that can be (virtually) plugged into the two emulated game ports. This will let you use your favorite joystick or gamepad to play with ParaJVE (as if it was a real Vectrex joystick).

At the time being, the code that handles the controller mapping is completed and fully functional. I'm currently working on some kind of calibration dialog that would let the user tweak the response of the analog controllers (I'm not sure if it will make it into the final release).

This is it, the next release is not too far away now ; more information and snapshot should be posted soon anyway.

Ah ah !!! I lied again...

... when I said there would not be any update before long : I'm about to release a new minor version soon, that will include two new features :

• Vectrex analog joystick support (through mouse mapping). HyperChase will be playable at last, as well as PatriotsIII in analog mode, for instance... :)
  
  
  Screenshot of the left analog joystick working in the Test Cartridge.
• Automatic building of ROM binaries by compiling your sources through Frank A. Kingswood's AS09 assembler. Now, executing your own programs gets as simple as selecting the source file and clicking the "Build & Run" button!
  
  In combination with this, you can also reload external modifications made to the ROM directly from within ParaJVE, without having to restart it : just select the "Rebuild / Reload ROM" menu item and you're done (no matter what kind of ROM you're running - binary or source).

This latter feature was added in an attempt to make ParaJVE more homebrew developers friendly. This great idea was suggested by Alex of Vectorzoa, who has started an effort to involve more people into vectrex creation... If you're interested, run and check this thread at the rec.games.vectrex newsgroup.
 

Dolby Surround Pro Logic ... -not-

Better late than never, ParaJVE now comes with a proper sound emulation!

Since I finally managed to get rid of the off-putting bug in the PSG code, the sound now seems to work quite accurately in the emulator. If there are any residual bugs they're not that obvious to spot (at least, nothing that can be heard easily).

Sound routines debugging proves to be especially tedious (IMO), and as I rapidly got tired of crawling through huge arrays of numbers -- Sampling 3 channels at 44kHz brings quite a lot ;) -- I had to implement some kind of visual tool to try and comprehend them in a more intuitive way.

Once coded, the new "samples monitor" immediately pointed out the problem, as you can see in this screenshot :

The yellow/white lines reflect the samples average, while the blue ones are the current maximum. The top channel (yellow) is the overall mixing of the 3 PSG channels (white)

Quite obviously, the problem came from some kind of saturation in the channel's output at some point... After looking for the probable root causes in the code, it turned out to be a pathetic sign mistake, buried somewhere in the periods computing... With this single line fixed, the sound output for the same "soundtrack" magically became :


Which clearly makes me happy ... oh well ... call me geek if you want ;)

Right, there's still some work to do on the audio : adding user options (enable switch, sampling rate, overall volume, ...) ; fixing the timing problems (the sound plays at the game's speed, which is too fast - see the previous post) ; the speech in Spike is not implemented (not planed yet) ; etc...

But all in all, with this part working, I feel that the next significant milestone has been reached. And as I'm quite satisfied with the current emulator status, a release should not be too far now...

Here and there

What have I been up to recently, concerning ParaJVE?
Well, lots of small things have been done, that may not necessarily shows right now, but that will come in handy in the future. Most notably:

• Fixed a couple of bugs in the emulator's memory mapping :
  
  
  • Before, if the emulated program accessed an area of memory that does not exist on the real Vectrex, the emulator's VM would terminate execution - with a self explanatory "invalid memory access" exception, mind you ;)
    It appears that the Vectrex is quite relaxed regarding these accesses, so I finally redirected all the nonexistent memory address space to a NullMemory handler that returns 0 on reads, and discards writes.
  
  
  • Fixed a stupid bug where the emulated program could write into a read-only address space (ROM and CARTRIDGE areas) - Yes, there are ROMs around that have bugs causing this kind of behaviour ;) ... Needless to say, this was fixed in 2 minutes once the problem has been diagnosed.
    
  
  Which leads us to the next point...
• As I needed some kind of tool that would allow an easier diagnosis of crashes in the emulated program, I implemented a back-trace feature, along with its GUI.
  
  When back-trace recording is enabled (slows down the emulation a bit on "not-so-fast" computers), any crash in the VM immediately opens the back-trace window, that shows the history of executed instructions, along with the registers/stack content.
  
  In the end this module will also make a neat debugging addition (coupled with other stuff like breakpoints) when I'll start to implement a vectrex developer debug toolbox in ParaJVE.


• Since the overlays rendering obviously appears way too dark, I started to try and make my own versions (Starting from an opaque picture of the overlay, I'm creating a picture made of several layers with different transparency).
  
  The few ones I completed look much better, so it sounds like I'll finally have to make them all (which is very time consuming, as I'm not that proficient in using GIMP) - Thus this task has been postponed...
  


• The next version will include the games documentations, whose browsing will be triggered by a menu in the emulator... Thus I had to convert all the text docs into HTML. After having converted one by hand, I figured out rather quickly that it would be much more easy if this was performed by an automated program instead ;)
  
  Hence the conversion tool was coded in a rush, and all the HMTL documentations are now ready for inclusion. Maybe I will add them as standalone download package as well, since some people may be interested in grabbing these HTML docs alone.
  


• I've started to ask several homebrew authors if I could include their games in the next version, and they kindly agreed -- so expect Thrust from Ville Krumlinde, Nebula Commander and Revector from Craig Aker to be embedded in the next packaging.
  
  As a consequence, I made a few modifications to the configuration file to support new information about the available games (release date and version, author's name and homepage URL, documentation path, and so on). Of course, the game selection dialog will display these pieces of information, but it's not implemented yet.
  


• Last but not least, I lately started to work seriously on the sound emulation (based on a C source form MESS/MAME).
  
  I now have something that is roughly working, outside of ParaJVE (The sound "commands" & time stamps were previously recorded within ParaJVE, so that they can be played back later by the offline sound emulation routines).
  
  But for unknown reasons, the sound routines stop to work correctly as soon as they are embedded in the emulator. It seems that I'm having timing/threads problems again, but it needs more investigations.

And to finish, just an additional remark :

  I am well aware of the FPS problem that plagues the current version (eg. The FPS counter displays 60, but the games runs like it's 80 or even more). Although I don't consider it to be a top priority task at the moment, I'll eventually try and fix that sooner or later. :)

Nearly there...

Well, it has been quite hard for me to find some time to work on ParaJVE these days, but the next release is almost ready in the end.

The loading and saving of the configuration in an XML file is done. This new file includes the games definitions (roms and overlay file paths, display settings, ...), as well as the emulator key bindings.

The GUI has also been partly rewritten (the debug controls of the previous release are not there anymore, and a new menu made its way into the emulator window). The emulator will now let you select the game to run through a game selection dialog, and you can also edit the key mappings using another dialog -- So it's not needed anymore to manually edit this in a text file :)

There's still some work to do on the timing (FPS) code : I tried several implementations and I'm really not sure what's the best one (depending on the runtime platform, some are better than others), so I guess I'll include them all in the emulator and let you choose eventually ;)

Once this is fixed, the only remaining thing to do is to think about a better packaging, in order to ease the install procedure.
It looks like I'll provide 2 different packagings : one for Windows, and another for Linux. No special packaging is planned for Mac, as I have not recieved any feedback from any Mac OS X user yet (as usual, feel free to contact me if you're willing to help on this matter).

So expect a release quite soon! (sometime around this week-end)

Here are some dialogs of the new GUI :