spinout

If you're working in RAM, consider referencing the console debug output that the ROM spits out with a customized build of mupen64plus. Printing the return address along with the debug text gives a rough idea where specific functions are. Search "bgm" on this page.

The 64DD also supplies a clock, it's implemented in some forks of mupen64plus, and the register is used by Animal Forest as I recall. I bet newer flash carts could read and write the register if their OS/firmware/whatever were written to do so.

What's wrong with the 64drive? I was one of the beta testers, had the CF only version and marshallh kindly replaced it free of charge when he redesigned to Micro SD & CF. Software on it is solid, marshallh knows n64 software and hardware about as well as SGI when they designed the damn console. ED64 has a definite price advantage though.

I don't know how I've missed this project for so long. I'll have to download and play it on my 64drive when time allows. Respect.

I'm at a loss as to the usefulness of this topic. The people with the skills and know how are aware of if not have all the information posted in this thread, plus more. I've been in #n64dev on efnet, there is a branch of mupen64plus which adds as much 64DD functionality as current documentation and rips allow. The main problem is is that nobody dumps 64DD disks. So what's the point of writing an emulator? How could it be tested? The developer documents are what emulator devs are interested in, unfortunately they only outline the framework for the N64DD, and don't go into specifics which are needed for accurate emulation. Rough emulation is probably possible with the resources available. tl;dr the people with skills and motivation can get this information easily with google if they don't have it already, and they have little motivation to use it. [/rant] Sorry if that came off as harsh. If you want to see useful developments regarding 64DD, search for the people involved and politely encourage them to continue development. Seek out 64DD owners and connect them with developers. Maybe more dumps can be made!

Post content here in spoiler tags and I'll add it to the wiki.

This is wonderful information. Some of it isn't even available for MQ debug. If the authors are cool with it it should go up on the wiki.

I've tested some hacks on the N64: mixed results. Bomb arrows: Working with some refinements Octopus: Z-buffer issues, textures, scale and animation no problem My LZO filesystem worked perfectly. THPS 1

Go for non-mainstream consoles. Ouya ftw! I should be getting mine soon.

Don't forget the skybox pointers and ovl pointers within code! Though I think if you're dealing strictly with maps ans scenes you won't move around actors objects or skyboxes.

I once took a stab at a level importer (in C) that worked between all games. I wrote about 85% of the code for it then lost interest.

Freefang did that video IIRC. It was one of the first maps ever imported to OoT by someone other than myself.

In MQ debug, you only have to have correct pointers in the scene table and the scene itself. In MM (and console OoT versions iirc), you have to have the pointers correct in the filesystem as well. This seems simple at first, but in all reality it is somewhat complicated because the filesystem has to have pointers in order, as it is a list for a binary search. When adding, removing, and replacing files, having offsets that are in order is no easy task.

Oh I forgot to mention Nintendo kinda did something very like this already: The iQue. It has a feature where you plug it into your computer and it can download games (for a fee) onto itself. Google it for more info.

The only plausible way I see this happening is using overclocked N64s with flash carts that have internet capability. Custom controllers are completely possible.

I disabled Wiki registration. OpenID should work, I'll go ahead and test it out right now. EDIT: ok it isn't working. PM will be sent shortly. Anyone else who may be having troubles please post here or PM me.

IMHO the Z64 filesystem was not designed with editing in mind. Compressed, removed, and re-sized files require immense changes to the filetable, ROM layout, and therefore every ROM offset of a file within each file (think code, scene map pointers, map skybox JPEG pointers...). The linker script that Nintendo put together when they built the Z64 binary must have been at least 5KB - if you're not familiar (I know you are, Jason), a linker is a *usually* small text file that is optionally used in the final stages of building a binary which dictates how the binary should be put together. So...? How about a filesystem rewrite; a patch which changes the file loading routines so the ROM uses a filesystem that does have editing in mind. I tried with z64-fs-new (or whatever I called it lol), but I got that hack wrong; I didn't create utilities to work with the filesystem. This is the most vital part, accessory utilities. Brainstorm this idea openly in this thread if you're interested, I might be able to help you a bit in one way or another if there's interest. I could write a library or something.

Something like http://spinout182.com/?a=pr&p=tm ? Circa 2009 It could use a ton of polishing but it's jawesome.

Nope, I don't think it's ever even been compiled on a M$ OS (though it is 100% compatible). It uses curses/ncurses.

A long, long time ago, before model importers were conceived, I made a dungeon. I took 119's second room (the one I use in test videos), and copied it about 16 times, each time making a different room. I did doors and reworked the scene and collision and everything. It was jawesome. (Golrious UoT shot) Anyways, at one point I tried having a puzzle that required the water to be horizontal. Now I finally know why it didn't work. Awesome info, get it on the wiki!

Looks dope: polished and clean. Full ROM read/write integration would be jawesome but that's just my style. +1 this notion

In total this probably took me about 4-5 hours That being said, it is only fun for 4-5 minutes.

The culprit is possibly floating point numbers. There is an oddity in the GCC compiler that loads floats from data sections instead of immediates, requiring additional relocations (see: http://gcc.gnu.org/....msg00084.html. Notice how all mips-gcc devs ignored it ) Try this, just to see what happens: u16 f1(u32 z_gp, struct z64_actor_t * a) { /* set message number for text */ float msg_no; int v = 0; if( count == 20 ) { count = 0; v = 367; msg_no = z_rand() * v; v = (int)msg_no; } count ++; return (u16)v; }

Airikita, the wiki should be usable now if you use OpenID.

http://spinout182.com/mqd/ovl_Effect_Ss_Hahen.S 0x155/341 00D8BCB0 809D2690 00000F20 0x06 0x0001 bin src En_Changer