(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		05-06-24 11:19 AM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - SNES Hacking, RAM Write Breakpoints, and Frustration (Need Help) New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
QBRADQ

Goomba


 





Since: 01-18-06
From: Eastern Oklahoma

Last post: 6637 days
Last view: 6637 days
Posted on 02-17-06 06:32 PM Link | Quote
Hello again.

Umm, I thought I had been posting to this board over the past few weeks, but none of the posts have gone through. Not sure what that's about, so I will be monitoring this one closely to see what's going on (possible I was forgetting to hit "Submit Thread" on the preview page).

NOTE: Using snes9x1.43.ep9r8

Anyway... what brings me here to ask for help is something that is frustrating the heck out of me. I'm hacking into an SNES ROM that's almost untouched (I'll be telling you what game it is once I have enough info to post). I've been looking for the map data, but had to start out with the few values that I knew. So, I found the RAM locations for enemy stats and the like, then traced where those came from in the ROM. Then, I figured out how this data was indexed, and where the index is stored in RAM.

However, I've now hit a wall while trying to trace where the index values are loaded from ROM. I've set a write breakpoint for 7EE83D, which is the RAM address of an enemy index value (8-bit, P->M=ON), but the breakpoint never trips. I can open up the hex viewer and watch the value change as expected, yet the breakpoint doesn't trip. Only on rare occassion (when the enemy loaded in at 7EE800 - 7EE9FF drops an item) does the breakpoint trip. At this point, the index value is set to 0xEA (possibly others, I've only seen this happen twice) no matter what the index value of the enemy was.

So... I used some creative save states and the "Frame Advance" feature to get a full CPU trace of the frame preceeding, the frame of, and the frame after the index value is set. Being nearly 90,000 operations long, I couldn't got through the entire trace by hand, so I used OpenOffice's spreadsheet application to search through it. The only time the program makes referance to an E83D address is when it reads the index value before loading the enemy data.

Digging a little deeper, I discovered that there are four DMA transfers (two General DMA, and two H-DMA) that occur at the begining of the frame in which the index value changes (I didn't look at the other frames). I thought this might be something, like the program is DMA'ing a bunch of data into the 7EE800 - 7EE9FF range on enemy load. However, from my understanding of the SNES's DMA, you can only transfer between the CPU and PPU.

This has indeed be frustratting. I have yet to attempt and trace the DMA opperations to see what is going on with those.

Questions
1) Is a CPU-ROM to CPU-RAM DMA transfer possible?
2) Are there any known bugs with snes9x1.43.ep9r8's debugger that might be makign it miss some instruction (specificaly something to do with storing to a relative memory address)?
3) Has anyone else come upon a similar problem? And if so, what was the solution?

Thanks,
QBRADQ

(edited by QBRADQ on 02-17-06 05:50 PM)
BMF54123
WARNING: MOOD LEVEL CRITICAL








Since: 11-18-05
From: MOOGLES

Last post: 6286 days
Last view: 6286 days
Posted on 02-18-06 04:18 AM Link | Quote
Originally posted by QBRADQ
Is a CPU-ROM to CPU-RAM DMA transfer possible?
Yes indeed. You just write a 17-bit RAM address ($00000-$1FFFF, or $7E0000-$7FFFFF) to $2181-$2183, and then DMA to $2180.

(edited by BMF54123 EX Alpha + on 02-18-06 03:24 AM)
Parasyte +

Red Paragoomba


 





Since: 01-05-06

Last post: 6607 days
Last view: 6607 days
Posted on 02-18-06 02:08 PM Link | Quote
I recall Geiger's debugger had incomplete breakpoint support for certain instructions. For example, the MVP/MVN instructions would not snap the debugger as you'd expect. I haven't any idea if these issues were ever looked at. There was a big debate about the whole thing a long while back which went nowhere.
d4s

Shyguy








Since: 12-01-05

Last post: 6409 days
Last view: 6306 days
Posted on 02-18-06 06:38 PM Link | Quote
Originally posted by BMF54123 EX Alpha +
Originally posted by QBRADQ
Is a CPU-ROM to CPU-RAM DMA transfer possible?
Yes indeed. You just write a 17-bit RAM address ($00000-$1FFFF, or $7E0000-$7FFFFF) to $2181-$2183, and then DMA to $2180.



wrong.
dma works by simultanously reading from the a-bus(rom,ram) and writing to the b-bus or vice versa.
although this looks like a neat way to copy stuff from rom to ram, its not possible on the actual hardware.
theres no way to transfer from a-bus to a register on the b-bus that in turn writes to the a-bus.


i know zsnes allows it, but it will break your code on the real thing, so just dont use it.

as parasyte suggested, use mvn/mvp instead, but be sure to read up how they work exactly before you try to implement them.


oops, didnt read the initial post.
i think its highly unlikely that things with a size of one or two bytes like individual enemy stats get transferred via block move commands (mvn/mvp).



(edited by d4s on 02-18-06 05:40 PM)
(edited by d4s on 02-18-06 05:41 PM)
(edited by d4s on 02-18-06 05:48 PM)
QBRADQ

Goomba


 





Since: 01-18-06
From: Eastern Oklahoma

Last post: 6637 days
Last view: 6637 days
Posted on 02-18-06 07:05 PM Link | Quote
Indeed. There are no MVN or MVP operations within the trace.

I really hope I can figure this out soon. Does anyone know of another emulator that has a debugger? Or perhaps just a command-line debugger I could use? I'm desperate here people!

Thanks,
QBRADQ
Sukasa

Birdo
Not quite as active as before.
Xkeeper supporter
Xk > ||bass
I IP Banned myself! Twice!








Since: 11-17-05
From: Somewhere over there

Last post: 6287 days
Last view: 6286 days
Posted on 02-18-06 09:37 PM Link | Quote
d4s: What register did you forget about? There's a set of 4 registers (17-bit addy, and an 8-bit data register) that are in the $21xx range that you can write to for Rom-> RAM memory-fill and that.

Check Qwerty's SNES hardware doc, in the DMA section.
BMF54123
WARNING: MOOD LEVEL CRITICAL








Since: 11-18-05
From: MOOGLES

Last post: 6286 days
Last view: 6286 days
Posted on 02-19-06 03:30 AM Link | Quote
Originally posted by d4s
although this looks like a neat way to copy stuff from rom to ram, its not possible on the actual hardware.
theres no way to transfer from a-bus to a register on the b-bus that in turn writes to the a-bus.

i know zsnes allows it, but it will break your code on the real thing, so just dont use it.
Oooookay...then what in the world are those registers good for? Seems silly to allow WRAM access from a PPU register when you can't even use DMA.
d4s

Shyguy








Since: 12-01-05

Last post: 6409 days
Last view: 6306 days
Posted on 02-19-06 11:16 AM Link | Quote
Originally posted by Sukasa +
d4s: What register did you forget about? There's a set of 4 registers (17-bit addy, and an 8-bit data register) that are in the $21xx range that you can write to for Rom-> RAM memory-fill and that.

Check Qwerty's SNES hardware doc, in the DMA section.


i dont think you got my point.
of course, $2180-$2183 can be used to write to ram.

that wasnt the question, however.
the question was: "is it possible to transfer data to wram by dma'ing to registers $2180-$2183?"

i will try to explain that again:
the snes has two busses, the A-bus (24-bit adressbus, cartridge rom, wram) and the B-bus (8-bit adressbus, apu ports, ppu regs).
from the cpu's pov, the B-bus is located at $2100-$21ff.

each bus can only be accessed by one device at a time.

dma works so fast because it accesses both busses simultanously, read from the a-bus (rom, for example) and write to the b-bus(vram ports) or vice versa.

however, its not possible to read AND write to the same bus at the same time.

but by dma'ing to regs $2180, youre exactly trying to do that.

dma reads data from the rom(a-bus) and transfers it to the wram port(b-bus).
at the same time, the wram port tries to write that data back to wram(a-bus).
thus, the dma reads and the wram port writes conflict, because both try to access the a-bus at the same time.

just because you CAN do this or that programming-wise, that doesnt mean that it will actually work, especially on the snes.
writing to vram outside blanking periods would be another example of this.
just dont do it.

and if you cant test your code on a real machine, be sure to at least test it in byuus bsnes, its the most accurate snes emu out there and imho the only one that fully emulates the above-mentioned limitations of the hardware.

i think byuu visits this board from time to time.
if you've questions regarding limitations of the hardware, ask him.


bmf:
i've never used the wram port regs, either.

but i think they're quite useful if you want to copy data from rom to ram fast and modify it at the same time.(decompressing data, building tilemaps and stuff like that)
first, you dont have to update the pointer to wram and second, you dont have to do writes to a 24bit adress in order to access wram-adresses above $7e1fff.

(edited by d4s on 02-19-06 10:28 AM)
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6286 days
Last view: 6286 days
Posted on 02-20-06 07:30 AM Link | Quote
@QBRADQ: Try Sleuth. It both logs, does breakpoints, and allows you to step through code line by line. It also allows you to step through the SPC700, though you can't breakpoint or log.

@the thread:

Of note is that Neviksti's InitSNES.asm file uses registers $2180-83 to initialize WRAM. I'll post it for your viewing pleasure:

;**** clear WRAM ********

STZ $2181 ;set WRAM address to $000000
STZ $2182
STZ $2183

LDX #$8008
STX $4300 ;Set DMA mode to fixed source, BYTE to $2180
LDX #wram_fill_byte
STX $4302 ;Set source offset
LDA #:wram_fill_byte
STA $4304 ;Set source bank
LDX #$0000
STX $4305 ;Set transfer size to 64k bytes
LDA #$01
STA $420B ;Initiate transfer

LDA #$01 ;now set the next 64k bytes
STA $420B ;Initiate transfer

...

And that's all it takes really. I didn't even know these registers existed until I was trying to fix something in Sukasa's homebrew rom he posted before the board crash. (It of course used Neviksti's code to initialize.)

edit:@d4s: So uh... I noticed the code I gave above does not work, according to you, so I decided to try to find a professional game that used such a technique. My first try was DKC and it showed up as the first DMA transfer:

DMA[0]: write Mode: 0 0x80A90B->0x2180 Bytes: 0 (fixed) V-Line:8

Now that's actually 64K of bytes but whatever. It's possible the developers at rare were incorrect and that this doesn't actually do anything on the real thing, but don't you find this at least a little bit odd, given they probably had way better debugging environments than us? Though... as far as the bus conflict goes, this is indeed a "fixed" address transfer, so that may be why it could theoretically work. i.e. if I understand correctly, only one bus access is needed from rom, though I don't know if this access is in reality performed only once.

Edit2: Blackthorne also uses it in a similar fashion. Have not yet encountered a sequential write to $2180, and don't expect to.

(edited by MathOnNapkins on 02-20-06 07:49 AM)
(edited by MathOnNapkins on 02-20-06 08:25 AM)
Sukasa

Birdo
Not quite as active as before.
Xkeeper supporter
Xk > ||bass
I IP Banned myself! Twice!








Since: 11-17-05
From: Somewhere over there

Last post: 6287 days
Last view: 6286 days
Posted on 02-20-06 01:04 PM Link | Quote
...And in that crash, it seemed to be related to either the tilemaps of the graphics later on. Before those I had a palette upload, which worked fine. Also, in that ROM, it seemed that the MVP instruction I was using didn't work for some reason... I think it might be interrupts messed with it.

Anyways, that ROM... died in my computer's hard drive failure, so I'm redoing it from scratch... On an old WIN3.1 compy :\
Gideon Zhi

Keese








Since: 12-05-05
From: ...behind you! Boo!

Last post: 6289 days
Last view: 6286 days
Posted on 02-20-06 02:35 PM Link | Quote
d4s- Dunno what you've been doing, but I've been using code like this in my games for a very long time. Copy and pasted from my DMA Beginner's Doc:


org $02895F
JSL $1FE300 ;Here, we overwrite the old JSL that decompressed the font.
;Read the log to find out how this address was determined.
;If you don't have a 4-byte JSL or load to overwrite, then
;you'll need to overwrite more than one command and reproduce
;them in your DMA routine.

%org $1FE300 ;1FE300 is some blank space before our font. Yay.

LDA #$00 ;$4300 is the DMA control register. Unless you're writing directly to vram,
STA $4300 ;this should probably always be zero.

LDA #$80 ;$4301 is the destination register. The upper address is assumed to be $21,
STA $4301 ;so you're gonna have to figure out which of the $2100-$21FF registers you
;want to write to.

LDA #$00 ;...in our case, since we're writing to WRAM ($7E:0000-$7F:FFFF), we need to
STA $2181 ;use $2180. We store the address that $2180 goes to in $2181-$2183. I'm going
LDA #$11 ;to leave these blank, but they're in standard pointer format. Of note is that
STA $2182 ;bank $7E must be written as $00, and $7F must be written as $01.
LDA #$01 ;So, if you were writing to $7F:9320 you'd write $20, $93, $01 in that order
STA $2183 ;to $2181, $2182, and $2183 in that order.

LDA #$00 ;These registers contain the address your read starts from. Since we're dealing
STA $4302 ;with loroms, you need to remember how lorom addressing works, and you'll need
LDA #$F0 ;to convert the address of your new font ($FF000, right?) to a standard 24-bit
STA $4303 ;LoROM pointer. I'll leave these blank as well.
LDA #$1F ;You should be able to fill them in yourself.
STA $4304

LDA #$00 ;$4305 and $4306 are the number of bytes you need to copy. Again, the order of
STA $4305 ;the bytes is the same as before -- the high byte of your address comes LAST.
LDA #$10 ;Notice that you can't exceed 64K in this. That's cuz of the bank boundaries.
STA $4306 ;Don't try to copy more than 32K if you're dealing with loroms, either.
;Note that since you're not doing -addresses-, counting here starts from $0,
;not $8000, like lorom addresses would.

LDA #$01 ;This register starts DMA! Note that there are 8 DMA channels that can be used
STA $420B ;if you want to do more than one DMA at a time (channels 0-7.) We're using
;Channel 0. If we wanted to use channel 1, we'd be writing to $431X instead of
;$430X. The same holds for the rest of the DMA channels.
;Note that writing a byte to $420B can start more than one channel at a time!
;Since we're writing #$01 to it (00000001 binary), we're starting channel 0.
;If we wrote #$02 (00000010 binary), we'd start channel 1.
;If we wrote #$03, we'd start channels 0 -and- 1!

RTL ;Kay, we're done!


And damn straight it works on the real thing. Been doing this for years. I think the first game I used this code in was Gundam Wing Endless Duel, back in june of '02 :p

Edit: I'm positive I've used the same code, or at least extremely similar derivatives, in at least Gundam Wing, Shin Megami Tensei 2, Kunio-tachi no Banka, G-Gundam, Rockman & Forte, Gunman's Proof, Super Robot Wars 3, King of Demons, Magical Pop'n, Jutei Senki, Cyborg 009, Madou Monogatari, and Hiouden. It's also used in Shiren, although that's not out yet (soon!), and I might have to employ it in Fire Emblem. I can also say for certain that I've completed Gundam Wing, Kunio, Rockman & Forte, Gunman's Proof, King of Demons, Magical Pop'n, and Madou Monogatari on my swcdx2 copier :p

(edited by Gideon Zhi on 02-20-06 01:46 PM)
Sukasa

Birdo
Not quite as active as before.
Xkeeper supporter
Xk > ||bass
I IP Banned myself! Twice!








Since: 11-17-05
From: Somewhere over there

Last post: 6287 days
Last view: 6286 days
Posted on 02-20-06 04:37 PM Link | Quote
Well, why would they even have those registers if they didn't work on the real thing? Those registers will really help with my filing system in my SNES game... fragmented files aren't always fun.
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6286 days
Last view: 6286 days
Posted on 02-21-06 03:01 PM Link | Quote
^ The issue is not whether they work, but whether they work with DMA. I'm pretty sure that using $2180-83 with a loop would be at least twice as fast as MVN or MVP. So even without DMA you could block move from WRAM to WRAM fairly quickly.

MVN/MVP use a lot of cycles - I've heard either 7 or 8 cycles per byte. that's why I think using these registers would be better. I'm wondering, however, if the cycles mentioned in documents are master cycles or cpu cycles. I'm leaning towards cpu cycles, but I can hope.
Sukasa

Birdo
Not quite as active as before.
Xkeeper supporter
Xk > ||bass
I IP Banned myself! Twice!








Since: 11-17-05
From: Somewhere over there

Last post: 6287 days
Last view: 6286 days
Posted on 02-22-06 12:10 AM Link | Quote
7 cycles a byte. I've changed my mind to use DMA for all file loading in that ROM. Now I just have to put together a macro system that works... I might be asking for help in that regard...
Gideon Zhi

Keese








Since: 12-05-05
From: ...behind you! Boo!

Last post: 6289 days
Last view: 6286 days
Posted on 02-22-06 08:52 PM Link | Quote
I asked the question of former-emulator-coder MKendora in my IRC channel, and this was the response:


[MKendora] you can't go WRAM to WRAM.
[MKendora] you can go ROM to WRAM, as far as I know.
[MKendora] RAM's not exactly on the A bus.
[Lakmir] this is a major concern for me, because a lot of my translations rely on DMA from ROM to $2180
[MKendora] Someone's on crack there.
[Lakmir] I can always replace the code with MVN or a load/store loop, but I'd rather keep the DMA if possible.
[MKendora] The only thing you can't do it A-bus WRAM to B-bus WRAM.
[MKendora] or DMA to DMA registers.
[MKendora] lots of games use that, iirc.
[MKendora] (ROM to 2180)
[Nightcrawler] According to Anomie's docs, you CAN write to RAM via DMA
[Nightcrawler] http://romhacking.deadbeat-inc.com/docs/regs.txt
[MKendora] then you pretty much can.
[MKendora] anomie's seldom wrong.
[MKendora] neviksti is the authority on limits...
[MKendora] and he only said no WRAM to WRAM DMAs.


Simply put, I think d4s is wrong No offense, man!
eNathan
Newcomer


 





Since: 02-22-06
From: Earth

Last post: 6514 days
Last view: 6514 days
Posted on 02-23-06 01:48 AM Link | Quote
QBRADQ, this is my only sugestion if your breakpoints are not triggering. Use an external software to do it, such as TSearch. Google for it
d4s

Shyguy








Since: 12-01-05

Last post: 6409 days
Last view: 6306 days
Posted on 02-25-06 06:35 AM Link | Quote
Originally posted by Gideon Zhi

[MKendora] you can't go WRAM to WRAM.
[MKendora] you can go ROM to WRAM, as far as I know.
[MKendora] RAM's not exactly on the A bus.


yep, i was wrong there guys, sorry for causing confusion. ~_=
mixed up wram/wram and rom/wram somehow.

still, i wonder what other bus wram is supposed to be connected to.
i'll have look at some official diagrams, but from what i recall, it was on the a-bus aswell.
maybe wram is some kind of special case, i think i'm gonna ask neviksti how it works exactly.

i will try this out later in places where i currently use mvn/mvp.

(edited by d4s on 02-25-06 05:37 AM)
(edited by d4s on 02-25-06 05:41 AM)
(edited by d4s on 02-25-06 05:42 AM)
creaothceann

Red Goomba








Since: 11-22-05

Last post: 6481 days
Last view: 6481 days
Posted on 02-25-06 11:19 AM Link | Quote
Look for anomie's docs on RomHacking.net, I think he mentioned it somewhere.
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - SNES Hacking, RAM Write Breakpoints, and Frustration (Need Help) |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.022 seconds; used 454.09 kB (max 580.41 kB)