News: 11 March 2016 - Forum Rules

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 - glennxserge

Pages: [1]
Programming / Re: Tools to learn how to create my own GUI editors
« on: July 02, 2020, 11:43:53 pm »
If you are just trying to get the last 54 bytes of data from a file.  I think it's easiest to just read the file data and then use the right indexing to capture it. 

Python has a pretty elegant way of managing lists/arrays

Try this:
fh = open("somefilename", "rb")
data =

byteLen = len(data)
chunk = data[byteLen-54:]

That will grab the last 54 bytes stored in data, that you read from your file. How you choose to display it and build your GUI, is up to you.

I'd say if you go the python route tKinter is a nice module that makes setting up an interface pretty easy.  Lots of examples too.  Good luck!

Thanks, Valendian!

Feelin a little foolish now (>_<).  Reading back through your earlier replies, I misinterpreted your comment about the 0xC offset.  For some reason I didn't connect the dots for the initial sector header leadin value and the sequential nature of the descending sectors.  It feels a little like you've had to answer me twice about that, so thank you for your patience.  But I think I've got it all straightened out now.

When I went back and started checking the calculated sector address vs. the header's explicit sector locations, I found I wasn't actually calculating the offsets correctly.  Worked it out last night, and now I do seem to be able to decode the LA properly from the mm::ss:ff output from no$psx and the header info matches at that address.  Testing data in those sectors during reads does impact the game, so I feel like now I'm in the right spot. 

I think now I just have to figure out what that data is, which of course means, I still have all my work ahead of me  :laugh:.  But, thanks to your help, CDROM reads aren't a gatekeeper anymore.  Thanks so much Valendian!  Off to do more digging

Thanks again, Valendian.  I've been down the rabbit hole a bit trying to figure out exactly what's happening with disc reads.  Which spun into trying to tease out root dir and volume directories, and all sorts of adventures  :laugh: 

The disc image I'm working with is in bin/cue format, and after poking around to find the PVD and figuring out that sectors where being stored in mode 2, I noticed that the .CUE file actually gives you this info upfront  :banghead:.  Oh well, lesson learned. Also notice that it supports CD-XA001, for what that's worth.

So I was able to start getting sector information out of those SetLoc calls using: numSectors * 0x930 + 0x18.  It seemed like I was making progress, but the only way I could think to "test" that data was to flood the sector so the game would softlock or generate some kind of in game glitch to verify that I was in the right spot on disc.  To make a long story short, I was off by 121 sectors (too far in).  I was able to verify that all of the reads for casting elements were off by 121.  So it was consistent.  But all the reads for casting elements were fairly close address-wise, so I tested some different areas on disc and the error was 130 off my calculated sector. So I'm wondering what in the world is going on?  Maybe no$psx is giving me the wrong debug info, or I'm not understanding some kind of indirection or pointer math in how sectors get accessed (more likely). 

So I'm a little stuck.  But, it's given me a whole new set of questions:
1. Chrono Cross Disc 1, the first 12 bytes of each sector has 10 FF's with 00 on each side, which is a little different than the 12 FF's expected.  Valendian, I'm guessing this isn't particularly important, but I figured I'd mention it.

2. In the sector header data contains a mm:ss:ff at 0xC-0xE of the line.  What is this for?

3. In one of the sectors I isolated for NPC dialog, I narrowed the data down to a word of data, which was obviously too small to be the text for that portion of the game.  It also was padded in a way that fit 8Byte addressing, so I as suspicious that maybe it was a pointer and the data for that conversation was somewhere else on disc, but there weren't any other reads... Is it possible for psx reads to chain?  Like one read gets an address from a sector and then jumps to another sector?

Thanks for hanging in there with me.  I'm stuck at the moment, but feel like I'm learning a lot.  So many little esoteric bits of stuff to discover.   

Thank, Valendian.  That's exactly what I was looking for.  I found an ISO9660 doc, so I'll start reading through that next.  The only hacks I've done have been cartridge based, so disc stuff is all new to me.

The setloc I trapped in emulation had these parameters: 00 02 16, which I guess would translate to sector 166.  It's my understanding that sectors contain 2KiB of data generally, so that puts the address at 0x53000 + initial offset.  I'm wondering is this the address for file data or for a table entry in the directory? Am I even in the ballpark?  :laugh:

Alright, off to read up a bit more. Thanks, again.

Hi everyone,

I'm starting a PS1 patch project for Chrono Cross to rebalance some of the enemy stats, and I'm just in the beginning stages of understanding how the game is organized on disc.  I've taken some time to create a text table which has helped me identify where battle dialog, item names, descriptions, and menu text are.  I figured it would be worth seeing if battle text might be proximal to battle data, since developers may want the seek distance to be close.  With that in mind, I figured I should start checking actual emulated CDRom-Seeks and start tracing through a debugger.  I've been using no$psx for this and found a few spots where a seek is initiated.

At startup, Chrono Cross performs a few disc reads, specifically at 0x1FC04A24, where a few CD related commands are issued: an 02h, 06, and a 09.  From the no$psx documentation page, these look like a SetLoc, Read, and Pause; which makes sense.  Tracing this whole section, I can see some interrupt registers at 0x1F801803 also signal when the read data is ready.  Starting to make some sense, but there are a couple of things I need to clear up.

1. For the initial SetLoc, according to no$psx, it takes 3 params: amm,ass,asect.  I'm guessing these refer a seek target like some combination of sector, offset, and buffer size.  However, I'm not seeing any information about how to decode that into a specific address.  I might be going about this wrong, but I'm hoping someone can give me a pointer about how to read this command.

2. When 0x1F801803, gets set for INTI1 & 3 interrupts, data should be ready.... somewhere. Is there a specific location in memory for this?  Is it cached?  Some kind of DMA transfer?  I'm hoping to follow this data and see if and how it gets uncompressed.

Thanks, in advance, for any help! 

Pages: [1]