So how should we go about adding mass storage and network access to the head computer? Well, we can start by assuming that we already have devices like hard disk and some network interface card built up and sitting on the shelf and now we have to take these devices and somehow integrate them into our computer architecture. How can we possibly do it? Well, instead of using physical devices, we can realize simple versions of these devices is built in chips that can be added to our harder simulator. And how to do this is something that I'm going to discuss separately later in this unit. So for now, let us assume that we have a built in disk cone shape, like flash memory unit, that is capable of storing lots of bits persistently. What can we do with this new capability? Well, one thing which is natural to do is to use this new disk for saving and loading hack programs. And as usual, any such change, any such new capability and modification requires modifying several different layers in the overall architecture. First, we must tinker with hack hardware, and allow programs to reside in a writable memory space, rather than in the read-only ROM, as we do now. Second, we'll have to specify a simple file system, and develop and operating system class that realizes obstructions like, loading the file and storing the file using this new disk device. Now, at this point it would make sense to also introduce some sort of a command shell or a terminal window that will enable users to access and manipulate their files. So as you see, as usual ,one thing leads to another. Now, what about connecting the head computer to the Internet? Now, this should be cool. But how can we possibly do it? Well, once again, like we did with the disk, let's assume that we have available to us a built-in network interface chip, and we can integrate this chip into our hardware simulator. Now, this chip should be designed to interact with the hack hardware from one end. And with some socket on your actual PC. And this is actually quite similar to the way the currently implemented keyboard shape operates. And because it interacts with the actual physical keyboard on your PC. So that's what we need also from the interface card, we need it to be able to handle steam of bits coming from the internet instead of from your keyboard. And so, in order to manage this new device, we'll have to right a new operating system class that knows how to move bits from one place to another using some standard communications protocol. Once we have these capabilities in place we could develop also subject programs that talk with these cheap, and provide a gateway to the Internet. For example, it will be quite cool to use Jack to develop a simple web browser based on HTTP. So as you see, all the extensions that we discussed that focus on adding peripheral devices to the basic hardware. Well, all these extensions require that you first design and integrate a new built in chip. Like we did with the disc and network interface that we just discussed. So how do you go about about? How do you build such a built in chips? Well, when we developed the Nand to Tetris simulators, we designed a simple and well documented interface for adding so called build in chips. And thanks to this interface, the simulated hechuddle platform is open ended, and extensible. So if you wish to build a new built in chip, like a hard disk or a speaker for example if you're interested in music, then you should start by first specifying and developing a stand alone Java class, that realizes the low level functionality that you want to use in this new device. And if you want to learn more about how to develop such Java chips, if you will, you can download the simulator software from the Nand to Tetris website and simply read the documentation. Our code is open sourced, pure Java. And you're welcome to modify and extend it as you please. Now, there's one thing that goes without saying. But I guess I'll say it anyways. Any one of the optimization and extension projects that we discussed requires very careful and pragmatic planning, and realist planning. You should start by articulating the exact functionality that you seek to deliver With this new device or with this new extension. And don't shoot too high. Focus on what is absolutely needed and ignore the rest. Next, you should identify every sort of sub-system an API in the existing architecture that has to be modified both in the hardware on the software. Then, you should specify the necessary API's of the new capabilities that you develop. And write some stub programs that test these new capabilities. Only after making all these preparations should you start working on the actual implementation that you have to deliver. And needless to say, but I'll say it anyway. Before implementing some reduced versions of the mass storage or network interface or any other device that tickles your fancy, you must first read about these things in the Internet. And then, once again, settle on the minimum subset of capabilities that you absolutely need for your project, otherwise you'll get lost. And so, in closing, I'd like to say something about sharing. If you come up with a cool project, and if you want to share it with other learners, we'll be glad, if you'll let us know about it, you don't necessarily have to share everything with the rest of the world. You may want to just describe your project idea, or the general approach, or the specification, or anything else that you want to share, so that other people will have the benefit of building this project from your own design, just like we asked you to build our designs throughout this course. Now, in the next unit, we'll talk about some more extensions at the Jack level and high level languages in general, and we'll also discuss something that comes up all the time in the discussion forums of Nand to Tetris courses. We'll talk about how to build the head computer, and actually any other computer, physically, rather than by a simulation. And we'll do this using a remarkable hardware technology called SPGA. So that's what we'll do in the next unit.