soeren gust <sgus-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=29
> Is there a way to use writeflash (at .org $100) to write at the
FAT/DIRECTORY?

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:


	 ;; Firmware entry vectors

	 .org $100
fm_wrt_ex:
	 not1 ext,0
	 jmpf fm_wrt_ex
	 ret

	 .org $110
fm_vrf_ex:
	 not1 ext,0
	 jmpf fm_vrf_ex
	 ret

	 .org $120
fm_prd_ex:
	 not1 ext,0
	 jmpf fm_prd_ex
	 ret

	 .org $130
int3_btr_irq:
	 push ie
	 clr1 ie,7
	 not1 ext,0
	 jmpf int3_btr_irq
	 pop ie
	 reti


;[...]


	 ;; Low level access functions

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


bios_rflash:
	 fwcall $e027

bios_vflash:
	 fwcall $e01b

	 ;; Danger Will Robinson!
	 ;;
	 ;; This call gives direct access to the flashmem write
	 ;; function.  All safeguards will be bypassed.

bios_wflash:
	 fwcall $e024


	 ;; Write a quarter of a sector.
	 ;;
	 ;; trh,trl = sector number, acc = part (0-3)
	 ;; returns: 0 = ok, not 0 = not ok
write_page:
	 bp trh,7,.bad_sector
	 push 0
	 push trh
	 push trl
	 push b
	 push c
	 callf calc_page_addr
	 push ie
	 push ocr
	 push xbnk
	 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
	 pop ocr
	 pop ie
	 pop c
	 pop b
	 pop trl
	 pop trh
	 pop 0
	 ret
.bad_sector:
	 mov #$ff,acc
	 ret

	 ;; Read a quarter of a sector.
	 ;;
	 ;; trh,trl = sector number, acc = part (0-3)
read_page:
	 bp trh,7,.bad_sector
	 push 0
	 push trh
	 push trl
	 callf calc_page_addr
	 push ie
	 push ocr
	 clr1 ie,7
	 mov #$81,ocr
	 callf bios_rflash
	 pop ocr
	 pop ie
	 pop trl
	 pop trh
	 pop 0
	 ret
.bad_sector:
	 ret

calc_page_addr:
	 rorc
	 and #1
	 st $7e
	 rorc
	 st $7f
	 ld trl
	 rolc
	 and #$fe
	 or $7e
	 st $7e
	 ld trh
	 rolc
	 st $7d
	 ret



Not actually tested or anything...  :-)


   // Marcus

Is there a way to use writeflash (at .org $100) to write at the FAT/DIRECTORY?

As you can see in my previous mail I found out how the VMU to VMU
communication works. I now need opinions about connecting a VMU to a PC. My
currently used hardware is built around an Atmel AT90S8515 microcontroller
for synch/async conversion. It is connected to the RS-232 serial port on a
PC. One of my questions is if I should rewrite most of the software,
contruct a pcb layout, document and release it or if I should think about
an easier hardware to connect the VMU to the PC?  To build the current
version people have to be able to etch their own pcbs (most likely single
sided) and need a programming cable/software for the Atmel. All the
software I have written for it is Linux specific and not easy portable,
although I think I could make an Amiga version, too.  I doubt that the
hardware will support the VMU to DC communication mode without major
hardware changes. This is a major problem since I think this communication
is more powerful and faster than the VMU to VMU communication. An easier
hardware still needs to convert the 5V logic to 3V, although most modern
PC parallel ports are already 3V, I think. This problem will vanish as soon
as somebody finds out that the VMU inputs are 5V tolerant.  Another problem
is that most modern OSs support multitasking, so getting a reliable timing
is nearly impossible. The main reason why I chose the VMU to VMU
communication for my interface has proved to be wrong: even with the simple
VMU to VMU protocol it is possible to generate errors which require
reinitialisation of the VMU on a DC. Or is there a way to reformat the VMU
without a DC?

When connecting the VMU to a PC a connector is needed. So does anybody know
a source for those connectors? My current solution is a pcb with the
innards of a VESA local bus connector, anybody got other ideas?

Best regards, Soeren

PS: I just read the documentation on Marcus page about the maplebus, I will
need to make some experiments, but I think this is the way to go.

The protcol used in VMU to VMU communication:

With this information it is possible to send and receive files from the VMU.
I myself have built a complex hardware using a AT90S8515 microcontroller
connected to a RS-232 port on a PC. The only purpose of the microcontroller
is to translate between the synchronous communication of the VMU to the
asynchronous communication on the PC side providing a reliable timing.

VMU Pinout:

  1 Input:  1=activate external IO, 0=all pins are floating
  2 Input:  +5V Power from DC, turns off display and all keys
  3 Output: CLK
  4 Input:  delayed DATA
  5 Output: DATA
  6 Input:  Handshake, 1="waiting for data"
  7 Output: GND
  8 Output: GND
  9 Output: Handshake always 1 ??
10 Input:  DATA
11 Output: delayed DATA
12 Input:  CLK
13 ??      ??
14 Output: +3.5V Power

Pin 2:
If feeding pin 2 with 3.5V there is only 2.8V on pin 14, so I think the VMU
needs 5V here, then there are 3.5V on pin 14, just like with batteries only.
If the VMU gets its power from pin 2 the display blanks and the keys don't
show any reaction, so I think the DC takes full control over the VMU, the
normal communication does not work anymore.

Pin 4,11:
The delayed data is produced by the receiving end, perhaps to check if
the data is correctly transmitted. This feature seems to be quite common in
synchronous data communication, the Atmel AVR AT90S8515 does use it, too.
In my experiments the communication works even if pins 4 and 11 are not
connected.

Pin 6:
If the VMU is in file mode and this pin is 1, it switches into "waiting for
data" mode.

All pins are in 3V logic, I don't know if the VMU is 5V tolerant, so better
use voltage converters on the VMU inputs.

The protocol:

The basic protocol is syncronous serial, MSB first, triggered on the 0-1 edge.
Timing is 64us low and 64 us high on the clock line. A delay between bytes
is not necessary.

The protocol is base on communication blocks. The format of the blocks is
start_of_block type_of_block data ... data end_of_block.

Start_of_block is a byte between 0x10 and 0x1f or 0x50. The length of data is
encoded into the start_of_block, if is is 0x10-0x1f the length is
start_of_byte-0x0f, if it is 0x50 the length is 128.

Type_of_block length end_of_block meaning
      0x02          2     0xff     filetype+size
      0x06         12     0xff     name in VMU
      0x04        128     0x00     filecontents
      0x08          1     0xff     write into flash
      0x03         12     0xff     directory data offset 0x10

After receiving start_of_byte the VMU answers with 0xe0. After receiving
the end_of_block marker the VMU answers with 0x0c to continue to communication
or with 0x0a to abort the communication.

The order of blocks is important, wrong blocks are rejected with 0x0a, abort
communication.

Example communication sending a file to VMU

Pin6 -> 1, wait for Pin10 (DATA IN) = 0.

Send 0x11, wait for 0xe0.
Send 0x02.
Send filetype, 0xcc = minigame, 0x33 = saved file, see directory entry 0x00.
Send size in 512 byte blocks.
Send 0xff, wait for 0x0c.

Send 0x1b, wait for 0xe0.
Send 0x06.
Send 12 chars ASCII filename on VMU.
Send 0xff, wait for 0x0c.

While there are still bytes to send:

Send 0x50, wait for 0xe0.
Send 0x04.
Send 128 byte of file contents.
Send 0x00, wait for 0x0c.

Send 0x10, wait for 0xe0.
Send 0x08.
Send 0x00, meaning unknown.
Send 0xff, wait for 0x0c.

End while.

Send 0x1b, wait for 0xe0.
Send 0x03.
Send 12 bytes directory entry at offset 0x10: timestamp, filesize, header offset
Send 0xff, wait for 0x0c.

Send 0x10, wait for 0xe0.
Send 0x08.
Send 0x00, meaning unknown.
Send 0xff, wait for 0x0c.

Pin6 -> 0.

The file is now transferred.

WARNING:
It is very easy possible to produce inconsistencies in the internal VMU
structures. Make sure the filesize and header offset is correctly entered
in the 0x03 block. Only use the filetypes 0x33 and 0xcc in the 0x02 blocks,
using 0x00 results in loss of free blocks, using 0x01 results in unusable
VMU. All these problems should be correctable by reinitialising the VMU
in the DC.

Best regards, Soeren.

> currently the list is open for subscription to anyone, do
> you want me to change that so that subscription needs approval?

I think it's fine at the moment

If people start flooding the list with inane questions like "What are
Zip files" etc, then maybe we should consider it.

Another option is to set it as a moderated list, and give everyone who
posts sensible stuff the right to post without it needing moderating.

However, hopefully this won't have to happen (..yet..)

hi,

it would be a great idea to have alexander villagran on our
list. does someone have a direct contact to him. it seems
he filters his mails extensively.

also please tell me other people who would make a great
addition to the list. either invite them directly or mail
their emails to me or richard so we can do that.

currently the list is open for subscription to anyone, do
you want me to change that so that subscription needs approval?

leo.

> 1) it doesn't seem to care what file you throw at it. (The only file I
> had to hand was vmi.tgz and it made a vmi for that quite happily!) - I
> guess it would be fairly hard, if not impossible to work out whether a
> file is a vm file or not.

	 next step. i have already started the vms struct to read the
	 header, but wanted to finish the vmi creation part first as the
	 old version had severe bugs.

> 2) if the resource name is less than 4 characters, the
> program fails to
> make a checksum for it

	 i know, why i usually work with java. the data area is not
	 zero'd and so it creates a wrong checksum.

	 leo.

> i have finished a new version of the vmi file creator. it is now much
> better in making file names. howevr, it does rename files if
necessary.
>
> if you have spare time, try the web version please:

Lets see, here's some things I found:

1) it doesn't seem to care what file you throw at it. (The only file I
had to hand was vmi.tgz and it made a vmi for that quite happily!) - I
guess it would be fairly hard, if not impossible to work out whether a
file is a vm file or not.

2) if the resource name is less than 4 characters, the program fails to
make a checksum for it

Apart from that it seems to be working perfectly!

okay,

i have finished a new version of the vmi file creator. it is now much
better in making file names. howevr, it does rename files if necessary.

if you have spare time, try the web version please:

http://virtuamunstaz.de/vmi.jsp

leo.

le-@... wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=20
>  i am solely talking about the VMU interrupts. i wondered what
>  the DC and VMU were talking about during the init phase and
>  if there is way to have a look into that.

The VMS will get a RFB interrupt (vector $43) when a Maple Bus packet
is received (see <URL:http://marcus.mangakai.org/dc/maplebus.html>),
provided that all registers are set up appropriately of course.  I have
written a small test program to look at the packets, but somehow I seem
to have missed something in the setup as I don't actually get any
packets...


   // Marcus

> Are you talking about SH4 interrupts or Potoato interrupts now?  (Note
> that both the DC and the VMS have dedicated hardware to handle the
> communication.  On the DC, you have DMA to do the communication, on the
> DC the "Work RAM" memory is used for incoming and outgoing messages.
> The actual message exchange is all done in hardware.

	 i am solely talking about the VMU interrupts. i wondered what
	 the DC and VMU were talking about during the init phase and
	 if there is way to have a look into that.

	 leo.

"matthias l. jugel" <le-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=17
> if it is possible, then the vmu's should be part of the
> boot protocol of the dc and it should be possible to
> program it in a way to tamper with it. so that is what
> i was asking, has anyone an idea which interrupts are
> triggered during communication?

Are you talking about SH4 interrupts or Potoato interrupts now?  (Note
that both the DC and the VMS have dedicated hardware to handle the
communication.  On the DC, you have DMA to do the communication, on the
DC the "Work RAM" memory is used for incoming and outgoing messages.
The actual message exchange is all done in hardware.


   // Marcus

Here's the response I've received from PlanetWeb.

>From: Andrew Chiles <achiles@...>
>To: "'Wayne Bartnick'" <wbartnick@...>
>Subject: RE: Question...
>Date: Fri, 25 Feb 2000 15:18:31 -0800
>
>Hi Wayne,
>
> I will have to get back to you on that because the developer who
>usually works on the VMU code for our product is off in Japan right, but he
>will be returning shortly. The GIF tool is excellent and we all love it
>over
>here. Thanks
>
>Andrew Chiles
>Assistant Producer
>Planetweb, Inc.
>http://dreamcast.planetweb.com
>
>
>-----Original Message-----
>From: Wayne Bartnick [mailto:wbartnick@...]
>Sent: Thursday, February 24, 2000 6:40 AM
>To: achiles@...
>Subject: Question...
>
>
>Andrew,
>
> >Thanks Wayne for the tool. Let us know if you need any information
> >on new browser upgrades to help you with your tools.
>
>I do have one question...  What can you tell me about a "compressed" VMI
>file?  I'm familiar with the pointer style 108 byte version that points to
>the actual VMS, but I've run across this other version, in which there's an
>INI-style header and the actual VMS data, compressed or encoded or
>something.
>
>Is that GIF tool working out for you ok?  Is there anything to
>fix/add/change?
>
>Thanks,
>
>Wayne Bartnick : VMU Animator
>http://www.flinet.com/~amorphis/vmu
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com

______________________________________________________

quite interesting, but what i had in mind, when asking
for infos about the dc-vmu communication was more on
the higher software level.

have you read that article about the battery swap trick
on ncs: http://www.ncsx.com/ncs110199/ncs1101m.htm ?
there is a little comment in the right box at the lower
end talking about an idea to be able to trigger the
dc-gdrom-motor via the vmu.

i would believe that you could use a vmu or assemble a
similar device that changes the way the dc behaves if
i see it, but these guys seem to work on it.

if it is possible, then the vmu's should be part of the
boot protocol of the dc and it should be possible to
program it in a way to tamper with it. so that is what
i was asking, has anyone an idea which interrupts are
triggered during communication?

i thought it might be an idea to write a small vmu game
that rewrites the interrupt pointers so we could capture
what happens.

leo.

> > a) packed vmi
> >
> > has someone gotten into that? I found one of those files on my upload
> > (nothing gets lost ;-). is the method of packing known?
>
>Not yet,  I've got the dreamfiles.com snaky game in packed .VMI format.
>  Perhaps if someone with a nexus card could download it, and send me
>the actual decompressed .VMS file it might be possible to work it out
>(although I'm no genius for code cracking!)

I've just sent an email out to someone I've met over at PlanetWeb (Andrew
Chiles, Assistant Producer, US DC Browser).  He told me that he would help
me out with anything I wanted to know concerning the US browser.  Even if it
doesn't support compressed VMI files (does anyone know if it does?), I'm
sure they've got some info on it, but whether or not he'll give it to me is
another story.  It could be encrypted, too, and it would defeat the purpose
just to hand the method over, as we would be able to edit our high scores
for Tokyo Extreme! (wow...)

At the very least, I could do the Nexus thing.  That way, we all could get
our heads into it.

> > ... and for the tools the coders should write something :-)
>
>Yeah, some nice simple tutorials for the animator / emulator /
>assembler / disassembler would be nice guys *grin*
>
>(although I've got an email I wrote with some simple explanations
>somewhere, which I'm sure could be re-shaped to fit)

Yeah, yeah, yeah...  I've had these fantastic visions of thorough PDF help
files and such.  Now, where did I put all that spare time I had lying
around... :P

Wayne Bartnick : VMU Animator
http://www.flinet.com/~amorphis/vmu
______________________________________________________

> they continue to astound me. Not only do they have one of the
cheapest web browers, but now this!

I've always thought you could make a fortune selling on old refurbished
486s and A1200s with Free net accounts - pick something up for next to
nothing from newspaper small ads, and sell on as an "internet computer"
for alot less than the cost of a dreamcast! *gig*

>One problem was that the delay time was 700mSec. I'm not sure if this
>is round trip or one-way, but it could make talking very frusterating

Is that delay for sound and video, or just the video? (If you can get
continual sound, but webcam style pictures, I'm sure it would be
acceptable)

Really the biggest problem with NetCams, is sound quality (if you've
ever tried to play real video / quicktime tv station feeds you'll know
how bad the audio quality can be!


>The picture showed a speaker/microphone headset that plugged
>in like a VMU.

There's a picture of a DC Mic on page 24 of the latest UK Official DC
Mag. (The mag says it comes bundled with the game "Seaman" in Japan.
The one here looks like the kind of mic you get on hands-free
headphones (a spherical mic with a blue-green foam cover, that is
attached to a VM like card via an inch (or so) long arm.

"matthias l. jugel" <le-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=12
> a) packed vmi
>
> has someone gotten into that? I found one of those files on my upload
> (nothing gets lost ;-). is the method of packing known?

Not yet,  I've got the dreamfiles.com snaky game in packed .VMI format.
  Perhaps if someone with a nexus card could download it, and send me
the actual decompressed .VMS file it might be possible to work it out
(although I'm no genius for code cracking!)

> b) FAQ answers
>
> okay richard, you asked for it :-)

Cheers - I've pasted them in, and am uploading now ;-)

> no, i don't want to answer the rest of the booyaka questions

I don't blame you.  I know all the answers to them, I just haven't yet
found the time to sit down and answer them ;-)

> ... and for the tools the coders should write something :-)

Yeah, some nice simple tutorials for the animator / emulator /
assembler / disassembler would be nice guys *grin*

(although I've got an email I wrote with some simple explanations
somewhere, which I'm sure could be re-shaped to fit)

One problem was that the delay time was 700mSec. I'm not sure if this is round trip or one-way, but it could make talking very frusterating (remember long distance that was routed via satellite? It's delay wasn't as bad but it was still tough to talk. Now it's all done with fibre and the delay is gone)

The picture (which was in the latest issue of the print version, but not the online article) showed a speaker/microphone headset that plugged in like a VMU. The camera plugged directly into the dreamcast.

- john
 

a) packed vmi

has someone gotten into that? I found one of those files on my upload
(nothing gets lost ;-). is the method of packing known?

b) FAQ answers

okay richard, you asked for it :-)

1.5
Yes, you can play vmu games on your computer. All you need is a VMU
emulator,
install it on your computer and download the games. You can get the
emulator
here (link to the tools part).

When downloading games, make sure you download the .VMS file and not
the link
file (also known as .VMI) which only points to the game file.

Some of the games may behave slightly different as on the real VMU as
the
emulator is usually faster than its real counterpart.

1.6
The VMU's central processing unit consists of a chip that is labeled
with the
the manufacturer, the product code name and some product identification
numbers. So if you open your VMU and have a look at the chip you will
find
some text printed on it that reads:

Manufacturer SEGA  JAPAN
Product Code   POTATO
Product ID 315-6124-03
		 5J49   8LGJ

As you can see the product code name is "POTATO" and now you have your
answer!

3.6
Most programs and data you can download from the internet is delivered
in so-
called packages or compressed archives. There are several types of
packages
and archives. The most common compression used in the Windows world is
ZIP.

A .ZIP file usually contains several files and in order to uncompress
these
files from the archive you need a program that can do the job. One of
the most
common for Windows is called "WinZIP" and can be downloaded from
http://www.winzip.com/. You can download an evaluation version there.

In case you want to look at other programs that do the job you might
want to
have a look here: http://winfiles.cnet.com/apps/98/compress.html

For DOS users there exists a program called pkzip/pkunzip and
UNIX/Linux users
can use the free zip/unzip utilities available.

After you have been able to unpack the files (make sure you put them in
a
separate directory!) you will find an executable you can click on :-)

--
no, i don't want to answer the rest of the booyaka questions ... and
for the
tools the coders should write something :-)

leo.

"richard munn (aka benjymous)" <richard.mun-@...> wrote:
original article:http://www.egroups.com/group/vmu-dev/?start=10
[...]
> the obvious sollutions would be some kind of run-line compression
(i.e.
> instead of writing %11111111 for eight black pixels in a row, you can
> encode "eight on" by some means) or possibly some form of huffman
> compression (Patent problems withholding..).
>
> However, is the VM up to the job of decompressing such data on the
fly?

You always write to the LCD in RC clock mode, so there should be no
problem there.  RLE decompressing isn't much tougher than just copying
the data.

   // Marcus

One thing I've added to the FAQ I've been working on (and of course I
welcome answers from everyone else...) is the subject of how many
frames of animation a VM can hold (Using the converted LCD file
approach).

I won't go though the whole thing, but basically my maths leads me to
believe it's roughly 300 frames using current techniques, or 500 if the
.vms application can read a separate file on the VM

[you can read the faq @ http://rvmu.port5.com/faq.html ]

Anyway, this has led me to wonder about compressing the frames on the
VM.

the obvious sollutions would be some kind of run-line compression (i.e.
instead of writing %11111111 for eight black pixels in a row, you can
encode "eight on" by some means) or possibly some form of huffman
compression (Patent problems withholding..).

However, is the VM up to the job of decompressing such data on the fly?

Soeren Gust <sgust@...> took my results and did a better
interpretation. I haven't worked on it in a while, so here's what he
wrote:



Hello John!

After finding your page about VMU development I decided to have a try
myself.
I got a VMU and started to play with the protocol using your page on the
01/21/00. I agree with the basic hardware protocol, synchronous serial,
MSB
first, triggered on the 0-1 edge. To translate this protocol into
something
more useful I used a AT90S8515 microcontroller from Atmel. This
microcontroller has a builtin UART which I use to communicate with the
PC.
There is also one synchronous serial port which I use to receive data
from
the VMU. Sending data to the VMU is done by hand, timed for 64us high
and
64 us low just like your page says. One of the things I want to know is
how
much time do I have to wait between bytes? Since I currently don't use
any
handshaking I lose bytes if I send them too fast. I think I lose them on
the UART receiver in the Atmel.
There is also currently no way to switch the VMU into receive mode by
the PC,
so as an interface it is not yet usable. I prefer the microcontroller
solution
to the direct PC connection because of problems with reliable timing, I
mainly
use Linux on my PC.
I think I have figured out more about the protocol than you put on your
page,
but I could be completely wrong. How the communication ends is a
complete
mistery to me, could you please send me more info on that? I can send a
complete file, but then there are still 2 pixel on the progress bar,
look at
the end of this mail for an example.
I disagree with the meaning on some of the pins especially with the
direction
of the delayed data pins. The levels look like 3V logic, I don't know
if they
are 5V tolerant, I have put buffers in between them and the Atmel which
I use
which 5V because I don't know how much power I can get at 3.5V out of
the
VMU and I get already battery low warnings.

VMU Pinout:

  1 Input:  1=activate external IO, 0=all pins are floating
  2 Input:  +5V Power from DC, turns off display and all keys
  3 Output: CLK
  4 Input:  delayed DATA
  5 Output: DATA
  6 Input:  Handshake, 1="waiting for data"
  7 Output: GND
  8 Output: GND
  9 Output: 1 ??
10 Input:  DATA
11 Output: delayed DATA
12 Input:  CLK
13 ??      ??
14 Output: +3.5V Power

Pin 2:
If feeding pin 2 with 3.5V there is only 2.8V on pin 14, so I think the
VMU
needs 5V here, then there are 3.5V on pin 14, just like with batteries
only.
If the VMU gets its power from pin 2 the display blanks and the keys
don't
show any reaction, so I think the DC takes full control over the VMU,
the
normal communication does not work anymore.

Pin 4,11:
The delayed data is produced by the receiving end, perhaps to check if
the data is correctly transmitted. This feature seems to be quite
common in
synchronous data communication, the Atmel AVR AT90S8515 does use it,
too.

Pin 6:
If the VMU is in file mode and this pin is set, it switches into
"waiting for
data" mode.

Communication:
The communication between VMUs seem to be block oriented. Legal start
block
markers seem to be 0x10-0x1f. They just seem to tell how many real data
bytes
are in the block, one more than the lower nibble. After sending the
start
marker the receiver answers with 0xe0. The next byte contains the type
of the
data, 02=filetype+size, 06=name, 04=data, 08=???. Following are the
data
bytes.  The last byte of every block can contain a new start marker, or
0x00/0xff which means that the sender expects an answer. Legal answers I
know are 0x0c meaning continue and 0x0a which means abort and start
again.
0x0a happens if the file is too big or there does already exist a file
with
the same name or the wrong type of block was received. A special start
marker
is 0x50, this means a blocksize of 128 bytes. 0x51-0x5f seem to have a
meaning,
too, but I don't know which. The order of blocks is important, the VMU
answers
0x0a if the block was received correctly, but was not the right type.

Example of communication how I understand it: A->B
A: 0x11 blocksize=2
B: 0xe0 recognized blockstart
A: 0x02 type:fileinfo
A: 0x03 filetype, 0x03=data, 0xcc=vmu game
A: 0x01 size in 512 byte blocks
A: 0xff End of block, waiting for answer
B: 0x0c OK, continue or 0x0a out of memory

A: 0x1b blocksize=12
B: 0xe0 recognized blockstart
A: 0x06 type:filename
A: 12 bytes filename
A: 0xff End of block, waiting for answer
B: 0x0c OK, continue or 0x0a file already there

start repeat 4 times

A: 0x50 blocksize=128
B: 0xe0 recognized blockstart
A: 0x04 type:data
A: 128 bytes data
A: 0x00 End of block, waiting for answer
B: 0x0c OK, continue

A: 0x10 blocksize=1
B: 0xe0 recognized blockstart
A: 0x08 type:?
A: 0x00 ?
A: 0xff End of block, waiting for answer
B: 0x0c OK, continue

end repeat 4 times

And now I am stuck, there are still 2 pixel displayed on the progress
bar,
perhaps the VMU is waiting for the timestamp? Sending any more blocks
leads
to 0x0a and back to "waiting for data". Just sending any bytes without
legal
block structure can even turn the VMU into sleep mode, or it can hang
completely ignoring any more commands.  I only have one VMU and no DC
so I
don't have any files on VMU to send. I think I have to rent a DC and
save a
game on my VMU for future tests.

Best regards, Soeren.

another question that is bugging me.

has anyone apart from john maushammer had a look at the communication or
what happens after the dc is powered up? it would be interesting to see
what they talk :-)

leo.

> Hmm In this case there is a file on the VMS which contains the dial up
> information... Anyone want to build a .cgi script which takes in the
> user's provider details on a web form and then makes a .VMS file which
> can be downloaded?

	 i am not sure it's in the file on the VMU. i think there is
	 some memory on the modem or on the dc itself that is used
	 to store the information. however, if i could get hold of
	 one of the files the browser does store on the vmu i could
	 have a go and look for the data and how to set it.

	 leo.

> what may be of interest to european dc users is that you can change
> the provider to use for dialling in with that american browser! and
> after
> you switched back to the DreamKey disc the european browser uses that
> new provider to connect to the net. one drawback: you cannot go into
> the DreamArena. at least not in germany, where viag interkom uses a
> private
> 192.168.* net for the dc-dialin and probably firewalled/proxied all
the
> connections to the net.


Hmm In this case there is a file on the VMS which contains the dial up
information... Anyone want to build a .cgi script which takes in the
user's provider details on a web form and then makes a .VMS file which
can be downloaded?

hi,

has anyone of you tried to run imported discs using the swaptrick?
i did that when trying the us-dc-mag gdrom with the new 1.1 browser
they distributed there. it's basically resetting the clock and
then swapping the discs after they have spindled down.

anyway, what i found was that the us browser does download vmu files
with a european SEGA checksum. either they have taken off the
restriction
or the browser behaves differently in a european dc.

actually the ACCESS browser in europe is much better in quality than
that american one, at least in my opinion. it tried to play around with
borders and does not have these nice R1/L1 menues.

what may be of interest to european dc users is that you can change
the provider to use for dialling in with that american browser! and
after
you switched back to the DreamKey disc the european browser uses that
new provider to connect to the net. one drawback: you cannot go into
the DreamArena. at least not in germany, where viag interkom uses a
private
192.168.* net for the dc-dialin and probably firewalled/proxied all the
connections to the net.

it's worth getting the march issue of dc-mag from the us as it contains
some
other nice demos and the chu-chu and sega swirl game ;-)

leo.

Works for me...  :)

>... just to see whether posting works properly via email
>
>=====
>--
>    _  Richard Munn  RAMTronics Software
>_ //  www   : http://come.to/ramtronics
>\X/   email : richard.munn@...
>__________________________________________________
>Do You Yahoo!?
>Talk to your friends online with Yahoo! Messenger.
>http://im.yahoo.com
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

... just to see whether posting works properly via email

=====
--
    _  Richard Munn  RAMTronics Software
_ //  www   : http://come.to/ramtronics
\X/   email : richard.munn@...
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

You'd have to make sure that you describe what the option does, as
having two different vms filename fields is bound to confuse people!!

hi,

let me start with something i'm working on ;-)

thanks to marcus i will extend the vmi creator to be able to read and
check the corresponding vms files. what i have not yet decided is
whether
to let the user set the name for the file on the VMU or derive it
magically. let me explain:

if you have a game file, like "TETRIS.VMS" you may want it to appear on
the vmu as "TETRIS.GAM" and the vmi be names "TETRIS.VMI". all that is
straightforward. i could accept any file names as vms-file and cut off
any extensions rename the original file to something .VMS and create the
corresponding .VMI and set the original file name in the VMU filename
field.
so "TETRIS.GAM" as the game file would then be renamed to "TETRIS.VMS".

it gets even more complicated ;-)

let us assume one of the uploads we had: "SONICADV_INT". there is no
extension i could cut off but the ressource should be named
"SONICADV.VMS"
and the original name should only appear in the .VMI file name field.

looks like i will have to let the user tell me what the 8 characters for
the ressource name should be and rename the file in any case.

comments?

leo.