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.

okay, on the page:

http://rvmu.port5.com/a/

I've set up 16 links to .vmi files with the file type field $0000 up
to $000f.

They're all game files (just a simple animation I made in a couple of
minutes), so I don't know if the browser will refuse to download the
ones that are filetyped as data (who can tell until we try..)

I'll test it tonight (local calls cheaper at weekends) but I'd welcome
it if some other people could test it too (especially on the US
browser, as I'd bet it may work slightly differently to the euro
one..)

> > No windoze here, man ;-)
> >
> > I'll use it if you produce an Amiga port, or open source it so
someone else
> > can!
>
> 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 ;-)

> 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?)

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

> > 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

Uh... guess I simply read your code wrong, then.  At first glance it
looked to me as if you were pushing the contents of Rom location $0123 and
$0124 onto the stack (which contain #$01 and #$20, the two values directly
following the #$21 value of the JMPF instruction), while actually you were
just pushing the lo- and hi-byte of the 16 bit value #$0123 onto the
stack...

The usage of your Assembler still confuses me at times.  Is there a manual
available somewhere that describes its usage a little more detailled?

> 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.

Yup... now I see. ;)

Bye


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

On 20 Mar 00, richard.munn@... (Richard Munn (aka benjymous)) wrote:

>
> > BTW, why don't you just use my DCI_VMI program if you want to quickly
> > generate a .VMI file for an existing .VMS file?  That should be as easy as
> > it gets... after execution, simply delete the .DCI file and keep the .VMI
> > file. ;)
> >
> >         http://www.franken.de/users/deco/myfiles/myfiles.html

> No windoze here, man ;-)
>
> I'll use it if you produce an Amiga port, or open source it so someone else
> can!

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.

But wasn't there a 'DOS Emulator' for Amiga available somewhere? ;)

Bye


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

--- In vmu-dev@egroups.com, "Wayne Bartnick" <wbartnick@h...>  wrote:
> [PETER MOORE]: No, Aaron, that is purely for the download of digital
music
> files. We will still obviously have the VMU which can save games and
that
> has got a 128k memory, as you may know, and gamers can save games on
their
> VMU and music on their MP3 player.

Not really surprising, as Shinobi (the libraries on which virtually
all games are built) can only handle cards with sizes up to 1 megabyte
(supported sizes are 128K, 256K, 512K and 1M).


   // Marcus

Hey guys,

Just reading through transcripts of the teleconference with Sega yesterday
morning, regarding their new Sega.com business model, and here's the answer
we were afraid of:
------------------
[KNOXVILLE REGISTER]: Yes, I just have one more question about the MP3
memory device will that also be able to save your games as well as MP3s?

[CHARLES BELLFIELD]: Peter...

[PETER MOORE]: No, Aaron, that is purely for the download of digital music
files. We will still obviously have the VMU which can save games and that
has got a 128k memory, as you may know, and gamers can save games on their
VMU and music on their MP3 player.
------------------
Wayne Bartnick : VMU Animator
http://www.vmudev.org
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Marcus Comstedt wrote:

> --- In vmu-dev@egroups.com, Soeren Gust <sgust@i...>  wrote:
> > I did some tests by error when developing my SerialToVM, filetype 0
> > means no directory entry, but the blocks are allocated in the FAT,
> > filetype 1 was not erasable with the VM (System Error 8b) and any
> other
> > file upload aborted when sending the header.
>
> Hum.  Are you sure this is the _VMI_ filetype?  It's not the same as
> the one used in the VMS directory (0x33 = data, 0xcc = game).

Good point. I'm just talking about VMU files. I noticed an interesting thing
last night. There are two VMU routines that I've encountered (so far) that
search through the file directory. The "count files" function counts all
files that are not type 0. The "select file based on index" function (i.e.
lookup the 5th file) only counts files of type $33 or $CC. The two use
incompatible ways of counting files. If other file types are to be
supported, then the VMU won't handle them well. It will include the odd-type
file in the count, but then not list it. When you try to select a file
beyond the listed files (but below the total file count), you'll set error
bit $80. (hope this description makes sense).

Also, (and it may say this in the manual), the white-on-black characters
indicates a file is copy-protected.

john

update to previous table:
** FLASH_ERRORCODE: bit 7 is set if file index is too big and can't find
filename.
      Since the count counts non-zero files and the file lookup only counts
$33 or $cc files, if
      a non-zero non-$33 non-$cc file type exists, then you'll get this
error.

--- In vmu-dev@egroups.com, Soeren Gust <sgust@i...>  wrote:
> I did some tests by error when developing my SerialToVM, filetype 0
> means no directory entry, but the blocks are allocated in the FAT,
> filetype 1 was not erasable with the VM (System Error 8b) and any
other
> file upload aborted when sending the header.

Hum.  Are you sure this is the _VMI_ filetype?  It's not the same as
the one used in the VMS directory (0x33 = data, 0xcc = game).


   // Marcus

Soeren Gust wrote:

> > I think I'll set up a page, and make .VMI files with types from 0 to
> > about 10, and see how a dreamcast handles them
>
> I did some tests by error when developing my SerialToVM, filetype 0
> means no directory entry, but the blocks are allocated in the FAT,
> filetype 1 was not erasable with the VM (System Error 8b) and any other
> file upload aborted when sending the header.

Cool. You saw an error. I've been working out the meanings for this error
bit, and a lot of it is still guesses, but here's what I think that number
means:

  05c     FLASH_ERRORCODE is a bit-mapped error register
** FLASH_ERRORCODE: bit 7 is an error
** FLASH_ERRORCODE: bit 6 describes FLASH @ 1FE44: 1 iff (FLASH @ 1FE44 ==
$FF) || (FLASH @ 1FE45 != 0)
** FLASH_ERRORCODE: bit 5 describes location of FAT-> 0=$00FE [default]
**                                           1=otherwise     [routine seems
flawed]
** FLASH_ERRORCODE: bit 4 describes location of root directory (1=bad)
** FLASH_ERRORCODE: bit 2 describes a bad directory file (links in FAT bad)
** FLASH_ERRORCODE: bit 1 is set if you have no files
** FLASH_ERRORCODE: bit 0 is an error

Error 08b is bits 7, 4, 1, and 0. Two of these are unknowns and it says you
have no files and that the root directory is in a bad place. Huh. That
doesn't make much sense, so maybe there are other errors possibly generated
when erasing a file (haven't gotten that far).

John.

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

Ok, then Maple Bus is not possible with the AT90S8515 I used. Perhaps its
easier to program a FPGA to do the Packet handling in hardware and keep the
Atmel, but I have never done anything like that. Any ideas for more
powerful microcontrollers usable for hobbyists? Nearly everthing is only
available in QFP or smaller cases, so more difficult to handle.

Soeren

> I think I'll set up a page, and make .VMI files with types from 0 to
> about 10, and see how a dreamcast handles them

I did some tests by error when developing my SerialToVM, filetype 0
means no directory entry, but the blocks are allocated in the FAT,
filetype 1 was not erasable with the VM (System Error 8b) and any other
file upload aborted when sending the header.

Soeren

Just read this this morning:
http://cnnfn.com/2000/04/03/technology/sega/


Here's the quick summary:
------------------------------------------------------------
** "FREE" dreamcast **
Sega will offer a rebate of $200 -- the cost of the Dreamcast game
console -- to gamers who sign up for two years of SegaNet Internet
service. It expects to launch this service in the fall, at a cost of
$21.95 a  month.Subscribers will also get a free keyboard.

** New VMU **
Sega also plans to have a specially designed MP3 player that inserts
into the Dreamcast console, in the space that is now occupied by the
visual memory unit, for downloading music from the Internet. The
portable device will cost below $100 and its 64 megabytes of disk space
will store about two hours of music.
------------------------------------------------------------

If you notice, this doesn't say the MP3 player will be a VMU, just that
it fits in the same slot (so why the cord coming out the side that we
saw in the picture?). I really doubt it'll have 64MB of _disk_ space;
more probably flash.

Well, let's hope that the VMU continues to live as a gaming machine.

-- john

> > but then what does file type 2 mean?
>
> Theory: The file type could be a bit field with two bits, with
> 1/0 meaning copy protect on/off and 2/0 meaning game/data.  I can't
> test this theory though as my DC isn't networked.

I think I'll set up a page, and make .VMI files with types from 0 to
about 10, and see how a dreamcast handles them

--- In vmu-dev@egroups.com, "Marcus Comstedt" <marcus@i...>  wrote:
>  Since the eGroups software was updated this weekend, the links in
the
> "VM News and Articles" folder in the Vault (now "Files") don't work
> any more. I suppose the folder should be moved to the "Links"
> section,

yeah, I noticed this, and have deleted the old news folder and made a
new one in links.  Also all the old links seem to have got lost, so
I'd welcome everyone to re-add their pages into the links!

>  but I couldn't find any way to modify existing entries.
> Perhaps the Owner or Moderator will be able to do it.

Well, the power is out there to make anyone a moderator.... *grin*

--- In vmu-dev@egroups.com, "Richard Munn (aka benjymous)"
<richard.munn@b...>  wrote:
> 2) The .VMI files' VMS type (field $64 - 67) contain the values:
>      $02 $00 $00 $70  for SCMINI001.VMI
> and  $02 $00 $00 %dd  for SCMINI002.VMI
>
> This leads me to suspect that field $66/$67 means something separate
> (and that the file type and it
> are both two byte numbers.)

Sounds reasonable.

> but then what does file type 2 mean?

Theory: The file type could be a bit field with two bits, with
1/0 meaning copy protect on/off and 2/0 meaning game/data.  I can't
test this theory though as my DC isn't networked.

As for $66/$67, $7000 and $dd00 looks like file sizes.  Is it the same
as in $68/$69?


> 3) Both .VMSs set the OCR to $cd (lcdis currently only recognises
$a1,
> $81, $a3 and $92)

bit 6, 3 and 2 are no care, so $cd is the same as $81.


> Trickstyle Jr (The minigame within the game Trickstyle, Found on
some
> foreign web site - I'll try and remember where..)
>
> sets the OCR to $4d and $cd

$4d is the same as $01.  That's the first time I've seen someone use
the half-speed mode...  :-)


   // Marcus

Thanks for the comments. I am, of course, working on version 1.03, and so
far the changes look like this:
  *   Rel 1.02 - Added support for "BPC d9,b3,r8" instruction.
  *            - Changed LABELS to better describe interrupts (according to
Marcus)
  *            - Added "FONT8," directive for printing 8-bit-wide font tables

  *            - fixed so that fonts and graphics can be labeled
  *            ERRATA- this release mistakenly labelled 1.01 in executable
  *   Rel 1.03 - fixed wrong commenting on MUL and DIV instructions:
  *              was "; B:ACC:C <- ACC:B * C"   now "; B:ACC:C <- ACC:C * B"
  *              was "; ACC:C remainder B <- ACC:B / C"
  *              now "; ACC:C remainder B <- ACC:C / B"
I don't have enough things in it to release yet, but I'll work on some of
your suggestions. I'll also be adding in more BIOS variables (as listed in
my last post).


"Richard Munn (aka benjymous)" wrote:

> Suggestions for LCDis:
>
> Bug: V1.02 still says v1.01 in its "comment line" when you run it
>
> ----
>
> You could automatically use the label start: for the memory address
> refered to by the JMPF at reset: (this would make it easier to find
> where execution starts)

Currently, all labels with english names (i.e. not "L1234") are pre-defined.
I've been thinking about defining labels based on an analysis of the code
(like the JMPF), but I'd like to be able to make it smarter and extend it
more (like recogonize certain segments of code as a particular routine).
This might take a while.

>
> ----
>
> It would also make sense to split out and comment the VM description
> lines (at $0200), so that you'd have something like:
>
> 0200-  |     BYTE   "TRICKSTYLE JR.  "                 ; File comment
> on VM (16 bytes)
> 0210-  |     BYTE   "TRICKSTYLE JR. VMU GAME.        " ; File comment
> on Dreamcast (32 bytes)
> 0230-  |     BYTE   "TRICKSTYLE.VMS  "                 ; Umm, can't
> remember offhand (16 bytes) (Marcus?)
>
> instead of:
>
> 0200-  |     BYTE   $54,$52,$49,$43,$4b,$53,$54,$59  ;ascii "TRICKSTY"
> 0208-  |     BYTE   $4c,$45,$20,$4a,$52,$2e,$20,$20  ;ascii "LE JR.  "
> 0210-  |     BYTE   $54,$52,$49,$43,$4b,$53,$54,$59  ;ascii "TRICKSTY"
> 0218-  |     BYTE   $4c,$45,$20,$4a,$52,$2e,$20,$56  ;ascii "LE JR. V"
> 0220-  |     BYTE   $4d,$55,$20,$47,$41,$4d,$45,$2e  ;ascii "MU GAME."
> 0228-  |     BYTE   $20,$20,$20,$20,$20,$20,$20,$20  ;ascii "        "
> 0230-  |     BYTE   $54,$52,$49,$43,$4b,$53,$54,$59  ;ascii "TRICKSTY"
> 0238-  |     BYTE   $4c,$45,$2e,$56,$4d,$53,$20,$20  ;ascii "LE.VMS  "
>

Yep, easy to do!

>
> ----
>
> Also, you could use
>
> BYTE "text"
>
> rather than
>
> BYTE $74,$65,$78,$74  ;ascii "text"
>
> when all the characters are in the normal printable range (i.e.
> 31<x<127)
>

I've been thinking of this, and maybe breaking the line on a '\0' character
(for readability).

>
> (although it might make sense to have an option switch to activate
> this, as it might make the listing messy if there is a mixture of
> printable and non printable characters within a large block.
>

Thanks for the feedback!

John

Suggestions for LCDis:

Bug: V1.02 still says v1.01 in its "comment line" when you run it

----

You could automatically use the label start: for the memory address
refered to by the JMPF at reset: (this would make it easier to find
where execution starts)

----

It would also make sense to split out and comment the VM description
lines (at $0200), so that you'd have something like:

0200-  |     BYTE   "TRICKSTYLE JR.  "                 ; File comment
on VM (16 bytes)
0210-  |     BYTE   "TRICKSTYLE JR. VMU GAME.        " ; File comment
on Dreamcast (32 bytes)
0230-  |     BYTE   "TRICKSTYLE.VMS  "                 ; Umm, can't
remember offhand (16 bytes) (Marcus?)

instead of:

0200-  |     BYTE   $54,$52,$49,$43,$4b,$53,$54,$59  ;ascii "TRICKSTY"
0208-  |     BYTE   $4c,$45,$20,$4a,$52,$2e,$20,$20  ;ascii "LE JR.  "
0210-  |     BYTE   $54,$52,$49,$43,$4b,$53,$54,$59  ;ascii "TRICKSTY"
0218-  |     BYTE   $4c,$45,$20,$4a,$52,$2e,$20,$56  ;ascii "LE JR. V"
0220-  |     BYTE   $4d,$55,$20,$47,$41,$4d,$45,$2e  ;ascii "MU GAME."
0228-  |     BYTE   $20,$20,$20,$20,$20,$20,$20,$20  ;ascii "        "
0230-  |     BYTE   $54,$52,$49,$43,$4b,$53,$54,$59  ;ascii "TRICKSTY"
0238-  |     BYTE   $4c,$45,$2e,$56,$4d,$53,$20,$20  ;ascii "LE.VMS  "

----

Also, you could use

BYTE "text"

rather than

BYTE $74,$65,$78,$74  ;ascii "text"

when all the characters are in the normal printable range (i.e.
31<x<127)

(although it might make sense to have an option switch to activate
this, as it might make the listing messy if there is a mixture of
printable and non printable characters within a large block.

I've been playing with an assortment of VM games, and have come across
the following notes, and things which show possible errors in what is
currently accepted (and since all of these games would have been made
using official devkits, that seems very likely)

----

Soul Calibur (Japanese) VM Games:

1) Neither game is a round number of blocks (Marcus has explained that
this isn't a problem - he just likes to pad out so that he's got
control over what goes at the end, and I agree that it makes sense)

2) The .VMI files' VMS type (field $64 - 67) contain the values:
      $02 $00 $00 $70  for SCMINI001.VMI
and  $02 $00 $00 %dd  for SCMINI002.VMI

This leads me to suspect that field $66/$67 means something separate
(and that the file type and it
are both two byte numbers.)

but then what does file type 2 mean?

(for those who don't remember, the currently understood values are
0=data and 3=game.  This would suggest that there are also 1 and 2
values, as seen here)

3) Both .VMSs set the OCR to $cd (lcdis currently only recognises $a1,
$81, $a3 and $92)

----

The VMUv demo from www.dreamcast.com:

Here the "type" (field $64 - 67)
   reads $02 $00 $00 $00

which is another apperance of the mysterious 2 value

It manages to confuse LCDis' memory bank detection (around line $0a29)

----

Trickstyle Jr (The minigame within the game Trickstyle, Found on some
foreign web site - I'll try and remember where..)

sets the OCR to $4d and $cd

Since the eGroups software was updated this weekend, the links in the
"VM News and Articles" folder in the Vault (now "Files") don't work
any more.  I suppose the folder should be moved to the "Links"
section, but I couldn't find any way to modify existing entries.
Perhaps the Owner or Moderator will be able to do it.

   // Marcus

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