A good exercise for the junior systems engineer, or someone who wants to fundamentally understand computers better than the REPL, is to build their own emulator.
There is likely a wealth of tutorials out there, but if there is not yet a canonical book on how to write an NES, Genesis, SNES, etc. emulator from scratch that can load real ROMs, I think this would really scratch an itch for the aspiring hardcore developer. It is a very illuminating exercise and given the performance of modern computers and the extensive number of graphics libraries for every semi-popular language in existence, I think a universal book could be written that pseudo-codes the concepts of emulation and enables developers of all stripes to build their own emulator.
What I really never understood is how the whole system dealt with the differences between PAL and NTSC. For starters, the Japanese system outputs in PAL, which is 625 horizontal scan lines at ~25 fps. The North American system outputs in NTSC, which is 525 horizontal scan lines at ~29.97 fps.
Does anybody understand how that worked?
As far as the SNES is concerned, PAL consoles simply letterbox the video and run the game 16.6% slower. Occasionally the game speed is modified to account for the decreased framerate. Super Metroid's engine was sped up so that gameplay was faster frame-by-frame and approximately as fast in wall clock time, but this introduced a number of bugs.
It wasn't until framebuffer based consoles like the Playstation where using the extra lines of PAL signal became common. Game speed was still a common issue until the Dreamcast and PS2 where game speed ceased to be an issue and optional 60Hz support was also common.
It's not quite enough to fill the screen vertically on many PAL TVs (and especially not monitors which in general have less or no overscan at all), but even the PlayStation's and Saturn's (and PlayStation 2's!) PAL modes still have this problem, the framebuffer is just not big enough vertically.
Also the pixel aspect ratio is still distorted, because the 2D gfx assets haven't been redrawn. On later consoles, some (but not all) 3D titles do account for this, sometimes even the 2D assets (HUDs, menus, etc.) are drawn with a bit of vertical stretching, especially on PS2 where bilinear filtering is available.
Even on PS2 some games still have wrong timing in the official PAL release. Final Fantasy X comes to mind... music speed is correct, everything else runs slow (picture is vertically squished as well, Square just didn't care about doing proper PAL versions until later in the PS2 era).
This (and earlier and in general just better title availability) is why some people living in PAL countries always preferred to bypass the region locks (or just import NTSC hardware) and import NTSC releases.
I'm not sure if there are any console games by an European developer where the PAL version is actually the original or intended experience and better, but on old home computers (C64, Amiga, etc.) there definitely are.
Oh. That should make uncompensated PAL games easier, right? 17% more time to time e.g. jumps in Mario is alot.
I’m in the UK but I ended up buying a Super Famicom to play SNES games* because I didn’t want to play the crappy slowed-down PAL versions and a good-condition SFC was significantly cheaper than a US SNES. The Japanese/European case design is also way cooler than the US one imo.
Funnily enough the Sega Mega Drive/Genesis power supply is a perfect match for connecting a Super Famicom to a UK power socket.
*I know US SNES carts are physically larger and won’t fit in an SFC without an adaptor, but I was using a flash cart with an SFC-sized shell. I had it connected to a CRT at the time so I wanted real hardware rather than emulation.
And as other have pointed out, Japan and USA both use NTSC.
[1] https://fabiensanglard.net/snes_video/#:~:text=totally%20use...
I don't know if the timings will be EXACTLY* the same as on an actual console from the "other" region but should be pretty close, close enough to not really notice a difference in gameplay and make all the games I know about from the "other" region work correctly, assuming you bypass the lockout chip as well and aren't trying to play a game which detects a disabled lockout chip like the SA-1 games.
Often these 50/60Hz switch mods either don't switch the colour encoding at all (you get PAL60 which actually works on many, even older, European TVs and monitors, or NTSC50) or breaks it completely, but use RGB interconnects and that won't be a problem at all. IIRC a PAL SNES modified this way outputs PAL60, but it might have been just totally broken composite / s-video as well (which will show up as monochrome on any display).
(on Dreamcast, PS2, and later model PS1s hardware from all regions can actually do both colour encodings as well.)
On NES you really need to swap a couple of chips and a crystal to convert a PAL console to NTSC or vice versa, some other older systems as well.
*) I know that at least on the 1st PlayStation, a PAL console switched via software to 60Hz doesn't have exactly the same timings as a real NTSC console, also vice versa, but the difference is so minor that at least I never even noticed, just read about it years later on the Internet, IIRC it was either the shmups.system11.org forum or some Mednafen developer comments on their website where I saw this
(apologies if this is already touched upon on your site, haven't read those pages fully yet...)
Even many of the earlier sets can be made to sync to 60Hz by adjusting vertical hold. Sometimes this control was even available without opening the TV set. Vertical size of the picture may become an issue then, though... (can often be adjusted easily as well but needs opening the set, and then you can't properly watch PAL TV anymore)
If using composite video or s-video (Y/C), then NTSC colour encoding could be a problem until some years later, but RGB inputs (via SCART / Péritel) were also very common on European TVs and that bypasses colour encoding / decoding completely (and also gives the best picture quality in general).
(well looks like I wasn't going to be a SINGLE post anon after all...)
https://news.ycombinator.com/item?id=41207608 (147 points, 8 comments)
https://news.ycombinator.com/item?id=41210537 (18 points, 2 comments)
https://news.ycombinator.com/item?id=41207756 (2 points, 0 comments)
I just checked those submissions, and it turned out they were posted in a single day (August 10th) with an eleven-hour time frame! The first submission was at 05:48 AM, the second at 06:37 AM (within less than an hour from the first), and the third at 16:24 PM, which raises one of the weirdest behaviors of the HN system (at least for me): "How or why on earth some submissions got accepted as 'duplicates' where others did not? ". I encounter this a lot when I try to submit a story and it gets rejected because it was already submitted. Sometimes, even if the original story is a month old or more!!
I second that. Two months ago I tried to submit what I found to be a quite interesting video from 2018 and it was immediately marked as duplicate:
https://news.ycombinator.com/item?id=40798566
Checking past submissions, I saw that the last time it had been submitted was a year ago:
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
But then, as you can see from that page, someone resubmitted the video a month ago and for some reason that one got through.
I also worry that HN is slowly turning into a karma farm like Reddit did. The point of reposting on HN just to build Internet Points escapes me,. At least on Reddit there was a market for accounts with high karma, so I guess I could see the motivation there. But here?
Who knows? Maybe there is a hidden club somewhere where your HN karma will open doors.
