 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by Cellar Dweller |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
| User | Post | ||
Cellar Dweller Flurry !!! Level: 27  Posts: 263/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
I can't help but wonder: Are you running a fever?  BTW, the link doesn't work. Perhaps you meant www.ditty-o.com. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 264/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| The USF Walkthrough document linked to in one of the message board threads I linked to explains in detail how USF ripping is performed. There is no attempt to figure out how all of the games's music code works, just enough to stop all but the music code. Then a tool that runs the music code and records all of the code and data that is part of the music engine is run. It runs until no new code or data has been accessed for a while. After that, all unused data is removed from the rip. According to the docs that I have, there is support for type 0 MIDI sequences built into Ultralib, and a tool to convert type 1 MIDI sequences to type 0 MIDI sequences was included with the IRIX based N64 devkit. For some reason, I have the impression that every N64 game used the MIDI features of Ultralib for music in some way. There is also support for compressesd MIDI sequences in Ultralib. off0x36 and 0ff0x38 are just offsets into a data structure somewhere else in memory. What is interesting about the command 0x36 function is that the way it is coded implies that the music command has two 16 bit arguments. The music command is 8 bytes in size, but the last 2 bytes seem to be there only to pad the command to a 32 bit boundry. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 265/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by neotransotaku Notes also predates Outlook. When I saw this thread, I pulled an 11 year old issue of PC Magazine off the shelf that had "Groupware" printed on the spine. Among ads for things such as Intel's upcoming "P6" processor, the editors gave great reviews to this "Lotus Notes" application that did LAN based e-mail and other group management stuff before most businesses had Internet service. I saw no mention of Outlook, but I did see something about "Microsoft Mail". |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 266/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
stag019's current name is too big to fit into the name field of the PM form without hacking the form with a text editor. I'm too lazy to do that, so I'll post the message here. Also, this information my be of use to others. Please excuse any crappy grammer/spelling; I need sleep.Originally sent by stag019 Here is the code that seems to have the pointers: 3ac0/80248ac0: 3c 05 00 11 LUI a1, 0x11 (17) The LUI instructions set the upper 16 bits of a register, in this case a1 and a2 are set to 0x00110000. The ADDIU instructions set the first register to the sum of the second register and the immediate 16 bit signed integer. Note that the second ADDIU's immediate parameter is treated as a negative integer and the value of a1 will thus be decreased to 0x00108a40. The third ADDIU sets a0 to 0x2 by adding r0, which is always zero, to 0x2. The JAL instruction calls a function at 0x802787d8. Because MIPS CPUs are highly pipelined, the instruction after a jump/branch/function call will be executed before the target instructions are executed. The 0x802787d8 function loads a MIO0 file into RAM starting at the ROM address in the second parameter (a1) up to the ROM address in the thid parameter (a2), and stores a pointer to the decompressed data in the segment table at the index specified in the first parameter (a0). If you want this code to load a MIO0 file that is somewhere else: 1. split the start ROM pointer into two 16 bit halves eg. 0x00108a40 => 0x0010 0x8a40 2. if the lower 16 bits is greater or equlal to 0x8000 add 1 to the high 16 bits eg. 0x0010 0x8a40 => 0x0011 0x8a40 3. place the high 16 bits at 0x3ac2 in the ROM and the low 16 bits at 0x3ace 4. do the same thing for the end pointer, except the high 16 bits go at 0x3ac6 and the low 16 bits go at 0x3aca If you need a MIO0 compressor: http://s91407720.onlinehome.us/acmlmboard_files/romhacking/sm64/mio0enc.exe |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 267/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by smwedit Have you tried this: 1. Save a copy of the Edit Layout page from this site. 2. Open the saved page in Notepad, or a similar app, and remove the offending form from the textarea. 3. Fix the action URL as above. 4. Save the edited page and load it with a web browser. 5. Edit your layout. Using a saved Edit Layout page from another site will not work, unless you have the same password at both sites, because the page has authantication information in a hidden field. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 268/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
It should not be too hard to create an ASM hack to load the 0x108a40 data predecompressed from some other area. I may be able to do it, if I remember to do it.  Originally posted by HyperHacker AFAIK, N64 games almost never read ROM data from memory mapped areas. They set up DMA tansfers from ROM to RAM and work with data in RAM. Even the function that loads compressed data first allocates RAM for the MIO0 file, uses a DMA transfer to load it into RAM, reads the size form the MIO0 header, allocates that much RAM, calls the uncompress function, and frees the memory holding the compresssed data. Keeping a bunch of data uncompressed may be a good idea for now, but after the data structure becomes better understood, it may be a good idea for editors to recompress the data on save. An inventory of the assets(textures, models, objects, etc) could be performed by walking the data and translating the information into the editors internal format. When saving, the data is translated back and saved in the game's format. If anyone is looking for a no-op level command, you can use a 0x24 command with an act mask of zero and the size byte set to how many bytes to skip. The size should be a multiple of four, and a zero size will cause the level loader to hang in an infinite loop. It is also possible to increase the size byte of a command to skip commands after it. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 269/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| I really don't know what the size limit is. IIRC, the N64 cart pinout has 16 address/data lines, an alel(address latch enable, low) line, an aleh(address latch enable, high), a read line, and some other clocking/save/lockout stuff. This suggests that the max size is 4G by 16 bits, or 8 GB. The hardware register for controlling the start of the transfers is 32 bits. I just don't know what the max size is. It may be much less than suggested here. |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
| Acmlm's Board - I2 Archive - - Posts by Cellar Dweller |
