QR Code Generator

This machine will generate a QR code from ASCII text that you write using the keyboard.

Background: QR codes have many different types, and I chose a set of restraints to make the build attainable. I restricted the generator to only generate version 1 QR codes (21×21), using only the 'Byte' encoding method from the ISO-8851-1 character set (Latin 1), using only error correction level 'L', and only using data mask 0. Because of these restrictions, the QR code can only accept 17 characters from the Latin 1 character set, which includes 191 different printable characters.

Text Display & Control Panel: For convenience, there is a 16-segment display attached to the generator so you can see what text you are typing in. (This display adapted from cadenjb) The input keyboard contains 95 common characters including but not limited to uppercase and lowercase letters. There is a backspace button and a clear display button to make it easier to type. In addition, for the 96 other characters that I did not include, there is a separate Latin 1 input panel where you can input your own bits. It also includes a backspace button and a 'write data' button. Because of the limitations of the display, characters that you manually write in will not appear on the 16-segment display, but the ASCII data will be stored in memory and will be generated into the QR code. Lastly, all inputs to the display are locked when the generation starts and unlocked after generation ends, the backspace button doesn't work if there are no characters, the keyboard/manual ASCII input does nothing once the character limit has been reached, and the generate button is locked when QR code is being generated, and when there are no characters written into memory.

QR code generation: The main part of this build is actual QR code generation. In this section, I'll walk you through how it works. First, we need to create the 'message'. This is 19 bytes which contain the data which will be held in the QR code. First, the QR code version and encoding method is added. Because of my restrictions, this is always 0100. Next the character count is added in the form of a byte. After this, the message data is added, and 0000 is added at the end. If the message is not 19 bytes long already, pad bytes are added in the form of the numbers 236 and 17 (in bytes) until all 19 bytes are full. This data is sent to the QR code over 2t serial, and will update the display. Now comes the hard part. QR codes use Reed-Solomon error correction. Specifically for my set of restrictions, I will always have 7 bytes of error correction, which can account for up to 7% of the data (or the error correction itself) being corrupted. To generate this data, I need to perform a polynomial long division within a Galois field. According to the QR specifications, we need to use bit-wise %2 and byte-wise %285. The 'message' we created earlier is now our message polynomial. The 19 bytes are now coefficients to an order-18 polynomial. To ensure we get 7 bytes at the end of the division, we multiply the message by x^7, which brings the leading term to x^25 and the lowest term to x^7. Now, we divide the message polynomial by something called the generator polynomial. This is specified by the amount of error correction bytes needed, so the generator polynomial is hard-coded into my machine as I always need exactly 7 bytes. After the division, which takes 19 steps, you are left with an order-6 polynomial, the coefficients of which are the Reed-Solomon error correction data. I figured out how to perform this entire calculation with just 2 different trapdoor ROMs (orange one is duplicated a few times for parallel processing), a few CCA's, %255 modules, and one giant shift register. After the division, the data is then sent to the display over 2t serial, and funneled into the correct spot. The data mask is applied, and the format/encoding method/mask specified is added in two places, along with the finder patterns and the timing pattern. And that's it, you have a QR code! Keep in mind this process is only for QR codes with the restrictions mentioned in the background section.

Notable Features:

Novelty: This is the second working QR code generator to exist in Minecraft.

Size: This is the smallest QR code in existence (not hard to beat as the first QR code generator was over 15 million blocks).

Speed: This is the fastest QR code generator in existence. From start to finish, not including typing time, the QR code takes about 2 minutes and thirty seconds to generate. This is around 6 times faster than the other generator that exists.

Versatility: It is able to encode any 17 characters from the ISO-8859-1 (Latin 1) character set, which includes 191 different printable characters.

Elegance: Reed-Solomon error correction uses order-25 polynomial long division within a Galois field, and I managed to fit the entire error correction circuit within 500k blocks, and it only takes a little over a minute and thirty seconds to run.

New ROM: For this project, I designed a 256-byte addressable ROM which contains the antilog and log tables for the Galois field. This lag-friendly design uses trapdoors to store each bit adjacent to each other, and takes advantage of instant wall signal transmission. Trapdoor ROMs have existed in the past, however this is the first (fully working) trapdoor ROM (that I know of) that uses both sides of each wall to transmit the data downwards, which shortens the length of the ROM down considerably.

QR Display: The display is nothing special, but all data is transmitted over two 2t serial lines (one ECC and one Message data) and funneled in with the alternating zigzag pattern that the QR code specification requires. It is scannable using a phone or other QR scanner, however I advise to use a resourcepack to increase the contrast between lit and unlit lamps. For convenience, a resource pack is included which turns all lit lamps white and unlit black.
https://cdn.discordapp.com/attachments/1113662408783831162/1113662430720...