Previous Page

by kode54 at 11:44 PM EDT on May 12, 2016
Thanks for missing the point entirely. You get a cookie.

Plain music-playing N64 ROM dumps, with all of the non-essential code dummied out, possibly with custom code compiled to handle setup and initialization, is a good way to go.

Streamed audio formats don't necessarily even need to be N64 related, and may be likely to end up in vgmstream instead.

Sequenced is hard enough to get right with the existing USF format. A more future proof USF format that doesn't rely on save states doesn't even need to require a new file format. The existing USF file format already supports both USFLIB and MINIUSF overlays containing either or both of ROM or save state. The save state is entirely optional in the file format, as is the ROM itself.

The problem is making the emulator library safely handle the case of no save state, and support cold booting a ROM image. I think that may be possible, it just needs a startup process that skips the state loading if there is no state to load.

Code coverage is also quite simple with the code I've assembled in the new lazyusf2 library. Unfortunately, it still requires the slower interpreter and full RSP interpreter modes, simply to make sure that every important piece of code or data is exposed and marked as used.

Also included in the binary array library that it uses to keep track of coverage, are simple functions for combining arrays, so that a caller that has already supplied a basic ROM image that already does full songs, and has a single uint32 somewhere that may be filled with an arbitrary song number, can run each known song for several loops, then combine all of the arrays together, zapping all of the unused bytes with zeroes.

I already wrote such a coverage tool for hand ripped 2sflib/mini2sf sets, since that Pokémon: Explorers Procyon Studios rip didn't work with the existing tools, so had to be trimmed through sheer brute force. It actually stops the coverage checking after so much memory coverage inactivity, or a period of play time, or so. I forget which.

This tool would need to be rewritten to trim usflib/miniusf sets, with the ripping tools already handling the part of writing a full set of proper song numbers. Or if you're feeling adventurous, write actual song data to the miniusf files, and modify the coverage and trimming process to separate coverage data into regions covered by the usflib and by the miniusf. Knock yourself out. :D
by hcs at 12:01 AM EDT on May 13, 2016
A nice thing about ROM-only is you should be able to track coverage with full dynarec, since you only need to look at explicit ROM access. Doesn't quite do the trick if you unpack stuff and load a RAM image, though.
by hcs at 8:58 PM EDT on June 4, 2016
I found the first of the USF docs UF had, a chatlog where we talk about ripping Diddy Kong Racing. Probably not useful but...

Unfortunately this backup is earlier than the second doc, so that's still missing.

edited 9:02 PM EDT June 4, 2016

Previous Page
Go to Page 0 1 2 3 4 5 6 7 8

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source