Sonic and Sega Retro Message Board: Kroc - Viewing Profile - Sonic and Sega Retro Message Board

TL;DR version:

How does one replace the CDDA tracks in an ISO/BIN/IMG/CUE?

History:

So I have a PSP. I'm emulating PSX games. CDDA audio is not supported on the newer versions of the built-in emulator, but using "POPSLoader" one can run the older emulators and get it working.
However, the older emulators are not as good (no custom screen sizing). Apparently the newer versions support something else (likely ATRAC3). Nobody has achieved this yet, but I would like to have a go at replacing the CDDA tracks in a PSX ISO with ATRAC3 versions to see if it'll work with the newer emulators.

I understand that the LBA addresses/times will be thrown off in a CUE file.

GeneHF has demonstrated being able to replace CDDA tracks here, http://forums.sonicr...ndpost&p=554339 but didn't describe the process.

I've Googled a lot and haven't found anything concrete enough except above Sonic Retro post.

Hope you can help.

Kind regards,
Kroc Camen.

Hello.
I am working on a complete disassembly of Sonic 1 Master System for the purposes of a full editing suite for the game.

I am working toward porting the ROM from 256K to 512K. This requires properly labelling and structuring the disassembly so that the code and data is portable and can be moved around the different banks.

I am using WLA DX and whilst it is an excellent tool for the job I am coming across instances of code and data that are not simple enough to make portable.

I would like to ask for the help of a C-programmer to add some new functions to WLA DX in order to solve some portability problems in the code.

Here's my first proposal for a new function:

".TABLE": Portable indexes

Here's a real-world problem I want to solve: making index numbers used in data, portable. In Sonic 1 SMS each level has a list of which objects (enemies, powerups &c.) appear where in the level. In the ROM a pointer table provides which object index number runs which code. This style of index-based functionality is very common, I imagine in most other games too.

How can we add to / remove from / rearrange the object code and function pointer list in the game without making all the level data invalid; pointing to the wrong objects? The current situation is that nobody bothers and just works around the ugly picture. The lists are included as binary and the pointer tables are only appended to. This is not flexible enough for me, especially if I want to head toward providing an editing suite with total-conversion capabilities.

My proposal is a new declaration for WLA DX: ".TABLE".

First you define the 'columns' of your table using a standard .STRUCT definition.

.STRUCT pointerList
    address: dw
.ENDST

Here's where the magic happens. Each row has it's own label, this label does not point to the output address of that data, but instead provides the index number of the row. I.e. 'badnick_motobug` = 2

.TABLE objectPointers INSTANCEOF pointerList
    .ROW badnick_crabmeat DATA $1234
    .ROW badnick_chopper  DATA $5678
    .ROW badnick_motobug  DATA $9ABC
    [...]
.ENDT

Now in your data statements you can refer to these labels rather than hard values

;list of objects in the level: (object ID, X, Y)
.db badnick_chopper, $20, $20
.db monitor_ring, $43, $12
[...]

.TABLE is also excellent for data that combines different data types (bytes, words, strings &c.). Currently in WLA DX this quite painful, e.g.

.db $FF
.dw $1234
.db $80
[...repeat 100 times...]

Doing this with .TABLE will be far more elegant and flexible:

.STRUCT hypotheticalTableDef
    first: db
    second: dw
    third: db
.ENDST

.TABLE hypotheticalTable INSTANCEOF hypotheticalTableDef
.ROW DATA $FF, $1234, $80
.ROW DATA $11, $5678, $A0
[...]
.ENDT

.TABLE would also define `_sizeof_[table name]` which will give how many rows are in the table -- perfect for initialising your loop in a flexible, portable way!

---

I also have a proposal for a block form of .DSTRUCT that will help with self-documentation, but I will post details of this soon.

Is there any one out there that would be willing to volunteer their efforts to help?

Hi. This is a general thread to mark an official place for discussing the 8-bit Sonic 1 disassembly I am undergoing.
The project is now available on GitHub:

github.com/Kroc/Sonic1-Z80-ASM

The download includes a batch script and the necessary binaries to compile the ROM.
You will need to provide your own Sonic 1 ROM file (renamed "ROM.sms") which is used to fill in the data banks.

This disassembly is being done to aid in creating my level editor MaSS1VE: The Master System Sonic 1 Visual Editor, which is also on GitHub here.

Continual praise and thanks goes to the community members who have made this possible, including David Declerk, ValleyBell and Penta Penguin.

Hi. I'm doing a complete disassembly of Sonic 1 for the Master System.
I have found various pieces of evidence to suggest that Sonic 1 was scaled back from a 512K game to 256K some way through development.
The most amazing thing I've just found is that an 8-bit rendition of Marble Zone's music is present in the ROM!

You can download a version of the ROM here with the Green Hill music replaced with the Marble Zone track:
http://camendesign.c..._MarbleZone.sms