For anyone working on decoding the BIOS, here's my list of variables
definitions so far. Sorry, but I can't provide the source code yet
without violating SEGA's copyright of the object code. I've got to
figure out a way to do this. I remember the BIG MAC assembler for the
APPLE II (it was all upercase back then!) had someone's source code
disassembly comments... they got around the copyright by only
distributing the comments... a provided program would disassemble your
ROM and match up the comments (of course, there was only one version of
ROM back then). Until then, these labels should help (and I plan on
incorporating them into LCDIS).

** STUPID VMU TRICK **
In looking at the BIOS code, I found only one "secret" thing so far.
(Actually two, but I'm not sure of the second one yet). It's pretty
lame, but here goes:

SECRET KEY SEQUENCE ON POWER-UP STOPS MEMORY-ERASE ROUTINE!!!
On power up (or reset), the software blacks-out the screen and beeps for
two seconds. It then checks for the secet button presses-- if the
buttons are pressed and the RAM contains the magic "initialized"
sequence (at $02C-$02F, see below), then the total memory clear is
aborted.

How does it help you? Not too much. As I said, it is a stupid trick.
About all it gets you out of is re-setting the time. The User's ram is
cleared after the VMU game exits, but not before, so if your program
crashes (or gets reset), the variables won't get lost. Of course, when
you run the game again your program may reset it's own variables, but
that's it's fault, not the BIOS's.

Example: Turn on the VMU and set the time. Now press the A,B, mode, and
select buttons and hold them down. Insert the battery tab for a second
or press the reset button . Now keep the buttons pressed until after the
beeping stops. Release. The old time won't be erased. Whohoo!

-- John




Ram bank 0 (the "OS" bank):
  000-003                    Index registers, bank 0 [default]
  004-007                    Index registers, bank 1 [doesn't seem used
by BIOS]
  008-00b                    Index registers, bank 2 [doesn't seem used
by BIOS]
  00c-00f                    Index registers, bank 3 [doesn't seem used
by BIOS]
  010-015                    Buffer used by clock mode to convert current
date and time to BCD (Binary Coded Decimal)
  010     TEMP_BCD_YEARHI
  011     TEMP_BCD_YEARLO
  012     TEMP_BCD_MONTH
  013     TEMP_BCD_DAY
  014     TEMP_BCD_HOUR
  015     TEMP_BCD_MINUTE
  016     TEMP_BCD_SECOND    never used?

  017     CD_YEARHI     Current date, year (high byte, binary)
  018     CD_YEARLO     Current date, year (low byte, binary)
  019     CD_MONTH      Current date, month
  01A     CD_DAY        Current date, day
  01B     CD_HOUR       Current time, hour
  01C     CD_MINUTE     Current time, minute
  01D     CD_SECOND     Current time, second
  01E     CD_HALFSEC    Current time, halfsecond (0 or 1)
  01F     CD_LEAPYR     odd=leapyear, even=not leapyear

  020                   has a decoded value (0-3==>1,2,4,8) of bits 2&3
of P7 (MEM023)
  021                   MEM020 and MEM021 also have a value that is
written to work RAM

  022
  023                   stores bits 2&3 of P7
  024                   some sort of code used in a switch statement

  02B     MEM02B        indicates FLASH initialized?
  02C..02F              Tested to see if it contains "REST" during reset
                        If this magic number is there and the
sleep+mode+A+B
                        buttons are pressed on reset, then memory isn't
cleared.

  030     VMU_MODE      0=File mode, 1=Game mode, 2=Clock mode
  031     CD_CLOCKSET   FF=date set, 00=not

  033     AUTO_SLEEP_TIMER  Auto power-off timer incremented at 2 Hz by
T1
  034     T1SoftCtr2        General purpose counter incremented at 2 Hz
by T1
                            used to time the 2 second beep, blink icons,
[autorepeat timer?]
  035     SLEEP_MODE        Bit-mapped: Bit 0 toggles when user presses
sleep
                                        Bit 6: 1=disables sleep (both
auto and user)
                                        Bit 7: 1=GetBtn will return $FE
instead of autosleeping

  036-037               Total free blocks
  038-039               Game blocks free (?)

  03E-03F               Free "extra" blocks in fat table (entries
200-230)

  050     CD_YRDIV4HI   Current date, year divided by four (high byte)
  051     CD_YRDIV4LO   Current date, year divided by four (low byte)

  052                   used by BCD routines. Also used as flash block
number
  053                   used by BCD routines.

  054 - msb    Address read from value at flash location 01FE46  (see
code @ 2296)
  055 - mid
  056 - low

  060     CURSOR_X      Cursor position, column (0-7)
  061     CURSOR_Y      Cursor position, row (0-3)
  064     CURSOR_XBNK   Bank drawn character will be in
  065     CURSOR_X_BYTE byte offset of calculated X position
  066     CURSOR_X_BIT  bit offset of calculated X position
  067     LCD_BKGROUND  Screen background color (0 or 0xFF). This affects
clearscreen and printing characters.
  068                   Scratch pad for rotating character (left)   (big
and small characters)
  069                   Scratch pad for rotating character (right)
(small characters only)
  06A                   drawing mask left  (looked up in table @ 1b56
from CURSOR_X_BIT)
  06B                   drawing mask right (looked up in table @ 1b5e
from CURSOR_X_BIT)

  06C     BIG_CHAR_FONT font type (0=ital, 1=bold, 2=normal) [not
changeable in US version]

  06D     GAME_LASTBLK  Last block used by mini-game
  06E     BATT_CHECK_DISABLE
                        Battery check flag. $FF = disable automatic
battery check,
                                            $00 = enable automatic
battery check.
  06F     FLASHA16_SHADOW  Save a FLASH bank that is saved and restored

  Used by P3 interrupt handler @ $1f3f:
  070     BUTTONS_PRESSED  ;P3 xor'ed with $FF; 1=button pressed
  072     BUTTONS_LAST     ;bitmap:1=ignore because we've seen before,
0=active
  071     BUTTONS_READ     ;bitmap:1=selected button is pressed & not
masked

  080-0FF         Stack

addresses 0x100-0x1ff are in the user bank: ---------------------

    0x110 - string to compare?
    0x128 - string to compare?

    0x125                       Number of bytes to compare?
    0x126     SIO0_BYTECOUNT    serial i/o byte count (bidirectional)
    0x13e     SIO1_BYTECOUNT    serial i/o byte count (input only)

   17C  FL_FINAL         1=wait for last byte to finalize writing
   17D  FL_ADDR_MSB      Flash read/write start address (24 bits big
endian)
   17E  FL_ADDR_MED
   17F  FL_ADDR_LSB
   17F  FL_BUFFER        0x180-0x1FF

soeren gust <sgus-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=109
> Could be, but I don't know how fast the controller has to be for
> maplebus, the atmel could be too slow.

The minimum time between two transitions on the Maple Bus is around 250
ns.


   // Marcus

"richard munn (aka benjymous)" <richard.mun-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=111
> Also, another question is what is that watch in the picture?  is that
> part of the kit (i.e. are the music controls wrist mounted?)  Or is
> that something entirely unrelated?

I think it's just a size reference or something.  Instead of the
classical matchbox...


> I might get my Japanese Prolog lecturer to translate what it says on
> that card, too ;-)

The kanji on the third line are a bit difficult to read, but the top
two lines say:

          MP3 Player
   Download from Internet


   // Marcus

>Also, another question is what is that watch in the picture?  is that
>part of the kit (i.e. are the music controls wrist mounted?)  Or is
>that something entirely unrelated?

http://dreamcast.ign.com/news/17300.html

There's another story about the various other peripherals - ISDN, LAN, Cell
Phone, Maraca Controllers, Dreameye, and Swatch Adapter.  The watch in the
picture is the actual Swatch, but the linked story has a picture of the
radio interface for it - very interesting, indeed.

"Swatch Access Adapter: The deal between Sega and Swatch results in a
Dreamcast Controller/Satellite Dish hybrid. Actually, this curious-looking
device allows you to upload data from specially placed Dreamcast terminals
to your specially made Swatch watch. Why would you want to do this? Well,
say you have a concert to go to . . . say, for a young group of Korean
chicks called Fin.K.L. (coming to LA in April - see you there, FinKL fans).
Well, you could write down all the info for the concert, but then where are
you supposed to get a piece of paper, or a pen, eh? This adapter allows you
to interface your watch with specially placed Dreamcast terminals located in
public places in order to upload the data from the internet. The main
purpose for the device is actually e-commerce, like pre-purchasing movie
tickets onto the watch."

Wayne Bartnick : VMU Animator
http://www.vmudev.org
______________________________________________________

> It's got a connector on the side! You can see the back of the thing
in the
> reflection behind it

Yeah, on closer inspection, it appears to have a cable that connects
directly to the dreamcast controller ports

Also, another question is what is that watch in the picture?  is that
part of the kit (i.e. are the music controls wrist mounted?)  Or is
that something entirely unrelated?

I might get my Japanese Prolog lecturer to translate what it says on
that card, too ;-)

to make it easier to keep track of all the VM related news and romours
flying around, I've created a new folder in the vault (see the web
based group interface).

Currently I've linked the mp3 article, and the interview Alexander
Villagran did with SegaX a while ago (you know, the one where he said
the official VM devkit would be made free on booyaka)

If anyone finds any interesting tidbits on the web, please link them in
there!

> oh, okay.  But would I be right in assuming that the only difference
> that would need to be made is the firmware that you load into the
> interface, so once the maple protocol is sorted, you can simply write
> the Amtel code and pop it in?

Could be, but I don't know how fast the controller has to be for
maplebus, the atmel could be too slow.

"richard munn (aka benjymous)" <richard.mun-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=104
> Does anyone know what you have to do to allow VM games to be copied
> (i.e. VM<->VM or through the DC file manager)
>
> Is it just a setting in the .VMI file, or is there something more
> complex afoot?

There is a byte in the <a href="http://marcus.mangakai.org/dc/vms/flash
mem.html">VMS directory</a> controlling whether the file can be copied
or not.  When a file is downloaded from the web, the browser presumably
sets this byte according to the VMI file somehow.  It might be a bit in
the "File type" field.  My DC isn't networked, so I can't do any
experiments on this matter.


   // Marcus

"richard munn (aka benjymous)" <richard.mun-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=103
> Could you say which of the lines are actually connected on the cable?

Ok.  GND is connected (obviously), and D0-D2 are connected (although D2
isn't actually used.  Perhaps it's used with one of those thingys you
can connect two cards to.)  Then comes the problematic wires, which are
connected to STROBE and ACK in the original cable.  With my
modification, they are instead connected to D7 and SEL, respectively.
All other pins are N/C.  So an adaptor cable would look something like
this:


             STROBE 1|-----+           |
             D0     2|------\----------|2   D0
   Original  D1     3|-------\---------|3   D1   Amiga
     cable   D2     4|--------\--------|4   D2   Parallel
                     |         +-------|9   D7   Port
             ACK   10|----\            |
                     |     \-----------|13  SEL
                     |                 |
                   18|\               /|18
             GND  ...|=---------------=|... GND
                   25|/               \|25


   // Marcus

It's got a connector on the side! You can see the back of the thing in the
reflection behind it-- I didn't see any other connectors or mode buttons.
But, you'd think that there would be extra buttons for the MP3 functions,
such as play, fwd, rev, etc., and a volume control. Otherwise, it would be
no fun navigating a menu just to pause it. Also, how does it plug into the
controller? The other end? Or does it just plug in via the side cable? That
would defeat the purpose of the screen during games, and if it didn't plug
into the controller, why keep the same form factor? Lots of questions; I
suspect that this thing will change a bit before final production, so I
wouldn't get too worried about the lack of mode/sleep buttons yet.

Thanks for the find, Richard!

John


"Richard Munn (aka benjymous)" wrote:

> here's a story from ign : http://dreamcast.ign.com/news/17299.html
>
> Sadly it's just a photo - no real details yet (such as memory capacity)
> and I noticed that it only has A and B buttons (no mode or sleep) which
> suggests that it might not be backward compatible with standard VM
> games (which would be a shame)
>
> But the biggest question in my mind is will it be programmable at all,
> or will it only play mp3s?  If you could program it, think how much you
> could cram into thirty odd megabytes!

here's a story from ign : http://dreamcast.ign.com/news/17299.html

Sadly it's just a photo - no real details yet (such as memory capacity)
and I noticed that it only has A and B buttons (no mode or sleep) which
suggests that it might not be backward compatible with standard VM
games (which would be a shame)

But the biggest question in my mind is will it be programmable at all,
or will it only play mp3s?  If you could program it, think how much you
could cram into thirty odd megabytes!

Does anyone know what you have to do to allow VM games to be copied
(i.e. VM<->VM or through the DC file manager)

Is it just a setting in the .VMI file, or is there something more
complex afoot?

"marcus comstedt" <marcu-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=91
> Ok, dcmtools now available for AmigaOS.  Two minor alterations of
> cable neccessary, see README.  Download from the ususal place.

Could you say which of the lines are actually connected on the cable?

This way I could build a simple adapter so that I wouldn't have to cut
up and alter the cable (assuming I bought a nexus) thus meaning I could
still use it with the windoze software too (if I really felt the need..)

soeren gust <sgus-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=97
> Richard Munn wrote:
>
> > Would it be too different to make the interface plug into a
dreamcast
> > controller so that the dreamcast sees your computer as a huge memory
> > card?
>
> Sorry, but thats not possible with the current interface. It only uses
> the VM to VM protocol. The DC to VM protocol is something completely
> different called "Maplebus". There is some information on marcus page,
> I have not made any tests with it yet.

oh, okay.  But would I be right in assuming that the only difference
that would need to be made is the firmware that you load into the
interface, so once the maple protocol is sorted, you can simply write
the Amtel code and pop it in?

(my knowledge of microcontrolers is fairly basic, before anyone starts
to pick big gaping holes in my question.. *grin*)

tyr-@... (alessandro sanasi) wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=99
> Official SEGA VMS Emulator!?  I haven't seen that one anywhere yet.
Could
> you please tell me where I can get one?  Please??

It's part of the SEGA DC DevKit, so unless you want to fork out with
$$$ and sign all sorts of NDA:s, you'll have to wait until Alex P
releases the VMS parts into public domain, as he said he'd do months
ago...


   // Marcus

On 21 Mar 00, marcus@... (Marcus Comstedt) wrote:

> Ok, I've sorted out what was causing the problem with dumpbios.s.
> It's an old assembler bug which I had already fixed, but somehow I
> forgot to make a new release.  Get one now at the usual place.

Any chances to get a _DOS port_ of that new version too? :)

> New features apart from the bugfix are support for the BPC
> instruction, and the ability to create .HEX-files for use with the
> official SEGA VMS emulator.

Official SEGA VMS Emulator!?  I haven't seen that one anywhere yet.  Could
you please tell me where I can get one?  Please??

John
 

On 21 Mar 00, marcus@... (Marcus Comstedt) wrote:

> Ok, I've sorted out what was causing the problem with dumpbios.s.
> It's an old assembler bug which I had already fixed, but somehow I
> forgot to make a new release.  Get one now at the usual place.

Any chances to get a _DOS port_ of that new version too? :)

> New features apart from the bugfix are support for the BPC
> instruction, and the ability to create .HEX-files for use with the
> official SEGA VMS emulator.

Official SEGA VMS Emulator!?  I haven't seen that one anywhere yet.  Could
you please tell me where I can get one?  Please??

Bye


Alessandro
---
You get what anyone gets. You get a lifetime.

Hello.

Hey, did I mention the new tools that I wrote for all you DOS / Windoze
freaks out there?  Together with the old ones, I now have:

     DCI / VMI File Creator v1.2
         creates a .DCI and .VMI file from a .VMS file

     DCI to VMS Converter v1.2
         converts a .DCI file into a .VMS file

     'El Cheapo' Frame Ripper
         copies frames from .LCD files into a textfile, that can then
         immediately be used in any .VMS source listing

      VMS Checksum Calculator v1.0
         calculates the checksum of .VMS Data Files

And my latest addition:

      LCD Animation Converter v1.0
         converts .LCD Animations into .VMS files (similar to what "DC
         Animator" does) and also creates a matching animated GIF image

Come and get them at

      http://www.franken.de/users/deco/myfiles/myfiles.html

I also put together an easy-to-understand Newbie Guide that explains the
basics of how to get started with VMU Programming (where to get the
necessary tools, the info, and example source code).  And best of all, I
have a fully-documented

      EXAMPLE SOURCE SKELETON

there (a simple & easy-to-understand "Hello World" source where every tiny
bit is documented and explained).

And now, visit my page... _please_!  No one notices that it's there or
bothers to link to it.  It's so frustrating. ;)

Bye


Alessandro
---
You get what anyone gets. You get a lifetime.

Richard Munn wrote:

> Would it be too different to make the interface plug into a dreamcast
> controller so that the dreamcast sees your computer as a huge memory
> card?

Sorry, but thats not possible with the current interface. It only uses
the VM to VM protocol. The DC to VM protocol is something completely
different called "Maplebus". There is some information on marcus page,
I have not made any tests with it yet.

Soeren

Okay, currently we've got an interface and software so that you can
plug a VM into your computer and transfer data.

Would it be too different to make the interface plug into a dreamcast
controller so that the dreamcast sees your computer as a huge memory
card?

This way you could transfer files simply by dropping them into a
directory on your harddrive, and likewise all saves would appear in the
directory automagically.

"richard munn (aka benjymous)" <richard.mun-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=89
> I don't know if anyone else has noticed this, but the Amiga version of
> Aslc always reports the time taken to assemble as 0ms.  I have finally
> tracked this down to the fact that the amiga (ixemul/libnix)
> implementation(s) of clock() seems to run at a different scale to unix
> machines.  Therefore I suggest the following alteration to the code
(in
> main.c) which (seems) to give proper timings (on my machine, anyhow,
> when tested agains the gnu time util.)
>
> at top of code (after #includes):
>
> #ifdef amiga
>   #define CLOCKDIV 0.1
> #else
>   #define CLOCKDIV 1000
> #endif
>
>
>
> and alter the line that reads:
>
>   "total errors %d\n", argv[i], (int)((stoptime-starttime)/1000),

>
> to:
>
>   "total errors %d\n", argv[i], (int)((stoptime-starttime)/CLOCKDIV),

Actually, I think the Right Thing To Do would be to use CLOCKS_PER_SEC
define in <time.h>.  So just change the line to

    "total errors %d\n", argv[i], (int)(1000*(stoptime-starttime)/CLOCKS
_PER_SEC),

I'll make sure it comes into the next release.


   // Marcus

tyr-@... (alessandro sanasi) wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=83
> Well, as it looks to me, you are pushing the 16 bit address onto the
stack
> which follows the JMPF instruction at address $0122.  Since you said
that
> the "unlimited flash write" function in the firmware doesn't have
code to
> switch back to the game, I assume it just ends with a RET.  So the
address
> you pushed onto the stack is used as a 'return address', thus
continuing
> execution at the point in the firmware where the documented routine
for
> "read flash rom" resides.  And after that is done, it switches us
back to
> the game.  Neat.

Spot on.  Almost.  What you got wrong is just that $0123 is not
precisely the location of the "read flash rom" function.  The function
starts at $0120 (which is why this is the target of the JMPF), and
looks like this:

0120- 20 e0 27 | int120link:  CALLF  LE027
0123- b8 0d    |              NOT1   EXT, 0
0125- 21 01 25 |              JMPF   L0125

I.e. it calls the _real_ function (in the $E000 area), and then
switches back to address $0125 in the game bank (which contains a RET
in the case at hand).  Since the address that was pushed to the stack
is $0123 and not $0120, the $E027 function is never called, and I only
get the return back to the game.


> What makes me wonder a little though is why you used the "read flash
rom"
> routine to 'borrow' the code for switching back into game mode...
wouldn't
> the "verify flash rom" routine at $0110 be better suited? ;)

Since it's not actually called, it doesn't matter which routine it is.


   // Marcus

tyr-@... (alessandro sanasi) wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=81
> On 12 Mar 00, marcus@... (Marcus Comstedt) wrote:
>
> > >1. There are two new one-byte opcodes ($50 and $51)
> >
> > In case you're interrested, these are for reading and writing the
flash
> > memory. $50 reads the flash and works like an LDC except that it
> > doesn't add ACC to the address.  The 17:th address bit is taken from
> > SFR $154.  $51 writes the flash, but it has a safeguard which makes
it
> > a bit more difficult to use.
>
> Um... do you mean that with those opcodes, you can write _single
bytes_ to
> the flash, instead of being forced to write data in chunks of 128
bytes at
> a time?

Sort of.  The bytes are written one at a time, but the flash process
may or may not require you to write exactly 128 bytes before the flash
memory is returned to a safe state.  I haven't examined the details, as
it really doesn't matter much.  See below.


> And could you please explain the $51 safeguard a bit more detailled?

I could, but I don't want to.  You see, using these instructions in
user code would be _bad_ practice.  If/when VM cards with larger flash
memories are released, such code would more likely than not break, and
there are BIOS calls available which are portable and provide the same
functionality.


   // Marcus

tyr-@... (alessandro sanasi) wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=80
> However, aren't word-values (16 bit), dword-values (32 bit) etc.
always
> stored in memory with the least significant byte _first_? (for
example,
> the word value $a033 is stored as $33 $a0 within a program).  So why
is it
> different here?  What exactly is the difference between 'endian' type

> values and 'word/dword' type values?

Well, it should be obvious if you think about it, but the answer is
"no", and that the difference is simply that if you store the least
significant byte _first_, that's little endian, and if you store it
_last_, that's big endian.

It's of course quite arbitrary which method you select, and the names
"big endian" and "little endian" are actually derived from the book
"Gullivers Travels", where there was a civil war fought about the
equally arbitrary question about which end to crack your breakfast egg
open in, the pointy ("little") or the round ("big") end.

Usually microprocessors have a native endianness in which they normally
store numbers.  Intel processors are little endian in their nature,
whereas many processors (Motorola 68k and PPC, SPARC, etc) are big
endian, as this format is more natural to humans (and the silicon
doesn't give a shit anyway :).  If you thunk about it, you normally
write "one hundred and twentythree" as "123", not "321".

Many modern CPU:s, like the Hitachi SH-4 in the Dreamcast can operate
in both big endian and little endian mode, configured by strapping
and/or by software.


   // Marcus

Ok, dcmtools now available for AmigaOS.  Two minor alterations of
cable neccessary, see README.  Download from the ususal place.


   // Marcus

I have just released new software for the SerialToVM. There is now a
program to receive files from the VM. Additionally all the software has
been ported to AmigaOS.

WARNING:
The ISP connector on the hardware is *not* the same as the one described in
the appnote AVR 910, I have accidentally exchanged the even and odd pins.
Double-check all connections when building a cable.

I don't know if anyone else has noticed this, but the Amiga version of
Aslc always reports the time taken to assemble as 0ms.  I have finally
tracked this down to the fact that the amiga (ixemul/libnix)
implementation(s) of clock() seems to run at a different scale to unix
machines.  Therefore I suggest the following alteration to the code (in
main.c) which (seems) to give proper timings (on my machine, anyhow,
when tested agains the gnu time util.)

at top of code (after #includes):

#ifdef amiga
   #define CLOCKDIV 0.1
#else
   #define CLOCKDIV 1000
#endif



and alter the line that reads:

   "total errors %d\n", argv[i], (int)((stoptime-starttime)/1000),

to:

   "total errors %d\n", argv[i], (int)((stoptime-starttime)/CLOCKDIV),

It stemmed from my misunderstanding that the second bank of Flash contained the BIOS, but it seems to actually be a seperate bank of ROM.

-- john
 

Sorry if this is too far off topic .. but is there a group like
this one reverse-engineering Sony's copy of the VMU ?
It doesn't look as nice as the VMU, and it's not as widely
available, but the ARM7 processor and IR diode make it interesting.

-adrian

Ok, I've sorted out what was causing the problem with dumpbios.s.
It's an old assembler bug which I had already fixed, but somehow I
forgot to make a new release.  Get one now at the usual place.
New features apart from the bugfix are support for the BPC
instruction, and the ability to create .HEX-files for use with the
official SEGA VMS emulator.


   // Marcus