range of a 4-bit two's complement BRR datum and offical doc accuracy

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

range of a 4-bit two's complement BRR datum and offical doc accuracy

Post by jeffythedragonslayer »

On page 3-2-2 of the official dev manual, we have:
R is the value obtainaed by shifting the 4-bit data, d, by the range value, r.

R = [d] * 2 ^ (r-15)

([d] is a decimal presentation of d, which is in two's compliment form, -7~ +8)
Huh? In other programming textbooks I notice the range of a two's complement signed integer always has one more negative number than positive numbers. You can think of the most significant bit of a two's complement int as the "negative flag." When the negative flag is set,
you can obtain the normal binary representation of the whole thing's magnitude by inverting all the bits and adding one.

Thus, 0111b (everything except the negative flag set, so it's the max positive value) maps to a 7 because the negative flag is clear, so we don't invert and add. Also, 1000b (minimum value with negative flag set) maps to -8 because it's inversion is 0111b, and adding one to it gives a magnitude of 1000b.

So I think this is a typo. Although people complain that the official docs are hard to understand, I tended to trust that they are accurate.
What has other people's experience been with their accuracy?
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: range of a 4-bit two's complement BRR datum and offical doc accuracy

Post by rainwarrior »

Yeah, just a mistake. Should be -8 to +7.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: range of a 4-bit two's complement BRR datum and offical doc accuracy

Post by creaothceann »

jeffythedragonslayer wrote: Tue Jan 17, 2023 7:03 pm Although people complain that the official docs are hard to understand, I tended to trust that they are accurate.
I tend to trust noted authors of the scene a bit more (Near, anomie, nocash etc.; e.g. Bruce Clark for the CPU) because they had years to write and correct their documentation.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: range of a 4-bit two's complement BRR datum and offical doc accuracy

Post by rainwarrior »

The SNES development book has a very small audience, and is not intended as an eternal reference or textbook. It's meant to be used by people who can resolve errors in the document with hands on experience with the hardware, or direct contact through their working relationship with Nintendo. I don't know how many revisions it got before the leaked version that's widely available, but probably not many, if any. If there are corrections or supplemental information, these could be transmitted directly without the manual having gotten an update.

(I dunno if we should consider it lucky we have the English version, as it probably got the benefit of corrections from deployment of an earlier Japanese one... though it may have also had the detriment of mistranslations.)

So, take everything in it with that grain of salt. It's generally pretty good, and it's great at giving an idea of what Nintendo thought their hardware was supposed to do, but it was a living working document, and that's very important contextual information.


No reference is perfect. Confidence in any of this information is on a sliding scale, but here's my general pecking order:

If you want a reference that's accurate, the best bet is the source code of a widely used emulator because you can trust that it's been tested with a lot of games and a lot of users. However, it's often difficult to read and understand source code directly.

Next after this, I would suggest a well-used wiki with a collaborative community that documents its sources when new information is found. Unfortunately.... we don't have one yet for SNES, IMO. The NESdev Wiki is an example of this. It's been around a very long time, and it's documented and cross referenced with discussion and collaboration on the forums. The SNESdev Wiki may eventually meet this bar, but right now I think it is too new to meet the "well-used" requirement. The superfamicom.org Wiki on the other hand is well used, but has very poor referencing and collaboration. Its edits are anonymous, commentless, with poor documentation and no records of coordination. It has a lot of good information, but the inability to collaborate effectively makes its veracity highly variable.

Third (well, second), we have past documents from single authors like Nocash or Anomie, who clearly put in a lot of work, a lot of revision, a lot of personal testing, and a lot of dicussion with others. These are generally very good (and often seem to be more reliable than the two wikis mentioned above). However, if anything with the wiki is wrong, we can correct it today. If anything on FullSNES is wrong, it may never be corrected.

I'd put the SNES development document just after those, though I do consider it very important reading. It gives a lot of insight into good practices for software development that are often not addressed by emulation and reverse-engineering focused authors. Some errors are expected, for the reasons I gave above, but if you actually apply it to work that you test on the hardware, most of these errors will reveal themselves to you. (Thankfully we have the community resources listed above to compensate for a lack of direct support from Nintendo.)

Finally there's one-off documents, YouTube videos, forums, rumours, etc. There's a lot of information that might be true, but a lot of it needs verification. Some of it is just leads for further investigation.


None of this estimation is a substitute for critical evaluation. The reason I can trust so much of the NESdev Wiki is that so often it cites the forum, where I can see who documented it, and what other people had to say about it. The discussion is part of the testing process. Similar goes for BSNES' source, because I know it's been tested on many many many games by many users. I don't expect perfection from any of these sources, but real evidence of testing does a lot for confidence in the information.
Post Reply