 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,490,281 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-27-24 12:06 AM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 2 guests |
| Main - ROM Hacking - Tiny question about max value in accumulator/variables(SNES) | New thread | New reply |
| Surlent |
| ||
 Red Paragoomba Level: 19 Posts: 9/54 EXP: 31437 Next: 4340 Since: 02-19-07 Last post: 5929 days Last view: 5929 days |
This might not be something related to ROM hacking actually, but I'm interested getting an answer in this question (this also might be a "noob"-question for me as a non ROM hacker actually, for you experts ...).
As for reading different documents about glitches in SNES games, I stumbled across a "maximum amount an accumulator can hold", which is 65535. Well, this number is very popular (usually zero is counted in, which makes 65536, which is an important classic exponentation (1^2, 2^2 and so on ...). This also might explain, why in RPGs enemies don't have more than 65535 HP; actually Zeromus in FF IV is an exception, but his HP gets refilled in battle once - unknown for the player. My question is about things like score in many games (Super Mario World for example), which usually goes into much higher instances. Have higher values than 65535, like the mentioned example of high scores like in any arcade type game "replacements" for going after that magic 655535-border ? Like each numeral of score is calculated individually, so a score of 1.000.000 actually is not really 1.000.000 in variables, but more or less a string of single (or more-digit) numerals - and just presented as a single number on-screen for the player ? It is dumb to describe, I just would like to know if the SNES technically can handle variables or values higher than 65535 (and thus scores bigger than that are "real" score values) or is there a trick to make bigger values usable. Since Zeromus has not about 130000 HP, but gets his life refilled once (mentioned on several sources, don't want to search for a link now), at least this might be an argument for my assumption, 65535 is somehow a border. Also, if you manage to do more damage than that number, it causes an overflow, resets to zero and actually does very low damage (normally truncated to 9999). Thanks in advance. |
| Sukasa |
| ||
 Red Birdo Level: 92 Posts: 86/2112 EXP: 7689702 Next: 67235 Since: 02-19-07 Last post: 4448 days Last view: 3220 days |
Hardware-wise, the Accumulator can only go up to 65535, yes. However, there is a carry flag, and if coded correctly, the 65c816 chip could handle, say, a 128-bit number, though as you might images that's be slow. Basically, for any number over 65535, there is ASM that is involved in the math. |
| Acmlm |
| ||
 Flurry Level: 37 Posts: 146/251 EXP: 315050 Next: 23203 Since: 02-19-07 From: Mirabel, Québec, Canada Last post: 6180 days Last view: 1813 days |
Flurry #&postrank& If there was no real way, most stuff on 8bit consoles would be limited to 255 ...
Add/substract operations on twice the register size are rather simple, they're done in 2 parts: CLC LDA $addr //lower part of the variable ADC $Lvalue //lower part of the value to add STA $addr LDA $addr+1 //higher part ADC $Hvalue //this also adds the carry if any STA $addr+1 This can be extended to any size you want ... some NES games even go over 65535 that way, like EXP in many RPG's 
But some games do store the higher values by digit instead, like the score in Mario games. ____________________ |
| DahrkDaiz |
| ||
 Nipper Plant Sandwich Artist Level: 46 Posts: 16/417 EXP: 674481 Next: 37293 Since: 02-22-07 Last post: 3487 days Last view: 3407 days |
Atleast in Mario Bros. 3, the score is a 24-bit number. I've done 16-bit math with two different 16-bit variables before. It's really not that hard. It's all about the carry flag. |
| Surlent |
| ||
|
Red Paragoomba Level: 19 Posts: 10/54 EXP: 31437 Next: 4340 Since: 02-19-07 Last post: 5929 days Last view: 5929 days |
Thanks for your replies. This reminds me about Locomotive Basic 1.0 (very old language, used in Schneider CPC464 I owned a long time; home computer), where maximum variable values could range only between 32767 and -32768.
It's actually interesting how these technical limits didn't prove any problem at all for the programmers early on ... Otherwise it still is impressive; like in SMRPG, the maximum HP was 255 originally (like they could have tweaked the number to something even like 300 or such, but I don't care and even find these numbers more "nostalgic" ).
These limits also might explain the question, why in certain older jump and runs the hero reaches the bottom screen, once he "overjumps" a certain height (if I'm not wrong) ? Maybe the virtual y axis for positioning and moving sprites begins at a certain (usually way higher value than the actual visible max height in-game) point and reaches zero at the bottom. Think about Metroid for example. If you go into the room with the evelator leading to Norfair, you can jump on that weird enemy statue things; by repeatedly bombing and jumping you end up at the bottom on the screen  |
| MathOnNapkins |
| ||
 Super Koopa Level: 62 Posts: 53/842 EXP: 1935593 Next: 49093 Since: 02-19-07 From: durff Last post: 4489 days Last view: 4012 days |
On stuff like adding and subtracting, the performance hit is neglegible when acting on numbers larger than 16 bits (65536 or whatever). You could add and subtract numbers as large as 128 bit without a significant penalty. It's doing stuff like multiplying and dividing that would be much more time consuming. It's all a matter of properly using the carry flag. ____________________ Zelda Hacking Forum hobbies: delectatio morosa |
| Sukasa |
| ||
|
Red Birdo Level: 92 Posts: 92/2112 EXP: 7689702 Next: 67235 Since: 02-19-07 Last post: 4448 days Last view: 3220 days |
Luckily, for most multiply/divides where one number is 16-bit and the other 8-bit, you can use the math coprocessor. otherwise, yeah, the performance hit could be quite high. |
| Main - ROM Hacking - Tiny question about max value in accumulator/variables(SNES) | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 67, rows: 93/94, time: 0.012 seconds. |