| The "unsure ROM/RAM" thread |
|
Forum Index - SMW Hacking - General SMW Hacking Help - SMW Data Repository - The "unsure ROM/RAM" thread |
|
|
|
|
| Posted on 2010-09-24 07:07:02 PM |
Link | Quote |
|
|
$18DF is in the Waiting to be Moderated section imamelia
|
|
| Posted on 2010-09-24 07:17:11 PM |
Link | Quote |
|
|
Yeah, I think one or two of them were. I'll delete them from the list when they actually get accepted.
|
|
| Posted on 2010-09-29 09:53:33 AM |
Link | Quote |
|
|
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.
|
|
| Posted on 2010-09-29 10:02:28 AM |
Link | Quote |
|
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)
|
| Last edited on 2010-09-29 10:02:43 AM by Sind. |
|
| Posted on 2010-09-29 10:10:56 AM |
Link | Quote |
|
Originally posted by SindI 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.
|
|
| Posted on 2010-09-30 04:03:05 PM |
Link | Quote |
|
|
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.
|
|
| Posted on 2010-10-01 10:30:56 AM |
Link | Quote |
|
|
I agree, it'd definitely be useful if you should check out the latest ROM/RAM Addresses approved.
|
|
| Posted on 2010-10-08 06:11:58 PM |
Link | Quote |
|
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.  We need to build that up.
|
|
| Posted on 2010-10-08 08:18:18 PM |
Link | Quote |
|
|
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.
|
|
| Posted on 2010-10-09 06:24:10 AM |
Link | Quote |
|
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.
|
|
| Posted on 2010-10-09 10:21:31 AM |
Link | Quote |
|
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."
|
|
| Posted on 2010-10-09 10:36:04 AM |
Link | Quote |
|
Originally posted by ErsanioYeah. 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.
|
|
| Posted on 2010-10-09 10:56:57 AM |
Link | Quote |
|
|
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
|
|
| Posted on 2010-10-09 11:42:10 AM |
Link | Quote |
|
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.
|
|
| Posted on 2010-11-18 07:45:05 AM |
Link | Quote |
|
*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.
|
|
| Posted on 2010-11-18 07:50:05 PM |
Link | Quote |
|
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. 
|
|
| Posted on 2011-06-10 09:26:45 AM |
Link | Quote |
|
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.
|
| Last edited on 2011-06-13 08:29:32 AM by Alcaro. |
|
|
|
|
|
|
Forum Index - SMW Hacking - General SMW Hacking Help - SMW Data Repository - The "unsure ROM/RAM" thread |
