Language…
16 users online: anonimzwx,  BeeKaay, codfish1002, DanMario24YT, Domokun007,  Eevee, HaruMKT, hhuxy, Knight of Time, lean4, margot, ModernKiwi, Pizzagamer9791,  Ringo, SysDataSoft, VLSkoot - Guests: 312 - Bots: 333
Users: 64,795 (2,375 active)
Latest user: mathew

The "unsure ROM/RAM" thread

$18DF is in the Waiting to be Moderated section imamelia
I change my layout every 4-5 months
Yeah, I think one or two of them were. I'll delete them from the list when they actually get accepted.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
noticed that the ROM map was updated recently. I want to view the changes since I last read through it. is there a log to view of added entries in reverse chronological order? there should be. thanks for your time.
I would imagine AlcaRobot to have a log of that, but personally I have never seen such a thing =/
(I want it too, to be honest =P)
Originally posted by Sind
I would imagine AlcaRobot to have a log of that

Does not exist. He overwrites the old ROM/RAM maps when downloading the new one.
There are IDs for every ROM/RAM address, but only ROM/RAM map mods can see them (and then they're only visible in some links to edit and delete the addresses). If I could access those IDs somehow, I'd gladly make a tool to sort them.
<blm> zsnes users are the flatearthers of emulation
I've always wanted to see the "newest" ROM/RAM map additions, but it's not set up that way. If you miss it in the waiting box on the front page, that's it.
I agree, it'd definitely be useful if you should check out the latest ROM/RAM Addresses approved.
To be honest, I'd prefer that we build up the ROM map for now. I mean, we only have 63% of the ROM addresses found. And none are waiting to be moderated. #w{=|} We need to build that up.
This is only because most of the ROM map can't be mapped, the way it's being done right now. Most bytes have no significance by themselves, making it impossible to fully map the ROM.
Now with extra girl and extra hacker
Yeah. I mean, we can't do things like this
$00:8000 | 1 byte | ASM | The opcode SEI
$00:8022 | 1 byte | ASM | The opcode TCD

And so on. They're part of the ROM too and it'd just fill the ROM map with useless things.

Regarding checking out the latest ROM addresses, guess you should talk to Kieran about it but I'm not sure if he'll do it.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
IMO, the ROM map needs more stuff like "ASM routine that handles X" or "Song data: <song name>". I'm not sure why people don't submit that sort of stuff as often as say, hex editing information.


There's nothing in the ROM that "can't be mapped."
Originally posted by Ersanio
Yeah. I mean, we can't do things like this
$00:8000 | 1 byte | ASM | The opcode SEI
$00:8022 | 1 byte | ASM | The opcode TCD



This made me chuckle. So there really is no way to tell an accurate percentage. In that case, 63% is a pretty good amount of the ROM.

Originally posted by Ersanio

Regarding checking out the latest ROM addresses, guess you should talk to Kieran about it but I'm not sure if he'll do it.


Yeah. It's doubtful simply because it would only affect the ROM addresses posted after the feature was implemented. I guess if a Mod added them in with the newest patches, music, sprites, etc. in the news posts, we could see it there.
Well another option is to sort the addresses by their ID. All the addresses have an ID as mentioned earlier. I'm sure ID 1 is the oldest while the highest ID is the newest :D
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Yeah, maybe we couldn't get every individual byte, but surely we could document 100% of the ROM by expressing it in terms of code and data. Like...

$00:8000 | # bytes | ASM | SNES reset routine

And that would count for "#" bytes of the ROM mmap, not just one ($008000). Everything in SMW has some purpose, unless it's unused or empty, in which case it could still be listed in the ROM map.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
*bump* because I can.

Regarding the comment about the ROM map being impossible to finish:

I've had a proposal for a looooooong time, but Kieran never seemed too interested in it, and that is to split the maps into three:

* RAM map - Same as it is now
* ROM map - Lists useful hex edits, which is what it mostly does now.
* ASM map - Lists routines (disassembled and commented) and blocks of data.

Seeing as I never got my ASM map, I took matters into my own hands and made the Advanced ROM Map on the old SMWiki which was the closest I got to my dream. Something like that, except with less manual work, would be awesome to see. Maybe I should make my own separate online system for that, seeing as it'll probably never get incorporated into SMWC.
I'd love something like that. I'm not very good at navigating All.log, and having something of that sort would make me very happy. #w{=3}
There's lots of unknown stuff around $143E through $1456. I'm pretty sure all of it is related to the various autoscroll commands, but according to the RAM map, it is also used by the credits. It is unknown how much of it has these meanings for all scroll commands.
I could gather the following from inspecting scroll command 8, which scrolls layer 2 back and forth (used in Morton's castle), in all.log:
$143E - Scroll command number, known
$143F - Secondary scroll command (often affects layer 2 while the primary one affects L1, it is unknown how often it has another value than $143E)
$1440 - The starting Y-position of the current scroll sprite, left-shifted twice, with the extra bits added to them.
$1441 - Same as $1440, but used by the secondary scroll command. It is unknown if this ever has another value than $1440.
$1442 - Layer 1 direction?
$1443 - Layer 2 direction?
$1444 - Unknown, likely used by the primary scroll command in other scroll commands
$1445 - Unknown, likely used by the secondary scroll command in other scroll commands
$1446 - Layer 1 X speed, 256ths of a pixel (16 bits)
$1448 - Unknown, used by the primary scroll command (16 bits)
$144A - Layer 2 X speed, 256ths of a pixel (16 bits)
$144C - Unknown, used by the secondary scroll command (16 bits)
$144E - Fraction bits for layer 1 X position, 256ths of a pixel. The high byte is always 00. (16 bits)
$1450 - Unknown, used by the primary scroll command (16 bits)
$1452 - Fraction bits for layer 2 X position, 256ths of a pixel. The high byte is always 00. (16 bits)
$1454 - Unknown, used by the secondary scroll command (16 bits)
$1456 - Current layer being processed by autoscroll sprite (#$00 = layer 1, #$04 = layer 2)
If someone thinks this is useful enough to send to the RAM map, feel free to.
<blm> zsnes users are the flatearthers of emulation
0FA8F seems to be the x speed of some eeries. Not all of them were effected by changing it.
all hail vipes
AddressSNESLengthTypeDescription
0FA8C$01:F88C2 bytesSprite physicsHorizontal speed of Eeries
0FA8E$01:F88E2 bytesMisc.Vertical speed of Eerie (sprite 39)

Code
EerieSpeedX:                      .db $10,$F0

EerieSpeedY:                      .db $18,$E8
It seems that this is already documented in all.log and the ROM map.
Background image by Tzadkiel & Anomalin