Author Topic: PC-Engine...how are Rom banks laid out for pointers?  (Read 464 times)

burn_654

  • Full Member
  • ***
  • Posts: 130
PC-Engine...how are Rom banks laid out for pointers?
« on: February 15, 2012, 07:11:14 AM »
Hi there, got a tech question. For the PC-Engine, what is the addressable size of rom banks? (For instance, with gb it's 0x4000 bytes, snes 0x8000 bytes) I'm trying to do some pointer calculation for Momotarou Katsugeki and making some progress, but otherwise bizarre results. So far what I have is taking the hex address, adding 6000 (or 8000 sometimes) and reversing the last two bytes.

For instance, 0001F5A5 + 6000 becomes 000255A5 which makes A5 55 become a working pointer. But I'm having trouble addressing text later on in the rom.
Anyone have experience with this?
Quote from: RegalSin
You know for that r-tard who goes like "oh something retro, let me put down my vabagelina, stop drinking my cheeze wine, and get to playing".

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: PC-Engine...how are Rom banks laid out for pointers?
« Reply #1 on: February 15, 2012, 08:48:19 AM »
The rom banks are 0x2000 in size. There are eight page registers 8k in size that make up the 64k cpu logical address range. Any bank of the rom can be mapped in any page register (MPR). As for pointers, I've seen them stored in quite a few different formats on the PCE (from the games that I've traced through). Some store just the 8k logical boundary, add or 'OR' the page bits to get the correct offset, then load in the bank separately. I haven't seen any commercial games that store the rom address as full 24bit address or 8bit(bank)+16bit(13bit page offset). At least, not that I can remember. Usually the data belongs to a larger block and so just a few bank #'s are required (as in then just store the first bank # and increment map from there - like 16k or 24k etc). 

burn_654

  • Full Member
  • ***
  • Posts: 130
Re: PC-Engine...how are Rom banks laid out for pointers?
« Reply #2 on: February 15, 2012, 09:24:34 AM »
Hmm...I'll admit I'm a little new to this. I'm mainly interested in trying to learn how to repoint to empty space...

As far as I can tell, my pointer looks like this:

A9A585BFA95585C0

The bold represents my hex values having been reversed, and this points to the 0001F5A5 hex location (an intro dialog). For instance by increasing A5 I can start a few characters later.

To point it to 0001F077 (another dialog) I've done this and it works:
A97785BFA95085C0

What's bizarre is that pointing to 00043F9C (some free FFFF space), this works:
A99C85BFA9BF85C0

But for 00045F8B it doesn't:
A98B85BFA9DF85C0

Now I could understand that the two existing dialogs are closer to each other (the same bank it looks like) but I'm uncertain how I was able to point to as far as 00043F9C like this.
Does anything look apparent from the pointer math/the bytes surrounding them? Figuring out how it knows what it knows, haha.
« Last Edit: February 15, 2012, 09:30:52 AM by burn_654 »
Quote from: RegalSin
You know for that r-tard who goes like "oh something retro, let me put down my vabagelina, stop drinking my cheeze wine, and get to playing".

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: PC-Engine...how are Rom banks laid out for pointers?
« Reply #3 on: February 15, 2012, 07:01:20 PM »
Hmm...I'll admit I'm a little new to this. I'm mainly interested in trying to learn how to repoint to empty space...

As far as I can tell, my pointer looks like this:

A9A585BFA95585C0

The bold represents my hex values having been reversed, and this points to the 0001F5A5 hex location (an intro dialog). For instance by increasing A5 I can start a few characters later.

To point it to 0001F077 (another dialog) I've done this and it works:
A97785BFA95085C0

What's bizarre is that pointing to 00043F9C (some free FFFF space), this works:
A99C85BFA9BF85C0

But for 00045F8B it doesn't:
A98B85BFA9DF85C0

Now I could understand that the two existing dialogs are closer to each other (the same bank it looks like) but I'm uncertain how I was able to point to as far as 00043F9C like this.
Does anything look apparent from the pointer math/the bytes surrounding them? Figuring out how it knows what it knows, haha.



 Heh... those hex values are opcodes:
Code: [Select]
    lda #$a5    ;a9 a5
    sta <$bf    ;85 bf
    lda #$55    ;a9 55
    sta <$c0    ;85 c0


 It's loading an immediate value in a pair of zero page regs to form an indirect address register. But that immediate address is only 16bits long, not 24bits or such. You should get mednafen emulator and trace through the code (set a read break point a offset text string). Without seeing all or most of the code, I don't know what it's doing.

Also, if you're hacking (and if you're new to PCE) - these cribsheets can help out: http://pcedev.wordpress.com/downloads-and-links/  (there's two pages there). They're meant for printing out on a high resolution printer, but you can still use them in the pic viewer.