Building screen and keyboard RAM

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Building screen and keyboard RAM

tyler1313
I'm trying to build the hack computer on a program called logisim. I'm curious about how to build some of the built in chips in this course as there is no explanation of how there are built here. If I was going to build say the screen and keyboard RAM, how big (how many registers) would they each be and would I build them exactly the same as the RAM16k chip? In this case, the only difference between the RAM 16K and the screen/keyboard RAM is that the value of the screen registers affects the pixels on screen and the value of the keyboard registers is affected by keyboard input?
Reply | Threaded
Open this post in threaded view
|

Re: Building screen and keyboard RAM

cadet1620
Administrator
The main problem with Screen and Keyboard with Logisim are that you can't connect what you build with your PC's screen or keyboard.

IvanT build a custom component for Logisim that is the nt2 Screen and you can use Logisim's built-in Keyboard component.

Here an example of aLogisim computer Using ivant's Screen

--Mark
   
Reply | Threaded
Open this post in threaded view
|

Re: Building screen and keyboard RAM

redemptionc
In reply to this post by tyler1313
I want to implement keyboard too!
I'm curious about the interrupt mechanism !
Reply | Threaded
Open this post in threaded view
|

Re: Building screen and keyboard RAM

rleininger
If you are asking about the interrupt mechanism of the Hack computer - there is none.  The Hack computer does not provide any kind of "hardware" interrupts.  The means by which the scan code of an attached hardware keyboard is provided to the Hack computer's keyboard register is hidden within the code that is used to implement the Hardware simulator and the CPU simulator programs.

Nothing in the hardware specification for the Hack computer, such as it is, provides a description of how the screen and keyboard interfaces work beyond the boundary of memory.  Only the effects seen on the screen based on current memory values and the value seen in the keyboard register based on the key depressed are described.
Reply | Threaded
Open this post in threaded view
|

Re: Building screen and keyboard RAM

WBahn
Administrator
In reply to this post by redemptionc
As rleininger says, the Hack has no defined interrupt. This may sound unrealistic, but quite few of the simplest microcontrollers have no interrupts or only timer-based interrupts. The reason -- cost. If getting rid of the interrupt circuitry saves $0.001 per part and you are selling 10 million of the product a year, then that's an additional $10,000 to the bottom line every year.

Without interrupts, if your program wants to detect that a key has been pressed, it has to look at the keyboard register while the key is depressed. So our code has to run in a loop that periodically "polls" the keyboard register to see if there is anything other than zero there.

But it's not that simple. A single press of the key will likely result in the key being depressed for many, many clock cycles. Let's use some old fashioned numbers and say that we have a real fast typist doing 100 words per minute. By convention, this is then 500 characters per second, or 2 ms per keystroke. The key is down the majority of that time, but let's call it half of the time, or 1 ms. One a processor with a 4 MHz clock that takes four clock cycles to execute a single instruction, that's enough time to execute 1000 instructions.

If our loop is too slow, then there is the change that we will poll it and see nothing, and then before we poll it again the person will press and release a key and we will still see nothing the next time. This is bad.

So we make sure that we poll it many times in the span that it takes the fastest typing speed we are concerned with to press and release a key. But now we will see the same key code many times in a row. So our code has to detect when the code changes and only report a key press on the first instance of each change (this approach works pretty well, but it doesn't provide for "autorepeat" when you intentionally hold down the key -- but the code can take care of that case, too).

The code is quite a bit more complicated than it would have to be if you had an interrupt, but the code only has to be written once (and then it can be used in many, many products).

If you wanted to build a system up in hardware around the Hack, you have to make some decisions on how to do things that are beyond the Hack specification. Probably the easiest way to do this is to use dual-port memory. There are a few different styles, but in one case it is nothing more than a memory bank that has two address ports -- a read address and a write address. For the screen memory, the Hack only needs access to the write address port so that it can write data into the memory. The video system, on the other hand, only needs access to the read port since it just needs to know what is stored there. The reverse is the case for the keyboard buffer.

Another simple way to accomplish the same goal is to use normal memory but multiplex the input and drive it with a clock that it twice as fast as the Hack clock. One one clock cycle the Hack controls the memory pins and on the other clock cycle the video system does. Neither system is even aware of the presence of the other system and thinks that they are the sole owners of the memory.