My Goodness, It Has Been a While, Hasn’t It?
I didn’t realize just how long it’s been since I posted and update on the OZ-3! I had a really busy and awesome summer, and I’m now settling into the school routine in my Senior year of high school.
Specific to the OZ-3, I decided to stop developing it short of my main goals. I’ll go into the details, but in the end I got a program running that’s essentially a very simple text editor that interfaces with both a keyboard and the LCD screen. It holds a buffer of 1024 characters, and supports all manner of symbols, shifting, arrows to navigate about the text, and skipping lines. A few reasons for stopping before making a more complex program are that 1), just making a program with such basic functionality was a huge task that taxed my brain and patience. I hadn’t anticipated that. Two, I started work in an embedded systems research lab at Oakland University under Dr. Darrin Hanna. I’ll elaborate on that in a post on the home page, but I became busy with a couple of projects for the lab and I wanted to shift my focus to the research I was doing. Lastly, I had simply become too busy otherwise. I worked quite a bit over the summer, and I was gone just about every other week, so keeping up consistent work on my personal projects was difficult. I decided to lay it down for the summer and pick something else up around this time of the year.
Back to the OZ-3. I never did make a new assembler, although the idea still exists and it’ll probably be used if I do get back into that type of CPU design. The assembler I had already written (version 2) provided me with the functionality that I needed to do what I wanted.
A new piece of hardware I designed for keyboard interfacing was a small module that hooks up to the input port of the OZ-3 and grabs characters from the keyboard as they come along. It has a few inputs: the keyboard clock, the keyboard data line, a character ready flag, a data bus output for the ASCII code of the scan code of the character, and an acknowledgment input. When the keyboard initiates a data transfer, the module extracts the 8-bit scan code from the 11-bit packet, then sets the character ready flag. The OZ-3 is more or less constantly checking that flag, and when it goes high, it reads the scan code and raises the acknowledgment input to tell the keyboard module that it’s ready to accept another character. I made it so that when a scan code is ready, the keyboard module can’t accept a new scan code, for a couple of reasons. First, it simplifies the logic within the module, and second, it provides a good way to handle missed input events without storing the events in a buffer. If there weren’t a buffer and the keyboard module kept overwriting the scan code it had ready, the end result would be, say, missing characters from sentences and words that the user typed. If the keyboard module doesn’t accept new scan codes, then the system will simply appear to be slow. While the user will have to re-type input, nothing will be lost, necessarily, in the end.
The next step to connecting the keyboard and LCD screen was to convert the rather arbitrarily assigned scan codes into usable, corresponding ASCII codes. The LCD screen uses standard ASCII codes for just about every English character, so I found it to be a pretty convenient setup. The method to convert scan codes to ASCII is generally a tedious and space-consuming one. Considering four-byte instructions, the subroutine that does the conversion takes up about 1,700 bytes of a program, and it’s just a brute force if-then-else tree, linking scan codes with ASCII codes. I didn’t like the inelegance of the solution, but it was the best I could come up with.
So, once the keyboard input has gone from scan codes to ASCII codes, it’s ready to go to the LCD screen. 1024 addresses in memory are “allocated” at the beginning of the program by clearing all of them to 0×0000. Each line of the LCD screen takes up sixteen addresses, and with two lines, a full screen of the LCD is thirty-two addresses. Two pointers keep track of the start of each of the lines in memory, and a subroutine handles grabbing the data from memory at those pointers and displaying them to the LCD every time a key is pressed. I did it this way, instead of using the extra memory in the LCD, because it would allow me to write more with the program, but also because it’s much, much easier to manipulate the text within the on-board memory simply because of the way the LCD screen allows access to its memory.
I mentioned the line pointers already. There’s also a cursor pointer that keeps the address of the place in memory to be written to upon the next keystroke, and a cursor is displayed on the LCD screen corresponding to that place. Using the arrow keys, which are actually 2, 4, 6, and 8 on the number pad because the arrow keys have double scan codes, the user can scroll through the buffer line by line using the vertical keys, or character by character using the horizontal keys.
There are bad things about the program that I wish I had fixed when I was still engaged in writing it. I do want to someday fix them, but it looks like that may not be any time soon. Anyway, the main one is that the characters aren’t inserted into the string, it just always over-writes. Backspace only moves the cursor back and puts a blank in its place, and the unused keys that still return valid ASCII codes that aren’t supported by the LCD screen just show up as two vertical lines, the LCD’s default for unknown characters. I hadn’t programmed their lack of functionality in, so now they have bad functionality. Caps lock also doesn’t work. I think that’s about it. I ought to be posting a video demonstrating this soon enough, so I can show some things instead of just talk about them!
Ben Oztalay
