On holiday

So no WIP posts, nor email replies until 23th of august.
Till then, have fun! :)

Shades of gray...

And how annoying they are...
I needed to get rid of this B&W screen, it had become a question of sanity :)

So I decided to go for a break with the AY-3-8192 (sound) emulation, and get back to the graphics code for a while.

After playing a bit with OpenGL (switching to the JSR-231 version of JOGL in the process) and overlay pictures, some basic overlay implementation brought colors to the screen.

Of course, the rendering still needs a lot of tweaking, but for what I've spent on it I'm rather satisfied with the result, and wanted to share some snapshots :

Another fun idea made its way while I was using OpenGL : it might be worth a try to use shader effects to render the vectrex screen's persistence and brightness. As I have no experience whith shaders in OpenGL, it would be a nice background task while learning how they work...

Now also available for Linux, MacOS X and Solaris

Well, hopefully, that is... :)

Here are the native libraries for these platforms ; with that you should be able to run the emulator on these targets too. As I have none of these systems available for testing, I can't check that it works properly. If you have a chance to try it, please tell me if it's ok or not.

To install the native libraries, download the right archive, unzip it directly into the emulator's directory, and you're nearly done!

Of course, as you can't launch the emulator with the vectrex.bat script, you'll have to write your own script to run the java command line (if you write one, I'd be very grateful if you could send me a copy, so that I can include it in the next distrib)

JOGL native libraries for Mac OS X 10.3+
JOGL native libraries for Linux/x86
JOGL native libraries for Solaris/SPARC 2.8+
JOGL native libraries for Solaris/x86 2.9+

Alternatively, you can get these files (as a JAR archive) from the JOGL 1.1.1 download page.

Huh... No Name yet ???

Doh, it looks like I totally forgot to choose a name for the emulator before it being released!

As I'm completely out of inspiration -- who would blame me with 36°C around ;) -- I thought something like ParaJVE (for Parabellum's Java Vectrex Emulator) would do the trick.

Or maybe JaVectrex would sounds better?

Whatever, I need help! I you've got any fun/nice ideas, please email me or post a comment before the name is settled in stone...

First public release

As I wanted to gather different feedback from potential users, I've decided to build and release a quick and dirty packaging for the emulator. Hopefully, everybody having a very minimal java knowledge should be able to run it without too much hassle! :)

You can download the emulator here : ParaJVE 0.1.0.060718

All that it needs to work properly is an installed Java Runtime Environment 5.0 (yes, a 1.5 JRE ; no, it won't work with a 1.4 JRE), and a windows platform (because of JOGL, a native OpenGL library I use atm).
If some of you want to try it on a mac, though, I think I can find the mac native libs, but I never tested them (ask me if you're willing to try that).

Once unzipped, all you need to do is :

• edit "vectrex.bat" to make the JAVADIR variable refer to the good path.
  
• edit "vectrex.properties" to set the various ROM paths, and also the keymapping (the file is self-commented)
  
• run the emulator "vectrex.bat"
  

As you will see, the project is far from completion, a lot of stuff is not implemented (sound,overlays) or not working properly (vectors alignment & drifts, frame limiter code, SAVE and LOAD won't work in this build).
Don't worry if it seems too slow on your machine as the code is not optimized at all (there will be huge room for speed improvement when I will come to profiling/optimisation).

Also, don't be disapointed by the awful GUI, as it's only a temporary one for this fast release... Still, nearly all original games seem to work, only clean-sweep is crashing at startup (working on that).

Of course, comments and ideas from everybody are most than welcome!

Talking about history...

Here is a short description of the emulator's developement history so far :

---

16/07/2006

• Fixed the never ending loop bug in Spike at $0721. It turned out to be a bug in the 6522 emulation code :
  the bit 7 of PortB was not always controlled by the CIA Timer1 when the Timer was running in "One shot mode" (as specified in the ACR register).
  

• The only game that doesn't work as expected now is clean-sweep : it crashes the VM when executing the instruction at $002B : "CMPX [D,X]", with D=$CAB5 and X=$C9EA, wich refers to an invalid address ($989f).
  
  I guess I'll have to trace from where the D / X values come from to locate the error...
  

---

15/07/2006

I played a bit with the vectoring/rendering part...

• Dots optimisation
  
  Tested some heuristics to remove the parasite dots from the vector lists. The best algorithm so far is removing a dot from the display list if it corresponds to one end of the previous or next line to be drawn. This effectively remove nearly all useless dots between linked segments (eg. for instance, the segments that draw the montain in pole position). Standalone dots are still displayed (the inactive mines in Minestorm, for instance).
  
  The ultimate algorithm would be to remove any dot that matches any segment ends coordinate. There will be a problem with the non-moving dot in the cosmic-chasm caves plan, though (as it will be removed since it's on a segment end)...
  


• Made a few tests to implement Screen Persistence :
  
  .1. By keeping the lines/dots in N history buffers (N=20) and drawing the oldest first, with a brilliance factor going from 0 (oldest) to 1 (new frame). This gives nice result but slows the emulation quite a bit on slower machines.
  
  .2. (OpenGL feature) saving the new frame primitives in an openGL display list while rendering them, allowing them to be redrawn at the next frame at a lower cost. I used a glFog with a depth depending on the display list age, so that the list brigthness depends on the lists age. This method should be faster than the previous one (and does not need java objects buffering), but gives less visually attractive results.



Without persistence

With persistence

---

14/07/2006

Fixed a bug in Bedlam (the game loops forever just before the first level "maze" starts growing). It is somehow related to the 6809 CWAI instruction emulation. The fix is only temporary, and need more investigation to be handled properly.

Here is the comment added to the CWAI emulation method:

/**
* According to the 6809 docs, it seems that the CWAI mask should
* be applied to the CC register before saving it onto the stack;
* but for some reason it prevents Bedlam from working properly
* (the only game around that makes use the CWAI instruction).
* unless it becomes a problem with another game, it is likely
* to stay this way until I've got the time to check it out!
*
* BEDLAM problem (when CWAI is implemented properly) :
*
* the main game loop at $00FD starts with "CWAI #$EF" that in
* fact waits for the refresh timeout to occur on T2. Before the
* program is resumed at $00FF, the IRQ routine at $09B9 is
* called. This routine is the rendering code, as it seems to
* draw everything. When this routine is done, it ends with an
* RTI (at $0C1D) that will return the control to the main loop,
* just after the CWAI. The problem is that when the main loop
* gains control, a T2 timeout already occured, and the next IRQ
* is pending (and handled since CC now has the I bit reset).
* Thus the main loop code is NEVER executed because the CPU is
* constantly executing the IRQ routine!
*
* Maybe the problem is not in the CPU emul code, but in the VIA
* T2 handling and IRQ handling instead...
*
* TODO - When things have settled down, investigate for this bug
*/

---

12/07/2006

• Fixed a bug in Solar Quest : the ship was rotating to the left when the joystick was centered.
  It was due to an error in several instructions of the 6809 emulation, that ended with the CC register
  containing wrong condition flags. Most of the condition flags update code rewritten.


• Fixed a bug in Web Wars : the joystick, when centered, was acting as if it was in the top-right corner.
  Was due to an error in the 16 bits read access to the VIA address space :
  
  "LDD <VIA_port_b" at $1D1F returned <port_b in both registers A and B, instead of <port_b in register A and <port_a in register B.
  
  Doh!!! I had just forgot to add 1 to the address of the second byte for 16 bits access in the VIA6522 memory mapper... :)

---

07/07/2006

Finally located the bug in MineStorm that drew garbage vectors for a few seconds when a fireball mine was shot before it became active.

It was in fact an error in the original code of minestorm, not in the emulator : In the mines rendering code, drawing an inactive fireball mine that was destroyed ended up in rendering a list that was located in the cartridge rom space (which is empty, since Minestorm is running)!

Once the bug was identified, the cure was extremely easy : initialising the cartridge rom space with $01, so that every location in this space is an empty Vector List.

Here is the comment added to the removeCartridge() method in VectrexMemory.java:

/**
* We fill with $01 to bypass a bug in MineStorm (invalid
* reference to the ROM area, when a fireball mine is hit by
* a bullet while it is not yet moving). This could be fixed
* around here in the ROM :
*
* launch_fireball:
* EC17 [86.04.........] LDA #4
* EC19 [A7.41.........] STA 1,U
* EC1B [0A.EA.........] DEC <$EA ; $C8EA
* EC1D [7E.EB.53......] JMP check_next_bullet ; $EB53
*
* Somewhere in this routine there should have been :
* LDA #8 ; mark fireball as active
* STA ,U ; store mine state (if it wasn't moving, state was $10)
*
* Actually, when a stationnary fire mine is hit, the program ends
* up drawing a VL located at $3408 (because it assumes that an
* object that's not moving is either a dumb / fire / magnet /
* magnet+fire mine, whereas here it's a fireball!
*
* So to fix this we just fill the ROM with ones so that it
* becomes a big empty vector list.
*
*/

Vectrex Emulation - Let the trip begin...

Yesterday, as I was trying to gather memories to write an history file for my current programming project (ParaJVE, a Vectrex emulator), I thought it would have been much more convenient to handle all this with a blog.

So, here it is!