"Working" in a loose sense. The recent(?) change to different software broke a ton of internal links. The wiki is superficially nicer, but content-wise, it's a shadow of its former self.LuigiBlood wrote:Wiki is working now.
- For making cartridges of your Super NES games, see Reproduction.
Actually every single page are still there. The links may not work, but they're searchable. Also, it's a wiki: Edit it if you find broken stuff.qfwfq wrote:"Working" in a loose sense. The recent(?) change to different software broke a ton of internal links. The wiki is superficially nicer, but content-wise, it's a shadow of its former self.LuigiBlood wrote:Wiki is working now.
A lot of images and files are broken or missing, and you can't find them in search. For example, check out this page:LuigiBlood wrote:Actually every single page are still there. The links may not work, but they're searchable. Also, it's a wiki: Edit it if you find broken stuff.qfwfq wrote:"Working" in a loose sense. The recent(?) change to different software broke a ton of internal links. The wiki is superficially nicer, but content-wise, it's a shadow of its former self.LuigiBlood wrote:Wiki is working now.
https://wiki.superfamicom.org/schematic ... nd-pinouts
The images and PDFs near the top aren't discoverable through the site search, nor are they available at their original URLs. For example, this link:
https://wiki.superfamicom.org/snes/file ... _color.pdf
gives you this:
Code: Select all
Cannot GET /snes/files/snes_schematic_color.pdf
I'm not sure how I've "made it personal." I have no idea who runs the site. I'm just reporting a high-impact bug.LuigiBlood wrote:Okay, fine, there are issues, don't make it personal either.
I've let him know. I do think the current backend is better though.
I do apologize if I'm coming off icy, though. At the company I work at, we have a culture of writing "postmortems," in which we analyze and document the root causes of development or operations issues to make sure they don't happen again. These analyses tend to be impersonal and matter-of-fact: here's what broke, here's why, and here's what we can do to fix it in the short term and in the long term. That's the mode I'm in here.
In any event, thank you for letting the site maintainer know about the issues.
Google had issued a "Security Warning" barring most people going to the site, Stating that someone over there didn't upgrade the HTTPS security certificate, marking it as a bad site...
Just to let you know!
The SSL certificate was renewed today, which is why it's working now:KungFuFurby wrote:The problem seems to have been resolved on my end. I got a warning from my browser the day you posted that warning. The warning went away today.
Code: Select all
Validity Not Before: May 17 14:50:42 2018 GMT Not After : Aug 15 14:50:42 2018 GMT
Full verification of the current cert:
Code: Select all
$ echo | openssl s_client -connect wiki.superfamicom.org:443 -servername wiki.superfamicom.org | openssl x509 -noout -text depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = wiki.superfamicom.org verify return:1 DONE Certificate: Data: Version: 3 (0x2) Serial Number: 04:4e:cc:94:12:75:02:ea:cf:ed:98:b1:94:a7:3d:31:dd:d6 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 Validity Not Before: May 17 14:50:42 2018 GMT Not After : Aug 15 14:50:42 2018 GMT Subject: CN=wiki.superfamicom.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c5:f5:53:3a:87:f2:43:e4:ed:57:47:ba:48:5c: ac:fd:d4:22:5d:b4:7e:59:8d:fe:66:77:09:a2:92: a7:02:33:15:aa:a3:5c:22:ef:db:f3:ad:4a:d1:23: c4:d6:cc:12:c2:a5:c6:33:82:35:58:02:37:c1:b6: e8:a2:79:dd:58:15:10:fe:0f:5f:2c:75:32:a2:2d: eb:14:d3:a9:3b:71:ce:5b:44:5b:e4:0b:a2:c3:c1: 26:7b:16:4f:cf:d9:fa:72:53:44:e4:56:30:4f:6e: 9b:84:fa:0c:2c:d5:1a:aa:f8:2c:38:f0:36:a8:56: d0:98:0e:c1:b0:94:35:47:38:b4:c8:19:5b:c9:e7: 8e:40:63:40:23:03:c2:d7:e0:17:23:de:ab:85:ae: 7d:64:ba:ba:06:05:17:2d:e2:1d:50:40:d3:1b:88: ee:aa:15:30:42:b2:67:85:eb:ef:63:1f:99:0f:d7: 32:a7:71:ad:56:6f:80:96:61:26:5c:22:38:9e:84: 04:ef:ce:27:9d:fa:f6:68:f4:e9:59:9f:c3:0d:56: 25:80:50:d0:f6:25:b6:ef:c8:22:8f:b3:1c:ee:8d: 38:fc:71:09:32:d1:78:b5:db:c8:b0:db:b8:91:c7: 27:26:dd:eb:ed:4d:3c:24:c0:d3:c1:e5:a2:c6:1e: 80:b1 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: 30:54:0D:20:B1:CE:E9:07:F6:8D:43:51:B8:E5:FF:F0:60:13:3A:1E X509v3 Authority Key Identifier: keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1 Authority Information Access: OCSP - URI:http://ocsp.int-x3.letsencrypt.org CA Issuers - URI:http://cert.int-x3.letsencrypt.org/ X509v3 Subject Alternative Name: DNS:wiki.superfamicom.org X509v3 Certificate Policies: Policy: 22.214.171.124.2.1 Policy: 126.96.36.199.4.1.449188.8.131.52 CPS: http://cps.letsencrypt.org User Notice: Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/ CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1(0) Log ID : 55:81:D4:C2:16:90:36:01:4A:EA:0B:9B:57:3C:53:F0: C0:E4:38:78:70:25:08:17:2F:A3:AA:1D:07:13:D3:0C Timestamp : May 17 15:50:42.607 2018 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:4E:4E:3A:FE:EB:4F:09:25:06:8B:EE:3A: F4:F8:77:27:73:E0:EB:81:16:94:0E:33:CC:20:AD:1F: 6F:21:2E:58:02:21:00:82:27:94:BE:89:28:C0:92:7A: 86:76:54:74:70:15:53:F3:E3:74:C5:19:4C:4E:D1:5E: 31:AE:33:2C:A2:90:DE Signed Certificate Timestamp: Version : v1(0) Log ID : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7: 6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78 Timestamp : May 17 15:50:42.726 2018 GMT Extensions: none Signature : ecdsa-with-SHA256 30:46:02:21:00:96:A3:44:B3:DF:FE:E5:73:2C:B8:5C: 94:A8:FD:C7:EC:E6:0A:50:36:5D:66:7D:CF:B0:75:E5: EE:64:E1:76:F1:02:21:00:BB:BE:53:6F:2C:D2:46:11: 61:27:C3:B7:9B:99:F6:BA:E9:2F:FB:6B:49:65:E9:D6: 64:02:6A:10:7A:32:9A:E8 Signature Algorithm: sha256WithRSAEncryption 99:89:7e:18:b9:9e:91:ce:18:56:4d:07:4a:05:69:e0:5c:bf: 21:ef:83:90:9b:b9:29:c0:d3:ed:52:cf:4b:67:e7:dc:5f:18: 7c:a1:f5:8c:16:ab:cf:2b:cd:fb:b2:72:d9:a4:07:d6:69:26: 5c:be:2a:94:ad:a5:e4:81:6c:84:09:09:04:91:35:b9:7b:a3: 47:38:ab:7f:8b:26:2f:41:f6:80:cb:f2:71:b4:a4:f1:92:6a: 6d:96:40:1c:7c:6c:38:97:70:34:df:bc:3a:a5:17:f6:92:ce: 7e:9f:b7:c0:a2:b1:11:a3:d5:02:67:ee:33:13:07:ab:a2:2d: ae:d6:90:7a:21:f8:63:cc:fd:93:cf:a0:75:92:6b:8b:8c:81: d6:00:da:13:ff:f9:f1:3d:22:d7:92:0e:e0:90:f0:42:94:b4: 30:ae:23:08:25:bf:53:6b:88:15:3e:e8:51:99:6a:62:58:c2: 47:8f:d7:e9:a8:70:fe:46:8e:46:a4:d2:8e:c7:19:5e:2f:56: 00:84:ab:22:df:c0:f7:16:92:60:d5:88:9e:ce:02:1b:f3:33: 16:b3:8b:4e:cd:b4:cd:e1:d0:27:66:e6:3b:9c:68:45:2e:e5: 87:93:4f:96:91:0b:16:79:6a:e9:36:b1:69:2e:70:ef:b4:bf: 79:b9:09:f8
I rewrote the bottom section too, so that it's less confusing. I hope this https://wiki.superfamicom.org/general-advice persuades people into realizing how powerful the 65816 actually is when you know how to use it.
I should make a section about the "little address self-fulfilling prophecy" where a 512 byte table of self-pointing addresses will automatically shrink down to 256 bytes if you use 8-bit addresses.
Here's a trick that can help:The only instruction that loads the Data Bank register is "PLB" which loads Data Bank "B" from the stack. This makes it tricky to change banks while in 16-bit accumulator mode, and "PEA $xxxx" only works with 16-bit values.
Code: Select all
; Set data bank to $85 pea $8500 plb ; dummy read to get rid of extra byte plb
Not only does the actual certificate have to be renewed, the HTTP server has to be told to reload its configuration (at least, in nginx). This is the issue I ran into specifically. This is fixed by specifying a renew-hook in the cron job's commandline.koitsu wrote:It looks like they're using Let's Encrypt for their certs (maybe they weren't before? Unsure), which means the certificate auto-expires every 90 days. This requires the server administrator set up some automation to renew it automatically at about the 60-75 day mark.