Computer design: Input/Output
I think it would be fun to develop a hardware like standard for a computer and then write an emulator for it - and in this spirit this post should be read.
I'm sick and tired of ever changing standards and lacking downward compatibility. The industry isn't going to give us user friendly standards, so we might better do it ourselves.
In this post I want to address the question how the user input should be collected and how the graphical output should be managed. The basic idea is that the user computer interaction is always in the state defined by the graphical output (for the most part, there might be hidden information, of course). So the user input should be collected whenever the displaying of the graphical output has finished and before the next displaying of it begins and out of convenience I'll call this time interval the vertical blank.
It is, for different reasons, a good idea to let the user define what frequency he prefers for the displaying of the graphical output. On the other hand it would be too much fuss, if he would be allowed to set it arbitrarily. Let us choose a basic frequency of 150 Hz, which would also allow the frequencies 75 Hz, 50 Hz, 37.5 Hz, 30 Hz, 25 Hz and so on. This way we cover PAL exactly and NTSC still good enough for animation.
So, let there be an interrupt at this frequency and then let the user define which every n-th of this interrupt should be accompanied by the vertical blank interrupt (VBI).
In order to force programmers to respect the idea that their programs should behave more or less the same no matter what the frequency for the displaying of the graphical output is, we require that our computer possesses a special kind of RAM, namely, well, let's call it SPLIT-RAM. When in the VBI, the processor can only access SPLIT-RAM, which contains for the processor in the VBI and only for it (in a multiprocessor system or in case the VBI is interrupted by another interrupt) a copy of the state it was in, when the processor entered the VBI, modified by the actions of the processor since, meaning, should another processor, or the same processor in another interrupt, write into this RAM, then this doesn't effect what the processor in the VBI sees and neither does it effect what the graphics hardware sees and vice versa any changes by the processor in the VBI are inconsequential for the processor(s) outside of the VBI, but only noticed by the processor in the VBI and the graphics hardware.
So, the SPLIT-RAM will forget whatever the inside VBI contents were when a new VBI occurs. This also requires that, when inside the VBI, the processor cannot be interrupted by the VBI. The VBI will then be postponed until it can next occur.
It is of course possible not to care about the VBI and do all animation in the 150 Hz interrupt, but it would save cycles to care, possibly speeding up the program by the full 300 or 500 percent (for 50 Hz or 30 Hz respectively). I am aware of the fact that this method yields very bad results for movie decoding, but I'm not interested in playing movies or showing TV, but in actual computer stuff.
When a 150 Hz interrupt is accompanied by a VBI this should be visible inside the 150 Hz interrupt by checking a bit somewhere. Then, and only then, should it be possible to read the user input. There is no need for caring about input devices, the emulator can do that. All that is required is a an upper bound for the input codes. Now, the role of the input codes is to steer the program and it's fair to say that there is a certain limit to the complexity of this, even if we allow for motion sensors. So, for what it's worth, let us allow 32 sensors with 64 bits each, hence an input code would be 256 bytes long. Per VBI we could generously allow 256 different input codes, writing them in wrap mode into an address space of 64 KB. Under optimal (VBI at 150 Hz) conditions that results in a user computer data flow of 9600 KB per second.
It's not really a problem if that isn't good enough, for instance if you would use brain scans to upload movies onto your computer (although I doubt that you could break that barrier that way), because you could use as many other interfaces as you wished. For almost all imaginable ways to steer a program the above interface would be good enough though. MMORPGs are not considered here, because synchronising them to the VBI is not an option. They are a case for another interface.
Finally, in case of a parallel processor system, the input might lack one VBI behind, but that's not really a problem, if the VBI frequency is 150 Hz and in case it isn't, the accompagnation bit can simply be set one 150 Hz interrupt earlier. The SPLIT-RAM makes sure that no problems result from this.
I'm sick and tired of ever changing standards and lacking downward compatibility. The industry isn't going to give us user friendly standards, so we might better do it ourselves.
In this post I want to address the question how the user input should be collected and how the graphical output should be managed. The basic idea is that the user computer interaction is always in the state defined by the graphical output (for the most part, there might be hidden information, of course). So the user input should be collected whenever the displaying of the graphical output has finished and before the next displaying of it begins and out of convenience I'll call this time interval the vertical blank.
It is, for different reasons, a good idea to let the user define what frequency he prefers for the displaying of the graphical output. On the other hand it would be too much fuss, if he would be allowed to set it arbitrarily. Let us choose a basic frequency of 150 Hz, which would also allow the frequencies 75 Hz, 50 Hz, 37.5 Hz, 30 Hz, 25 Hz and so on. This way we cover PAL exactly and NTSC still good enough for animation.
So, let there be an interrupt at this frequency and then let the user define which every n-th of this interrupt should be accompanied by the vertical blank interrupt (VBI).
In order to force programmers to respect the idea that their programs should behave more or less the same no matter what the frequency for the displaying of the graphical output is, we require that our computer possesses a special kind of RAM, namely, well, let's call it SPLIT-RAM. When in the VBI, the processor can only access SPLIT-RAM, which contains for the processor in the VBI and only for it (in a multiprocessor system or in case the VBI is interrupted by another interrupt) a copy of the state it was in, when the processor entered the VBI, modified by the actions of the processor since, meaning, should another processor, or the same processor in another interrupt, write into this RAM, then this doesn't effect what the processor in the VBI sees and neither does it effect what the graphics hardware sees and vice versa any changes by the processor in the VBI are inconsequential for the processor(s) outside of the VBI, but only noticed by the processor in the VBI and the graphics hardware.
So, the SPLIT-RAM will forget whatever the inside VBI contents were when a new VBI occurs. This also requires that, when inside the VBI, the processor cannot be interrupted by the VBI. The VBI will then be postponed until it can next occur.
It is of course possible not to care about the VBI and do all animation in the 150 Hz interrupt, but it would save cycles to care, possibly speeding up the program by the full 300 or 500 percent (for 50 Hz or 30 Hz respectively). I am aware of the fact that this method yields very bad results for movie decoding, but I'm not interested in playing movies or showing TV, but in actual computer stuff.
When a 150 Hz interrupt is accompanied by a VBI this should be visible inside the 150 Hz interrupt by checking a bit somewhere. Then, and only then, should it be possible to read the user input. There is no need for caring about input devices, the emulator can do that. All that is required is a an upper bound for the input codes. Now, the role of the input codes is to steer the program and it's fair to say that there is a certain limit to the complexity of this, even if we allow for motion sensors. So, for what it's worth, let us allow 32 sensors with 64 bits each, hence an input code would be 256 bytes long. Per VBI we could generously allow 256 different input codes, writing them in wrap mode into an address space of 64 KB. Under optimal (VBI at 150 Hz) conditions that results in a user computer data flow of 9600 KB per second.
It's not really a problem if that isn't good enough, for instance if you would use brain scans to upload movies onto your computer (although I doubt that you could break that barrier that way), because you could use as many other interfaces as you wished. For almost all imaginable ways to steer a program the above interface would be good enough though. MMORPGs are not considered here, because synchronising them to the VBI is not an option. They are a case for another interface.
Finally, in case of a parallel processor system, the input might lack one VBI behind, but that's not really a problem, if the VBI frequency is 150 Hz and in case it isn't, the accompagnation bit can simply be set one 150 Hz interrupt earlier. The SPLIT-RAM makes sure that no problems result from this.
Labels: 04, computer design
Eingetragen Am/um
21:28
