8-bit CPU: Display (part 2)

Earlier I worked on a display module, but could not proceed because I had no means of programming an EEPROM. I had to step aside for a moment and build a device that can do that.

Now I have programmer, but what data should I write on the chip? Well, Ben explained the main idea quite carefully in a series of videos, but my build differs a little.

One thing is - I did not follow the videos exactly, so I'm fairly certain that I have connected display segments to EEPROM's data output pins differently. In Ben's video there were several wires, connecting pins on different sides of EEPROM and displays. I have just one.

Ben mapped every digit on a paper and carefully worked out the byte values for each. I suppose it's fine if you want to show the process in detail. But I have lazier idea - let C compiler and Arduino do it for me. They are much better at performing tedious calculations. I'll just set the rules.

For starters, I have to figure out which bit is connected to which segment. I could probably trace the wire from EEPROM to the display, then look up in datasheet which pin controls which segment. But there's an easier way - just try it out. Remove the EEPROM, grab a jumper wire and connect data lines to +5V one by one. See what lights up and write it down as #define in code.


Got something like this (showing just 2 lines of 8):
#define SEG_BIT_A       (1 << 5)
#define SEG_BIT_B       (1 << 4)
The (1<<4) translates to 0b00010000, but expresses the intent more clearly: we want a value with only bit #4 set. Here segment B appears to be connected to EEPROM's data pin IO4.

Now, when we have all segments mapped out, we can combine them to get digits. For example: digit '4' should have segments B, C, F and G lit. If we translate that to code we get:
#define DIGIT_4     (SEG_BIT_B | SEG_BIT_C | SEG_BIT_F | SEG_BIT_G)
I am not sure what byte value exactly that produces, but actually it doesn't matter. If rules are set correctly it will just work. If not - I've probably misspelled something (or the whole idea is wrong 😉). If I decide to rewire the display differently, I'll just have to update few #defines. The point is - I'll never have to re-calculate the whole table by hand.

I decided to re-arrange the data on EEPROM, so that mappings for numbers are together. I'll have 4 bytes for value 0, next four - for 1 and so on.

Because of that I can process one value, write the bytes to EEPROM and move on to the next. I do not have to return multiple times for the value, to get ones-place, tens-place and so on. There are no calculations involving division and taking reminder needed, I can just use sprintf() function to format the value as text (I suspect, sprintf() does something similar internally anyway, but I do not have to worry about it) and then map each character (not to be confused with value it represents) to the digit. One small thing - since I like little endian better, I chose to store patterns for displays (ones-place, tens-place) from right to left. So I have to process the formatted text backwards, but that is not a big problem.

My EEPROM has 4 times more capacity compared to ones Ben used, so I do not have to choose carefully what extra display mode to add. I filled it with mappings for decimal unsigned, decimal signed, hexadecimal and octal display modes. And I still have space for 4 more.

EEPROM is programed now, let's put it in, arrange wires lines for some random input, power it up, and crank up the speed of the clock.


Ok, it shows something, and if I change the input it shows different value. Now, how do I know it works correctly? One thing that comes in mind is to connect it to Arduino, write a program that counts and outputs all possible byte values. Additionally: connect those 2 mode-select wires and cycle the display modes. Then I'll just have to observe it running for few minutes. One more finishing touch: let's connect that 555 chip.


Observations did not reveal any anomalies, so I can consider this done for now and move to other things. Notice that I did not add any register chips to it. That's because I intended to build just a display device, not an output register. I'm sure I will merge those eventually, but for now I plan to use the display independently.

After I have used the display for some time now, I've noticed few shortcomings. But nothing major, I'll try to fix them later.

Comments

Post a Comment

Popular posts from this blog

8-bit CPU: ALU and Flags

Image
Now that I have a pair of devices that can store a byte, I can proceed to do something more interesting. Build a device that add them together, for example. In other words - let's build an ALU. The design follows same basic idea as Ben's - two 4-bit adders, XOR gates and an output buffer. I'm using HC logic here, so I used 74HC283, 74HC86 and 74HC245 chips. Since I've built only one Register and did not want to build another, I connected my Program Counter board as register B. If I keep the counting function disabled, it serves the purpose just fine. It took a lot of wires, but I'm just getting started, let's build Flags register as well.  There were no surprises with Zero flag - 4 NOR and 3 AND gates does the job - just following the Ben's design. Another latch (74HC173) chip to store it, done. The fun starts with the Carry flag: I wanted to support a carry-in signal for the ALU. It is very useful if one wants to perform the addition or subtraction for wid
Read more

8-bit CPU: Clock module

Image
The parts are finally here an I can have some fun! Since nothing runs without clock, I decided to start with that module. It's probably not the most fun one, but I definitely need it, before doing something else. I was planning to follow Ben's design to some point. I had some TS555CN timers at home, so I decided to try those first, before opening the package with the new ones I ordered. Wired up the 555 in basic astable configuration with capacitors, potentiometer and decided to test if it works. So I connected a LED to the output and powered it up. It worked. Well, sort of. LED blinked and I  could adjust the frequency, but then suddenly it started to blink very fast, then again back to normal. What's even stranger I could trigger or suppress the effect by touching either chip or capacitor (just top of the chip, not the leads). I did accidentally connect my power backwards on first try 😓, so I figured it caused some damage or something. Replaced the chip with one of my n
Read more

8-bit CPU: Memory

Image
Time for another important part of the computer - memory. Here I think I have to come up with my own design. Ben's version has only 16 bytes, uses nowadays-exotic 74189 memory chips and there are DIP switches for programming. For the memory I plan to use 62256 SRAM chip. It can store 32 KiB of data, I initially plan to use just 256 bytes, so I'll connect remaining address pins to GND. I'm also not in a mood for any DIP switch based programming, so I'll add an EEPROM instead. There are several ways how computer can utilize such setup: split the address space into program and data memory. This is how Ben's 6502 breadboard computer works. Some additional logic gates are used for chip selection, the main issue however is that it is not very flexible. use Harvard architecture , where program and data memories are completely separate. Reading and fetching instruction are two different operations: former accesses RAM, latter - ROM. This is how AVR microcontrollers (heart
Read more