Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

I'll try to explain my design and reasoning, working up from the seven-segment encoder. The "7hex" chip uses a demultiplexer with the input tied high simply because I did not  build a dedicated decoder at that point yet. Using such a decoder would save a lot of NANDs so I will probably switch to that. From there the signals go into a series of three-state buffers with the enable tied to the data, turning the signals into "three-state bits" if you will. These are tied to one bus per output line, making essentially an easy to program ROM by tying each input to the buses corresponding to a "one" in that position. The busses are then inverted, because inverting this output meant drawing less ROM lines (i.e. the average output pattern has more ones than zeroes).

Moving on to the "Hex Digit" module, it is set up pretty similarly to the display in the videos, with the ripple blanking checking if the digit is zero AND if ripple blanking is in, then blanking this digit and sending ripple blank out. The ripple negative was more complicated tho. The only solution I could come up with was to tie the blanking *output* of the *next* digit back into this one, to "look ahead" to see if we're on the last blank digit, and if so, enable the negative sign.

Finally, the display itself, basically it uses a multiplexer to choose between the decimal and hex formats, and then there's a bit of logic for the hex blanking mode. Other than that it's wired up pretty much as you'd expect, with the blanking wrapping around to the previous digit for the ones that need ripple negative.