Author Topic: Debuggers for the PC Engine:  (Read 688 times)

termis

  • Hero Member
  • *****
  • Posts: 1485
Debuggers for the PC Engine:
« on: June 08, 2007, 01:47:37 PM »
Here's what I want to do.  I want to compare the CD and the SCD-released versions of Tengai Makyou: Ziria to see if the SCD version is indeed using the extra RAM provided by the SCD card.

I know you can use a debuggers to check if memory is being used, but that's about all I know.  Anyone care to give me a quick rundown where I can find this debugger, and lead me in the right direction?  I haven't properly coded for years, so it might take some time to get it going, but this is just a burning question that I must find the answer to!

malducci

  • Guest
Re: Debuggers for the PC Engine:
« Reply #1 on: June 08, 2007, 06:05:35 PM »
The only public debugger for PCE/TG and CD systems is mednafen (http://www.mednafen.com). You need to edit the mednafen.cfg file - look for the line for the CD bios path. Put in the path that has your system cards(roms) and save the CFG file.

From there, just type:

 mednafen somegame.cue

once the game is running press ALT+D to get into the debugger. Some keys for the debugger interface: "s" to stop or step once instruction at a time, "r" run ( or run until break), shift+enter changes the source address of the short memory display below the disassembler, "enter" changes the starting point for the disassembler , "spacebar" marks a spot for breakpoint in the disassembler window, shift+r breaks on a read addresses ( PC or read instructions ), shift+w breaks on write addresses, control+r breaks on vram read addresses, control+w breaks on vram write addresses, O breaks on opcode(hex value), "F10" resets the system, "F5" save state, "F7" load state. You can use the directional arrows to move around the debugger screen - the action area/sport will be highlighted.

For the read/write CPU break points the address is in hex and is a 16bit address 0x0000-0xFFFF. The CPU actually has a 21bit address bus via use of internal MPR registers. For to break on a specific absolute address, use the * before the address value. So to break on addresses in bank 11, the absolute address of bank 11 is 0x22000 - 0x23FFF. Don't use the C style hex notation just *22000 for absolute or 1BFF for logical address.

when in the debugger alt+1 is the main debugger screen, alt+2 is the tile/sprite viewer, alt+3 is the memory editor.

In the memory editor, press "<" and ">" to go between "RAM" "VCE" "VDC" "PSG" "CPU logical" "CPU physical" "ADPCM".

There are a lot more keys for each more, including dumping an area of memory to a binary file.


As far as the difference between Ziria CD and SCD: the SCD version was recompiled for SCD and the script is compressed so it does use the extra memory of the SCD unit. Dave Shadoff looked into this as part of a translation prospect.







termis

  • Hero Member
  • *****
  • Posts: 1485
Re: Debuggers for the PC Engine:
« Reply #2 on: June 08, 2007, 06:25:44 PM »
The only public debugger for PCE/TG and CD systems is mednafen (http://www.mednafen.com). You need to edit the mednafen.cfg file - look for the line for the CD bios path. Put in the path that has your system cards(roms) and save the CFG file.

From there, just type:

 mednafen somegame.cue

once the game is running press ALT+D to get into the debugger. Some keys for the debugger interface: "s" to stop or step once instruction at a time, "r" run ( or run until break), shift+enter changes the source address of the short memory display below the disassembler, "enter" changes the starting point for the disassembler , "spacebar" marks a spot for breakpoint in the disassembler window, shift+r breaks on a read addresses ( PC or read instructions ), shift+w breaks on write addresses, control+r breaks on vram read addresses, control+w breaks on vram write addresses, O breaks on opcode(hex value), "F10" resets the system, "F5" save state, "F7" load state. You can use the directional arrows to move around the debugger screen - the action area/sport will be highlighted.

For the read/write CPU break points the address is in hex and is a 16bit address 0x0000-0xFFFF. The CPU actually has a 21bit address bus via use of internal MPR registers. For to break on a specific absolute address, use the * before the address value. So to break on addresses in bank 11, the absolute address of bank 11 is 0x22000 - 0x23FFF. Don't use the C style hex notation just *22000 for absolute or 1BFF for logical address.

when in the debugger alt+1 is the main debugger screen, alt+2 is the tile/sprite viewer, alt+3 is the memory editor.

In the memory editor, press "<" and ">" to go between "RAM" "VCE" "VDC" "PSG" "CPU logical" "CPU physical" "ADPCM".

There are a lot more keys for each more, including dumping an area of memory to a binary file.


Wow, thanks a bunch for all that - That's some good info there.

Quote
As far as the difference between Ziria CD and SCD: the SCD version was recompiled for SCD and the script is compressed so it does use the extra memory of the SCD unit. Dave Shadoff looked into this as part of a translation prospect.


Ah hah... But now you just told me everything I wanted to know!   :dance:   Well, almost.  Does you mean that the script is cached in the SCD portion of the RAM, where as it wasn't before?

And does that also mean there's some interest in people translating Ziria?  :D

Anyway, I definitely appreciate the info.  As I find some more time, I'm seriously considering trying out some coding for the PC Engine. It seems like it could be a good time waster.

ParanoiaDragon

  • Hero Member
  • *****
  • Posts: 4619
Re: Debuggers for the PC Engine:
« Reply #3 on: June 08, 2007, 07:57:03 PM »
IIRC, there's interest in both Ziria & CF1.

malducci

  • Guest
Re: Debuggers for the PC Engine:
« Reply #4 on: June 09, 2007, 03:55:24 AM »
CF1 project has already been started by Dave Shadoff. He's making all the tech info public as we go along. Ziria (version CD 2.0) really needs a professional translation job to do it justice - plus the script it really big. If we could find a translator capable of, and willing to stick with the whole script, then we get working on the Ziria project.

Quote
As I find some more time, I'm seriously considering trying out some coding for the PC Engine. It seems like it could be a good time waster.

Hey, cool :D if you've got questions, come over to the (efnet) #utopiasoft channel. And if your interested in using assembly, I could throw together some skeleton apps + some tutorials. If C is more your style, then Nodtveidt would be the man to go to.

ParanoiaDragon

  • Hero Member
  • *****
  • Posts: 4619
Re: Debuggers for the PC Engine:
« Reply #5 on: June 09, 2007, 09:19:55 PM »
I suppose there's no chance of english audio in CF1......I believe all the audio is redbook.  I wish there was atleast an easy way to include subtitles during those parts.

nodtveidt

  • Guest
Re: Debuggers for the PC Engine:
« Reply #6 on: June 09, 2007, 10:07:08 PM »
All redbook? That makes it even easier to replace spoken dialogue, as long as you have a sound person taking care of any background audio, such as music or foley effects.

termis

  • Hero Member
  • *****
  • Posts: 1485
Re: Debuggers for the PC Engine:
« Reply #7 on: June 10, 2007, 12:02:08 PM »
Hey, cool :D if you've got questions, come over to the (efnet) #utopiasoft channel. And if your interested in using assembly, I could throw together some skeleton apps + some tutorials. If C is more your style, then Nodtveidt would be the man to go to.

I'd most likely go at it with C.  I only had a semester of x86 assembly, and it just boggles my mind how anyone can make a full-fledged application in any type of assembly language.  It seriously blows me away when I hear about games like the Saturn Virtua Fighter 2 was written in assembly, let alone home-brew apps.  It took me forever to just write some incredibly simple apps in assembly. 

All redbook? That makes it even easier to replace spoken dialogue, as long as you have a sound person taking care of any background audio, such as music or foley effects.

Yeah, I think even the original didn't have too many other things other than straight speech (though I'm sure for anyone who worked on it would seem like tons).  I do recall a few explosions, some shattering noises and whatnot, but I think vast majority of the clips were just speech.  Other than the actual recording, timing everything would be the biggest job, unless the timing sequence for the audio clips itself was also hacked somehow.

What I'd love to see is Ys IV sound track going through a complete dub.  That would rule.

ParanoiaDragon

  • Hero Member
  • *****
  • Posts: 4619
Re: Debuggers for the PC Engine:
« Reply #8 on: June 10, 2007, 07:14:38 PM »
I think I was tired when I wrote that ](*,)  Anyways, I guess it wouldn't be too hard, as long as there's no music that would have to be recomposed.  I know I wouldn't want to try recomposing, as I probably don't have the right sounds to make it sound just right.  But, the other problem is finding someone who would want to be the head of the dub project.  I personally was on the Ys 4 project, & it could've been finished, but Justus wanted perfection sound quality-wise, which is fine, I'm not putting him down, but, I think we could've had it finished & sounding fine, if we'd gone thru with all of it.  I had already done my Dr. Flair parts, & was getting ready to be the narrator ala Alan Openheimer.......or atleast as close as I could get to how he sounded in the narration of Ys 1 & 2.