Emuze

Topics on software tools like TileStudio, comments on documentation and tutorials (or the lack of) should go here.
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Emuze

Post by paul »

Emuze is an Eeprom Management tool for the Uzebox. Being a rom, it can be invoked through the SD card bootloader interface or programmed like any other hex (ie it is a tool to use from your Uzebox, not your PC). It'll keep watch over your hard-earned highscores and saved games (and even let you edit them ;) ). It'll also unbrick eeproms that fell victim to that crazy Pac-Man game...

Image

He looks trustworthy to me.

Emuze controls vary based on the currently enabled menu. In all cases, holding a movement key will eventually auto-scroll through the menu. A red arrow denotes an activated menu selection, while a green arrow is a passively moving cursor.

Controls:

A: Activates the currently active menu option. Also activates the selected eeprom nibble for editing (a red arrow indicates an editing state).
B: Goes back up one layer in the activation hierarchy. This can be the previous menu or just the previous state for the current activity (like when you want to move on to another nibble).

Dpad Left/Right:
  • Cycles eeprom block pages when the game icons menu has focus.
  • Next/previous nibble when editing a block. Hold down to scroll quickly.
Dpad Up/Down:
  • Navigate vertical menus
  • Cycle hex nibbles when hex editing arrow is red. Also jumps editing arrow between upper and lower rows when the hex editing arrow is green.
I'll try to get a wiki page together that maps eeprom formats for each game (perhaps even standardizing hi score formats). It might not be a bad idea to reserve a block or two just for 32 bit high scores. Many games will waste an entire eeprom block for this purpose.

Note that the emulator occasionally shows some graphical artifacts when dealing with eeprom access. This doesn't seem to be an issue when run on the hardware. Source can be found in the Uzebox svn. There's a couple of eeprom hex/bins in the zip in case you just want to muck around with it in the emulator. ID's for supported games are located here. I'll try to provide a little wiki intro for what you need to do to get icons for your game included in future Emuze builds.

Image

Now, finally, someone can break Nebososo's B.C. Dash time :lol:
Attachments
emuze.zip
(165.14 KiB) Downloaded 1745 times
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Emuze

Post by uze6666 »

Nice tool Paul!

Guys, now you have no excuses to not use save games! ;)

-Uze

Edit: love that emu pic! :lol:
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Emuze

Post by D3thAdd3r »

This tool kind of doubles as Game Shark for the Uzebox ;) I like the idea of having one block just for scores, or games like soko/lolo that only need a couple bytes to store progress anyways. More icons looks better though, so I'm torn between :lol:
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Emuze

Post by paul »

New build in svn adds support for:

- Kernel block editing (still viewable in detailed form with the "Explore" menu option).
- 3-deep "Undo" buffer. This replaces the "Re-load" menu option. A "Save" will push the oldest undo off the list. Each block may only have a single undo command present in the 3-deep buffer.
- All changes must be explicitly saved in order to persist. In the past, formats and pastes would auto-save.

It's not a bad idea to copy & paste your kernel block to a free block before making any changes to it in case you want to restore default settings at a later date.
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Emuze

Post by D3thAdd3r »

Paul, I was wondering how difficult it would be to implement a generic format for detail pages. Just so each game could have a detail page like the kernel does, last level completed, score, whatever matters for the game. That way people could just whip up a detail page once they have the eeprom format all figured out for their program. Maybe something like number of attributes, offset into block where each attribute starts, string describing the attribute, and I suppose there would need to be a bit of custom decoding for some games to interpret the data. Maybe this would all be a pain though. I think you should go ahead and standardize the hi-score since you have put all the work into making all this, so I doubt anyone would disagree with you being the authority on general format.
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Emuze

Post by paul »

Yeah, i was thinking about this recently. A format string sounds like the easiest and cheapest means for doing this. I'd prefer not to have code specific to any one game, and that probably won't be necessary if we provide enough command tokens to cover almost any eeprom layout (even for those compressing data).

The interface could place short hex chunks under their corresponding details and you'd see the changes reflected immediately. Currently you have to scan the game's code to know exactly what changes you're effecting. It's most useful atm for freeing up space and un-bricking Pac-Man victims ;)
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Emuze

Post by D3thAdd3r »

For some of you that might not know, Paul is one of the great Uzebox developers responsible for DK,Pacman,Platz,Space Invaders,Frogger,and this nice tool. He became very involved in developing games for iPhone, and though I suspect he still visits on occasion, this tool is in need of update.

I am going to make icons for all my games that don't have them(Uzesweeper,AE,FrogFeast) and add them to Emuze. While I'm at it, it would be great if anyone who has a game and notices this post would also make an animation for their game and post it here. If nothing else, just your sprite frames. I can take care of all the details, but I will need either 1 picture or multiple pictures if you want animation. Each frame should be 18x16(3x2 mode 1 tiles) and you can specify how many NTSC frames each animation frame lasts. Otherwise I will try and spend some time and make what seems best for each game if no one speaks up. Probably try and keep it at 2-3 frames max unless it really needs more. Also I have updated the only missing entry I know about on the EEPROM Block ID Reservation List, but if yours isn't there please add it.

I wont get at this for a good while, but another thing I am considering down the road is adding support for FatFS. It is reaching a point where we are running out of EEPROM space, for instance if you have played and made a save for every Uzebox game you should basically already be out of space(your Holey Moley addiction has cost you a lot of space ;) ). It would be very nice to save your EEPROM data to a file on the SD card and then load up a different one from the SD into your EEPROM. It would kind of be like changing a memory card on older game consoles(saturn,psx,n64,etc). More useful would also be to switch to mode 3 and use SD->ram for the graphics, animation data, etc. That way we can just update one file on Emuze instead of re-compiling to keep up to date plus eventually we will run out of space to store all those tile graphics in flash :o Games like Zelda and I suspect we will see some other RPGs in the future, are going to need space.

It is pretty quick and easy to do just using the graphics you already have for your game. Here is an example of what you are trying to do, it's easy enough I made icons for 3 games in about 15 minutes so it's worth doing. For the animation on those frames I would use probably 180,4. Then every 3 seconds they will go to the second frame and stay there for 4 frames, perfect for a blink for example.
Attachments
emuzeicons.png
emuzeicons.png (765 Bytes) Viewed 15439 times
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Emuze

Post by uze6666 »

Good idea! I was thinking the same thing last week. PM me a google account, I'll add you to the Google Code SVN commiters.

I'm all in for using sd loading of graphics in Emuze, but I suspect it's going to be more than a bit of work. For the saves states, yeah we will run out eventually. That's why Paul made emuze. Using the SD is a neat idea if it's managed by the kernel and all states goes into a single file. Downside is that FatFS takes a lot of flash and RAM. :|
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Emuze

Post by D3thAdd3r »

uze6666 wrote:I'm all in for using sd loading of graphics in Emuze, but I suspect it's going to be more than a bit of work.
Definitely. I couldn't get around to all that for quite some time, but preliminary investigation seems we would have enough ram to do it with PFF at least. 28 ram tiles can display the same amount of icons per screen that the current version does, at 16x16 resolution.
uze6666 wrote:Using the SD is a neat idea if it's managed by the kernel and all states goes into a single file. Downside is that FatFS takes a lot of flash and RAM.
I have tried using FatFS enough to agree the flash/rom cost would cripple all but the most simple games. It seems a natural choice for tools, otherwise PFF writes should be good. I'm not real crazy about PetitFS being required/tied together for EEProm in the kernel for games. Every thing in 1 file handled automatically would be spectacular, but I have no clue how it could be done in a flexible way either.
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Emuze

Post by D3thAdd3r »

New icons: (if the game is yours and you want to do something different just say the word)
atomix,holey moley,zombienator,chess4uzebox,corrida nebososa,dr. mario,pipes,whack a mole,frogger,donkey kong,mega sokoban,lander
Attachments
newicons.png
newicons.png (3.62 KiB) Viewed 15372 times
Post Reply