11 March 2016 - Forum Rules
Started by Hop, February 13, 2016, 12:11:58 PM
Quote from: Hop on February 13, 2016, 06:23:43 PMThis file doesn't seem to give the addresses that the gfx roms load into.
Quote from: Hop on February 13, 2016, 06:23:43 PMROM_REGION( 0x600000, "gfx", 0 )
Quote from: Hop on February 14, 2016, 03:24:12 AMit would look like ROM_REGION( 0x600000, "gfx", 0 ) defines a region with length 0x600000 rather than address 0x600000.
Quote from: mz on February 14, 2016, 03:35:30 AMIn that case, the line "ROM_REGION( CODE_SIZE, "maincpu", 0 )" should give you the "gfx" address. Just find what that CODE_SIZE constant is, and replace it in "save mem.bin, CODE_SIZE, 20000".
Quote from: Hop on February 14, 2016, 04:29:11 AMAs an experiment I tried changing the first 2 words of Region: ':maincpu' in the memory window to 1234 5678 then running f 0,100000,d.12345678 gives "Found at 000000"However changing the first 4 bytes of Region: ':gfx' in the memory window to 12 34 56 78 then running f 0,800000,d.12345678 or f 900000,700000,d.12345678 both return"Not found"
Quote from: Hop on February 17, 2016, 04:36:46 AMThanks for the information. I'm slowly beginning to understand how it all works.Am I correct in thinking that after the game is up and running in MAME, editing the gfx region of memory in the debugger will have no effect on the actual in-game graphics because at that point the data has already been decoded into another (MAME) buffer? If so, is there a way to ask MAME to re-decode?
Quote from: Hop on February 17, 2016, 05:09:01 AMI'm more interested in finding out how the data is stored and decoded that hacking the ROM. I'll step through the code that uses the data defined in the GFXDECODE macros to figure out how the data is stored/coded.
Quote from: Hop on February 17, 2016, 06:08:02 AMWow. That's great. Many thanks. What defines where the memory for each of the different sets is starts? So for example knowing the 16x16 layout, where does the actual 16x16 data start in ROM/memory?
Quotegraphics ROMs on CPS1 (like most arcade hardware) aren't mapped into any CPU's address space. Graphics ROMs in arcade machines are like CHR ROM on the NES: the CPU doesn't need to (and usually can't) read them, they're directly connected to the graphics hardware.
QuoteThe MAME debugger is generally more targetted toward developing new drivers and fixing emulation bugs than at facilitating ROM hacking.
Quote from: Hop on February 18, 2016, 07:21:15 AMThanks for the info. I've got some code up and running that loads the roms and displays the 8x8 gfx data. I'll extend it to the other sets later. I then came across MAME decode() function which does the same thing!This is very interesting. I'd never really thought that the CPU would not have access to the data. I guess the video hardware would have to be used to perform pixel perfect collision detection, and any tile metadata would have to be defined in the program address space.I was also expecting to see palette data in the ROMs, but it looks like this is stored in the CODE and put in place as and when required - it seemed a little strange having the colour indices and the colours themselves in two different regions of memory, but I guess it gives allows for palette effects (like the fades I've seen in sf2).
QuoteDoes this imply that any pull requests made that don't move MAME in this direction would be rejected?
Page created in 0.170 seconds with 19 queries.