News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Valendian

Pages: [1] 2 3
1. Yeah you're right there are 1x00 10xFF 1x00. This is called the sync field and is used as part of the framing structure. The CDROM controller uses the sync field to detect the start of a sector.

2. The mm:ss:ff will tell the CDROM controller exactly which sector this is. These are the bytes that SetLoc is seeking.

3. There is no chaining but you can tell the CDROM the read multiple consecutive sectors.

Your dead right with the 166 (0xA6) but the offset depends on the disc image. It could be any of these
A6*800=53000 (iso)
A6*930+10=5F530 (mode1 bin/img)
A6*930+18=5F538 (mode2 bin/img)
The initial offset is not included in the LBA. It has to do with the lead-in and is not part of the binary image.

If the image in bin/img format you can find mm:ss:ff at offset 0xC (right after the 12x FF)
Yoh can simply search the image for it to find the sector


Default CDROM addressing is by time and LBA is used for data discs with an ISO9660 file system. You can work it out in LBA with arithmetic. I think it's 75 sectors per second. I can't remember if there is an initial offset 2:0:0 for example but you can find that by opening the img file in a hex editor and looking at offset 0xC of any sector.

I've only ever seen the CDROM dump sectors on the stack via DMA. Stack is at 0x801FXXXX and grows downwards

You may able to code CDROM at the register level but be prepared for a whole lot of work with little or no documentation to guide you. Would it be easier to track down the library call that the engine uses to read a sector and call that with your LBA.

I did this before years ago. The WiFi connection required a shield for the PI. On the PC I just used a browser. I had a web server on the PI that served back plain old html. Just a lightweight DIY server written in pure C that used the berkley socket API. I toggled the GPIO's using something like this from the server
Code: [Select]
system("echo 1 > /sys/class/gpio/gpio18/value");

It's relatively straightforward to communicate over UART if that's an option. The PC will see a UART connection (COMX on windows). You can open the COM port from C# using the SerialPort class inside the System.IO.Ports namespace. On the RaspberyPI it will show up as /dev/ttyS0 or /dev/serial0.

Would be much faster and cheaper to use cheats then to burn CDs. This is gonna be very random

The TOC has nothing to do with subchannel data.

The TOC is often confused with the file system. As a ROM hacker you should not have to change the TOC, but you may want to change the contents of the file system (move files around or resize files). You can use the (badly named) TOC changer to do this.

You can change the TOC by editing the CUE file directly and point the burning software at your modified CUE file. The TOC is part of the lead in. It describes a session or what tacks (songs) are on the disc. It is almost not used for data discs (just a single track that spans the entire disc and the BIN file contains a raw dump of that track). Audio CD's make use of the TOC to add artist and song name to the tracks (songs). Here are some examples

Code: [Select]
REM GENRE Electronica
PERFORMER "Faithless"
TITLE "Live in Berlin"
FILE "Faithless - Live in Berlin.mp3" MP3
    TITLE "Reverence"
    PERFORMER "Faithless"
    INDEX 01 00:00:00
    TITLE "She's My Baby"
    PERFORMER "Faithless"
    INDEX 01 06:42:00
    TITLE "Take the Long Way Home"
    PERFORMER "Faithless"
    INDEX 01 10:54:00
    TITLE "Insomnia"
    PERFORMER "Faithless"
    INDEX 01 17:04:00
    TITLE "Bring the Family Back"
    PERFORMER "Faithless"
    INDEX 01 25:44:00
    TITLE "Salva Mea"
    PERFORMER "Faithless"
    INDEX 01 30:50:00
    TITLE "Dirty Old Man"
    PERFORMER "Faithless"
    INDEX 01 38:24:00
    TITLE "God Is a DJ"
    PERFORMER "Faithless"
    INDEX 01 42:35:00

First off use an emulator with a debugger such as no$psx or pSX. Then place a read/write breakpoint on the start address. This will let you know where the game engine is using that memory. Take note of all the addresses that read/write. Now find some free space and patch the code so it read writes to there instead.

You will need to use a MIPS instruction set reference.

Newcomer's Board / Re: Rom Editors
« on: February 16, 2020, 10:25:09 am »
You might be able to get away with Windows95 or Linux running in a browser

But you wont get far with this approach

Personal Projects / Re: GodHands (Vagrant Story Editor)
« on: February 15, 2020, 08:28:50 am »
Try this link

or this

V0.2.3 fixes some issues (available in the bottom link)
Weapon Stats are now computed (Blade+Grip+Gems)
Equipment Parameters were messed up
Mpd Enemies cleaned up a little

Is this the one? Slightly different name but it does contain source code.

Edit: Apologies the zip file is corrupt and it did not contain any source code, here are all the pcsx versions I have collected appears to be the same zip (has the same content when extracted)

There appears to be a version 2 of this in the util section

Personal Projects / Re: GodHands (Vagrant Story Editor)
« on: February 15, 2020, 02:42:51 am »
@The_E_y_es: I think TOC blindly changes the file size and doesn't care if data overlaps. While DiskTool will not allow you to overlap two files, which is intentional. But you have already emptied out this space? Then there must be a bug somewhere and I will track it down immediately. This is a good time for this work since many things are blocked until files can be resized automatically (with automatic LBA fixup).

Hi The_E_y_es. I opened an issue to track this bug:
In the near future all file resizing/relocating will be handled automatically when using the main editor (no need to burden a user with these tasks) but DiskTool will continue to provide manual access if needed.

@Pezito: Yes export/import to standard 3D format is coming soon. Perhaps you can give me some advice. Can you suggest a 3D format that has these features
1) Simple (ideally text based)
2) Animations
3) Gouraud Shaded Polygons (used for baked in lighting)

If I go with OBJ format I don't have animations. Also Gouraud shading is nice to have but not essential.

Bugfix has been released. Problem was related to self-intersection.

Personal Projects / Re: GodHands (Vagrant Story Editor)
« on: February 11, 2020, 05:39:36 pm »
Thanks for all the support, I really appreciate it.

I do hope to support translations and have already made some progress on this front (equipment, misc items and characters). My priority is supporting the needs of the users. So if you want something done then make some noise. I already have these on the to do list and will happily bump them to the top.

While I'm on the topic, I've had to refrain from doing the 3d viewer thing, because it soaks up so much time. This time was spent instead on features that modders need.

Disk editor is fairly robust now. You can drag to export. And soon will be able to add new files/folders. I am tempted to release this as a separate tool.

Personal Projects / GodHands (Vagrant Story Editor)
« on: February 08, 2020, 02:01:32 pm »
I'm currently working on a level editor for Vagrant Story called GodHands. It's very much a work in progress, but its finally at a usable state. I'll post some progress as things happen. I usually set some time aside over the weekends.

GodHands is open source and if you would like to contribute in any way please get in touch. I'd appreciate beta tester feedback, bug reports and development contributions.

Edit Enemies, Equipment and Treasure Chests
Export / Import data (either the entire enemy or just the skills)
Export texture maps from the rooms in TIM/PNG/BMP format
Built in Disk Tool which let's you resize/relocate files (which CDMage doesn't allow)
The DiskTool also allows you to export files

Let me know your thoughts and suggestions.

Those are good findings. Nice work. This Tracker is an awesome application. I starred you on github. I'll have to keep an eye on this.

I'd be happy to wiki-fy the info for you. But I would prefer if you had your own login.

Newcomer's Board / Re: How to Learn how to use a PSX debugger?
« on: August 23, 2019, 03:34:35 pm »
There's a good tutorial here for the pSX debugger

Totally agree with what Fast6191 said, Just search the savestate for the data you wanna work with and then corrupt the data in memory. You can learn a lot by seeing how the game breaks by changing values.

Its great to see someone using these tools. You are gonna love making cutscenes. The only real limitation is that you have to use the animations that are already available in the game.

PRG (Program) files are executable programs. They mostly contain software but also contain data. These files can be converted to a human readable form using a MIPS disassembler. You wont get much benefit from reading that unless you have knowledge of programming and a lot of patience. The original developer has complete freedom in how data and software are arranged. Generally the disassembler makes no attempt to separate data from the software, so a human must decide which is which.

I'm looking at the font in video memory right now. I'm trying to trace it back to where it came from on the disc. I can lift out the font for you.

June 07, 2019, 04:56:17 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
The font is stored in BATTLE\SYSTEM.DAT at offset 0x1E0F0. The image is 4bit 256x96 pixels and is 0x3000 (12288) bytes in size. Each character is 12x12 pixels and they are arranged in a 21x8 grid.

There are many fonts in this file. This font appears to be a portion of a larger image containing other fonts. There is another 12x12 font immediately before this dialog font and it is also 12x12. And there is a tiny 8x8 font running vertically along one edge of the entire image, which makes use of the fact that 21 characters leaves 4 bytes (8 pixels).

The entire image is blitted to video memory in a single copy operation. The full image begins at offset 0x1ABF0 but it does not appear to have a file header. I have no idea how tall it is, only that it is at least 256x192 and not larger than 256x256. I have not found the CLUT (Color Look Up Table), so the font does not have correct colors. There appear to be many CLUT's each containing 16 colours (4-bit) but I have not found the right one.

Newcomer's Board / Re: How to get Vagrant Story's speech bubble font?
« on: June 05, 2019, 02:55:54 am »
BATTLE.PRG has an embedded font. It most likely is the one you want. I dont have the notes to hand right now but I will have a look and get you the offsets.

Notes say this
Code: [Select]
233eC graphics (?) $800 bytes, 32*32, font

These commands are for a cross compiler. You need to get you development environment set up first.

If you are on Windows you first need to get a Linux machine setup. Best to get virtalbox and install Ubuntu

Once Ubuntu is set up do the following

Code: [Select]
sudo apt update
sudo apt install build-essential
sudo apt install make
sudo apt-get install gcc-arm-linux-gnueabi
sudo apt-get install arm-gcc-none-eabi
Once those are installed you can build for ARM. But you will need to study the reference manual to do anything of interest.

This is what make prints when everything has already been built?

What's your makefile look like? I'm not a make guru, but I know the basics. I can take a look for you.

Pages: [1] 2 3