soeren gust <sgus-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=61
> Does not work on European VMS, as soon as the program starts it resets
> the VMS and I have to enter the time again. Just how did you find the
> correct location $ef5? Is there perhaps another location in the
Japanese
> VMS which works and is identical in all versions?

Try changing $ef5 to $ef8.  I have found that even different Japanese
BIOSes differ.  $ef5 works with version 1.002.  $ef8 works with version
1.004.  The European BIOS might be closer to the 1.004 version.

An easy way to check if you have an 1.002 firmware is to increase the
year to 2048, and then try to decrease it back to 2047.  If it pops up
to 2559 instead, it's an 1.002.  :-)

The $ef5 location is rather carefully selected as an LDC instruction
that stores the result away somewhere where it can be retrieved later.
I've tried to find a better location that would be more likely to work
with different firmware revisions, but failed.  There are not that many
LDC instructions in total in the entire firmware.  The $e000-$ffff area
(which is most likely to be identical in all firmwares) contain none.


   // Marcus

> >     b) you can get 5V from the PS/2 connector if you need
> >        external power, so that might be an idea instead of
> >        really external power as you used. i don't know if it
> >        is enough though.
>
> Should be enough, but I wanted a replacement for the VM battery
> power, and with 5V it just says "Change Battery". Another point:
> not all systems are PCs.

The Amiga Diskdrive port has +5 and +12 lines, so you could grab power
from there
 

I just looked on the web at this page and it showed +12v, -12v outputs and audio in/out. The Amiga 1000 looks a little different: it has audio in and out, two clocks, +12, +5, and -5, and interrupt (in?) and a reset-out.

And of course, all RS-232 serial ports can provide power, just as long as you don't use too much of it(!). The standard output is +/-12v; minimum required output is +/- 3v, and many of the devices cheat a bit.
 

 
Or alternatively, just a standard 3.5" Hard drive power cable would
work (and is available on most systems) - you can buy cables designed
to double one plug to two drives, which could be adapted to a power vm
with passthru dongle.

> Ok, here's a fun trick for everyone who has a Japanese VMS.
>
> I've written a program to dump the contents of the VMS firmware.
> Unfortunately, it depends on certain instructions being present in
> certain locations within the firmware itself, so it will probably only
> work with a Japanese firmware.  You're welcome to try with an American
> or European VMS, but don't be surprised if it explodes into blue smoke
> or something.  ;-)

Does not work on European VMS, as soon as the program starts it resets
the VMS and I have to enter the time again. Just how did you find the
correct location $ef5? Is there perhaps another location in the Japanese
VMS which works and is identical in all versions?

> >  b) you can get 5V from the PS/2 connector if you need
> > 	   external power, so that might be an idea instead of
> > 	   really external power as you used. i don't know if it
> > 	   is enough though.
>
> Should be enough, but I wanted a replacement for the VM battery
> power, and with 5V it just says "Change Battery". Another point:
> not all systems are PCs.

The Amiga Diskdrive port has +5 and +12 lines, so you could grab power
from there

Or alternatively, just a standard 3.5" Hard drive power cable would
work (and is available on most systems) - you can buy cables designed
to double one plug to two drives, which could be adapted to a power vm
with passthru dongle.

> 1. OS timing problems- is it possible to just be rude and turn off
> interrupts while we run?

Not all OSs allow such things on normal programs, on DOS it is common
practice AFAIK.

> 2. If I remember right, there are some open collector outputs on the
> parallel port.

In theory yes, in practice most of them are just normal CMOS outputs. Most
modern boards since Intels TX chipset do only use 3V logic in the ISA bridge,
this includes the parallel port, so this is not a problem.

> Going the other way:  when I hooked up the VMU to an analayzer, I used
> default TTL levels; so if  my analyzer saw it's output levels, a parallel
> port should also see it.

3V logic is designed to be compatible with 5V inputs, as long as the inputs
are not on several harddisks by Seagate...

>  a) do you have old floppy connector cables? they have these
> 	   connectors which look like they could work instead of
> 	   the local bus stuff (which is unlikely to be around for
> 	   most people)

I only use the contacts from VLB, the plastic is thrown away. There
are pictures in the archive.  The contacts from old floppy cables
are more like ISA bus connectors, the contacts are too thick.

>  b) you can get 5V from the PS/2 connector if you need
> 	   external power, so that might be an idea instead of
> 	   really external power as you used. i don't know if it
> 	   is enough though.

Should be enough, but I wanted a replacement for the VM battery
power, and with 5V it just says "Change Battery". Another point:
not all systems are PCs.

> p.s. I missed about 2 days of messages right around the time Soeren
first
> talking about his work here. Did anyone else?


Yeah, My info on the member's page said "permanently bouncing" which
means it couldn't get mails through to me, so I now read everything via
the web instead. (but I gather that was a problem with my bigfoot
redirector email address.

Don't forget guys that you can read past messages, and post from the
group webpage @ http://www.egroups.com/group/vmu-dev/ and you can
change your settings to "read on the web" using the members tab

Two things occured to me about using the parallel port with a PC to talk
with a VMU

1. OS timing problems- is it possible to just be rude and turn off
interrupts while we run? It looks like the timing is espcially critical, but
maybe there is a slack time that we can periodically turn the interrupts
back on and let the OS do its stuff. An analysis of the VMU's firmware might
be able to find if such a slack time exists and possibly the time limit
before a time-out error.

2. If I remember right, there are some open collector outputs on the
parallel port. This could solve the 5v PC into a 3v VMU problem: Use the
VMU's 3 volt output as a voltage source for the pullup. Going the other way:
when I hooked up the VMU to an analayzer, I used default TTL levels; so if
my analyzer saw it's output levels, a parallel port should also see it.

ok. I lied. Three.

3. I guess the biggest problem is the connector. I just soldered to the
insides of a VMU, but this was sortof a pain in the neck.

Great work Soeren!

-- john

p.s. I missed about 2 days of messages right around the time Soeren first
talking about his work here. Did anyone else?


"Matthias L. Jugel" wrote:

> soeren gust <sgus-@...> wrote:
> original article:http://www.egroups.com/group/vmu-dev/?start=54
> > I have just released the first version of my PC to VM transfer
> hardware.
> > You can get it at "http://soeren.infoserv.de/vm/".
>
>         while looking over your hardware descriptions:
>
>         a) do you have old floppy connector cables? they have these
>            connectors which look like they could work instead of
>            the local bus stuff (which is unlikely to be around for
>            most people)
>
>         b) you can get 5V from the PS/2 connector if you need
>            external power, so that might be an idea instead of
>            really external power as you used. i don't know if it
>            is enough though.
>
>         great work :-) i will talk with out hardware guy next
>         week and see if we can find an easier way to connect the
>         vmu.
>
>         leo.
>
> ------------------------------------------------------------------------
> post: vmu-dev@eGroups.com, unsubscribe: vmu-dev-unsubscribe@eGroups.com
> http://www.egroups.com/group/vmu-dev/
>
> ------------------------------------------------------------------------
> Sign up for the latest technology news from PC World.com!
> Sign up today for PC World's email newsletters.
> FREE and easy-to-digest, these daily emails give you everything from
> breaking technology news, to top product reviews and hot new shareware!
> http://click.egroups.com/1/2206/0/_/417030/_/952685478/
>
> eGroups.com Home: http://www.egroups.com/group/vmu-dev/
> http://www.egroups.com - Simplifying group communications

soeren gust <sgus-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=54
> I have just released the first version of my PC to VM transfer
hardware.
> You can get it at "http://soeren.infoserv.de/vm/".

	 while looking over your hardware descriptions:

	 a) do you have old floppy connector cables? they have these
	    connectors which look like they could work instead of
	    the local bus stuff (which is unlikely to be around for
	    most people)

	 b) you can get 5V from the PS/2 connector if you need
	    external power, so that might be an idea instead of
	    really external power as you used. i don't know if it
	    is enough though.

	 great work :-) i will talk with out hardware guy next
	 week and see if we can find an easier way to connect the
	 vmu.

	 leo.

I have just released the first version of my PC to VM transfer hardware.
You can get it at "http://soeren.infoserv.de/vm/".

tyr-@... (alessandro sanasi) wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=51
>         MOV #$80,ACC            ; move value $80 into ACC register
>         ST 2                    ; store it in memory address 2

Those kind of comments are in IMO worse than no comments at all.  If
someone doesn't know what the ST instruction does, it's easy enough to
look it up.  A comment should tell you about the _purpose_ of the
instruction, not the _function_.  For example:

     MOV #3,lvs  ; start with three lives

not

     MOV #3,lvs  ; move the number three into address lvs


> fwcall .macro
>        mov     #<$0123,0
>        push    0
>        mov     #>$0123,0
>        push    0
>        not1    ext,0
>        jmpf    \1
>        .endm
>
> bios_rflash:
>        fwcall  $e027
>
> How does macro definition work in the VMU assembler, and how are
those
> macros used?  What does stuff like "mov #<$0123,0" or "jmpf \1" do
> exactly?  What's the "\1" for in the latter?  What's a "fwcall"?

The .macro definition just stores the next lines (up to .endm) into a
macro called "fwcall".  The "fwcall $e027" line below will invoke the
macro, which simply means that the lines stored previously are
substituted for the macro call.  In the process, all \n where n is a
number are substituted for the nth positional argument to the macro.
So \1 will be replaced with the first argument to the macro, namely
$e027.

As for "mov #<$0123,0", well it moves the low byte of the constant
$0123 into address 0.  It's a perfectly normal mov instruction.

Btw, the firmware call macro uses a dirty trick.  You are not required
or expected to understand how it works.  :-)


> And here:
>
>        clr1    ie,7
>        mov     #$81,ocr
>        mov     #2,xbnk
>        push    xram+4
>        set1    xram+4,0
>        mov     #0,$7c
>        callf   bios_wflash
>        callf   bios_vflash
>        pop     xram+4
>        pop     xbnk
>
> Why is xram+4 pushed on the stack?

Because the "flash access" icon on the LCD should be restored to its
previous state when we're done writing.  The 'normal' FLASH write
function (at $100) handles the display of this icon for us, but here we
have to get our hands dirty outselves.  (Or simply ignore the icon.
But I think it's nice. :)


> Wouldn't that be the data at address
> $184 or what?

Yes.

> Or why is xbnk set to #2?

Because there's where the icons live.


   // Marcus

Ok, I've spotted what you're doing wrong.  Somehow, you seem to have
misunderstood the concept of big-endianness.  The _most_ significant
part of the address goes into the _lowest_ memory location ($7D), the
_least_ significant part of the address goes into the _highest_
memory location ($7F).  So


   Alessandro>        ld lev_offs_lo
   Alessandro>        st $7d                   ; $7d = lo-offset current
write-address
   Alessandro>        ld lev_offs_hi
   Alessandro>        st $7e                   ; $7e = hi-offset current
write-address
   Alessandro>        mov #0,$7f               ; $7f = 0 (24 bit big endian)

should be

       ld lev_offs_lo
       st $7f                   ; $7f = lo-offset current write-address
       ld lev_offs_hi
       st $7e                   ; $7e = hi-offset current write-address
       mov #0,$7d               ; $7d = 0 (24 bit big endian)


   // Marcus

Hello.

Just wanted to mention it... when anyone of you posts source code, even if
it's only a small part, PLEASE COMMENT IT, preferably EVERY SINGLE LINE!

Believe me, even though some of you professionals here probably don't need
detailled comments in a source listing, 'newbies' like me who just started
with this a few weeks ago and don't do programming for a living *DO* need
it and are thankful for every comment, even if it's something as simple as
for example

         MOV #$80,ACC            ; move value $80 into ACC register
         ST 2                    ; store it in memory address 2
                                 ; (used for indirect addressing, @R2)

Again, for the professionals here, commenting such simple things may sound
silly, but I still remember what a hard time I had when working my way
through Marcus Comstedt's sample "Tetris' listing a few weeks ago, needing
over half an hour to fully understand even simple things like the Clear
Screen routine, and _I_ always had a knack for assembler.  But others who
have to start _completely_ from scratch will probably give up when finding
only listings with few to no explanations.

So please _please_ *PLEASE*, when you post stuff, comment *EVERYTHING*, as
detailled as possible, and preferrably with as simple words as possible.
Always try to make it understandable even for someone with _no_ previous
VMU knowledge.  Give 'hobby-programmers' like me a chance to catch up too.
;)

Anyway, to be completely honest, part of the reason why I posted this is
because Marcus' latest source listing about unrestricted write access to
the VMU Flash Rom again gave me a pretty hard time (also with almost no
comments, but please don't take this personal). :)  For a start could
someone please explain to me the following:

fwcall .macro
        mov     #<$0123,0
        push    0
        mov     #>$0123,0
        push    0
        not1    ext,0
        jmpf    \1
        .endm

bios_rflash:
        fwcall  $e027

How does macro definition work in the VMU assembler, and how are those
macros used?  What does stuff like "mov #<$0123,0" or "jmpf \1" do
exactly?  What's the "\1" for in the latter?  What's a "fwcall"?

And here:

        clr1    ie,7
        mov     #$81,ocr
        mov     #2,xbnk
        push    xram+4
        set1    xram+4,0
        mov     #0,$7c
        callf   bios_wflash
        callf   bios_vflash
        pop     xram+4
        pop     xbnk

Why is xram+4 pushed on the stack?  Wouldn't that be the data at address
$184 or what?  Or why is xbnk set to #2?  So many questions, and nothing
has been explained... ;)

Bye


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

Hello.

About my problem with not being able to correctly write to the Flash Rom,
here is some sample code.  For reasons unknown to me, this one seems to
cause the program to _hang_ when calling the write_flash function, while
in the real program I'm working on it only seemed to refuse to write to
addresses not divisable by $100 (e.g. $180, $280 etc.).

Therefore I think I'm probably doing something _generally_ wrong (stupid
me).  So, if someone could please explain to me *EVERY* step needed to
write to the Flash Rom, *IN DETAIL*, I would highly appreciate it...

BTW, people, when you post source code or new tricks, *PLEASE* add as many
comments as possible.  Write down after each line of code what the given
command does, and why it needs to be done this way.  Even though the code
may be perfectly obvious for you, for many others it is *NOT*.  So for
God's sake, please _comment_ your stuff!  I really can't point this out
often enough.

Ok, now let's get to the code sample.  If anyone can show me what I'm
doing wrong, I would highly appreciate it:

------------------------------------------------------------------------


lev_offs_lo = $30               ; define variables to store address
lev_offs_hi = $31


      [...]


      .org    $100

write_flash:
      not1 ext,0                 ; VMS Firmware call, "write Flash Rom"
      jmpf write_flash
      ;
      ret


      [...]


start:
        mov #$a1,ocr             ; the usual program init stuff
        mov #$09,mcr
        mov #$80,vccr
        clr1 p3int,0
        clr1 p1,7
        mov #$ff,p3
        ;
        ; ---------------------------------------------------------------
        ; fill Ram from $80 - $ff with %10101010 (test data to write)
        ; ---------------------------------------------------------------
        ;
        mov #$80,1          ; we start at Ram location $80
        mov #$aa,acc        ; byte to write
.fill_block:
        st @R1              ; write byte (@R0 & @R1 always access Ram half)
        inc 1               ; increase pointer
        ld 1
        bnz .fill_block     ; already 128 byte written?
        ;
        ; ---------------------------------------------------------------
        ; now write the test data to the Flash Rom
        ; ---------------------------------------------------------------
        ;
        mov #<write_location,lev_offs_lo    ; write-address in Flash (lo)
        mov #>write_location,lev_offs_hi    ; write-address in Flash (hi)
        ;
        mov #4,c                 ; c = counter (we write 4 * 128 byte)
        ;
.write_next_part:
        push 0                   ; save what gets scratched by flash write
        push b
        push c
        push trl
        push trh
        push xbnk
        ;
        push ie
        push ocr
        ;
        clr1 ie,7                ; clear IE bit 7 (disable all interrupts)
        mov #$81,ocr             ; switch to 600 kHz when writing to Flash
        ;
        mov #1,$7c               ; set Finalize Flag (1 = wait indefinitely
                                 ; for last byte to stabilize)
        ld lev_offs_lo
        st $7d                   ; $7d = lo-offset current write-address
        ld lev_offs_hi
        st $7e                   ; $7e = hi-offset current write-address
        mov #0,$7f               ; $7f = 0 (24 bit big endian)
        ;
        call write_flash         ; write to Flash Rom
        ;
        pop ocr
        pop ie
        ;
        pop xbnk                 ; restore what got scratched by flash write
        pop trh
        pop trl
        pop c
        pop b
        pop 0
        ;
        ; ---------------------------------------------------------------
        ; add 128 to write address, so next chunk of data will be placed
        ; after the data we just wrote
        ; ---------------------------------------------------------------
        ;
        ld lev_offs_lo
        add #$80                 ; add #$80 to lo-byte
        st lev_offs_lo
        ld lev_offs_hi
        addc #0                  ; add carry to hi-byte, if result > 255
        st lev_offs_hi
        ;
        dbnz c,.write_next_part  ; already 4 * 128 byte written?
        ;
        ; ---------------------------------------------------------------
        ; now show what we wrote on the LCD screen
        ; ---------------------------------------------------------------
        ;
        mov #<write_location,trl
        mov #>write_location,trh
        call setscr              ; standard 'display screen' routine
                                 ; as found in "Tetris", "Bounce" etc.

      [...]


        .cnop 0,$80              ; address must be divisable by $80

write_location:
        ;
        ; 512 (4 * 128) byte to overwrite
        ;
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "                                                  "
        .byte "            "


------------------------------------------------------------------------

Bye


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

Last night I wrote a simple little tool, which converts an LCD file
into a series of 'n*x portable bitmaps.

It also generates a script file which uses the programs "ppmtogif" and
"whirlgif" to convert each .pbm into a .gif, and then encode them into
a gifanim (using the correct timings from the lcd file)

However, it seems that the pbmtogif program isn't included in normal
Gnu distributions (probably due to the unisys patent stuff) and also
whirlgif (which does seem to be Gnu) gets confused by long argument
strings,  so it's unlikely that you'll actually get the script to run!
(but hey, it's the idea that counts...)

Anyway, It's hardly been tested, but I found it does work on the code
veronica .lcd file available on dreamcast.com [ look ->
http://www.dreamcast.com/games/downloads/vmugames/files/ ]  using the
amiga binary of ppmtogif, and I can create a gifanim as long as I
manually edit the script down to only give whirlgif 30 frames in it's
arguments!

Hopefully I'll find a better sollution soon!

You can find the c++ source file in the vault.

>>>>> "Alessandro" == Alessandro Sanasi <tyro@...> writes:

   Alessandro> I'm currently writing a program where I need to write data to the
VMU
   Alessandro> Flash Rom.  Only problem, for some reason I can't write to
addresses that
   Alessandro> are not divisable by $100 (all addresses are within the VMU
gamefile, of
   Alessandro> course).  Basically, this means writing blocks of 128 bytes of
data to
   Alessandro> addresses like $100, $200, $300 etc. works, but writing to
addresses like
   Alessandro> $180, $280, $380 etc. does _not_ work.  But in the description
about the
   Alessandro> VMS Firmware it is stated that it's enough if the addresses are
divisable
   Alessandro> by _$80_.

   Alessandro> So, any ideas what I might be doing wrong here? ;)  I need to
write a part
   Alessandro> of _continuous data_, without gaps of 128 byte after each 128 byte
of
   Alessandro> data...

Well, it works for me.  :-)  Can't say what you're doing wrong without
looking at your code.


   // Marcus

Hello.

I'm currently writing a program where I need to write data to the VMU
Flash Rom.  Only problem, for some reason I can't write to addresses that
are not divisable by $100 (all addresses are within the VMU gamefile, of
course).  Basically, this means writing blocks of 128 bytes of data to
addresses like $100, $200, $300 etc. works, but writing to addresses like
$180, $280, $380 etc. does _not_ work.  But in the description about the
VMS Firmware it is stated that it's enough if the addresses are divisable
by _$80_.

So, any ideas what I might be doing wrong here? ;)  I need to write a part
of _continuous data_, without gaps of 128 byte after each 128 byte of
data...

Or how about some short sample code that first writes data to an address
at .cnop 0,$100 and then at .cnop 0,$180 or something?

Bye


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

Ok, here's a fun trick for everyone who has a Japanese VMS.

I've written a program to dump the contents of the VMS firmware.
Unfortunately, it depends on certain instructions being present in
certain locations within the firmware itself, so it will probably only
work with a Japanese firmware.  You're welcome to try with an American
or European VMS, but don't be surprised if it explodes into blue smoke
or something.  ;-)

Anyway, here's the procedure:

* Get dumpbios.s from the vault, and assemble it.  Upload the binary to
your VMS.
* Enter game mode on the VMS.  A text "Working..." should appear on the
top of the display.
* At this point, reinsert the VMS into the controller.  Since the
dumper program writes a lot of data to the FLASH, it's better to run on
DC power than on batteries.
* You should see a progress indicator moving slowly to the right.  When
the indicator reaches the right edge of the screen, the dump is
finished.  This takes approx 6 minutes.
* If the text "Error!!!" appears, the dump has failed.  Remove the VMS
from the controller and press Mode to leave the dump program, then try
again.
* When the dump completes, the VMS will automatically leave game mode
and should appear in the File screen on the DC again.
* Now transfer the dumpbios game back to the computer again.
* Finally, get undumpbios.c from the vault, compile it, and run it on
the dumpbios binary you got back from the VMS.  This program will
accept either a .VMS or a .DCI file.
* Now you should have a firmware dump in the file "vmbios.bin".  You
can test it in the softvms emulator by starting it with the flags `-b
vmbios.bin'.

As always Jim, should you or your Dreamcast be injured or killed during
this mission, I will disavow all knowledge of your actions...


   // Marcus

"marcus comstedt" <marcu-@...> wrote:
> Apart from the naming of the VMS file, this could actually be read by
a
> separate program if placed into comments, like so:

     i don't think that is necessary. the vms file contains already two
     descriptions and a 16 byte creator string. I already take these
infos
     out of the vms file with the creator. the only problem there is that
     in the vmi the title/creator are 32 byte and there is only one 32
byte
     string in the vms (dc info).

> etc.  Then it would be ignored by the assembler, and some other
program
> could extract the info and create a VMI file.  It would also have have
> the opportunity to look at the generated .vms file to get total file
> size etc.

     it makes sense ... an external program would give more options.

     leo.

Marcus wrote:

> No.  There is a check that prevents you from writing outside the game
> file iself.  _However_, there is another BIOS vector you can use which
> does not have this limitation.  It's a bit tricky to call though, as it
> doesn't have any code to return to the game ROM bank.  Here's some code
> you might find useful:
> ...

Thanks, it worked, I have be able to correct the errors in my FAT and DIR.

Soeren Gust

"richard munn (aka benjymous)" <richard.mun-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=42

>   ;; Information to create .VMI link file
>
>   .title       "vmi title goes here"
>   .description "copyright somebody or other"
>
>   .resource    "MYGAME"
>   .vmuname     "MyGame_GAM"
>
>   .checksum    SEGA

Apart from the naming of the VMS file, this could actually be read by a
separate program if placed into comments, like so:

*%title: Blah blah
*%description: Argle blargle
*%checksum: SEGA

etc.  Then it would be ignored by the assembler, and some other program
could extract the info and create a VMI file.  It would also have have
the opportunity to look at the generated .vms file to get total file
size etc.


   // Marcus

Would it make sense to add extra directives to the assembler so that it
can call/use the vmu code directly to create a .vmi file on assembly?


i.e. something like:


   ;; Information to create .VMI link file

   .title       "vmi title goes here"
   .description "copyright somebody or other"

   .resource    "MYGAME"
   .vmuname     "MyGame_GAM"

   .checksum    SEGA



if this was at the top of a file called main.s, when assembled it would
create a .vms file called "MYGAME.VMS" and a corresponding vmi file
called "MYGAME.VMI" - the other fields correspond to the data fields
available in vmi files.

leo-

>         :-) i just see john's vmu gong game with marcus icon. looks like
>         we are not alone.

I don't have a dreamcast, so what was the point -- I couldn't see it!
(actually thanks; now I can see it on the PC)

I've got to finish up that game some day....


john

> BTW, it's not possible to have an alpha channel in a ppm.  You need to
> create a PNG or something to get alpha.

	 maybe i should encode gif directly. the picture are small enough
	 to be no problem without compression and it would be more portable
	 as the current solution of calling an external program.

	 would it make sense to put stuff like the vmi/vms file functions
	 and maybe the dcm tools stuff into a "libvmu.a". if written
	 portable you could then write more sophisticated programs with
	 a "gui" and don't care about the innards.

	 :-) i just see john's vmu gong game with marcus icon. looks like
	 we are not alone.

	 leo.

"matthias l. jugel" <le-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=38

>   marcus: i hope you understand that the tetris icon in the
> virtuamunstaz
>   demo is there due to our ignorance. take it as homage :-)

:-)

BTW, it's not possible to have an alpha channel in a ppm.  You need to
create a PNG or something to get alpha.


   // Marcus

"matthias l. jugel" <le-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=35
> while comparing the results of my icon extraction with the icons on
> booyaka i found that the colors are somewhat different (for Hydro
> Thunder). any hints how i could convert the 16 colors into their
> corresponding values in a 256 color cube?

   actually, replying to my articles is not usually my style ...

   okay, the color decoding is right now. it's very simple. the colors
   are in 12 bits RGB, and all i had to do was doubling each of the 4
   bits for R, G and B.

   a color code of f339 (fully opaque, somewhat blue) results in
   33 33 99 and i do not care about the alpha channel yet. i don't know
   how to code that channel into ppm pictures.

   marcus: i hope you understand that the tetris icon in the
virtuamunstaz
   demo is there due to our ignorance. take it as homage :-)

   leo.

While we're on the subject of building custom connector hardware, would
it be easier to build some kind of connector box that lets you plug in
a DC controller to your computer? (which would then let you access the
VM too)

The connector would be easier to get hold of, as you can buy 3rd party
controller extension cables fairly cheaply

while browsing the home pages i found a few people working on encoding
programs for vmi.

i have made an attempt to create the encoder parts and data description
portable in the vmu data creator. maybe someone might want to look at
it by downloading the source available on our home page.

http://virtuamunstaz.de/vmi.tgz

if you have suggestion to solve things different tell me.

leo.

while comparing the results of my icon extraction with the icons on
booyaka i found that the colors are somewhat different (for Hydro
Thunder). any hints how i could convert the 16 colors into their
corresponding values in a 256 color cube?

as far as i remember the icon color for marcus mini tetris is right
or am i wrong? can somebody please have a look.

http://virtuamunstaz.de/vmi.jsp

leo.

and another step forward. i don't thing i decode the vms data size
correctly, but i am working on it. however, the online version does
now check if someone uploads a vmi instead of a vms.

you can view vms header info using the "view info" option and the
uploaded file display (last ten only) display the info now instead
of the file name.

leo.