Custom everdrive MD v3 menu

For anything related to cart (SRAM, SF2 mapper, audio, CD mode 1, ...)

Moderator: BigEvilCorporation

Post Reply
twosixonetwo
Very interested
Posts: 58
Joined: Tue Feb 25, 2014 3:38 pm

Custom everdrive MD v3 menu

Post by twosixonetwo » Fri Nov 28, 2014 3:01 pm

I've recently been thinking about the possibilities of a custom everdrive menu (MDOS.bin), and therefore started reverse engineering how the software works. I haven't achieved much, but I wanted to create a thread to see if someone already did the same thing, has any information about it, or is interested in such a thing. I still need to ask krikzz, maybe he is willing to give me more information on the thing.

Some possibilities for this:
- Change pretty much anything about the looks of the menus
- Have the menu make sound effects
- Write "applications" (vgm player, hex editor) that don't need the console to reset to turn back to the menu
- Make SD-Cards that directly boot a game (this might be interesting for people who do speedruns of games and often hard-reset the console)

The thing is however, that this stuff needs to fit in ram, or else you will have to flash it, which is very slow.

So here's what I found out so far: When the everdrive turns on, there's a bootloader in address space 0x0000 - 0xFFFF (the bootloader takes only ~23kB of that, the rest is zeroes). The bootloader is then trying to read from the sd-card and copies the mdos.bin to ram. I've dumped the bootloader but haven't found the actual routine that copies the mdos.bin yet. Still inside MDOS.bin you will find a lot of jumps to subroutines in ram, so I'm quite sure that it's being copied to ram before being executed.

Controlling the SD-card seems to be done via the addresses 0x80000,0x80002,0x80004,0x80006.

There don't seem to be any integrity checks for mdos.bin. I was able to change the menu colors by just changing the corresponding values in the mdos.bin, without the need to generate anything like a checksum.

So if anyone has already tried this and has more information than I have, feel free to inform me :)

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Fri Nov 28, 2014 5:17 pm

Some documentation:

http://krikzz.com/pub/support/index.php ... erdrive-md
http://krikzz.com/pub/support/everdrive ... ec-1.1.doc

It's for the old model but maybe this can help you

twosixonetwo
Very interested
Posts: 58
Joined: Tue Feb 25, 2014 3:38 pm

Post by twosixonetwo » Sat Nov 29, 2014 11:00 am

Thanks, thats very interesting. I didn't think of looking for information on the old everdrive. I will see how much of this applies to the everdrive v3!

twosixonetwo
Very interested
Posts: 58
Joined: Tue Feb 25, 2014 3:38 pm

Post by twosixonetwo » Sun Dec 07, 2014 3:41 pm

I've mailed krikzz and he gave me quite a bunch of very usable information. By the time he answered I already had tried disassembling the code a bit, but I had only found out that writes to 0x80000 seemed to select some register and writes/reads from 0x80002 were used for data. But finding out which registers actually exist and what they do would have been quite hard.

So future plans I have are to code a small OS that has most of the functions of the current OS, with added support for small applications, that fit in ram, and do stuff like wave or vgm playback and to build a more graphical interface for game selection. I made a small mock up how I imagine this could look:

Image

Obviously the icons here are just placeholders for proper icons and this interface has some challenges, as I would have to do icons for all games that should be available via this interface and they would all have to share palettes...

twosixonetwo
Very interested
Posts: 58
Joined: Tue Feb 25, 2014 3:38 pm

Post by twosixonetwo » Mon Dec 15, 2014 12:53 pm

(Should someone wonder why I keep posting here: I will keep this thread updated as long as I work on this, so that if I ever stop working on it, the information I have gathered is still available for other people)

I have written a small test rom (as a replacement for the usual mdos.bin) which displays some text on the screen. From the information krikzz sent me, I knew that the mdos.bin header begins with the entry-point vector, so it was quite easy to get something running, however I thought that the bootloader copies the font, which turned out to be wrong. So even though the bootloader contains the rom, and initializes the VDP-registers my test rom has to copy the font to VRAM and enable display afterwards.
The next steps are going to be reading from the sd-card, which could take a while, since I've never done any lowlevel stuff with SPI or FAT. I think I am going to mostly use the core functions from the original MDOS.bin which provide functionality like "write a word to spi" or "receive block from spi". This should pretty much eliminate the risk of accidentaly bricking my everdrive by overwriting the bootloader while I am doing stuff I don't know anything about ;)

Post Reply