--- In vmu-dev@egroups.com, Paul Kratt <sblur@e...> wrote:
> Hey List,
>
> Sorry to make this bothersome post, but I have a quick question
about the
> LCD files.
> After looking a Richards LCD code he put in the files section, I
> understood everything up to the point where he uses a for statement
to
> load the file. After he loads the file, what exactly is he doing to
> decode the Frames?

Okay, I've looked at my code again and realise that it is fairly nasty
(the multiplication code after the first for loop is me converting the
frame number into a 3 digit ascii string for the filename of each
frame.) - an example of my "if it aint broke don't fix it" strategy to
programming ;-)

I've gone through the file and added some new comments (about to
upload...)


> P.S. If anyone's using a Mac, (I doubt it) please check out my
DCI<->VMS
> conversion program.


Well not directly.  I run MacOS8.1 on my Mac emulator on my Amiga (68k
code only) - are your binaries PPC only?

Hey List,

Sorry to make this bothersome post, but I have a quick question about the
LCD files.
After looking a Richards LCD code he put in the files section, I
understood everything up to the point where he uses a for statement to
load the file. After he loads the file, what exactly is he doing to
decode the Frames? Sorry, but I dont use C++ and I've only understood a
few programs I've looked at. I'm probably going to learn it next year.

Anyway, I know that if you read an LCD file exactly the way the frames
come, it seems every other frame has data, and every frame you advance
seems less and less viewable. This is as far as I've gotten with my mac
VMU animation program. I did make a successfull animation that views in
my VMU files section that is only one pixel off,
(http://metrosonic.webprovider.com/vmu/) but after looking at Richard's
code It seems I'm even more confused as to how it works because it
appears he multiply's something by 10. The only thing I can seem to make
out of this is that every odd numbered frame is ignored, expect for the
first frame, and every frame is moved up and to the left and wrapped
around as many pixels as the frame number. Is this the case? And if it is
or isn't is there an easy way to encode/decode each frame without
requiring a bunch of code that moves the picture in memory than decodes
it?

Is this every other frame thing my fault? (I'll ask this to be safe,
becuase just last week a found out the problem I had been struggling on
for a month was only caused by me not resetting a value to zero) And If
my idea is not correct can someone explain in plain english (Or basic if
you wish to use a launguage) how these are encoded? I would really
apprecate it! I've already got the entire thing laid out, and it read it
writes AS IS, so I just need this to have the first version ready.

Thanks Again in advance to anyone who responds.


P.S. If anyone's using a Mac, (I doubt it) please check out my DCI<->VMS
conversion program. I finally got around to finishing it after having it
sit on my hard drive since Janurary. It even has it's own VMI editor that
will let you edit the info in a VMI. I'll be updating it as soon as I can
with the new protection info from Marcus's page.
URL for MacVMUtil ->
http://www.emulationzone.org/projects/sonicblur/vmutil/

> Does the chao game allow fighting head-to-head?Sort of, you plug your VMs=
  together, select fight, they transfer datato each other, then you disconnec=
t before the fight happens (meaningthat the result can be different for each=
  player)Now that I've got a nexus card (I was very surprised at how fast its=
hipped from the US, and it worked out at £20 - the same price asanofficial V=
M over here!!) I can fiddle with the english version of Chaoadventure instea=
d of the jap version (although I doubt the actual codeis any different, just=
  the menu text)

In a sudden fit of productivity, I whipped together a new release of
the assembler.  Source available now in the usual place, AmigaOS
binary will be uploaded tomorrow.

New features:

* Correct time measurement (using CLOCKS_PER_SEC)  :-)
* Correct line number information during pass 2+
* Strings of length one can be used as numeric expressions


   // Marcus

> Let's say I plug two VMUs together, and both run the same program.  Is
> there an easy-to-use way how the two programs can exchange data between
> them?  For example to realize a 2-player game where each player uses his
> own VMU screen?  Maybe there is a ready-to-use routine somewhere, just
> like there is one for writing/reading the Flash Memory...

I haven't find any links in the BIOS yet... As you can see below, there are
some links I haven't worked out yet.

e000-wipe FLASH
e003-
e006-
e009-
e00c-
e00f-
e012-
e015-setup memory
e018-writeFlashBulk; write FLASH quick
e01b-go_verifyFlash
e01e-read FLASH bank 0 (1 byte) [not used]
e021-read FLASH bank 1 (1 byte) [not used]
e024-go_writeFlashOS
e027-go_readFlash
e02a-increment system time by 1 halfsecond
e02d-check leap year

There is one other undocumented link in low memory, but it doesn't look too
interesting... I think it just does the sleep function.

All of the BIOS serial routines run at 600kHz. I'm not sure if this is
required, or if you could run at a slower baud rate in normal mode. Also,
I'm not sure if LCD access would mess up the serial port like it messes up
the sound.

Besides the battery issue (see Richard's post about using a 9v battery--
this might solve the short life!), it doesn't look like it would take much
else to do the communications (besides the fact that the register
definitions are unknown, so we'd have to copy code just like it is). Does
the chao game allow fighting head-to-head?

- john

p.s. If you had a really big program, you could use 200 blocks of one VMU
(program + data) and then use the other VMU just for data storage (like a
map of a large world). If you got fancy enough, the second VMU could do
decompression of data to store even more!

On 30 Mar 00, maushammer@... (jmm) wrote:

> > 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 pretty cool. The one I got actually comes with a small accellerator
> card so that the timing is dead-on. It's also got a real LCD screen so
> you'll know exactly how the graphics will look. And, so that you can test
> VMU-VMU communications, it's got a connector on the end of it. There's
> even a rather precise physical model of the resonant frequencies of the
> piezo buzzer, so you'll know which frequencies to avoid. It was just
> $25...  but I'm kindof bummed because it lacks step and trace ability...

Gasp!  Where did you get that?  I thought only official developers and big
companies that have contracts with SEGA get one...?

Any chances that you could post the program part of it, so others can use
it too?

BTW, please do not post messages in HTML.

Bye


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

Hello.

Let's say I plug two VMUs together, and both run the same program.  Is
there an easy-to-use way how the two programs can exchange data between
them?  For example to realize a 2-player game where each player uses his
own VMU screen?  Maybe there is a ready-to-use routine somewhere, just
like there is one for writing/reading the Flash Memory...

Bye


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

On 07 Apr 00, richard.munn@... (Richard Munn (aka benjymous)) wrote:

> > Uh... sorry, but the source is completely written in assembler (all other
> > languages confuse me too much), so porting it to another system would
> > basically mean a complete re-write.
>
> hmm.  oh well.  Maybe if you could write some simple pseudocode of the
> algorithms used, I could convert it to C ;-)

I didn't have to write any 'breathtaking' algorithms, mostly it was only
'filling in the fields' according to the info on Marcus' website and then
saving the result. ;)  And the .DCI files... well, the first 32 byte is a
copy of the original VMU directory entry, and the following data is the
VMU file with the order of the bytes reversed in groups of 4 (e.g. a
string like "12345678" would turn into "43218765").  Every idiot can write
a decoding routine for _that_. ;)

The algorythm for file checksum calculation is on Marcus' page too
(although determining the file size to use can be a bit tricky), and
source code for LZW compression (required for animated GIFs) should be
available on the internet (alas I wasn't that lucky to find a ready-to-use
source in assembler, so I had to write that one myself, *deep sigh*).

> > But wasn't there a 'DOS Emulator' for Amiga available somewhere? ;)
>
> Well, if it will run on a 286 under freedos, then it will work on the
> emulator I've got (you don't use any strange undocumented msdos features, do
> you?)

It only uses the 'standard' DOS function calls (INT 21), so every emulator
that supports the officially documented features included in DOS 3.0 and
up should suffice (DOS 2.0 would usually do too, but I'm using one
function that is only available since DOS 3.0 to get the complete source
path).

Bye


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

> I started looking at what it would take to make a PC parallel-port to
> vmu adapter to use with Soeren's program.

> So, anyway, it looks like I'll need at least a series
> current-limiting resistor unless the pull-ups are a high value. That's
> just my computer; I'm sure there will be variations.

Better use a 74LS07 with pullups connected to the 3.5V from the VM. There
are many variants of parallel ports out there.

> Well, the hardest part I think will be the input. The parallel port can
> generate interupts, so maybe I'll use that line to sample the data.

I doubt that it will reliable, especially since you need to generate
the delayed data, but perhaps with a real fast processor...

Soeren

> I have made some experiments to write a full irq driven sound engine.

I have put the code and a small demo program at
http://soeren.infoserv.de/vm/sound.html

Soeren

The values in my previous mail were with my SerialToVM connected, here
are the value standalone:

watch: 0.25mA
sleep watch: 0.1mA
getkeys 6MHz: 8.6mA
getkeys 3MHz: 5.4mA
getkeys 600Khz: 2.9mA
getkeys 300Khz: 2.4mA
getkeys 32kHz: 0.65mA
getkeys 16kHz: 0.65mA
sleep 6MHz: 3.0mA
sleep 3MHz: 1.65mA
sleep 600Khz game: 0.55mA
sleep 300Khz game: 0.35mA
sleep 32kHz game: 0.15mA
sleep 16kHz game: 0.15mA

Soeren

--- In vmu-dev@egroups.com, Richard Munn <richard.munn@b...> wrote:
> Here's something interesting - A game which seems to do it's save
CRC
> differently to the others - take a look:

Well, the VMS doesn't know about the CRC at all, and the DC file
manager doesn't care either, so the use of the CRC field is basically
up to the application (game) itself.  If the game uses the high-level
functions in the Shinobi library, it will use the CRC algorithm
documented on my site, but if it doesn't it can chose to do whatever
it likes with this field.


   // Marcus

Here's something interesting - A game which seems to do it's save CRC
differently to the others - take a look:

--- Paul Acevedo <eastman@...> wrote:
> Date: Tue, 25 Apr 2000 04:26:15 -0500
> From: Paul Acevedo <eastman@...>
> Subject: VMU file editing help
> To: richard.munn@...
>
> Dear Richard,
>
> I posted this question in the Booyaka VMU boards and was hoping you might
> offer some advice...
>
> **
> I'm trying to edit the save file for the Japanese game Space Griffon, but
> have hit a big snag. I found where the variables are (for weapons, etc.) but
> this game seems to use a different CRC method than other VMU files. When I
> run VMS_CRC, I get this message:
>
> "Checksum-Field is zero. Really set new CRC value?"
>
> Well, whether I set a new value or not, the game recognizes my files as bad
> saves (with only 1 variable changed), so it seems to me that the checksum
> field must be located somewhere else.
>
> Can someone PLEASE help me determine where that is and how to calculate the
> new value? I can provide you with files to compare, etc.. Any help would be
> appreciated!
> ***
>
> Thanks for your time.
>
> Regards,
>
> Paul Acevedo          eastman@...
> Want List: http://gametz.com/user/eastx.html


=====
_  Richard Munn  RAMTronics Software
_ //  www   : http://come.to/ramtronics
\X/   email : richard.munn@...

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

I started looking at what it would take to make a PC parallel-port to
vmu adapter to use with Soeren's program. I checked out the voltages on
my laptop, and found some interesting results. The parallel port seems
to use three voltages - ground, 3.3 and 4.5v. Ground and 3.3v are used
for outputs, but inputs are pulled up to 4.5 volts. This higher input
voltage happens on the dedicated inputs (10,11,12,13,15), but also when
the input/output switchable data pins (1,2-9) are set to input (set bit
5 of 0x37a high). So, anyway, it looks like I'll need at least a series
current-limiting resistor unless the pull-ups are a high value. That's
just my computer; I'm sure there will be variations.

Well, the hardest part I think will be the input. The parallel port can
generate interupts, so maybe I'll use that line to sample the data.
It'll be a while before I get to start testing...

john

I just thought I'd post to say that I've successfully powered my VMfrom a
standard 9 volt battery (for about half an hour of playingTrickstyle jr) with no
obvious adverse effects.  I figure it can't bea good idea for prolonged use, but
it didn't seem to mind...

Here are some power measurements for the VM:

watch: 1mA
sleep watch: 0.85mA
transfer: 5mA, 8mA peak
getkeys loop 6MHz: 9.2mA
getkeys loop 3MHz: 6mA
getkeys loop 600Khz: 3.6mA
getkeys loop 300Khz: 3.2mA
getkeys loop 32kHz: 1.5mA
getkeys loop 16kHz: 1.4mA
sleep 6MHz: 3.7mA
sleep 3MHz: 2.4mA
sleep 600Khz game: 1.3mA
sleep 300Khz game: 1.1mA
sleep 32kHz game: 0.9mA
sleep 16kHz game: 0.9mA

Soeren

> Now during the game, I'm writing many things to the LCD screen, and thus
> have to change from 32 KHz to 600 KHz pretty often (by clearing/setting
> bit 5 in the Oscillation Control Register).  But it seems as if this also
> affects a sound that is currently active (creates high 'beeping' noises
> occasionally, although the sound is supposed to be a 'deep' one, e.g. when
> using a value of $c0 in ACC).  It's also hard to 'time' the tunes right,
> because if I use normal 'delay' loops, the game will be slowed down
> notably (because nothing else is executed during the delay).

Yes, the timer1 clock depends on the processor clock. The only idea I have
is not to change to 600KHz when writing to the LCD, this seems to work but
is slower, so you can see that not every pixel is updated at once. Or you
can always run at 600KHz or even 300KHz, how much more power that costs
can you see in my next article.

> 2. Is there a way to have the sound routines being handled by an
> interrupt?  I tried to re-direct the timer/counter 1 interrupt vector to
> handle the sound, but it turned out that this interrupt is called far too
> seldom to make appropriate tunes.  Is it possible to program a 'free'
> interrupt to occur regularly after an user-set time?  And if so, can
> anyone tell me how this is done (maybe timer 0 could be programmed for
> this)?

I have made some experiments to write a full irq driven sound engine. The
interrupt vector for timer1 interrupts is at $2b. For timing I used the
high byte of timer1 in split timer mode. I set t1hr to 0 and count the
interrupts, so I get about 20 irq per second, more can be generated by
changing t1hr to higher values. Don`t forget to set the t1hie bit to
enable the interrupt and clear the t1hovl bit in the interrupt routine.

> 3.  In the above code, first the timer-period value is written to t1lr
> (timer 1 low reload), then it is rotated to the right one bit, bit 7 is
> set, and the result is written to t1lc (timer 1 low compare).  After that,
> the value $50 is written to t1cnt (timer 1 control).  Although I use this
> routine, I don't exactly understand _why_ all that needs to be set this
> way.  Can anyone please explain me AS DETAILLED AS POSSIBLE how this audio
> stuff works and why things need to be done the way as described above?

OK I will try it: The timer1 is split into 2 seperate timers: t1l and
t1h. Both are 8 bit registers which increment with a frequency of clock/6.
It is possible to combine both registers, but that feature is not used here.
Every time one of the counters overflows from $ff to 0 an interrupt is
generated if the t1lie and t1hie bits in t1cnt are set. Additionally the
t1lovr and t1hovr bits are set. The counters are then reloaded with the t1lr
and t1hr values.

Now to the sound: if t1l < t1lc then there is a 0 sent to the speaker, if
t1l > t1lc then there is a 1 sent to the speaker. What is sent if t1l = t1lc
I don`t know. The calculation you mention above only sets t1lc to the middle
between t1lr and $100. So you get a symmetrical square wave at the speaker.
By changing t1lc you can change the 0 to 1 ratio of the signal.

Soeren

Hello.

I'm currently writing a Pacman game for the VMU, and now I've run into
some serious problems creating sound for it.

Here is the sample source code for playing sound, posted by Marcus
Comstedt a while back.  Marcus said that the Timer counts with 32768/6 Hz,
so one timer-period is 32768/(frequency*6).  The subroutine 'playsound'
thus needs to be called with ACC = 256-32768/(frequency*6).

playsound:
        mov #0,t1cnt            ; stop Timer 1 high/low
        ;
        st t1lr                 ; set Timer 1 Low Reload
        ror
        or #$80
        st t1lc                 ; set Timer 1 Low Compare
        ;
        mov #$50,t1cnt          ; start Timer 1 Low
        ;
        ret

And to turn off the sound again:

nosound:
        mov #0,t1cnt
        ;
        ret

Now during the game, I'm writing many things to the LCD screen, and thus
have to change from 32 KHz to 600 KHz pretty often (by clearing/setting
bit 5 in the Oscillation Control Register).  But it seems as if this also
affects a sound that is currently active (creates high 'beeping' noises
occasionally, although the sound is supposed to be a 'deep' one, e.g. when
using a value of $c0 in ACC).  It's also hard to 'time' the tunes right,
because if I use normal 'delay' loops, the game will be slowed down
notably (because nothing else is executed during the delay).

I don't know how to solve this problem, so I would like to ask here if
anyone has experience with sound programming and can give me some tips.
Basically, what I need to know is:

1.  How do I have to play a tune so it won't 'change' when I switch
oscillation speeds?

2. Is there a way to have the sound routines being handled by an
interrupt?  I tried to re-direct the timer/counter 1 interrupt vector to
handle the sound, but it turned out that this interrupt is called far too
seldom to make appropriate tunes.  Is it possible to program a 'free'
interrupt to occur regularly after an user-set time?  And if so, can
anyone tell me how this is done (maybe timer 0 could be programmed for
this)?

3.  In the above code, first the timer-period value is written to t1lr
(timer 1 low reload), then it is rotated to the right one bit, bit 7 is
set, and the result is written to t1lc (timer 1 low compare).  After that,
the value $50 is written to t1cnt (timer 1 control).  Although I use this
routine, I don't exactly understand _why_ all that needs to be set this
way.  Can anyone please explain me AS DETAILLED AS POSSIBLE how this audio
stuff works and why things need to be done the way as described above?
Also, can anyone explain me how the timer works in general (for what
exactly all the timer registers are for and how they are used)?

Lots of thanks in advance for any help and tips you people can give me.

Bye


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

--- In vmu-dev@egroups.com, Soeren Gust <sgust@i...>  wrote:
> It basically looks like it is base64 encoded, at least the charset
is
> the same and the linelengths match. After decoding I get a file with
> 3112 bytes which does looks completely different than the vms file.
> Are you sure you attached the correct file? Or is it encrypted by
the
> Dreamcast?

It's encrypted.  Alessandro and I did an experiment with a file
containing only a large amount of zeroes.  The attachment had the
expected length, but the data was not even periodical.  So it's
probably RC4 encrypted or something.


   // Marcus

> I've added a new folder in the files section, which contains three
> files, a .vmi and a .vms file and an email (including all headers) in
> which I attached this file.

It basically looks like it is base64 encoded, at least the charset is
the same and the linelengths match. After decoding I get a file with
3112 bytes which does looks completely different than the vms file.
Are you sure you attached the correct file? Or is it encrypted by the
Dreamcast?

Soeren

at http://www.dreamcast.com

I've found that there are some nasty graphical glitches when you run
the Powerstone games on SoftVMS (although the games themselves seem to
run quite happily)

It can be found (with dubious legality) at:

http://vmugames.virtualave.net/ani/powers.vmi

--- In vmu-dev@egroups.com, "Richard Munn (aka benjymous)"
<richard.munn@b...>  wrote:
> The zero'th bit indicates whether the file is copy protected or not
> (0 = copyable, 1=protected)
>
> and the first bit indicates file type
> (0 = data, 1=game)

Thanks for the info.  I'll update my page.  Any ideas regarding the
contents of $66-$67?


  // Marcus

I've added a new folder in the files section, which contains three
files, a .vmi and a .vms file and an email (including all headers) in
which I attached this file.

Okay, from my tests (with the web page mentioned in an earlier test) I
think Marcus' assumptions were right.  In other words the DC only
looks at the two least significant bits

(i.e. %0000000000000011)
                      ^^

The zero'th bit indicates whether the file is copy protected or not
(0 = copyable, 1=protected)

and the first bit indicates file type
(0 = data, 1=game)

therefore the possible types are:

0 (%00) = Copyable data
1 (%01) = Protected data
2 (%10) = Copyable game
3 (%11) = Protected game

I tested up to file type 6, and as far as I can tell they just cycle
round on a modulus of 4, indicating that only the two bits I mentioned
are actually used (so type 4 = type 0 ; type 5 = type 1 ; type 6 =
type 2 ; etc)

--- In vmu-dev@egroups.com, tyro@d...  wrote:
>  Hello.
>
> Just wanted to ask... are there any new DOS/Windows ports of Marcus'
VMU
> Emulator and / or Assembler?  I could really use an emulator with
correct
> timing, so I don't have to upload my game to a real VMU all the time
to
> see how it really looks.

Well, there's windows source in the main softvms archive, so I guess
you could compile your own ;-)

> Also, I heard something about an 'Official VMU Emulator' from SEGA.
Does
> anyone know where I could get that? ;)

Yeah, just contact sega, but be prepared to pay a few thousand for it
(it's part of the official DC devkit)

A guy from SOA has mentioned that he is trying to get Sega to release
the official VM devkits, but nothing's happened yet (see the links
section of this site for a link to the news story)

Hello.

Just wanted to ask... are there any new DOS/Windows ports of Marcus' VMU
Emulator and / or Assembler?  I could really use an emulator with correct
timing, so I don't have to upload my game to a real VMU all the time to
see how it really looks.

Also, I heard something about an 'Official VMU Emulator' from SEGA.  Does
anyone know where I could get that? ;)

Bye


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

Would it be possible to set up a server which accepts emails which it
then saves in a central database?

A user could then visit its website, select a message from a list, and
recieve it as an email.

This way, it would be easy for people to trade game saves using just a
Dreamcast, as the GameMail software that is part of the European web
stuff built into some games (Sonic Adventure and Rayman2 are two that
I know of) allows you to send and recieve attachments (i.e. game
saves)

It would probably also be handy to have the server scan incomming
mails to check that they do actually contain attachments (and that the
attachments are sega files) - which reminds me, what's the X-Mailer
tag for the GameMail stuff?

Also an option for people to rank saves that they've downloaded would
also be nice (i.e. 0..10)

Enter your vote today!  Check out the new poll for the vmu-dev
group:


So, you're on this list because you're
interested in programming for the
Dreamcast's VM, but what do you actually
own?

   o I own a Dreamcast and a VM
   o I've got a Dreamcast, but not a VM (which would be odd, but hey!)
   o I've not got a Dreamcast at all, just a VM
   o I don't own a Dreamcast or a VM


To vote, please visit the following web page:

http://www.egroups.com/polls/vmu-dev

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the eGroups
web site listed above.

Thanks!

I've added a second news folder in the links section for stories that
aren't really VM-related, but are still interesting.  New in is a
large report on Sega's new ISP, and the "free dreamcast" offer that
goes it.