WEBVTT 00:00:00.000 --> 00:00:03.399 So imagine you go out and buy a brand new laptop 00:00:03.399 --> 00:00:06.280 today. Right. Just a standard laptop. Yeah. You 00:00:06.280 --> 00:00:08.939 bring it home, you unbox it, turn it on, and 00:00:08.939 --> 00:00:10.939 then you realize that because you speak English, 00:00:11.480 --> 00:00:13.919 the computer is, well, it's functionally useless. 00:00:14.460 --> 00:00:16.620 Oh, wow. OK. Right. To actually read your native 00:00:16.620 --> 00:00:18.940 language on the screen, you're forced to go back 00:00:18.940 --> 00:00:22.620 to the store and buy a specific, wildly expensive, 00:00:22.859 --> 00:00:25.059 completely different brand of hardware. I mean, 00:00:25.199 --> 00:00:27.500 that sounds completely absurd to us now. Exactly, 00:00:27.719 --> 00:00:31.359 because today, language is just this invisible 00:00:31.359 --> 00:00:33.659 software toggle, right? You go into your settings, 00:00:33.799 --> 00:00:36.679 you pick French or Arabic or Japanese, and the 00:00:36.679 --> 00:00:39.259 whole interface just instantly transforms. Yeah, 00:00:39.380 --> 00:00:42.299 it's totally frictionless. We just kind of take 00:00:42.299 --> 00:00:44.420 it for granted that any hardware can display 00:00:44.420 --> 00:00:46.840 any language on Earth. But if you step back into 00:00:46.840 --> 00:00:49.600 the world of 1980s personal computing and specifically 00:00:49.600 --> 00:00:52.740 in Japan, that invisible software toggle was, 00:00:52.759 --> 00:00:54.799 I mean, it was practically science fiction. Oh 00:00:54.799 --> 00:00:57.859 yeah, it really was. To read your own language, 00:00:58.219 --> 00:01:00.700 you were held hostage by one company's physical 00:01:00.700 --> 00:01:04.000 hardware monopoly. So today, we're doing a deep 00:01:04.000 --> 00:01:08.079 dive into how a secret spare time software project 00:01:08.079 --> 00:01:13.349 inside IBM Japan called DOSV changed all of that. 00:01:13.469 --> 00:01:15.750 Such a wild story. It really is. We're looking 00:01:15.750 --> 00:01:18.769 at how this project not only solved a massive 00:01:18.769 --> 00:01:22.409 linguistic engineering problem, but like accidentally 00:01:22.409 --> 00:01:25.430 detonated a national computing monopoly and forced 00:01:25.430 --> 00:01:27.930 the entire Japanese market to open up to the 00:01:27.930 --> 00:01:30.250 world. It's honestly one of the most fascinating 00:01:30.250 --> 00:01:33.790 examples in tech history of software just brute 00:01:33.790 --> 00:01:36.180 forcing a hardware problem. Okay, let's unpack 00:01:36.180 --> 00:01:38.219 this because before we can understand a solution 00:01:38.219 --> 00:01:40.799 We have to understand why displaying Japanese 00:01:40.799 --> 00:01:42.939 on a computer was such a total nightmare in the 00:01:42.939 --> 00:01:44.939 1980s, right? So we have to look at the physics 00:01:44.939 --> 00:01:47.000 of early computers They were built by English 00:01:47.000 --> 00:01:49.280 speakers for English speaker, which means the 00:01:49.280 --> 00:01:52.200 architecture was Pretty limited very limited 00:01:52.200 --> 00:01:54.540 I mean the English alphabet plus numbers and 00:01:54.540 --> 00:01:57.700 some basic punctuation totals about 128 characters 00:01:57.700 --> 00:02:01.480 and in computing terms That is incredibly lightweight. 00:02:02.060 --> 00:02:04.180 You can represent any of those characters with 00:02:04.180 --> 00:02:07.040 just seven bits of data. So that easily fits 00:02:07.040 --> 00:02:09.300 into a single byte. Just a standard single byte 00:02:09.300 --> 00:02:12.060 character. Exactly. And beyond just the storage 00:02:12.060 --> 00:02:15.500 space, think about the visual rendering. Drawing 00:02:15.500 --> 00:02:19.360 a capital A or lowercase e on a screen requires 00:02:19.360 --> 00:02:22.719 this really simple tiny grid of pixels. Just 00:02:22.719 --> 00:02:25.659 a few dots, really. Yeah. And the rudimentary 00:02:25.659 --> 00:02:28.199 processors of the late 70s and early 80s, they 00:02:28.199 --> 00:02:30.340 could handle that minimal graphic processing 00:02:30.340 --> 00:02:32.400 without breaking a sweat. But then you have the 00:02:32.400 --> 00:02:35.020 Japanese language, which relies on kanji. Right. 00:02:35.300 --> 00:02:37.340 And we aren't talking about 100 characters here. 00:02:37.419 --> 00:02:40.639 We're talking about thousands of incredibly complex, 00:02:40.900 --> 00:02:42.599 intricate glyphs. So single byte goes right out 00:02:42.599 --> 00:02:45.060 the window. Instantly. Yeah. Just to assign a 00:02:45.060 --> 00:02:48.699 unique digital ID. to every single kanji character, 00:02:49.139 --> 00:02:51.379 you immediately have to move to double byte characters. 00:02:51.659 --> 00:02:53.520 Which doubles the memory requirement right off 00:02:53.520 --> 00:02:55.460 the bat. It does. But honestly, that was just 00:02:55.460 --> 00:02:57.759 the identification part. The real bottleneck 00:02:57.759 --> 00:02:59.879 was the graphics. Drawing the actual characters. 00:03:00.379 --> 00:03:03.919 Exactly. To make a complex kanji character legible 00:03:03.919 --> 00:03:07.000 on a monitor, you can't use a simple pixel grid. 00:03:07.599 --> 00:03:12.500 You need a dense 16 by 16, or even a 24 by 24 00:03:12.500 --> 00:03:15.560 pixel matrix. Oh wow, so it's a huge jump in 00:03:15.560 --> 00:03:18.560 visual data. Massive. If an early 80s computer 00:03:18.560 --> 00:03:21.120 tried to calculate and draw those thousands of 00:03:21.120 --> 00:03:24.000 dense pixel grids on the fly just using pure 00:03:24.000 --> 00:03:26.379 software, the processor would practically melt 00:03:26.379 --> 00:03:28.300 down. It was just too much. So they couldn't 00:03:28.300 --> 00:03:30.240 use software. They had to create a physical workaround, 00:03:30.240 --> 00:03:32.219 right? Yeah, since the processor couldn't draw 00:03:32.219 --> 00:03:35.020 the text fast enough, they baked the characters 00:03:35.020 --> 00:03:37.580 physically into the motherboard itself. Literally 00:03:37.580 --> 00:03:40.539 hardware chips. Yep. They used specialized ROM 00:03:40.539 --> 00:03:43.139 chips, read -only memory. They were preloaded 00:03:43.139 --> 00:03:46.000 with a drawn Kanji bitmaps. So when you typed, 00:03:46.360 --> 00:03:48.340 the computer wasn't computing a shape at all? 00:03:48.479 --> 00:03:50.280 No, not at all. It was essentially just rubber 00:03:50.280 --> 00:03:52.719 stamping a physical image from that chip directly 00:03:52.719 --> 00:03:55.469 onto the screen. And I guess whoever controls 00:03:55.469 --> 00:03:57.710 that specialized physical hardware controls the 00:03:57.710 --> 00:04:00.270 market. That's exactly what happened. Because 00:04:00.270 --> 00:04:02.849 of this requirement, a Japanese company named 00:04:02.849 --> 00:04:06.539 NEC completely cornered the landscape with their 00:04:06.539 --> 00:04:09.639 proprietary PC -98 architecture. The PC -98. 00:04:09.719 --> 00:04:11.560 That was the behemoth, right? Oh, absolutely. 00:04:11.759 --> 00:04:14.120 It had the Kanji ROM chips built right in, and 00:04:14.120 --> 00:04:16.199 it dominated. I mean, if you wanted to run a 00:04:16.199 --> 00:04:18.420 business or write a document in Japan, you bought 00:04:18.420 --> 00:04:22.339 a PC -98. It was a perfectly sealed, highly profitable 00:04:22.339 --> 00:04:25.810 walled garden. 100%. And meanwhile, you have 00:04:25.810 --> 00:04:29.089 IBM, right? This company dominating the entire 00:04:29.089 --> 00:04:32.509 rest of the globe with the standard IBM PC. Yeah, 00:04:32.649 --> 00:04:34.329 everywhere else, they're the kings. But they're 00:04:34.329 --> 00:04:36.310 staring at the third largest economy in the world 00:04:36.310 --> 00:04:38.930 and realizing they are essentially locked out. 00:04:39.069 --> 00:04:41.629 And their attempts to break in were just, I mean, 00:04:41.689 --> 00:04:43.990 it was a master class in corporate self -sabotage. 00:04:44.170 --> 00:04:45.889 They certainly did not make it easy on themselves. 00:04:45.990 --> 00:04:49.050 Not at all. First, they released the IBM 5550. 00:04:49.370 --> 00:04:52.269 And technically, It was a beast, right? Oh yeah. 00:04:52.610 --> 00:04:54.709 It had the Kanji ships, it read high quality 00:04:54.709 --> 00:04:57.709 fonts, and it displayed them at a massive resolution 00:04:57.709 --> 00:05:01.819 of 1024 by 768. But the price, the price was 00:05:01.819 --> 00:05:04.339 so astronomical that only massive enterprise 00:05:04.339 --> 00:05:06.959 clients who already owned IBM mainframes could 00:05:06.959 --> 00:05:09.060 afford it. Yeah, regular consumers couldn't even 00:05:09.060 --> 00:05:13.100 look at a 5550. So IBM panics and they try to 00:05:13.100 --> 00:05:15.240 build a consumer friendly machine to compete 00:05:15.240 --> 00:05:18.899 with NEC. They create the IBM JX. And this is 00:05:18.899 --> 00:05:21.040 where the strategy just completely unraveled. 00:05:21.040 --> 00:05:24.279 It's unbelievable. IBM deliberately crippled 00:05:24.279 --> 00:05:28.220 the JX. They took the Intel 8086 processor, which 00:05:28.220 --> 00:05:31.430 was the standard of the day. with a 16 -bit data 00:05:31.430 --> 00:05:34.629 bus, and they swapped it out for the older Intel 00:05:34.629 --> 00:05:37.810 8088. Which is a really crucial technical downgrade. 00:05:38.129 --> 00:05:40.350 Explain why that matters so much. Well, the 8088 00:05:40.350 --> 00:05:43.529 still processed data internally at 16 bits, but 00:05:43.529 --> 00:05:46.069 its external data bus, the pathway it uses to 00:05:46.069 --> 00:05:47.870 communicate with the rest of the computer, was 00:05:47.870 --> 00:05:49.829 only eight bits wide. I read this great analogy 00:05:49.829 --> 00:05:51.810 in the source. It's like dropping a massive V8 00:05:51.810 --> 00:05:54.029 engine into a sports car, but then forcing all 00:05:54.029 --> 00:05:56.170 the exhaust through a cocktail straw. That is 00:05:56.170 --> 00:05:58.370 exactly what it was like. It choked the entire 00:05:58.370 --> 00:06:01.709 system. And IBM did this intentionally. They 00:06:01.709 --> 00:06:03.850 deliberately neutered their consumer machine 00:06:03.850 --> 00:06:06.410 purely so it wouldn't be fast enough to compete 00:06:06.410 --> 00:06:10.490 with their wildly expensive 5550 enterprise machine. 00:06:10.550 --> 00:06:12.430 Yeah, they were terrified of cannibalizing their 00:06:12.430 --> 00:06:14.589 own high end sales. It's just wild. They protected 00:06:14.589 --> 00:06:17.170 their margins, but they destroyed their reputation. 00:06:17.410 --> 00:06:20.889 Exactly. The JX was sluggish. Consumers hated 00:06:20.889 --> 00:06:23.750 it. And software developers practically boycotted 00:06:23.750 --> 00:06:26.689 it because IBM was being so uncooperative with 00:06:26.689 --> 00:06:29.579 the architecture. So by trying to protect a niche, 00:06:29.579 --> 00:06:33.379 high -end product, IBM basically guaranteed that 00:06:33.379 --> 00:06:36.939 NEC's PC -98 kept its iron grip on the mainstream 00:06:36.939 --> 00:06:40.100 market. They handed the market to NEC on a silver 00:06:40.100 --> 00:06:43.000 platter. So hardware isn't working. The corporate 00:06:43.000 --> 00:06:45.639 strategy is a total mess. The only way forward 00:06:45.639 --> 00:06:47.920 is to rethink the basic physics of the problem, 00:06:47.959 --> 00:06:50.420 which brings us to 1987. And to a developer at 00:06:50.420 --> 00:06:52.819 the IBM Yamato Development Laboratory named Masai 00:06:52.819 --> 00:06:55.000 Kiko Hattori. Right. And Hattori is the perfect 00:06:55.000 --> 00:06:56.879 person for this because he actually worked on 00:06:56.879 --> 00:06:59.699 the doomed JX project. Yeah, he spent years in 00:06:59.699 --> 00:07:02.540 the trenches dealing with a nightmare of trying 00:07:02.540 --> 00:07:05.759 to localize Western hardware for Japanese users 00:07:05.759 --> 00:07:08.620 and in his spare time at the lab he starts looking 00:07:08.620 --> 00:07:11.319 at the horizon of global computing. And he realizes 00:07:11.319 --> 00:07:13.439 two massive shifts are happening at the same 00:07:13.439 --> 00:07:15.800 time. Right. What's fascinating here is how he 00:07:15.800 --> 00:07:18.759 connected the dots. First, the video graphics 00:07:18.759 --> 00:07:21.459 array, the VGA card, had just been introduced, 00:07:21.800 --> 00:07:26.000 which made 640 by 48080 resolution a global standard. 00:07:26.240 --> 00:07:29.079 OK, so better graphics? Yes. And second, the 00:07:29.079 --> 00:07:32.100 new Intel 386 processors were hitting the market, 00:07:32.500 --> 00:07:35.579 bringing a true 32 -bit architecture. So a lot 00:07:35.579 --> 00:07:37.439 more speed. And what does that mean for Japanese 00:07:37.439 --> 00:07:40.470 text? Well, Hattori hypothesizes that with a 00:07:40.470 --> 00:07:43.509 VGA card's visual capabilities plus the sheer 00:07:43.509 --> 00:07:46.990 raw calculating speed of the 386 processor, a 00:07:46.990 --> 00:07:49.310 computer finally has enough brute force to just 00:07:49.310 --> 00:07:51.910 bypass the physical ROM chips entirely. Wait, 00:07:51.930 --> 00:07:54.110 so you could just draw the kanji fonts via software? 00:07:54.370 --> 00:07:56.290 Exactly. Loading them straight from the hard 00:07:56.290 --> 00:07:58.269 disk into memory, drawing them on the fly. Which 00:07:58.269 --> 00:08:00.829 means you don't need proprietary Japanese hardware 00:08:00.829 --> 00:08:03.529 anymore. No ROM chips needed. You could just 00:08:03.529 --> 00:08:07.379 use the exact same... cheap globally standard 00:08:07.379 --> 00:08:11.420 IBM PC clones that someone in New York or London 00:08:11.420 --> 00:08:14.160 was using and just force it to speak Japanese. 00:08:14.379 --> 00:08:16.879 That was the theory anyway. But theory and execution 00:08:16.879 --> 00:08:19.180 are very different. Right. Because drawing double 00:08:19.180 --> 00:08:22.199 -byte text entirely through software on a 1980s 00:08:22.199 --> 00:08:25.800 processor was agonizingly slow. Agonizing. The 00:08:25.800 --> 00:08:28.740 lag between hitting a key and the kanji character 00:08:28.740 --> 00:08:32.120 actually appearing on screen was totally unacceptable 00:08:32.120 --> 00:08:34.870 for a typist. I love this detail from the source. 00:08:35.289 --> 00:08:37.470 Hattori actually kept a stopwatch on his desk 00:08:37.470 --> 00:08:40.149 during the entire development phase. Just constantly 00:08:40.149 --> 00:08:42.730 timing the delay. Yeah, the team was obsessively 00:08:42.730 --> 00:08:45.190 timing the rendering process, trying to shave 00:08:45.190 --> 00:08:47.789 milliseconds off the text drawing software so 00:08:47.789 --> 00:08:50.149 it would feel natural to a human typing at full 00:08:50.149 --> 00:08:52.110 speed. They had to make it imperceptible. But 00:08:52.110 --> 00:08:54.190 hold on, I have a massive problem with this timeline. 00:08:54.429 --> 00:08:57.429 Oh, let's hear it. So if we're in 1987, right, 00:08:57.429 --> 00:09:01.269 VGA cards and 386 processors are brand new, bleeding 00:09:01.269 --> 00:09:03.220 edge tech. Oh, yeah. they were top of the line. 00:09:03.679 --> 00:09:06.120 Which means they were prohibitively expensive. 00:09:06.440 --> 00:09:10.179 So wasn't Hattori just building another IBM 5550, 00:09:10.500 --> 00:09:12.659 like another machine that was technically brilliant, 00:09:12.940 --> 00:09:15.899 but that no average consumer in Japan could actually 00:09:15.899 --> 00:09:19.100 afford? You know, that is exactly the trap IBM 00:09:19.100 --> 00:09:21.059 management thought he was falling into. They 00:09:21.059 --> 00:09:23.360 looked at the cost of those components and thought 00:09:23.360 --> 00:09:25.539 the project was financially useless. Because 00:09:25.539 --> 00:09:27.620 no one would buy it. But Hattori was banking 00:09:27.620 --> 00:09:29.980 on the sheer gravitational pull of the global 00:09:29.980 --> 00:09:33.370 market. He wasn't building software for 1987, 00:09:33.389 --> 00:09:36.190 he was skating to where the puck was going. Ah, 00:09:36.309 --> 00:09:38.730 okay, building for the early 90s. Exactly. He 00:09:38.730 --> 00:09:40.789 knew that because the entire planet was adopting 00:09:40.789 --> 00:09:44.909 VGA and the 386, economies of scale would force 00:09:44.909 --> 00:09:47.129 the prices of those components to just plummet. 00:09:47.210 --> 00:09:49.710 So it's like designing the elevator systems for 00:09:49.710 --> 00:09:52.450 a skyscraper before the upper floors have even 00:09:52.450 --> 00:09:54.610 been constructed. That's a great way to put it. 00:09:54.649 --> 00:09:56.429 He knew the global hardware would eventually 00:09:56.429 --> 00:09:58.610 catch up to his software. And that software became 00:09:58.610 --> 00:10:02.000 known as DOSV. Right. Now, just a quick clarification 00:10:02.000 --> 00:10:04.759 on the name for you listening. DOSV stands for 00:10:04.759 --> 00:10:08.139 Disk Operating System slash VGA. The V is for 00:10:08.139 --> 00:10:11.330 VGA, not the Roman numeral five. Yeah, even though 00:10:11.330 --> 00:10:13.649 it coincidentally launched around the same time 00:10:13.649 --> 00:10:16.909 as MS -DOS version 5, the V is strictly for the 00:10:16.909 --> 00:10:19.970 graphics. Good to know. So Hattori and his team 00:10:19.970 --> 00:10:22.590 have a working prototype. They proved software 00:10:22.590 --> 00:10:24.690 can beat hardware. But the biggest threat to 00:10:24.690 --> 00:10:27.590 this project wasn't NEC, was it? No, not at all. 00:10:27.669 --> 00:10:30.330 It was their own colleagues at IBM. Because DSV 00:10:30.330 --> 00:10:33.600 worked Almost too well. Way too well. It was 00:10:33.600 --> 00:10:36.679 initially designed just to run on IBM's own localized 00:10:36.679 --> 00:10:39.340 machines in Japan, but because the underlying 00:10:39.340 --> 00:10:42.019 code was built to interface with standard VGA 00:10:42.019 --> 00:10:45.740 hardware, Early users and testers quietly realized 00:10:45.740 --> 00:10:48.700 something really explosive. And this is the part 00:10:48.700 --> 00:10:51.240 that terrified IBM. Right. You could take a floppy 00:10:51.240 --> 00:10:53.639 disk with Diaz V, stick it into a completely 00:10:53.639 --> 00:10:56.740 generic, cheap PC clone made by an American company 00:10:56.740 --> 00:10:59.639 like Gateway, for example, and it would run flawless 00:10:59.639 --> 00:11:02.299 Japanese. Which means IBM loses its hardware 00:11:02.299 --> 00:11:04.360 monopoly. Hattori and his team actually had to 00:11:04.360 --> 00:11:06.019 hide this fact from the rest of the company. 00:11:06.480 --> 00:11:09.179 When word leaked out, 80 % of the staff at the 00:11:09.179 --> 00:11:12.139 Yamato office opposed the DoSV project. 80%. 00:11:12.320 --> 00:11:15.879 They were furious. Because if DoSV allowed cheap 00:11:15.879 --> 00:11:18.940 global clones to enter the Japanese market, no 00:11:18.940 --> 00:11:22.019 one would ever buy IBM's expensive proprietary 00:11:22.019 --> 00:11:24.139 enterprise machines again. It is the ultimate 00:11:24.139 --> 00:11:26.799 innovator's dilemma. The established divisions 00:11:26.799 --> 00:11:29.460 would rather protect a shrinking slice of a proprietary 00:11:29.460 --> 00:11:33.000 pie than risk their margins to open up the entire 00:11:33.000 --> 00:11:36.340 market. But Hattori's bosses, the Chomu Maruyama 00:11:36.340 --> 00:11:39.440 and Nobumi, they saw the bigger picture. Yeah, 00:11:39.440 --> 00:11:42.200 they realized Japan was isolating itself. They 00:11:42.200 --> 00:11:45.080 knew IBM had to cannibalize its own hardware 00:11:45.080 --> 00:11:48.340 advantage to establish a new open Japanese standard 00:11:48.340 --> 00:11:50.960 based on the global architecture. And that realization 00:11:50.960 --> 00:11:53.519 led to an unbelievable corporate showdown in 00:11:53.519 --> 00:11:56.460 December 1990. Maruyama takes his pitch, which 00:11:56.460 --> 00:11:59.360 was titled, The Low -End PC Strategy in Japan, 00:11:59.980 --> 00:12:02.740 straight to IBM's Management Committee. Now standard 00:12:02.740 --> 00:12:04.860 operating procedure at this executive committee 00:12:04.860 --> 00:12:07.620 is incredibly strict. You get exactly 15 minutes. 00:12:07.700 --> 00:12:09.460 Right. You make your pitch, they say yes or no, 00:12:09.480 --> 00:12:12.710 and you leave. But Maruyama knew 15 minutes wasn't 00:12:12.710 --> 00:12:15.149 nearly enough to convince a hardware company 00:12:15.149 --> 00:12:18.090 to essentially just give away its hardware advantage. 00:12:18.309 --> 00:12:21.250 So he just didn't leave. He didn't. He dug in 00:12:21.250 --> 00:12:24.470 and fought for his life for an entire hour, debating 00:12:24.470 --> 00:12:27.690 the executives until IBM CEO John Akers finally 00:12:27.690 --> 00:12:30.570 relented and approved the strategy. Wow. An hour 00:12:30.570 --> 00:12:33.149 long standoff. So they get the green light. But 00:12:33.149 --> 00:12:35.789 getting corporate approval is just. politics. 00:12:35.789 --> 00:12:38.409 True. The actual physics of forcing an English 00:12:38.409 --> 00:12:41.230 -first architecture to render thousands of complex 00:12:41.230 --> 00:12:44.029 kanji without crashing the system. That's where 00:12:44.029 --> 00:12:46.389 the real trick lies. How did they actually buffer 00:12:46.389 --> 00:12:49.629 all that data? Well, they built a truly ingenious 00:12:49.629 --> 00:12:52.769 software architecture that relied on three specific 00:12:52.769 --> 00:12:55.850 drivers. These drivers acted as translators between 00:12:55.850 --> 00:12:57.970 the operating system and the hardware. OK, what 00:12:57.970 --> 00:13:00.409 was the first one? The first was called UF -ONT 00:13:00.409 --> 00:13:04.169 .SYS. The font driver. Exactly. Instead of pulling 00:13:04.169 --> 00:13:07.450 from a physical ROM chip, F -O -N -T .S -Y -S 00:13:07.450 --> 00:13:09.889 grabbed the massive file of Japanese glyphs from 00:13:09.889 --> 00:13:12.350 the hard drive and loaded the entire set directly 00:13:12.350 --> 00:13:14.429 into the computer's extended memory. So the raw 00:13:14.429 --> 00:13:16.269 visual data was just always sitting there, ready 00:13:16.269 --> 00:13:19.009 to be accessed instantly. Yep. But getting it 00:13:19.009 --> 00:13:21.289 from memory to the screen is the dangerous part. 00:13:21.809 --> 00:13:25.409 Which brings us to DSP .S -Y -S, the display 00:13:25.409 --> 00:13:27.750 driver. And this is the sleight of hand that 00:13:27.750 --> 00:13:31.230 really made DOS V work, right? It really is. 00:13:31.610 --> 00:13:33.570 Standard DOS expects to handle simple single 00:13:33.570 --> 00:13:37.409 byte text. If you try to force raw, complex graphical 00:13:37.409 --> 00:13:40.090 bitmaps directly into the video memory, the system 00:13:40.090 --> 00:13:44.230 panics. It just crashes. Right. So DSP .SYS creates 00:13:44.230 --> 00:13:47.149 a tiny 20 kilobyte chunk of memory and calls 00:13:47.149 --> 00:13:50.149 it a simulated video buffer. So it's essentially 00:13:50.149 --> 00:13:53.230 a safe staging area. Exactly. Whenever a program 00:13:53.230 --> 00:13:55.610 wanted to write Japanese text, it dumped the 00:13:55.610 --> 00:13:57.450 character codes into this simulated sandbox. 00:13:58.230 --> 00:13:59.929 The driver would fetch the heavy bitmaps from 00:13:59.929 --> 00:14:02.740 the font memory. paint the complex Japanese characters 00:14:02.740 --> 00:14:06.019 inside this safe 20 kilobyte buffer, and then, 00:14:06.299 --> 00:14:08.600 only when it was perfectly rendered, it would 00:14:08.600 --> 00:14:10.940 blitz the finished image over to the actual video 00:14:10.940 --> 00:14:13.039 memory to be displayed. So it's tricking the 00:14:13.039 --> 00:14:14.940 hardware. The computer thinks it's just handling 00:14:14.940 --> 00:14:17.500 routine data transfers, completely unaware it's 00:14:17.500 --> 00:14:19.799 rendering complex foreign languages. It's a brilliant 00:14:19.799 --> 00:14:22.080 workaround. Yeah. And the final piece was IAS 00:14:22.080 --> 00:14:24.659 .SYS, the input assist subsystem. What did that 00:14:24.659 --> 00:14:27.289 do? It sat at the front end, it allows you to 00:14:27.289 --> 00:14:29.950 type phonetically on a standard keyboard, and 00:14:29.950 --> 00:14:32.549 it would dynamically convert those keystrokes 00:14:32.549 --> 00:14:35.190 into the correct kanji characters on the screen. 00:14:35.590 --> 00:14:37.590 But, you know, whenever you use software to trick 00:14:37.590 --> 00:14:40.750 hardware, you are going to expose flaws in the 00:14:40.750 --> 00:14:43.730 physical manufacturing. Oh, absolutely. And DoSV 00:14:43.730 --> 00:14:47.049 exposed a massive one regarding how cheap hardware 00:14:47.049 --> 00:14:50.320 handled scrolling. Yes. This is fascinating. 00:14:51.000 --> 00:14:53.960 Early versions of DoSV caused catastrophic failures 00:14:53.960 --> 00:14:57.799 on certain generic PC clones, specifically those 00:14:57.799 --> 00:15:00.679 using a very popular cheap graphics controller 00:15:00.679 --> 00:15:04.100 made by Sing Labs. What kind of failure? Well, 00:15:04.100 --> 00:15:05.960 if you tried to scroll down a page of text, the 00:15:05.960 --> 00:15:08.460 screen would violently tear, turning the Japanese 00:15:08.460 --> 00:15:10.600 characters into completely unreadable garbage. 00:15:10.740 --> 00:15:13.120 Oh, gross. Why did that happen? To understand 00:15:13.120 --> 00:15:14.980 why, you have to look at how different languages 00:15:14.980 --> 00:15:17.879 move on a screen. When Western software scrolls 00:15:17.879 --> 00:15:20.570 English text, It's just shifting tiny lightweight 00:15:20.570 --> 00:15:22.649 text strings around in the memory. It's incredibly 00:15:22.649 --> 00:15:24.870 fast. Right, because it's single byte. Exactly. 00:15:25.129 --> 00:15:28.389 Yeah. But scrolling massive, dense, kanji graphics 00:15:28.389 --> 00:15:30.809 requires moving a tremendous amount of data. 00:15:31.529 --> 00:15:34.009 If the software tries to manually move all those 00:15:34.009 --> 00:15:36.070 heavy tixels every time you hit the down arrow, 00:15:36.490 --> 00:15:38.509 the screen refreshes while the memory is only 00:15:38.509 --> 00:15:41.070 half updated. Which causes that terrible visual 00:15:41.070 --> 00:15:43.549 tear. Right. So how do you avoid the tear? You 00:15:43.549 --> 00:15:47.090 use a hardware trick called CRTC address wraparound. 00:15:47.309 --> 00:15:50.149 CRTC stands for Cathode Ray Tube Controller. 00:15:50.350 --> 00:15:52.909 Okay. Instead of forcing the software to physically 00:15:52.909 --> 00:15:56.470 move millions of pixels in memory, the CRTC wraparound 00:15:56.470 --> 00:15:58.789 simply changes the hardware pointer that tells 00:15:58.789 --> 00:16:01.169 the monitor where the top of the screen is. Oh, 00:16:01.169 --> 00:16:03.250 I see. It's like having a giant physical painting 00:16:03.250 --> 00:16:05.990 and instead of repainting the entire canvas every 00:16:05.990 --> 00:16:07.590 time you want to look at a lower section, you 00:16:07.590 --> 00:16:09.850 just like physically pan the camera down. That 00:16:09.850 --> 00:16:12.710 is a perfect analogy. Hardware scrolling is seamless. 00:16:13.470 --> 00:16:15.919 But here's the catch. Western software practically 00:16:15.919 --> 00:16:18.220 never needed to hardware scroll heavy graphics. 00:16:18.720 --> 00:16:21.320 Oh, no. So what did the manufacturers do? Well, 00:16:21.500 --> 00:16:24.639 the manufacturers of these cheap generic VGA 00:16:24.639 --> 00:16:27.679 clones like Sang Labs, they just cut corners. 00:16:28.009 --> 00:16:30.909 They didn't wire the CRTC wrap around correctly 00:16:30.909 --> 00:16:33.029 because nobody in America or Europe was using 00:16:33.029 --> 00:16:35.509 it. They bolted the camera to the floor because 00:16:35.509 --> 00:16:37.809 they assumed you'd never need to pan it. Exactly. 00:16:37.990 --> 00:16:40.649 It wasn't until DoSV came along and stressed 00:16:40.649 --> 00:16:43.750 the hardware in this highly specific localized 00:16:43.750 --> 00:16:46.570 way that the manufacturing flaw was exposed. 00:16:46.809 --> 00:16:49.049 Wow. And IBM actually had to write a patch for 00:16:49.049 --> 00:16:51.590 this, right? In a later version, they added a 00:16:51.590 --> 00:16:54.389 special command line, switch slash HS equals 00:16:54.389 --> 00:16:57.830 LC, just to bypass the broken hardware in those 00:16:57.830 --> 00:17:00.549 specific graphics cards. It was incredibly messy 00:17:00.549 --> 00:17:03.070 trying to force global hardware to adapt locally. 00:17:03.210 --> 00:17:05.690 And clunky. I mean, earlier versions of localized 00:17:05.690 --> 00:17:07.950 DOS were heavily marketed as being bilingual, 00:17:08.410 --> 00:17:10.509 boasting an English mode and a Japanese mode. 00:17:10.710 --> 00:17:12.470 Yeah, but to switch between them? You literally 00:17:12.470 --> 00:17:14.289 had to reboot the entire computer. You couldn't 00:17:14.289 --> 00:17:17.049 just toggle it. Not very user friendly. No. But 00:17:17.049 --> 00:17:19.430 despite the glitches, the screen tearing, and 00:17:19.430 --> 00:17:22.250 the weird reboots, Mariamma's promise to the 00:17:22.250 --> 00:17:26.160 executives held true. DOSV worked. It did. And 00:17:26.160 --> 00:17:28.720 it completely shattered the Japanese computing 00:17:28.720 --> 00:17:30.900 landscape. The barrier to entry overnight went 00:17:30.900 --> 00:17:33.619 from build a billion dollar proprietary factory 00:17:33.619 --> 00:17:37.200 in Japan to install this software on a generic 00:17:37.200 --> 00:17:39.400 machine. And IBM didn't hoard this advantage 00:17:39.400 --> 00:17:42.279 either. They actively open sourced the revolution. 00:17:42.640 --> 00:17:45.200 Right. Microsoft Japan immediately saw the potential. 00:17:45.380 --> 00:17:48.559 Their executive, Susumu Furukawa, met with IBM 00:17:48.559 --> 00:17:51.299 and acquired the source code for DOSV. And then 00:17:51.299 --> 00:17:55.920 in December 1990, IBM founds the OA DG. the PC 00:17:55.920 --> 00:17:58.220 Open Architecture Developers Group specifically 00:17:58.220 --> 00:18:01.380 to promote this new global standard across Japan. 00:18:01.660 --> 00:18:04.440 And the invasion was staggering. Between 1992 00:18:04.440 --> 00:18:07.980 and 1994, generic PC clones just flooded the 00:18:07.980 --> 00:18:10.359 market. Global heavyweights like Compaq and Dell, 00:18:10.420 --> 00:18:12.660 who'd been locked up for a decade, suddenly arrived 00:18:12.660 --> 00:18:15.240 in force. The gravitational pull was so intense 00:18:15.240 --> 00:18:17.519 that even the massive domestic Japanese giants 00:18:17.519 --> 00:18:20.160 gave up. I mean, Fujitsu had spent years pushing 00:18:20.160 --> 00:18:22.299 their own proprietary architecture called FM 00:18:22.299 --> 00:18:24.599 Towns. Right. They completely abandoned it and... 00:18:24.400 --> 00:18:26.680 pivoted to making their own DSV generic clones. 00:18:27.180 --> 00:18:28.940 People across Japan just started calling these 00:18:28.940 --> 00:18:33.160 generic machines DOSV PESECOM. DOSV personal 00:18:33.160 --> 00:18:36.420 computers. Exactly. And the final fatal blow 00:18:36.420 --> 00:18:40.599 to NEC's PC -98 monopoly came as global hardware 00:18:40.599 --> 00:18:43.920 just kept getting faster. IBM releases the ThinkPad 00:18:43.920 --> 00:18:47.400 laptop and the PSV desktop. And NEC tries to 00:18:47.400 --> 00:18:49.980 fight back with a new machine called the PC -9821. 00:18:50.279 --> 00:18:52.440 But their marketing is so desperate at this point, 00:18:52.599 --> 00:18:54.599 their big advertising flex was bragging that 00:18:54.599 --> 00:18:57.160 their proprietary machine could scroll a specific 00:18:57.160 --> 00:19:01.000 word processor, Ichitaro, slightly faster than 00:19:01.000 --> 00:19:03.039 IBM's machine. Yeah, when you are reduced to 00:19:03.039 --> 00:19:05.420 bragging about the scroll speed of a single application, 00:19:05.940 --> 00:19:07.900 you have already lost the war on architecture. 00:19:07.940 --> 00:19:10.819 Totally. An IBM executive named Yuzuru Takamura 00:19:11.019 --> 00:19:13.680 summed it up perfectly at the time. He pointed 00:19:13.680 --> 00:19:15.980 out that graphical interfaces like Windows were 00:19:15.980 --> 00:19:18.779 the inevitable future. Global processors and 00:19:18.779 --> 00:19:20.700 generic graphics cards were going to see exponential 00:19:20.700 --> 00:19:23.460 leaps in speed and massive drops in price purely 00:19:23.460 --> 00:19:25.680 because the entire world was buying them. So 00:19:25.680 --> 00:19:27.700 what does this all mean? It means you can't out 00:19:27.700 --> 00:19:30.380 -innovate the combined R &D budget of the entire 00:19:30.380 --> 00:19:33.650 planet. Exactly. Tokimura knew that if NEC's 00:19:33.650 --> 00:19:36.690 PC -98 continued using an isolated proprietary 00:19:36.690 --> 00:19:39.230 motherboard, it would eventually be crushed by 00:19:39.230 --> 00:19:41.430 the sheer momentum of global standardization. 00:19:41.730 --> 00:19:44.490 Because Windows was built for the global PC standard. 00:19:45.009 --> 00:19:47.609 Adapting Windows to NEC's proprietary hardware 00:19:47.609 --> 00:19:50.369 was a nightmare, but for DoSV, you just supplied 00:19:50.369 --> 00:19:53.009 the kanji as a software font. And he was entirely 00:19:53.009 --> 00:19:56.460 right. By the time Windows 95 launched, the underlying 00:19:56.460 --> 00:19:59.279 battle of the operating systems was over. Windows 00:19:59.279 --> 00:20:01.839 absorbed the linguistic capability seamlessly. 00:20:02.380 --> 00:20:05.519 Both NEC's hardware monopoly and DoSV itself 00:20:05.519 --> 00:20:08.339 faded into the background. But DoSV had already 00:20:08.339 --> 00:20:11.650 won the war. It permanently globalized the Japanese 00:20:11.650 --> 00:20:14.170 computing market. It is such a profound legacy. 00:20:14.650 --> 00:20:16.789 A developer sitting in a lab with a stock watch, 00:20:16.890 --> 00:20:19.450 hiding his results from his own colleagues, manages 00:20:19.450 --> 00:20:21.950 to brute force a hardware monopoly into submission, 00:20:22.329 --> 00:20:24.910 and opens an entire nation to global standards. 00:20:25.029 --> 00:20:27.049 It really is. And, you know, it leaves us with 00:20:27.049 --> 00:20:29.529 a fascinating principle to consider today. DoSV 00:20:29.529 --> 00:20:31.589 proved that if you have enough raw processing 00:20:31.589 --> 00:20:35.130 power, you can simulate incredibly complex proprietary 00:20:35.130 --> 00:20:37.930 physical hardware entirely in software. Software 00:20:37.930 --> 00:20:40.440 always eats hardware. eventually. Precisely. 00:20:41.039 --> 00:20:43.160 Look at the walled gardens we deal with today. 00:20:43.440 --> 00:20:46.079 We have smartphones with heavily locked proprietary 00:20:46.079 --> 00:20:48.940 ecosystems. We have exclusive gaming consoles. 00:20:49.240 --> 00:20:51.940 We have highly specialized VR headsets. Right. 00:20:52.059 --> 00:20:54.619 As our processors become unimaginably powerful 00:20:54.619 --> 00:20:57.559 over the next decade, what happens to those physical 00:20:57.559 --> 00:21:00.440 monopolies? Oh wow. What happens when the next 00:21:00.440 --> 00:21:03.740 generation's equivalent of DOS V figures out 00:21:03.740 --> 00:21:06.180 how to emulate all of their proprietary physical 00:21:06.180 --> 00:21:10.480 features purely in software on completely generic, 00:21:10.839 --> 00:21:12.799 off -the -shelf hardware. That is a brilliant 00:21:12.799 --> 00:21:14.819 thought to end on. The walls of today's tech 00:21:14.819 --> 00:21:17.579 ecosystems might seem impossibly high, but someone 00:21:17.579 --> 00:21:19.539 is always in a lab with a stopwatch, figuring 00:21:19.539 --> 00:21:21.579 out how to build a software ladder right over 00:21:21.579 --> 00:21:23.960 them. As you go about your day interacting with 00:21:23.960 --> 00:21:26.759 all your frictionless devices, remember the invisible 00:21:26.759 --> 00:21:28.940 battles that made them possible. We will catch 00:21:28.940 --> 00:21:30.299 you next time on The Deep Dive.