 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,480,322 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-25-24 05:32 AM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 1 guest | 2 bots |
| Main - ROM Hacking - Things that make you think "WHY???" | New thread | New reply |
| Ailure |
| ||
|
Hats Steam Board2 group Level: 121 Posts: 542/3965 EXP: 19777184 Next: 279512 Since: 02-19-07 From: Sweden, Skåne Last post: 3300 days Last view: 2051 days |
Posted by HyperHackerBinary coded decimal is actually common, as I seen it on a quite few NES games now, such as Mario bros. The levels are stored in a single, byte... a binary-coded decimal one. I figure it's easier to output it on the screen codewise when it's binary-coded decimal.  ____________________ AIM: gamefreak1337, MSN: Emil_sim@spray.se, XMPP: ailure@xmpp.kafuka.org
|
| Kernal |
| ||
|
Gone Level: 88 Posts: 1022/1881 EXP: 6461560 Next: 189104 Since: 02-20-07 Last post: 6145 days Last view: 6136 days |
Also, 6502 derivative CPUs had a binary-coded decimal "mode" you could set, so the special BCD arithmetic was automatically handled by the CPU, you'd just have to remember to set the mode properly when doing math on BCD-encoded bytes.
That wouldn't explain Pokémon though as the Game Boys used a Z80, unlike the NES and SNES. |
| Ailure |
| ||
|
Hats Steam Board2 group Level: 121 Posts: 543/3965 EXP: 19777184 Next: 279512 Since: 02-19-07 From: Sweden, Skåne Last post: 3300 days Last view: 2051 days |
And the NES as far I know, didn't support the BCD mode anyway. :/
Or at least, the documentation I used for developing my silly NES testing program said so.  ____________________ AIM: gamefreak1337, MSN: Emil_sim@spray.se, XMPP: ailure@xmpp.kafuka.org
|
| HyperHacker |
| ||
|
... Level: 73 Posts: 97/1220 EXP: 3366455 Next: 119413 Since: 03-25-07 From: no Last post: 6090 days Last view: 6074 days |
The GBZ80 had some BCD instructions too. I just don't get why they mixed it like that.  |
| Xkeeper |
| ||
|
Level: 105 Posts: 1535/2846 EXP: 12027069 Next: 235191 Since: 02-19-07 Last post: 6059 days Last view: 2796 days |
Hello again, thread.
Link's Awakening has some weird shit -- unused "B-", "1F", "2F", "3F", "4F" tiles, "PLAYER", and what looks suspiciously like an open chest. Perhaps the chests on the mapscreen were meant to stay there (but open) instead of vanish when you opened them? Even weirder, as far as I can tell, that half-heart (and probably the empty one) is never used. There are different ones used for the status bar... Although that switch graphic still boggles my mind. Why would it be there? ____________________ I dealt with it. |
| Mattrizzle |
| ||
 Red Cheep-cheep Level: 33 Posts: 30/202 EXP: 226315 Next: 2864 Since: 04-21-07 From: United States Last post: 2419 days Last view: 2380 days |
Another screwed up thing is how in every version of NBA Jam on the SNES, the portraits of players 0x12-0x30(Hakeem Olajuwon-Nick Anderson) are compressed and loaded from WRAM, while all of the other players' portraits are uncompressed and loaded directly from the ROM. This really adds up in NBA Jam TE, where there are even more uncompressed portraits. Iguana should have either compressed all of them, or not even bothered compressing them in the first place.
And while I'm on the subject of these portraits, some of the players that weren't in the original arcade version of NBA Jam look absolutely hideous! 
If you want to know who these mugs are, look at the Of all of the portraits above, Derrick McKey and Clarence Weatherspoon are the only ones that didn't get new portraits in NBA Jam T.E. (Robert Parish wasn't in T.E.). Posted by UnsurpassedDarknessPosted by BMF54123Are you sure it isn’t tile 0x152? UnsurpassedDarkness is right, BMF. It's spawning tile 0x152 in the coin's place. Somehow it's linked to the address which makes tile 0x152 appear behind the block bounce sprite(113B9). Changing it to 0x02 makes it spawn tile 0x25 as it should, but if Mario is standing on a block while the block bounce animation occurs, he'll fall through it. title text is better than alternate text for "hover over secrets". --xkeeper Thanks, Xk. It really shows how much I still need to learn about HTML, even after taking two web design classes in high school  ...____________________ |
| SnifflySquirrel |
| ||
|
Newcomer Level: 3 Posts: 1/1 EXP: 78 Next: 50 Since: 05-03-07 From: Vermont Last post: 6201 days Last view: 6116 days |
A little off-topic, but you can fix that coin glitch fairly easily. At SNES $02:934A, there's a JSR to $91B8. Redirect this JSR to an unused space in ROM bank $02 and place the following code at the new destination:
LDA #$02 JMP $91BA Now coins above bounce sprites will be replaced by tile 25, and bounce sprites will still replace the tile underneath them with tile 152. On-topic: SMW has so many different kinds of sprites, it's not even funny. In addition to the known tables used for "regular" sprites, projectiles, score sprites, and block bounce sprites, there are also separate tables for coin sprites that pop out of coin blocks, the sparkles that appear when coins are collected, "poof" animations, etc. They could have at least stuck all of the "effect" sprites in a single table... I'm surprised the programmers could even keep track of it all. |
| Smallhacker |
| ||
 Panser Swedish weirdo times eleven Level: 42 Posts: 81/339 EXP: 494427 Next: 26935 Since: 02-19-07 From: Stockholm, Sweden Last post: 5183 days Last view: 5183 days |
Sukasa and I have been working on disassembling and documenting SMW for a few days. Some routines are so terrible that they really make me think "WHY???".
Example of one routine: It begins with this: $00/AB09 C008 CPY #$08 ;\Completely pointless code.(Translation: Compare Y to the value 8. Skip past 0 bytes, no matter what.) Later in the routine: $00/AB0F A700 LDA [$00] ;\ Okay, so take [$00], storeMe: Why in the world does it OR the bytes together? Wouldn't that ruin the data? Sukasa: Apparently, it's meant to be ruined
Me: ...Is it some kind of mega-lame encryption, And if so, WHY? ...later... Me: ...this place gives me headaches... Can't we work on some other code? 
Sukasa: Sure, go ahead. anyways, this seems to upload the decompressed GFX while scrambling it afterwards ( ).
Me: Okay... WHAT THE HELL? I'll have nightmares about this routine for a few years.
Sukasa: Ouch. ...and if you're looking for a completely ununderstandable (is that a word?) routine, you might want to try to look at the Mario update routine. Here's an image illustrating the routine: 
It is a miracle that the game actually works. ____________________   |
| MathOnNapkins |
| ||
 Super Koopa Level: 62 Posts: 116/842 EXP: 1935320 Next: 49366 Since: 02-19-07 From: durff Last post: 4487 days Last view: 4010 days |
Zero length branches are totally understand able in that they show they planned to do something then later scrapped it. NOPing would mean that they'd have to notice it is useless first I guess. And with so many different programmers focusing on different stuff I think that's a lot to ask. ____________________ Zelda Hacking Forum hobbies: delectatio morosa |
| HyperHacker |
| ||
|
... Level: 73 Posts: 644/1220 EXP: 3366455 Next: 119413 Since: 03-25-07 From: no Last post: 6090 days Last view: 6074 days |
It could also indicate removed debug code. |
| Main - ROM Hacking - Things that make you think "WHY???" | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 52, rows: 82/82, time: 0.017 seconds. |