Offline
Michigan

Current Status: Trippy H loads immediately and cannot be exited as though it were a dedicated Trippy-H cart.

------- old:
Here is something I have been working on for a few days now and only got a little bit of progress. But progress is progress and this really helps me understand gameboy debugging.

Analyzed the WRAM addresses for any and all changes that occur when you press buttons, select particular cursor locations and of course: when you enter DJ mode (Trippy H).
After hours and hours, I found that WRAM $D5CE is the game mode byte, or at least that's what I call it. This byte is changed directly before switching between dancing mario, menu, view, shoot and trippy H (as well as the other menus and modes).

Dance = 19, menu = 00, shoot = 01, DJ = 1F, view = 02, play - 07, etc.

After learning this, I set an access break when the byte 00 is written to $D5CE
1:D5CE 00 w
The first instance was when you press a button while mario dances. I restarted the emu and pressed A. The code broke and stopped at $74AC where there was an "LD A, $00"

I replaced this with "LD A, $1F" and restarted again.

This time when you press a button at dancing mario, Trippy H starts!

----------------------------------------------------------------------------------------------------------------

Next update I would like to stop the cart from checking if the camera is present. This will allow the ROM to be put onto a normal flash cart.
Has someone done this before?

2nd future update would be to remove unnecessary routines like "shoot  " and "view" hopefully the ROM itself can be reduced in size. Potentially an MBC1 + SRAM + BATTERY

3rd future update I would like to break the ROM even more and remove saving altogether so that it can be safely put on a 64M cart along with LSDJ or a dedicated ROM only cart. There of course would be two versions, one with saving and one without.

Last edited by Jazzmarazz (Jan 29, 2016 1:35 am)

Offline
Australia

I've already stripped the cam register ready checking. Ill dig it up for you. If you trap all reads from the sram region you'll find an infinite loop that waits for bit x to set/clear. There are two or three of these routines you'll need to nop out and it'll boot on any flash cart.

Offline
NUMBSKULL

Could you just modify the JP instruction at 0100-0103 to go straight to Trippy H instead of the normal menu location?

I'm out of my league here.

Offline
Michigan
BennVenn wrote:

I've already stripped the cam register ready checking. Ill dig it up for you. If you trap all reads from the sram region you'll find an infinite loop that waits for bit x to set/clear. There are two or three of these routines you'll need to nop out and it'll boot on any flash cart.

Not surprised you've done this. I could have sworn I read about it somewhere. Yeah, please find it. smile

catskull wrote:

Could you just modify the JP instruction at 0100-0103 to go straight to Trippy H instead of the normal menu location?

I'm out of my league here.

Its pretty packed there. Stack pointer, video registers, etc.
I have also tried skipping the dancing mario, but that breaks the rom. Ideally dancing mario could be switched with a custom Trippy H intro. wink
in any case, the very first interaction with the gameboy jumps into Trippy H so I am no longer worried about that.

Offline
Michigan

Ok. By replacing $40DB with "LD A, $1F" the player may never leave Trippy H. This allow for us to remove unused routines and officially make this a Trippy-H-dedicated ROM.

Offline
Australia

I think Catskull is onto something, we should take a snapshot of the VRAM when in Trippy H, then work back to find the functions that load the data, then it would be a simple jump.

WRAM, VRAM, SND registers, OAM/Pallet data. That's all that should be necessary? The stack *should* be empty or its contents not important.

Offline
Michigan

IDK about that. I feel like there is more to it than a simple jump.

If a simple jump is what you want, then I think you need to locate a write to $D5CE with $1F. This is the byte which says which mode we are playing. 1F pertains to T-H.

Performing a write break of 1F to that location (when I shoot the Dj-spaceship) is at $568B:

LD A, $1F
LD [$D5CE], A
...

This should return to the main loop after a few more commands. You could try that.

How about the Routines that check if the camera is present?

Offline
Australia

OK, the ROM checks bit 0 of $A000, this is the camera ready flag. It is used for both initialisation and when taking an image. Set a breakpoint on all reads to A000 and you'll catch them all (Pokemon!). Modify these instructions and it'll be compatible on flash carts. Or, you can write $FF to the SRAM and that should be the same as the camera saying its ready.

Offline
Michigan

Thanks Ben. Did you change the cart type in header too? I haven't tested it out on a real cart yet, but my version that skips the other menus never touches A000.

Oh, did you find that fix after we skyped and took apart GB cameras together? xD

Last edited by Jazzmarazz (Jan 25, 2016 6:25 pm)

Offline
Australia

I think you'll find it checks $ A000 before any graphic operations. I didnt bother changing the cart type bits. You might need to if using a derp etc...

A guy on reddit had the idea to copy it to an ems cart then trade between his real camera to get the images onto a pc. I modded the rom and sent it to him but never heard back!

Offline
Michigan
BennVenn wrote:

I think you'll find it checks $ A000 before any graphic operations. I didnt bother changing the cart type bits. You might need to if using a derp etc...

A guy on reddit had the idea to copy it to an ems cart then trade between his real camera to get the images onto a pc. I modded the rom and sent it to him but never heard back!

I am currently stepping through thousands of loops to find that ONE routine that wipes SRAM before the "gamefreaks" logo. SRAM is seemingly randomized and then cleared but it never breaks for me...so I am searching by hand. You say it is checked before any graphic operations wich 'looks' correct when watching the SRAM in real time, but it never breaks!

I have already wiped the routine that triggers the A000 check when you press "shoot" but I just can't find the pre-graphics check.


My method for picture dumping was to copy the save to my Mega Memory Card and then to an EMS and then to PC. No trading or hacking needed.

EDIT1:

The routine at $0462 is as follows:

XOR A
LDI [HL], A
DEC BC
LD A, C
OR B
JR NZ, $0462

This routine is always jumped to after these two lines:

LD HL, $xxxx
LD BC, $xxxx

Where the word stored in HL represents a memory address and the word stored in BC represents the number of times to repeat the routine at $0462. The routine itself clears every byte to 00 in this range. For example, the below code will place 00 in every byte from A000 to AFFF.

LD HL, $A000
LD BC, $1000
CALL $0462

Last edited by Jazzmarazz (Jan 26, 2016 12:08 am)

Offline
Michigan

There is also a routine at $0473 and $0487 that I am now learning. 0473 seems to be toying with the 7th bit of data.
@$0473:

BIT 7, H
JR NZ, $0486

@$0486:

LD [$4000], A
AND A
PUSH AF
LDI A, [HL] // @$048B
LD [DE], A
INC DE
DEC BC
LD A, C
OR B
JR NZ, $048B
POP AF
RET NC
POP AF
LDH [$FF9B], A
LD [$2000], A
RET

in the case I am studying, $0473 is preceded by:

LD A, $17
LD HL, $4980
LD DE, $8CC0 
DL BC, $0260

So there is a little bit more going on than the clearing routine described above.

EDIT1:

In the case of routine $0473:
DE represents a memory address and BC represents the number of times to loop. DE always seems to be within the VRAM area.

EDIT2:

The routine at $0473 is the routine which writes new Tiles to VRAM. I haven't quite figured out how if they come from the address stored in HL yet or not. The bytes themselves don't match up.

EDIT3: There are a few other routines associated with VRAM that I have found. $048B for example writes Tiles to the BG map.

EDIT4: HL in routine $048B represents the the tiles location in VRAM, not the actual sprite itself.

Last edited by Jazzmarazz (Jan 26, 2016 9:45 pm)

Offline
Michigan

A major improvement I would like to make, but am not skilled enough to do, is add a second Pulse channel to Trippy H.
There are three tabs listed as: Sound I, Sound II and Noise, where these represent Pulse 2, Wave, and Noise respectively. Pulse 1 is used for menu sound effects like quitting and saving.  This is useless.


Here is Tab 1, but controls the registers of Pulse 2. You can switch between 3 different pulse width options, even though the gameboy is capable of 4.

Here is Tab 2 called Sound 2, but it controls the wave channel. As you can see, there is a custom waveform being played. There are three options, 1. Pulse with 50% width, 2. the sample you can see and 3. a hand drawn waveform.

And here is the Noise Tab which controls the noise registers. Decent percussion loops can be made here.

For the above three, I would like to remove the Trippy-H text at the top right to make room for a duplicate of Sound I which will control Pulse 1.
Changing their names will be an easy graphics swap once I locate the sprite storage. All of the tabs will be shifted right.

On this page, I would like to remove the "SE" tab. The other tabs can then be shifted to the right to accommodate the addition Pulse 1.

The coolest thing about Trippy-H is the frequency modulation option. At the top right of Sound 1 and Sound 2 control, there is a Modulation box. You can adjust the amplitude of modulation, frequency of modulation and waveform of the modulation.

Offline
sweden

I can't explain how exciting this is! Keep up the great work!

Offline
Michigan
nordloef wrote:

I can't explain how exciting this is! Keep up the great work!

Hey thanks! You can pick one of the WIP versions here:
http://www.epforums.org/showthread.php? … ippy-H-WIP

Offline
NUMBSKULL

Yeah dude, great work. I can't offer much help but I enjoy your updates.